archetype-review-base

# Archetype-review-base — shared review framework Every domain reviewer follows this skeleton. Each reviewer's own SKILL.md adds the domain heuristics on top. This skill defines the parts that must be IDENTICAL across all reviewers. ## Output artifact (canonical) Pre-implementation reviewers (the `*-reviewer` agents — ~30 in `agents/` — invoked by architect BEFORE senior-dev claims tasks) write a **threat model** at `docs/sec-threats/TM-{slug}.md` and append a `<!-- HANDOFF -->` block (see "Workflow scaffold" below). That is the single convention for every reviewer. **One TM file per feature slug.** Per-reviewer filename suffixes (`TM-api-{slug}.md`, `TM-extension-{slug}.md`) are deprecated — consumers glob `TM-{slug}.md` and per-suffix files silently escape their checks. When multiple domain reviewers run on the same slug, each APPENDS its own `## {reviewer} findings` section and its own `<!-- HANDOFF -->` block to the shared `TM-{slug}.md` — never overwrite another reviewer's sections. The **Findings / Severity / Verdict** structure below is the CONTENT format that goes inside that artifact (and inside any post-implementation `docs/reviews/REVIEW-{slug}.md` produced by a review-tier agent). Path differs by phase; the section grammar is identical. ## Mandatory report sections The report (TM or REVIEW) MUST contain these sections in this exact order: ```markdown # TM-{slug} — {reviewer name} <!-- pre-impl; post-impl review-tier files use REVIEW-{slug} --> Review...