القائمة
Use when everything is written down and in order for a fresh agent, and the user wants to continue with a new context — print a concise continuation prompt for the next agent.
التثبيت باستخدام 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 | next |
| description | Use when everything is written down and in order for a fresh agent, and the user wants to continue with a new context — print a concise continuation prompt for the next agent. |
Print:
/route
(path to the governing slice and the next obvious task)
If the next task is implementation-bound, include the specific artefacts to read
(design.md, plan.toml, the active runtime phase sheet) and name any unresolved
assumptions or design questions the next agent must assess before declaring
readiness.
Before printing, confirm the durable state is actually in order — notes current, phase status accurate, work committed or its uncommitted state noted — so the next agent inherits truth, not a stale story.