/rpi

name: rpi
description: 'Drive one accepted change through implementation and checks to done, with one fresh review only where a mistake is costly. Use when: asked to run or orchestrate work through RPI.'
practices:
- design-by-contract
hexagonal_role: domain
consumes:
- plan
- implement
- validate
produces: []
context_rel:
- kind: customer-of
  with: plan
- kind: customer-of
  with: implement
- kind: customer-of
  with: validate
skill_api_version: 1
user-invocable: true
metadata:
  graph_root: true
  tier: meta
  dependencies: [plan, implement, validate]
  capabilities: [own_authorized_outcome, report]
  effects: [modify_authorized_subject, dispatch_conditional_validator]
  canonical_status: canonical
  disposition: keep_strategy
output_contract: 'concise human-readable closeout; no machine artifact'

RPI

Own the authorized outcome through finish. RPI (research, plan, implement) is one native pass, not fixed phases: use the native coding agent and shell. BD or the caller's tracker owns work and handoffs; Git owns content and delivery. AgentOps supplies a small charter and one fresh judgment where a mistake is costly, not a scheduler.

Operating charter

1. Use the existing accepted outcome, scope and real bounds. A clear change needs no Plan, Recall or Learn worksheet. Resolve uncertainty only when it could change the implementation or acceptance decision. 2. Take the smallest acceptance-advancing action. [Plan](../plan/SKILL.md) runs only when intent is missing, an uncertainty is consequential or evidence disproves the approach. Once an implementer can act and a validator can judge, implement; do not keep improving the plan. Approach revisions preserve acceptance and authorized scope. Acceptance changes need caller authority. 3. [Implement](../implement/SKILL.md) and repair ordinary known defects directly. A known test failure needs a fix and a discriminating check, not another planning phase, council or helper. 4. Use focused checks during edits and complete required integration checks before finishing. Reuse a check result only while its inputs are unchanged; rerun affected checks after changes. Reserve capacity for integration and repair. Keep a subject unchanged while it is being judged. 5. Spend validation where a mistake is costly. For an ordinary change the checks and CI are the gate: finish. Obtain [Validate](../validate/SKILL.md) from one fresh author-distinct context only when the caller asks, when a mistake cannot be cheaply undone after it lands (a published release or instructions users will follow, a security boundary, destroying data or tracker state, deleting a check that protects the product), or when no deterministic check covers the changed behavior. Use the author's model family unless the caller selects additional legs; explicitly required reviewers remain required. 6. One round. Give the validator the accepted criteria, the exact subject and one question written before it starts, never the author's confidence or desired verdict; it does not re-run the checks. Repair what fails the accepted behavior or would mislead a user, break install or the CLI, or remove protection for the product; treat the rest as optional notes. Confirm each repair with a check and finish. A repair does not start another review, and `NOT_PROVEN` is reported with its gaps, not chased. Keep review cost a fraction of the cost of the work; when it approaches that cost, stop and report what is unchecked. 7. Stop at completed acceptance, cancellation, refusal, a spent real bound, a pending caller decision or an unresolved causal stall after the help below. A choice the accepted outcome depends on that lies outside existing authority (changed acceptance, wider scope, an irreversible step it does not cover) is the caller's decision, not a stall, so no helper applies. Finish the independent authorized work, then stop and return the choice instead of waiting on it, handed over in full: what raised it, what you found, the options with their tradeoffs and your recommendation. A count or a link is not a handover, and the result is never `done` while a choice is open. Adjacent improvements are not permission to expand the goal. Report them briefly only when useful; do not turn them into another work batch.

Delegation and handoffs

When delegation is authorized and useful, select the runtime's task-only dispatch option for independent work: a short prompt in a full-history fork still carries the full history, and prompt wording proves neither isolation nor a smaller inherited context. Supply accepted intent and scope, the exact subject, relevant evidence, remaining bounds, the result's consumer and check ownership; resume an author for direct repair when useful. At completion, verify the expected subject and required results; a quiet or partial status is not success. Integrate as Implement's [delegated work](../implement/references/delegated-work.md) describes, carrying each worker's `not_as_briefed` and `gaps` lines into the closeout below.

Causal stall and bounds

Name a stall by what you observed, never by a count:

• Unknown cause: a check fails and neither its output nor the diff points to a

change or assumption you can name.

• Recurrence: a check that passed after a repair fails again for the same cause.
• No progress: the failing check's output and the diff are unchanged since the

previous attempt, or a delegated worker's last observed activity has not changed since you last looked.

• Wrong objective: a caller correction, or a check of the accepted example,

shows the work aims at something acceptance does not ask for.

Any of the four admits at most one bounded fresh helper for that incident within authority and bounds; if it stays unresolved, the stalled Result names its observed fact. Give it the failed assumption, evidence and one discriminating question.