bigpowers 2.73.9 → 2.74.1

package/skills/dispatch-agents/SKILL.md

@@ -5,6 +5,13 @@ effort: standard
 description: Dispatch multiple subagents in parallel on independent tasks. No waiting between them — all run concurrently. Use when tasks are truly decoupled and speed matters. Distinct from delegate-task (concurrent here, no inter-task review gate).
 ---
 
+# story: e09s04
+# story: e45s38
+<!-- story: e45s11 -->
+
+
+# story: e45s30
+
 # Dispatch Agents
 > **HARD GATE** — **HARD GATE** — Agent work must be parallelizable and have explicit synchronization points. Do NOT dispatch work that has hidden dependencies between agents.
 
@@ -36,30 +43,57 @@ Before dispatching, verify each task pair is truly independent:
 
 If any two tasks conflict, sequence them with `delegate-task` or `execute-plan` instead.
 
-### 2. Write task briefs
+## Subagent depth tiers (e45s30)
 
-Before writing briefs, read `specs/state.yaml` if it exists — each agent gets only the decisions relevant to its task, nothing else.
+Map `effort:` frontmatter and story `risk:` to prompt depth — do not send `minimal_decisive` agents a `full_maturity` brief.
 
-For each task, use this minimal template (each agent starts cold — brief size directly controls token cost and hallucination risk):
+| Tier | When | Brief shape | Token budget |
+|------|------|-------------|----------------|
+| `full_maturity` | `effort: heavy`, `risk: P0`, security-sensitive diffs | Full `task_brief` + CONVENTIONS excerpts + threat model if present | Full envelope |
+| `standard` | `effort: standard`, `risk: P1`–`P2` | Standard `task_brief` fields below | Default |
+| `minimal_decisive` | `effort: light`, `risk: P3`, read-only exploration | `goal` + `verify` + `in_scope` only | ≤15 lines |
 
