rpi-kit 1.4.0 → 2.0.0

package/skills/rpi-agents/SKILL.md

@@ -1,59 +1,83 @@
 ---
 name: rpi-agents
-description: This skill should be used when the user asks about RPI agent behavior, rules, or roles, asks "what agents are involved", "how does the code reviewer work", "what are the agent rules", "customize agent behavior", or mentions agent names like requirement-parser, product-manager, ux-designer, senior-engineer, cto-advisor, doc-synthesizer, plan-executor, code-simplifier, code-reviewer, explore-codebase, test-engineer, or doc-writer.
-version: 1.0.1
-license: MIT
+description: This skill should be used when the user asks about RPIKit agents, their roles, or behavior.
 ---
 
-# RPI Agent Guidelines
+# RPIKit Agents
 
-Behavioral constraints for RPI agents. Every agent follows the general rules below PLUS their role-specific rules.
+## Overview
 
-## General Rules (All Agents)
+RPIKit v2 uses 13 named agents with rich personas. Each agent has a distinct personality that shapes how it approaches problems, ensuring diverse perspectives across the development pipeline.
 
-1. **Cite evidence.** Every claim must reference a specific file, dependency, or codebase pattern. No unsupported statements.
-2. **Name unknowns.** If you're uncertain, say what you don't know. Never fill gaps with assumptions.
-3. **Be concrete.** Anti-pattern: "This could improve performance." Instead: "Batching the 3 API calls reduces round-trips from 3 to 1."
-4. **Stay in scope.** Only analyze what's relevant to the feature. Don't audit the entire codebase.
-5. **Structured output.** Use the section format specified for your role. Include your verdict per section.
+## Agent Reference
 
-## Output Format (Research Agents)
+| Name | Role | Phase | Persona |
+|------|------|-------|---------|
+| Luna | Analyst | Request | Curious, asks uncomfortable questions |
+| Atlas | Codebase Explorer | Research | Methodical, evidence-based |
+| Scout | External Investigator | Research | Skeptical, checks everything |
+| Nexus | Synthesizer/Facilitator | Cross-phase | Diplomatic but decisive |
+| Mestre | Architect | Plan | Pragmatic, hates over-engineering |
+| Clara | Product Manager | Plan | Value-driven, cuts scope |
+| Pixel | UX Designer | Plan (conditional) | Empathetic, user-first |
+| Forge | Executor | Implement | Disciplined, follows plan |
+| Sage | Tester | Implement + Review | Paranoid about edge cases |
+| Razor | Simplifier | Simplify | Minimalist, loves deletion |
+| Hawk | Adversarial Reviewer | Review | Forced to find problems |
+| Shield | Security Sentinel | Review | Professionally paranoid |
+| Quill | Technical Writer | Docs | Clear, concise, WHY not WHAT |
 
-Each research agent outputs markdown sections with verdicts:
+## Agents by Phase
 
