microsoft/hve-core
Publicmirrored fromhttps://github.com/microsoft/hve-coreAvailable
docs/rpi/README.md
138lines · modecode
| 1 | --- |
| 2 | title: Understanding the RPI Workflow |
| 3 | description: Learn the Research, Plan, Implement, Review workflow for transforming complex tasks into validated code |
| 4 | author: Microsoft |
| 5 | ms.date: 2026-02-18 |
| 6 | ms.topic: concept |
| 7 | keywords: |
| 8 | - rpi workflow |
| 9 | - task researcher |
| 10 | - task planner |
| 11 | - task implementor |
| 12 | - task reviewer |
| 13 | - github copilot |
| 14 | estimated_reading_time: 4 |
| 15 | --- |
| 16 | |
| 17 | The RPI (Research, Plan, Implement, Review) workflow transforms complex coding tasks into validated solutions through four structured phases. Think of it as a type transformation pipeline: |
| 18 | |
| 19 | > Uncertainty → Knowledge → Strategy → Working Code → Validated Code |
| 20 | |
| 21 | ## Why Use RPI? |
| 22 | |
| 23 | AI coding assistants are brilliant at simple tasks and break everything they touch on complex ones. The root cause: 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 patterns match your existing modules or that the APIs it's calling actually exist. |
| 24 | |
| 25 | RPI solves this through a counterintuitive insight: when AI knows it cannot implement, it stops optimizing for "plausible code" and starts optimizing for "verified truth." The constraint changes the goal. |
| 26 | |
| 27 | ### Key Benefits |
| 28 | |
| 29 | * Uses verified existing patterns instead of inventing plausible ones. |
| 30 | * Traces every decision to specific files and line numbers. |
| 31 | * Creates research documents anyone can follow, eliminating tribal knowledge. |
| 32 | |
| 33 | > [!TIP] |
| 34 | > **Want the full explanation?** See [Why the RPI Workflow Works](why-rpi.md) for the psychology, quality comparisons, and guidance on choosing between strict RPI and rpi-agent. |
| 35 | |
| 36 | RPI separates concerns into distinct phases, each with its own specialized custom agent. |
| 37 | |
| 38 | ## The Four Phases |
| 39 | |
| 40 | ### 🔬 Research Phase (Task Researcher) |
| 41 | |
| 42 | This phase transforms uncertainty into verified knowledge. |
| 43 | |
| 44 | * Investigates codebase, external APIs, and documentation |
| 45 | * Documents findings with evidence and sources |
| 46 | * Creates ONE recommended approach per scenario |
| 47 | * Output: `{{YYYY-MM-DD}}-<topic>-research.md` |
| 48 | |
| 49 | ### 📋 Plan Phase (Task Planner) |
| 50 | |
| 51 | This phase transforms knowledge into actionable strategy. |
| 52 | |
| 53 | * Creates coordinated planning files with checkboxes and details |
| 54 | * Includes line number references for precision |
| 55 | * Validates research exists before proceeding |
| 56 | * Output: Plan and details files |
| 57 | |
| 58 | ### ⚡ Implement Phase (Task Implementor) |
| 59 | |
| 60 | This phase transforms strategy into working code. |
| 61 | |
| 62 | * Executes plan task by task with verification |
| 63 | * Tracks all changes in a changes log |
| 64 | * Supports stop controls for review |
| 65 | * Output: Working code + `{{YYYY-MM-DD}}-<topic>-changes.md` |
| 66 | |
| 67 | ### ✅ Review Phase (Task Reviewer) |
| 68 | |
| 69 | This phase transforms working code into validated code. |
| 70 | |
| 71 | * Validates implementation against research and plan specifications |
| 72 | * Checks convention compliance using instruction files |
| 73 | * Runs validation commands (lint, build, test) |
| 74 | * Identifies follow-up work and iteration needs |
| 75 | * Output: `{{YYYY-MM-DD}}-<topic>-review.md` |
| 76 | |
| 77 | ## The Critical Rule: Clear Context Between Phases |
| 78 | |
| 79 | 🔴 **Always use `/clear` or start a new chat between phases.** |
| 80 | |
| 81 | Each custom agent has different instructions. Accumulated context causes confusion: |
| 82 | |
| 83 | ```text |
| 84 | Task Researcher → /clear → Task Planner → /clear → Task Implementor → /clear → Task Reviewer |
| 85 | ``` |
| 86 | |
| 87 | Research findings are preserved in files, not chat history. Clean context lets each agent work optimally. After clearing, open the relevant `.copilot-tracking/` artifact in your editor so the next agent can see it (for example, open the research document before invoking Task Planner). |
| 88 | |
| 89 | For the technical explanation of why this matters, see [Context Engineering](context-engineering.md). |
| 90 | |
| 91 | ## When to Use RPI |
| 92 | |
| 93 | | Use RPI When... | Use Quick Edits When... | |
| 94 | |--------------------------------|-------------------------| |
| 95 | | Changes span multiple files | Fixing a typo | |
| 96 | | Learning new patterns/APIs | Adding a log statement | |
| 97 | | External dependencies involved | Refactoring < 50 lines | |
| 98 | | Requirements are unclear | Change is obvious | |
| 99 | |
| 100 | **Rule of Thumb:** If you need to understand something before implementing, use RPI. |
| 101 | |
| 102 | ## Quick Start |
| 103 | |
| 104 | 1. **Define the problem** clearly |
| 105 | 2. **Research** using `/task-research <topic>` (automatically switches to Task Researcher) |
| 106 | 3. **Clear context** with `/clear` |
| 107 | 4. **Plan** using `/task-plan` (automatically switches to Task Planner) |
| 108 | 5. **Clear context** with `/clear` |
| 109 | 6. **Implement** using `/task-implement` (automatically switches to Task Implementor) |
| 110 | 7. **Clear context** with `/clear` |
| 111 | 8. **Review** using `/task-review` (automatically switches to Task Reviewer) |
| 112 | |
| 113 | > [!TIP] |
| 114 | > The `/task-research`, `/task-plan`, `/task-implement`, and `/task-review` prompts automatically switch to their respective custom agents, so you don't need to manually select them. |
| 115 | |
| 116 | ## Next Steps |
| 117 | |
| 118 | * [Task Researcher Guide](task-researcher.md) - Deep dive into research phase |
| 119 | * [Task Planner Guide](task-planner.md) - Create actionable plans |
| 120 | * [Task Implementor Guide](task-implementor.md) - Execute with precision |
| 121 | * [Task Reviewer Guide](task-reviewer.md) - Validate implementations |
| 122 | * [Using Them Together](using-together.md) - Complete workflow example |
| 123 | * [Context Engineering](context-engineering.md) - Why context management matters |
| 124 | * [Agents Reference](../../.github/CUSTOM-AGENTS.md) - All available agents |
| 125 | * [Agent Systems Catalog](../agents/README.md) - Browse all agent families beyond RPI |
| 126 | |
| 127 | ## See Also |
| 128 | |
| 129 | * [Engineer Guide](../hve-guide/roles/engineer.md) - Role-specific guide for engineers using RPI agents |
| 130 | * [Tech Lead Guide](../hve-guide/roles/tech-lead.md) - Architecture review and prompt engineering workflows |
| 131 | * [Stage 6: Implementation](../hve-guide/lifecycle/implementation.md) - Where RPI fits in the project lifecycle |
| 132 | |
| 133 | --- |
| 134 | |
| 135 | <!-- markdownlint-disable MD036 --> |
| 136 | *🤖 Crafted with precision by ✨Copilot following brilliant human instruction, |
| 137 | then carefully refined by our team of discerning human reviewers.* |
| 138 | <!-- markdownlint-enable MD036 --> |
| 139 | |