← ClaudeAtlas

spec-techlisted

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.
davidlee/doctrine · ★ 1 · Testing & QA · score 69
Install: claude install-skill davidlee/doctrine
# Spec Tech 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 into > `spec-NNN.toml`, then `spec req add` its requirements. Use `show` to read the > reassembled whole, `validate` for FK integrity, `list` for the corpus (flags in > `--help`; verb model in `using-doctrine.md`). Identity, the relational spine, and > flat fields (incl. `c4_level`, `[[source]]` anchors) live in `spec-NNN.toml`, the > narrative in `spec-NNN.md`; requirements are **peer entities** (`REQ-NNN`) membered > via `members.toml`; tech-only spec→spec edges are written with `doctrine spec > interactions add`/`remove` (not hand-authored). **There is no CLI flag for the > spine — it is authored TOML, and > `spec validate` is the integrity gate.** Capture the durable architecture and mechanism: - the shape of the solution — components, boundaries, data flow, invariants - the key technical decisions and their rationale (link relevant ADRs) - interfaces and contracts that outlive any single change - constraints the implementation must honour **The relational spine** places