Cursor rule

1---
2description: "Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs/ directory."
3alwaysApply: false
4---
5 
6# Write Document (BMAD)
7 
8Create high-signal technical documentation that serves as an expert collaborator for both humans and AI. This skill enforces the BMAD principles to prevent context rot and ensure architectural durability.
9 
10**Distinct from `edit-document`:** Use this skill to create a document that does not yet exist. Use `edit-document` when a document already exists and needs restructuring, clarity, or prose improvements.
11 
12> **HARD GATE** — Every document must have a clear "Reason for Existence." If a document doesn't provide actionable leverage for a caller or test, do not create it.
13 
14## The BMAD Principles
15 
16| Principle | Execution |
17| :--- | :--- |
18| **B**old | Make strong assertions. Define clear boundaries and "Never" rules. No "it might" or "usually." |
19| **M**inimal | High-density, low-filler. **Circuit Breaker**: If the file exceeds 300 lines or the session exceeds 20 turns, you MUST run `terse-mode` and compact state before saving. |
20| **A**ctionable | Link every doc to a verifiable outcome. **Architectural Docs**: Verify via Gherkin features (`specs/verifications/features/`) or grep-based structure checks (`grep -c "pattern" file`) that prove the design's *constraints* are present. |
21| **D**urable | Design for the long-term. **Scalability**: Use "Nested Indexing"—root files link to module-level `GEMINI.md` indexes; do not list individual sub-files in the root. |
22 
23## Process
24 
25### 1. Identify the Artifact Type & Scope
26 
27Choose the correct BMAD-BigPowers artifact:
28- **Decision Record (ADR)**: For "Why" decisions (saved to `specs/adr/`).
29- **Context Map**: For system-wide architectural mapping (`specs/tech-architecture/tech-stack.md`).
30- **Technical Guide**: For "How-to" with verification (saved to `<module>/REFERENCE.md`).
31- **Behavioral Feature**: Gherkin-style compliance specs (saved to `specs/verifications/features/`).
32- **Project README**: Project-facing documentation (saved to `README.md` at project root).
33 
34**Cross-Cutting Concerns**: If a doc affects multiple modules, place the authoritative source in the lowest common ancestor directory and use "Delegates" (one-line pointers) in sub-directories to maintain the Single Source of Truth without violating the Stepdown Rule.
35 
36### 2. Draft with Semantic Velocity
37 
38> **STREAM CONTINUITY** — When writing file content, output in continuous chunks of ~200 lines. Do not pause. Continue immediately until complete. If you need time, emit a placeholder comment rather than going silent.
39 
40Write the document focusing on "Expert Collaboration":
41- **Instructions over Descriptions**: Tell the reader (human or AI) exactly how to interact with the system.
42- **Provenance Links**: Link to ADRs, Issues, or Commits to preserve intent.
43- **The Stepdown Rule**: Information should descend exactly one level of abstraction. If a root doc needs to explain a leaf-level detail, it must point to a sub-index first.
44 
45### Quick README (Project READMEs only)
46 
471. Ask: "Project name? One-sentence description?"
482. Generate `README.md` at project root using the template in [REFERENCE.md](REFERENCE.md) — no TOC, no second interview round.
493. Fill gaps from `CLAUDE.md` / `AGENTS.md` commands if available (prefer `AGENTS.md`); use `TODO` markers otherwise.
504. Output and suggest `edit-document` for polish.
51 
52→ verify: `test -f README.md && [ "$(grep -c '^## ' README.md)" -ge 7 ]`
53 
54### 3. Apply the 94% Quality Gate
55 
56Before finalizing, audit the document against these red flags:
57- [ ] **Filler Language**: Are there pleasantries or "I hope this helps"? (Delete them).
58- [ ] **Ambiguity**: Are there "usually," "often," or "it depends" without specific conditions?
59- [ ] **Dead Ends**: Does the document end without a "Next Step" or "Verification" command?
60- [ ] **Shallow Content**: Does it restate the code without explaining the *intent* or *contracts*?
61 
62### 4. Sync and Organize
63 
64- **Big Powers Hierarchy**: Place the document in the correct tier (Global -> Project -> Sub-directory). Project READMEs are an exception — they go to project root (`README.md`), not `specs/`.
65- **Nested Indexing**: If adding a module-level doc, ensure the module's `GEMINI.md` is updated. If the module's index is new, add it to the root `GEMINI.md`.
66- **Sync**: Run `scripts/sync-skills.sh` if the document is a `SKILL.md` or affects generated artifacts.
67 
68## Rules
69 
70- **Minimalism is a requirement**: If a document can be a 5-line table, do not make it a 5-line essay.
71- **Verifiable outcomes**: Every technical document must include at least one `verify:` command. For architecture, this can be a `grep` or `run_shell_command` that validates the existence of required files or patterns.
72- **No speculative docs**: Do not write documentation for features that do not exist yet unless explicitly doing `elaborate-spec`.
73 
74 
75Suggest next skill: `audit-code` or `sync-skills.sh`.
76 
77---
78 
79# Project README Template
80 
81Combined from dbader/readme-template and jehna/readme-best-practices. No TOC.
82 
83## Navigation
84 
85| Lines | Section |
86|-------|---------|
87| 1 | Title |
88| 5–40 | Navigation |
89| 41–42 | Sections |
90| 43–54 | 1. Title + Badges |
91| 55–60 | 2. Tagline |
92| 61–64 | 3. Description |
93| 65–67 | 4. Prerequisites |
94| 68–75 | Prerequisites |
95| 76–78 | 5. Installation |
96| 79–89 | Installation |
97| 90–92 | 6. Usage |
98| 93–102 | Usage |
99| 103–105 | 7. Features |
100| 106–113 | Features |
101| 114–116 | 8. Configuration |
102| 117–125 | Configuration |
103| 126–128 | 9. Development Setup |
104| 129–139 | Development |
105| 140–142 | 10. Running Tests |
106| 143–152 | Tests |
107| 153–155 | 11. Contributing |
108| 156–164 | Contributing |
109| 165–167 | 12. Changelog |
110| 168–172 | Changelog |
111| 173–175 | 13. Links |
112| 176–181 | Links |
113| 182–184 | 14. License |
114| 185–191 | License |
115| 192–194 | 15. Credits (optional) |
116| 195–199 | Credits |
117| 200–202 | Verify |
118 
119## Sections
120 
121### 1. Title + Badges
122 
123```markdown
124# Project Name
125 
126![License](https://img.shields.io/badge/License-MIT-yellow.svg)
127![npm version](https://img.shields.io/npm/v/your-package.svg)
128 
129```
130 
131Fill badges from CLAUDE.md stack info if available. Default to license + version badges.
132 
133### 2. Tagline
134 
135```markdown
136> One-line description of what this project does and why it matters.
137```
138 
139### 3. Description
140 
1412-3 paragraphs: what problem it solves, who it's for, and what makes it different.
142 
143### 4. Prerequisites
144 
145```markdown
146## Prerequisites
147 
148- **Runtime**: Node.js v18+ (from CLAUDE.md)
149- **Package manager**: npm (or pnpm/yarn)
150```
151 
152Auto-fill from CLAUDE.md commands section when possible.
153 
154### 5. Installation
155 
156```markdown
157## Installation
158 
159```bash
160npm install -g your-package
161# or
162npx your-package
163```
164```
165 
166Prefer npx one-shot if applicable; list global install as alternative.
167 
168### 6. Usage
169 
170```markdown
171## Usage
172
173```bash
174your-command --help
175your-command do-something
176```
177```
178 
179Include the most common 1-2 commands. Link to full docs if they exist.
180 
181### 7. Features
182 
183```markdown
184## Features
185 
186- Feature 1: short description
187- Feature 2: short description
188```
189 
1903-6 bullet points of what the project does. Derived from the project's purpose.
191 
192### 8. Configuration
193 
194```markdown
195## Configuration
196 
197| Variable | Default | Description |
198|----------|---------|-------------|
199| `VAR_NAME` | `value` | What it controls |
200```
201 
202Use `TODO` markers if unknown.
203 
204### 9. Development Setup
205 
206```markdown
207## Development
208 
209```bash
210git clone <repo-url>
211cd project
212npm install
213```
214```
215 
216Auto-fill from CLAUDE.md `Run` and `Build` commands.
217 
218### 10. Running Tests
219 
220```markdown
221## Tests
222
223```bash
224npm test
225npm run lint
226```
227```
228 
229Auto-fill from CLAUDE.md `Test` and `Lint` commands.
230 
231### 11. Contributing
232 
233```markdown
234## Contributing
235
2361. Fork the repo.
2372. Create a feature branch (`git checkout -b feature/my-thing`).
2383. Commit changes (`git commit -am 'Add my thing'`).
2394. Push (`git push origin feature/my-thing`).
2405. Open a Pull Request.
241```
242 
243### 12. Changelog
244 
245```markdown
246## Changelog
247 
248See [CHANGELOG.md](../../CHANGELOG.md) or [Releases](https://github.com/user/repo/releases).
249```
250 
251### 13. Links
252 
253```markdown
254## Links
255 
256- Repository: https://github.com/user/repo
257- Issue tracker: https://github.com/user/repo/issues
258```
259 
260### 14. License
261 
262```markdown
263## License
264 
265MIT — see [LICENSE](../../LICENSE) for details.
266```
267 
268Detect from CLAUDE.md or project LICENSE file.
269 
270### 15. Credits (optional)
271 
272```markdown
273## Credits
274 
275Built with [bigpowers](https://www.npmjs.com/package/bigpowers).
276```
277 
278## Verify
279 
280After generation, run: `grep -c "^## " README.md` — expect ≥ 7 section headings.
281