← LeaderboardThe Skill Leaderboard

gentle-ai-cognitive-doc-design

Design docs that reduce cognitive load. Trigger: writing guides, READMEs, RFCs, onboarding, architecture, or review-facing docs.

Published by Gentleman-Programming ↗Gentleman-Programming/gentle-shell

Try your first task

Draft a quick-path onboarding README

Start a fresh conversation. Replace the highlighted placeholders.

Use gentle-ai-cognitive-doc-design to draft an onboarding README for [service and team] from [architecture, setup, tests, owners, access paths, and escalation contacts]. Follow the repository's template when stronger; otherwise lead with the outcome, give a short happy-path setup and verification sequence, then concise decision details, a reader checklist, and the next useful link. Group edge cases after the quick path and use supplied facts without inventing contacts or commands.

Required inputs

  • [service and team]
  • [architecture, setup, tests, owners, access paths, and escalation contacts]

User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗

SKILL.md

name: gentle-ai-cognitive-doc-designdescription: "Design docs that reduce cognitive load. Trigger: writing guides, READMEs, RFCs, onboarding, architecture, or review-facing docs."license: Apache-2.0metadata:   author: gentleman-programming  version: "1.0"

When to Use

Load this skill when creating or editing documentation that people need to understand quickly, retain, or use during review.

Use it especially for:

  • PR descriptions and review notes.
  • Contributor or maintainer guides.
  • Architecture, workflow, or onboarding docs.
  • Any doc that currently feels long, dense, or hard to scan.

Critical Patterns

PatternRule
Lead with the answerPut the decision, action, or outcome first. Context comes after.
Progressive disclosureStart with the happy path, then add details, edge cases, and references.
ChunkingGroup related information into small sections. Keep flat lists short.
SignpostingUse headings, labels, callouts, and summaries so readers know where they are.
Recognition over recallPrefer tables, checklists, examples, and templates over prose that must be remembered.
Review empathyDesign docs so reviewers can verify intent without reconstructing the whole story.

Documentation Shape

Use this default structure unless the repo already provides a stronger template:

# <Outcome-oriented title>

<One paragraph: what changed, who it helps, and why it matters.>

## Quick path

1. <First action>
2. <Second action>
3. <Verification or expected result>

## Details

| Topic | Decision |
|-------|----------|
| <area> | <concise explanation> |

## Checklist

- [ ] <Reader can confirm this>
- [ ] <Reader can confirm that>

## Next step

<Link or action that continues the workflow.>

PR and Review Docs

When documenting a PR, reduce reviewer burnout by making the review path explicit:

  • State what to review first.
  • State what is intentionally out of scope.
  • Link the previous and next PR when work is chained.
  • Keep each section focused on one decision or unit of work.
  • Use checklists for acceptance criteria and verification.

Commands

# Check markdown files changed in the current branch
git diff --name-only -- '*.md'

# Inspect PR changed-line count for cognitive load
gh pr view <PR_NUMBER> --json additions,deletions,changedFiles