From architecture-docs
Create and improve architecture documentation. Use this skill whenever the user needs ADRs, technical specs, RFCs, runbooks, or any architecture documentation -- even if they just say "document this decision," "write up the design," or "we need an RFC for this change."
How this skill is triggered — by the user, by Claude, or both
Slash command
/architecture-docs:documentationopusThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create effective documentation that captures decisions, designs, and operational knowledge. Good architecture docs answer "why" -- the code already shows "what."
Create effective documentation that captures decisions, designs, and operational knowledge. Good architecture docs answer "why" -- the code already shows "what."
| Need | Document Type | When to Use |
|---|---|---|
| Record a decision | ADR | A significant technical decision was made and the reasoning should be preserved |
| Design a feature | Tech Spec | A feature needs detailed design before implementation begins |
| Propose a major change | RFC | A change needs broader discussion and buy-in before committing |
| Explain the system | Architecture Doc | Someone needs to understand how the system works and why |
| Enable operations | Runbook | An on-call engineer needs to diagnose and resolve issues at 3 AM |
One ADR per decision. Use the template in templates/adr-template.md.
Create specs as directories with focused files -- each file is independently consumable by implementation agents:
docs/specs/[feature]/
├── README.md # Overview, goals, non-goals (entry point)
├── api.md # API contracts, endpoints, schemas
├── data-model.md # Database schema, entity relationships
├── implementation.md # Phases, tasks, migration strategy
├── operations.md # Monitoring, alerts, failure modes
└── decisions.md # Key decisions with ADR links
Use the template in templates/tech-spec-template.md.
Reference shared/output-conventions.md for file locations and naming.
RFCs are for proposals that need broader discussion before commitment. They differ from ADRs (which record decisions already made) and specs (which detail approved designs).
docs/rfcs/[number]-[title]/
├── README.md # Summary, motivation, status
├── design.md # Detailed technical proposal
├── migration.md # Rollout plan, backward compatibility
└── alternatives.md # Seriously considered alternatives with trade-offs
Write runbooks for the on-call engineer at 3 AM who has never seen this system before.
Structure each procedure as: symptom → diagnosis steps → resolution steps → escalation path.
related-diagrams and related-adrsnpx claudepluginhub crazymeal/claude-architect-marketplace --plugin architecture-docsAuthors technical documentation through a repeatable workflow: audience analysis, Diátaxis-mode selection, structure, draft, review, publish. Covers READMEs, ADRs, API docs, and runbooks.
Clear technical documentation, API docs, architecture decision records, and runbooks.