cognitive-doc-design

Structures documentation to reduce cognitive load for readers and reviewers.

Updated Aug 25, 2026
One-click install
npx skills add https://github.com/CarlosWilliamsR/SketchOS --skill cognitive-doc-design-carloswilliamsr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: cognitive-doc-design
Source: https://github.com/CarlosWilliamsR/SketchOS/tree/main/.config/opencode/skills/cognitive-doc-design
Command: npx skills add https://github.com/CarlosWilliamsR/SketchOS --skill cognitive-doc-design-carloswilliamsr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Documentation often becomes long, dense, and hard to scan, forcing readers and PR reviewers to reconstruct context before they can act. This Skill applies cognitive-load principles so guides, READMEs, RFCs, and review docs communicate the key decision or action immediately. ## Core Features & Use Cases - Cognitive Patterns: Applies six rules including leading with the answer, progressive disclosure, chunking, signposting, and recognition over recall. - Default Document Template: Provides a reusable Markdown structure with an outcome-oriented title, quick path, details table, checklist, and next step. - PR Review Guidance: Makes the review path explicit by stating what to review first, what is out of scope, and linking chained PRs. - Use Case: When writing an architecture RFC that reviewers keep ignoring, restructure it so the decision appears first, details live in a scannable table, and acceptance criteria become a checklist. ## Quick Start Ask the AI to rewrite your README or PR description using cognitive load principles so the key decision and action steps appear first.

Frequently Asked Questions about cognitive-doc-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write documentation that is easier to scan?

Lead with the decision or action, then add context afterward. Group related information into small sections, use headings and callouts as signposts, and prefer tables, checklists, and examples over long prose paragraphs.

How to structure a PR description for faster code review?

State what reviewers should look at first, declare what is intentionally out of scope, and link previous and next PRs when work is chained. Keep each section focused on one decision and use checklists for acceptance criteria and verification.

What is progressive disclosure in technical writing?

Progressive disclosure means presenting the happy path first, then layering in details, edge cases, and references. Readers get the essential answer immediately and only dig deeper when they need to.

When should I not use a fixed documentation template?

Skip the default template when the repository already provides a stronger or established structure. The goal is reducing cognitive load, so an existing convention that readers already know usually wins over introducing a new format.

How can I check if a PR is too large to review easily?

Run gh pr view <PR_NUMBER> --json additions,deletions,changedFiles to inspect the changed-line count. Large diffs signal high cognitive load, so consider splitting the work or documenting the review path explicitly.