specweave 1.0.550 → 1.0.552

package/plugins/specweave/skills/done/SKILL.md

@@ -11,7 +11,7 @@ argument-hint: "<increment-id> [--auto]"
 
 **PM-Led Closure**: Validate tasks, tests, and docs before closing.
 
-**AUTO-CLOSURE DEFAULT**: After `sw:do` completes all tasks, `sw:done` runs automatically — no user confirmation needed. Quality gates (grill, judge-llm, PM validation) provide the safety net. If something is wrong, the user can re-open the increment.
+**AUTO-CLOSURE DEFAULT**: After `sw:do` completes all tasks, `sw:done` runs automatically — no user confirmation needed. Quality gates (code-review, simplify, grill, judge-llm, PM validation) provide the safety net. If something is wrong, the user can re-open the increment.
 
 ## Context Overflow Prevention
 
@@ -31,7 +31,7 @@ Argument: Required increment ID (e.g., "001", "0001", "0042", "0153-feature-name
 
 | Option | Description |
 |--------|-------------|
-| `--auto` | Legacy flag, now a no-op. Auto-closure is the default for all modes. All quality gates (grill, judge-llm, Gate 0, PM gates) always enforced. |
+| `--auto` | Legacy flag, now a no-op. Auto-closure is the default for all modes. All quality gates (code-review, simplify, grill, judge-llm, Gate 0, PM gates) always enforced. |
 
 ---
 
@@ -41,18 +41,53 @@ Argument: Required increment ID (e.g., "001", "0001", "0042", "0153-feature-name
 
 If closing a SpecWeave framework increment, show post-closure reminders: update CHANGELOG.md, CLAUDE.md, consider version bump, run `npm test && npm run rebuild`, check for breaking changes. Informational only, not blocking.
 
-### Step 2: Inline Grill Review (MANDATORY — STOP GATE)
+### Step 2: Code Review (MANDATORY — STOP GATE with Fix Loop)
+
+**The CLI blocks closure if `code-review-report.json` is missing (when required).** Do NOT skip this step.
+
+1. Check config: `jq -r '.codeReview.required // true' .specweave/config.json` — if `false`, skip to Step 3
+2. Read max iterations: `MAX_ITER=$(jq -r '.codeReview.maxFixIterations // 3' .specweave/config.json 2>/dev/null)`
+3. Read blocking severities: defaults are `critical`, `high`, `medium` (configurable via `codeReview.blockingSeverities`)
+4. **Iteration loop** (ITERATION=1):
+   a. Invoke `Skill({ skill: "sw:code-reviewer", args: "--increment <id>" })`
+   b. **Verify report written**: `Bash({ command: "test -f .specweave/increments/<id>/reports/code-review-report.json && echo OK || echo MISSING" })`
+   c. If report MISSING: write it manually from code-reviewer output using the Write tool
+   d. Read the report JSON: parse the `summary` object for severity counts
+   e. **Evaluate blocking findings**: Sum counts for `critical` + `high` + `medium` (or configured severities)
+   f. If no blocking findings → PASS, continue to Step 3
+   g. If blocking findings exist AND ITERATION < MAX_ITER:
+      - Display findings summary
+      - Implement fixes for all critical/high/medium issues from the report
+      - Increment ITERATION
+      - Delete the stale report: `rm -f .specweave/increments/<id>/reports/code-review-report.json`
+      - Go back to step 4a (re-run code-reviewer)
+   h. If blocking findings exist AND ITERATION >= MAX_ITER:
+      - **STOP closure** — display remaining findings
+      - Log: "Code review failed after {N} fix iterations. {X} findings remain."
+      - Increment stays in-progress
+
+### Step 3: Simplify (Non-Blocking Cleanup)
+
+Code review passed. Run simplify to clean up code before the grill examines it.
+
+1. Invoke `Skill({ skill: "simplify" })` — this is a built-in Claude Code skill, NOT a `sw:` skill
+2. `/simplify` spawns 3 parallel agents checking: duplication, readability, efficiency
+3. Apply any suggested improvements
+4. **Non-blocking**: Even if simplify finds issues, proceed to Step 4 (Grill)
+5. Purpose: Clean code before grill reduces grill findings and improves ship readiness
+
+### Step 4: Inline Grill Review (MANDATORY — STOP GATE)
 
 **The CLI blocks closure if `grill-report.json` is missing.** Do NOT skip this step.
 
-1. Check config: `jq -r '.grill.required // true' .specweave/config.json` — if `false`, skip to Step 3
+1. Check config: `jq -r '.grill.required // true' .specweave/config.json` — if `false`, skip to Step 5
 2. Invoke `Skill({ skill: "sw:grill" })` with incrementId
 3. **Verify report written**: `Bash({ command: "test -f .specweave/increments/<id>/reports/grill-report.json && echo OK || echo MISSING" })`
 4. If report MISSING: write it manually from grill output using the Write tool
 5. BLOCKERs or CRITICALs (shipReadiness: NOT READY) → STOP closure, ask user to fix
 6. Passes → continue
 
-### Step 3: Judge LLM Validation (MANDATORY — STOP GATE)
+### Step 5: Judge LLM Validation (MANDATORY — STOP GATE)
 
 **A report file MUST be written regardless of outcome (even WAIVED if consent denied).**
 
@@ -63,21 +98,21 @@ If closing a SpecWeave framework increment, show post-closure reminders: update
 5. **APPROVED** → continue | **CONCERNS** → show, allow continuation | **REJECTED** → STOP closure
 6. No ANTHROPIC_API_KEY or consent denied → write WAIVED report, continue
 
-### Step 4: Status Validation
+### Step 6: Status Validation
 
 - `ready_for_review` -> Proceed
 - `active` -> Check all tasks done, transition to `ready_for_review` first
 - `completed` -> Already closed, warn user
 - `backlog` / `paused` / `abandoned` -> BLOCK with error
 
-**No confirmation needed**: Proceed directly to closure. Quality gates (grill, judge-llm, Gate 0, PM gates) are the safety net — NOT user confirmation prompts. NEVER stop to ask "should I close this?" — just close it. If a gate fails, the increment stays open automatically. If the user disagrees with closure, they can re-open.
+**No confirmation needed**: Proceed directly to closure. Quality gates (code-review, simplify, grill, judge-llm, Gate 0, PM gates) are the safety net — NOT user confirmation prompts. NEVER stop to ask "should I close this?" — just close it. If a gate fails, the increment stays open automatically. If the user disagrees with closure, they can re-open.
 
-### Step 5: Load Increment Context
+### Step 7: Load Increment Context
 
 1. Find increment directory: normalize ID to 4-digit, match `.specweave/increments/0001-*/`
 2. Load: `spec.md`, `plan.md`, `tasks.md`, `tests.md`
 
-### Step 6: Automated Completion Validation (Gate 0)
+### Step 8: Automated Completion Validation (Gate 0)
 
 MANDATORY, cannot be bypassed. Runs BEFORE PM validation.
 
@@ -94,7 +129,7 @@ MANDATORY, cannot be bypassed. Runs BEFORE PM validation.
 
 If validation fails -> increment stays in-progress, command exits.
 
-### Step 7: PM Validation (3 Gates)
+### Step 9: PM Validation (3 Gates)
 
 PM validation report goes in: `.specweave/increments/####-name/reports/PM-VALIDATION-REPORT.md`
 
@@ -106,11 +141,11 @@ PM validation report goes in: `.specweave/increments/####-name/reports/PM-VALIDA
 
 **Gate 3 - Documentation Updated**: CLAUDE.md, README.md, CHANGELOG.md updated as needed. Inline docs complete. No stale references.
 
-### Step 8: PM Decision
+### Step 10: PM Decision
 
 **All gates pass**:
 1. Create marker file: `mkdir -p .specweave/state && touch .specweave/state/.sw-done-in-progress`
-2. Run completion via CLI: `Bash({ command: "specweave complete <id> --yes" })` — the CLI re-verifies quality gate reports (grill-report.json, judge-llm-report.json) exist. It also triggers `LifecycleHookDispatcher.onIncrementDone()` for living docs sync, GitHub Project sync, and issue closure.
+2. Run completion via CLI: `Bash({ command: "specweave complete <id> --yes" })` — the CLI re-verifies quality gate reports (code-review-report.json, grill-report.json, judge-llm-report.json) exist. It also triggers `LifecycleHookDispatcher.onIncrementDone()` for living docs sync, GitHub Project sync, and issue closure.
 3. Remove marker file: `rm -f .specweave/state/.sw-done-in-progress`
 4. Generate completion report, update backlog
 
@@ -121,7 +156,7 @@ PM validation report goes in: `.specweave/increments/####-name/reports/PM-VALIDA
 - If GitHub issue exists, reopen it with failure details
 - Increment remains in-progress
 
-### Step 8.5: Pull Request Creation (pr-based only)
+### Step 10.5: Pull Request Creation (pr-based only)
 
 Check push strategy:
 ```bash
@@ -136,9 +171,9 @@ PUSH_STRATEGY=$(jq -r '.cicd.pushStrategy // "direct"' .specweave/config.json 2>
 
 **If `direct`:** Skip this step entirely (existing behavior unchanged).
 
-### Step 9: Post-Closure Sync (AUTOMATIC via CLI hooks)
+### Step 11: Post-Closure Sync (AUTOMATIC via CLI hooks)
 
-The `specweave complete` call in Step 8 triggers `LifecycleHookDispatcher.onIncrementDone()` which automatically handles:
+The `specweave complete` call in Step 10 triggers `LifecycleHookDispatcher.onIncrementDone()` which automatically handles:
 
 - **Living docs sync** (`sync_living_docs` flag): Updates feature specs and user story files
 - **GitHub Project sync** (`sync_to_github_project` flag): Pushes spec to GitHub Project
@@ -166,22 +201,22 @@ If any operation failed, display: "Run `sw:progress-sync` to retry failed sync o
 3. For EACH user story in spec.md, search: `gh issue list -R {owner}/{repo} --search "[{feature_id}][{us_id}]" --state open --json number`
 4. Close each: `gh issue close {number} -R {owner}/{repo} -c "Completed as part of increment {increment_id}"`
 
-### Step 10: Sync Living Docs (MANDATORY)
+### Step 12: Sync Living Docs (MANDATORY)
 
 Execute: `Skill({ skill: "sw:sync-docs" })` with the increment ID. Do NOT just mention it -- actually invoke it. This serves as a verification pass to confirm living docs are up to date after closure.
 
-### Step 10b: Update Links in Docs (MANDATORY)
+### Step 12b: Update Links in Docs (MANDATORY)
 
 After living docs sync, update cross-references and bidirectional links so existing docs reference the newly created feature specs. Do NOT skip this step:
 
-1. Read the feature spec files created by Step 10 (`.specweave/docs/internal/specs/{project}/FS-XXX/FEATURE.md` and `us-*.md`)
+1. Read the feature spec files created by Step 12 (`.specweave/docs/internal/specs/{project}/FS-XXX/FEATURE.md` and `us-*.md`)
 2. Update existing docs (FEATURE-CATALOG, module docs, etc.) with links to the new specs
 3. Verify bidirectional links between increment → feature spec → living docs
 4. Change `[DRAFT]` → `[COMPLETE]` on doc sections matching completed ACs
 
-Verify that `.specweave/docs/internal/specs/{project}/FS-XXX/` contains `FEATURE.md` and `us-*.md` files. If missing, re-run Step 10.
+Verify that `.specweave/docs/internal/specs/{project}/FS-XXX/` contains `FEATURE.md` and `us-*.md` files. If missing, re-run Step 12.
 
-### Step 11: Post-Closure Quality Assessment
+### Step 13: Post-Closure Quality Assessment
 
 Runs ONLY if closure succeeded. Invoke: `sw:qa ${incrementId}`
 
@@ -195,7 +230,7 @@ Report saved to: `.specweave/increments/####/reports/qa-post-closure.md`
 
 Quality assessment runs AFTER closure (not blocking delivery). Critical issues trigger follow-up increment creation.
 
-### Step 12: Handle Incomplete Work
+### Step 14: Handle Incomplete Work
 
 If scope creep detected, offer options:
 - A) Complete all tasks (estimate effort)

package/plugins/specweave/skills/grill/SKILL.md

@@ -360,7 +360,7 @@ Then write the report using the Write tool:
 
 ## Integration with sw:done
 
-`sw:done` calls `sw:grill` as Step 2 (blocking gate). The CLI re-verifies `grill-report.json` exists when running `specweave complete`.
+`sw:done` calls `sw:grill` as Step 4 (blocking gate), after code-review (Step 2) and simplify (Step 3). The CLI re-verifies `grill-report.json` exists when running `specweave complete`.
 
 You can also run `sw:grill` standalone at any time for early feedback.
 

package/plugins/specweave/skills/team-lead/agents/reviewer-logic.md

@@ -1,6 +1,8 @@
 You are the LOGIC REVIEWER agent.
 
 REVIEW TARGET: [REVIEW_TARGET]
+PR TITLE: [PR_TITLE]
+PR DESCRIPTION: [PR_DESCRIPTION]
 
 MISSION:
   Examine the target code for correctness, logic bugs, edge cases, error handling gaps,
@@ -61,3 +63,20 @@ RULES:
   - No speculation: only report issues you can demonstrate with concrete reasoning
   - Consider context: understand the function's purpose before flagging issues
   - Test coverage: note if critical paths lack test coverage
+
+DO NOT FLAG (universal):
+  - Style/formatting issues (spacing, brace style, trailing commas) — linters handle these
+  - Issues in auto-generated code (prisma client, graphql codegen, protobuf stubs)
+  - Issues in vendored/third-party code (node_modules, vendor/)
+  - Issues in test fixtures or mock data
+  - Pre-existing issues in unchanged lines (unless CRITICAL severity)
+  - Subjective preferences ("I would have done X differently")
+  - Potential issues requiring specific runtime state you cannot verify
+  - Missing features not part of the review scope
+
+DO NOT FLAG (logic-specific):
+  - Intentional fallthrough in switch statements (when commented)
+  - Defensive programming patterns that appear redundant but add safety
+  - Algorithm choices that are correct but not optimal (performance reviewer handles those)
+  - Missing error handling in test files
+  - Type narrowing patterns that look unusual but are TypeScript-correct

package/plugins/specweave/skills/team-lead/agents/reviewer-performance.md

@@ -1,6 +1,8 @@
 You are the PERFORMANCE REVIEWER agent.
 
 REVIEW TARGET: [REVIEW_TARGET]
+PR TITLE: [PR_TITLE]
+PR DESCRIPTION: [PR_DESCRIPTION]
 
 MISSION:
   Examine the target code for performance anti-patterns, scalability issues,
@@ -61,3 +63,21 @@ RULES:
   - Quantify when possible: "This loop is O(n²) over user.orders" is better than "slow loop"
   - Consider scale: what works for 100 users may break at 10,000
   - No premature optimization: only flag issues with measurable impact
+
+DO NOT FLAG (universal):
+  - Style/formatting issues (spacing, brace style, trailing commas) — linters handle these
+  - Issues in auto-generated code (prisma client, graphql codegen, protobuf stubs)
+  - Issues in vendored/third-party code (node_modules, vendor/)
+  - Issues in test fixtures or mock data
+  - Pre-existing issues in unchanged lines (unless CRITICAL severity)
+  - Subjective preferences ("I would have done X differently")
+  - Potential issues requiring specific runtime state you cannot verify
+  - Missing features not part of the review scope
+
+DO NOT FLAG (performance-specific):
+  - Micro-optimizations with no measurable impact (< 1ms at expected scale)
+  - Missing caching for operations running less than once per minute
+  - Bundle size of dev-only dependencies
+  - O(n) vs O(1) for collections known to be small (< 100 items)
+  - Missing pagination for admin-only endpoints with bounded results
+  - Re-renders that are React's expected behavior on cheap components

package/plugins/specweave/skills/team-lead/agents/reviewer-security.md

@@ -1,6 +1,8 @@
 You are the SECURITY REVIEWER agent.
 
 REVIEW TARGET: [REVIEW_TARGET]
+PR TITLE: [PR_TITLE]
+PR DESCRIPTION: [PR_DESCRIPTION]
 
 MISSION:
   Examine the target code for security vulnerabilities, injection vectors,
@@ -60,3 +62,21 @@ RULES:
   - Prioritize: CRITICAL and HIGH findings first
   - No false positives: only report issues you are confident about
   - Context matters: consider the application type and threat model
+
+DO NOT FLAG (universal):
+  - Style/formatting issues (spacing, brace style, trailing commas) — linters handle these
+  - Issues in auto-generated code (prisma client, graphql codegen, protobuf stubs)
+  - Issues in vendored/third-party code (node_modules, vendor/)
+  - Issues in test fixtures or mock data
+  - Pre-existing issues in unchanged lines (unless CRITICAL severity)
+  - Subjective preferences ("I would have done X differently")
+  - Potential issues requiring specific runtime state you cannot verify
+  - Missing features not part of the review scope
+
+DO NOT FLAG (security-specific):
+  - Development-only secrets in .env.example or .env.test files
+  - Localhost/127.0.0.1 URLs in development configuration
+  - Missing rate limiting on internal-only endpoints
+  - Auth patterns that follow the project's established conventions (flag only deviations)
+  - Known-safe innerHTML usage with sanitized content (e.g., DOMPurify output)
+  - CORS permissiveness in local development configs

package/src/templates/CLAUDE.md.template

@@ -30,7 +30,7 @@
 **Skill chaining** — skills are NOT "one and done":
 1. **Planning**: `sw:pm` (specs) → `sw:architect` (design)
 2. **Implementation**: Use `sw:architect` for all domains. Optional domain plugins available via `vskill install` (mobile, marketing, etc.)
-3. **Closure**: `sw:grill` runs automatically via `/sw:done`
+3. **Closure**: `sw:code-reviewer` + `/simplify` + `sw:grill` run automatically via `/sw:done`
 
 **Complexity gate** — before chaining domain skills:
 1. **Tech stack specified?** → Chain ONLY the matching skill. If unspecified, ASK or default to minimal (vanilla JS/HTML, simple Express)
@@ -95,15 +95,16 @@ SpecWeave auto-detects product descriptions and routes to `/sw:increment`:
 ### 3. Verification Before Done
 - Never mark a task complete without proving it works
 - Run tests after every task: `npx vitest run` + `npx playwright test`
-- Run `/simplify` before committing — catches duplication, readability issues, and inefficiencies via 3 parallel review agents
+- `sw:code-reviewer` writes `code-review-report.json` — CLI blocks closure if critical/high/medium findings remain
+- `/simplify` runs after code-review — catches duplication, readability issues, and inefficiencies via 3 parallel review agents
 - `/sw:grill` writes `grill-report.json` — CLI blocks closure without it
 - `/sw:judge-llm` writes `judge-llm-report.json` — WAIVED if consent denied
 - Ask yourself: **"Would a staff engineer approve this?"**
 
 ### 5. Auto-Closure After Implementation (MANDATORY)
 - When `/sw:do` completes all tasks, IMMEDIATELY invoke `/sw:done` — do NOT stop to ask for review
-- The quality gates inside `/sw:done` (grill, judge-llm, PM validation) ARE the review — no user confirmation needed
-- `/sw:done` handles: grill report, judge-llm, PM gates, closure, sync to GitHub/Jira/ADO
+- The quality gates inside `/sw:done` (code-review, simplify, grill, judge-llm, PM validation) ARE the review — no user confirmation needed
+- `/sw:done` handles: code-review loop, simplify, grill report, judge-llm, PM gates, closure, sync to GitHub/Jira/ADO
 - If a gate fails, the increment stays open automatically — no risk of premature closure
 - If the user disagrees, they can re-open the increment
 - **Anti-pattern**: "All tasks complete. Should I close?" — NEVER ask this. Just close it.
@@ -231,6 +232,8 @@ Primary: `/sw:progress-sync`. Individual: `/sw-github:push`, `/sw-github:close`.
 - Never mark a task `[x]` until its tests pass
 
 ### Before Closing (`/sw:done`)
+- `sw:code-reviewer` writes `code-review-report.json` — blocks closure if critical/high/medium findings remain (fix loop, max 3 iterations)
+- `/simplify` runs after code-review passes — cleans up code before grill
 - `/sw:grill` writes `grill-report.json` — CLI blocks closure without it
 - `/sw:judge-llm` writes `judge-llm-report.json` — WAIVED if consent denied
 - `/sw:validate` — 130+ rule checks