rpi-kit 1.4.1 → 2.1.0

package/commands/rpi/set-profile.md

@@ -1,124 +0,0 @@
----
-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/test.md

@@ -1,198 +0,0 @@
----
-name: rpi:test
-description: Run TDD (Red-Green-Refactor) on a specific task or set of tasks from the plan. Writes one failing test, verifies failure, implements minimal code, verifies pass, refactors.
-argument-hint: "<feature-slug> [--task <id>] [--all]"
-allowed-tools:
-  - Read
-  - Write
-  - Edit
-  - Bash
-  - Glob
-  - Grep
-  - Agent
-  - AskUserQuestion
----
-
-<objective>
-Execute strict TDD cycles (RED → GREEN → REFACTOR) for tasks in a feature's PLAN.md. One test at a time, verify fail, implement, verify pass.
-</objective>
-
-<process>
-
-## 1. Load config and parse arguments
-
-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`)
-- `--all`: run TDD for all uncompleted tasks sequentially
-
-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:
-```
-Plan not found. Run /rpi:plan {feature-slug} first.
-```
-
-Read `{folder}/{feature-slug}/plan/eng.md` for technical context (especially Testing Strategy section).
-
-## 3. Detect test infrastructure
-
-Scan the project for existing test setup:
-- Look for test config files: `jest.config.*`, `vitest.config.*`, `pytest.ini`, `pyproject.toml [tool.pytest]`, `*.test.*`, `*.spec.*`
-- Identify the test runner command (from config `test_runner` or auto-detect)
-- Identify test file naming convention (`*.test.ts`, `*.spec.ts`, `*_test.py`, etc.)
-- Identify assertion style (`expect`, `assert`, etc.)
-
-If no test infrastructure found, ask the user:
-"No test setup detected. What test framework and runner should I use?"
-
-## 4. For each target task, run TDD cycle
-
-### Phase RED: Write failing test
-
-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.
-
-Read these files:
-- {folder}/{feature-slug}/plan/PLAN.md
-- {folder}/{feature-slug}/plan/eng.md
-
-Current task:
-**{task_id}** {task_description}
-Files: {files}
-
-Test infrastructure:
-- Framework: {detected_framework}
-- File convention: {convention}
-- Assertion style: {style}
-
-Write ONE failing test for this task:
-1. Create or edit the appropriate test file following project conventions
-2. Write a single test that describes the expected behavior
-3. The test must exercise real code through the public interface
-4. Use clear, behavior-describing test name
-5. Minimal assertions — one logical check
-
-Do NOT write any implementation code. Only the test.
-
-Follow test-engineer rules from RPI agent guidelines.
-```
-
-### Phase VERIFY RED: Confirm correct failure
-
-Run the test:
-```bash
-{test_runner} {test_file}
-```
-
-Check the output:
-- **Test fails with expected reason** (function/module not found, assertion fails) → proceed to GREEN
-- **Test errors** (syntax error, import error, typo) → fix the test, re-run
-- **Test passes** → the behavior already exists. Either the test is wrong or the task is already done. Ask the user.
-
-Report to user:
-```
-RED: Test fails correctly.
-  Test: {test_name}
-  Failure: {failure_reason}
-```
-
-### Phase GREEN: Minimal implementation
-
-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.
-
-The following test is currently FAILING:
-{test_file}:{test_name}
-Failure reason: {failure_reason}
-
-Write the MINIMAL code to make this test pass.
-- Only touch files listed for this task
-- Do NOT add features beyond what the test requires
-- Do NOT write additional tests
-- Match existing code style
-
-Task context:
-**{task_id}** {task_description}
-Files: {files}
-```
-
-### Phase VERIFY GREEN: Confirm pass
-
-Run the test again:
-```bash
-{test_runner} {test_file}
-```
-
-Also run the full test suite to check for regressions:
-```bash
-{test_runner}
-```
-
-Check:
-- **Target test passes** → proceed to REFACTOR
-- **Target test fails** → fix implementation, re-run (do NOT change the test)
-- **Other tests break** → fix regressions before proceeding
-
-Report to user:
-```
-GREEN: Test passes.
-  Test: {test_name}
-  All tests: {pass_count}/{total_count} passing
-```
-
-### Phase REFACTOR: Clean up
-
-Review the implementation just written:
-- Remove duplication
-- Improve names
-- Extract helpers if warranted (3+ uses)
-- Do NOT add new behavior
-
-After refactoring, re-run tests to confirm still green:
-```bash
-{test_runner}
-```
-
-### Commit
-
-If all tests pass:
-```bash
-git add {changed_files}
-git commit -m "{type}({task_id}): {task_description}"
-```
-
-## 5. Check for additional tests needed
-
-After the first TDD cycle for a task, check eng.md for additional test scenarios:
-- Edge cases mentioned in the plan
-- Error handling paths
-- Boundary conditions
-
-If more tests are needed, ask the user:
-"Task {task_id} has additional test scenarios. Continue with next test cycle?"
-
-If yes, repeat the TDD cycle (RED → GREEN → REFACTOR) for each additional test.
-
-## 6. Report results
-
-```
-TDD complete for task {task_id}:
-- Tests written: {N}
-- All passing: {pass_count}/{total_count}
-- Files changed: {list}
-
-{If --all: proceed to next task}
-{If single task: suggest next task or /rpi:implement to continue}
-```
-
-</process>