Skip to main content

gentle-ai-cognitive-doc-design

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

Quellinformationen

Repository
Gentleman-Programming/gentle-shell
Letzte Quellaktivität
25. August 2026 um 15:16
Erkannte Sprache von SKILL.md
Englisch
Sterne
1.338
Forks
204

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
gentle-ai-cognitive-doc-design
description
Design docs that reduce cognitive load. Trigger: writing guides, READMEs, RFCs, onboarding, architecture, or review-facing docs.
license
Apache-2.0
metadata
{"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 | 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: ```markdown # <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 ```bash # 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 ```
Auf GitHub ansehen