docs
Docs
Keep the repo legible to humans and agents.
Principles
- Docs rot silently — every code change is a possible doc change
- Documentation is part of the interface; optimize for scanability, rhythm, and visual clarity, not just correctness
- Describe the current state, not the edit history; use before/after wording only when migration context helps the reader
- Routing docs stay short; depth lives in
docs/ - No duplication when a pointer will do
- Use repo-relative links for in-repo docs; external links are fine in sources and references
- Doc drift is a real failure, not polish debt
Handoffs
- Missing boot, smoke, e2e, logs, or agent-readiness infrastructure → use
agent-readiness - Need to judge existing code, a diff, branch, or PR with evidence → use
review - Need to validate your own completed change on the real surface → use
verify
Workflow
1. Audit the doc surface
Check the files humans and agents actually rely on:
AGENTS.mdCLAUDE.mdREADME.mdCONTRIBUTING.mdSECURITY.mddocs/- plans, specs, runbooks, decision docs
Flag stale commands, dead paths, duplicated guidance, routing failures, and places where filenames or implementation order are leaking into the visible docs surface.
2. Update routing docs
Keep top-level docs terse and navigational.
AGENTS.mdshould be a table of contents, not a wiki- If the repo uses
AGENTS.md, keepCLAUDE.mdat the same level as a symlink toAGENTS.mdinstead of maintaining a second authored file README.mdshould lead with value and the fastest path to use the projectCONTRIBUTING.mdshould hold contributor setup, validation, and workflowSECURITY.mdshould hold private-first vulnerability reporting guidance- Push detail downward instead of bloating top-level files
- For coordination or workspace repos, keep one canonical setup doc and let
README.mdpoint to it instead of repeating the full bootstrap flow inline - Use the concrete top-level split and section order in references/documentation.md instead of inventing a new shape every time
- Keep visible docs copy human-facing and task-ordered; let the reference file own the detailed labeling and scannability rules
- Prefer terse routing over narrative sprawl, for example
README.mdshould link to deeper docs instead of re-explaining them inline
3. Update deep docs and specs
Refresh the detailed documents that actually carry the knowledge.
- architecture and API docs
- task guides and runbooks
- feature specs, plans, and decision records
- readiness infrastructure docs after agent-readiness changes
Write each updated section as the reader's current source of truth. Avoid "previously/now" or "before/after" framing unless the doc is a migration note, changelog, or decision record.
For new features, use the directory layout and templates in references/structuring.md — specs, plans, and decisions each have their own shape.
4. Clean up drift
- deduplicate repeated facts
- delete or archive stale docs
- fix cross-links and moved paths
- keep naming and commands consistent across files
- keep one canonical home for setup or install commands in workspace-style repos, and replace copied command blocks elsewhere with short pointers
- normalize visible labels, casing, and section order when the docs read like a file tree instead of a user guide
Example — fixing a stale path after a rename:
# AGENTS.md
-- Run `scripts/bootstrap.sh` to set up the dev environment.
+- Run `scripts/setup.sh` to set up the dev environment.
5. Validate reality
Do not trust prose. Check that commands, file paths, and entry points still match the repo.
Concrete checks:
rg -n "old/path|stale-command" AGENTS.md CLAUDE.md README.md docs/when paths or commands movedtest -e <path-from-docs>before keeping a file referencetest ! -e AGENTS.md || { test -L CLAUDE.md && test "$(readlink CLAUDE.md)" = "AGENTS.md"; }when normalizing agent entrypoints
Output
After docs work, report a compact docs footer:
- files updated
- verified: command names or path checks, not output logs
- removed or rewritten: only if stale or duplicated docs changed
- gaps: remaining doc gaps, or
none - next:
agent-readiness,review,verify, ornone
Keep the footer to 5 labeled lines or fewer. Do not repeat the same file list in prose after listing changed files.
References
- references/documentation.md — AGENTS.md shape, scoped rules, README patterns, doc hygiene
- references/specifications.md — feature specs, conformance tests, spec drift, SDD trade-offs
- references/structuring.md — directory layout, templates, and naming for specs, plans, and decisions
More from uinaf/agents
docs-keeper
Maintain project documentation with clear human/agent separation. Use when setting up a new project, auditing docs, creating plans, or managing agent working memory. Triggers include "set up docs", "create a plan", "audit documentation", "init project structure", or any task involving project documentation conventions.
10verify
Self-check your own completed change before handing off to `review` — the pre-review sanity pass. Use when you want to check your work, run checks, validate changes, make sure a change is ready, test it end-to-end, run repo guardrails (lint, typecheck, tests, build), exercise the real surface with evidence, and catch obvious self-correctable issues. Produces a `ready for review` / `needs more work` / `blocked` verdict — never a ship decision. If the repo cannot be booted or exercised reliably, hand off to `agent-readiness`. If auditing someone else's diff, branch, or PR, use `review` instead.
8viteplus
Migrate or align frontend repositories to the stock VitePlus workflow. Use when standardizing package or monorepo repos around `vp`, `voidzero-dev/setup-vp`, `vite-plus/test`, and VitePlus-native CI, test, packaging, and hook flows. Default to replacing direct package-manager and Vitest wiring with the VitePlus equivalents unless the repo has a proven exception.
8review
Independently audit existing code, diffs, branches, or pull requests using concern-specific reviewer personas and evidence. Use when triaging risk in a PR, deciding whether a change is safe to ship, or following up on a `verify` pass to make the call the builder cannot make on their own work. Produces a `ship it` / `needs review` / `blocked` verdict. Do not use to self-check a change you just authored; use `verify` for that.
8agent-readiness
Audit and build the infrastructure a repo needs so agents can work autonomously — boot scripts, smoke tests, CI/CD gates, dev environment setup, observability, and isolation. Use when a repo can't boot, tests are broken or missing, there's no dev environment, agents can't verify their work, or agents need human help to get anything done. Do not use for reviewing an existing diff or for documentation-only cleanup.
8gh-deploy-pipeline
Set up or align a GitHub Actions deploy pipeline for an app or service. Use when standardizing repos around the verify-then-deploy shape: push to main → detect affected lanes → verify and build artifacts → e2e → deploy each lane to its host (Cloudflare Pages, AWS Amplify, GHCR + VPS, etc.) with a non-cancellable per-lane concurrency group. Pairs with `gh-release-pipeline` for versioned packages; use for deploying running apps, not publishing artifacts to a registry.
8