rpi

Go from a task description or research note straight to a living behavioral spec plus a goal envelope — a ready-to-run work order for a condition-based agent loop — in one pass, with no separate design to review and no phased plan. Use when user says 'make a goal-ready spec', 'spec this for an agent loop', 'turn this into a goal for /goal', or 'one-shot a spec and goal from this'. Do NOT invoke for genuine tradeoffs the user wants to review (use rpi-propose), a narrow scoped change wanting a phased plan (use rpi-plan), or a phased plan without a design (use rpi-blueprint).

Move completed or superseded .rpi/ artifacts to .rpi/archive/ with reference checks and frontmatter updates. Use when user says 'archive these artifacts', 'clean up .rpi/', or 'archive completed work'.

Go from a research note or a short problem statement straight to a phased plan in one pass, without a separate design to review. Use when user says 'just get me to a plan', 'skip the design, plan it', 'one-shot this from the research note', or 'I don't need a design, just plan this'. Do NOT invoke for genuine tradeoffs, multiple defensible approaches, or high-blast-radius changes — use rpi-propose instead; for a narrow scoped change to existing behavior use rpi-plan.

Create git commits for the current working tree with user approval, sensitive-content scan, and gitignore enforcement. Use when user says 'commit this', 'commit the changes', 'make a commit', or 'let's commit what we have'.

Diagnose a bug iteratively: reproduce, find root cause, attempt up to 3 fixes, produce a diagnosis artifact. Use when user says 'why is X not working?', 'X is broken', 'after Y, I see Z fail', or reports broken behavior, even if they don't say 'diagnose'. Do NOT invoke for understanding working code (use rpi-research).

Walk through a recent diff and explain what changed and why, focusing on non-obvious decisions. Use when user says 'explain the changes', 'walk me through the diff', 'what did we just do?', or 'explain how <feature> was implemented'.

Capture in-flight conversation context to a deterministic per-project temp file at the end of a session, so the next session in the same project can be told to read and consume it. Use when user says 'handoff', 'end of session', 'save session context for next time', 'wrap this up for the next session', or 'hand off to the next session'.

Execute an approved plan from .rpi/plans phase by phase with TDD and per-phase verification. Use when user says 'implement the plan', 'start implementing', 'run the next phase', or just approved a plan.

Plan a concrete, scoped change to existing behavior — produce a phased implementation plan. Use when user says 'remove the X flag', 'update Y to do Z', 'make sure X happens', or 'improve A to do B', even if they don't say 'plan'. Do NOT invoke when the change requires weighing design tradeoffs (use rpi-propose).

Design a new feature or non-trivial change with tradeoffs — produce a design and behavioral spec. Use when user says 'add feature X', 'introduce mode Y', 'support Z', or proposes new functionality, even if they don't say 'propose'. Do NOT invoke for narrow tweaks (use rpi-plan) or open-ended exploration (use rpi-research).

Investigate a question conversationally — codebase exploration or external systems/libraries/frameworks. Use when user says 'how does X work?', 'how could X be improved?', 'investigate Y', 'explore Z', 'what frameworks exist for X', 'survey the X space', or 'what's the state of X', even if they don't say 'research'. Do NOT invoke for broken behavior (use rpi-diagnose) or concrete changes with tradeoffs (use rpi-propose).

Amend an existing implementation plan in .rpi/plans when a new constraint or a review finding lands after the plan is drafted or partly built. Use when user says 'the constraint changed, update the plan', 'revise the plan for X', 'a review found a gap, amend the plan', or 'the API changed, the plan needs to account for it'. Do NOT invoke to create a fresh self-contained scoped change from scratch — use rpi-plan instead.

Install or upgrade the rpi binary into ~/.rpi/bin/rpi for the Claude Code plugin. Use when user says '/rpi:rpi-setup', 'install rpi', 'set up the rpi plugin binary', or after first installing the rpi plugin.

Detect spec drift and sync .rpi/specs/ to the current codebase — rewrite, rename, merge, or archive obsolete specs. Use when user says 'sync the specs', 'the spec is stale', 'specs need updating', or 'clean up old specs'.

Verify an implementation against its design and spec across completeness, correctness, and coherence — produce a severity-classified review. Use when user says 'verify the implementation', 'check the implementation matches the design', or 'review what I just shipped'.

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

Go from a research note or a short problem statement straight to a phased plan in one pass, without a separate design to review. Use when user says 'just get me to a plan', 'skip the design, plan it', 'one-shot this from the research note', or 'I don't need a design, just plan this'. Do NOT invoke for genuine tradeoffs, multiple defensible approaches, or high-blast-radius changes — use rpi-propose instead; for a narrow scoped change to existing behavior use rpi-plan.

Diagnose a bug iteratively: reproduce, find root cause, attempt up to 3 fixes, produce a diagnosis artifact. Use when user says 'why is X not working?', 'X is broken', 'after Y, I see Z fail', or reports broken behavior, even if they don't say 'diagnose'. Do NOT invoke for understanding working code (use rpi-research).

Walk through a recent diff and explain what changed and why, focusing on non-obvious decisions. Use when user says 'explain the changes', 'walk me through the diff', 'what did we just do?', or 'explain how <feature> was implemented'.

Execute an approved plan from .rpi/plans phase by phase with TDD and per-phase verification. Use when user says 'implement the plan', 'start implementing', 'run the next phase', or just approved a plan.

Plan a concrete, scoped change to existing behavior — produce a phased implementation plan. Use when user says 'remove the X flag', 'update Y to do Z', 'make sure X happens', or 'improve A to do B', even if they don't say 'plan'. Do NOT invoke when the change requires weighing design tradeoffs (use rpi-propose).

Design a new feature or non-trivial change with tradeoffs — produce a design and behavioral spec. Use when user says 'add feature X', 'introduce mode Y', 'support Z', or proposes new functionality, even if they don't say 'propose'. Do NOT invoke for narrow tweaks (use rpi-plan) or open-ended exploration (use rpi-research).

Investigate a question conversationally — codebase exploration or external systems/libraries/frameworks. Use when user says 'how does X work?', 'how could X be improved?', 'investigate Y', 'explore Z', 'what frameworks exist for X', 'survey the X space', or 'what's the state of X', even if they don't say 'research'. Do NOT invoke for broken behavior (use rpi-diagnose) or concrete changes with tradeoffs (use rpi-propose).

Amend an existing implementation plan in .rpi/plans when a new constraint or a review finding lands after the plan is drafted or partly built. Use when user says 'the constraint changed, update the plan', 'revise the plan for X', 'a review found a gap, amend the plan', or 'the API changed, the plan needs to account for it'. Do NOT invoke to create a fresh self-contained scoped change from scratch — use rpi-plan instead.