-```
-Goal: [one sentence — what success looks like]
-In scope: [explicit file or module list]
-Out of bounds: [what NOT to touch]
-Verify: [runnable command]
-Prior decisions: [relevant entries from specs/state.yaml — omit section if none apply]
+Record `depth: <tier>` in the Agent tool description when dispatching.
+
+### 2. Write typed task briefs (Orca message protocol)
+
+Before writing briefs, read `specs/state.yaml` if it exists — each agent gets only the decisions relevant to its task, nothing else.
+
+Every inter-agent message uses a **typed envelope** — no freeform prose between waves:
+
+| `type` | When | Required fields |
+|--------|------|-----------------|
+| `task_brief` | Dispatch | `task_id`, `goal`, `in_scope`, `out_of_bounds`, `verify`, `prior_decisions` |
+| `checkpoint` | Mid-wave progress | `task_id`, `status` (`running`\|`blocked`), `comment` (one line) |
+| `result` | Agent return | `task_id`, `exit` (`pass`\|`fail`), `summary`, `verify_output` |
+| `circuit_open` | 3 consecutive failures | `task_id`, `failures` (3), `escalate_to` (`user`) |
+
+Example `task_brief` (each agent starts cold — brief size directly controls token cost and hallucination risk):
+
+```yaml
+type: task_brief
+task_id: agent-1
+goal: [one sentence — what success looks like]
+in_scope: [explicit file or module list]
+out_of_bounds: [what NOT to touch]
+verify: [runnable command]
+prior_decisions: [relevant entries from specs/state.yaml — omit if none]
 ```
 
+Emit **`checkpoint`** comments when an agent is slow or blocked — one line, no stack traces. Parent reads checkpoints before spawning follow-ups.
+
 Do not include the full conversation, full file contents, or decisions unrelated to this agent's task.
 
-### 3. Iterative retrieval (max 3 cycles)
+### 3. Circuit breaker + iterative retrieval (max 3 cycles)
+
+Track **consecutive failures per `task_id`**. On the **3rd consecutive `result.exit: fail`** for the same task, emit `type: circuit_open` and **stop dispatching** that task — escalate to user with the three failure summaries. Reset counter on any `pass`.
 
 After each wave completes:
-1. **Dispatch** — run parallel agents with briefs.
-2. **Evaluate** — read outputs; list gaps vs goal.
+1. **Dispatch** — run parallel agents with typed `task_brief` envelopes.
+2. **Evaluate** — read `result` messages; list gaps vs goal; honor open circuits.
 3. **Refine** — tighten briefs or spawn follow-up agents (max **3 cycles** total).
 
-Stop when gaps empty or cycle 3 reached — escalate to user.
+Stop when gaps empty, circuit opens, or cycle 3 reached — escalate to user. If agents go silent without returning, invoke `diagnose-stall` before spawning another wave.
 
 ### 4. Dispatch in parallel
 
@@ -73,14 +107,14 @@ Agent 3: brief for task C
 
 ### 5. Collect and review results
 
-When all agents return:
-- Review each result independently
-- Run all verify commands
-- Check diffs for scope violations or CONVENTIONS.md breaches
+When all agents return: review each result, run verify commands, check diffs for scope violations.
 
 ### 6. Integrate
 
-Merge accepted results. If any agent's result conflicts with another, resolve manually and note the conflict.
+Merge accepted results. Resolve conflicts manually; note in summary.
+
+Report: which tasks succeeded, which need revision, overall verify status.
 
-Report a summary: which tasks succeeded, which need revision, and overall verify status.
+## Verify
+→ verify: `grep -q 'circuit_open' skills/dispatch-agents/SKILL.md && grep -q 'task_brief' skills/dispatch-agents/SKILL.md && echo OK || echo FAIL`
 

package/skills/elaborate-spec/SKILL.md

@@ -3,6 +3,7 @@ name: elaborate-spec
 model: opus
 effort: standard
 description: Refine a rough idea into a clear, detailed specification through dialogue. Does not produce code. Use when user has a vague idea, wants to think through a feature before planning, or needs to turn "I want X" into a concrete spec.
+# story: e24s01
 ---
 
 # Elaborate Spec

package/skills/evolve-skill/SKILL.md

@@ -4,6 +4,10 @@ description: Benchmark-gated skill evolution — consume bigpowers-benchmark rep
 model: opus
 effort: standard
 ---
+# story: e23s03
+
+# story: e09s01
+# story: e09s05
 
 # Evolve Skill
 
@@ -31,3 +35,6 @@ effort: standard
 → verify: `grep -c 'run-benchmark\|pass_at_k\|BASELINE-' skills/evolve-skill/SKILL.md | awk '{if($1>=2) print "OK"; else print "FAIL"}'`
 
 See [REFERENCE.md](REFERENCE.md) for ADR template.
+
+
+<!-- story: e31s07 -->

package/skills/gate-trace/SKILL.md

@@ -1,7 +1,9 @@
+# story: e45s05
 ---
 name: gate-trace
 description: "Deterministic traceability quality gate — reads coverage matrix + blind-spot data, applies decision rules with oracle confidence downgrade, emits PASS/CONCERNS/FAIL/WAIVED verdict. Use before release-branch to gate merges on traceability."
 # story: e38s06
+# story: e45s32
 model: haiku
 effort: light
 ---
@@ -39,7 +41,15 @@ TEA-inspired: if trace links rely on heuristics rather than explicit tags, confi
 5. Apply oracle confidence downgrade based on the heuristic link ratio from the matrix's `oracle_stats`.
 6. **Drift check (e39s03):** If `specs/drift-report.json` exists and has suspect links, mark verdict as CONCERNS with note: "Drift detected — some implementing files are newer than their specs. Run scripts/check-spec-drift.sh for details."
 7. Output verdict + rationale to stdout.
-7. Update `specs/execution-status.yaml` with gate-trace result.
+8. **Adversarial refute check (e45s32):** Before emitting PASS, attempt to **refute** the verdict — list at least one concrete traceability gap that would block merge if it were real. If the gap is real, downgrade the verdict. Rubber-stamping is prohibited; every PASS must survive one refutation attempt.
+9. **Completeness critic (e45s05)** — Run adversarial gap-finding:
+
+```bash
+bash scripts/lib/completeness-critic.sh
+```
+
+Classify output as **BLOCKER / WARNING / FILLED**. **BLOCKER overrides any PASS verdict → FAIL.** Append critic summary to rationale.
+10. Update `specs/execution-status.yaml` with gate-trace result.
 
 ## Verdict Semantics
 

package/skills/guard-git/REFERENCE.md

@@ -1,5 +1,19 @@
 # Git guardrails — reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–14 | Navigation |
+| 16–24 | Secret patterns |
+| 26–44 | Copy layout |
+| 46–72 | Claude Code |
+| 74–92 | Cursor and Cursor CLI |
+| 94–120 | Gemini CLI |
+| 122–135 | Google Antigravity |
+| 137–178 | Verify (local tests) |
+
 ## Secret patterns (audit + pre-commit)
 
 Agents must not commit files containing:

package/skills/kickoff-branch/SKILL.md

@@ -1,4 +1,3 @@
-# story: e51s03
 ---
 name: kickoff-branch
 model: haiku
@@ -6,6 +5,10 @@ effort: standard
 description: Create a git worktree and feature branch, then verify a clean test baseline before any code is written. Use when starting a new feature or task, when user wants to work in isolation from main, or mentions "start a branch" or "new worktree".
 ---
 
+# story: e51s03
+# story: e20s03
+
+
 # Kickoff Branch
 
 > **HARD GATE** — Direct work on `main` or `master` is PROHIBITED. Every task MUST start with this skill to create a feature branch or worktree.

package/skills/migrate-spec/REFERENCE.md

@@ -1,5 +1,17 @@
 # Migrate Spec — Reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–22 | Navigation |
+| 24–62 | spec-kit → bigpowers Mapping |
+| 64–130 | BMAD → bigpowers Mapping |
+| 132–154 | Learnings to Adopt |
+| 156–350 | Output Formats + state.yaml template |
+| 352–620 | Reference blocks 1–2 + extended mappings |
+
 # migrate-spec Reference — spec-kit, BMAD, Learnings
 
 Transformation rules for spec-kit and BMAD projects, plus learnings to adopt and output formats.

package/skills/migrate-spec/SKILL.md

@@ -4,6 +4,12 @@ model: sonnet
 effort: standard
 description: Detect GSD, spec-kit, or BMAD spec artifacts and transform them into bigpowers YAML layout (state.yaml, release-plan.yaml, epics/, requirements/, plans/, ADRs). Use when migrating foreign spec docs.
 ---
+# story: e25s01
+# story: e25s02
+# story: e25s03
+# story: e25s04
+# story: e25s05
+# story: e25s06
 
 # Migrate Spec
 

package/skills/plan-work/REFERENCE.md

@@ -1,5 +1,16 @@
 # Plan Work — Reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–14 | Navigation |
+| 16–38 | Output file formats |
+| 40–71 | Plan template |
+| 73–91 | Verify step format rules |
+| 93–131 | Sub-operations (risk, define-success, zoom-out, slopcheck, delta tags) |
+
 ## Output file formats
 
 ### Story spec: `specs/epics/<capsule>/eNNsYY-<slug>.md`
@@ -11,14 +22,14 @@ Populated countable-story-format with all 20 sections. Minimum maturity: 3 (Coun
 ```yaml
 story_id: e01s01
 title: Login
