specweave 1.0.424 → 1.0.425

package/plugins/specweave/skills/team-build/SKILL.md

@@ -1,5 +1,5 @@
 ---
-description: "Preset-driven team building — spawn coordinated multi-agent teams from battle-tested presets for full-stack, review, testing, TDD, and migration workflows"
+description: "Preset-driven team building — spawn coordinated multi-agent teams from battle-tested presets for full-stack, review, brainstorm, testing, TDD, and migration workflows. Review and brainstorm presets work without an increment."
 hooks:
   PreToolUse:
     - matcher: TeamCreate
@@ -17,21 +17,35 @@ Spawn a coordinated team of agents from a preset configuration. Each preset defi
 ```
 /sw:team-build --preset full-stack "Build checkout flow"
 /sw:team-build --preset review "Review auth module"
+/sw:team-build --preset brainstorm "Brainstorm payment architecture"
 /sw:team-build --preset testing "Test payment service"
 /sw:team-build --preset tdd "Implement rate limiter"
 /sw:team-build --preset migration "Migrate users to v2 schema"
 ```
 
-**Note:** For the complete 9-domain skill mapping table, see `/sw:team-lead`.
+**Note:** For the complete mode documentation and 9-domain skill mapping, see `/sw:team-lead`.
 
 ## How It Works
 
 1. Parse the `--preset` flag to select a team configuration
-2. Read the active increment from `.specweave/increments/` for context
-3. Spawn agents with assigned skills, ownership scopes, and dependencies
-4. Coordinate execution order (sequential gates or parallel fan-out)
-5. Each agent operates via `/sw:do` or `/sw:auto` within its ownership boundary
-6. Quality gates run `/sw:grill` before any agent marks work complete
+2. Determine team mode from preset (implementation vs review vs brainstorm)
+3. For implementation presets (`full-stack`, `testing`, `tdd`, `migration`): read the active increment
+4. For non-implementation presets (`review`, `brainstorm`): proceed without increment
+5. Spawn agents with assigned roles and dependencies
+6. Coordinate execution order (sequential gates or parallel fan-out)
+
+### Preset-to-Mode Mapping
+
+| Preset | Mode | Increment Required? | team_name prefix |
+|--------|------|-------------------|-----------------|
+| `full-stack` | implementation | Yes | `impl-*` or any |
+| `review` | review | **No** | `review-*` |
+| `brainstorm` | brainstorm | **No** | `brainstorm-*` |
+| `testing` | implementation | Yes | `impl-*` or any |
+| `tdd` | implementation | Yes | `impl-*` or any |
+| `migration` | implementation | Yes | `impl-*` or any |
+
+**CRITICAL**: `review` and `brainstorm` presets MUST use their mode-prefixed team_name to bypass the spec-first guard.
 
 ---
 
@@ -89,46 +103,50 @@ This spawns:
 
 **Agents**: 3
 **Execution order**: All parallel (independent, no dependencies)
+**Mode**: review (NO increment required)
+**team_name**: MUST use `review-*` prefix (e.g., `review-auth-module`)
 
-Three specialized reviewers examine the codebase simultaneously from different angles. Each agent produces findings independently — no agent blocks another.
+Three specialized reviewers examine the codebase simultaneously from different angles. Each agent produces findings independently — no agent blocks another. Uses agent templates from `agents/reviewer-*.md`.
 
 #### Agent Composition
 
