メニュー
Use before making architectural or workflow choices, when correctness depends on project governance, or when entering an unfamiliar subsystem — to load the project's authoritative rules before you act on assumptions.
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 | canon |
| description | Use before making architectural or workflow choices, when correctness depends on project governance, or when entering an unfamiliar subsystem — to load the project's authoritative rules before you act on assumptions. |
Understand project governance before you act, so you do not spread heresy.
Identify the authorities that bear on your task, then read the ones that carry meaning for it — not all of them, every time. The CLI is the source of truth — see [[mem.fact.doctrine.cli-source-of-truth]].
CLAUDE.md, AGENTS.md — standing instructions and conventions. Project
conventions are documented in [[mem.pattern.doctrine.conventions]].doctrine <kind> show <id>:
doctrine spec list - specs describing product intent / technical architecturedoctrine adr list - architecture decision recordsdoctrine policy list - policiesdoctrine standard list - standards of practicedesign.md — canon for this change's design intent.For implementation truth (gotchas, patterns, invariants tied to files or
commands), /retrieve-memory rather than rediscovering it.
Read entities tier-aware — via show, never a single raw file. The storage
rule + read-via-show discipline are resident in the boot digest and detailed in
using-doctrine.md. The storage model and storage rule are documented in
[[mem.concept.doctrine.storage-model]]; storage tiers: authored, runtime,
derived — see [[mem.fact.doctrine.storage-tiers]]. Reading one tier and
concluding "empty" is false witness.
Beware — and refuse to commit:
If governance is missing, contradictory, or ambiguous on a choice that matters,
stop and /consult rather than normalizing around a guess.