-status: todo
+status: failing
 bcps: 3
 tasks:
   - id: 1
     description: "Add login form component tests"
     verify: "npm test -- login-form.test.tsx"
     risk: P1
-    status: todo
+    status: failing   # flip to passing only after verify exits 0 (e45s06)
 ```
 
 Update `specs/epics/<capsule>/epic.yaml` manifest to list the story and its BCPs. Run `bash scripts/sync-status-from-epics.sh` after structural changes.
@@ -89,6 +100,22 @@ Every task and story MUST be assigned a `risk:` level (P0, P1, P2, P3). When `sp
 
 `verify-work` scales its UAT depth based on this field.
 
+### Requirement delta tags (e45s29)
+
+When modifying existing behavior in story spec § Requirements:
+
+```markdown
+#### MODIFIED: User can reset password via email link
+**Before:** Password reset required admin approval.
+**After:** Self-service reset via signed email link (expires 1h).
+
+#### REMOVED: Legacy OAuth1 login
+**Before:** OAuth1 provider supported for enterprise SSO.
+**After:** (removed) — provider deprecated; OAuth2 only.
+```
+
+Tags: `ADDED`, `MODIFIED`, `REMOVED`, `RENAMED`. `MODIFIED`/`REMOVED`/`RENAMED` without before/after → plan-work gate FAIL.
+
 ### Define Success
 
 Before planning, convert task statements into observable "step → verify: <cmd>" pairs:

