|
| 1 | +--- |
| 2 | +name: writer |
| 3 | +description: > |
| 4 | + Write, edit, and restructure user-facing and developer-facing documentation. |
| 5 | + Use when asked to create/update docs such as `README.md`, `docs/**`, and |
| 6 | + other Markdown documentation; |
| 7 | + when drafting tutorials, guides, troubleshooting pages, or migration notes; and |
| 8 | + when improving inline API documentation (KDoc) and examples. |
| 9 | +--- |
| 10 | + |
| 11 | +# Write documentation (repo-specific) |
| 12 | + |
| 13 | +## Decide the target and audience |
| 14 | + |
| 15 | +- Identify the target reader: end user, contributor, maintainer, or tooling/automation. |
| 16 | +- Identify the task type: new doc, update, restructure, or documentation audit. |
| 17 | +- Identify the acceptance criteria: “what is correct when the reader is done?” |
| 18 | + |
| 19 | +## Choose where the content should live |
| 20 | + |
| 21 | +- Prefer updating an existing doc over creating a new one. |
| 22 | +- Place content in the most discoverable location: |
| 23 | + - `README.md`: project entry point and “what is this?”. |
| 24 | + - `docs/`: longer-form docs (follow existing conventions in that tree). |
| 25 | + - Source KDoc: API usage, examples, and semantics that belong with the code. |
| 26 | + |
| 27 | +## Follow local documentation conventions |
| 28 | + |
| 29 | +- Follow `.agents/documentation-guidelines.md` and `.agents/documentation-tasks.md`. |
| 30 | +- Use fenced code blocks for commands and examples; format file/dir names as code. |
| 31 | +- Avoid widows, runts, orphans, and rivers by reflowing paragraphs when needed. |
| 32 | + |
| 33 | +## Make docs actionable |
| 34 | + |
| 35 | +- Prefer steps the reader can execute (commands + expected outcome). |
| 36 | +- Prefer concrete examples over abstract descriptions. |
| 37 | +- Include prerequisites (versions, OS, environment) when they are easy to miss. |
| 38 | +- Use consistent terminology (match code identifiers and existing docs). |
| 39 | + |
| 40 | +## KDoc-specific guidance |
| 41 | + |
| 42 | +- For public/internal APIs, include at least one example snippet demonstrating common usage. |
| 43 | +- When converting from Javadoc/inline comments to KDoc: |
| 44 | + - Remove HTML like `<p>` and preserve meaning. |
| 45 | + - Prefer short paragraphs and blank lines over HTML formatting. |
| 46 | + |
| 47 | +## Validate changes |
| 48 | + |
| 49 | +- For code changes, follow `.agents/running-builds.md`. |
| 50 | +- For documentation-only changes in Kotlin/Java sources, prefer `./gradlew dokka`. |
| 51 | + |
0 commit comments