doctrine

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.

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.

Use to formally close a slice once its phases are complete, audited, and reconciled — confirm the rollup, verify spec-coherence, harvest durable findings, reconcile lifecycle status, and land a clean final commit. Routed to from /reconcile.

Use when running a value-elicitation session — surfacing and asking the next worthwhile pairwise value questions, reviewing suspect anchors, or calibrating value evidence with a human via `doctrine compare elicit`.

Use when receiving feedback on your work — review findings, user corrections, audit results, external reviewer notes — to triage by authority, adjudicate each point on evidence, integrate without regressions, and close the loop with the source. Evidence flips positions; assertions don't.

Use whenever reviewing code for quality and correctness — a diff, PR, module, or subsystem — producing verified, severity-ranked findings on the RV ledger. Not for comprehension tours (walkthrough) or doctrine-conformance hunts (inquisition, user-invoked only).

Agentic pair programming — drive a change together with a human partner in the loop, narrating intent and pausing at decision points. Use when the user wants to work side-by-side rather than hand off a whole task. Calibrated by three dials (role, detail, autonomy) and an always-on challenge mandate.

Guided walkthrough of code, a diff/PR, architecture, tests, or docs — build the reader's mental model, explain the choices made and their tradeoffs, and critically evaluate the artifact. Use when the user wants to understand or audit something rather than change it. Adapts to expert vs learner; companion to the pair skill.

Use when operating at the edge of your capacity — high complexity, deep uncertainty, unfamiliar territory, expensive context — and being confidently wrong would be costly. A conduct posture layered onto whatever skill governs the stage; it changes how you work, not which work you do.

Use to drive a slice's phases to completion through sub-agent workers in isolated worktrees — you orchestrate and are the sole writer, the workers execute. Routes to `/dispatch-subprocess` (codex/pi) or `/dispatch-agent` (claude); overridable via `[dispatch] claude-force-subprocess-dispatch` in `doctrine.toml`. The funnel cadence (import → verify → branch-point → one commit → record) is identical on both arms. Default serial (one worker per phase); parallelize file-disjoint phases. Conflicts report-and-halt, never auto-merge.

Use when a slice's design is locked and it needs an executable phase plan — refine each phase's objective and entry/exit/verification criteria, author plan.toml + plan.md, and materialise the runtime phase sheets. Routed to from /design.

Use after a slice's phases are implemented, when the task is now evidence, conformance, and reconciliation against the design — disposition every finding on a reconciliation review ledger (the RV kind) before closure.

Use when the user wants to create, survey, triage, tag, or transition a doctrine backlog item (issue / improvement / chore / risk / idea) — `doctrine backlog` is the CLI surface; use this skill to drive the correct verb for the intent.

Create a context packet and continuation prompt to continue with the next step in progressing a slice or other governing doctrine artifact. Use whenever the work is in good condition for onboarding and a fresh agent would more efficiently continue.

Use after /audit resolved the RV ledger and wrote the reconciliation brief — you are the sole explicit writer of reconciled truth. Consume the RV + brief, write changes through two surfaces (direct edit for per-slice artefacts, REV for governance/spec), and hand off a resolved outcome to /close. Routed to from /audit.

The codex/pi arm of `/dispatch` — `doctrine worktree fork --worker` then spawn the worker as a subprocess with its cwd bound to the fork. Reached only from the `/dispatch` router on a codex/pi↔env-marker agreement; do not invoke directly.

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.

Use to implement one planned, approved phase of a slice — once its design and plan exist and its runtime phase sheet is ready. Move the phase to in_progress, build it TDD red/green/refactor, keep notes current, end green, and surface blockers early.

Use whenever you complete a unit of work, a task, or a phase — record implementation notes so progress and findings are durable, not stranded in conversation context.

Use when work needs isolation from the current workspace — when /execute (mode=solo) or the /dispatch funnel must run a phase on its own branch without touching the main working tree. Detects existing isolation, creates a fork via `doctrine worktree fork` (the sole creation+provision+mark verb; coordination tier excluded), runs the commit-before-spawn / branch-point / baseline guards, and hands back the fork branch.

Use just before executing a specific phase — expand its authored plan entry (objective + EN/EX/VT) into the disposable runtime phase sheet with a concrete task breakdown, assumptions, and verification steps. Routed to from /plan or /execute.

Use when authoring or revising the technical specification — the how of a capability, downstream of the product spec and upstream of per-slice design. Use to record durable architecture and mechanism, not a single change's design.

Use only when the user explicitly requests an "inquisition" (e.g. "seek out heresy", "begin an inquisition", "inquisition on X") to hunt adversarially for deviations from doctrine, design, plan, conventions, or acceptance criteria. Do NOT use for routine "review X" or ordinary code review.

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.

Unified memory corpus maintenance — covers both reactive (change-triggered) and proactive (periodic/idle-time improvement) paths. One skill, two entries.

Use before making non-trivial assumptions — before touching a subsystem you have not this session, before running or changing a command pipeline, when code and docs conflict, when asked "what is the right way here?", when debugging a recurring failure, or when about to answer with "probably/usually/likely".

Structured audit for stability gates — before releases, migrations, large refactors, or when agent confusion is detected. Use to prune, correct, and re-anchor the memory corpus before it drifts past useful.

Use when you discover or confirm a durable fact, constraint, invariant, convention, sharp edge, footgun, or reusable workflow that a future agent would otherwise rediscover — capture it before it is lost to conversation context. Triggers at phase/slice wrap-up too.

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.

Use when authoring, revising, normalising, or reviewing a doctrine product specification/PRD - the durable product intent, requirements, success measures, behaviours, and verification basis for an evergreen capability. use before creating or scoping slices that descend from shared product intent. use when a request asks for product requirements, functional requirements, non-functional requirements, product scope, acceptance gates, out-of-scope boundaries, success measures, or agent-readable product context. do not use for one-off change planning, implementation design, technical architecture, or phase execution.