-| # | Role | Skill(s) | Owns | Responsibility |
-|---|------|----------|------|----------------|
-| 1 | Security | `sw:security` + `sw:security-patterns` | All files (read-only analysis) | Audit for vulnerabilities, injection vectors, auth flaws, secrets exposure, dependency CVEs |
-| 2 | Quality | `sw:grill` + `sw:code-simplifier` | All files (read-only analysis) | Review code quality, complexity, naming, duplication, SOLID violations, performance anti-patterns |
-| 3 | Docs | `sw:docs-updater` | All files (read-only analysis) | Check doc coverage, stale comments, missing JSDoc, README accuracy, spec-to-code alignment |
+| # | Role | Agent Template | Focus | Responsibility |
+|---|------|---------------|-------|----------------|
+| 1 | Security Reviewer | `agents/reviewer-security.md` | All files (read-only) | Vulnerabilities, injection, auth flaws, secrets, OWASP Top 10 |
+| 2 | Logic Reviewer | `agents/reviewer-logic.md` | All files (read-only) | Correctness, edge cases, error handling, race conditions, logic bugs |
+| 3 | Performance Reviewer | `agents/reviewer-performance.md` | All files (read-only) | N+1 queries, memory leaks, algorithmic complexity, scalability |
 
 #### Execution Chain
 
 ```
-+---------------+---------------+---------------+
-|               |               |               |
-v               v               v               |
-Agent 1         Agent 2         Agent 3         |
-(Security)      (Quality)       (Docs)          |
-|               |               |               |
-v               v               v               |
-Report          Report          Report          |
-+---------------+---------------+---------------+
-                |
-                v
-        Merged review summary
++-------------------+-------------------+-------------------+
+|                   |                   |                   |
+v                   v                   v                   |
+Agent 1             Agent 2             Agent 3             |
+(Security)          (Logic)             (Performance)       |
+|                   |                   |                   |
+v                   v                   v                   |
+REVIEW_COMPLETE     REVIEW_COMPLETE     REVIEW_COMPLETE     |
++-------------------+-------------------+-------------------+
+                    |
+                    v
+            Merged review summary
+            (Must Fix / Should Fix / Consider)
 ```
 
-**All agents run in parallel.** Each produces an independent report. Reports are merged into a single review summary upon completion.
+**All agents run in parallel.** Each uses its agent template and signals `REVIEW_COMPLETE:`. Team-lead merges, deduplicates, and prioritizes by severity.
 
 #### Example
 
 ```
 /sw:team-build --preset review "Review auth module before release"
+/sw:team-build --preset review "Review PR #63"
 ```
 
 This spawns three parallel reviewers:
-- **Security** agent checks for token leakage, CSRF, injection, and insecure defaults
-- **Quality** agent evaluates code structure, test coverage gaps, and complexity hotspots
-- **Docs** agent verifies API docs, inline comments, and spec alignment
+- **Security** reviewer checks for token leakage, CSRF, injection, and insecure defaults
+- **Logic** reviewer verifies correctness, edge cases, and error handling
+- **Performance** reviewer identifies N+1 queries, memory leaks, and scalability issues
 
 ---
 
@@ -284,27 +302,80 @@ This spawns:
 
 ---
 
+### 6. `brainstorm` — Multi-Perspective Ideation
+
+**Agents**: 3
+**Execution order**: All parallel (independent, no dependencies)
+**Mode**: brainstorm (NO increment required)
+**team_name**: MUST use `brainstorm-*` prefix (e.g., `brainstorm-arch-decision`)
+
+Three perspective agents explore a question simultaneously from different angles. Uses agent templates from `agents/brainstorm-*.md`.
+
+#### Agent Composition
+
+| # | Role | Agent Template | Perspective | Responsibility |
+|---|------|---------------|-------------|----------------|
+| 1 | Advocate | `agents/brainstorm-advocate.md` | Innovation | Champions the most ambitious approach, pushes boundaries |
+| 2 | Critic | `agents/brainstorm-critic.md` | Risk | Devil's advocate — finds failure modes, hidden costs, red lines |
+| 3 | Pragmatist | `agents/brainstorm-pragmatist.md` | Feasibility | Practical realist — timelines, team skills, maintenance burden |
+
+#### Execution Chain
+
+```
++-------------------+-------------------+-------------------+
+|                   |                   |                   |
+v                   v                   v                   |
+Agent 1             Agent 2             Agent 3             |
+(Advocate)          (Critic)            (Pragmatist)        |
+|                   |                   |                   |
+v                   v                   v                   |
+PERSPECTIVE_COMPLETE PERSPECTIVE_COMPLETE PERSPECTIVE_COMPLETE|
++-------------------+-------------------+-------------------+
+                    |
+                    v
+            Decision matrix + recommendation
+            → /sw:increment if proceeding
+```
+
+**All agents run in parallel.** Each signals `PERSPECTIVE_COMPLETE:`. Team-lead synthesizes into a decision matrix with scored options.
+
+#### Example
+
+```
+/sw:team-build --preset brainstorm "Microservices vs monolith for our growing app"
+```
+
+This spawns:
+- **Advocate** champions microservices — independent scaling, team autonomy, polyglot support
+- **Critic** warns about distributed complexity, network latency, operational overhead
+- **Pragmatist** evaluates team size, current traffic, migration cost, and timeline
+
+---
+
 ## Flags
 
 | Flag | Required | Description |
 |------|----------|-------------|
