/flow-next-plan

name: flow-next-plan
description: Create structured build plans from feature requests or Flow IDs. Use when planning features or designing implementation. Triggers on /flow-next:plan with text descriptions or Flow IDs (fn-1-add-oauth, fn-1-add-oauth.2, or legacy fn-1, fn-1.2, fn-1-xxx, fn-1-xxx.2).
user-invocable: false

Flow plan

Turn a rough idea into a spec with tasks in `.flow/`. This skill does not write code.

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`.

Chart boundary (fn-135)

A **ready** (or already-captured) spec whose work is understood stays in plan - chart is too late. An unshaped oversized freeform idea with consequential unknowns is **not** plan input: recommend `/flow-next:chart` first (or `/flow-next:guide` when unsure). Plan decomposes work that is already understood; it does not replace discovery.

Preamble

**CRITICAL: flowctl is BUNDLED — NOT installed globally.** `which flowctl` will fail (expected). Define once; subsequent blocks (here and in `steps.md`) use `$FLOWCTL`:

FLOWCTL="${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/flowctl"
[ -x "$FLOWCTL" ] || FLOWCTL=".flow/bin/flowctl"

Copy-mode version drift

Before Step 0, read `.flow/meta.json` and `${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/.claude-plugin/plugin.json` once to perform this check. In copy mode only, when both `.flow/meta.json` `setup_version` and the installed plugin manifest version are available and differ, ask exactly `Local Flow-Next copy v<X> differs from plugin v<Y>. Refresh before planning?` via AskUserQuestion. Offer exactly **Refresh now (Recommended)** and **Continue this run**. Refresh stops cleanly, tells the user to run `/flow-next:setup`, then rerun Plan; never invoke Setup or resume this Plan invocation. Continue warns once and proceeds. Under autonomous, Ralph, or receipt-driven execution, warn once and proceed without asking. Version match, plugin mode, or unavailable comparison evidence is silent. Never read or write legacy `version_ack` / `snippet_ack`; Setup alone owns setup-mode and snippet integrity.

**Role**: product-minded planner with strong repo awareness. **Goal**: produce a spec with tasks that match existing conventions and reuse points. **Task size**: every task must fit one `/flow-next:work` iteration (~100k tokens max). If it won't, split it.

The Golden Rule: No Implementation Code

**Plans are specs, not implementations.** Do NOT write the code that will be implemented.

Code IS allowed:

• **Signatures/interfaces** (what, not how): `function validate(input: string): Result`
• **Patterns from this repo** (with file:line ref): "Follow pattern at `src/auth.ts:42`"
• **Recent/surprising APIs** (from docs-scout): "React 19 changed X — use `useOptimistic` instead"
• **Non-obvious gotchas** (from practice-scout): "Must call `cleanup()` or memory leaks"

Code is FORBIDDEN:

• Complete function implementations
• Full class/module bodies
• "Here's what you'll write" blocks
• Copy-paste ready snippets (>10 lines)

**Why:** Implementation happens in `/flow-next:work` with fresh context. Writing it here wastes tokens in planning, review, AND implementation — then causes drift when the implementer does it differently anyway.

Input

Full request: $ARGUMENTS

Accepts:

• Feature/bug description in natural language
• Flow spec ID `fn-N-slug` (e.g., `fn-1-add-oauth`) or legacy `fn-N`/`fn-N-xxx` to refine existing spec
• Flow task ID `fn-N-slug.M` (e.g., `fn-1-add-oauth.2`) or legacy `fn-N.M`/`fn-N-xxx.M` to refine specific task
• **Resolvable tracker handle** — a tracker key like `wor-17` / `wor-17.2` that `flowctl show` resolves to the linked spec/task (fn-52.10). Treated as the existing spec/task, **never** as a new idea (R16). See the handle-recognition rule in Step 1.
• Chained instructions like "then review with /flow-next:plan-review"

Examples:

• `/flow-next:plan Add OAuth login for users`
• `/flow-next:plan fn-1-add-oauth`
• `/flow-next:plan fn-1` (legacy formats fn-1, fn-1-xxx still supported)
• `/flow-next:plan fn-1-add-oauth then review via /flow-next:plan-review`

If empty, ask: "What should I plan? Give me the feature or bug in 1-5 sentences." Under autonomous mode, do not ask — report `NEEDS_HUMAN: no planning input provided` and stop.

FIRST: Parse Options or Ask Questions

Check configured backend:

REVIEW_BACKEND=$($FLOWCTL review-backend)

Returns: `ASK` (not configured), or `rp`/`codex`/`copilot`/`cursor`/`host`/`none` (configured).

Autonomous mode (mode:autonomous / FLOW_AUTONOMOUS)

Parse `$ARGUMENTS` for the literal token `mode:autonomous` (strip it, same shape as capture's `mode:autofix` — a NEW parse branch, never overloading that token). Also honor the env var `FLOW_AUTONOMOUS=1` as a secondary signal (process-level drivers). Either signal → `AUTONOMOUS=1`.

Under `AUTONOMOUS=1`:

• **Ask NO setup questions.** Explicit passthrough flags (`--depth`, `--research`, `--review`) win as usual; for anything unset, apply the autonomous defaults: depth = `short`, research = `grep` (repo-scout), review = configured backend (`none` when `REVIEW_BACKEND` is `ASK`).
• **Never hang on a question.** If a genuinely unanswerable ambiguity remains (e.g. empty input), stop cleanly with a one-line `NEEDS_HUMAN: <reason>` report instead of asking.
• Autonomy ≠ Ralph: neither `mode:autonomous` nor `FLOW_AUTONOMOUS` activates ralph-guard hooks or any receipt path — they gate question suppression only.

Option Parsing (skip questions if found in arguments)

Parse the arguments for these patterns. If found, use them and skip questions:

**Research approach**:

• `--research=rp` or `--research rp` or "use rp" or "context-scout" or "use repoprompt" →