@codename_inc/spectre 5.0.0 → 5.2.0

package/plugins/spectre-codex/skills/execute/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: "execute"
-description: "👻 | Adaptive Wave-Based Build -> Code_Review -> Validate Flow"
+description: "👻 | Adaptive Wave-Based Build with Per-Wave Verification Gate"
 user-invocable: true
 ---
 
@@ -11,9 +11,9 @@ user-invocable: true
 Treat the current command arguments as this workflow's input. When invoked from a slash command, use the forwarded `$ARGUMENTS` value.
 
 
-# execute: Adaptive Task Execution with Quality Gates
+# execute: Adaptive Task Execution with Per-Wave Verification
 
-Execute tasks in parallel waves with full scope context, adapt based on learnings, code review loop, validate requirements. Outcome: complete implementation with verified quality and E2E requirement coverage.
+Execute tasks in parallel waves with full scope context, verify each wave before proceeding, adapt based on learnings, audit cross-wave integration, generate manual test guide. Outcome: complete implementation with verified quality and E2E requirement coverage.
 
 ## ARGUMENTS
 
@@ -39,7 +39,9 @@ $ARGUMENTS
 
   2. **Dispatch Wave**: Launch parallel @dev subagents (1 per task batch)
      - **CRITICAL**: Each subagent MUST read `SCOPE_DOCS` before executing
-     - Each receives: task batch assignment, dependency completion reports, SCOPE_DOCS paths
+     - Each receives: task batch assignment, SCOPE_DOCS paths, and (after wave 1) a **Prior-Wave Context** block
+     - **Prior-Wave Context** (REQUIRED in waves 2+): the orchestrator appends each prior wave's @dev Completion Reports verbatim into this wave's dispatch prompt under a `## Prior-Wave Context` header. Includes Completed tasks, Files changed, Scope signal, Discoveries, and Guidance from each prior batch. This is how state is carried forward — there is no separate state file.
+     - **Test discovery**: instruct @dev to use the project's native related-test command (`jest --findRelatedTests <file>`, `pytest` by path, `vitest related`, `cargo test <path>`). Do not create parallel test files for code already covered.
      - Instruct: "Read scope docs first to understand E2E UX and integration points. Load Skill(spectre-tdd), then execute tasks sequentially using its TDD methodology. **Commit after each parent task** with conventional commit format (e.g., `feat(module): add X`, `fix(module): resolve Y`). Return completion report with **Implementation Insights** + **E2E Completeness Check**."
 
      **E2E Completeness Check** (subagent returns one per batch):
@@ -47,15 +49,64 @@ $ARGUMENTS
      - 🟡 Gap — [specific functionality missing for E2E UX]
      - 🔴 Blocker — [cannot deliver spec without changes to other tasks]
 
-  3. **Mark Complete**: Update tasks doc with `[x]` for completed tasks
+  3. **Per-Wave Verification Gate**: Verify the wave's output before adapting or advancing.
 
