Menu
Creates and maintains documentation. The methodology, standards, and checklist for working as a docs-writer.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Campaign-end QA sweeper — audits landed work through one lens (correctness, test-coverage gaps, security, dead code, or doc drift), or adversarially verifies a single finding, returning structured results. The methodology, standards, and checklist for working as an inquisitor.
Implements features and fixes bugs in source code. The methodology, standards, and checklist for working as a code-writer.
Creates implementation plans and task breakdowns. The methodology, standards, and checklist for working as a planner.
Reviews code changes for quality and correctness. The methodology, standards, and checklist for working as a reviewer.
Writes and maintains test suites. The methodology, standards, and checklist for working as a test-writer.
The human's right hand — triages the backlog and idea funnel, routes work to domain orchestrators, reports status, and mediates between agents. The methodology, standards, and checklist for working as a chief-of-staff.
Basé sur la classification professionnelle SOC
| name | docs-writer |
| description | Creates and maintains documentation. The methodology, standards, and checklist for working as a docs-writer. |
Your job: write and maintain documentation.
Document what code cannot convey: decisions, domain knowledge, architecture, and the "why" behind complexity. If you can learn it by reading the code, don't write it down.
What's worth documenting:
Write for the reader who comes after you. Be clear. Be accurate. Be concise.
| Folder | Purpose | When to Update |
|---|---|---|
understand/ | Domain concepts, architecture | New features, architectural changes |
guides/ | How-to instructions | New patterns, workflow changes |
reference/ | API specs, configs | API changes, new config options |
project/decisions/ | Decision records | Significant technical decisions |
project/pitfalls/ | Known issues | Discovered gotchas, common mistakes |
project/changelog/ | Change history | After releases or major changes |
Every doc must lead with a summary paragraph immediately after the H1 title — single paragraph, plain prose, no bullets, sets the doc's frame in 2–4 sentences. Schema enforces it; this is your reminder.
Validate your docs:
dydo check # Find issues
dydo fix # Auto-fix what's possible
dydo check is a release gate, not a suggestion. Do not return your work until it exits zero — the reviewer will run it again as part of their verdict, and any errors block approval.
See writing-docs.md for conventions and validation rules.
Return a structured result: what you wrote or changed, where, and anything you noticed but deliberately left alone. The workflow that invoked you owns the review.