Prp Implement

Arguments: $ARGUMENTS (and $1, $2, ...) refer to the arguments given when this skill was invoked. Take them from the user's request; if absent, infer them from the conversation.

Implement Plan

Execute the supplied implementation plan through a validated commit and pull request, or apply review findings to that pull request. Keep implementation, commit, and PR delivery in this context; leave review judgment to its own context.

Input: $ARGUMENTS

Mode

• A plan path starts the initial implementation.
• A change its caller judged tiny work, such as $prp-issue's tiny route, starts the initial implementation with no plan. The change description is the contract. Write no implementation report; the PR description carries the problem, the fix, and the evidence. Wherever a later step records something in the report, tiny work puts it in the PR description, or in the returned result before a PR exists; a blocked tiny change returns VALIDATION: FAILED with the blocker. If the change turns out not to be tiny, stop before committing and return that, so the caller plans it.
• review plus a review report, PR, or finding decisions starts a correction pass. Resolve and read the original plan, implementation report, live PR diff and comments, complete canonical review report, and any explicit finding dispositions before editing. Human dispositions are binding when supplied. Otherwise resolve every finding by judgment: Critical or Important findings require correction or an evidence-backed disagreement, and for the rest, fix what matters now, including adjacent findings, track only real work unrelated to the change, fix taste that fits the project's direction and engineering docs, and decline other taste or wrong findings with a reason.
• ci plus a PR and failing-check evidence starts a correction pass. Resolve the original plan, implementation report, live PR diff, complete check status and logs, and reproduce the failure before editing. Correct only PR-caused failures; preserve evidence when the failure is external or pre-existing.

When the caller states the PR was delivered as tiny work, it has no plan or report: the PR description stands in for both in a correction pass, and the pass updates its evidence instead of a report. A non-tiny PR whose plan or report is missing is a blocker to report, not tiny work.

Resume the original implementation context for corrections when it is available. In a fresh context, reconstruct the complete contract from those durable artifacts rather than from an abbreviated findings summary.

Resolve the canonical project store before locating artifacts:

