メニュー
Use when code-changing intent has emerged and there is no governing slice yet — to scope the change into a slice (scope document + metadata) before any design or implementation. Routed to from /route.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
The claude arm of `/dispatch` — spawn a worker via the `Agent` tool using the dispatch-worker subagent type with worktree isolation. Base is explicit — `dispatch arm-spawn --base B` writes the base file, then cd into the spawn dir before the Agent spawn so the WorktreeCreate hook forks at B. Worker self-commits via the gated `worker_commit` MCP tool; the orchestrator lands via `dispatch_import` → `dispatch_conclude_phase` → `dispatch_reap`. Reached only from the `/dispatch` router on a claude↔env-marker agreement; do not invoke directly.
Use at the very start of ANY substantive work in a Doctrine repo — before inspecting files, running commands, or writing code. The mandatory gate that chooses the governing skill. Skip it only when the user has explicitly told you to.
Use when a named subsystem, capability, or code surface needs governance coverage assessed before authoring a spec — deciding what is already governed by an existing PRD / tech spec / ADR, what is dark, and where new spec boundaries should fall by product altitude and C4 level. Use before creating or scoping a product or technical spec for an unfamiliar or partially-governed surface. Use when a request asks to "assess coverage", "find governance gaps", "what's already specified", "where should this spec's boundary sit", "one spec or several", "what needs a PRD vs a tech spec", or "is this subsystem properly documented". Produces a reviewable coverage-map artifact that feeds `/spec-product` and `/spec-tech`. Do not use when the target spec and its boundary are already known and unambiguous — go straight to `/spec-product` or `/spec-tech`. Do not confuse with `doctrine coverage` — unrelated CLI verb for requirement verification.
Use the moment you hit an unanticipated obstacle, a decision with competing tradeoffs, or emergent complexity mid-task — before adapting planned scope, adding a dependency, taking a shortcut, or making any impactful concession on your own.
Use when a slice needs architectural shaping before implementation — decision triage, critical analysis of tradeoffs and solutions, and section-by-section validation of design.md until the decisions lock. Routed to from /route once a slice exists.
Use when work surfaces something epistemic worth keeping — "we're assuming / proceeding as if X", "we decided X over Y", "open question worth outliving this session", "we're bound by X", "evidence for/against X", "testable hypothesis", or a stable concept worth naming — and when settling, relating, or surveying such records. Routes capture, settle, and survey intent to the correct `doctrine knowledge` verb.
| name | slice |
| description | Use when code-changing intent has emerged and there is no governing slice yet — to scope the change into a slice (scope document + metadata) before any design or implementation. Routed to from /route. |
You are converting intent into a concrete, scoped unit of change. A slice is one
coherent change — not a project-global decision (that is an ADR) and not
evergreen spec material (.doctrine/spec/).
Confirm the frame. Code-changing intent, and no governing slice already
covers it. Pull the constraints first: /canon for ADRs and .doctrine/spec/tech/, and
conventions; /retrieve-memory for subsystem gotchas on the surface you will
touch.
Create the slice:
doctrine slice new "<title>" [--slug <slug>]
Allocates the next id and scaffolds slice-nnn.toml (metadata, relations,
lifecycle status — starts at proposed) + slice-nnn.md (scope document).
Make scope explicit in slice-nnn.md:
Seed the affected surface as coarse scope-relevant selectors — a rough
path/glob fence on where the change lives, captured now while scope is fresh:
doctrine slice selector add <id> "src/foo/**" "src/bar.rs" --intent scope-relevant
These are intentionally loose (the exact touch-set is /design's job). They
feed the audit-time slice conformance delta; an unfenced slice has nothing to
diff git actuals against.
Record structure in slice-nnn.toml: metadata, lifecycle status. Honour
the storage rule — structured data in TOML, prose in MD, never queried/derived
data in prose. Relations are written with doctrine link, not hand-authored
rows — it validates the pair against RELATION_RULES (the legal vocabulary;
using-doctrine.md § Relating entities). e.g. governed_by an ADR, specs a
spec, supersedes a prior slice.
Check the altitude. If the work is really a project-global decision →
doctrine adr new. If it is evergreen specification → author a tech spec (doctrine spec new tech) or a product spec (doctrine spec new product).
Keep the slice to one shippable change; split if it sprawls.
You MUST shape the design before planning: record the lifecycle move
(doctrine slice status <id> design — bare number) and hand off to /design.
Do not jump to /plan or /execute from a bare slice — /route's gate forbids
it. If genuine tradeoffs or unknowns surface while scoping, /consult.