using-together.md

July 27, 2026 · View on GitHub

This guide walks through an evidence-led RPI lifecycle for a complex task. RPI Agent is a user-selected lifecycle wrapper, and /rpi-quick is a skill-based full-flow entry point. They activate the same phase skills, use one task identity, and do not require an autonomous pipeline of specialized task workers.

The Complete Workflow

┌────────────────────┐     ┌─────────────────────┐     ┌────────────────────┐     ┌────────────────────┐
│ Research readiness │ ──→ │ Plan                │ ──→ │ Implement          │ ──→ │ Review             │
│                    │     │ rpi-plan            │     │ rpi-implement      │     │ rpi-review         │
│ Reuse evidence or  │     │ Parent-owned plan,  │     │ Direct execution,  │     │ One reconciliation │
│ research a gap     │     │ details, critique   │     │ changes, validation│     │ record and routing │
└────────────────────┘     └─────────────────────┘     └────────────────────┘     └────────────────────┘
     │                                                                    │
     │ demonstrated gap                                                   │ routes open work
     ▼                                                                    ▼
   rpi-research                                                         Follow-up
   research/{{YYYY-MM-DD}}/{{task_slug}}-research.md                    earliest stage or next item

Critical Rule: Manage Context Deliberately

Use /clear or start a new chat when a long lifecycle has accumulated context, when switching tasks, or when a fresh context will improve the next responsible action. A reset does not require new research or a full lifecycle restart.

Why this matters:

Accumulated context can obscure evidence, decisions, and the next owner.
Durable task artifacts carry context through a reset or a later session.
Stable IDs and markers locate the relevant scope when surrounding prose changes.

For the deeper explanation of how LLM context affects agent behavior, see Context Engineering.

Walkthrough: Adding Azure Blob Storage

Let's walk through adding Azure Blob Storage to a Python data pipeline.

Research Readiness

Assess the available task context, acceptance criteria, decisions, dependencies, and completed research. For this Azure Blob Storage example, external SDK choices, authentication, and large-file streaming demonstrate a research gap.
Use /rpi-research for that bounded gap:

/rpi-research Azure Blob Storage integration for Python data pipeline

Provide additional context in your message:

I need to add Azure Blob Storage integration to our Python data pipeline.
The pipeline currently writes to local disk in src/pipeline/writers/.

Research:
- Azure SDK for Python blob storage options
- Authentication approaches (managed identity vs connection string)
- Streaming uploads for files > 1GB
- Error handling and retry patterns

Focus on approaches that match our existing patterns in the codebase.

/rpi-research will:
- Search your codebase for existing patterns
- Research Azure SDK documentation
- Evaluate authentication options
- Create a research document with recommendations
Review the output:

## 🔬 Research: Azure Blob Storage Integration

✅ Research document created at:
.copilot-tracking/research/2025-01-28/blob-storage-research.md

Key findings:
- Recommended: azure-storage-blob SDK with async streaming
- Authentication: Managed identity for production, connection string for dev
- Existing pattern: WriterBase class in src/pipeline/writers/base.py

Plan

Open or reference the research artifact. If the conversation has accumulated unrelated detail, begin a fresh context.
Use /rpi-plan with the available evidence:
```
/rpi-plan
```

Provide additional planning guidance:

/rpi-plan
Focus on:
- The streaming upload approach recommended in the research
- Phased rollout: storage client first, then writer class, then integration
- Include error handling and retry logic

Review the output. /rpi-plan creates a plan, matching phase-details artifact, and independent critique:

.copilot-tracking/plans/2025-01-28/blob-storage-plan.md
.copilot-tracking/details/2025-01-28/blob-storage-phase-details.md
.copilot-tracking/reviews/plans/2025-01-28/blob-storage-plan-critique.md

Verify the plan structure:

<!-- rpi:phase id=P01 -->
### [ ] P01: Storage Client Setup

<!-- rpi:task id=P01-T01 -->
#### [ ] P01-T01: Create BlobStorageClient class

<!-- rpi:task id=P01-T02 -->
#### [ ] P01-T02: Add configuration schema

<!-- rpi:phase id=P02 -->
### [ ] P02: Writer Implementation

<!-- rpi:task id=P02-T01 -->
#### [ ] P02-T01: Create BlobWriter extending WriterBase

<!-- rpi:phase id=P03 -->
### [ ] P03: Integration

