documentation

Write and maintain READMEs, runbooks, API docs, and code comments describing existing code.

1|Updated Apr 24, 2026
One-click install
npx skills add https://github.com/kreek/consult --skill documentation-kreek
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: documentation
Source: https://github.com/kreek/consult/tree/main/plugin/skills/documentation
Command: npx skills add https://github.com/kreek/consult --skill documentation-kreek

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases accumulate stale, redundant, or misplaced documentation that misleads readers and drifts from the code it describes. This Skill enforces disciplined documentation practices so docs stay accurate, minimal, and located where their maintainers can catch drift. ## Core Features & Use Cases - Scoped doc authoring: Write READMEs, runbooks, tutorials, how-to guides, reference docs, module docs, and code comments only when requested, approved, or required by validation. - Source-of-truth discipline: Link to code, schemas, tests, CLI help, or OpenAPI specs instead of restating generated facts in prose. - Tripwire guardrails: Detect common documentation mistakes like unsolicited doc edits, bloated READMEs, and stale paragraphs, and route release notes to the appropriate skill. - Use Case: After shipping a new service, ask the agent to write a runbook covering alerts, rollback steps, and ownership, placed next to the service code where reviewers can keep it current. ## Quick Start Use the documentation skill to write a README for this module covering its purpose, install steps, minimal usage, and links onward.

Frequently Asked Questions about documentation

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

FAQPage Schema
How do I write a good README for a software project?▼

A README should cover purpose, install and run steps, minimal usage, and links onward to deeper docs. Keep it short and direct; longer READMEs are not more thorough, they just hide the essentials.

When should I add code comments versus improving the code itself?▼

Encode rules in names, types, schemas, or tests first. Add a comment only for the why that remains non-obvious after the code expresses everything it can.

Should documentation be updated during every code change?▼

No. Documentation is a separate work product, not an implementation reflex. Update docs only when requested, approved after a concrete gap is found, or required by a validator.

What types of documents does this skill not cover?▼

Forward-looking documents like design docs, ADRs, RFCs, tech specs, and PRDs are out of scope. CHANGELOGs, release notes, and migration notes route to the release skill, and API contract shape routes to the api skill.

How do I handle stale or outdated documentation?▼

Delete stale docs you cannot fix now, or mark them with a tracked rewrite owner. Orphaned prose is misinformation and worse than no documentation at all.