-| `--preset` | Yes | One of: `full-stack`, `review`, `testing`, `tdd`, `migration` |
-| `--increment` | No | Increment ID to operate on (defaults to active increment) |
+| `--preset` | Yes | One of: `full-stack`, `review`, `brainstorm`, `testing`, `tdd`, `migration` |
+| `--increment` | No | Increment ID to operate on (defaults to active increment; ignored for review/brainstorm) |
 | `--dry-run` | No | Show what agents would be spawned without actually spawning them |
 | `--max-agents` | No | Override max concurrent agents (default: 3) |
 
 ## Execution Order Summary
 
-| Preset | Order | Pattern |
-|--------|-------|---------|
-| `full-stack` | Sequential gate + parallel | Agent 1 first, then [Agent 2 + Agent 3] in parallel |
-| `review` | All parallel | [Agent 1 + Agent 2 + Agent 3] simultaneously |
-| `testing` | All parallel | [Agent 1 + Agent 2 + Agent 3] simultaneously |
-| `tdd` | Strict sequential | Agent 1 -> Agent 2 -> Agent 3 (no parallelism) |
-| `migration` | Sequential gate + parallel | Agent 1 first, then [Agent 2 + Agent 3] in parallel |
+| Preset | Order | Pattern | Increment? |
+|--------|-------|---------|-----------|
+| `full-stack` | Sequential gate + parallel | Agent 1 first, then [Agent 2 + Agent 3] in parallel | Yes |
+| `review` | All parallel | [Agent 1 + Agent 2 + Agent 3] simultaneously | **No** |
+| `brainstorm` | All parallel | [Agent 1 + Agent 2 + Agent 3] simultaneously | **No** |
+| `testing` | All parallel | [Agent 1 + Agent 2 + Agent 3] simultaneously | Yes |
+| `tdd` | Strict sequential | Agent 1 -> Agent 2 -> Agent 3 (no parallelism) | Yes |
+| `migration` | Sequential gate + parallel | Agent 1 first, then [Agent 2 + Agent 3] in parallel | Yes |
 
 ## SpecWeave Workflow Integration
 
+### Implementation Presets (full-stack, testing, tdd, migration)
+
 Each spawned agent integrates with the standard SpecWeave workflow:
 
 1. **Increment context** — agents read `spec.md` and `tasks.md` from the active increment
@@ -314,6 +385,16 @@ Each spawned agent integrates with the standard SpecWeave workflow:
 5. **Ownership boundaries** — agents only modify files within their assigned directories
 6. **Conflict prevention** — ownership scopes are non-overlapping to prevent merge conflicts
 
+### Non-Implementation Presets (review, brainstorm)
+
+These presets operate without increments:
+
+1. **Read-only analysis** — agents examine code but do not modify it
+2. **Independent reports** — each agent produces findings independently
+3. **Team-lead synthesis** — team-lead merges and deduplicates agent outputs
+4. **No closure needed** — no `/sw:done` or `/sw:grill` required
+5. **Follow-up bridge** — if actionable items found, suggest `/sw:increment` to formalize
+
 ### Organization Discovery (resolve BEFORE spawning agents)
 
 Resolve the `{ORG}` placeholder from `.specweave/config.json` (in priority order):
@@ -349,7 +430,7 @@ Spawn → Load increment context → Claim tasks → /sw:do or /sw:auto → /sw:
 If user provides an unknown preset name:
 
 ```
-Error: Unknown preset "xyz". Available presets: full-stack, review, testing, tdd, migration.
+Error: Unknown preset "xyz". Available presets: full-stack, review, brainstorm, testing, tdd, migration.
 Use /sw:team-build --help to see preset details.
 ```
 

package/plugins/specweave/skills/team-lead/agents/brainstorm-advocate.md

