Menu
Distinguish README synopsis work from actual documentation updates. Use when README, docs, CLI help text, man pages, GNU info files, changelog prose, or project documentation are changed or reviewed.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when changing what a running devloop harness serves — pointing it at a different directory or worktree, or making the live harness serve newer or different code (a newer commit, another branch, or in-progress edits) without a wasteful restart.
Use when verifying that a UI change works end to end by driving the running app in a real browser — confirming a fix, reproducing a reported UI symptom, or proving a wizard/form/flow behaves — with Playwright against the exact code under review.
Enforce a Roborev plus Kata development workflow for code changes. Use when Codex is asked to implement, fix, refactor, or review work tracked by Kata and Roborev, especially when branch discipline, non-blocking review jobs, validation gates, SemVer, changelog checks, and final delivery reporting matter.
Use when working on GitHub pull requests that need PR-ready validation, review-thread replies, reviewer mentions, linked external references, or merge readiness checks.
Create or review a standalone repository that publishes a set of Codex or Claude skills with shared validation, linking, eval, and agent metadata conventions.
Prepare small, reviewable local commits with explicit rationale, SemVer impact, task hygiene, branch cleanup expectations, and clear commit commentary. Use when asked to commit work, prepare a PR-ready change, decide version impact, write commit messages, or clean up merged feature branches.
| name | documentation-boundary |
| description | Distinguish README synopsis work from actual documentation updates. Use when README, docs, CLI help text, man pages, GNU info files, changelog prose, or project documentation are changed or reviewed. |
README.md is a project synopsis, not the full documentation.
Use README.md to help a reader decide quickly:
Put documentation in:
docs/--help outputWhen editing README.md:
When changing behaviour or adding features, update the real documentation surface:
docs/--help outputDo not claim documentation is updated if only README.md changed.
Do not treat changelog prose, release notes, or commit summaries as the real documentation update for changed behaviour.
When CLI behaviour changes, update the user-facing CLI surface that explains that behaviour, such as --help, man pages, or info pages when present. Updating docs alone is not enough when the command itself exposes help for the changed behaviour.
If CLI help or man pages exist for changed CLI behaviour, do not close the task as fully documented until those surfaces are updated. Report that docs and changelog may already be changed, but CLI help and man or info pages still need updates.
For docs-only maintenance, such as README synopsis edits, link fixes, or prose cleanup, do not require feature documentation for unchanged behaviour. Still report which documentation surfaces changed.
Do not apply checklist items mechanically. Require CLI help, man pages, info pages, changelog prose, or docs updates only when the changed behaviour or changed documentation surface makes them relevant.
Before finalising prose changes, load and apply $oiticica-style.
Apply it to:
Before completion, report which surfaces changed by filling this checklist:
Documentation surfaces:
If user-facing behaviour changed and docs, CLI help, man pages, and info pages are all unchanged, say whether that is acceptable and why.