菜单
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.
用 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 | spec-tech |
| description | 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. |
You are authoring the technical spec — the how, downstream of the product spec
(/spec-product) and upstream of per-slice design (/design). The entity
engine (TOML+MD tiers, relations, show command) is documented in
[[mem.concept.doctrine.entity-engine]].
Structural. Doctrine manages specs as first-class entities — a tech spec is the same three coordinated writes as a product spec: scaffold with
spec new(subtype/title/slug only), hand-edit the spine and flat fields intospec-NNN.toml, thenspec req addits requirements. Useshowto read the reassembled whole,validatefor FK integrity,listfor the corpus (flags in--help; verb model inusing-doctrine.md). Identity, the relational spine, and flat fields (incl.c4_level,[[source]]anchors) live inspec-NNN.toml, the narrative inspec-NNN.md; requirements are peer entities (REQ-NNN) membered viamembers.toml; tech-only spec→spec edges are written withdoctrine spec interactions add/remove(not hand-authored). There is no CLI flag for the spine — it is authored TOML, andspec validateis the integrity gate.
Capture the durable architecture and mechanism:
The relational spine places every spec in the corpus tree (all hand-edited
TOML, gated by spec validate):
descends_from — tech→PRD, single-valued, a validated FK to the product intent
this capability realises.parent — a single parent, acyclic containment (the C4 decomposition).parent is never expressed as an
interactions edge, and an interactions edge is never containment (PRD-012
principle) — decomposition and peer uses/calls are distinct axes.C4 altitude. Hand-authored specs normally stop at the container/component level; code-level (C4 level 4) specs are exceptional, authored only when a unit of mechanism genuinely needs that resolution.
Posture is dual. A tech spec may be retrospective (the shipped how) or
forward-intent (SPEC-001/SPEC-002 style, describing an unbuilt engine) — both
are legal, provided planned stays distinguishable from verified. Requirements
are REQ-NNN entities at status pending; there are no coverage tables and no
status derivation — observed coverage is reconciled, never inferred from the spec.
The exemplar trio locks the three canonical shapes — read them with spec show
before authoring:
context) — the whole-system synthesis: anchor-free, no parent,
no descends_from; names the containers and their composition, never restating
any one container's mechanism.container) — parent only, no descent: a mechanism container
whose children carry the per-capability descent.component) — parent + descends_from: the thin (not anaemic)
capability shape — kind-specific contracts only, shared mechanism cited via the
parent, never restated.Keep it evergreen. A single change's concrete design — current vs target
behaviour, code-impact, verification — belongs in that slice's /design, not
here. If a decision is project-global and load-bearing, it may be an ADR
(doctrine adr new) rather than spec prose.