Planning and Steering
#Plans
| Command or prompt | Intent |
|---|---|
plan: <request> |
Require Flux to create a structured plan before it starts the request. |
/plan |
Show the active plan, its step states, and recorded verification commands. |
/plan clear |
Remove the active plan when it is no longer useful. |
no plan or skip plan |
Ask Flux to execute a request directly without creating a plan. |
Prefix a request with plan: to force a structured plan:
plan: migrate the API client to the new authentication flow
Flux can also create a plan automatically for sufficiently complex refactors, migrations, or multi-phase work. Auto-generated plans usually contain 2 to 5 high-level steps. The active plan is saved in ./.flux/.plan-state.json, and Flux expects to work one step at a time with step states such as pending, in_progress, done, and failed.
plan: and plan - ... are explicit opt-ins. Flux also recognizes opt-outs such as no plan, skip plan, don't plan, without a plan, and do not ... plan. /plan only shows or clears the active plan; there are no /plan add or /plan edit subcommands.
#Steering
| Command | Intent |
|---|---|
/steer <directive> |
Add <directive> as session-scoped direction for the active task. |
/steer list |
Show the active steering directives. |
/steer remove <number> |
Remove the directive at <number>. |
/steer clear |
Remove every active steering directive. |
Steers add session-scoped direction to the active task without rewriting the original request:
/steer preserve backward compatibility
/steer list
/steer remove 1
/steer clear
Use steering when constraints change mid-task, a deadline narrows the scope, or a subagent also needs the updated direction. Steers are included in subsequent agent and subagent prompts until removed. They are in-memory only: they are not written to disk or resumed in a later CLI process. Running bare /steer behaves like /steer list.
#Independent subagents
Flux may delegate self-contained work to parallel subagents. Each gets its own conversation context and the available tools, while confirmations remain visible in the main UI. Flux currently allows up to five concurrent subagents. Write-oriented subagents attempt to work in isolated Git worktrees and apply their changes back afterward; if the merge-back step fails, Flux reports a warning. See plugins and subagents for details.