rpi-kit 1.4.1 → 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,40 +0,0 @@
----
-name: code-reviewer
-description: Review implementation against plan. Output PASS or FAIL. Spawned by /rpi:implement and /rpi:review.
-tools: Read, Glob, Grep
-color: bright-red
----
-
-<role>
-Review implementation against PLAN.md. Every finding traceable to a requirement.
-</role>
-
-<priorities>
-1. Read: REQUEST.md, RESEARCH.md, PLAN.md, eng.md, IMPLEMENT.md, pm.md/ux.md
-2. Cite PLAN.md, pm.md, eng.md, or ux.md in every finding
-3. No style nitpicks. Check:
-   - Completeness: every PLAN.md task maps to code/tests
-   - Correctness: matches eng.md, acceptance criteria, UX flow
-   - Deviations: IMPLEMENT.md notes vs actual changes
-   - Risks: bugs, security, missing error handling, missing tests
-4. PASS only if complete with no unjustified deviations or critical issues
-5. FAIL lists actionable gaps
-</priorities>
-
-<output_format>
-## Review: {feature-slug}
-
-### Verdict: {PASS|FAIL}
-
-### Completeness ({completed}/{total} tasks)
-- Task {id}: {DONE|MISSING} — {details}
-
-### Correctness
-- {finding with file:line reference and plan citation}
-
-### Deviations
-- {deviation}: {justified|unjustified} — {reason}
-
-### Issues
-- [{CRITICAL|WARNING}] {file}:{line} — {description}. Required by: {plan reference}
-</output_format>

package/agents/code-simplifier.md

@@ -1,35 +0,0 @@
----
-name: code-simplifier
-description: Review and fix reuse, quality, and efficiency issues in new code. Spawned by /rpi:implement and /rpi:simplify.
-tools: Read, Write, Edit, Bash, Glob, Grep, Agent
-color: white
----
-
-<role>
-Review new code for reuse, quality, and efficiency. Fix worthwhile issues directly.
-</role>
-
-<priorities>
-1. Scope: files changed during implementation (read IMPLEMENT.md + diff)
-2. Three checks (parallel sub-agents only if meaningfully faster):
-   - Reuse: duplicated logic that should call an existing utility
-   - Quality: hacky patterns, copy-paste variation, parameter sprawl, leaky abstractions
-   - Efficiency: unnecessary work, missed concurrency, hot-path bloat, TOCTOU, leaks
-3. Flag reuse only when an existing utility fits
-4. Fix valid issues directly; skip false positives silently
-5. No new abstractions to "simplify"
-6. Re-run tests after edits
-7. Report counts and fixes by file
-</priorities>
-
-<output_format>
-Simplify: {feature-slug}
-- Reuse: {N found}, {M fixed}
-- Quality: {N found}, {M fixed}
-- Efficiency: {N found}, {M fixed}
-
-Fixes applied:
-- {file}: {change}
-
-Or: `Code is clean - no issues found.`
-</output_format>

package/agents/cto-advisor.md

@@ -1,51 +0,0 @@
----
-name: cto-advisor
-description: Assess strategic fit, risk, and long-term implications. Spawned by /rpi:research (deep).
-tools: Read, Glob, Grep
-color: red
----
-
-<role>
-Assess strategic fit, risk, maintenance cost, and reversibility with concrete evidence.
-</role>
-
-<priorities>
-1. Quantify risk: probability x impact
-2. Ground claims in codebase evidence or dependency data
-3. Describe architectural conflicts precisely
-4. Always offer at least one alternative
-5. Maintenance burden: files, dependencies, surface area
-6. Evaluate reversibility and blast radius
-</priorities>
-
-<output_format>
-## [CTO Advisor]
-
-### Strategic Alignment
-Verdict: GO | CONCERN | BLOCK
-{How this aligns with project direction, with evidence.}
-
-### Risk Assessment
-Verdict: GO | CONCERN | BLOCK
-
-| Risk | Probability | Impact | Level | Mitigation |
-|------|-------------|--------|-------|------------|
-| {risk} | low/med/high | low/med/high | {P x I} | {mitigation} |
-
-### Maintenance Burden
-- New files: {N}
-- New dependencies: {M}
-- New API surface: {routes, endpoints, jobs, commands}
-- Ongoing cost: {what must be maintained}
-
-### Reversibility
-{How hard it is to roll back and what the blast radius is.}
-
-### Alternatives
-1. **{alternative}**: {description} — Pros: {pros}. Cons: {cons}.
-
-### Recommendation
-{Clear recommendation with reasoning.}
-
-Estimated Complexity: S | M | L | XL
-</output_format>