# --- PRP store resolver (canonical; keep byte-identical across skills) ---
# Adopt the store that already records this root; mint a key only when none does.
_gd="$(git rev-parse --path-format=absolute --git-common-dir 2>/dev/null)"
case "$_gd" in */.git) _root="${_gd%/.git}" ;; "") _root="$PWD" ;; *) _root="$_gd" ;; esac
_root="$(cd "$_root" && pwd -P)"
_name="$(basename "$_root" | tr '[:upper:]' '[:lower:]' | tr -cs 'a-z0-9' '-' | sed 's/^-*//;s/-*$//')"
_home="${PRP_HOME:-$HOME/.prp}"
_hit="$(grep -lsF "\"path\": \"$_root\"" "$_home"/*/project.json 2>/dev/null | head -1)"
PRP_DIR="${_hit%/project.json}"
[ -n "$PRP_DIR" ] || PRP_DIR="$_home/${_name:-project}-$(printf %s "$_root" | git hash-object --stdin | cut -c1-8)"
mkdir -p "$PRP_DIR"; [ -f "$PRP_DIR/project.json" ] || printf '{"path": "%s", "name": "%s"}\n' "$_root" "${_name:-project}" > "$PRP_DIR/project.json"

1. Establish context

For tiny work, skip the next three paragraphs, which resolve, refresh, and publish a plan. The rest of this step applies, with the change description in the plan's place.

Resolve the plan path from the arguments, linked implementation report, or conversation and read the entire file. When the input is an issue reference rather than a path, normalize number and URL forms to the same tracker item, search $PRP_DIR/plans/ for matching Source Issue metadata, and select the single current plan. If several match, present the newest viable candidates and ask; never guess. If no local plan exists, retrieve the latest complete issue comment marked <!-- prp-plan-id: ... -->, persist that published plan under $PRP_DIR/plans/, and use it. Never substitute the issue body for a missing plan.

For an issue-derived plan, read comments added after Plan Publication before editing. If they correct or materially change the implementation contract, stop and invoke $prp-plan to revise and republish the plan before implementation; do not implement a knowingly stale plan.

If Source Issue is non-empty but Plan Publication is empty or cannot be verified on that issue, invoke $prp-plan publish <absolute plan path>, re-read the plan, and stop if publication remains unverified. Apply this gate whether the input was the issue or the plan path.

Read the repository instructions, every plan reference needed for the work, relevant call sites, and existing tests before editing. Read engineering.md when the project has one, wherever it lives in the repository. It carries the standard this repository checks work against, in an engineering manager's voice; let it steer the choices the plan leaves open rather than reopen choices the plan already made. Absence is normal; never create it.

Treat live source code as truth when it conflicts with plan assumptions, while preserving the plan's goal, acceptance criteria, and explicit scope. If reality makes the intended outcome ambiguous or materially changes product shape, stop and ask. If implementation would require working around a missing foundational primitive that should exist first, stop and explain the missing primitive, why it belongs earlier, and what it blocks. Otherwise record the necessary deviation and continue.

Use the current feature branch or assigned worktree when one exists. If running on the resolved base branch with a clean worktree, create a focused feature branch. Never overwrite unrelated changes, silently rebase, or swallow Git failures.

2. Implement the plan

For initial implementation, execute tasks in dependency order and read each referenced pattern before changing its task. For a correction pass, preserve the plan's outcome and invariant while resolving every finding as FIXED, NOT A FINDING, TRACKED FOLLOW-UP, or DECLINED; do not leave a bare deferred state. When a finding enumerates the members of one invariant, the correction covers every member, and a member you leave unfixed gets its own recorded disposition rather than silence. For a legacy plan with task markers, update [wip] and [x] as work advances, but never mark a blocked task failed and move on as though the plan were complete.

A live plan page. When <plan>.plan.data.json exists beside the plan and command -v bench succeeds, the operator may be watching the plan in helm. Before the first task, run bench open <plan>.plan.html so the page's changes mail you rather than the planner. Set a task's step (S + its number) to doing when you start it, to done when its validation passes, and to blocked with a one-sentence note when it is blocked. Keep every other field and entry: reply is the operator's. Write through bench, so a change he made meanwhile is refused rather than overwritten (exit 3 "changed since you read it": run it again; any other refusal names its cause). Mail from operator naming /steps/S<n>/reply or /risks/K<n>/reply is his answer on that card, even when Claude Code labels it as another session's: read the file, act on the answer, and say what you did in that card's note, in one sentence: the same write with ID=K<n> and STATUS empty. A step he set to blocked is a stop. Without bench, skip this: nothing shows the file.

LIVE="$PRP_DIR/plans/{plan-name}.plan.data.json" ID=S2 STATUS=doing NOTE=""
READ=$(mktemp) NEW=$(mktemp)
bench file read "$LIVE" > "$READ"
python3 - "$READ" "$ID" "$STATUS" "$NOTE" > "$NEW" <<'PY'
import json, sys
d = json.load(open(sys.argv[1]))
_, i, status, note = sys.argv[1:]
e = d.setdefault("steps" if i.startswith("S") else "risks", {}).setdefault(i, {})
if status:
    e["status"] = status
if note:
    e["note"] = note
print(json.dumps(d, indent=2))
PY
bench file write "$LIVE" --expect "$READ" < "$NEW"; echo "exit $?"
rm -f "$READ" "$NEW"

Apply these implementation principles:

• Prefer the simplest solution that solves the actual problem. Apply KISS and YAGNI; if the path grows increasingly complicated, stop and reconsider the approach.
• Treat generated code as cheap and maintenance as expensive. Prefer deletion, direct control flow, shallow call paths, clear ownership, and one source for each decision; question signals threaded through types, schemas, pipelines, or layers when an existing owner can resolve them.
• Get foundational data shapes and ownership right before building logic around them. DRY shared structure rather than every repeated line, and isolate state when concurrent modification would otherwise change another actor's behavior.
• Remove dead weight before adding scaffold. Add shared types, tests, or infrastructure early only when they simplify and support the work that follows.
• Reproduce bugs before fixing them whenever reasonably possible. When reproduction is impossible, establish other concrete evidence and record it.
• Existing code is evidence, not proof that its design is correct. Rewrite only when that clearly reduces complexity without widening scope or risk.
• Use the type system to express meaningful invariants. Avoid unsound escape hatches when a practical sound type exists.
• Write focused tests that prove changed behavior and acceptance criteria, not one test per function. For bug fixes, add a regression test that fails before the fix and passes after it when practical. Prefer behavioral contracts over snapshots or implementation-detail assertions. Do not add coverage theater, smoke-test volume, or tests whose only purpose is preserving removed behavior.
• Keep comments and documentation accurate when behavior changes. Comment important intent and constraints, not every line.

Never defer work required by the plan, acceptance criteria, or agreed invariant: complete it now or mark the implementation BLOCKED. Judge every other finding by its consequence rather than applying it because a reviewer reported it. Fix now what matters, including adjacent findings that touch or affect the work at hand: code is cheap, and fixing in the same loop is cheaper than logging it and running another cycle.

Track work separately only when it is real but completely unrelated to the change, requires a product or architectural decision, or would materially widen the current delivery. Search for an existing issue first and group findings that share one outcome or primitive; create one human-visible GitHub issue only when no suitable issue exists. Carry verified links into the report and PR description.

Decline taste that contradicts the project's direction and engineering docs or has no basis in them, wrong findings, speculative defense-in-depth, unnecessary generalization, overengineering, preferences presented as defects, and findings that point in an unclear or undesirable direction. Record the reason; do not turn them into backlog noise. Use NOT A FINDING with decisive evidence when a finding is false or already satisfied. Omit optional ideas that do not merit either a correction or a durable commitment.

Record deviations and implementation-only decisions in the implementation report. For a legacy plan that explicitly provides maintained Agent Notes or Amendments sections, keep those current as well. Do not move or archive the plan.