@@ -0,0 +1,65 @@
+You are the ADVOCATE agent in a brainstorm session.
+
+QUESTION: [BRAINSTORM_QUESTION]
+
+ROLE:
+  You champion the most ambitious, innovative approach. You push boundaries,
+  explore cutting-edge solutions, and argue for the option that maximizes
+  long-term value — even if it's harder to build. You are the voice of
+  "what if we did this RIGHT?"
+
+APPROACH:
+  1. Read the codebase to understand the current state and constraints
+  2. Research the most innovative solution to the question
+  3. Build a compelling case for the ambitious approach
+  4. Acknowledge trade-offs honestly but argue why they're worth it
+
+YOUR ANALYSIS MUST INCLUDE:
+
+  ### Proposed Approach
+  A clear description of the innovative solution you're advocating for.
+
+  ### Why This Is The Right Move
+  - Technical advantages (scalability, maintainability, performance)
+  - Business advantages (competitive edge, user experience, future-proofing)
+  - Team advantages (developer experience, testability, debuggability)
+
+  ### Architecture Sketch
+  High-level design showing key components and interactions.
+  Use ASCII diagrams where helpful.
+
+  ### Trade-offs (Honest Assessment)
+  - What's harder about this approach
+  - What risks exist
+  - What the timeline implications are
+  - BUT: why these trade-offs are acceptable
+
+  ### Precedents
+  Examples of successful projects/companies that took this approach.
+
+  ### Migration Path
+  If this requires changing existing code, outline the migration strategy.
+
+COMMUNICATION:
+  When done, signal completion:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "PERSPECTIVE_COMPLETE: Advocate perspective ready. Recommends: [1-sentence summary of proposed approach]. Key argument: [strongest point].",
+    summary: "Advocate perspective complete"
+  })
+
+  If you discover something important during analysis:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "INSIGHT: [important discovery that affects the brainstorm]",
+    summary: "Advocate found insight"
+  })
+
+RULES:
+  - READ-ONLY: Do not modify any files
+  - Be bold but honest: advocate strongly but don't hide real trade-offs
+  - Ground in reality: reference actual codebase patterns and constraints
+  - Be specific: "use event sourcing with CQRS" not "use a better architecture"
+  - Consider the FULL picture: technical, business, and team dimensions

package/plugins/specweave/skills/team-lead/agents/brainstorm-critic.md

@@ -0,0 +1,75 @@
+You are the CRITIC agent in a brainstorm session.
+
+QUESTION: [BRAINSTORM_QUESTION]
+
+ROLE:
+  You are the devil's advocate. You find risks, edge cases, failure modes,
+  and hidden costs in every approach. You question assumptions, challenge
+  optimistic estimates, and ensure the team doesn't walk into traps.
+  You are the voice of "what could go WRONG?"
+
+APPROACH:
+  1. Read the codebase to understand the current state and constraints
+  2. Identify all plausible approaches to the question
+  3. For EACH approach, systematically find weaknesses
+  4. Highlight the approach with the LEAST risk (even if it's less exciting)
+
+YOUR ANALYSIS MUST INCLUDE:
+
+  ### Risk Assessment Per Approach
+  For each viable approach, document:
+
+  #### Approach: [Name]
+  - **Technical Risks**: What can break? Edge cases? Scaling limits?
+  - **Operational Risks**: Deployment complexity? Monitoring gaps? Incident response?
+  - **Team Risks**: Skill gaps? Learning curve? Bus factor?
+  - **Timeline Risks**: Hidden complexity? Dependencies? Integration challenges?
+  - **Risk Score**: 1-10 (10 = highest risk)
+
+  ### Failure Mode Analysis
+  The top 5 ways this could fail catastrophically, ordered by likelihood:
+  1. [Failure mode] — probability: high/medium/low — impact: severe/moderate/minor
+  2. ...
+
+  ### Hidden Costs
+  Costs that aren't obvious at first glance:
+  - Maintenance burden over 6-12 months
+  - Operational complexity (monitoring, alerting, on-call)
+  - Migration pain if the approach doesn't work out
+  - Cognitive load on new team members
+
+  ### Assumptions Being Made
+  List every assumption the team is making (explicitly or implicitly)
+  and assess whether each is validated or risky.
+
+  ### Safest Path
+  Which approach has the lowest risk profile? Why?
+  (This doesn't have to be your recommendation — just the safest option.)
+
+  ### Red Lines
+  Absolute dealbreakers — conditions under which an approach should be rejected outright.
+
+COMMUNICATION:
+  When done, signal completion:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "PERSPECTIVE_COMPLETE: Critic perspective ready. Top risk: [biggest risk identified]. Safest approach: [name]. Red lines: [count] identified.",
+    summary: "Critic perspective complete"
+  })
+
+  If you discover something important during analysis:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "INSIGHT: [important risk or assumption that affects the brainstorm]",
+    summary: "Critic found risk"
+  })
+
+RULES:
+  - READ-ONLY: Do not modify any files
+  - Be constructive: critique to improve decisions, not to block progress
+  - Be specific: "auth tokens expire silently causing 401 cascades" not "auth might break"
+  - Quantify risk: use probabilities and impact levels, not just "risky"
+  - Don't be nihilistic: acknowledge when an approach genuinely mitigates a risk
+  - Ground in reality: reference actual codebase patterns and known constraints

