Write TechSpec

Produce docs/specs/<slug>/_techspec.md — the technical answer to the spec's requirements. The PRD said what and why; this document decides how, where, and with which — and its Build Order is what write-tasks turns into the task graph, so sequencing quality here becomes execution quality later.

Preconditions — two entry modes

$ARGUMENTS names the spec (slug or path), or describes a refactor/bug fix. Pick the mode by whether product behavior changes:

• Feature work (product behavior changes) — docs/specs/<slug>/_prd.md must exist; if it doesn't, stop and point the user at write-prd. Product decisions need the product conversation first. If the PRD contains low-level technical decisions that belong here, surface that as a finding and propose relocating them rather than silently duplicating.
• Refactor or bug fix (no product behavior change) — this skill is the pipeline entry point; no PRD interview happens. When no spec folder exists yet, mint one following write-prd's numbering rule (<spec-root>/NNNN-<kebab-slug>/, scanning both the configured Spec Root and its resolved archive directory — docs/history/specs/ for the built-in docs/specs root, or <spec-root>/_archived/ otherwise — for the highest prefix), and write a minimal _prd.md carrying only the contract downstream skills parse: the frontmatter (spec, status: active, surfaces), a problem statement, Project Constraints, goals, core features, and non-goals — engineering-framed, a few lines each. It exists so write-tasks, qa-gate, and archive-spec keep a single artifact contract; it is not a product document. If the "refactor" turns out to change product behavior, stop and route to write-prd.

Ground rules