Spec Completion Review Mode
Workflow is backend-split. Read workflow-common.md for Phase 0 (backend detection + philosophy), then read ONLY the file matching your active backend:
BACKEND=codex→ workflow-codex.mdBACKEND=copilot→ workflow-copilot.mdBACKEND=cursor→ workflow-cursor.mdBACKEND=rp→ workflow-rp.md
Do not load the others — only the active backend's file is needed.
Verify that the combined implementation of all tasks in a spec satisfies the spec requirements. This is NOT a code quality review (that's impl-review's job) — this confirms spec compliance only.
Role: Spec Completion Review Coordinator (NOT the reviewer)
Backends (branch on the Phase 0 RP_ELIGIBLE probe):
- When
RP_ELIGIBLE=1: RepoPrompt (rp), Codex CLI (codex), GitHub Copilot CLI (copilot), or Cursor CLI (cursor) - When
RP_ELIGIBLE=0: Codex CLI (codex), GitHub Copilot CLI (copilot), or Cursor CLI (cursor) — rp is macOS-only; never list it in guidance you surface (--review=rpstays accepted)
Preamble — execute Phase 0 exactly once
The executable Phase 0 lives in workflow-common.md §"Phase 0: Backend Detection" — Read it and execute it ONCE, before any other bash in this skill. It defines $FLOWCTL (bundled — NOT installed globally; which flowctl fails, expected), probes RP_ELIGIBLE, resolves $BACKEND via the single flowctl review-backend call, and handles the ASK / none cases. Never invoke flowctl review-backend a second time in the same run.
Exception: a --review=<backend> argument (see Backend Selection below) wins — when present, set BACKEND from the flag and skip Phase 0's review-backend call + ASK handling (still run its $FLOWCTL / RP_ELIGIBLE setup lines).
When RP_ELIGIBLE=0 (not macOS, no rp-cli), never steer the user toward rp: every backend summary, recommendation, or override hint you surface presents only the runnable configured backends codex, copilot, cursor (plus none). Suppression is not a ban: an explicit --review=rp, FLOW_REVIEW_BACKEND=rp, or review.backend=rp still resolves to rp and errors at runtime via require_rp_cli() as today.
Backend Selection
Priority (first match wins):
--review=rp|codex|copilot|cursor|noneargumentFLOW_REVIEW_BACKENDenv var — bare backend (rp,codex,copilot,cursor,none) OR spec form (codex:gpt-5.4:xhigh,copilot:claude-opus-4.5,cursor:gpt-5.5-high).flow/config.json→review.backend(same bare / spec forms)- Error - no auto-detection
Parse from arguments first
Check $ARGUMENTS for:
--review=rpor--review rp→ use rp--review=codexor--review codex→ use codex--review=copilotor--review copilot→ use copilot--review=cursoror--review cursor→ use cursor--review=noneor--review none→ skip review
If found, use that backend and skip all other detection.
Otherwise: Phase 0 resolves it
No --review flag → $BACKEND comes from workflow-common.md Phase 0 (executed once per the Preamble): the single flowctl review-backend "$SPEC_ID" call with ASK handling included. Do not re-resolve here.
Backend at a glance
When RP_ELIGIBLE=0, omit the rp line below from any guidance you surface (explicit --review=rp still honored):
- rp — RepoPrompt (macOS GUI); builder auto-selects context. Primary backend.
- codex — Codex CLI (cross-platform); uses OpenAI models (default
gpt-5.5).FLOW_CODEX_MODEL/FLOW_CODEX_EFFORTenv vars, or--spec codex:gpt-5.4:xhigh. - copilot — GitHub Copilot CLI (cross-platform); supports Claude Opus/Sonnet/Haiku 4.5 and GPT-5.2 families via a Copilot subscription.
FLOW_COPILOT_MODEL/FLOW_COPILOT_EFFORTenv vars, or--spec copilot:claude-opus-4.5:xhigh. - cursor — Cursor CLI (
cursor-agent, cross-platform); reachesgpt-5.5-high(1M-ctx default), thegpt-5.3-codexfamily,composer-2.5, andclaude-opus-4-8-thinking-highvia a Cursor subscription.FLOW_CURSOR_MODELenv var, or--spec cursor:gpt-5.5-high. Cursor folds reasoning effort into the model name — no effort field.
Spec grammar: backend[:model[:effort]] — FLOW_REVIEW_BACKEND and .flow/config.json review.backend both accept this. Examples: codex, codex:gpt-5.2, copilot:claude-opus-4.5:xhigh, cursor:gpt-5.5-high (cursor takes model only — no :effort). Per-spec default_review (set via flowctl spec set-backend) overrides env.
Critical Rules
For rp backend:
- DO NOT REVIEW CODE YOURSELF - you coordinate, RepoPrompt reviews
- MUST WAIT for actual RP response - never simulate/skip the review
- MUST use
setup-review- handles window selection + builder atomically - DO NOT add --json flag to chat-send - it suppresses the review response
- Re-reviews MUST stay in SAME chat - omit
--new-chatafter first review
For codex backend:
- Use
$FLOWCTL codex completion-reviewexclusively - Pass
--receiptfor session continuity on re-reviews - Parse verdict from command output
For copilot backend:
- Use
$FLOWCTL copilot completion-reviewexclusively - Pass
--receiptfor session continuity on re-reviews (session only resumes when prior receipt hasmode == "copilot") - Model + effort resolved via (first match wins):
--spec backend:model:effortflag, per-specdefault_review,FLOW_REVIEW_BACKENDspec,FLOW_COPILOT_MODEL/FLOW_COPILOT_EFFORTenv vars, registry defaults - Parse verdict from command output
For cursor backend:
- Use
$FLOWCTL cursor completion-reviewexclusively - Pass
--receiptfor session continuity on re-reviews (session only resumes when prior receipt hasmode == "cursor") - Model resolved via (first match wins):
--spec cursor:<model>flag, per-specdefault_review,FLOW_REVIEW_BACKENDspec,FLOW_CURSOR_MODELenv var, registry default (gpt-5.5-high). No effort — Cursor bakes effort into the model name;cursor:<model>:<effort>is rejected - Parse verdict from command output
For all backends:
- If
REVIEW_RECEIPT_PATHset: write receipt after SHIP verdict (RP writes manually after fix loop; codex writes automatically via--receipt) - Any failure → output
<promise>RETRY</promise>and stop
FORBIDDEN:
- Self-declaring SHIP without actual backend verdict
- Mixing backends mid-review (stick to one)
- Skipping review silently (must inform user and exit cleanly when backend is "none")
Input
Arguments: $ARGUMENTS
Format: <spec-id> [--review=rp|codex|copilot|cursor|none]
- Spec ID - Required, e.g.
fn-1orfn-22-53k --review- Optional backend override
Workflow
REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
Step 0: Parse Arguments
Parse $ARGUMENTS for:
- First positional arg matching
fn-*→SPEC_ID --review=<backend>→ backend override- Remaining args → focus areas
Step 1: Load Backend Workflow
$BACKENDwas already resolved by workflow-common.md Phase 0 (Preamble) — do NOT re-run it.- Read only the file for that backend:
| $BACKEND | File to read |
|------------|--------------|
| codex | workflow-codex.md |
| copilot | workflow-copilot.md |
| cursor | workflow-cursor.md |
| rp | workflow-rp.md |
Do not read the other backend files. Each is self-contained for its backend; loading the others wastes context.
Step 2: Execute the backend workflow
Follow the phases in the per-backend file end-to-end. Each file owns its own Identify → Execute → Verdict → Receipt steps (and, for RP, the full Phase 1-4 setup-review / chat-send / receipt build).
Fix Loop (INTERNAL - do not exit to Ralph)
CRITICAL: Do NOT ask user for confirmation. Automatically fix ALL valid issues and re-review — our goal is complete spec compliance. Never use AskUserQuestion in this loop.
MAX ITERATIONS (backend-agnostic — applies to ALL backends: rp, codex, copilot, cursor): keep an iteration counter in agent context, starting at 0. Each fix+re-review cycle increments it. When the counter reaches ${MAX_REVIEW_ITERATIONS:-4} (default 4; env-overridable, configurable in Ralph's config.env) and the verdict is still NEEDS_WORK, BREAK the loop and escalate: surface the surviving gaps to the caller and stop (in Ralph mode output <promise>RETRY</promise> so the next iteration starts fresh). Never loop unbounded. The per-backend workflow files defer to this cap.
If verdict is NEEDS_WORK, loop internally until SHIP or the iteration cap:
- Parse issues from reviewer feedback (missing requirements, incomplete implementations)
- Fix code and run tests/lints
- Commit fixes (mandatory before re-review; RP backend uses the snapshot-scoped staging in workflow-rp.md — never blanket-stage with
git add --all) - Re-review:
- Codex: Re-run
flowctl codex completion-review(receipt enables context) - Copilot: Re-run
flowctl copilot completion-review(receipt enables context; must bemode == "copilot"to resume) - Cursor: Re-run
flowctl cursor completion-review(receipt enables context; must bemode == "cursor"to resume) - RP:
$FLOWCTL rp chat-send --window "$W" --tab "$T" --message-file <literal re-review path from workflow-rp.md's fix loop>(NO--new-chat; stdout redirected to the same literal response file, Read once)
- Codex: Re-run
- Repeat until
<verdict>SHIP</verdict>— or the MAX ITERATIONS cap above breaks the loop (escalate with surviving gaps)
CRITICAL: For RP, re-reviews must stay in the SAME chat so reviewer has context. Only use --new-chat on the FIRST review.
Step 3: Record the verdict (MANDATORY — every backend, every terminal outcome)
The moment the fix loop terminates, write the outcome back so the rest of the pipeline sees it — exactly as /flow-next:plan-review writes set-plan-review-status. Without this, a standalone completion review leaves completion_review_status: unknown, which keeps flowctl ready --require-completion-review demanding a review (pilot's gate), feeds make-pr's Open-items / draft heuristic stale state, and blocks tracker-sync's terminal verified rung.
# Final verdict resolved to SHIP → ship; NEEDS_WORK at the iteration cap → needs_work.
$FLOWCTL spec set-completion-review-status "$SPEC_ID" --status ship --json # on SHIP
$FLOWCTL spec set-completion-review-status "$SPEC_ID" --status needs_work --json # on NEEDS_WORK at cap
Write it on BOTH terminal paths (SHIP and capped-NEEDS_WORK). This is the same write /flow-next:work performs when it runs completion-review inline; a standalone invocation must not skip it.