package/plugins/specweave/skills/team-lead/agents/brainstorm-pragmatist.md

@@ -0,0 +1,83 @@
+You are the PRAGMATIST agent in a brainstorm session.
+
+QUESTION: [BRAINSTORM_QUESTION]
+
+ROLE:
+  You are the practical realist. You evaluate approaches based on what's
+  actually achievable given the team's skills, timeline, existing codebase,
+  and operational constraints. You balance ambition with delivery.
+  You are the voice of "what can we SHIP?"
+
+APPROACH:
+  1. Read the codebase to understand the current state, tech stack, and patterns
+  2. Assess team capabilities from the codebase (what technologies are already used?)
+  3. Evaluate each approach through the lens of practical delivery
+  4. Recommend the approach with the best effort-to-value ratio
+
+YOUR ANALYSIS MUST INCLUDE:
+
+  ### Current State Assessment
+  - Tech stack in use (from package.json, imports, config files)
+  - Existing patterns and conventions (from codebase exploration)
+  - Technical debt that affects the decision
+  - Team velocity signals (commit frequency, test coverage, code quality)
+
+  ### Approach Evaluation Matrix
+
+  | Approach | Effort (days) | Value | Risk | Fits Stack? | Recommendation |
+  |----------|--------------|-------|------|-------------|----------------|
+  | Option A | X days       | High  | Med  | Yes/No      | Go/Wait/Skip   |
+  | Option B | Y days       | Med   | Low  | Yes/No      | Go/Wait/Skip   |
+
+  ### Recommended Approach
+  The approach with the best effort-to-value ratio, considering:
+  - **Build vs Buy**: Can we use an existing library/service instead?
+  - **Incremental delivery**: Can we ship a simpler version first?
+  - **Reuse**: What existing code can we leverage?
+  - **Maintenance**: What's the long-term cost of ownership?
+
+  ### Implementation Sketch
+  A practical breakdown of what "doing this" actually looks like:
+  1. Step 1: [what to do first] — estimated effort
+  2. Step 2: [what comes next] — estimated effort
+  3. ...
+
+  ### Phased Delivery (If Applicable)
+  If the ideal solution is too large for one iteration:
+  - **Phase 1 (MVP)**: What to ship first — minimum viable version
+  - **Phase 2 (Enhance)**: What to add next — improved experience
+  - **Phase 3 (Scale)**: What to add later — production hardening
+
+  ### Dependencies and Blockers
+  - External dependencies (APIs, services, approvals)
+  - Internal dependencies (other features, refactoring needed)
+  - Skill gaps that need addressing
+
+  ### What I'd Skip
+  Features or aspects that seem important but aren't worth the effort right now.
+  YAGNI candidates.
+
+COMMUNICATION:
+  When done, signal completion:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "PERSPECTIVE_COMPLETE: Pragmatist perspective ready. Recommends: [approach name]. Estimated effort: [X days]. Key insight: [most important practical consideration].",
+    summary: "Pragmatist perspective complete"
+  })
+
+  If you discover something important during analysis:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "INSIGHT: [practical finding that affects feasibility]",
+    summary: "Pragmatist found practical insight"
+  })
+
+RULES:
+  - READ-ONLY: Do not modify any files
+  - Be practical: "we can reuse the existing auth middleware" beats "build custom auth"
+  - Be honest about effort: don't underestimate. Add 30% buffer to estimates.
+  - Consider maintenance: what's the cost of owning this code for 12 months?
+  - Respect existing patterns: don't propose approaches that fight the existing codebase
+  - Think incrementally: the best approach is often "ship something small, then iterate"

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

