Rpi
Run a mandatory Discover → Implement → Validate agent loop in one session so work does not stop at code completion and learnings feed back into the knowledge flywheel.
Overview
rpi is a journey-wide agent skill that enforces Discover–Implement–Validate in one autonomous session—usable whenever a solo builder needs an agent to finish with validation, not stop after implementation.
Install
npx skills add https://github.com/boshu2/agentops --skill rpiWhat is this skill?
- Three mandatory phases unless complexity is fast: discovery, implementation, and validation in one session
- Fully autonomous by default—no mid-run confirmations unless --interactive is set
- Phase 2 completion is explicitly not the end; Phase 3 captures learnings and turns the flywheel
- Anti-pattern table: do not stop after Phase 2 to ask about commits; do not call /vibe instead of full /validation
- Only stop after three retries exhausted on a genuine blocker
- Three mandatory phases when complexity is not fast
- Stop only after three retries exhausted on blockers
- Default mode is fully autonomous unless --interactive is set
Adoption & trust: 832 installs on skills.sh; 384 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your coding agent finishes implementation and asks to commit, skipping validation so quality gaps and learnings never get captured.
Who is it for?
Builders using AgentOps-style /rpi who want end-to-end autonomous runs with a hard validation gate and flywheel learnings.
Skip if: Quick one-off edits where complexity is fast, or workflows that intentionally require human confirmation between every phase unless --interactive is set.
When should I use this skill?
User invokes /rpi for autonomous Discover–Implement–Validate execution (AgentOps), especially when they must not end after Phase 2.
What do I get? / Deliverables
The agent runs all three phases hands-free, completes wrapped validation (not ad-hoc vibe alone), and only interrupts the human after Phase 3 or when retries are exhausted.
- Completed three-phase session with implementation plus full validation wrap
- Captured learnings from post-mortem/retro/forge path (not vibe-only)
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Invoke /rpi so the agent discovers requirements, implements, then validates without asking to commit mid-session.
Treat Phase 3 validation as the quality gate before merge instead of stopping at green compile output.
Run post-mortem and retro after validation so fixes improve the next autonomous cycle.
Use discovery phase output to constrain prototype scope before full implementation.
How it compares
Agent ops workflow skill with a fixed three-phase rule—not informal ‘vibe check then ship’ chat habits.
Common Questions / FAQ
Who is rpi for?
Solo and indie developers orchestrating Claude or similar agents through structured /rpi runs who need validation and retros wired in by default.
When should I use rpi?
Across Build when implementing features, Ship when you need review and validation before merge, and Operate when capturing post-mortems after agent-led fixes—any time you invoke /rpi and are not using --interactive.
Is rpi safe to install?
Autonomous mode can commit, test, and call tools without pausing; check Prism Security Audits and use --interactive if you require human approval gates.
SKILL.md
READMESKILL.md - Rpi
# Autonomous Execution Rules ## The Three-Phase Rule RPI has THREE mandatory phases (unless complexity == `fast`). You MUST run all three — discovery, implementation, AND validation — in a single session. Do NOT stop after implementation. Do NOT ask the user if they want to commit after Phase 2. Phase 2 completing is NOT the end — it is the midpoint. Validation (Phase 3) is where learnings are captured and the knowledge flywheel turns. Skipping it breaks the flywheel. ## Fully Autonomous by Default Unless `--interactive` is explicitly set, RPI runs hands-free from start to finish. Do NOT: - Ask the user for confirmation between phases - Ask "want me to commit?" or "should I continue?" - Pause to summarize and wait for input - Request clarification mid-execution - Stop to ask about approach or strategy The human's only touchpoint is AFTER Phase 3 completes. If something is genuinely blocked (3 retries exhausted), then and only then do you stop and report. Everything else runs autonomously. The user invoked `/rpi` because they want you to GO — not to narrate. ## Anti-Patterns (DO NOT) | Anti-Pattern | Why It's Wrong | Correct Behavior | |--------------|----------------|------------------| | Stop after Phase 2 and ask to commit | Skips validation — no quality check, no learnings, flywheel doesn't turn | Proceed directly to Phase 3 | | Call `/vibe` directly instead of `/validation` | `/vibe` is one sub-step; `/validation` wraps vibe + post-mortem + retro + forge | Always call `/validation` from `/rpi` | | Ask "want me to commit?" between phases | Interrupts autonomous flow — user invoked `/rpi` for hands-free execution | Commit only after ALL phases complete | | Ask the user ANY question during execution | RPI is autonomous unless `--interactive` — questions break the flow | Make best judgment and proceed; report at end | | Run Phase 1 inline instead of delegating to `/discovery` | Loses brainstorm → search → research → plan → pre-mortem sequencing | Delegate via `Skill(skill="discovery")` | | Summarize findings and wait after Phase 1 | Discovery output is an input to Phase 2, not a deliverable | Proceed immediately to Phase 2 | | Pause to explain what you're about to do | Narration wastes time — the user wants results, not commentary | Execute, then report at the end | ## Phase Completion Tracking After each phase, log progress: ``` PHASE 1 COMPLETE ✓ (discovery) — proceeding to Phase 2 PHASE 2 COMPLETE ✓ (implementation) — proceeding to Phase 3 PHASE 3 COMPLETE ✓ (validation) — RPI DONE ``` # RPI lifecycle best practices Citation table extracted during research for `soc-bcrn` (RPI lifecycle sharpening). The lifecycle skills (`/rpi`, `/discovery`, `/crank`, `/validation`) MUST reference principles by `#` from this file — they MUST NOT duplicate the body content here. When a principle is wrong or stale, update this file and the citations fix themselves. Source research: `.agents/research/2026-05-07-rpi-lifecycle-sharpening.md` §Objective 4. ## Table A — Principles to encode | # | Principle | Source citation | Encode in | |---|---|---|---| | 1 | Explicit done criteria | `docs/context-lifecycle.md` (Gap 1) | discovery, plan, validation | | 2 | Strict delegation over compression | `skills/shared/references/strict-delegation-contract.md`, `.agents/learnings/2026-04-19-orchestrator-compression-anti-pattern.md` | rpi, discovery, crank, validation | | 3 | Fresh context per worker (Ralph Wiggum) | `docs/scale-without-swarms.md` | crank, swarm | | 4 | Isolation + waves + gates (3–5 workers/wave) | `docs/scale-without-swarms.md` | crank | | 5 | Evidence-based gates, not vibe | `docs/context-lifecycle.md` Gap 1 | validation, vibe | | 6 | Test-first when feasible | `skills/crank/SKILL.md` (test-first mode) | crank | | 7 | Atomic changes compose | `docs/brownian-ratchet.md` | crank | | 8 | Reconcile, don't push | `PRODUCT.md` design principle (K8s control loops), `docs/cdlc.md` | rpi, evolve | | 9 | Agent fungibility + filesyste