-```markdown
-## [Section Name]
-Verdict: GO | CONCERN | BLOCK
+- **Request:** Luna
+- **Research:** Atlas + Scout -> Nexus (synthesis)
+- **Plan:** Mestre + Clara + Pixel (conditional) -> Nexus (validation)
+- **Implement:** Forge + Sage (if TDD enabled)
+- **Simplify:** Razor
+- **Review:** Hawk + Shield + Sage (parallel) -> Nexus (synthesis)
+- **Docs:** Quill
+- **Party Mode:** Nexus (facilitator) + 3-5 relevant agents
+- **Archive:** Nexus (merge delta into specs)
 
-[Findings with evidence]
+## Conditional Agents
 
-### [Sub-section if needed]
-[Details]
+**Pixel** only activates when frontend work is detected. Controlled by `.rpi.yaml`:
+
+```yaml
+ux_agent: auto    # auto | always | never
 ```
 
-End with: `Estimated Complexity: S | M | L | XL`
+- `auto` -- Pixel activates when the feature involves UI/frontend components
+- `always` -- Pixel always participates in planning
+- `never` -- Pixel is never activated
+
+## Party Mode Agent Selection
+
+Nexus selects agents based on the topic:
+
+- **Technical topics** -> Mestre + Atlas + Scout
+- **Product topics** -> Clara + Luna + Pixel
+- **Security topics** -> Shield + Hawk + Mestre
+- **Mixed topics** -> Mestre + Clara + Atlas + Shield
+
+The number of agents defaults to `party_default_agents` in `.rpi.yaml` (default: 4).
 
-## Agent Roles
+## Review Dynamics
 
-The RPI workflow uses 12 specialized agents. Each has detailed behavioral rules, anti-patterns, and output formats defined in its own file under `agents/`:
+Review runs three agents in parallel for independent perspectives:
 
-| Agent | Role | Phase |
-|-------|------|-------|
-| requirement-parser | Extract structured, testable requirements | Research |
-| product-manager | Scope, user stories, effort, acceptance criteria | Research, Plan |
-| ux-designer | User flows, interaction patterns, UI decisions | Research (deep), Plan |
-| senior-engineer | Technical approach, architecture, dependencies | Research, Plan |
-| cto-advisor | Risk, feasibility, strategic alignment | Research (deep) |
-| doc-synthesizer | Merge research outputs into RESEARCH.md | Research |
-| explore-codebase | Scan codebase for patterns and context | Research |
-| test-engineer | Write failing tests before implementation (TDD) | Implement (TDD), Test |
-| plan-executor | Implement tasks from PLAN.md surgically | Implement |
-| code-simplifier | Check reuse, quality, efficiency and fix | Implement |
-| code-reviewer | Review implementation against plan | Implement, Review |
-| doc-writer | Generate documentation from artifacts | Docs |
+1. **Hawk** -- adversarial code review (quality, patterns, architecture)
+   - Uses 5 perspectives: dev, ops, user, security, business
+   - Forced to find problems (zero findings triggers re-analysis)
+   - Classifies findings: P1 (blocks) | P2 (should fix) | P3 (nice-to-have)
+2. **Shield** -- security audit (OWASP Top 10, secrets, injection, auth bypass)
+3. **Sage** -- test coverage (untested modules, uncovered paths, missing tests)
+4. **Nexus** -- synthesizes findings into final verdict: PASS | PASS with concerns | FAIL
 
-For full role-specific rules, anti-patterns, and output formats, see the individual agent definitions in `agents/*.md`.
+## Knowledge Compounding
 
-## Related
+When review agents find problems and the dev fixes them:
 
-For the workflow process (phases, commands, configuration), see the **rpi-workflow** skill.
+1. The solution is auto-saved to `rpi/solutions/{category}/`
+2. Categories are auto-detected: performance, security, database, testing, architecture, patterns, decisions
+3. Scout checks solutions/ in future research phases, preventing repeated mistakes

package/skills/rpi-workflow/SKILL.md

@@ -1,245 +1,219 @@
 ---
 name: rpi-workflow
-description: This skill should be used when the user wants to develop a feature systematically, asks "how do I start a new feature", "walk me through the workflow", "help me build this step by step", says "research plan implement", mentions TDD or test-driven development, mentions model profiles or model selection, or mentions any RPI command (/rpi:init, /rpi:new, /rpi:research, /rpi:plan, /rpi:implement, /rpi:test, /rpi:simplify, /rpi:status, /rpi:review, /rpi:docs, /rpi:add-todo, /rpi:set-profile).
-version: 0.2.0
-license: MIT
+description: This skill should be used when the user wants to develop a feature systematically, asks "how do I start a new feature", "walk me through the workflow", or mentions any RPI command.
 ---
 
-# RPI Workflow
+# RPIKit Workflow
 
-RPI (Research → Plan → Implement) is a systematic feature development workflow with validation gates at each phase.
+## Overview
 
-## Workflow Phases
+RPIKit v2 is a 7-phase pipeline for AI-assisted feature development:
+request -> research -> plan -> implement -> simplify -> review -> docs
 
-### Phase 0: Init
-Run `/rpi:init` once per project to configure:
-- Feature folder location (default: `rpi/`)
-- Default research tier
-- Parallel threshold, commit style, and other preferences
-- Creates `.rpi.yaml` at project root
+Each phase produces artifacts that feed the next, with named agents driving each step.
 
-### Phase 1: New Feature
-Run `/rpi:new` to start. Adaptive interview:
-- Start with core questions: what feature, what problem it solves
-- Ask follow-ups based on answers (who uses it, complexity, constraints, references)
-- Set up isolation based on `isolation` config:
-  - `none`: work on current branch
-  - `branch`: `git checkout -b feature/{slug}`
-  - `worktree`: create `.worktrees/{slug}` with `git worktree add`
-- Generate `{folder}/{feature-slug}/REQUEST.md` with structured sections
+## Quick Start
 
-REQUEST.md sections: Summary, Problem, Target Users, Constraints, References, Complexity Estimate.
+1. `/rpi:init` -- configure RPIKit for your project
+2. `/rpi:new my-feature` -- start a feature (Luna interviews you)
+3. `/rpi my-feature` -- auto-progress through phases
 
-### Phase 2: Research
-Run `/rpi:research {feature-slug}` with optional tier flag.
+## Phases
 
-Research tiers control agent composition:
-- `--quick`: requirement-parser + explore-codebase (feasibility only)
-- `--standard` (default): + product-manager + senior-engineer (scope + approach)
-- `--deep`: + cto-advisor + ux-designer if UI (full analysis + alternatives)
+| Phase | Command | Agents | Artifacts |
+|-------|---------|--------|-----------|
+| Request | /rpi:new | Luna | REQUEST.md |
+| Research | /rpi:research | Atlas, Scout, Nexus | RESEARCH.md |
+| Plan | /rpi:plan | Mestre, Clara, Pixel, Nexus | PLAN.md, eng.md, pm.md, ux.md, delta/ |
+| Implement | /rpi:implement | Forge, Sage | IMPLEMENT.md |
+| Simplify | /rpi:simplify | Razor | code changes |
+| Review | /rpi:review | Hawk, Shield, Sage, Nexus | review verdict |
+| Docs | /rpi:docs | Quill | README, changelog |
 
-All selected agents run in **parallel fan-out**. Doc-synthesizer merges outputs into RESEARCH.md.
+## Auto-Flow
 
-RESEARCH.md format:
-1. Executive Summary (5 lines: verdict, complexity, risk, recommendation, key finding)
-2. Requirements Analysis
-3. Product Scope
-4. Codebase Context
-5. Technical Analysis
-6. Strategic Assessment (deep tier only)
-7. Alternatives (mandatory if NO-GO)
+`/rpi {feature}` detects the current phase and runs the next one automatically:
 
-Verdicts: **GO**, **GO with concerns**, **NO-GO**
-- NO-GO includes alternative approaches and scope reduction suggestions
-- Override with `--force` flag
-
-### Phase 3: Plan
-Run `/rpi:plan {feature-slug}`.
-
-Adaptive artifact generation:
-- Always: PLAN.md (task checklist) + eng.md (technical spec)
-- Adaptive: pm.md (user stories) and ux.md (user flows) — generated based on feature type
-- After research, asks user to confirm which artifacts to generate
-
-PLAN.md task format:
-```markdown
-## Phase 1: Phase Name
-
-- [ ] **1.1** Task description
-  Effort: S | Deps: none
-  Files: src/path/to/file.ts
-  Test: returns 200 for valid request with auth token
-
-- [ ] **1.2** Another task
-  Effort: M | Deps: 1.1
-  Files: src/other/file.ts
-  Test: rejects duplicate entries with 409 conflict
+```
+/rpi oauth  ->  has REQUEST.md?   ->  Phase 2: Research
+/rpi oauth  ->  has RESEARCH.md?  ->  Phase 3: Plan
+/rpi oauth  ->  has PLAN.md?      ->  Phase 4: Implement
+/rpi oauth  ->  has IMPLEMENT.md? ->  Phase 5: Simplify
+/rpi oauth  ->  simplify done?    ->  Phase 6: Review
+/rpi oauth  ->  review PASS?      ->  Phase 7: Docs
 ```
 
-### Standalone: TDD
-Run `/rpi:test {feature-slug}` to run TDD cycles on individual tasks.
-
-- Works independently of `/rpi:implement` — use when you want TDD on specific tasks
-- Strict RED → GREEN → REFACTOR per task, one test at a time
-- Auto-detects test framework and conventions from the project
-- Flags: `--task <id>` for single task, `--all` for all uncompleted tasks
-
-### Phase 4: Implement
-Run `/rpi:implement {feature-slug}`.
-
-Smart execution mode:
-- < 8 tasks: single plan-executor agent, sequential
-- 8+ tasks: group into waves by dependency, execute in parallel
-- Override: `--sequential` or `--parallel` flags
+If the feature does not exist: `Feature 'oauth' not found. Run /rpi:new oauth to start.`
 
-Pipeline per phase:
-1. Execute tasks → commit per task
-   - If TDD enabled: RED (write failing test) → VERIFY RED → GREEN (minimal code) → VERIFY GREEN → REFACTOR → commit
-   - If TDD disabled: execute task → commit (original behavior)
-2. Simplify (3 parallel sub-agents: reuse, quality, efficiency)
-3. Review (code-reviewer checks against plan + test coverage)
-4. Phase verdict: PASS or FAIL
+## Escape Hatches
 
-IMPLEMENT.md tracks: task completion with commits, start/end times, files changed, deviations, simplify findings, review verdict.
+Run a specific phase directly:
 
-After implementation, isolation cleanup runs based on config:
-- `none`: nothing
-- `branch`: asks to merge into main branch
-- `worktree`: asks to merge + remove the worktree
+```
+/rpi:research oauth   -- force (re)run research
+/rpi:plan oauth       -- force (re)generate plan
+/rpi:implement oauth  -- force (re)implement
+/rpi:simplify oauth   -- force simplify
+/rpi:review oauth     -- force review
+/rpi:docs oauth       -- force docs
+```
 
-## Configuration (.rpi.yaml)
+## Global Flags
 
-```yaml
-folder: rpi                    # Feature folder location
-tier: standard                 # Default research tier
-commit_style: conventional     # Commit message format
-parallel_threshold: 8          # Task count for parallel mode
-skip_artifacts: []             # Artifacts to never generate
-isolation: none                # none | branch | worktree
-tdd: false                     # Enable Test-Driven Development
-test_runner: auto              # Test command (auto-detect or explicit)
-session_isolation: auto        # auto | aggressive | off
-max_tasks_per_session: 5       # tasks before warning/checkpoint
-profile: balanced              # quality-first | balanced | speed-first | budget (optional)
-models:                        # Per-phase overrides (optional, takes precedence over profile)
-  # research: opus
-  # plan: opus
-  # implement: sonnet
-  # review: opus
 ```
+--quick          -- quick flow (skip research + full plan)
+--skip=phase     -- skip specific phase(s)
+--force          -- re-run phase even if artifacts exist
+--from=phase     -- start from a specific phase
+```
+
+## Quick Flow
 
-## Model Resolution Algorithm
+`/rpi:new my-feature --quick` triggers a streamlined pipeline for small (S) features:
 
-When a command spawns an agent, it resolves which model to use for the Agent tool's `model` parameter. The algorithm is:
+1. Luna asks 1-2 quick questions, produces compact REQUEST.md
+2. Skip research + full plan
+3. Forge receives REQUEST.md + context.md directly
+4. Forge generates mini-plan inline (3-5 tasks max)
+5. Implements task by task
+6. Razor does quick simplify
+7. Skip formal review (lint/tests only)
+8. Quill updates docs if needed
 
-### Resolution Order
+**Auto-trigger:** Luna estimates complexity S and suggests quick flow.
+**Safeguard:** If Forge detects complexity > S during implement, it stops and suggests running full research + plan.
 
-1. **Per-phase override**: If `.rpi.yaml` has a `models.{phase}` value, use it.
-2. **Profile default**: If `.rpi.yaml` has a `profile` value, look up the model for this phase in the profile table below.
-3. **Inherit parent**: If neither is set, omit the `model` parameter entirely. The agent inherits the parent session's model (current default behavior).
+## Delta Specs
 
-### Profile Lookup Table
+Delta specs capture only what changes, not the full system state.
 
-| Profile | research | plan | implement | review |
-|---------|----------|------|-----------|--------|
-| `quality-first` | opus | opus | opus | opus |
-| `balanced` | opus | opus | sonnet | opus |
-| `speed-first` | sonnet | sonnet | sonnet | sonnet |
-| `budget` | haiku | sonnet | haiku | sonnet |
+- `rpi/specs/` -- source of truth for current system state
+- `rpi/features/{slug}/delta/` -- what changes for this feature
+  - `ADDED/` -- new spec files
+  - `MODIFIED/` -- changes to existing specs
+  - `REMOVED/` -- specs being deleted
+- `/rpi:archive` merges delta into specs and cleans up the feature folder
 
-Note: The budget profile uses haiku for research and implement phases.
-Research quality may degrade with haiku -- research agents require structured
-analysis with citations and evidence. Recommended for small or simple features only.
+Flow: research creates baseline from existing specs, plan creates delta, archive merges delta back into specs.
 
-### Phase-to-Command Mapping
+## Knowledge Compounding
 
-| Phase | Commands |
-|-------|----------|
-| `research` | `/rpi:research` |
-| `plan` | `/rpi:plan` |
-| `implement` | `/rpi:implement`, `/rpi:test`, `/rpi:simplify` |
-| `review` | `/rpi:review`, `/rpi:docs` |
+RPIKit builds a persistent knowledge base that grows with every feature.
 
-Commands without a phase (`/rpi:init`, `/rpi:new`, `/rpi:status`, `/rpi:add-todo`, `/rpi:onboarding`, `/rpi:set-profile`) do not use model resolution. `/rpi:onboarding` spawns agents but always inherits the parent model -- it is not a workflow phase.
+- `rpi/solutions/` -- organized by category (performance/, security/, database/, testing/, architecture/, patterns/, decisions/)
+- **Auto-saved:** during review, when Hawk/Shield find problems and the dev fixes them
+- **Manual:** `/rpi:learn` -- Nexus asks what you learned and generates a solution doc
+- **Reuse:** Scout checks solutions/ before external research and includes relevant solutions in RESEARCH.md
 
-### Validation
+Solution format:
 
-Valid model names: `opus`, `sonnet`, `haiku`.
+```markdown
+# {Title}
 
-If a `models.{phase}` value or a `profile` value in `.rpi.yaml` is invalid:
-- Log a warning: `Warning: Invalid model "{value}" for {phase} phase. Falling back to parent model.`
-- Omit the `model` parameter (inherit parent model).
-- Do NOT stop execution.
+## Problem
+{symptoms, how it manifests}
 
-If `profile` is set to an unrecognized name:
-- Log a warning: `Warning: Unknown profile "{value}". Valid profiles: quality-first, balanced, speed-first, budget. Falling back to parent model.`
-- Treat all phases as "inherit parent".
+## Solution
+{code, approach, what worked}
 
-### Status Messages
+## Prevention
+{how to avoid in the future}
 
-When a model is resolved (not inherited), the command outputs once before spawning agents:
-```
-Profile: {profile} | {phase} phase -> {model}
+## Context
+Feature: {slug} | Date: {YYYY-MM-DD}
+Files: {list}
 ```
 
-When inheriting the parent model (no profile, no override), output nothing extra -- this preserves current behavior silently.
+## Party Mode
 
-## Feature Folder Structure
+`/rpi:party "topic"` -- multi-agent debate on any topic.
 
 ```
-{folder}/{feature-slug}/
-├── REQUEST.md
-├── research/
-│   └── RESEARCH.md
-├── plan/
-│   ├── PLAN.md
-│   ├── pm.md          (adaptive)
-│   ├── ux.md          (adaptive)
-│   └── eng.md
-└── implement/
-    ├── IMPLEMENT.md
-    ├── checkpoints/    (per-task status files)
-    └── sessions/       (session boundary records)
+/rpi:party "GraphQL vs REST for the API?"
+/rpi:party oauth "how to handle token refresh?"
 ```
 
-## Session Isolation
-
-RPI automatically manages session boundaries to prevent context drift in large features.
+1. Nexus analyzes the topic and selects 3-5 relevant agents
+2. Each agent responds in character with their perspective
+3. Nexus identifies consensus and divergence points
+4. If divergence: Nexus asks each agent to respond to the opposing argument
+5. Nexus synthesizes final recommendation with trade-offs
 
-### How It Works
+Output is saved to `rpi/solutions/decisions/` when requested.
 
-After `/rpi:plan`, the system computes a **context weight** from task count, files touched, and dependency depth. This determines the isolation tier:
+## Utility Commands
 
-| Tier | Context Weight | Behavior |
-|---|---|---|
-| 1 (Inline) | <= 8 | Single session, no checkpoints |
-| 2 (File-mediated) | 9-18 | Single session, warns after N tasks |
-| 3 (Wave-isolated) | > 18 | Multiple sessions, forced checkpoints per wave |
+```
+/rpi:init       -- configure RPIKit + generate context.md
+/rpi:status     -- view all features and their current phase
+/rpi:party      -- multi-agent debate on any topic
+/rpi:learn      -- manually capture a solution/insight
+/rpi:archive    -- merge delta into specs, delete feature folder
+/rpi:onboarding -- first-time setup, analyzes codebase, guides the user
+```
 
-### Agent Communication
+## Configuration
 
-Agents write results to per-task checkpoint files in `implement/checkpoints/`. The orchestrator reads only 1-line status summaries — full agent output never accumulates in the session context.
+`.rpi.yaml` reference:
 
-Each agent receives only: its specific task + eng.md. No conversation history, no full plan, no research output.
+```yaml
+version: 2
 
-### Deviation Handling
+# Directories
+folder: rpi/features
+specs_dir: rpi/specs
+solutions_dir: rpi/solutions
+context_file: rpi/context.md
 
-Agents classify deviations by severity:
-- **cosmetic** (naming, formatting): auto-accepted
-- **interface** (changed signatures): flags downstream tasks
-- **scope** (did more/less): blocks for human decision
+# Execution
+commit_style: conventional
+tdd: false
 
-### Resuming
+# Conditional agents
+ux_agent: auto                 # auto | always | never
 
-`/rpi:implement {slug} --resume` reads checkpoint files and continues from the last incomplete task with a fresh session context.
+# Quick flow
+quick_complexity: S
 
-## Cross-Session Continuity
+# Knowledge compounding
+auto_learn: true
 
-All state lives in markdown files. When resuming:
-- `/rpi:status` shows all features with current phase, progress, tier, and session count
-- `/rpi:implement` reads checkpoint files and resumes from last completed task
-- Multiple features can be in progress simultaneously
+# Party mode
+party_default_agents: 4
+```
 
-## Related
+## Directory Structure
 
-For agent behavioral guidelines, see the **rpi-agents** skill or individual agent files in `agents/`.
+```
+rpi/
+├── context.md
+├── specs/
+│   ├── auth/
+│   │   └── session-management.md
+│   └── payments/
+│       └── stripe-checkout.md
+├── solutions/
+│   ├── performance/
+│   ├── security/
+│   ├── database/
+│   ├── testing/
+│   ├── architecture/
+│   ├── patterns/
+│   └── decisions/
+└── features/
+    └── {slug}/
+        ├── REQUEST.md
+        ├── research/
+        │   └── RESEARCH.md
+        ├── delta/
+        │   ├── ADDED/
+        │   ├── MODIFIED/
+        │   └── REMOVED/
+        ├── plan/
+        │   ├── PLAN.md
+        │   ├── eng.md
+        │   ├── pm.md
+        │   └── ux.md
+        └── implement/
+            └── IMPLEMENT.md
+```

package/agents/code-reviewer.md

@@ -1,108 +0,0 @@
----
-name: code-reviewer
-description: Reviews implementation against the plan requirements. Checks completeness, correctness, deviations, and code quality. Outputs PASS or FAIL. Spawned by /rpi:implement and /rpi:review.
-tools: Read, Glob, Grep
-color: bright-red
----
-
-<role>
-You review implementation against the plan. You check that requirements are met, deviations are justified, and the code is correct. Every finding must cite a specific plan requirement.
-</role>
-
-<rules>
-1. Every finding must cite a specific requirement from PLAN.md, pm.md, or eng.md — no untraceable observations
-2. No style nitpicks — focus on correctness, completeness, and plan alignment
-3. Check: are ALL tasks from PLAN.md implemented? List any missing tasks by ID
-4. Check: are there deviations from the plan? Are they justified in IMPLEMENT.md?
-5. Verdict is PASS only if all requirements are met and no unjustified deviations exist
-6. For FAIL verdict, list specific gaps with actionable fixes — not vague suggestions
-</rules>
-
-<anti_patterns>
-- Bad: "The code could be more readable"
-- Good: "Task 1.3 (route handlers) is incomplete — POST /auth/google/callback is missing. Required by eng.md section 'API Design'."
-
-- Bad: "Consider adding more tests"
-- Good: "PLAN.md task 3.2 specifies 'test OAuth callback error handling' but no test covers the case where Google returns an invalid token."
-</anti_patterns>
-
-<execution_flow>
-
-## 1. Load all context
-
-Read all feature files:
-- REQUEST.md — original requirements
-- RESEARCH.md — research findings and constraints
-- PLAN.md — task checklist (the source of truth)
-- eng.md — technical spec
-- pm.md — acceptance criteria (if exists)
-- ux.md — UX requirements (if exists)
-- IMPLEMENT.md — implementation record
-
-## 2. Completeness check
-
-For each task in PLAN.md:
-- Is it marked `[x]` in IMPLEMENT.md?
-- Do the files listed in the task actually exist and contain the expected changes?
-- Use Grep/Glob to verify
-
-List any incomplete tasks.
-
-## 3. Correctness check
-
-For each implemented task:
-- Does the implementation match eng.md's technical approach?
-- If pm.md exists: are acceptance criteria met? Check each AC.
-- If ux.md exists: are user flows implemented? Check each step.
-- Use Grep to find the actual code and verify.
-
-## 4. Deviation check
-
-Read the Deviations section of IMPLEMENT.md:
-- Is each deviation documented?
-- Is each deviation justified with rationale?
-- Are there unlisted deviations? (Compare PLAN.md expectations with actual files)
-
-## 5. Code quality check
-
-Quick scan for:
-- Obvious bugs or logic errors
-- Security concerns (injection, auth bypass, data exposure)
-- Missing error handling for critical paths
-- Tests for critical functionality
-
-## 6. Verdict
-
-### PASS criteria:
-- All tasks complete
-- All acceptance criteria met
-- All deviations justified
-- No critical code issues
-
-### FAIL criteria:
-- Any task incomplete
-- Any acceptance criterion unmet
-- Any unjustified deviation
-- Any critical code issue (security, data loss)
-
-## 7. Output
-
-```markdown
-## Review: {feature-slug}
-
-### Verdict: {PASS|FAIL}
-
-### Completeness ({completed}/{total} tasks)
-- Task {id}: {DONE|MISSING} — {details}
-
-### Correctness
-- {finding with file:line reference and plan requirement citation}
-
-### Deviations
-- {deviation}: {justified|unjustified} — {reason}
-
-### Issues
-- [{CRITICAL|WARNING}] {file}:{line} — {description}. Required by: {plan reference}
-```
-
-</execution_flow>