1.1 KiB
1.1 KiB
description, argument-hint
| description | argument-hint |
|---|---|
| Write or improve documentation (README, docstrings, JSDoc, godoc, ADRs) | [file path, symbol, or topic to document] |
Write documentation for: $@
Structure your answer as:
- Audience — who is reading this (new contributor, end user, API consumer, future self) and what they already know
- One-paragraph summary — what it is and when to use it
- Minimal example — the smallest runnable/usable snippet that demonstrates the primary path
- API or interface — for code: every public symbol with one line of purpose and a signature. For prose: headings and key terms.
- Gotchas — non-obvious behavior, common mistakes, sharp edges, things that look like bugs but aren't
- How to verify — for code docs, a command or test the reader can run; for prose, a cross-link to source
Match the existing style of the project's docs. Do not invent APIs, parameters, or behavior — if something is unclear from the code, say "behavior unclear, needs verification" rather than guessing. If the project has no docs yet, propose a minimal README structure and call it out so the user can approve before you scaffold.