菜单
Serialize the current brainstorm/design discussion into a structured implementation spec and delegate the build to the cheaper "executor" subagent (Sonnet). Use when the user says to dispatch, delegate, hand off, or offload implementation to the executor after designing an approach together.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Reviews code changes before merging, through a correctness/security lens and an SRE operational-risk lens. Use when reviewing PRs, checking staged changes, reviewing diffs, code review, merge readiness check, assessing deploy or rollback risk, or validating changes before commit/push.
Dispatches a task to a Claude Fable 5 subagent with a prompt written the way Fable 5 wants to be prompted, and holds a back-and-forth with it across turns. Use when the user says /ask-fable, ask fable, fable, fable 5, send this to fable, hand this off to fable, get a Fable second opinion, or when a task sits at the top of the difficulty range: multi-hour or multi-day implementations, deep debugging, whole-repo review or bug hunts, dense technical screenshots, or ambiguous multithreaded requests where first-shot correctness matters.
Drafts a copy-pasteable prompt for Claude Fable 5 without dispatching anything. Use when the user says /prompt-fable, write me a fable prompt, draft a prompt for fable, help me prompt fable 5, or wants to hand a prompt to Fable somewhere else (the web app, another session, a colleague). For actually running the task, use the ask-fable skill instead.
User-invoked codebase recon via an ant-colony pattern. The moderator carves a large or unfamiliar codebase into disjoint territories, fans out cheap Haiku scout subagents that explore in parallel and dump full findings to /tmp scratchpads (returning only terse pointers), then one Sonnet verifier cross-checks every claim against the repo before reporting. Use to map an unfamiliar codebase or locate where something lives without bloating the main context.
User-invoked breadth check — convenes 3 specialist subagent personas to pressure-test a plan/decision/diff from angles you might have missed, surfacing framed positions + a dissent log. Intended to run AFTER the user has already reasoned through the problem, as a final "did we miss anything" sweep.
Renders conversation content (brainstorms, design discussions, walls of text) as a single self-contained, visually-structured HTML page that is easy to grasp at a glance. Use when the user says "visualize this", "make this visual", "turn this into a page", "make a visual explainer", "render as HTML", "this is a wall of text", "hard to read", "make a visual summary", or wants a friendlier visual representation of a technical discussion, architecture, concept explainer, or set of decisions/tradeoffs.
| name | dispatch |
| description | Serialize the current brainstorm/design discussion into a structured implementation spec and delegate the build to the cheaper "executor" subagent (Sonnet). Use when the user says to dispatch, delegate, hand off, or offload implementation to the executor after designing an approach together. |
| disable-model-invocation | true |
| argument-hint | [optional: focus/constraints for this dispatch] |
You are the orchestrator. The design thinking happens in THIS thread; the cheaper executor subagent does the mechanical implementation. Run inline — do not fork. Follow these steps.
You should be arriving here after a design discussion. If the task is still vague, do NOT dispatch yet — resolve the open questions with the user first. A weak executor fails on under-specified specs, not on typing.
The executor starts with ZERO of this conversation's context. The spec file is
its entire world. Write it to .claude/dispatch/spec.md (create the dir) if in
a repo, otherwise to the session scratchpad. Use this structure:
# <task title>
GOAL
<one or two sentences — the WHY, the outcome>
FILES TO TOUCH
<exact paths. If a path must be created, say so.>
INTERFACE CONTRACTS
<function/type signatures, expected inputs/outputs, data shapes. This is the
highest-leverage section — pin every seam the executor must not decide.>
STEPS
<mechanical steps if non-trivial; leave obvious HOW to the executor>
DO NOT TOUCH
<explicit non-goals and files/behavior to leave alone>
DEFINITION OF DONE
<the exact command(s) that must pass — build, test, lint, typecheck>
Leave the mechanical how to the executor; pin the decisions (interfaces,
files, done-criteria). Fold any $ARGUMENTS (focus/constraints) into the spec.
Call the Agent tool with subagent_type: executor and name: executor-run
(the name makes it resumable). Prompt:
Implement the spec at <spec path>. Read it and the named source files first.
Implement exactly what's specified. If anything is ambiguous or uncovered,
return a BLOCKED: question instead of guessing.
Read the executor's final message:
Starts with BLOCKED: — it hit ambiguity (this is by design, not failure).
Do NOT treat it as done. Surface the question to the user, get the answer,
update the spec file, then resume the same executor via SendMessage
(to: executor-run) with: "Answer: . The spec at is updated.
Resume from where you stopped." Resuming keeps its context and partial work.
Repeat until it completes.
Reports implementation — review what changed and the verification output. Relay a concise summary to the user. Do not commit unless the user asks. If verification failed, decide whether to re-spec or resume with guidance.