Menu
Use when tracking work with Kata: creating task inventories, backlog lists, follow-up work, searching or creating issues, assigning active work, recording comments and relationships, closing verified work, or reporting Kata task hygiene.
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 | kata |
| description | Use when tracking work with Kata: creating task inventories, backlog lists, follow-up work, searching or creating issues, assigning active work, recording comments and relationships, closing verified work, or reporting Kata task hygiene. |
Use this skill for Kata lifecycle hygiene. Kata is the shared issue ledger; keep issue state true.
Task inventories belong in Kata, not repository commits. When an agent creates an inventory of tasks, first state that the inventory must not be committed to the repository unless the user explicitly asks for repository documentation.
kata agent-instructions when local Kata command guidance may have changed.kata search "<query>" --json.kata create "<title>" --body "<body>" --idempotency-key "<key>" --json.kata ready --json to find unblocked work unless the user provides an issue.kata assign <ref> <owner> --json.kata comment <ref> --body "<note>" --json
kata edit <ref> --blocks <other-ref> --json or kata edit <ref> --blocked-by <other-ref> --json.kata delete or kata purge unless the user explicitly asks for that exact destructive action and issue ref.When creating a task inventory, backlog list, follow-up list, TODO inventory, or remaining-work list, explicitly state that it must not be committed to the repository unless the user asks for repository documentation.
Record task inventories in Kata:
kata comment <ref> --body "<note>" --json.<ref> once the ref is known.kata close <ref> --done --message "<validation and delivery evidence>" --commit <sha>
kata edit <ref> --label needs-review --json
kata comment <ref> --body "<validation failure or blocker; next concrete action>" --json
For completed issue skills-abc after successful validation and commit, use this shape:
kata assign skills-abc dmvianna --json
kata comment skills-abc --body "Validation passed: <command>. Commit: <sha>." --json
kata close skills-abc --done --message "Validation passed: <command>. Delivered in commit <sha>." --commit <sha>
Then report: Kata issue skills-abc closed.
Reject Kata hygiene that creates or uses an issue but never assigns it, closes unvalidated work, or finishes a task while leaving its completed issue open.
When the issue ref is known, write the exact ref in the corrective commands. Never answer corrective commands with <ref> for a report that already names an issue.
For a completed validated issue left open, require this concrete shape with the real issue ref substituted:
kata assign <real-ref> <owner> --json
kata close <real-ref> --done --message "<validation and commit evidence>" --commit <sha>
For any other completed validated work left open, require:
kata assign <ref> <owner> --jsonkata close <ref> --done --message "<validation and delivery evidence>" --commit <sha>