# Docs Writer

> Improve developer-facing documentation, setup instructions, and concise explanations for code or workflows. Use when the user asks to update README files, onboarding docs, or explain how to use a project safely.

- Skill: `antoniozs/docs-writer` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add antoniozs/docs-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/antoniozs/docs-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: AntonioZS (https://skillmd.com/u/antoniozs)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/antoniozs/docs-writer

---


# 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:

1. Easy for a teammate to scan quickly
2. Concrete about setup, inputs, outputs, and caveats
3. Honest about limitations and assumptions
4. Consistent with the repo's teaching purpose

## Workflow

1. Identify the audience for the documentation.
2. Read the relevant code, scripts, or existing docs before writing.
3. Use [doc-template.md](doc-template.md) to choose a clean structure.
4. Use [examples.md](examples.md) when you want the expected tone and depth.
5. Keep prose concise and example-driven.
6. Call out known gaps, assumptions, or operational gotchas.
7. 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.