rpi-kit 1.2.0 → 1.3.0

package/.claude-plugin/marketplace.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
   "name": "rpi-kit",
-  "version": "1.1.0",
+  "version": "1.3.0",
   "description": "Research → Plan → Implement. A systematic feature development workflow with validation gates, multi-role agent teams, and adaptive depth.",
   "owner": {
     "name": "Daniel Mendes"
@@ -11,7 +11,7 @@
       "name": "rpi-kit",
       "source": "./",
       "description": "Research → Plan → Implement. A systematic feature development workflow for Claude Code and Codex.",
-      "version": "1.1.0",
+      "version": "1.3.0",
       "author": {
         "name": "Daniel Mendes"
       },

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "rpi-kit",
-  "version": "1.1.0",
+  "version": "1.3.0",
   "description": "Research → Plan → Implement. A systematic feature development workflow with validation gates, multi-role agent teams, and adaptive depth.",
   "author": {
     "name": "Daniel Mendes",

package/README.md

@@ -73,6 +73,7 @@ Copy `AGENTS.md` and `codex.md` to your project root. The workflow rules and age
 | `/rpi:review` | Code review against plan requirements + test coverage |
 | `/rpi:docs` | Generate documentation from implementation artifacts |
 | `/rpi:add-todo` | Capture quick implementation ideas in `{folder}/todos/` |
+| `/rpi:set-profile` | Switch the active model profile for agent execution |
 
 ## Research Tiers
 
@@ -136,6 +137,33 @@ test_runner: auto  # or "npm test", "npx vitest", "pytest", etc.
 - **Implementation** writes a failing test first, verifies failure, then implements minimal code
 - **Review** checks test coverage and verifies tests exercise real code through public interfaces
 
+## Model Profiles
+
+Control which AI model runs each workflow phase. Profiles optimize the cost/quality tradeoff by using stronger models where reasoning matters most and faster models for mechanical tasks.
+
+| 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 |
+
+### Configure via command
+
+```bash
+/rpi:set-profile balanced
+```
+
+### Configure via `.rpi.yaml`
+
+```yaml
+profile: balanced              # quality-first | balanced | speed-first | budget
+models:                        # Per-phase overrides (optional)
+  implement: opus              # Override a single phase
+```
+
+Per-phase overrides in `models:` take precedence over the profile. No profile configured = all agents inherit the parent session's model (current default behavior).
+
 ## Feature Folder Structure
 
 Each feature lives in its own folder (configurable via `.rpi.yaml`):

package/commands/rpi/docs.md

@@ -21,13 +21,17 @@ Generate documentation for a completed feature using all RPI artifacts as source
 
 ## 1. Load config and parse arguments
 
-Read `.rpi.yaml` for folder path.
+Read `.rpi.yaml` for folder path. Also read `profile` and `models` keys.
 Parse `$ARGUMENTS`:
 - First argument: `{feature-slug}` (required)
 - `--skip-inline`: skip adding inline code documentation
 - `--skip-readme`: skip README updates
 - `--skip-changelog`: skip changelog entry
 
+## 1b. Resolve model
+
+Resolve the model for the `review` phase following the Model Resolution Algorithm in the rpi-workflow skill. Store as `{resolved_model}`. If a model is resolved, output the status message before agent spawns.
+
 ## 2. Validate prerequisites
 
 Verify the feature has passed review. Read `{folder}/{feature-slug}/implement/IMPLEMENT.md`.
@@ -66,7 +70,7 @@ Use Glob and Grep to read the actual implemented files and identify what needs d
 
 ## 5. Launch parallel documentation agents
 
-Use the Agent tool to launch applicable agents concurrently.
+Use the Agent tool to launch applicable agents concurrently. If a model was resolved in Step 1b, include `model: "{resolved_model}"` in each Agent tool call.
 
 ### Agent 1: Inline Documentation (unless --skip-inline)
 

package/commands/rpi/implement.md

@@ -21,7 +21,7 @@ Execute tasks from PLAN.md with per-task commits, automatic code simplification,
 
 ## 1. Load config and parse arguments
 
-Read `.rpi.yaml` for configuration.
+Read `.rpi.yaml` for configuration. Also read `profile` and `models` keys.
 Parse `$ARGUMENTS`:
 - First argument: `{feature-slug}` (required)
 - `--sequential`: force single agent mode
@@ -31,9 +31,29 @@ Parse `$ARGUMENTS`:
 - `--resume`: resume from last completed task in existing IMPLEMENT.md
 - `--from-task {id}`: resume from a specific task ID (used with --resume)
 
-## 2. Validate prerequisites
+## 1b. Resolve model
 
-Read `{folder}/{feature-slug}/plan/PLAN.md`. If missing:
+Resolve the model for the `implement` phase following the Model Resolution Algorithm in the rpi-workflow skill. Store as `{resolved_model}`. If a model is resolved, output the status message once before task execution begins.
+
+## 2. Resolve feature path and validate prerequisites
+
+Parse `{feature-slug}` from arguments.
+
+**Resolution order:**
+1. Check if `{folder}/{feature-slug}/` exists → type = "feature", path = `{folder}/{feature-slug}`
+2. If not, Glob `{folder}/*/changes/{feature-slug}/` → if found, type = "change", path = matched path, parent_path = parent directory
+3. If multiple matches → AskUserQuestion listing all matches with full paths
+4. If no match → error: `Feature not found: {feature-slug}. Run /rpi:new {feature-slug} first.`
+
+If `type == "change"`:
+- Set `parent_path` to the parent feature directory
+- Read parent artifacts for agent context:
+  - `{parent_path}/REQUEST.md`
+  - `{parent_path}/research/RESEARCH.md` (if exists)
+  - `{parent_path}/plan/PLAN.md` (if exists)
+  - `{parent_path}/plan/eng.md` (if exists)
+
+Read `{path}/plan/PLAN.md`. If missing:
 ```
 Plan not found. Run /rpi:plan {feature-slug} first.
 ```
@@ -143,7 +163,7 @@ Initialize session task counter: `tasks_this_session = 0`
 
 ### 6a. Agent prompt template (all tiers)
 
-For each task, construct the agent prompt:
+For each task, construct the agent prompt. If a model was resolved in Step 1b, include `model: "{resolved_model}"` in every Agent tool call (plan-executor and test-engineer).
 
 ```
 You are the plan-executor agent for the RPI workflow.
@@ -162,6 +182,16 @@ Test: {test_spec from PLAN.md, if present}
 ## Technical Context
 {contents of eng.md}
 
+If `type == "change"`, add:
+
+## Parent Feature Context
+{contents of parent artifacts read in step 2}
+
+This is a CHANGE to an existing feature. When implementing:
+- Ensure compatibility with existing parent feature code
+- Flag breaking changes as scope deviations
+- Reference parent architecture decisions from eng.md
+
 ## Rules
 - Only touch files listed for this task
 - Match patterns from CONTEXT_READ -- do not invent new patterns

package/commands/rpi/init.md

@@ -41,6 +41,16 @@ Use AskUserQuestion to gather preferences. Ask up to 4 questions at a time:
 - "Enable Test-Driven Development during implementation?" — Options: No (default), Yes
 - If yes: "What command runs your tests?" — Options: auto-detect (Recommended), `npm test`, `npx vitest`, `pytest`, custom
 
+**Batch 5 (Model Profiles):**
+- "Which model profile do you want for agent execution?" — Options:
+  - `balanced` (Recommended — opus for research/plan/review, sonnet for implement)
+  - `quality-first` (opus everywhere — maximum quality)
+  - `speed-first` (sonnet everywhere — maximum speed)
+  - `budget` (haiku + sonnet mix — cost optimized, may reduce research quality)
+  - "No profile" (default — all agents inherit parent model)
+
+If reconfiguring and a profile already exists, show: "Current profile: {profile}. Change model profile?" with the same options plus "Keep current ({profile})".
+
 ## 3. Create .rpi.yaml
 
 Write the config file at the project root:
@@ -61,6 +71,7 @@ tdd: {true|false}
 test_runner: {auto|command}
 session_isolation: {auto|aggressive|off}
 max_tasks_per_session: 5      # tasks before session warning (Tier 2) or forced checkpoint (Tier 3)
+profile: {balanced|quality-first|speed-first|budget}  # omit if "No profile" selected
 ```
 
 ## 4. Create feature folder
@@ -73,11 +84,25 @@ mkdir -p {folder}
 ## 5. Confirm
 
 Output a brief confirmation:
+
+With profile:
+```
+RPI initialized.
+Config: .rpi.yaml
+Features: {folder}/
+Tier: {tier}
+Profile: {profile} (research: {model}, plan: {model}, implement: {model}, review: {model})
+
+Next: /rpi:new to start your first feature.
+```
+
+Without profile:
 ```
 RPI initialized.
 Config: .rpi.yaml
 Features: {folder}/
 Tier: {tier}
+Profile: none (agents inherit parent model)
 
 Next: /rpi:new to start your first feature.
 ```

package/commands/rpi/new.md

@@ -29,7 +29,34 @@ If no argument, ask: "What feature do you want to build?" and derive the slug fr
 
 ## 3. Check for existing feature
 
-Check if `{folder}/{feature-slug}/` already exists. If yes, warn the user and ask if they want to continue (overwrite REQUEST.md) or pick a different name.
+Check if `{folder}/{feature-slug}/` already exists.
+
+If it does NOT exist, continue to step 4 (new feature interview).
+
+If it DOES exist, ask the user with AskUserQuestion:
+
+"Feature '{feature-slug}' already exists ({folder}/{feature-slug}/). What do you want to do?"
+
+Options:
+- "Create a change for this feature" — go to step 3b
+- "Overwrite existing REQUEST.md" — continue to step 4 (current behavior)
+- "Pick a different name" — go back to step 2
+
+## 3b. Set up change
+
+Ask: "What change do you want to make to {feature-slug}?" and derive change-slug (kebab-case) from the answer.
+
+Check if `{folder}/{feature-slug}/changes/{change-slug}/` already exists. If yes, warn and ask to overwrite or pick a different name.
+
+Read parent feature context for the interview:
+- `{folder}/{feature-slug}/REQUEST.md`
+- `{folder}/{feature-slug}/research/RESEARCH.md` (if exists)
+- `{folder}/{feature-slug}/plan/PLAN.md` (if exists)
+- `{folder}/{feature-slug}/implement/IMPLEMENT.md` (if exists)
+
+Store the parent artifacts content as `parent_context` for use in steps 4 and 6.
+
+Set `is_change = true` and `parent_slug = {feature-slug}`.
 
 ## 4. Adaptive interview
 
@@ -48,6 +75,22 @@ Start with core questions, then ask follow-ups based on answers.
 
 Use AskUserQuestion for structured questions. Keep it conversational — 2-3 questions per batch, max 3 batches. Stop when you have enough to write a clear REQUEST.md.
 
+### Change mode interview (if `is_change == true`)
+
+Replace the core questions with context-aware ones:
+
+**Core (always ask):**
+- "What do you want to change in {parent_slug}?" (skip if already answered in step 3b)
+- "Why is this change needed?"
+
+**Adaptive follow-ups (based on parent artifacts):**
+- If parent has IMPLEMENT.md: "Which parts of the existing implementation are affected?"
+- If parent has PLAN.md with architecture decisions: "Does this change any architecture decisions from the original plan?"
+- If change sounds like it could break things: "Will this break any existing behavior?"
+- Always offer: "Any constraints or references?"
+
+Use AskUserQuestion. Keep it lighter than new features — max 2 batches.
+
 ## 5. Set up isolation
 
 Read `isolation` from `.rpi.yaml` (default: `none`).
@@ -128,6 +171,45 @@ Write `{folder}/{feature-slug}/REQUEST.md` with this structure:
 {S | M | L | XL} — {brief justification}
 ```
 
+### Change mode directory creation (if `is_change == true`)
+
+Skip isolation setup (changes use the parent feature's branch/worktree context).
+
+Create the change directory structure:
+```bash
+mkdir -p {folder}/{parent_slug}/changes/{change-slug}/research
+mkdir -p {folder}/{parent_slug}/changes/{change-slug}/plan
+mkdir -p {folder}/{parent_slug}/changes/{change-slug}/implement
+```
+
+Write `{folder}/{parent_slug}/changes/{change-slug}/REQUEST.md` with this structure:
+
+```markdown
+# {Change Title}
+
+## Parent Feature
+[{Parent Feature Title}]({relative-path-to-parent-REQUEST.md})
+{1-2 sentence summary of parent feature from parent_context}
+
+## Summary of Change
+{What changes in the existing feature}
+
+## Motivation
+{Why this change is needed}
+
+## Affected Areas
+- {Components/files of parent feature that are affected}
+
+## Breaking Changes
+- {List or "None"}
+
+## Constraints
+- {Technical/business constraints}
+
+## Complexity Estimate
+{S | M | L | XL} — {brief justification}
+```
+
 ## 7. Next step
 
 Output:
@@ -141,4 +223,14 @@ Options:
   --deep      Full analysis with strategic review
 ```
 
+### Change mode output (if `is_change == true`)
+
+Output:
+```
+Change created: {folder}/{parent_slug}/changes/{change-slug}/REQUEST.md
+Parent: {folder}/{parent_slug}/
+
+Next: /rpi:research {change-slug}
+```
+
 </process>

package/commands/rpi/plan.md

@@ -20,21 +20,41 @@ Generate implementation plan artifacts from the research output. Adapts which ar
 
 ## 1. Load config and parse arguments
 
-Read `.rpi.yaml` for configuration.
+Read `.rpi.yaml` for configuration. Also read `profile` and `models` keys.
 Parse `$ARGUMENTS`:
 - First argument: `{feature-slug}` (required)
 - `--force`: proceed even if research verdict was NO-GO
 - `--skip-pm`: don't generate pm.md
 - `--skip-ux`: don't generate ux.md
 
-## 2. Validate prerequisites
+## 1b. Resolve model
 
-Read `{folder}/{feature-slug}/research/RESEARCH.md`. If missing:
+Resolve the model for the `plan` phase following the Model Resolution Algorithm in the rpi-workflow skill. Store as `{resolved_model}`. If a model is resolved, output the status message before agent spawns.
+
+## 2. Resolve feature path and validate prerequisites
+
+Parse `{feature-slug}` from arguments.
+
+**Resolution order:**
+1. Check if `{folder}/{feature-slug}/` exists → type = "feature", path = `{folder}/{feature-slug}`
+2. If not, Glob `{folder}/*/changes/{feature-slug}/` → if found, type = "change", path = matched path, parent_path = parent directory
+3. If multiple matches → AskUserQuestion listing all matches with full paths
+4. If no match → error: `Feature not found: {feature-slug}. Run /rpi:new {feature-slug} first.`
+
+If `type == "change"`:
+- Set `parent_path` to the parent feature directory
+- Read parent artifacts for agent context:
+  - `{parent_path}/REQUEST.md`
+  - `{parent_path}/research/RESEARCH.md` (if exists)
+  - `{parent_path}/plan/PLAN.md` (if exists)
+  - `{parent_path}/plan/eng.md` (if exists)
+
+Read `{path}/research/RESEARCH.md`. If missing:
 ```
 Research not found. Run /rpi:research {feature-slug} first.
 ```
 
-Check the verdict in RESEARCH.md. If NO-GO and no `--force` flag:
+Check verdict. If NO-GO and no `--force`:
 ```
 Research verdict is NO-GO. Review alternatives in RESEARCH.md.
 To proceed anyway: /rpi:plan {feature-slug} --force
@@ -85,7 +105,7 @@ After the interview, create a brief alignment summary that will be included in a
 
 ## 4. Generate eng.md (always)
 
-Launch senior-engineer agent:
+Launch senior-engineer agent. If a model was resolved in Step 1b, include `model: "{resolved_model}"` in the Agent tool call.
 ```
 You are planning the technical implementation for a feature.
 
@@ -108,9 +128,23 @@ Be concrete. Cite existing codebase files and patterns from the research.
 Follow senior-engineer rules from RPI agent guidelines.
 ```
 
+If `type == "change"`, append to the agent prompt:
+
+```
+## Parent Feature Context
+{contents of parent artifacts read in step 2}
+
+This is a CHANGE to an existing feature. Focus on:
+- What's different from the parent implementation
+- Compatibility with existing code
+- Breaking changes to watch for
+```
+
+> **Note:** Also append this same parent context block to the pm.md (step 5), ux.md (step 6), and PLAN.md (step 7) agent prompts when `type == "change"`.
+
 ## 5. Generate pm.md (if not skipped)
 
-Launch product-manager agent:
+Launch product-manager agent. If a model was resolved, include `model: "{resolved_model}"` in the Agent tool call.
 ```
 You are creating product requirements for a feature.
 
@@ -133,7 +167,7 @@ Follow product-manager rules from RPI agent guidelines.
 
 ## 6. Generate ux.md (if not skipped)
 
-Launch ux-designer agent:
+Launch ux-designer agent. If a model was resolved, include `model: "{resolved_model}"` in the Agent tool call.
 ```
 You are designing the user experience for a feature.
 
@@ -156,7 +190,7 @@ Follow ux-designer rules from RPI agent guidelines.
 
 ## 7. Generate PLAN.md
 
-After all agents complete (eng.md is required, pm.md and ux.md may be parallel), launch senior-engineer agent again to create the task breakdown:
+After all agents complete (eng.md is required, pm.md and ux.md may be parallel), launch senior-engineer agent again to create the task breakdown. If a model was resolved, include `model: "{resolved_model}"` in the Agent tool call.
 
 ```
 You are creating an implementation plan from the technical spec.

package/commands/rpi/research.md

@@ -20,21 +20,37 @@ Run parallel research agents on a feature's REQUEST.md, synthesize findings into
 
 ## 1. Load config and parse arguments
 
-Read `.rpi.yaml` for folder path and default tier.
+Read `.rpi.yaml` for folder path and default tier. Also read `profile` and `models` keys.
 Parse `$ARGUMENTS`:
 - First argument: `{feature-slug}` (required)
 - Flags: `--quick`, `--standard`, `--deep` (override config tier)
 - Flag: `--force` (proceed even if previous research exists)
 
-## 2. Validate feature
+## 1b. Resolve model
 
-Read `{folder}/{feature-slug}/REQUEST.md`. If it doesn't exist, error:
-```
-Feature not found: {folder}/{feature-slug}/REQUEST.md
-Run /rpi:new {feature-slug} first.
-```
+Resolve the model for the `research` phase following the Model Resolution Algorithm in the rpi-workflow skill. Store as `{resolved_model}`. If a model is resolved, output the status message before agent spawns.
+
+## 2. Resolve feature path
+
+Parse `{feature-slug}` from arguments.
+
+**Resolution order:**
+1. Check if `{folder}/{feature-slug}/` exists → type = "feature", path = `{folder}/{feature-slug}`
+2. If not, Glob `{folder}/*/changes/{feature-slug}/` → if found, type = "change", path = matched path, parent_path = parent directory
+3. If multiple matches in step 2 → AskUserQuestion listing all matches with full paths
+4. If no match → error: `Feature not found: {feature-slug}. Run /rpi:new {feature-slug} first.`
+
+If `type == "change"`:
+- Set `parent_path` to the parent feature directory
+- Read parent artifacts for agent context:
+  - `{parent_path}/REQUEST.md`
+  - `{parent_path}/research/RESEARCH.md` (if exists)
+  - `{parent_path}/plan/PLAN.md` (if exists)
+  - `{parent_path}/plan/eng.md` (if exists)
 
-If `{folder}/{feature-slug}/research/RESEARCH.md` already exists and `--force` not set, ask user:
+Validate that `{path}/REQUEST.md` exists. If not, error.
+
+If `{path}/research/RESEARCH.md` already exists and `--force` not set, ask user:
 "Research already exists for this feature. Overwrite?"
 
 ## 3. Determine agent composition by tier
@@ -59,7 +75,7 @@ If `{folder}/{feature-slug}/research/RESEARCH.md` already exists and `--force` n
 
 ## 4. Launch research agents in parallel
 
-Use the Agent tool to launch ALL selected agents concurrently in a single message.
+Use the Agent tool to launch ALL selected agents concurrently in a single message. If a model was resolved in Step 1b, include `model: "{resolved_model}"` in each Agent tool call.
 
 Each agent receives this prompt:
 ```
@@ -87,9 +103,21 @@ Follow your role-specific rules as defined in the rpi-agents skill.
 
 For explore-codebase agent, also instruct it to scan the project codebase for relevant files, patterns, and conventions.
 
+If `type == "change"`, append to each agent prompt:
+
+```
+## Parent Feature Context
+{contents of parent artifacts read in step 2}
+
+This is a CHANGE to an existing feature. Focus on:
+- What's different from the parent implementation
+- Compatibility with existing code
+- Breaking changes to watch for
+```
+
 ## 5. Synthesize into RESEARCH.md
 
-After all agents complete, use the Agent tool to launch the doc-synthesizer agent.
+After all agents complete, use the Agent tool to launch the doc-synthesizer agent. If a model was resolved, include `model: "{resolved_model}"` in the Agent tool call.
 
 Prompt:
 ```

package/commands/rpi/review.md

@@ -17,13 +17,26 @@ Review the implementation against the plan. Check completeness, correctness, and
 
 <process>
 
-## 1. Load config and validate
+## 1. Load config and resolve feature path
 
-Read `.rpi.yaml` for folder path.
-Validate that all required files exist:
-- `{folder}/{feature-slug}/plan/PLAN.md`
-- `{folder}/{feature-slug}/plan/eng.md`
-- `{folder}/{feature-slug}/implement/IMPLEMENT.md`
+Read `.rpi.yaml` for folder path. Also read `profile` and `models` keys.
+
+Parse `{feature-slug}` from arguments.
+
+**Resolution order:**
+1. Check if `{folder}/{feature-slug}/` exists → type = "feature", path = `{folder}/{feature-slug}`
+2. If not, Glob `{folder}/*/changes/{feature-slug}/` → if found, type = "change", path = matched path, parent_path = parent directory
+3. If multiple matches → AskUserQuestion listing all matches with full paths
+4. If no match → error: `Feature not found: {feature-slug}`
+
+If `type == "change"`:
+- Set `parent_path` to the parent feature directory
+- Read parent artifacts for agent context
+
+Validate that required files exist:
+- `{path}/plan/PLAN.md`
+- `{path}/plan/eng.md`
+- `{path}/implement/IMPLEMENT.md`
 
 If any missing, error with guidance on which command to run.
 
@@ -38,8 +51,14 @@ Read all plan and implementation files:
 - ux.md (if exists — UX requirements)
 - IMPLEMENT.md (implementation record)
 
+## 2b. Resolve model
+
+Resolve the model for the `review` phase following the Model Resolution Algorithm in the rpi-workflow skill. Store as `{resolved_model}`. If a model is resolved, output the status message before agent spawns.
+
 ## 3. Launch code-reviewer agent
 
+If a model was resolved in Step 2b, include `model: "{resolved_model}"` in the Agent tool call.
+
 ```
 You are the code-reviewer agent for the RPI workflow.
 
@@ -54,6 +73,15 @@ Read these files for the complete feature context:
 
 Then review the actual code changes. Use Grep and Glob to find the files listed in the plan and verify the implementation.
 
+If `type == "change"`, also read parent feature files for context:
+- {parent_path}/REQUEST.md
+- {parent_path}/research/RESEARCH.md (if exists)
+- {parent_path}/plan/eng.md (if exists)
+
+This is a CHANGE to an existing feature. Additionally check:
+- Compatibility with parent feature's existing implementation
+- Whether breaking changes listed in the change REQUEST.md are properly handled
+
 Your review must check:
 
 ### 1. Completeness

package/commands/rpi/set-profile.md

@@ -0,0 +1,124 @@
+---
+name: rpi:set-profile
+description: Switch the active model profile. Controls which AI model runs each workflow phase (research, plan, implement, review).
+argument-hint: "[quality-first|balanced|speed-first|budget]"
+allowed-tools:
+  - Read
+  - Write
+  - AskUserQuestion
+---
+
+<objective>
+Display the current model profile and phase-model mapping, or switch to a new profile. Persists the selection in `.rpi.yaml`.
+</objective>
+
+<process>
+
+## 1. Load current config
+
+Read `.rpi.yaml` from the project root. If it doesn't exist:
+```
+No RPI config found. Run /rpi:init first.
+```
+
+Extract `profile` and `models` keys (both may be absent).
+
+## 2. Parse arguments
+
+Parse `$ARGUMENTS`:
+- If empty: display current profile (step 3), then ask if user wants to switch (step 4)
+- If argument provided: validate and switch to that profile (step 5)
+
+## 3. Display current profile
+
+Resolve the effective model for each phase using the Model Resolution Algorithm defined in the rpi-workflow skill.
+
+Output:
+```
+Current profile: {profile_name or "none (inheriting parent model)"}
+
+Phase mappings:
+  research:   {resolved_model or "inherit"}
+  plan:       {resolved_model or "inherit"}
+  implement:  {resolved_model or "inherit"}
+  review:     {resolved_model or "inherit"}
+```
+
+If any per-phase overrides exist in `models:` block:
+```
+Per-phase overrides active: {list overridden phases}
+(Overrides take precedence over the profile. Edit .rpi.yaml to change.)
+```
+
+## 4. Ask to switch (only if no argument)
+
+Use AskUserQuestion:
+"Switch to a different profile?"
+
+Options:
+- `quality-first` -- opus for all phases (maximum quality)
+- `balanced` -- opus for research/plan/review, sonnet for implement (recommended)
+- `speed-first` -- sonnet for all phases (fastest)
+- `budget` -- haiku for research/implement, sonnet for plan/review (cheapest, may reduce research quality)
+- `none` -- inherit parent model (current behavior)
+- "Keep current" -- no change
+
+If "Keep current", output "No changes made." and stop.
+
+If switching to `budget`, display warning:
+```
+Note: The budget profile uses haiku for research and implement phases.
+Haiku may produce lower-quality research outputs for complex features.
+RPI research agents have strict requirements (evidence-backed verdicts,
+structured analysis). Consider using --deep tier sparingly with this profile.
+```
+
+## 5. Validate profile name
+
+Check that the provided profile name is one of: `quality-first`, `balanced`, `speed-first`, `budget`, `none`.
+
+If invalid:
+```
+Unknown profile: "{input}"
+
+Valid profiles: quality-first, balanced, speed-first, budget, none
+
+Usage: /rpi:set-profile [profile-name]
+Run /rpi:set-profile with no arguments to see current profile and select interactively.
+```
+
+Stop. Do not modify config.
+
+## 6. Persist to .rpi.yaml
+
+Read the current `.rpi.yaml` content. Update the `profile` key:
+- If `profile:` line exists: replace the value
+- If `profile:` line does not exist: add it after the last existing config key, before any comments at the end
+- If selected profile is `none`: remove the `profile:` line (or set to empty)
+
+Do NOT modify the `models:` block. Per-phase overrides are preserved as-is.
+
+Write the updated `.rpi.yaml`.
+
+## 7. Confirm
+
+Display the new effective mapping:
+```
+Profile switched to: {profile_name}
+
+Phase mappings:
+  research:   {model}
+  plan:       {model}
+  implement:  {model}
+  review:     {model}
+```
+
+If `models:` overrides exist:
+```
+Note: Per-phase overrides in .rpi.yaml take precedence over the profile.
+Overridden phases: {list}
+```
+
+Tip: Edit .rpi.yaml to customize individual phases.
+
+</process>

package/commands/rpi/simplify.md

@@ -18,10 +18,19 @@ Run 3 parallel code review sub-agents (reuse, quality, efficiency) on the implem
 
 <process>
 
-## 1. Load config and identify changes
+## 1. Load config, resolve path, and identify changes
 
-Read `.rpi.yaml` for folder path.
-Read `{folder}/{feature-slug}/implement/IMPLEMENT.md` to identify what was implemented.
+Read `.rpi.yaml` for folder path. Also read `profile` and `models` keys.
+
+Parse `{feature-slug}` from arguments.
+
+**Resolution order:**
+1. Check if `{folder}/{feature-slug}/` exists → type = "feature", path = `{folder}/{feature-slug}`
+2. If not, Glob `{folder}/*/changes/{feature-slug}/` → if found, type = "change", path = matched path, parent_path = parent directory
+3. If multiple matches → AskUserQuestion listing all matches with full paths
+4. If no match → error: `Feature not found: {feature-slug}`
+
+Read `{path}/implement/IMPLEMENT.md` to identify what was implemented.
 
 Get the diff of all implementation changes:
 ```bash
@@ -30,9 +39,13 @@ git diff HEAD~{number_of_commits}
 
 If no git history, use the files listed in IMPLEMENT.md tasks and read them directly.
 
+## 1b. Resolve model
+
+Resolve the model for the `implement` phase following the Model Resolution Algorithm in the rpi-workflow skill. Store as `{resolved_model}`. If a model is resolved, output the status message before agent spawns.
+
 ## 2. Launch 3 parallel sub-agents
 
-Use the Agent tool to launch all 3 concurrently in a single message.
+Use the Agent tool to launch all 3 concurrently in a single message. If a model was resolved in Step 1b, include `model: "{resolved_model}"` in each Agent tool call.
 
 ### Agent 1: Reuse Checker
 

package/commands/rpi/status.md

@@ -16,18 +16,31 @@ Display detailed status cards for all features (or a specific feature) in the RP
 
 ## 1. Load config
 
-Read `.rpi.yaml` for folder path. Default to `rpi/` if not found.
+Read `.rpi.yaml` for folder path. Default to `rpi/` if not found. Also read `profile` and `models` keys.
 
-## 2. Discover features
+## 2. Discover features and changes
 
-Use Glob to find all `REQUEST.md` files:
+Use Glob to find all top-level `REQUEST.md` files:
 ```
 {folder}/*/REQUEST.md
 ```
 
 Each parent directory is a feature slug.
 
-If `$ARGUMENTS` specifies a feature slug, filter to that feature only.
+Also find all change `REQUEST.md` files:
+```
+{folder}/*/changes/*/REQUEST.md
+```
+
+Parse each match to extract parent_slug and change_slug.
+
+If `$ARGUMENTS` specifies a slug:
+1. Check if it matches a top-level feature → show that feature and its changes
+2. If not, check if it matches a change slug → show just that change (with parent context)
+3. Resolution follows the shared Resolve Feature Path logic:
+   - Check `{folder}/{slug}/` exists → type = "feature"
+   - Glob `{folder}/*/changes/{slug}/` → type = "change"
+   - Multiple matches → AskUserQuestion
 
 If no features found:
 ```
@@ -44,6 +57,9 @@ For each feature slug, check which files exist:
 - `plan/PLAN.md` exists, no `implement/IMPLEMENT.md` → Phase: **planned**
 - `implement/IMPLEMENT.md` exists → Phase: **implementing** or **complete**
 
+For each change, determine phase using the same logic as features,
+but looking in `{folder}/{parent_slug}/changes/{change_slug}/` instead.
+
 ## 4. Gather details per feature
 
 For each feature, read the relevant files to extract:
@@ -70,7 +86,12 @@ For each feature, read the relevant files to extract:
 
 ## 5. Display detailed cards
 
-Output a card per feature:
+First, display the active profile at the top of the output. Resolve the effective model for each phase using the Model Resolution Algorithm in the rpi-workflow skill:
+- With profile: `Profile: {profile} (research: {model}, plan: {model}, implement: {model}, review: {model})`
+- With overrides, mark overridden phases with `*`: `Profile: balanced (research: opus, plan: opus, implement: opus*, review: opus)`
+- No profile: `Profile: none (inheriting parent model)`
+
+Then output a card per feature:
 
 ```markdown
 ## {feature-slug}
@@ -89,6 +110,8 @@ Verdict: {GO|GO with concerns|NO-GO|—}
 ```markdown
 # RPI Status
 
+Profile: balanced (research: opus, plan: opus, implement: sonnet, review: opus)
+
 ## oauth2-auth
 Phase: implement (6/9 tasks)
 Verdict: GO
@@ -96,6 +119,8 @@ Complexity: M
 Tier: 2 (context weight: 14.5)
 Sessions: 2
 Current: Task 2.1 — Login component
+  └─ add-social-login  [research: GO]
+  └─ fix-token-refresh  [new]
 
 ## payment-system
 Phase: research
@@ -112,6 +137,9 @@ Phase: new
 Verdict: —
 ```
 
+Changes are displayed indented under their parent feature with `└─` prefix.
+Each change shows its own phase status using the same rules as features.
+
 ## 6. Suggest next action
 
 For each feature, suggest the logical next command:

package/commands/rpi/test.md

@@ -21,7 +21,7 @@ Execute strict TDD cycles (RED → GREEN → REFACTOR) for tasks in a feature's
 
 ## 1. Load config and parse arguments
 
-Read `.rpi.yaml` for configuration (folder, test_runner).
+Read `.rpi.yaml` for configuration (folder, test_runner). Also read `profile` and `models` keys.
 Parse `$ARGUMENTS`:
 - First argument: `{feature-slug}` (required)
 - `--task <id>`: run TDD for a specific task (e.g., `1.2`)
@@ -29,6 +29,10 @@ Parse `$ARGUMENTS`:
 
 If no `--task` or `--all`, ask the user which task to work on.
 
+## 1b. Resolve model
+
+Resolve the model for the `implement` phase following the Model Resolution Algorithm in the rpi-workflow skill. Store as `{resolved_model}`. If a model is resolved, output the status message before agent spawns.
+
 ## 2. Validate prerequisites
 
 Read `{folder}/{feature-slug}/plan/PLAN.md`. If missing:
@@ -53,7 +57,7 @@ If no test infrastructure found, ask the user:
 
 ### Phase RED: Write failing test
 
-Launch test-engineer agent:
+Launch test-engineer agent. If a model was resolved in Step 1b, include `model: "{resolved_model}"` in the Agent tool call.
 ```
 You are the test-engineer agent for the RPI workflow.
 
@@ -103,7 +107,7 @@ RED: Test fails correctly.
 
 ### Phase GREEN: Minimal implementation
 
-Launch plan-executor agent:
+Launch plan-executor agent. If a model was resolved, include `model: "{resolved_model}"` in the Agent tool call.
 ```
 You are implementing a single task using TDD.
 

package/package.json

@@ -1,12 +1,12 @@
 {
   "name": "rpi-kit",
-  "version": "1.2.0",
+  "version": "1.3.0",
   "description": "Research → Plan → Implement. A systematic feature development workflow for Claude Code.",
   "license": "MIT",
   "author": "Daniel Mendes",
   "repository": {
     "type": "git",
-    "url": "https://github.com/dmend3z/rpi-kit.git"
+    "url": "git+https://github.com/dmend3z/rpi-kit.git"
   },
   "keywords": [
     "claude-code",
@@ -19,7 +19,7 @@
     "agents"
   ],
   "bin": {
-    "rpi-kit": "./bin/cli.js"
+    "rpi-kit": "bin/cli.js"
   },
   "files": [
     ".claude-plugin/",

package/skills/rpi-workflow/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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, 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).
+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
 ---
@@ -122,8 +122,70 @@ 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
 ```
 
+## Model Resolution Algorithm
+
+When a command spawns an agent, it resolves which model to use for the Agent tool's `model` parameter. The algorithm is:
+
+### Resolution Order
+
+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).
+
+### Profile Lookup Table
+
+| 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 |
+
+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.
+
+### Phase-to-Command Mapping
+
+| Phase | Commands |
+|-------|----------|
+| `research` | `/rpi:research` |
+| `plan` | `/rpi:plan` |
+| `implement` | `/rpi:implement`, `/rpi:test`, `/rpi:simplify` |
+| `review` | `/rpi:review`, `/rpi:docs` |
+
+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.
+
+### Validation
+
+Valid model names: `opus`, `sonnet`, `haiku`.
+
+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.
+
+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".
+
+### Status Messages
+
+When a model is resolved (not inherited), the command outputs once before spawning agents:
+```
+Profile: {profile} | {phase} phase -> {model}
+```
+
+When inheriting the parent model (no profile, no override), output nothing extra -- this preserves current behavior silently.
+
 ## Feature Folder Structure
 
 ```