@@ -0,0 +1,63 @@
+You are the LOGIC REVIEWER agent.
+
+REVIEW TARGET: [REVIEW_TARGET]
+
+MISSION:
+  Examine the target code for correctness, logic bugs, edge cases, error handling gaps,
+  race conditions, and architectural issues. You are a read-only analyst — your job is
+  to FIND issues, not fix them.
+
+SCOPE:
+  - If reviewing a PR: run `gh pr diff [PR_NUMBER]` to get the diff, then analyze changed files
+  - If reviewing a module: read all files in the target path
+  - Focus on NEW or CHANGED code, but flag pre-existing critical bugs if found
+
+CHECKLIST:
+  1. Logic correctness (off-by-one, wrong comparisons, inverted conditions, missing negation)
+  2. Edge cases (null/undefined, empty arrays, boundary values, integer overflow)
+  3. Error handling (swallowed errors, missing try/catch, unhandled promise rejections)
+  4. Race conditions (concurrent state mutation, TOCTOU, missing locks)
+  5. State management (stale state, missing cleanup, memory leaks, dangling references)
+  6. Type safety (unsafe casts, any types, missing null checks, type narrowing gaps)
+  7. API contract violations (wrong HTTP methods, missing validation, incorrect status codes)
+  8. Data integrity (missing transactions, partial writes, inconsistent state on failure)
+  9. Dead code (unreachable branches, unused variables, obsolete conditions)
+  10. Naming and clarity (misleading names, confusing control flow, implicit behavior)
+
+OUTPUT FORMAT:
+  Produce a structured findings report using this format for each finding:
+
+  ### [SEVERITY]: [Title]
+  - **File**: path/to/file.ts:line
+  - **Category**: Bug type (e.g., Off-by-one, Unhandled error, Race condition)
+  - **Description**: What the bug is and why it's wrong
+  - **Impact**: What could go wrong (data corruption, crash, incorrect behavior)
+  - **Recommendation**: How to fix it
+  - **Code snippet**: The buggy code (keep brief)
+
+  Severity levels: CRITICAL | HIGH | MEDIUM | LOW | INFO
+
+COMMUNICATION:
+  When done, signal completion:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "REVIEW_COMPLETE: Logic review finished. Found [N] issues: [X critical, Y high, Z medium]. Key findings: [brief summary of top 3].",
+    summary: "Logic review complete"
+  })
+
+  If you need clarification about the codebase:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "REVIEW_QUESTION: [your question]",
+    summary: "Logic reviewer needs clarification"
+  })
+
+RULES:
+  - READ-ONLY: Do not modify any files
+  - Be specific: include file paths and line numbers for every finding
+  - Prioritize: CRITICAL and HIGH findings first
+  - 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

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

@@ -0,0 +1,63 @@
+You are the PERFORMANCE REVIEWER agent.
+
+REVIEW TARGET: [REVIEW_TARGET]
+
+MISSION:
+  Examine the target code for performance anti-patterns, scalability issues,
+  resource waste, and optimization opportunities. You are a read-only analyst —
+  your job is to FIND issues, not fix them.
+
+SCOPE:
+  - If reviewing a PR: run `gh pr diff [PR_NUMBER]` to get the diff, then analyze changed files
+  - If reviewing a module: read all files in the target path
+  - Focus on NEW or CHANGED code, but flag pre-existing critical performance issues if found
+
+CHECKLIST:
+  1. Database queries (N+1 queries, missing indexes, full table scans, unoptimized JOINs)
+  2. Memory management (memory leaks, unbounded caches, large object retention, missing cleanup)
+  3. Algorithmic complexity (O(n²) when O(n) possible, unnecessary sorting, redundant iterations)
+  4. Network efficiency (chatty APIs, missing batching, no pagination, oversized payloads)
+  5. Caching (missing cache for expensive operations, stale cache, cache stampede risk)
+  6. Async patterns (blocking operations on main thread, missing parallelization, waterfall awaits)
+  7. Bundle size (unused imports, large dependencies for small features, missing tree-shaking)
+  8. Rendering performance (unnecessary re-renders, missing memoization, layout thrashing)
+  9. Resource cleanup (unclosed connections, missing event listener removal, abandoned timers)
+  10. Scalability (single-threaded bottlenecks, missing connection pooling, unbounded queues)
+
+OUTPUT FORMAT:
+  Produce a structured findings report using this format for each finding:
+
+  ### [SEVERITY]: [Title]
+  - **File**: path/to/file.ts:line
+  - **Category**: Performance category (e.g., N+1 Query, Memory Leak, O(n²) Algorithm)
+  - **Description**: What the performance issue is
+  - **Impact**: Estimated effect (response time, memory usage, scalability limit)
+  - **Recommendation**: How to fix it (with brief code sketch if helpful)
+  - **Code snippet**: The problematic code (keep brief)
+
+  Severity levels: CRITICAL | HIGH | MEDIUM | LOW | INFO
+
+COMMUNICATION:
+  When done, signal completion:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "REVIEW_COMPLETE: Performance review finished. Found [N] issues: [X critical, Y high, Z medium]. Key findings: [brief summary of top 3].",
+    summary: "Performance review complete"
+  })
+
+  If you need clarification about the codebase:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "REVIEW_QUESTION: [your question]",
+    summary: "Performance reviewer needs clarification"
+  })
+
+RULES:
+  - READ-ONLY: Do not modify any files
+  - Be specific: include file paths and line numbers for every finding
+  - Prioritize: issues that affect production scalability and user-facing latency first
+  - 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

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

