Documentation
Turn rough code or ops knowledge into READMEs, API references, runbooks, architecture notes, or onboarding guides your future self and users can follow.
Overview
Documentation is an agent skill most often used in Build (also Operate, Ship) that writes and maintains READMEs, API docs, runbooks, architecture docs, and onboarding guides for technical audiences.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill documentationWhat is this skill?
- Five document types: README, API documentation, runbook, architecture doc, and onboarding guide
- README pattern with quick start under five minutes to first success
- Runbook structure with rollback steps and escalation path
- Five editorial principles including write for the reader and keep it current
- Trigger phrases: write docs for, document this, create a README, write a runbook, onboarding guide
- 5 document types defined (README, API, runbook, architecture, onboarding)
- 5 documentation principles numbered in the skill
Adoption & trust: 5k installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your product works in code but readers—users, collaborators, or future you—lack a clear, current path from setup to safe operations.
Who is it for?
Solo builders shipping APIs, CLIs, or SaaS who need consistent doc structure without hiring a technical writer.
Skip if: Pure marketing landing copy or SEO blog campaigns—use growth-oriented skills; this skill targets technical documentation patterns.
When should I use this skill?
Triggers include write docs for, document this, create a README, write a runbook, onboarding guide, or when the user needs API, architecture, or operational technical writing.
What do I get? / Deliverables
You get audience-appropriate doc drafts with the skill’s section templates and principles applied so docs stay scannable and maintainable.
- README or quick-start section
- API or runbook draft aligned to skill outlines
- Architecture or onboarding doc with linked references
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Most solo builders draft product-facing and repo docs while building; this is the default shelf even though the same patterns apply later for ops and launch. Docs subphase is the canonical home for technical writing artifacts tied to the codebase and APIs.
Where it fits
Draft a README with quick start and configuration after scaffolding a new API service.
Refresh API error codes and auth section in public docs to match the release branch.
Capture an architecture doc with trade-offs while scoping an MVP integration.
How it compares
Structured doc-type playbooks rather than one-off chat paragraphs that omit rollback, auth, or quick-start requirements.
Common Questions / FAQ
Who is documentation for?
Solo and indie builders who need READMEs, API references, runbooks, or onboarding material without starting from a blank page.
When should I use documentation?
During Build for README and API docs; during Operate for runbooks; during Ship or Launch when release notes and operator docs must match what shipped; whenever you say write docs for, document this, or create a README.
Is documentation safe to install?
It is prose-generation guidance with no built-in secret exfiltration; review the Security Audits panel on this Prism page before enabling broad repo access in your agent.
SKILL.md
READMESKILL.md - Documentation
# Technical Documentation Write clear, maintainable technical documentation for different audiences and purposes. ## Document Types ### README - What this is and why it exists - Quick start (< 5 minutes to first success) - Configuration and usage - Contributing guide ### API Documentation - Endpoint reference with request/response examples - Authentication and error codes - Rate limits and pagination - SDK examples ### Runbook - When to use this runbook - Prerequisites and access needed - Step-by-step procedure - Rollback steps - Escalation path ### Architecture Doc - Context and goals - High-level design with diagrams - Key decisions and trade-offs - Data flow and integration points ### Onboarding Guide - Environment setup - Key systems and how they connect - Common tasks with walkthroughs - Who to ask for what ## Principles 1. **Write for the reader** — Who is reading this and what do they need? 2. **Start with the most useful information** — Don't bury the lede 3. **Show, don't tell** — Code examples, commands, screenshots 4. **Keep it current** — Outdated docs are worse than no docs 5. **Link, don't duplicate** — Reference other docs instead of copying