Help us improve
Share bugs, ideas, or general feedback.
From skills
Writes technical documentation: READMEs, API docs, architecture docs, how-to guides, RFCs, design docs, and ADRs. Applies type-specific rules for each format.
npx claudepluginhub kriscard/skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/skills:docsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Different documentation types serve different purposes. The format rules exist because readers come to each type with a specific goal — give them what they came for immediately.
Generates or updates documentation for code, APIs, or systems including READMEs, API references, inline comments, technical guides, and ADRs.
Guides collaborative creation of documentation including READMEs, API docs with OpenAPI specs, architecture docs, proposals, technical specs, and decision records via structured stages.
Guides creation of README files, API docs, user guides, developer guides, and troubleshooting docs with structured process, templates, and best practices.
Share bugs, ideas, or general feedback.
Different documentation types serve different purposes. The format rules exist because readers come to each type with a specific goal — give them what they came for immediately.
The README answers: "what is this and can I use it in 2 minutes?"
Rules:
Structure:
# Project Name
One sentence description.
## Install
[<5 commands]
## Quick Start
[One working example]
## [Links to deeper docs if needed]
Rules:
Parameter format:
name (string, required) — The user's display name. Max 50 characters.
limit (number, optional, default: 20) — Results per page. Max 100.
Rules:
Structure:
## Context
[What problem this system solves, who uses it]
## Key Decisions
[Decision record format: what, why, alternatives considered, tradeoffs]
## System Diagram
[C4 context or container diagram]
## Data Flow
[How data moves through the system for the main use cases]
Rules:
For team-facing proposals and records. Ask which type before starting — each has a different section convention.
| Type | Use When |
|---|---|
| RFC | Change isn't decided yet — soliciting feedback before committing |
| Product design doc | Scoping new work — goals, non-goals, user stories, success metrics |
| Architecture proposal | System design or pattern change — current state, proposed design, trade-offs, migration |
| ADR | Decision already made — capture context, decision, consequences |
Workflow for proposals/records:
RFC/design doc structure:
## TL;DR
[Summary — write last]
## Problem
[What's painful, with real data]
## Proposed Solution
[Scoped, not "change everything"]
## Why Now?
[What triggered this]
## Trade-offs
[Pros AND cons — naming downsides builds trust]
## Alternatives Considered
[What you rejected and why]
## Rollback Plan
[Makes skeptics comfortable]
## Open Questions
[Decision points for the reader — silence in team chat means readers didn't know what to react to]
For docs going into team chat: include a TL;DR at the top suitable for pasting into Slack.
Before delivering any docs, verify:
Load the template that matches the doc type — all are equal priority, triggered by type alone.
| Doc Type | Load when | Reference |
|---|---|---|
| ADR | Decision already made — need to capture context and consequences | references/adr-template.md |
| RFC | Change not decided — soliciting team feedback before committing | references/rfc-template.md |
| Architecture Proposal | System design or pattern change with trade-off analysis | references/architecture-proposal-template.md |
| Design Doc | Scoping new work — goals, non-goals, user stories, success metrics | references/design-doc-template.md |