Documentation First
Use this skill to turn ambiguous work into durable, executable context before implementation.
Workflow
- Identify whether the task is trivial. If it is trivial, do not create ceremony.
- Read
~/.codex/standards/agent-native-standard.mdwhen the work affects coordination, memory, delegation, tests, or delivery. - Read
~/.codex/standards/engineering-standard.mdwhen the work affects architecture, schemas, APIs, data, security, observability, or TypeScript/Effect boundaries. - Use the repository's existing doc convention. If none exists, create the smallest fitting artifact:
docs/adr/NNNN-kebab-title.mdfor architectural, stack, product, data, security, or operational decisions.docs/specs/YYYY-MM-DD-kebab-feature.mdfor feature or workflow specifications.- Tests, schemas, fixtures, OpenAPI, tool contracts, or evals when executable documentation is clearer than prose.
- Keep the artifact short enough to guide implementation, not replace it.
Required Content
Include only sections that change implementation quality:
- Goal and non-goals
- Domain vocabulary and invariants
- Contracts, schemas, tools, APIs, events, and permissions
- State, persistence, migrations, failure modes, observability, rollout, and recovery
- Acceptance criteria and validation plan
- Decision, alternatives, and consequences for ADRs
Rules
- Prefer machine-readable contracts over duplicated prose.
- Do not create parallel sources of truth.
- Do not document obvious code behavior.
- Use the document to brief subagents; it must stand without hidden conversation context.