菜单
Emit a /goal command pointed at a feature directory containing a blueprint.md (or the legacy prd.md + tech-spec.md). Use whenever the user wants to implement, build, ship, or run a feature whose design lives in a docs/features/<name>/ directory (or similar). Do NOT use for design discussions or one-shot edits.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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 | goal-from-spec |
| description | Emit a /goal command pointed at a feature directory containing a blueprint.md (or the legacy prd.md + tech-spec.md). Use whenever the user wants to implement, build, ship, or run a feature whose design lives in a docs/features/<name>/ directory (or similar). Do NOT use for design discussions or one-shot edits. |
Emit a /goal command pointed at a feature directory. The user pastes it to launch — Claude Code's slash commands are parsed from user input, not from model output.
blueprint.md — the current single-document design artifact (product what + technical how in one file). Use the Blueprint template.prd.md + tech-spec.md (+ optional user-stories.md) for older feature directories that predate the Blueprint. Use the Legacy template./goal Implement the feature specified in <feature-dir>/. Follow <feature-dir>/blueprint.md as the source of truth for both WHAT correct means and HOW to build it, matching the existing codebase's patterns, conventions, and terminology so the new code fits naturally rather than inventing divergent structure. The feature is complete only when every acceptance criterion in the Blueprint is satisfied AND demonstrably verified: all new and existing tests pass, the build is green, and lint is clean. Treat the Blueprint as the source of truth for correctness — if the implementation and the Blueprint disagree, the implementation is wrong. For each acceptance criterion, there must be a passing test that exercises it through the system's surface — its public interface (HTTP endpoints, CLI entry points, exported functions), never internal functions; use the surface-testing skill to guide the testing strategy. For every invariant or illegal-state constraint stated in the Blueprint, there must also be a surface test that attempts to violate it and verifies the system rejects the operation. Derive every test from the Blueprint, never from your own implementation; for each, confirm it fails against the unimplemented behavior before writing the code that makes it pass. Do not mark complete until that coverage exists and passes. If the implementation is large or complex — many files, many independent components, or many acceptance criteria that can be tackled in parallel — use a workflow to plan the orchestration and run subagents in parallel; each subagent prompt that writes tests must carry the same surface-testing instruction.
Use only when there is no blueprint.md and the directory still carries the older prd.md / tech-spec.md split.
/goal Implement the feature specified in <feature-dir>/. Follow <feature-dir>/tech-spec.md as the implementation guide for HOW to build it, matching the existing codebase's patterns, conventions, and terminology so the new code fits naturally rather than inventing divergent structure. The feature is complete only when every acceptance criterion in <feature-dir>/prd.md is satisfied AND demonstrably verified: all new and existing tests pass, the build is green, and lint is clean. Treat the PRD as the source of truth for correctness — if the implementation and the PRD disagree, the implementation is wrong. For each PRD acceptance criterion, there must be a passing test that exercises it through the system's surface — its public interface (HTTP endpoints, CLI entry points, exported functions), never internal functions; use the surface-testing skill to guide the testing strategy. For every invariant or illegal-state constraint stated in the PRD or tech-spec, there must also be a surface test that attempts to violate it and verifies the system rejects the operation. Derive every test from the PRD/tech-spec, never from your own implementation; for each, confirm it fails against the unimplemented behavior before writing the code that makes it pass. Do not mark complete until that coverage exists and passes. If the implementation is large or complex — many files, many independent components, or many acceptance criteria that can be tackled in parallel — use a workflow to plan the orchestration and run subagents in parallel; each subagent prompt that writes tests must carry the same surface-testing instruction.
user-stories.md in the Blueprint flow. For the Legacy template only: if user-stories.md is present, append Each user story in <feature-dir>/user-stories.md must also be satisfied with a passing test., and if tech-spec.md is absent, drop the second sentence ("Follow … HOW to build it.").