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
| Pattern |
Rule |
| Lead with the answer |
Put the decision, action, or outcome first. Context comes after. |
| Progressive disclosure |
Start with the happy path, then add details, edge cases, and references. |
| Chunking |
Group related information into small sections. Keep flat lists short. |
| Signposting |
Use headings, labels, callouts, and summaries so readers know where they are. |
| Recognition over recall |
Prefer tables, checklists, examples, and templates over prose that must be remembered. |
| Review empathy |
Design 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
1---2name: cognitive-doc-design3description: Design docs that reduce cognitive load. Trigger: writing guides, READMEs, RFCs, onboarding, architecture, or review-facing docs.4license: Apache-2.05---6
7## When to Use
8
9Load this skill when creating or editing documentation that people need to understand quickly, retain, or use during review.
10
11Use it especially for:
12
13- PR descriptions and review notes.
14- Contributor or maintainer guides.
15- Architecture, workflow, or onboarding docs.
16- Any doc that currently feels long, dense, or hard to scan.
17
18## Critical Patterns
19
20| Pattern | Rule |
21|---------|------|
22| Lead with the answer | Put the decision, action, or outcome first. Context comes after. |
23| Progressive disclosure | Start with the happy path, then add details, edge cases, and references. |
24| Chunking | Group related information into small sections. Keep flat lists short. |
25| Signposting | Use headings, labels, callouts, and summaries so readers know where they are. |
26| Recognition over recall | Prefer tables, checklists, examples, and templates over prose that must be remembered. |
27| Review empathy | Design docs so reviewers can verify intent without reconstructing the whole story. |
28
29## Documentation Shape
30
31Use this default structure unless the repo already provides a stronger template:
32
33```markdown
34# <Outcome-oriented title>
35
36<One paragraph: what changed, who it helps, and why it matters.>
37
38## Quick path
39
401. <First action>
412. <Second action>
423. <Verification or expected result>
43
44## Details
45
46| Topic | Decision |
47|-------|----------|
48| <area> | <concise explanation> |
49
50## Checklist
51
52- [ ] <Reader can confirm this>
53- [ ] <Reader can confirm that>
54
55## Next step
56
57<Link or action that continues the workflow.>
58```
59
60## PR and Review Docs
61
62When documenting a PR, reduce reviewer burnout by making the review path explicit:
63
64- State what to review first.
65- State what is intentionally out of scope.
66- Link the previous and next PR when work is chained.
67- Keep each section focused on one decision or unit of work.
68- Use checklists for acceptance criteria and verification.
69
70## Commands
71
72```bash
73# Check markdown files changed in the current branch
74git diff --name-only -- '*.md'
75
76# Inspect PR changed-line count for cognitive load
77gh pr view <PR_NUMBER> --json additions,deletions,changedFiles
78```
gabrielmoreira