package/skills/plan-work/SKILL.md

@@ -1,3 +1,8 @@
+# story: e45s04
+# story: e45s06
+# story: e45s09
+# story: e45s33
+# story: e45s35
 ---
 name: plan-work
 model: opus
@@ -5,6 +10,8 @@ effort: standard
 description: "PLANNING SPINE STEP 3 of 3 — Plan the work: write detailed implementation tasks into the active epic capsule (specs/epics/eNN-slug/). Produces countable-story-format .md specs and runnable -tasks.yaml files. Use after slice-tasks (step 2). Not a substitute for scope-work (step 1) or slice-tasks (step 2)."
 ---
 
+# story: e45s29
+
 # Plan Work
 
 > **Spine position:** Step 3 — scope-work → slice-tasks → plan-work.
@@ -46,14 +53,45 @@ If this plan touches an existing module, run `assess-impact` first to understand
 
 3. **Write capsule story spec + tasks** — Output two files inside the active epic capsule. See [REFERENCE.md](REFERENCE.md) for file formats and the plan-template. Each task MUST include a `risk:` field (`P0` | `P1` | `P2` | `P3`) based on BCP + story type heuristics (see REFERENCE.md). If a test plan artifact (`specs/tech-architecture/eNN-TEST_PLAN_LATEST.md`) exists, read it and inherit its P0/P1 risk classifications and scenario IDs (`SC-eNNsYY-P0-NN`). Each task optionally includes a `security:` field (`none` / `low` / `medium` / `high`) sourced from the epic's `specs/security/epics/<id>/THREAT_MODEL.md`. Tasks with `security: medium` or `security: high` MUST include "no new security findings in affected paths" in their verify steps.
 
+   **Requirement delta tags (e45s29):** When a story modifies existing behavior, the story spec § Requirements MUST use OpenSpec-style delta tags with mandatory before/after content:
+
+   | Tag | When | Required content |
+   |-----|------|------------------|
+   | `ADDED` | New requirement | Full requirement text |
+   | `MODIFIED` | Changed behavior | **Before:** prior behavior · **After:** new behavior |
+   | `REMOVED` | Retired requirement | **Before:** what existed · **After:** (removed) + rationale |
+   | `RENAMED` | ID or title change only | **Before:** old ID/title · **After:** new ID/title |
+
+   Net-new stories (greenfield) use `ADDED` only. `MODIFIED`/`REMOVED`/`RENAMED` without before/after blocks fail the plan-work gate.
+
 4. **Verify step format** — Every step MUST follow: `N. <What to do> → verify: <runnable command>`. See [REFERENCE.md](REFERENCE.md) for good/bad examples.
 
