cognitive-doc-design

Agent Skills › Gentleman-Programming/gentle-ai › cognitive-doc-design

cognitive-doc-design

GitHub

用于设计降低认知负荷的技术文档，涵盖PR描述、架构说明及新手指南。通过结构化模板和渐进式披露等模式，提升文档的可读性、扫描效率及审查体验。

skills/cognitive-doc-design/SKILL.md Gentleman-Programming/gentle-ai

Trigger Scenarios

编写或编辑README、RFC、架构文档创建PR描述、审查笔记、入职指南

Install

npx skills add Gentleman-Programming/gentle-ai --skill cognitive-doc-design -g -y

More Options

Use without installing

npx skills use Gentleman-Programming/gentle-ai@cognitive-doc-design

指定 Agent (Claude Code)

npx skills add Gentleman-Programming/gentle-ai --skill cognitive-doc-design -a claude-code -g -y

安装 repo 全部 skill

npx skills add Gentleman-Programming/gentle-ai --all -g -y

预览 repo 内 skill

npx skills add Gentleman-Programming/gentle-ai --list

SKILL.md

Frontmatter

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

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