メニュー
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.
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 | backlog |
| description | 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. |
The backlog is the work-intake home — latent work intent captured as
issue, improvement, chore, risk, or idea items, triaged and
promoted into slices.
needs = hard dependency. after = soft ordering (suggestion).
The CLI is the source of truth for exact flags: doctrine backlog --help
| intent | verb |
|---|---|
| capture a new item | doctrine backlog new <kind> [title] |
| survey items | doctrine backlog list [--kind …] [--status …] [--tag …] [--all] |
| inspect one item | doctrine backlog show <ID> |
| transition status | doctrine backlog edit <ID> --status <STATUS> [--resolution <R>] |
| add/remove tags | doctrine backlog tag <ID> <tag> … [--remove <tag>] (adds positional; --remove/-d repeatable) |
| record a hard dep | doctrine backlog needs <ID> <DEP-ID> [<DEP-ID> …] |
| record soft ordering | doctrine backlog after <ID> <PREDECESSOR-ID> |
The work-intake membership test ([[mem.concept.backlog.work-intake-membership]]):
a candidate that does not fit the work-status lifecycle
(open|triaged|started|resolved|closed) is not a backlog item.
open → triaged → started → resolved → closed
resolved, closed) require a resolution, passed via
--resolution (fixed|done|mitigated|accepted|expired|duplicate|wont-do|obsolete|promoted).doctrine backlog edit <ID> --status <STATUS> transitions in-place. --status
is required; nothing is prompted. Terminal statuses also need --resolution.Lowercased, [a-z0-9_:-]. Colon namespacing (e.g. area:backlog). Adds are
positional, removes use --remove/-d — both in one call:
doctrine backlog tag <ID> area:cli --remove stale.
needs — hard prerequisite; validates every ref exists, refuses a closing
dependency cycle (names the members; nothing written). Use for "X blocks Y."after — soft sequencing preference; validates target exists, never rejects
a cycle (evicted at order time). Use for "do X before Y if convenient."ISS-, IMP-, CHR-, RSK-, IDE-) auto-selects the kind —
no need to pass --kind to show/edit/tag/needs/after.*.md) is hand-edited.list by default; use --all or --status closed
to reveal.