Why the RPI Workflow Works

AI coding assistants are brilliant at simple tasks. Ask for a function that reverses a string, and you'll get working code in seconds. Ask for a feature that touches twelve files across three services, and you'll get something that looks right, compiles cleanly, and breaks everything it touches.

If you've spent hours debugging AI-generated code that ignored your project's conventions, used variable names that don't match anything in your codebase, or confidently called APIs that don't exist, you're not alone. The problem isn't that AI is incapable. The problem is that we're asking it to do too many things at once.

The Real Problem

Here's what took us a while to figure out: AI is doing exactly what it's designed to do. When you ask it to "build a feature," it generates plausible output quickly. The issue is that "plausible" and "correct" aren't the same thing.

WARNING

The failure mode you'll recognize

You: "Build me a Terraform module for Azure IoT"

AI: immediately generates 2000 lines of code

Reality: Missing dependencies, wrong variable names, outdated patterns, breaks existing infrastructure

Why does this happen? Because AI can't tell the difference between investigating and implementing. When you ask for code, it writes code. It doesn't stop to verify that the variable naming convention it chose matches your existing modules. It doesn't check whether the resource it's creating already exists. It doesn't ask itself whether the API it's calling is current or deprecated.

AI writes first and thinks never. Not because it's broken, but because that's the only mode it has when you give it unrestricted access to both research and implementation.

The Counterintuitive Insight

The solution isn't teaching AI to be smarter. It's preventing AI from doing certain things at certain times.

RPI keeps Research, Plan, Implement, Review, and Follow-up distinct so a task uses the smallest credible action at each point. It starts with research readiness: supplied or completed research is reused when adequate, while /rpi-research investigates a demonstrated requirements, acceptance, dependency, material-risk, complexity, uncertainty, or decision-critical gap.

• /rpi-research investigates a demonstrated gap and produces evidence for planning readiness.
• /rpi-plan owns one task-centered implementation plan and records independent critique.
• /rpi-implement directly executes approved work, records changes and validation, and returns material discoveries for plan reconciliation.
• /rpi-review creates one evidence-reconciliation record and routes defects, decision gaps, research gaps, and residual work.

When a long lifecycle needs a fresh context, durable artifacts preserve the task identity, evidence, decisions, and next action. A reset can reduce accumulated context, but it does not require a new research stage or a fresh run of every lifecycle concept.

Use RPI Agent as a user-selected wrapper that activates the applicable RPI skills. It is an entry surface for the phase skills, not an autonomous dispatcher of specialized task workers.

The Difference in Practice

Without RPI, AI thinks: "This looks like a reasonable variable name. I'll use prefix."

With RPI, research evidence can find: "12 existing modules in this repository use resource_prefix, not prefix; variables.tf contains the established pattern."

When AI knows it cannot implement during research, it stops optimizing for "plausible code" and starts optimizing for "verified truth." The constraint changes the goal.

What Happens in Each Lifecycle Concept

Understanding what AI does differently in each phase helps explain why separation works.

Research: Investigating a Demonstrated Gap

Research runs when readiness shows that planning cannot responsibly proceed with the supplied evidence. /rpi-research remains focused on the gap:

• Searches for existing patterns instead of inventing new ones.
• Cites precise source locations when they support a finding.
• Distinguishes evidence, assumptions, and unresolved questions.
• Documents dependencies, APIs, conventions, and planning readiness.

When evidence is adequate, Research is reused or satisfied-and-skipped instead of repeated.

Planning Phase: Sequencing, Not Improvising

/rpi-plan synthesizes adequate evidence into an adaptable implementation strategy. It owns one checklist and drafts every phase itself. Planning focuses on:

• Giving each phase a coherent outcome goal and each task an observable behavior or capability goal.
• Identifying dependencies between changes.
• Keeping requirements, details, and linked references under the task they inform, and leaving verification choices to the implementer.
• Showing the overall change and each phase's slice of it as Mermaid diagrams in the Phase Checklist.
• Using code as illustrative guidance unless a real interface or requirement makes it binding.
• Recording independent rpi-plan-critique evidence before implementation readiness.

