Menu
Address // REVIEW annotations left in source files. Use when the user says 'fix review comments', 'address review comments', or when a file contains // REVIEW markers.
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
Audit a blueprint (or other plan/design/spec/diff) against the repository's Accepted ADRs to find where it VIOLATES or CONTRADICTS a binding decision — using parallel sub-agents that each own a slice of the ADR corpus, then a synthesized verdict. This is a companion to blueprint-review, meant to run during blueprint work once the design is drafted and before the build starts. Use when the user says "check the blueprint against our ADRs", "does this violate any ADRs", "audit the plan for ADR compliance", "make sure the blueprint doesn't contradict an ADR", or "/blueprint-adr-audit". It is READ-ONLY: it reports findings and does not edit the plan, the ADRs, or any code. Do NOT use it to WRITE a new ADR (that is adr-write), to REVIEW the blueprint for gaps/correctness (that is blueprint-review), to review code for bugs (/code-review), or to check a spec's documentation quality (review-openapi).
Review an existing Blueprint (the single product + technical design document) for gaps, inconsistencies, unresolved questions, correctness holes, and ambiguities that would force decisions during the build, then produce an updated version. Use when the user asks to "review the blueprint", "check the blueprint", or "update the blueprint". Reviews both halves and the user-stories section in one pass. Do NOT use to start a new Blueprint from scratch (use blueprint-create) or to make minor wording edits that don't need a structured review.
Finish a Linear ticket from inside its worktree and hand it back to the captain: verify the PR merged, set the ticket to Done, and post a `## Ticket Done` entry to the ticket's PROJECT status-update timeline (never a ticket comment) so the orchestrating /captain picks it up on its next re-hydrate. Use when a ticket's PR is merged and you're closing it out — 'captain done', '/captain-done', 'finish this ticket and tell the captain', 'mark this done for the captain', 'hand this back to the captain'. This is the worker-side finishing counterpart to /captain (the orchestrator) and a specialization of /linear-handoff for the merged-and-closed moment. Do NOT use to pause mid-ticket (use /linear-handoff), to hand off one long-running ticket's own progress as a ticket comment (that's /linear-handoff issue mode), or when the work isn't part of a captain-managed project.
Manage a Linear project across sessions as an orchestrator: each invocation it re-hydrates project state from Linear (the source of truth) plus its own last project status update (its memory), tells you what changed and what's ready next, and on your go launches the next ticket as a herdr worktree + Claude session via the captain-next wrapper. It sequences work (what's next, what's parallel-safe), keeps Linear current by writing the next project status update, and reconciles finished worktrees. Use when the user says 'run the captain for <project>', '/captain', 'what's next on <project>', 'manage the git-server build', 'start the next ticket', or 'I finished <ticket>, what now'. It is the ongoing, managing counterpart to /linear-resume (a one-shot read) and it drives /linear-start via the launcher. You can also ask it to help plan the project or create tickets WITHIN that already-managed project — the loop below is its default job, not its limit. Do NOT use captain to create or capture a standalone ticket, sp
Pick up a Linear ticket and start working it. Fetch the ticket, verify the current branch matches Linear's own git branch name (the worktree is created before the session, e.g. by a claude-branch-style wrapper), then classify the ticket (bug / improvement / feature) from its Linear labels — falling back to its content when unlabeled. Bugs and trivial improvements start immediately; features with enough detail hand off to /blueprint-create. Use when the user says 'pick up <TEAM>-<NUM>', 'work this ticket', 'start <ticket>', 'start working ENG-42', '/linear-start', or gives a Linear id/URL and asks to begin. This is greenfield only — to *resume* an in-flight build or long-running ticket from its latest handoff, use /linear-resume first. Do NOT use to merely create a ticket or to open a PR — those belong to the ticket-creation and PR skills.
Write or edit writing in the user's practitioner blog voice — experience-backed, conversational, story-driven, opinionated but humble. Use for blog posts, tech specs, engineering communications, and any long-form writing the user asks for. Activated when the user asks to "write a post", "draft a blog", "write up X", "edit this for style", "review this for my style", or invokes /writing-style directly.
| name | review-comments |
| description | Address // REVIEW annotations left in source files. Use when the user says 'fix review comments', 'address review comments', or when a file contains // REVIEW markers. |
You are tasked with reading a file provided and addressing any // REVIEW comments in the file
When this command is invoked:
Check if parameters were provided:
If no parameters provided, respond with:
I'll help you review a file, please provide the name of the file which
contains `// REVIEW` comments and I'll read the file and begin implementation
Tip: You can also invoke this command with a ticket file directly: `/review-comments code.go`