Use Pxx and Pxx-Txx IDs, headings, and markers to navigate between the plan and phase-details artifact. They remain stable when surrounding text changes.

/rpi-plan owns the overall checklist and phase details. It may use bounded assistance internally for one exact phase, while rpi-plan-critique independently assesses the complete plan and details.

Implement

Open or reference the plan, phase-details, and critique artifacts. Use a fresh context only when accumulated conversation detail would impede the approved work.

Use /rpi-implement to execute directly and flexibly within the approved scope:

/rpi-implement plan=.copilot-tracking/plans/2025-01-28/blob-storage-plan.md details=.copilot-tracking/details/2025-01-28/blob-storage-phase-details.md task=P01-T01

Review change evidence as each approved task completes. After P01 completes:

CHG-001: Add BlobStorageClient
Related task: P01-T01
Files: src/storage/blob_client.py
Validation: Passed

P01-T01 and P01-T02 have completion evidence.

Check the code and validation evidence, then continue to the next approved Pxx or Pxx-Txx item.

If implementation requires a significant departure from the approved plan, record a linked DIV-xxx in the changes record and AM-xxx amendment in the plan, then update the affected phase-details section. Return those records for a fresh rpi-plan-critique assessment before affected dependent work resumes. Ordinary local judgment and non-material divergence do not require this gate.

When the in-scope implementation is ready for review, hand off the plan, phase details, critique disposition, amendments, and changes record:

Implementation complete!

Changes record: .copilot-tracking/changes/2025-01-28/blob-storage-changes.md

Files created (3):
- src/storage/blob_client.py
- src/pipeline/writers/blob_writer.py
- tests/integration/test_blob_writer.py

Files modified (2):
- src/config/schema.py
- src/pipeline/factory.py

Ready for review.

Review

Open or reference the complete evidence set. Begin a fresh context only when it will help evidence reconciliation.
Use /rpi-review to reconcile the implementation:
```
/rpi-review task=blob-storage
```
/rpi-review creates or updates one review record:
- Locates research, plan, phase details, plan critique, amendments, changes, and validation evidence
- Reconciles each Pxx and Pxx-Txx item with completion and change evidence
- Assesses AM-xxx amendments and DIV-xxx divergences
- Uses an optional generic bounded lens only when it reduces a specific review uncertainty
- Records severity-graded RV-xxx findings, separate execution status and outcome, validation evidence or Unavailable, and next-owner routing
Review the findings:

## ✅ Review: Blob Storage Integration

| Summary           |                                                                  |
|-------------------|------------------------------------------------------------------|
| Review Record     | .copilot-tracking/reviews/logs/2025-01-28/blob-storage-review.md |
| Execution Status  | Complete                                                         |
| Outcome           | Defects found                                                    |
| Critical Findings | 0                                                                |
| Medium Findings   | 1                                                                |
| Low Findings      | 1                                                                |
| Residual Work     | 1                                                                |

RV-001 [Medium]: Missing docstring on BlobStorageClient.upload_stream().
Destination: rpi-implement

RV-002 [Low]: Consider adding retry count to configuration schema.
Destination: distinct follow-up

Follow-up item:
- Add performance benchmarks for large file uploads (deferred from research)

Return RV-001 to `rpi-implement`, then review it again before committing.

Address findings through their recorded next owner:
- Address each RV-xxx finding through its recorded next owner
- Return the implementation defect in RV-001 to rpi-implement, then review it again with rpi-review before committing
- Resolve or explicitly accept material findings before committing
- Track residual work as a distinct follow-up item

Follow-up

Review routes work rather than silently looping it through a generic worker chain:

Defects return to rpi-implement.
Decision gaps return to rpi-plan.
Evidence gaps return to rpi-research.
Residual work becomes a distinct next item.

Artifact Summary

After completing RPI, you have:

