---
name: rpi
description: 'Own an authorized outcome through implementation, checks and fresh final validation; load planning and memory only when useful. Triggers: "run rpi", "run one traversal", "execute this plan", orchestration or worker delegation that implements changes.'
practices:
- bdd-gherkin
- tdd
- design-by-contract
hexagonal_role: domain
consumes:
- plan
- implement
- validate
produces:
- rpi-report.v1
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: [dispatch_core_phases]
  canonical_status: canonical
  disposition: keep
output_contract: 'concise human-readable result; optional rpi-report.v1 when a caller or declared consumer requests machine-readable evidence'
---

# RPI

Own the authorized outcome through finish. 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 fresh judgment, 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)
   shapes missing intent or revises a disproved 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 final judgment. Reuse valid exact-input receipts; rerun affected
   checks after changes. Reserve capacity for integration, review and repair.
   Keep the final subject unchanged while it is being judged.
5. Obtain [Validate](../validate/SKILL.md) from one fresh author-distinct context
   in the author's model family unless the caller selects required additional
   legs. There is no fixed ten-minute cap; explicitly required
   reviewers remain required. Risk deepens evidence, not reviewer multiplication. Repair
   actionable findings within authority and remaining bounds, then revalidate
   the changed exact subject.
6. Stop at completed acceptance, cancellation, refusal, a spent real bound or
   an unresolved causal stall after the help below. Adjacent improvements are
   not permission to expand the goal. Report them briefly only when useful;
   do not turn them into another work batch.

## Context and handoffs

Load required contracts once per context, then inspect the source or evidence
needed for the next decision. A reference link is available context, not a
reading list. Search before opening large files; retrieve relevant sections
and expand when uncertainty requires it. Do not reread unchanged material or
copy full logs into successive tool results and handoffs.

When delegation is authorized and useful, give each worker task-specific
context: accepted intent and scope, exact subject, relevant evidence, remaining
bounds and the requested result. Prefer a new task-only context for an
independent subtask; resume the original worker for a direct repair when useful.
Validators always receive fresh context, without the author's desired verdict.
Use observed runtime capabilities; prompt wording does not prove isolation.

Return concise findings, check facts and accessible evidence references. Keep
full logs available, showing only decision-relevant excerpts; disclose truncation
or missing evidence. Reuse one caller-owned handoff instead of multiplying
plans, receipt summaries and status documents. Machine evidence such as `verdict.v2` is optional
unless requested or required by a declared consumer. When no machine
artifact is requested or required, return the result without creating one.

## Causal stall and bounds

Unknown cause, recurrence, no progress or a wrong objective admits
at most one bounded fresh helper for that incident within authority and bounds.
Give it the failed assumption, evidence and one discriminating question. Resume
only with a different testable approach; an unhelpful answer ends the attempt.
Do not chain helpers or rename the incident. Known failures get direct repair.
Cancellation, refusal and spent hard time/cost/quota skip help.

Respect actual caller/native limits, including explicit repair-round bounds.
Retries, compaction, helpers and new subjects never renew them; retry count
alone is not a spent budget. If interruption threatens evidence, preserve
accepted intent, exact subject, useful receipts, unresolved cause, bounds and
helper use in the native handoff. Prompt text proves no native enforcement.
[Outer-goal guidance](references/outer-goal.md) remains optional.

## Evidence and boundaries

Bind accepted intent, complete changed paths, exact subject and factual receipts
for the fresh validator; disclose affected orphaned acceptance evidence. Use
existing provenance helpers rather than a new evidence format. Requested proof
uses caller-selected protected external non-Git storage; preserve legacy
`.agents/` evidence. Missing identity, freshness or proof means NOT_PROVEN;
proven failed acceptance or scope violation means FAIL. PASS needs every
criterion verified and empty `not_checked`. Authors cannot issue binding PASS.

[Memory](../memory/SKILL.md), specialists and runtime adapters are on demand;
no-match and no-change are valid. Read [boundaries](references/boundaries.md)
when authority, scope, evidence or delivery is at issue. The optional
[fixed-dispatch adapter](references/bounded-adapter.md) is not the native
execution engine. Do not invent a runtime, hidden machine artifact or workflow
to finish an ordinary change.

Report the result, strongest checks and material limits. Plans, activity,
reviews and saved pages earn no capability credit; NOT_PLANNED and NOT_BUILT
are progress descriptions, not semantic verdicts.