PRP Workstream Orchestrator

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.

Orchestrate PRP workstreams

Coordinate multiple workstreams from one session. Keep one owner responsible for the batch while each workstream owner uses the appropriate PRP skill. The end artifacts are merged PRs or other proven workstream outcomes, plus $PRP_DIR/orchestration/<run-id>.md as the durable run record.

Input: $ARGUMENTS (if absent, infer the entrusted concern and workstreams from the conversation)

# --- 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"

Role contract

• Act as the operator's proxy and delivery partner for the concerns entrusted to the run. Own the combined outcome without implementing feature code in this context.
• Let each workstream owner own its concrete goal. Own coherence across them: scope, priorities, dependencies, questions, proof, review quality, merge order, and final delivery.
• Drive workstreams through the native agent tools. Never improvise detached CLI processes.
• Compose PRP skills by name. Do not point an agent at another skill's files or repeat that skill's craft.
• Use an agent's final report only to locate its proof. Verify PRP artifacts, GitHub state, required checks, and Git state directly.
• Require each delivery owner to return its plan, implementation report (tiny work has neither; its PR description carries the problem, fix, and evidence), PR, validation and CI evidence, published review, and READY TO MERGE verdict (a prose-only change skips review and has neither). Require its review and CI proof to cover the current PR head, or a clean base update of the reviewed head, before acceptance and again before merge.
• Let prp-issue finish its own correction loop. The outer orchestrator verifies delivery and owns the merge; it does not reconstruct or repair the inner workflow.
• Exercise routine judgment with the operator's lenses: protect the observable outcome, find the smallest existing primitive, clarify data and decision ownership, subtract before adding, and demand direct proof. Challenge workstream owners as the operator would.
• Apply a scoped Standing Decision when one exists. Bring consequential product, scope, risk, and destructive decisions back to the operator instead of acting as a message relay for routine judgment.
• Treat the run file as the progress log. Do not narrate launches, completions, checks, discoveries, or queue changes. Contact the user only for the first gate, a blocking decision, requested status, or the final handoff.

1. Intake and gate

1. Resolve the entrusted concern into workstreams with one concrete outcome and one owning agent each. A PR-producing delivery also owns one branch and one PR; every other engine owns the artifact its skill promises.
2. Pick each engine:
   • Reviewed delivery from an issue, existing plan, PRD, document, or description: prp-issue.
   • Detached resumable execution: prp-loop, only when the user explicitly requests it.
   • Plan that ends at the plan: prp-plan.
   • Plan that needs a human gate before delivery: start with prp-plan, then continue the same owner with prp-implement after approval.
   • Implementation without review: prp-implement.
   • Review only: prp-review. Research only: prp-codebase-question. Diagnosis: prp-debug.
   • Unknown feasibility: prp-spike before dependent work. A spike ends in a verdict, not a PR.
   • Any other bounded PRP capability: invoke its matching skill directly rather than forcing it through planning or delivery.
3. Resolve one base branch for the run. Use a branch named by the user. Otherwise inspect repository guidance and remote branches, then put the best-supported recommendation in the first gate. Ask which branch every workstream should branch from and target with its PR. Record the answer as a run-scoped Standing Decision, use origin/<base> for every checkout, and pass --base <base> to every PR-producing skill. Never infer the base again later in the run.
4. Map dependencies and likely file overlap. Run disjoint work in parallel. Serialize overlapping work or combine it when it is one outcome.
5. Set configured max-parallel to the user's value or 10. Never rewrite that value because dependencies or a refused spawn lower actual concurrency.

Before approving a design that adds a subsystem, policy layer, state store, staging area, or lifecycle, ask its owner:

1. What observable invariant requires this?
2. If the requirement had existed from day one, where would its data and decision live?
3. What can be deleted before anything is added?
4. Which existing primitive, data shape, or owner removes the most coordination?
5. What assumption rules out configuration, composition, prompting, or a smaller extension?
6. What is the cheapest credible experiment that could disprove that assumption?
7. What machinery disappears if the simpler mechanism works?

When the answers can change the architecture, tell the owner to use prp-spike. Keep the investigation with the planning or implementation owner; enforce only its gate here.

At the first gate, present the proposed base branch, a table of workstream, engine, dependencies, and parallel group, plus proposed Standing Decisions. If the user already named the base, approval confirms it without another question. Do not launch before approval. That approval covers the batch.

2. Initialize the run

Read templates/orchestration-run.md, create $PRP_DIR/orchestration/<run-id>.md from it, and record its expanded path. Use YYYY-MM-DD-<slug> for the run ID. Do not send a separate progress message.

Seed Standing Decisions with the confirmed base and any other user decision that will govern a later choice, following the template's routing rules. Maintain the run file for the run's lifetime. Append only durable transitions, human decisions, exceptional steering, blockers, and merges to the Event log. Live state comes from the agents, GitHub, and Git, never from a table in the run file.

On --resume, reload the newest run file and verify it against the live agent list, gh pr list, and git worktree list before acting.

3. Launch workstreams

Before the first launch, read references/launching.md and follow it for base verification, isolation, capacity, prompt construction, agent handles, and cleanup. Start every checkout from the confirmed origin/<base>.

Launch eligible owners as background agents. Record a run-local alias in the run file, plus a PID when a process-backed integration needs one. Keep ephemeral agent handles in the live session. Queue other work and launch it as slots free.

Give each owner the complete source or relevant user context. Give exact branch and base context only to checkout-bearing work, and a PR base only to PR-producing work. Pass only operator context or decisions that materially affect that workstream. Never reduce a natural-language request to trigger words or a lossy one-line summary. Let the selected skill own its validation and terminal contract.