+4a. **Cross-artifact consistency pass (HARD GATE — e45s04)** — Before handoff, run:
+
+```bash
+bash scripts/lib/plan-consistency-check.sh specs/epics/<capsule>/
+```
+
+Print CRITICAL / HIGH / MED findings. **CRITICAL or HIGH blocks code generation** — fix capsule artifacts first. MED requires explicit user acknowledgment.
+
+4b. **tasks.yaml failing ledger (e45s06)** — Every new task entry starts with `status: failing`. Only flip to `status: passing` after its `verify:` command exits 0 during `develop-tdd` or `verify-work`. Never pre-mark passing at plan time.
+
 5. **Review with user** — Confirm step order, granularity, and that verify commands are runnable in this project.
 
+## Lifecycle Gates (e45s09)
+
+| Gate | When | Pass condition |
+|------|------|----------------|
+| **Pre-Implementation** | Before `kickoff-branch` / first RED commit | Root-cause stated for bugs; `assess-impact` done for module changes; plan-consistency-check PASS |
+| **Validation** | Story marked done | All tasks `status: passing`; verify evidence in `specs/verifications/` |
+| **Reopen-don't-refile** | Regression on shipped story | Reopen existing story/bug — do not create duplicate capsule entries |
+
 After writing capsule tasks, suggest `kickoff-branch` (if not already on a feature branch) then `build-epic`, `execute-plan`, or `develop-tdd`.
 
 ## Verify
 
+→ verify: `test -f scripts/lib/plan-consistency-check.sh && bash scripts/lib/plan-consistency-check.sh specs/epics/e45-quality-core/ 2>&1 | head -5`
+
 
 
 ## Handoff

package/skills/publish-package/REFERENCE.md

@@ -1,5 +1,16 @@
 # Publish Package — Reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 3–18 | Navigation |
+| 20–28 | Options |
+| 30–60 | Examples |
+| 62–72 | Integration with release-branch |
+| 74–252 | Reference blocks 1–8 |
+
 ## Options
 
 | Flag | Description |

package/skills/release-branch/REFERENCE.md

@@ -1,5 +1,19 @@
 # Release Branch — Reference
 
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1–3 | Title |
+| 5–16 | Navigation |
+| 18–41 | PR body template |
+| 43–54 | Worktree cleanup |
+| 56–96 | Cycle-time recording |
+| 98–119 | CI verification |
+| 121–126 | Solo-local fallback |
+| 128–134 | Handoff |
+| 136–155 | Reference block 1 (manual squash) |
+
 # Release Branch — Reference
 
 ## PR body template (team-pr mode)

package/skills/release-branch/SKILL.md

@@ -1,11 +1,18 @@
-<!-- story: e38s07 -->
 ---
 name: release-branch
+# story: e14s01 e15s03
 model: haiku
 effort: standard
 description: Make the merge/PR/keep/discard decision for a feature branch, verify coverage gates, create the PR with gh, and clean up the worktree. Use when a feature is done and ready to ship, or when user says "release", "merge", or "open a PR".
 ---
 
+<!-- story: e38s07 -->
+<!-- story: e45s15 -->
+<!-- story: e45s32 -->
+<!-- story: e45s39 -->
+<!-- story: e20s02 -->
+
+
 # Release Branch
 
 > **HARD GATE** — Do NOT merge or release if tests fail or if coverage gates are not met. If the branch is red, return to `develop-tdd` to fix regressions or add missing tests before proceeding.
@@ -55,6 +62,8 @@ If REVIEW.md is missing or stale → run `security-review` inline. Findings bloc
 
 Run `gate-trace` before merge. FAIL blocks merge; CONCERNS requires explicit override in `specs/state.yaml` (`traceability_override: CONCERNS accepted, reason: <explanation>`). WAIVED if no matrix available.
 
