documentation

Write and verify README, API, and ADR documentation against shipped code behavior.

4|Updated Jun 19, 2026
One-click install
npx skills add https://github.com/douglance/sdlc-plugin --skill documentation-douglance
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: documentation
Source: https://github.com/douglance/sdlc-plugin/tree/main/.rulesync/skills/documentation
Command: npx skills add https://github.com/douglance/sdlc-plugin --skill documentation-douglance

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Documentation often drifts out of sync with the code it describes, leaving engineers with stale commands, wrong signatures, and misleading examples. This Skill ensures documentation is written after behavior ships and verified against the actual source of truth. ## Core Features & Use Cases - Ship-time documentation: Write README, usage guides, and API/interface docs that match the real code, with signatures, parameters, return shapes, and errors pulled directly from the source. - Architecture Decision Records: Capture ADRs for decisions with lasting consequences, including context, rejected alternatives, and accepted trade-offs. - Verification against behavior: Run every documented command and check every example against shipped behavior before considering docs complete. - Use Case: After merging a new CLI feature, use this Skill to update the README with a working example, document the new flags exactly as implemented, and record an ADR explaining why the interface was designed that way. ## Quick Start Use the documentation skill to write a README and API reference for the feature that just shipped, verifying every command and example against the actual code.

Frequently Asked Questions about documentation

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

FAQPage Schema
How do I write documentation that matches the actual code?▼

Read the shipped change first, then pull signatures, parameters, and examples directly from the source code. Run every command you document so examples are verified against real behavior rather than written from memory.

When should I write an ADR for a code change?▼

Write an ADR when a decision has lasting consequences, such as interface designs or rejected alternatives. Record the context, the decision made, the alternatives rejected, and the trade-off accepted.

What is the difference between ship-time documentation and decision documentation?▼

Ship-time documentation is written after a change lands and describes how to use what shipped. Decision documentation captures choices as they happen during development; this Skill covers the former and defers the latter to the documentation-and-adrs skill.

Why does documentation become stale after releases?▼

Docs go stale when written from plans rather than shipped behavior, or when examples are never executed. Verifying every command and signature against the real code before publishing prevents this drift.

When should I not use this documentation skill?▼

Avoid it before behavior ships, since documenting planned interfaces produces guesses that age into inaccuracies. For capturing decisions during development rather than after release, use the documentation-and-adrs skill instead.