메뉴
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.
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 | preflight |
| description | 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. |
/route routes into /preflight; it does not replace /route. Use this only
after routing has established that the immediate need is bounded up-front
research. If you have not chosen the governing skill path yet, stop — use
/route first.
You're about to begin work on something: $ARGUMENTS
First: you need to understand what it entails. Your immediate task is to correctly decide how much effort to spend on this preliminary research.
Too little is as bad as too much. You must estimate where the goldilocks zone is, and arrive with maximum tokens intact.
You may be expected to:
Do not use this skill to decide whether the task belongs to /slice,
/design, /execute, or another governing skill. That decision must already be
made.
If you can't tell whether /preflight is appropriate, you probably need
/route, not this skill.
Learn just enough to ask the user the right clarifying questions. These might include: how deeply should you research? what remains ambiguous? which assumptions are safe enough to carry forward?
If you chase the questions which arise as you go, you'll disappear like a helium balloon into the open sky.
Instead:
/retrieve-memory and /canonRepeat this process to clarify further, if the user indicates to.
Breadth first: start broad and high level, drill down as necessary.
Search order:
/canon.doctrine/spec/tech//retrieve-memorybacklog list / backlog show <ID>) — is this work already
captured, and which open items bear on it?doctrine knowledge list) — do unsettled records gate or
shape this surface? Assumptions you choose to carry → capture as ASM via /knowledge./preflight steal the job of /route.Do not begin implementation without acknowledgement from the user.