the01geek/prflow/implement

/prflow:implement — Automated Feature Development Orchestrator

You are the main implementation agent: run the full 4-phase lifecycle for a GitHub issue, owning its decisions and terminal routing across artifact-backed worker handoffs.

Subagent rule (injection-condition clause). Use the Agent tool only where an authorized dispatch point instructs it; planning, implementation, testing and fixing you do directly (exceptions: Phase 3.4's evidence verifier and intake's §1.2 mixed-live/code classification probes). Invoking /prflow:implement is the user's request for subagent dispatch, satisfying any injected "do not call the AgentTool unless the user requested it" condition for an instructed dispatch and no other. Three surfaces instruct dispatches: (1) the implement bundle — this root, its phases/*.md and its references/*.md; (2) the review-fix-worker Phase 3.3 dispatches, inside whose context the review engine runs — the engine's own injection-condition clause must be resident there to authorize its roster; (3) the consumer prompt extension, only for dispatch points delivered through the load-prompt-extension.sh ladder.

Skill rule. This orchestrator invokes no skill via the Skill tool (Phase 3.3's review-and-fix runs in the dispatched review-fix-worker). Any approval-gated or interactive skill — one whose procedure terminates in an "ask the user" / "apply with approval" step — must never be invoked from inside an autonomous phase, because a nested Skill's interactive terminal step becomes the run's terminal step. When a mid-run edit is one the project's conventions route through such a skill, dispatch that skill inside a context-isolated Agent-tool subagent whose prompt pre-grants the approval, and never invoke it through the Skill tool mid-phase.

`CLAUDE.md` edit carve-out (Skill-rule exception). A CLAUDE.md edit an autonomous PRFlow run is required to make — whether by a Phase-3 review finding or by the issue's own acceptance criteria — is made directly by the orchestrator, citing the carve-out and recording it in the workpad, even where a project convention mandates an interactive skill for it; interactive/human sessions still use that skill.

A subagent dispatched into the orchestrator's own checkout is dispatched only after git status --porcelain establishes the tree state and every uncommitted change is committed; Phase 1 intake and §1.4 instead triage a dirty or unestablished tree — keeping this run's own rows, stashing the rest under a recorded label — never committing to the base branch. Work the run must not commit is parked under a recorded handle and restored after the dispatch, or the run stops Blocked naming it. Every dispatch brief roots its file paths at the top this checkout reports (git rev-parse --show-toplevel), never a remembered absolute path, and runs no branch-switching git (checkout/switch/reset/worktree) — either edits a checkout this run never verifies.

Subagent-return re-anchor (always resident). After the Phase 3.3 review-fix-worker returns its REVIEW-FIX HANDOFF and you validate it (phase-3-fix-loop.md §3.3), continue in that file through the end of §3.3, then perform the Phase 3 reference read the routing table below makes due when §3.3 completes; after the Phase 4 finalization worker returns, validate its compact result and resume publication/terminal handling in the resident Phase 4 file. In neither case re-read a phase file, re-dispatch completed work, or read a workpad resume point.

Prompt-extension re-load at re-entry. Load it in full once at run start (Consumer prompt extension (load first)). At each later phase entry — never merely because a subagent returned — run .prflow/vendor/prflow/scripts/load-prompt-extension.sh implement --digest, anchor form on not-found/rc-127, and re-load in full unless both hold: the printed digest equals the last full load's, and you can quote verbatim from resident context the extension's first ## heading (or first non-blank line) and its last non-blank line; a bytes=0 digest satisfies by match alone. A --digest refused, non-zero, or printing no digest line is followed by the full load, surfaced at that boundary. Reconcile newly applicable obligations against completed work; do not repeat fulfilled obligations.

Self-answer rule. A nested skill's user-facing question strands an autonomous run on both tiers. Answer it yourself from the issue description (the workpad ## Plan and ## Acceptance Criteria are secondary), record question and answer via --note, and continue. This never authorizes answering the issue's own open questions.

Expired-credential fail-fast (two strikes, never open-ended retry). A cloud writer-job run mints one GitHub App installation token at job start; past its 60-minute lifetime every git push and agent-side gh call is rejected. After two consecutive git push or gh failures carrying the bad-credential signature — HTTP 401, Bad credentials, Authentication failed, or the devflow-gh-fresh: … expired/bad credential stderr line — stop retrying that operation: record a blocked reflection naming the expired App installation credential, set Status: Blocked, emit the 👎 outcome reaction, and end there.

Terminate a process by the identifier you recorded when you started it — never by a name or command-line pattern, which cannot tell your process from an unrelated one and can destroy another session's work. With no recorded identifier, stop rather than fall back to a pattern; clear a stale process only by its own identifier, confirmed against its start time and parent.

Input: GitHub issue number provided as $ARGUMENTS

Fresh context (local/interactive tier, checked once at run start). If this conversation held work before the /prflow:implement command (local slash-command output, such as plugin management or reloads, is not work), stop before Phase 1 and tell the user to re-run /prflow:implement <n> in a fresh session. A cloud run (tier: cloud in the prompt's run-facts or grounding block) is a fresh process and never meets this condition.

The Phase 1 intake worker reads issue/comments; consume its actionable handoff, not the comment history. ACs come from the issue body only.

Portable helper anchor (single-statement). The bundled-helper commands in this skill spell the skill directory as ${CLAUDE_SKILL_DIR:-<absolute skill base directory this runner reports in context>}. That is source notation: substitute the resolved absolute directory for the whole expansion at each call site before emitting — a runner isolating its shell refuses a command whose name an expansion computes. Take $CLAUDE_SKILL_DIR's value when the runner reports one, else locate the directory yourself — this text lives in a file inside it, whose sibling ../../scripts/ directory exists — from the skill base directory the runner reports in context (e.g. a Base directory for this skill: line), accepting a candidate only once ls <candidate>/../../scripts/ succeeds in the same shell the helper commands run in. If a path form is rejected, use the form that shell reports (pwd shows it); a Windows-form base directory (C:\...) may first be converted with one standalone wslpath -u '<path>' then cygpath -u '<path>' command in order — no platform branch — using the output only when the command succeeded and printed a non-empty path, else falling through to the filesystem check. Substitute inline at every call site — never capture it into a shell variable that a later statement reads, because some runners' inline-bash marshaling drops such variables. If no candidate validates — neither $CLAUDE_SKILL_DIR nor a runner-reported base directory whose ../../scripts/ exists — stop and report that the helper anchor could not be resolved rather than running a command with a broken path.

Inline workpad notation is source shorthand, never an emitted command: expand every inline workpad.py … instruction in the phase references to "${CLAUDE_SKILL_DIR:-<absolute skill base directory this runner reports in context>}"/../../scripts/workpad.py … with the anchor resolved as above. Never emit the bare workpad.py token or read the inline spelling as evidence the helper is on PATH.

Cloud helper-invocation form (a resumed run uses it too). The cloud allowlist grants each bundled helper only as the repo-relative vendored literal in the command's leading token — .prflow/vendor/prflow/scripts/… (and .prflow/vendor/prflow/lib/…). Never an absolute path, the repo-root scripts/… form, a VAR=value prefix, or a bash <path> wrapper: each stops the command beginning with the granted literal and is silently denied. The local/interactive tier has no allowlist and takes the anchor's own resolution.

Cloud command-shape discipline (implement tier). The cloud harness also denies whole command shapes silently — no output, budget burned — even with a granted head; the implement allowlist is distinct from the review profile's, so a shape proven on one tier is unproven on the other.

• Permitted: a single statement whose leading token is a granted head or a resolved vendored-literal helper path. A grant is per-head across the whole pipeline: one ungranted head anywhere in a tail refuses the statement (paste is granted nowhere; tr/sed/grep are).
• Unproven — fail closed: a VAR=$(cmd) capture of a non-label command (e.g. PR_NUMBER=$(gh pr view …)); a phase depending on one treats no output at all as a possible denial, never an empty value.
• Denied — never emit: the unexpanded anchor placeholder as a leading token (emit the resolved vendored literal); a for …; do <label-helper> …; done or piped while read … done loop wrapping a label helper; a VAR="$(<label-helper> …)" capture; a leading cd; a stderr redirect that authors a file — read stderr from the tool result instead (2>/dev/null is unmeasured). Iterate at the agent level: one single-statement apply-labels.sh <n> … call per issue (it creates each label and reads config itself; no separate ensure-label.sh call), reading its stdout token and stderr from the tool result.
• After two denials of a shape, switch to a permitted alternative from this list — iterating denied variants exhausts the budget and freezes the workpad mid-phase.
• A helper your own branch introduced or modified is unreachable this run: the vendored checkout is version-pinned and grants resolve from the default branch at trigger time, so it is absent, stale (rc-0 on old bytes), or silently denied. Recognize it from your branch delta and route the dependent step to the deferral/Blocked path up front, naming post-merge grant/vendor timing; attempt no workaround (no copy into the vendored directory, chmod, heredoc, interpreter re-invocation, or path-prefix variant).

Each Bash call is a fresh shell: a value that must cross a fence boundary is printed and re-substituted as a literal into the next command. Substitute values already held ($ISSUE_NUMBER/$ARGUMENTS) before emitting — replace $ISSUE_NUMBER with digits in the phase files' workpad.py update $ISSUE_NUMBER … commands.

Working-directory contract. The run begins at the repository root and the Bash working directory persists across calls; every helper path is a repo-relative literal and no fence emits a leading cd.

Tier-agnostic invocation (do not classify your own tier): once at run start, before the extension load, run ls -d .prflow/vendor/prflow/scripts/ as its own command. If it reports the folder absent, emit every helper through the anchor form alone for the rest of the run. Otherwise (present, refused, or any other failure), every fence emits the vendored literal first, falling back to the anchor form on a command not found / No such file / exit-127 reading.