The plan becomes a contract. When implementation begins, the AI follows the plan rather than making decisions on the fly.

Implementation Phase: Following, Not Inventing

/rpi-implement directly executes approved Pxx or Pxx-Txx work. It remains flexible within the evidence boundary:

• No time wasted rediscovering conventions.
• Completion checkboxes change only after completion evidence exists.
• Descriptive change evidence and truthful validation establish what happened.
• A significant discovery updates the affected plan after its required decision and pauses only dependent work; the existing critique is not repeated.

Review Phase: Validating, Not Assuming

/rpi-review writes one record that reconciles implementation against documented evidence:

• Compares the task-centered plan, critique, changes, and validation evidence in one pass and writes the findings itself, then decides the outcome and every route.
• Separates execution status from outcome and records validation as passed, failed, skipped, or unavailable.
• Routes defects to implementation, decision gaps to planning, research gaps to research, and residual work to follow-up.

Follow-up: Routing, Not Relabeling

Follow-up records the next owner after review. It does not hide work inside a generic loop or merge residual work into the active task. A task can return to the earliest affected concept, or residual work can become a distinct next item.

The Quality Difference

RPI produces measurably different outcomes than traditional AI coding:

Aspect	Traditional Approach	RPI Approach
Pattern matching	Invents plausible patterns	Uses verified patterns when evidence is needed
Traceability	"The AI wrote it this way"	Links decisions and changes to durable evidence
Knowledge transfer	Context remains in one conversation	Reusable research, plan, change, and review artifacts
Rework	Assumptions surface late	Review routes each gap to the earliest responsible lifecycle concept
Validation	Hope it works or manual testing	Records evidence or an explicit unavailable or skipped reason

The Paradigm Shift

Stop asking AI: "Write this code."

Start asking: "Help me research, plan, then implement with evidence."

RPI treats research as a readiness decision, planning as evidence-led coordination, implementation as direct execution, and review as evidence reconciliation. The task takes only the lifecycle actions it needs.

The Learning Curve

Let's be honest: your first RPI lifecycle may feel slower. You're learning to judge research readiness, preserve durable evidence, and choose the smallest responsible next action.

By your third feature, the lifecycle feels natural. Research becomes faster because you can identify a genuine gap, planning tightens because you recognize the evidence needed for your codebase, and implementation can remain focused on approved work.

The value compounds over time. Research, planning, change, and review artifacts can accumulate into institutional memory when the task needs them. New team members can understand how decisions were made and which work remains.

Choosing an RPI Entry Surface

HVE Core provides alternative surfaces for the same RPI phase skills. Choose the entry point that matches how you want to begin, then take only the lifecycle actions the task needs.

RPI Agent

Select RPI Agent when you want a user-selected lifecycle wrapper. It activates matching RPI skills, begins with research readiness, and preserves one task identity across any durable artifacts. It runs in manual mode by default and can switch to a confirmed automatic session that completes the remaining phases through Review and then offers ranked follow-up work.

Direct Phase Skills

Use /rpi-research, /rpi-plan, /rpi-implement, or /rpi-review when the next responsible lifecycle action is known.

Matching the Entry Surface to the Task

Entry surface	Use it when	Lifecycle contract
RPI Agent	You want a user-selected wrapper around phase skills	Research readiness and applicable phase activation
Direct phase skills	The next responsible action is already known	Bounded Research, Plan, Implement, or Review work

Evidence-Driven Escalation

Research readiness, planning critique, implementation-time discoveries, and review findings determine when the task returns to an earlier concept. Start with adequate evidence when it exists; activate /rpi-research when a demonstrated gap prevents credible planning or review.

Next Steps

Ready to try it yourself?

• Your First RPI Workflow: 15-minute hands-on tutorial
• Using RPI Together: context management and handoffs
• RPI Overview: the lifecycle concepts explained
• Context Engineering: deliberate context reset and artifact-based resumption

---

🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.