Flow work
Execute a plan systematically. Focus on finishing.
Follow this skill and linked workflows exactly. Deviations cause drift, bad gates, retries, and user frustration.
IMPORTANT: This plugin uses .flow/ for ALL task tracking. Do NOT use markdown TODOs, plan files, TodoWrite, or other tracking methods. All task state must be read and written via flowctl.
Preamble
CRITICAL: flowctl is BUNDLED — NOT installed globally. which flowctl will fail (expected). Define once; subsequent blocks (here and in phases.md) use $FLOWCTL:
FLOWCTL="$HOME/.codex/scripts/flowctl"
[ -x "$FLOWCTL" ] || FLOWCTL=".flow/bin/flowctl"
Pre-check: Local setup version
Non-blocking, same pattern as /flow-next:plan — one-line nag when the local setup lags the plugin:
SETUP_VER=$(jq -r '.setup_version // empty' .flow/meta.json 2>/dev/null)
PLUGIN_JSON="${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-$HOME/.codex}}/.codex-plugin/plugin.json"
PLUGIN_VER=$(jq -r '.version' "$PLUGIN_JSON" 2>/dev/null || echo "unknown")
if [[ -n "$SETUP_VER" && "$PLUGIN_VER" != "unknown" && "$SETUP_VER" != "$PLUGIN_VER" ]]; then
echo "Plugin updated to v${PLUGIN_VER}. Run /flow-next:setup to refresh local scripts (current: v${SETUP_VER})." >&2
fi
Continue regardless (never blocks; silent when setup was never run or versions match).
Hard requirements (non-negotiable):
- You MUST run
flowctl donefor each completed task and verify the task status isdone. - You MUST stage with
git add -A(never list files). This ensures.flow/andscripts/ralph/(if present) are included. - Do NOT claim completion until
flowctl show <task>reportsstatus: done. - Do NOT invoke
/flow-next:impl-reviewuntil tests/Quick commands are green.
Role: execution lead, plan fidelity first. Goal: complete every task in order with tests.
Ralph Mode Rules (always follow)
If REVIEW_RECEIPT_PATH is set or FLOW_RALPH=1:
- Must use
flowctl doneand verify task status isdonebefore committing. - Must stage with
git add -A(never list files). - Do NOT use TodoWrite for tracking.
Autonomous Mode (questions off, no receipt obligations)
If $ARGUMENTS contains the literal token mode:autonomous (strip it — same parse shape as capture's mode:autofix, a NEW branch) or FLOW_AUTONOMOUS=1 is set:
- Ask NO setup questions (branch + review questions below are suppressed).
- Branch defaults deterministically to
--branch=newwhen no explicit branch option is present — under autonomy "the user's answer" never exists, and defaulting to the current branch could commit straight to main. Name the new branch exactly the spec'sbranch_namefield ($FLOWCTL show <spec-id> --json | jq -r '.branch_name') — pilot's branch matrix, its all-done PR probe, and make-pr's branch-match spec detection all key on that name; an ad-hoc name breaks multi-tick continuity. - Review = explicit
--reviewpassthrough if present, else the configured backend (nonewhenREVIEW_BACKENDisASK). - Autonomy ≠ Ralph. Neither signal sets
FLOW_RALPH, impliesREVIEW_RECEIPT_PATHreceipt obligations, or activates ralph-guard hooks. The Ralph rules above apply only under their own markers (the done/git add -A/no-TodoWrite discipline is universal anyway). - Never hang on a question. A genuinely unanswerable ambiguity → stop cleanly with a one-line
NEEDS_HUMAN: <reason>report instead of asking.
Input
Full request: $ARGUMENTS
Accepts:
- Flow spec ID
fn-N-slug(e.g.,fn-1-add-oauth) or legacyfn-N/fn-N-xxxto work through all tasks - Flow task ID
fn-N-slug.M(e.g.,fn-1-add-oauth.2) or legacyfn-N.M/fn-N-xxx.Mto work on single task - Markdown spec file path (creates spec from file, then executes)
- Idea text (creates minimal spec + single task, then executes)
- Chained instructions like "then review with /flow-next:impl-review"
Examples:
/flow-next:work fn-1-add-oauth/flow-next:work fn-1-add-oauth.3/flow-next:work fn-1(legacy formats fn-1, fn-1-xxx still supported)/flow-next:work docs/my-feature-spec.md/flow-next:work Add rate limiting/flow-next:work fn-1-add-oauth then review via /flow-next:impl-review
If no input provided, ask for it.
FIRST: Parse Options or Ask Questions
Check configured backend:
REVIEW_BACKEND=$($FLOWCTL review-backend)
Returns: ASK (not configured), or rp/codex/none (configured).
Option Parsing (skip questions if found in arguments)
Parse the arguments for these patterns. If found, use them and skip corresponding questions:
Branch mode:
--branch=currentor--currentor "current branch" or "stay on this branch" → current branch--branch=newor--new-branchor "new branch" or "create branch" → new branch--branch=worktreeor--worktreeor "isolated worktree" or "worktree" → isolated worktree
Review mode:
--review=codexor "review with codex" or "codex review" or "use codex" → Codex CLI (GPT 5.5 High)--review=rpor "review with rp" or "rp chat" or "repoprompt review" → RepoPrompt chat (viaflowctl rp chat-send)--review=exportor "export review" or "external llm" → export for external LLM--review=noneor--no-reviewor "no review" or "skip review" → no review
Autonomous mode:
mode:autonomoustoken (stripped from arguments) orFLOW_AUTONOMOUS=1env → suppress ALL setup questions; defaults per the Autonomous Mode section above (branchnew, review = configured backend).
If options NOT found in arguments
If AUTONOMOUS=1 (autonomous mode): ask nothing — apply the autonomous defaults and continue to the workflow.
If REVIEW_BACKEND is rp, codex, or none (already configured): Only ask branch question. Show override hint:
Quick setup: Where to work?
a) Current branch b) New branch c) Isolated worktree
(Reply: "a", "current", or just tell me)
(Tip: --review=rp|codex|export|none overrides configured backend)
If REVIEW_BACKEND is ASK (not configured): Ask both branch AND review questions:
Quick setup before starting:
1. **Branch** — Where to work?
a) Current branch
b) New branch
c) Isolated worktree
2. **Review** — Run Carmack-level review after?
a) Codex CLI
b) RepoPrompt
c) Export for external LLM
d) None (configure later with --review flag)
(Reply: "1a 2a", "current branch, codex", or just tell me naturally)
Wait for response. Parse naturally — user may reply terse or ramble via voice.
Defaults when empty/ambiguous:
- Branch =
new - Review = configured backend if set, else
none(no auto-detect fallback)
Do NOT read files or write code until user responds.
Workflow
After setup questions answered, read phases.md and execute each phase in order.
Worker agent model: Each task is implemented by the worker agent role with fresh context. This prevents context bleed between tasks and keeps re-anchor info with the implementation. The main conversation handles task selection and looping; worker agent handles implementation, commits, and reviews.
If user chose review, pass the review mode to the worker. The worker agent invokes /flow-next:impl-review after implementation and loops until SHIP.
Completion review gate: When all tasks in a spec are done, if --require-completion-review is configured (via flowctl next), the work skill invokes /flow-next:spec-completion-review before allowing the spec to close. This verifies the combined implementation satisfies the spec. The spec-completion-review skill handles the fix loop internally until SHIP.
Tracker sync (opt-in, off by default)
The no-tracker path is the documented default and is behaviorally unchanged. Every tracker touchpoint below runs ONLY when the bridge is active AND the specific event is opted in; otherwise it is a silent no-op (no new steps, no new prerequisites). The bridge is active iff `flowctl sync