-  4. **Reflect**: Review completion reports for:
+     **3a. Deterministic pre-gate (no AI)**
+     - Detect project commands from `package.json` / `pyproject.toml` / `Cargo.toml` / `Makefile`
+     - Run lint, typecheck, build — whichever apply
+     - If any fail: dispatch @dev to fix the failures, re-run the gate. Do NOT invoke @reviewer until all deterministic checks pass.
+
+     **3b. Parallel review lenses (single message, two @reviewer dispatches)**
+
+     Build each reviewer prompt from:
+     - Wave diff: `git diff <parent-of-first-wave-commit>..HEAD`
+     - Acceptance criteria: verbatim text from scope/tasks docs for this wave's tasks
+     - Files-touched manifest
+
+     **Forbidden in reviewer prompts**: @dev completion reports, implementer rationale, orchestrator paraphrase of "what the dev did and why". The reviewer is a clean room — diff + criteria only.
+
+     **Lens 1 — security + correctness**
+     - OWASP Top-10, injection, auth, secrets, data exposure
+     - Logic, edge cases, state transitions
+     - Scope adherence (flag only in-scope issues; do not flag missing out-of-scope work)
+
+     **Lens 2 — wiring**
+     - Apply the Defined → Connected → Reachable methodology:
+       - Defined: code exists in a file
+       - Connected: code is imported/called by other code
+       - Reachable: a user action can trigger the code path
+     - For each new function/component, grep for usage (not just definition)
+     - For UI features, trace render-backward: JSX ← variable ← source ← user action
+     - Flag dead computations (computed but never reach output) and old code paths still active when replaced
+
+     **Severity & evidence rule** (enforced in both lens prompts):
+     - Every CRITICAL or HIGH finding MUST include:
+       1. `file:line` reference
+       2. A reproducible failure scenario or exploit path describing observable behavior
+     - Findings without an evidence chain are auto-downgraded one severity level. "Could potentially" is not evidence.
+     - Each finding includes a hash: `sha256(file_path + line + finding_category)` for the fix-loop ledger (3c).
+
+     **3c. Bounded fix loop**
+
+     If lens dispatches return CRITICAL/HIGH:
+     - **Iteration cap**: 3 fix waves maximum
+     - **Hash ledger**: maintain a set of finding hashes addressed. If a finding with a hash already in the ledger reappears in a later review, classify as "reviewer disagreement" and escalate to user — do NOT re-queue.
+     - **Fix/test ratio**: monitor changes per fix wave. If test-file changes > 0.5 × implementation-file changes, halt and surface to user — likely "fixing the test instead of the bug."
+     - **Diff-growth circuit-breaker**: if cumulative fix-wave diff grows > 25% per iteration, halt and surface — fixes are adding surface area, not reducing it.
+     - **Dispatch fix**: parallel @dev subagents address each CRITICAL/HIGH finding. Each fix-dev receives the finding's full evidence chain (file:line + scenario), not just the description.
+     - **Re-verify**: after fixes commit, return to 3a (deterministic) then 3b (lenses).
+
+     **3d. Exit condition**: No CRITICAL/HIGH remain, OR iteration cap reached and user has been notified of unresolved findings.
+
+  4. **Mark Complete**: Update tasks doc with `[x]` for completed tasks
+
+  5. **Reflect**: Review completion reports for:
      - Scope signals (🟡/🟠/🔴) from implementation insights
      - E2E completeness gaps (🟡/🔴) from completeness checks
-     - **If** all ⚪ across both → skip to step 6
+     - **If** all ⚪ across both → skip to step 7
      - **Else** → adapt tasks
 
-  5. **Adapt** (only if triggered):
+  6. **Adapt** (only if triggered):
      - Modify future tasks with learned context
      - Add tasks for E2E gaps with `[ADDED - E2E gap]` prefix
      - Add required sub-tasks with `[ADDED]` prefix
@@ -63,34 +114,28 @@ $ARGUMENTS
      - Flag cross-task integration issues to remaining waves
      - **Guardrails**: ❌ No "nice-to-have" additions, ❌ No scope expansion, ✅ Only adapt for spec compliance
 
-  6. **Next Wave**: Identify next tasks, gather relevant completion reports, return to step 1
-
-## Step 2 - Code Review Loop
-
-- **Action** — ExecutedeveviewLoop: Until no critical/high feedback:
+  7. **Next Wave**: Identify next tasks, gather prior-wave completion reports for the Prior-Wave Context block, return to step 1
 
-  1. **Spawn Review**: @dev subagent runs `Skill(code_review)` (Claude slash route: `code_review`)
-  2. **Analyze**: Identify critical/high items
-     - **If** none → exit loop
-  3. **Address**: Parallel @dev subagents fix feedback
-  4. **Re-verify**: Return to step 1
+## Step 2 - Cross-Wave Validate
 
