菜单
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.
用 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 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.
Use after routing has chosen this path, when the next step is bounded up-front research to understand a substantive task, surface unknowns and tensions, and assess readiness — without drifting into implementation or open-ended exploration.
| name | route |
| description | 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. |
The mandatory routing layer for Doctrine. The routing gate concept is documented in [[mem.concept.doctrine.routing-gate]]. Follow it rigorously unless the user has instructed otherwise. If the user explicitly invoked a skill, use that now; if the routing layer indicates a subsequent action in a chain, go on with it afterwards.
Do not respond, explore, inspect files, run commands, or start implementation until you have chosen the skill that governs the task. If there is a reasonable chance another Doctrine skill governs it, route through that skill first.
Do not rationalize around this. If you skip routing because the task feels familiar, simple, urgent, or "probably fine", you are doing it wrong:
When unsure, route to the stricter skill, not the looser one.
The routing table, mid-flight rules (consult / record-memory / backlog / notes /
next / conduct postures), and core guardrails are already inlined in this
session's prefix (@.doctrine/state/boot.md). Apply them from there — this
skill does not restate them. What follows is route-unique.
The core loop (slice→design→plan→execute→audit→close) is documented in [[mem.pattern.doctrine.core-loop]].
backlog list — is this intent
already captured, and do open items bear on it?/spec-tech; product specs → /spec-product;
spec target or boundary unclear → /spec-coverage-assessment first./execute — the design, plan, and
runtime phase sheet must exist first (the no-code-without-approved-plan gate).doctrine --help (dev: ./target/debug/doctrine --help) is the source of
truth. If doctrine is unavailable, STOP and alert the user.
The inlined prefix is written by a prior session's hook, so it can lag a
just-made edit. Freshen-now ritual: run doctrine boot, then /clear or
restart — regenerate THEN clear; doctrine boot alone cannot refresh the
already-inlined prefix. (Disk sentry, separate check: doctrine boot --check.)