+> **Adversarial refute framing (e45s32):** The final pre-merge check is **refute, not rubber-stamp**. Before declaring ready, actively try to disprove traceability completeness — missing story tags, absent verify evidence, stale security review. Only proceed when refutation fails.
+
 ### 3. Diff review
 
 - [ ] All commits intentional, no secrets, CONVENTIONS.md compliance
@@ -75,9 +84,26 @@ bash scripts/land-branch.sh <task-slug> "feat(scope): description"
 
 ### 6. Create PR (team-pr only)
 
-Create the pull request, then merge via `gh`:
+Create the pull request with a **literal provenance marker** in the body so agent-generated PRs are identifiable and do not rot silently:
+
+```markdown
+<!-- bigpowers-provenance: agent-generated -->
+```
+
+Place the marker on its own line immediately after the `## Summary` heading. Then merge via `gh`:
 
 ```bash
+gh pr create --title "..." --body "$(cat <<'EOF'
+## Summary
+<!-- bigpowers-provenance: agent-generated -->
+
+- ...
+
+## Test plan
+- [ ] ...
+
+EOF
+)"
 gh pr merge --squash --delete-branch
 ```
 
@@ -93,55 +119,18 @@ mv specs/epics/eNN-slug specs/epics/archive/
 
 ### 7b. CI verification & agent lock release (e39s02)
 
