plan

A command that runs the planning stage of the fable-flow software-development process. It turns the task and codebase investigation reports into a plan that can divide work into separate parallel tracks.

In plain words
What is it for?
Use it after exploration to plan a feature or fix, with an optional limit on parallel tracks. If the exploration reports are missing, it runs that stage first.
Why use it?
It gives implementers a shared technical plan and identifies design decisions that need to be resolved before coding, especially for a new project.

Command

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/jjilli/fable-flow/plan
Clone the repo
git clone --depth 1 https://github.com/jjilli/fable-flow
Per session 41 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 677 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00041 $0.00677
Opus 5 $0.00020 $0.00338
Sonnet 5 $0.00008 $0.00135
Haiku 4.5 $0.00004 $0.00068

Measured yesterday against content hash 684b0a2c760d, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

plan scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

commands/plan.md · 18 lines

What it actually says

Run the Plan phase of the fable-flow pipeline.

Input: $ARGUMENTS (may refine or replace the task in .fable-flow/task.md; --tracks N caps parallel tracks, default 3)

  1. Load the task (arguments, else .fable-flow/task.md) and the three scout digests .fable-flow/explore-*.md. If digests are missing, run the Explore phase first exactly as /fable-flow:explore describes, then continue.
  2. New/greenfield project — brainstorm direction first. When the task is a whole new project or a whole-product brief (little or no existing code to constrain the choices), don't jump to the plan. Surface every open design and direction decision you have and put each one to the user — do not truncate to a handful, and never silently assume a default on their behalf. Ask them as card-based multiple-choice questions (one decision per card, your recommended option first, and an option preview — a small ASCII mockup, code snippet, or layout sketch — wherever a visual side-by-side helps). The card UI takes only a few at a time, so ask across as many rounds as it takes, and keep going until nothing material is unresolved. Look up any fact yourself and spend the user's attention only on genuine decisions — but on all of them. Fold the answers into .fable-flow/task.md before planning; if planning later exposes a decision you never settled, put that to the user too rather than guessing. For a well-specified change to an existing codebase, skip this and plan directly. (This is the default clarification; the heavier opt-in grilling skill is only for when the user explicitly asks to be grilled.)
  3. Spawn one fable-flow:architect with: the task, all digests inline, the max track count, any relevant lessons from .fable-flow/memory/lessons/, and Base: <current branch> @ <HEAD sha>.
  4. Save the plan verbatim to .fable-flow/plan.md.
  5. Verify track file-ownership is pairwise disjoint. If two tracks own the same file: one revision request to the architect naming the overlaps; if it still overlaps, collapse the overlapping tracks into one and note that you did.

Then report: the plan's shape (tracks, what each owns, merge order), the contracts in one or two sentences, and the risks the architect called out. The deliverable of this command is the plan itself — don't start implementing. This is the user's sign-off point: they can revise the plan, then run /fable-flow:implement and /fable-flow:review stage by stage — or hand the whole thing off with /fable-flow:ship, which runs this same plan gate and then carries the run to completion (implement → merge → review → ship) without further check-ins.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 18 lines · 41 tokens per session scan A 684b0a2c760d

Subscribe to this mod's changes

plan is a command published in the GitHub repository jjilli/fable-flow (2 stars, last pushed 1mo ago), licensed MIT. It adds 41 tokens to every session and 677 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.