Menu
Signals that this message was dictated by voice, so technical terms may be mis-transcribed. Use when the user prefixes a dictated message with /v.
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
Run /code-review, /simplify, /brooks-review, /review, and /exemplar-review on a change via parallel subagents, address the meaningful findings, fold the fixes into clean commits, and force-push with lease. Use when the user wants to review-and-fix a change before merge — on uncommitted work, the current feature branch, or a GitHub PR / GitLab MR. Triggers include "review-fix", "review and fix this PR/MR", "polish this branch", or "run the reviews, address the suggestions, then force-push".
Run one PR-processing tick on the current repo's open pull requests, then stop. Finalize your own / agent-authored PRs (rebase-if-needed, /code-review then /review-fix if needed, /recommit, green CI), review community and bot PRs, and emit exactly one canonical recommend-* verdict label per PR. File follow-up and idea issues without blocking any merge. Does one tick then stops, so it composes with /loop for a recurring PR loop (e.g. `/loop /process-prs`, `/loop 1h /process-prs`). Never merges, never closes; the verdict is a recommendation, not an action. GitHub-only (uses `gh`). Use when the user wants to process, finalize, triage, or review open pull requests, set up a recurring PR-handling agent, or run one PR-processing pass.
Run one implementation tick on the current repo's ready-for-agent issues, then stop. Pick the oldest unassigned ready-for-agent issue, implement its agent brief in an isolated worktree, get tests and lint green, run /review-fix, and open a non-draft PR with "Closes #N", then stop. If the brief proves underspecified or the work can't go green, abort and demote the issue instead of shipping a guess. Never merges. Does one issue end-to-end per tick, so it composes with /loop for a recurring implementation loop (e.g. `/loop /implement-issues`, `/loop 1h /implement-issues`). GitHub-only (uses `gh`). The middle leg of the pipeline: process-issues -> implement-issues -> process-prs. Use when the user wants to implement ready-for-agent issues, turn triaged issues into pull requests, or set up a recurring AFK implementation agent.
Run one autonomous codebase-improvement pass on the current repo. Self-discover the single highest-leverage, low-risk improvement (architecture, tech debt, dead code, test gaps, simplification) and either ship it end-to-end as a non-draft PR for /process-prs to review and verdict, or, when it needs human judgment, file one needs-triage issue. Does exactly one thing then stops, so it composes with /loop for recurring improvement (e.g. `/loop /kaizen-codebase` or `/loop 1d /kaizen-codebase`). The self-directed sibling of /implement-issues: same shipping discipline, but it finds its own work instead of grabbing a ready-for-agent issue. Use when the user wants to continuously or periodically improve a repository, asks to "improve the codebase", set up a recurring code-quality agent, or run one improvement iteration.
Run one issue-triage tick on the current repo's open issues, then stop. Scan untriaged issues, classify them (type: bug/feature/task), reproduce bugs, and route each through the canonical triage state machine: needs-info / ready-for-agent (with an agent brief) / ready-for-human, or park a wontfix/duplicate/out-of-scope belief in needs-triage for the maintainer. Does one tick then stops, so it composes with /loop for a recurring issue loop (e.g. `/loop /process-issues`, `/loop 1h /process-issues`). Never closes an issue, never applies wontfix; those stay the maintainer's call. GitHub-only (uses `gh`). The autonomous sibling of the interactive /triage skill. Use when the user wants to triage, classify, or process open issues, prepare issues for AFK agents, or set up a recurring issue-triage agent.
Render the open decision points of a task as an ASCII tree so the user can see where they are and what to answer next. Use when a task has branched into several pending choices, when the user asks "where am I?" / "what do I need to decide?" / "what's left to decide", or invokes /where-am-i. About task decisions, not git branch or working directory. Pure presentation; reads state from the conversation, persists nothing.
| name | v |
| description | Signals that this message was dictated by voice, so technical terms may be mis-transcribed. Use when the user prefixes a dictated message with /v. |
| disable-model-invocation | true |
| argument-hint | <your dictated message> |
The text in $ARGUMENTS came from voice dictation, for this turn only. Speech-to-text
garbles terms that have no phonetic redundancy: repo and project names, CLI tool names,
command flags, file paths, identifiers, and acronyms. Ordinary prose is usually fine; the
precise, consequential nouns are where it breaks.
Apply this protocol to the dictated message, then carry out the request. Do not apply it to
later messages unless they also begin with /v.
Open your reply with a single one-line readback that paraphrases the request with the
technical terms resolved. Put terms you resolved or are assuming in code font so the user
can catch a wrong guess at a glance.
Heard: deploy the
widget-syncservice after runningterraform apply.
For each suspect term that is both likely mis-transcribed and consequential (getting it wrong sends you down the wrong path):
kubectl get pods and move on.Do not interrogate ordinary words. Only the high-cost-if-wrong terms warrant a question.
If the ambiguity blocks only part of the task, say what you can safely start and what you need from the user, rather than halting the whole thing on one trivial clarification.