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.

Informações da origem

Repositório
Gentleman-Programming/gentle-shell
Última atividade na origem
25 de agosto de 2026 às 15:16
Idioma detectado do SKILL.md
inglês
Estrelas
1.338
Forks
204

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
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 ```
Ver no GitHub