cognitive-doc-design

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

cognitive-doc-design

GitHub

专注于降低认知负荷的文档设计技能，适用于PR描述、README、RFC等。提供结构化模板和渐进式披露等模式，帮助快速创建清晰、易扫描的技术文档。

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

Trigger Scenarios

编写或编辑技术指南撰写README文件创建RFC文档编写入职指南生成架构文档准备审查用文档

Install

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

More Options

Non-standard path

npx skills add https://github.com/Gentleman-Programming/gentle-ai/tree/main/internal/assets/skills/cognitive-doc-design -g -y

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