-## Step 3 - Validate Requirements
+- **Action** — SpawnValidation: @analyst runs `Skill(validate)` (Claude slash route: `validate`) with **narrowed scope**:
+  - Focus: cross-wave integration audit (did later waves silently break earlier waves' wiring?) + scope-creep audit (anything implemented that is NOT in the acceptance criteria?) + dead-computation sweep across the full cumulative diff
+  - Skip: per-area wiring verification (already done per-wave in Step 1.3b's wiring lens)
 
-- **Action** — SpawnValidation: @reviewer runs `Skill(validate)` (Claude slash route: `validate`) with task list
-- **Action** — AddressGaps: If high priority gaps → dispatch @dev subagents to fix
+- **Action** — AddressGaps: If high priority gaps surface → dispatch @dev subagents to fix.
 
-## Step 4 - Prepare for QA
+## Step 3 - Prepare for QA
 
 - **Action** — GenerateTestGuide: @dev runs `Skill(create_test_guide)` (Claude slash route: `create_test_guide`)
   - Save to `{OUT_DIR}/test_guide.md`
 
-## Step 5 - Report
+## Step 4 - Report
 
 - **Action** — SummarizeCompletion:
-  - Tasks completed, waves executed, code review iterations, validation status
+  - Tasks completed, waves executed, per-wave fix-loop iteration counts, validation status
   - Test guide location
   - **Task Evolution Summary**: Adaptations made (or "None - original plan executed")
   - **E2E Gaps Addressed**: Summary of completeness issues found and resolved
+  - **Unresolved Findings** (if any): Any CRITICAL/HIGH that hit the fix-loop cap and were escalated to user
 
 - **Action** — RenderFooter: Use `Skill(spectre-guide)` skill for Next Steps

package/plugins/spectre-codex/skills/plan/SKILL.md

@@ -49,9 +49,11 @@ Treat the current command arguments as this workflow's input. When invoked from
   - `OUT_DIR=docs/tasks/{branch_name}` (or user-specified)
   - `mkdir -p "${OUT_DIR}"`
 
-- **Action** — ScanExistingContext: Read all existing artifacts in `{OUT_DIR}/ (if you haven’t already)` and assess coverage across 4 dimensions.
+- **Action** — ScanExistingContext: Read all existing artifacts in `{OUT_DIR}/ (if you haven't already)` and assess coverage across 4 dimensions.
 
-  Scan for: `task_context.md`, `specs/plan.md`, `concepts/scope.md`, `research/*.md`
+  Scan for: `task_context.md`, `specs/plan.md`, `concepts/scope.md`, `specs/ux.md`, `research/*.md`
+
+  While scanning `concepts/scope.md` and `specs/ux.md`, extract any **filled assumptions** — places where the upstream artifact defaulted a value because the user didn't specify (e.g., DB choice, retry policy, copy variants, segment fallbacks). Carry these forward to Step 3's design surface so they're reviewer-visible before plan generation.
 
   | Dimension | Covered if artifact contains... | Covered by |
   | --- | --- | --- |
@@ -95,13 +97,26 @@ Use research findings from Step 1 to determine appropriate planning depth.
   | Integration points | Research findings | Internal only = Low, 1-2 external = Med, 3+ external = High |
   | External complexity | @web-research | Well-documented with libraries = Low, Some prior art = Med, Novel/emerging = High |
 
-- **Action** — CheckHardStops: Any true = automatic COMPREHENSIVE | db_schema_destructive | new_service_or_component | auth_or_pii_change | | payment_billing_logic | public_api_change | caching_consistency | slo_sla_risk |
+- **Action** — CheckHardStops: Any true = automatic COMPREHENSIVE.
+  - `db_schema_destructive` — drops, renames, or non-additive column changes
+  - `data_migration_required` — backfill, transform, or row-by-row data change
+  - `new_service_or_component` — net-new service, daemon, or top-level component
+  - `auth_or_pii_change` — authn/authz flow, session handling, PII storage/exposure
+  - `secrets_or_credentials_handling` — new secret introduced, rotation, or boundary change
+  - `payment_billing_logic` — money flow, invoicing, charge logic
+  - `public_api_change` — externally-consumed API surface modified
+  - `concurrent_writes_or_locking` — concurrency, locking, or distributed coordination
+  - `caching_consistency` — cache invalidation, staleness windows, multi-tier caching
+  - `cross_service_or_cross_workspace_change` — coordinated change across services or workspaces
+  - `slo_sla_risk` — latency, throughput, or availability budget at stake
+
+- **Action** — DetermineTier (decisive rules, not point-scoring):
 
-- **Action** — DetermineTier:
+  - **COMPREHENSIVE** — if ANY hard-stop is triggered OR any signal scores High OR two or more signals score Medium
+  - **STANDARD** — if no hard-stops AND no High signals AND at most one Medium signal
+  - **LIGHT** — only if every signal scores Low AND no hard-stops AND the change is plausibly a single-file diff
 
-  - **LIGHT**: All/most Low signals, single component, clear pattern match, no hard-stops
-  - **STANDARD**: Mix of Low/Med signals, multi-file but contained scope, no hard-stops
-  - **COMPREHENSIVE**: Any High signal, multiple Med signals, or any hard-stop triggered
+  When in doubt between two tiers, choose the higher. The cost of over-planning a small change is hours; the cost of under-planning a large one is weeks.
 
 - **Action** — LogTier: Note the assessed tier in your response for transparency, then proceed immediately to the next step. Do NOT ask for confirmation.
 
@@ -129,6 +144,14 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
   > - [decision] — [rationale; alternative considered]
   > - [decision] — [rationale; alternative considered]
   >
+  > **How we'll know it works** (verification spine):
+  > - [change] → [test name | observable behavior | state condition]
+  > - [change] → [test name | observable behavior | state condition]
+  >
+  > **Filled assumptions** (surfaced from scope.md / ux.md / inferred):
+  > - [assumption] — *source: [scope.md / ux.md / default]*
+  > - [assumption] — *source: [scope.md / ux.md / default]*
+  >
   > **Open questions** (with default assumption):
   > 1. [question] — *default: [assumption]*
   > 2. [question] — *default: [assumption]*
@@ -138,6 +161,8 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
   **CRITICAL**:
   - **Single proposed approach**, not a menu. If a true fork exists, surface it as an open question with your recommendation — not as parallel options.
   - Stay at the *shape* level: components, key decisions, structural changes. Defer file-by-file detail to `create_plan`.
+  - **Verification is mandatory.** Every major change in the approach must declare how it will be checked — falsifiable signal, not prose. This becomes the spine that `create_plan` and `create_tasks` build on.
+  - **Filled assumptions are mandatory.** If scope.md or ux.md left something silent and you defaulted it, surface the default here. Reviewer-visible by design — these are the silent decisions that bite at execution.
   - Open questions should be specific and answerable; pair each with a default assumption so the user can skip if the default is fine.
 
 - **Action** — IterateDesign: If the user replies with answers, edits, or pushback, update the design and re-present. Loop until user says 'looks good' (or equivalent).
@@ -208,4 +233,24 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 
 ---
 
+### Post-Tasks Tier Re-check
+
+After tasks return, do a fast self-check against tier signals:
+
+- Count parent tasks, sub-tasks, files touched (sum of unique paths in Context blocks), and Phase 0 dep count.
+- **Escalation triggers** (any true → recommend re-running at a higher tier):
+  - Tier was LIGHT but tasks touch >3 files OR have >2 parent tasks
+  - Tier was STANDARD but tasks reveal a hard-stop signal not caught earlier (e.g., a migration sub-task appeared)
+  - Tasks contain any Out-of-Bounds violation
+- **Downgrade triggers** (rare; only suggest if confident):
+  - Tier was COMPREHENSIVE but tasks collapsed to a single parent with no migrations, no new components, and no API change
+
+If an escalation/downgrade is triggered, surface it as a recommendation — do NOT silently re-run. Format:
+
+> Tier reassessment: I planned this as {original tier}, but tasks revealed {signal}. Recommend re-running as {new tier}. Reply 'rerun' to regenerate or 'keep' to proceed as-is.
+
+Only proceed past this checkpoint when the user confirms.
+
+---
+
 - **Action** — RenderFooter: Use `Skill(spectre-guide)` skill for Next Steps

package/plugins/spectre-codex/skills/plan_review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: "plan_review"
-description: "👻 | Find simplifications in a plan or tasks"
+description: "👻 | Independent multi-lens review of plan.md + tasks.md — finds overengineering, missing verification, hallucinated deps, weak references"
 user-invocable: true
 ---
 
@@ -10,33 +10,174 @@ user-invocable: true
 
 Treat the current command arguments as this workflow's input. When invoked from a slash command, use the forwarded `$ARGUMENTS` value.
 
+# plan_review: Multi-Lens Review of Plan & Tasks
 
-You are a senior staff engineer with deep expertise in system design, architecture, and pragmatic problem-solving. Your specialty is finding the simplest path to meet all requirements.
+## Description
 
-Review the following [plan/document/tasks/context] and identify opportunities to simplify while ensuring all requirements and functionality are delivered.
+- **What** — Independent review of `plan.md` + `tasks.md` from four specialized lenses, dispatched in parallel
+- **Outcome** — Structured findings with concrete edit suggestions; optional write-back to update both artifacts
+- **Role** — Senior staff engineer + reviewer panel; bias toward pragmatic problem-solving, YAGNI enforcement, and verifiability
 
-For each simplification opportunity, provide:
-1. **What to simplify** - Specific component, process, or decision
-2. **Why** - What complexity it removes (cognitive load, dependencies, maintenance burden, etc.)
-3. **Impact** - Confirm that all original requirements remain satisfied
-4. **Risk** - Any trade-offs or risks introduced by the simplification
+## ARGUMENTS Input
 
-Focus on:
-- Removing unnecessary abstractions or indirection
-- Consolidating duplicated logic or patterns
-- Questioning assumptions that add complexity
-- Identifying over-engineering
-- Suggesting proven, boring solutions over novel approaches
+<ARGUMENTS>
+$ARGUMENTS
+</ARGUMENTS>
 
-## Testing Review
-**Context**: We use fast TDD with 1 happy path test + 1 unhappy path test per feature. A separate task handles achieving 100% test coverage post-feature work.
+## Why Four Lenses
 
-Evaluate the testing approach and flag:
-- **Over-testing**: Tests beyond 1 happy + 1 unhappy path that should be deferred to the coverage task
-- **Wrong tests**: Testing implementation details instead of behavior, brittle tests that will break on refactors, or tests that don't actually validate requirements
-- **Missing critical paths**: Cases where the 1+1 approach genuinely misses a requirement-breaking scenario (rare, but call it out)
-- **Test complexity**: Overly elaborate test setup, mocking, or assertions that could be simpler
+A single reviewer biases toward the issues it notices first. Published practice (Cognition, Anthropic, Osmani) converges on four high-yield review angles for AI-agent-authored plans. We dispatch each as a parallel subagent so coverage is structurally guaranteed, not dependent on a single reviewer remembering everything.
 
-Remember: The goal is fast feedback during development. More comprehensive testing comes later.
+| Lens | Subagent | Finds |
+|------|----------|-------|
+| **YAGNI / familiar-shape bias** | `@reviewer` | Mature-system patterns that crept in unprompted (auth → rate-limit, CRUD → soft-delete, etc.). Forces ONE "delete this" recommendation. |
+| **Verifiability** | `@analyst` | Acceptance criteria that aren't executable; verification gaps between plan and tasks. |
+| **Existence / hallucination** | `@finder` | File paths, packages, APIs, or symbols referenced that don't actually exist. The slopsquatting fence. |
+| **Canonical reference quality** | `@patterns` | "Follow existing pattern" claims without a real file:line anchor; missed reuse opportunities. |
 
-End with a prioritized list of recommendations (high/medium/low impact).
+## Step 1 — Locate Artifacts
+
+- **Action** — DetermineTaskDir:
+  - `branch_name=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo unknown)`
+  - **If** user specifies path in ARGUMENTS → `TASK_DIR={that value}`
+  - **Else** → `TASK_DIR=docs/tasks/{branch_name}`
+
+- **Action** — ResolveArtifacts: Locate the three required inputs.
+  - `PLAN=${TASK_DIR}/specs/plan.md` (or scoped name)
+  - `TASKS=${TASK_DIR}/specs/tasks.md` (or scoped name)
+  - `CONTEXT=${TASK_DIR}/task_context.md`
+  - If any are missing, list what's missing and stop — do NOT review against a partial set. Suggest the user run `plan` or `create_tasks` first.
+
+- **Action** — ReadAll: Read each file completely into context before dispatching reviewers. Reviewers receive curated excerpts, not raw paths.
+
+## Step 2 — Dispatch Four Parallel Reviewers
+
+Spawn all four subagents in a single message (parallel). Each receives the same artifact excerpts but a different review brief.
+
+### Lens 1 — YAGNI / Familiar-Shape Bias (`@reviewer`)
+
+> Review this plan and task list for unrequested complexity. Agents have a documented "familiar-shape bias": shown a feature, they reproduce the mature-system shape from their training data (auth → adds rate-limiting; CRUD → adds soft-delete; form → adds optimistic UI; service → adds telemetry; module → adds feature flags). Your job is to find that bias here.
+>
+> Find:
+> 1. Anything in `plan.md` Technical Approach that isn't traceable to a requirement in `task_context.md` / scope / PRD.
+> 2. Tasks in `tasks.md` that implement something the requirements don't ask for.
+> 3. Abstractions, interfaces, or layers introduced for a single concrete caller.
+> 4. Generality (config files, plugin points, factories) where the actual need is one specific behavior.
+> 5. Overlap with the `Out-of-Bounds — DO NOT add` list (if anything violates that list, it's a hard fail).
+>
+> Required output: nominate the SINGLE highest-leverage thing to delete and justify it. You must pick one. Then list other simplifications ranked by impact. For each finding, cite the exact file:line or section header it lives in.
+
+### Lens 2 — Verifiability (`@analyst`)
+
+> Review this plan and task list for verification quality. The single highest-correlate of successful AI-agent execution is the ability to self-verify. Find every place where verification is missing, prose-only, or disconnected.
+>
+> Find:
+> 1. Items in `plan.md` "Verification — How We Know This Works" that are prose ("works correctly", "is consistent") rather than executable (test name / observable behavior / state condition).
+> 2. Phases in `plan.md` that don't declare a verification signal.
+> 3. Sub-tasks in `tasks.md` whose acceptance criteria aren't one of the three executable types (test passes / observable behavior / state condition).
+> 4. Verification signals in `plan.md` with no matching acceptance criterion in `tasks.md`.
+> 5. Behavior-changing sub-tasks in `tasks.md` that lack a preceding RED test sub-task.
+>
+> Required output: list every non-executable criterion with a proposed rewrite in one of the three types. Cite file:line for each.
+
+### Lens 3 — Existence / Hallucination (`@finder`)
+
+> Review this plan and task list for references to things that may not exist. AI-generated plans hallucinate file paths, package names, function signatures, and API endpoints at measurable rates (~20% for packages per Snyk analysis). Your job is to verify every reference is real.
+>
+> Verify:
+> 1. Every file path mentioned in `plan.md` "Critical Files for Implementation" and in `tasks.md` Context blocks — does the file exist in the repo today? Use Glob/Read to confirm.
+> 2. Every package in `plan.md` "External Dependencies" — does it exist at the named version? (Note: actual install/registry check is the executor's Phase 0 job; your job is to flag suspicious names — typos, near-misses to well-known packages, lookalikes.)
+> 3. Every function, class, or symbol named in plan/tasks — grep the repo, confirm it exists where claimed.
+> 4. Every API endpoint, env var, or CLI flag referenced — confirm it's defined in the codebase.
+>
+> Required output: list every reference that fails verification, with `expected: <plan claim>` and `actual: <repo state>`. If everything checks out, say so explicitly — don't pad.
+
+### Lens 4 — Canonical Reference Quality (`@patterns`)
+
+> Review this plan and task list for the quality of "follow existing pattern" references. Anthropic's own guidance is to anchor plans with concrete examples (e.g., "HotDogWidget.php is a good example"). Vague "follow existing patterns" without a file:line anchor is a documented failure mode.
+>
+> Find:
+> 1. Places in `plan.md` Technical Approach that reference "existing patterns" or "similar features" without a specific file:line.
+> 2. Sub-tasks in `tasks.md` whose Context block lacks a canonical reference pointer.
+> 3. Better canonical references that the plan missed — actual files in the codebase that more closely match the intended shape.
+> 4. Reuse opportunities the plan ignored: utilities, hooks, helpers, or types already in the repo that the plan re-implements.
+>
+> Required output: for each weak/missing reference, propose a specific file:line that should be the anchor. For each missed reuse, cite the existing utility and which task should use it.
+
+## Step 3 — Synthesize Findings
+
+- **Action** — CollectFindings: Wait for all four reviewers to return. Read every finding.
+
+- **Action** — DeduplicateAndPrioritize: Merge findings that overlap (e.g., a missing canonical reference may surface from both Lens 4 and Lens 2). Assign severity:
+  - **Blocker** — would cause execution to fail or produce wrong output (hallucinated file path, criterion the executor can't check, Out-of-Bounds violation)
+  - **High** — meaningfully reduces output quality (missing RED test, weak canonical reference, prose criterion)
+  - **Medium** — overengineering or reuse miss without functional blast radius
+  - **Low** — stylistic or nice-to-have
+
+- **Action** — RenderFindingsTable: Output a single structured table. Schema is fixed.
+
+  ```markdown
+  ## Review Findings — {feature name}
+
+  ### Must-Delete (Lens 1 — YAGNI)
+  > {The single nominated highest-leverage cut, with rationale.}
+
+  ### Findings
+
+  | # | Severity | Lens | Location | Finding | Suggested Edit |
+  |---|----------|------|----------|---------|----------------|
+  | 1 | Blocker  | Existence | plan.md `## External Dependencies` | `react-use-undocumented@2.4.0` doesn't exist on npm | Remove; the plan can use `useReducer` from React stdlib (see `src/hooks/useFormState.ts:18`) |
+  | 2 | High     | Verifiability | tasks.md `1.2.1` | "Component renders correctly" is prose | Replace with: Test passes `<ProductCard /> renders product.title and product.price` |
+  | 3 | High     | YAGNI | plan.md `## Technical Approach` | Adds retry-with-backoff for a sync internal call | Delete; not in requirements; Out-of-Bounds list already forbids retry logic |
+  | … |          |       |          |         |                |
+
+  ### Summary
+  - Blockers: {N} — must resolve before /execute
+  - High: {N}
+  - Medium: {N}
+  - Low: {N}
+  ```
+
+## Step 4 — Surface Findings & Apply Edits
+
+- **Action** — PresentFindings: Render the findings table inline.
+
+- **Action** — OfferWriteBack: After the table, prompt:
+
+  > Reply with which findings to apply:
+  > - `all` — apply every suggested edit
+  > - `blockers` — apply Blocker + High severity only
+  > - `1,3,5` — apply specific finding numbers
+  > - `skip` — leave artifacts unchanged
+  >
+  > For findings I apply, I'll edit plan.md and/or tasks.md inline and re-run a fast self-check.
+
+- **Wait** — User selects.
+
+- **Action** — ApplyEdits: For each selected finding:
+  - Open the named artifact (plan.md or tasks.md)
+  - Apply the Suggested Edit verbatim where possible; if the edit needs adaptation, make the minimum change consistent with the finding's intent
+  - Track which findings were applied
+
+- **Action** — SelfCheck: After edits, run a fast pass over the modified sections:
+  - Re-verify any file:line refs touched
+  - Re-verify acceptance criteria are still executable
+  - Confirm no edit introduced a new Out-of-Bounds violation
+  - If any check fails, surface it and ask the user before continuing
+
+- **Action** — ReportApplied:
+
+  > Applied: {list of finding numbers}. Skipped: {list}.
+  > {Path to updated plan.md and tasks.md}.
+
+## Step 5 — Next Steps
+
+- **Action** — RenderFooter: Use `Skill(spectre-guide)` skill for Next Steps footer.
+
+---
+
+## Notes
+
+- This skill does NOT generate plans or tasks. It reviews them. If `plan.md` or `tasks.md` doesn't exist, route the user to `plan` first.
+- The four lenses are intentionally non-overlapping by design but will surface overlap in practice — dedupe at synthesis, don't ask reviewers to coordinate.
+- The "Must-Delete" nomination from Lens 1 is mandatory output — even on a tight plan, naming the single weakest element is a forcing function against under-review.