$npx -y skills add girijashankarj/cursor-handbook --skill architecture-docsWorkflow for creating and maintaining architecture documentation. Use when the user needs to document system architecture or make ADRs.
| 1 | # Skill: Create Architecture Documentation |
| 2 | |
| 3 | ## Trigger |
| 4 | When the user needs to document system architecture or make Architecture Decision Records (ADRs). |
| 5 | |
| 6 | ## Prerequisites |
| 7 | - [ ] Codebase or design available to analyze |
| 8 | - [ ] docs/ or docs/architecture/ directory exists (or create it) |
| 9 | - [ ] Mermaid support in docs (GitHub, MkDocs, etc.) |
| 10 | |
| 11 | ## Steps |
| 12 | |
| 13 | ### Step 1: System Overview |
| 14 | - [ ] High-level architecture diagram (Mermaid) |
| 15 | - [ ] List all services/components |
| 16 | - [ ] Document communication patterns |
| 17 | - [ ] Document data flow |
| 18 | |
| 19 | ### Step 2: Component Documentation |
| 20 | For each service/component: |
| 21 | - [ ] Purpose and responsibilities |
| 22 | - [ ] Technology stack |
| 23 | - [ ] API contracts (if applicable) |
| 24 | - [ ] Data stores |
| 25 | - [ ] Dependencies |
| 26 | - [ ] Scaling characteristics |
| 27 | |
| 28 | ### Step 3: Architecture Decision Records (ADRs) |
| 29 | For significant decisions: |
| 30 | - [ ] Title: Short descriptive title |
| 31 | - [ ] Status: Proposed / Accepted / Deprecated / Superseded |
| 32 | - [ ] Context: Why this decision is needed |
| 33 | - [ ] Decision: What was decided |
| 34 | - [ ] Consequences: Trade-offs and implications |
| 35 | |
| 36 | ADR template: |
| 37 | ```markdown |
| 38 | # ADR-{number}: {title} |
| 39 | |
| 40 | ## Status |
| 41 | {Proposed | Accepted | Deprecated | Superseded by ADR-{n}} |
| 42 | |
| 43 | ## Context |
| 44 | {What is the issue that we're seeing that is motivating this decision?} |
| 45 | |
| 46 | ## Decision |
| 47 | {What is the change that we're proposing and/or doing?} |
| 48 | |
| 49 | ## Consequences |
| 50 | {What becomes easier or harder because of this change?} |
| 51 | ``` |
| 52 | |
| 53 | ### Step 4: Data Flow Diagrams |
| 54 | - [ ] Request flow through the system |
| 55 | - [ ] Event/message flow |
| 56 | - [ ] Data pipeline flow |
| 57 | - [ ] Authentication flow |
| 58 | |
| 59 | ### Step 5: Operational Documentation |
| 60 | - [ ] Deployment architecture |
| 61 | - [ ] Monitoring and alerting overview |
| 62 | - [ ] Disaster recovery plan |
| 63 | - [ ] Scaling procedures |
| 64 | |
| 65 | ## Completion Checklist |
| 66 | - [ ] At least one diagram (Mermaid) for system or data flow |
| 67 | - [ ] ADRs for significant decisions (format, status, context, decision, consequences) |
| 68 | - [ ] Component list with purpose and tech stack |
| 69 | - [ ] Operational section (deploy, monitor, scale) |
| 70 | |
| 71 | ## If Step Fails |
| 72 | - **Step 1 (overview)**: Start with 3–5 boxes; add detail later. Use `flowchart LR` or `flowchart TB` for simple flows |
| 73 | - **Step 3 (ADRs)**: Number format `ADR-001`; keep each ADR to one decision |
| 74 | - **Step 4 (diagrams)**: Mermaid syntax: no spaces in node IDs; use `A[Label]` not `A[Label with spaces]` |
| 75 | |
| 76 | ## Example |
| 77 | Step 1: `flowchart LR` with Client -> API -> DB, API -> Cache. Step 3: ADR-001 Use PostgreSQL — Status Accepted, Context: need relational, Decision: PostgreSQL, Consequences: SQL expertise required. |