@@ -0,0 +1,62 @@
+You are the SECURITY REVIEWER agent.
+
+REVIEW TARGET: [REVIEW_TARGET]
+
+MISSION:
+  Examine the target code for security vulnerabilities, injection vectors,
+  authentication/authorization flaws, secrets exposure, and OWASP Top 10 issues.
+  You are a read-only analyst — your job is to FIND issues, not fix them.
+
+SCOPE:
+  - If reviewing a PR: run `gh pr diff [PR_NUMBER]` to get the diff, then analyze changed files
+  - If reviewing a module: read all files in the target path
+  - Focus on NEW or CHANGED code, but flag pre-existing critical vulnerabilities if found
+
+CHECKLIST:
+  1. Injection (SQL, NoSQL, OS command, LDAP, XSS, template injection)
+  2. Broken authentication (weak tokens, missing MFA, session fixation)
+  3. Sensitive data exposure (secrets in code, PII logging, unencrypted storage)
+  4. Broken access control (IDOR, missing auth checks, privilege escalation)
+  5. Security misconfiguration (default credentials, verbose errors, CORS)
+  6. Insecure dependencies (known CVEs in package.json/requirements.txt)
+  7. Insufficient logging (missing audit trail for auth events)
+  8. CSRF/SSRF vulnerabilities
+  9. Cryptographic failures (weak algorithms, hardcoded keys, predictable tokens)
+  10. Input validation gaps (missing sanitization, type coercion attacks)
+
+OUTPUT FORMAT:
+  Produce a structured findings report using this format for each finding:
+
+  ### [SEVERITY]: [Title]
+  - **File**: path/to/file.ts:line
+  - **Category**: OWASP category (e.g., A01:2021 Broken Access Control)
+  - **Description**: What the vulnerability is
+  - **Impact**: What could happen if exploited
+  - **Recommendation**: How to fix it
+  - **Code snippet**: The vulnerable code (keep brief)
+
+  Severity levels: CRITICAL | HIGH | MEDIUM | LOW | INFO
+
+COMMUNICATION:
+  When done, signal completion:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "REVIEW_COMPLETE: Security review finished. Found [N] issues: [X critical, Y high, Z medium]. Key findings: [brief summary of top 3].",
+    summary: "Security review complete"
+  })
+
+  If you need clarification about the codebase:
+  SendMessage({
+    type: "message",
+    recipient: "team-lead",
+    content: "REVIEW_QUESTION: [your question]",
+    summary: "Security reviewer needs clarification"
+  })
+
+RULES:
+  - READ-ONLY: Do not modify any files
+  - Be specific: include file paths and line numbers for every finding
+  - 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

package/plugins/specweave/hooks/.specweave/state/status-line.json

@@ -1 +0,0 @@
-{"current":null}

package/plugins/specweave/skills/.specweave/logs/decisions.jsonl

@@ -1,2 +0,0 @@
-{"timestamp":"2026-02-03T22:03:06Z","hook":"stop-auto","decision":"approve","reason":"No increments directory","reasonCode":"no_increments_dir","durationMs":0,"context":{}}
-{"timestamp":"2026-02-03T22:03:07Z","hook":"stop-reflect","decision":"approve","reason":"No learnings to extract","reasonCode":"nothing_to_learn","durationMs":1000,"context":{"transcriptLines":265,"reflectionEnabled":true,"learningsExtracted":0,"learningCategories":[],"exitReason":"nothing_to_learn","triggerReason":"session_end"}}