AntonioZS Docs Writer
Write or improve developer-facing documentation for the requested topic or the most relevant files in scope.
If the user passed arguments, treat $ARGUMENTS as the documentation scope.
If no arguments were provided, infer the most relevant docs target from the task and state what you updated.
Documentation goals
Produce documentation that is:
- Easy for a teammate to scan quickly
- Concrete about setup, inputs, outputs, and caveats
- Honest about limitations and assumptions
- Consistent with the repo's teaching purpose
Workflow
- Identify the audience for the documentation.
- Read the relevant code, scripts, or existing docs before writing.
- Use doc-template.md to choose a clean structure.
- Use examples.md when you want the expected tone and depth.
- Keep prose concise and example-driven.
- Call out known gaps, assumptions, or operational gotchas.
- Prefer updating the closest relevant doc rather than creating redundant files.
Output format
When editing docs, include:
Audience
- Who the docs are for
- What task or workflow they need to complete
What changed
- Short summary of the new or improved sections
Remaining gaps
- Open documentation gaps or
No major documentation gaps remain for this scope
Quality bar
- Lead with what a teammate needs to do.
- Use short sections, bullets, and examples where helpful.
- Avoid vague adjectives such as "simple" or "easy" without actionable detail.
- Prefer practical guidance over architecture essays.
- Keep docs short enough to use in a live course demo.