cognitive-doc-design

Structures documentation to reduce cognitive load for readers and reviewers.

Updated Jun 5, 2026
One-click install
npx skills add https://github.com/zMynxx/bifrost-with-opencode --skill cognitive-doc-design-zmynxx
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: cognitive-doc-design
Source: https://github.com/zMynxx/bifrost-with-opencode/tree/main/.opencode/skills/cognitive-doc-design
Command: npx skills add https://github.com/zMynxx/bifrost-with-opencode --skill cognitive-doc-design-zmynxx

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Technical 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 docs lead with the answer, chunk information, and stay scannable. ## Core Features & Use Cases - Cognitive Patterns: Six rules including lead with the answer, progressive disclosure, chunking, signposting, recognition over recall, and review empathy. - Default Document Template: A reusable Markdown structure with an outcome-oriented title, quick path, details table, checklist, and next step. - PR Review Guidance: Practices for reducing reviewer burnout, such as stating review order, declaring out-of-scope items, and linking chained PRs. - Use Case: When writing an onboarding guide or a PR description that feels dense, apply the template and checklist patterns so reviewers can verify intent without reading every line. ## Quick Start Rewrite my PR description using the cognitive-doc-design structure with a quick path, details table, and reviewer checklist.

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 answer or decision first, then add context. Use progressive disclosure by starting with the happy path, chunk related information into small sections, and prefer tables, checklists, and examples over long prose.

How to structure a PR description for faster code review?▼

State what to review 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 outcome 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 template for that doc type. The cognitive patterns still apply, but the structure should follow existing project conventions.

How do I check if my PR is too large for reviewers?▼

Run 'gh pr view <PR_NUMBER> --json additions,deletions,changedFiles' to inspect the changed-line count. Large diffs increase cognitive load, so consider splitting the work into chained PRs with clear review order.