cognitive-doc-design

Structures Markdown documentation to reduce cognitive load for readers and reviewers.

Updated May 24, 2026
One-click install
npx skills add https://github.com/etrigan16/v0-cipher-ar --skill cognitive-doc-design-etrigan16
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: cognitive-doc-design
Source: https://github.com/etrigan16/v0-cipher-ar/tree/main/.opencode/skills/cognitive-doc-design
Command: npx skills add https://github.com/etrigan16/v0-cipher-ar --skill cognitive-doc-design-etrigan16

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 lead with the answer and stay easy to navigate. ## Core Features & Use Cases - Cognitive Patterns: Applies six rules including lead-with-the-answer, progressive disclosure, chunking, signposting, and recognition over recall. - Default Document Template: Provides a reusable Markdown structure with quick path, details table, checklist, and next step sections. - 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 onboarding guide that feels overwhelming, restructure it so new contributors see the happy path first, with edge cases and references progressively disclosed afterward. ## Quick Start Restructure my README using the cognitive-doc-design patterns so it leads with the outcome and uses progressive disclosure.

Frequently Asked Questions about cognitive-doc-design

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

FAQPage Schema
How do I reduce cognitive load in technical documentation?▼

Lead with the answer or decision first, then add context. Use progressive disclosure to show the happy path before edge cases, chunk related information into small sections, and prefer tables and checklists over prose that must be memorized.

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.

What is progressive disclosure in documentation writing?▼

Progressive disclosure means presenting the simplest happy path first, then layering in details, edge cases, and references. Readers get what they need immediately without wading through exceptions upfront.

When should I not use a fixed documentation template?▼

Skip the default template when the repository already provides a stronger established structure. The skill explicitly defers to existing repo conventions rather than forcing its own shape onto every document.

How do I check which Markdown files changed in my branch?▼

Run git diff --name-only -- '*.md' to list changed Markdown files. To gauge review load on a PR, use gh pr view <PR_NUMBER> --json additions,deletions,changedFiles to inspect changed-line counts.