spec-coverage-assessmentlisted

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.
davidlee/doctrine · ★ 1 · Testing & QA · score 69

Install: claude install-skill davidlee/doctrine

# Spec Coverage Assessment Bounded census of a named surface's governance extent, upstream of authoring. Answers three questions an agent otherwise answers by unguided judgement: what is already covered, what is dark, and where should new spec boundaries fall. Output is a reviewable coverage-map artifact — it is not itself a spec, an ADR, or a doctrine-tracked entity. ## Name collision — read before writing anything down `doctrine coverage` (`coverage record | verify | forget`) is **requirement-verification evidence** — whether a `REQ-NNN` has been observed to hold. It has nothing to do with this skill. Never call this skill's output bare "coverage" in prose, a commit, or a doctrine entity — always qualify it: "spec coverage", "governance coverage", or "the coverage map". Never invoke `doctrine coverage` verbs expecting this skill's semantics, and never let a reviewer conflate the two — they are different axes (requirement-proof vs. surface-vs-spec extent) that happen to share a word. ## Boundary Use this skill when the surface is a subsystem, crate, capability, or code area whose existing governance is unclear — you don't yet know which specs touch it, whether they're current, or how a new spec should be carved. Do not use it when: - the target spec and its boundary are already known and unambiguous — go straight to `/spec-product` or `/spec-tech`. - the task is authoring or revising one already-scoped spec — that's `/spec-product` / `/spec-tech` directly; this sk