-> **HARD GATE** — Do NOT declare success until CI completes. A push that fails CI is a regression, not a release.
-
-After push, run CI polling:
+> **HARD GATE** — Do NOT declare success until CI completes. **Three-independent-facts** (e45s15): commit landed, workflow green, registry visible — see [REFERENCE.md](REFERENCE.md#three-independent-facts-release).
 
 ```bash
 bash scripts/wait-for-ci.sh --timeout 600 --interval 30
 ```
 
-Then release the story lock:
+- [ ] CI passes; `release.ci_verified: true` in state.yaml
+- On failure: `handoff.next_skill = fix-bug`
 
-```bash
-LOCK="specs/agent-locks.yaml"; STORY="<story-id>"
-[ -f "$LOCK" ] && python3 -c "
-import yaml
-d=yaml.safe_load(open('$LOCK'))
-if d:d['locks']=[l for l in d['locks'] if l.get('story_id')!='$STORY']
-yaml.dump(d,open('$LOCK','w'),default_flow_style=False)
-print(f'LOCK RELEASED: $STORY')
-"||echo "No lock for $STORY — idempotent"
-```
+### 8. Clean up & return
 
-- [ ] CI workflow passes after push (wait-for-ci.sh exit 0)
-- [ ] `release.ci_verified: true` documented in state.yaml
-- On failure: `handoff.next_skill = fix-bug` with CI failure URL
-
-### 8. Clean up worktree
-
-```bash
-git worktree prune
-git worktree remove ../<branch-name> 2>/dev/null || true
-git branch -d <branch-name>
-```
-
-### 8a. Cycle-time recording
-
-After landing, record delivery metrics with the git-derived, additive script:
-
-```bash
-bash scripts/record-cycle-time.sh append \
-  --story <story_id> --bcps <bcps> \
-  --range "$(git merge-base main HEAD)..HEAD" \
-  --file specs/metrics/cycle-times.yaml
-```
-
-### 9. Return to main
-
-```bash
-git checkout main && git status && pwd
-```
+Worktree prune, branch delete, `git checkout main`. Cycle-time: see [REFERENCE.md](REFERENCE.md#cycle-time).
 
 Report: "Branch released."
 

package/skills/request-review/SKILL.md

@@ -1,3 +1,6 @@
+# story: e45s07
+<!-- story: e45s07 -->
+<!-- story: e45s17 -->
 ---
 name: request-review
 model: opus
@@ -5,21 +8,44 @@ effort: standard
 description: Dispatch a fresh reviewer agent with a clean context to critique the code after audit-code passes. The reviewer has no shared state with the coding agent and gives a genuine second opinion. Use after audit-code passes, before committing, or when user wants an independent code review.
 ---
 
+# story: e45s28
+
 # Request Review
 
-Dispatch a fresh reviewer agent with a clean context. The reviewer has no shared state — it can give a genuine second opinion because it hasn't been involved in writing the code.
+Dispatch fresh reviewer agents with clean contexts. Reviewers have no shared state — they find what the coding agent missed.
+
+**Distinct from `audit-code`:** `audit-code` is self-review (internal). This skill dispatches external agents.
+
+**Solo developer note:** Reviewer agents replace the human reviewer.
+
+**Run `audit-code` first.** Don't waste reviewer attention on hygiene issues you could have caught yourself.
+
+## Santa Method — Dual-Blind AND Gate (e45s07)
+
+Use **two independent reviewers** (Reviewer A and Reviewer B) with **no shared context** between them or the coding agent.
 
-**Distinct from `audit-code`:** `audit-code` is the coding agent checking its own work (internal). This skill dispatches an external agent whose job is to find what the coding agent missed.
+| Parameter | Value |
+|-----------|-------|
+| Reviewers | 2 (mandatory) |
+| `MAX_REVIEW_ITERATIONS` | **5** (hard cap — e45s28; iteration 6 forbidden) |
+| Pass rule | **AND-gate** — both reviewers must pass independently |
+| Blindness | Neither reviewer sees the other's report until both complete |
 
-**Solo developer note:** This replaces the human reviewer. The reviewer agent IS the reviewer.
+**Iteration loop (max `MAX_REVIEW_ITERATIONS`):**
 
-**Run `audit-code` first.** This skill assumes `audit-code` has already passed. Don't waste a reviewer's attention on hygiene issues you could have caught yourself.
+1. Dispatch Reviewer A and Reviewer B in parallel with identical briefs but separate contexts.
+2. Collect both reports. Each categorizes findings: must-fix / should-fix / consider.
+3. **AND-gate:** If **either** reviewer has must-fix findings → FAIL round. Run `respond-review`, fix, re-dispatch both reviewers.
+4. If both pass (zero must-fix, score ≥ 94% each) → review complete.
+5. After **5** iterations without dual pass → **stop**; report "Review cap exhausted (5/5). Human decision required." Do not merge.
+
+> **HARD GATE** — Single-reviewer pass is insufficient. Partial agreement does not satisfy the AND-gate.
 
 ## Process
 
 ### 1. Prepare the review brief
 
-Write a self-contained brief for the reviewer agent. Include:
+Write a self-contained brief for each reviewer. Include:
 
 - What was built (feature description, not implementation)
 - Which files changed (the diff context)
@@ -29,12 +55,25 @@ Write a self-contained brief for the reviewer agent. Include:
 - What you're most uncertain about (where you want fresh eyes)
 - **Security focus** — If the epic has a `specs/security/epics/<id>/THREAT_MODEL.md`, include the relevant vulnerability categories as reviewer focal points. Also include the false-positive exclusion rules so the reviewer avoids known-safe patterns. Tag the review as `security-sensitive: true` if THREAT_MODEL risk is HIGH+.
 
-### 2. Dispatch the reviewer agent
+### 2. Fan-out parallel reviewers (e45s17)
+
+Beyond the mandatory dual-blind pair (e45s07), optionally dispatch **N dimension-specific subagents in one message** — one check per agent for broader coverage (OpenAI Codex `code-review-*` pattern):
+
+| Agent | Focus |
+|-------|-------|
+| R-correctness | Logic, edge cases, verify command result |
+| R-conventions | CONVENTIONS.md, test quality (F.I.R.S.T) |
+| R-security | Injection, auth, secrets (when `security-sensitive`) |
+| R-design | Simpler alternatives, API shape |
 
-Use the Agent tool with a completely fresh context. The agent prompt must be self-contained — no references to "our conversation" or "what we discussed."
+Santa Method still applies: each agent is blind; AND-gate uses Reviewer A + B scores. Fan-out agents feed findings into `respond-review` but do not replace the dual-blind pair.
+
+### 2b. Dispatch both reviewer agents (parallel)
+
+Use the Agent tool twice with completely fresh contexts. Each prompt must be self-contained — no references to "our conversation" or "what we discussed."
 
 ```
-You are a code reviewer. Review the following code changes.
+You are code reviewer [A|B]. Review the following code changes independently.
 
 Context: [feature description]
 CONVENTIONS.md rules: [paste relevant sections]
@@ -56,19 +95,22 @@ For each finding, categorize as: must-fix / should-fix / consider.
 Run the verify command and report the result.
 ```
 
-### 3. Collect the report
+### 3. Collect both reports
 
-When the reviewer returns:
-- Read every finding before acting on any
-- Note the verify command result
-- Compute the quality score: `100 × (total_items − must_fix − should_fix) / total_items`
-- Report the score to the user
+When reviewers return:
+- Read every finding from **both** reports before acting on any
+- Note each verify command result
+- Compute quality score per reviewer: `100 × (total_items − must_fix − should_fix) / total_items`
+- **AND-gate check:** both scores ≥ 94% and zero must-fix from **both**?
 
-> **HARD GATE** — If score < 94%, do NOT merge. Run `respond-review` to resolve must-fix and should-fix findings first. The 94% threshold also applies to the compliance SCORE computed by `npm run compliance` (scripts/audit-compliance.sh): SCORE = passing Gherkin scenarios / total × 100.
+> **HARD GATE** — If either score < 94% or either has must-fix → FAIL round. Run `respond-review` first. The 94% threshold also applies to `npm run compliance` (scripts/audit-compliance.sh).
 
 ### 4. Hand off to respond-review
 
-Pass the reviewer's report to `respond-review` to categorize findings and apply fixes.
+Pass combined findings to `respond-review` to categorize and apply fixes. Increment iteration counter. Re-dispatch both reviewers until AND-gate passes or iteration 3 exhausted.
+
+Report to user: "Review round [N/3]. Reviewer A: [score], Reviewer B: [score]. AND-gate: [PASS|FAIL]."
 
-Report to user: "Review complete. [N] findings: [X] must-fix, [Y] should-fix, [Z] consider. Running respond-review."
+## Verify
 
+→ verify: `grep -q 'AND-gate' skills/request-review/SKILL.md && grep -q 'max 3' skills/request-review/SKILL.md && echo OK`

package/skills/research-first/SKILL.md

@@ -5,6 +5,9 @@ model: sonnet
 effort: standard
 ---
 
+# story: e03s01
+# story: e21s02
+
 # Research First
 
 > **HARD GATE** — Do NOT implement until prior art is searched. Minimum outcome: adopt, extend, compose, or build — with evidence.

package/skills/run-benchmark/SKILL.md

@@ -1,9 +1,10 @@
 ---
 name: run-benchmark
-# story: e48s01
+# story: e45s01
 model: haiku
 effort: standard
 description: Run skill quality benchmarks from specs/benchmarks/ definitions — N-run with/without-skill delta grading, train/validation split, pass@k + benchmark.json reports. Use before and after evolve-skill to prove quality changes are improvements, not regressions.
+# story: e23s02
 ---
 
 # Run Benchmark
@@ -30,9 +31,9 @@ Benchmark definitions partition scenarios into two sets:
 ## Usage
 
 ```bash
-run-benchmark <skill-name>           # benchmark single skill
-run-benchmark --all                  # benchmark all with definitions
-run-benchmark <skill-name> --baseline # pin results as baseline
+bash scripts/run-benchmark.sh <skill-name>           # benchmark single skill
+bash scripts/run-benchmark.sh --all                  # benchmark all with definitions
+bash scripts/run-benchmark.sh <skill-name> --baseline # pin results as baseline
 ```
 
 ## Process