Artifact	Location	Purpose
Research, when it runs	`.copilot-tracking/research/{{YYYY-MM-DD}}/{{task_slug}}-research.md`	Evidence and recommendations
Plan	`.copilot-tracking/plans/{{YYYY-MM-DD}}/{{task_slug}}-plan.md`	Checkboxes, requirements, decisions, and amendments
Phase details	`.copilot-tracking/details/{{YYYY-MM-DD}}/{{task_slug}}-phase-details.md`	Evidence-based context for `Pxx` and `Pxx-Txx` work
Plan critique	`.copilot-tracking/reviews/plans/{{YYYY-MM-DD}}/{{task_slug}}-plan-critique.md`	Independent planning credibility assessment
Changes	`.copilot-tracking/changes/{{YYYY-MM-DD}}/{{task_slug}}-changes.md`	`CHG-xxx`, `DIV-xxx`, validation, and handoff evidence
Review	`.copilot-tracking/reviews/logs/{{YYYY-MM-DD}}/{{task_slug}}-review.md`	Reconciliation, `RV-xxx` findings, outcome, and routing
Code	Your source directories	Working implementation

Common Patterns

Returning to Research

If implementation or review reveals a demonstrated evidence gap:

Record the gap and its affected task scope.
Return to /rpi-research for the bounded investigation.
Update planning only when the evidence changes the approved scope, decision, or acceptance criteria.
Resume the earliest affected lifecycle concept from the durable artifacts.

Handling Complex Tasks

For very large tasks:

Break work into distinct task identities where the outcomes are independently reviewable.
Reuse adequate research from prior work rather than repeat it.
Keep each plan, phase-details, changes, and review artifact set dated and task-specific.
Build incrementally.

Team Handoffs

RPI artifacts support handoffs:

Research doc explains decisions
Plan and phase details show remaining Pxx and Pxx-Txx work
Changes record shows completed work, validation, and linked changes or divergences
Review record shows separate execution status, outcome, findings, and routing

Review Routing

The Review concept routes findings to the earliest responsible lifecycle concept or a distinct Follow-up item.

Iteration Paths

Review result	Action	Target phase or owner
Conformant	Commit changes	Done
Defects found	Fix implementation issues	Implement
Research-gap finding	Investigate missing context	Research
Decision-gap finding	Revise supported scope or decision	Plan
Residual work	Create distinct follow-up work	Follow-up owner

Defect Flow

When /rpi-review identifies Critical or High findings:

Open the review log in your editor.
Use /rpi-implement to address implementation findings.
Preserve the relevant changes and validation evidence.
Return to review with /rpi-review when the evidence is ready.

Research and Planning Flow

When /rpi-review identifies research or planning gaps:

Open the review log and the referenced task artifacts.
Choose the appropriate direct phase skill:
- /rpi-research for a demonstrated missing-evidence gap.
- /rpi-plan for a decision gap or unsupported plan assumption.
Resume from the earliest affected lifecycle concept.

Quick Reference

Lifecycle concept	Direct skill	Output
Research, when needed	`/rpi-research`	`.copilot-tracking/research/{{YYYY-MM-DD}}/{{task_slug}}-research.md`
Plan	`/rpi-plan`	Plan, phase details, and critique
Implement	`/rpi-implement`	Source changes and changes evidence
Review	`/rpi-review`	One review record with status, outcome, and routing
Follow-up	Routed from review	Earliest responsible stage or a distinct next item

Tip

RPI Agent and /rpi-quick are alternative lifecycle entry surfaces for the same phase skills. They use research readiness and do not require fresh research or every lifecycle concept in one conversation.

For a long lifecycle, resume with the stable task ID, Pxx, Pxx-Txx, headings, and  markers in the durable artifacts.

RPI Entry Surfaces

Choose the entry surface that best fits the task. Both RPI Agent and /rpi-quick activate the same phase skills.

Entry surface	Use it when	Contract
`RPI Agent`	You want a user-selected lifecycle wrapper	Activates applicable phase skills from research readiness
`/rpi-quick`	You want a skill-based full-flow entry point	Same lifecycle contract and one task identity
Direct phase skills	The next responsible action is already known	Bounded Research, Plan, Implement, or Review work

Resuming a Long Lifecycle

A long lifecycle can accumulate context. Resume from the durable RPI artifact set rather than relying on a conversation transcript:

Open or reference the dated artifact that establishes the next action.
Use the stable task ID, Pxx, Pxx-Txx, headings, and  markers to find the affected scope.
Start a fresh chat or use /compact only when it will improve the next responsible action.
Treat the durable artifact set, rather than the conversation transcript, as the source of truth.

Tip

For the full explanation of how context affects the lifecycle, see Context Engineering.

See Agents Reference for RPI Agent details.

RPI Overview - Understand the workflow
Why the RPI Workflow Works - Understand the rationale for phase separation
Context Engineering - Why context management matters

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