| name | fable5-planning-workflow |
| description | Fable 5-tuned planning orchestrator. Turns goals into validated, ready APS work with minimal ceremony — acts when enough is known, recommends instead of surveying, and treats the plan as a living artifact it may evolve. Use when running on Claude Fable 5 and work needs planning, replanning, or a readiness decision. Companion to fable5-dev-workflow and fable5-aps-loop; prior-model projects use planning-workflow instead. |
Fable 5 Planning Workflow
Turn intent into a validated, ready work item — or an honest decision that
the work is blocked or out of scope. Same handoff contract as
planning-workflow; leaner path to it. This workflow never writes code and
never creates branches.
Operating stance
When you have enough information to plan, plan. Do not re-derive facts
already established in the conversation, re-litigate decisions the user has
already made, or survey options you will not pursue. If approaches genuinely
compete, give a recommendation with the deciding trade-off, not a catalogue.
Ask the user one question only when the next planning step would otherwise be
guesswork on something only they can answer — product intent, risk appetite,
scope boundaries. Everything else, resolve from project truth and record the
assumption.
Path
- Ground in project truth. Current source, tests, ADRs, release state,
and feature flags outrank stale plan prose. Where the plan and the code
disagree, the code is the fact and the plan carries the intent — preserve
intent, correct facts.
- Match the goal to work. One existing item, an update, a split, a new
item, or out of scope. In APS projects,
aps-planning is the engine for
truth validation and item drafting; follow plans/aps-rules.md — items
carry intent, outcome, and validation, never implementation steps.
- Design gate — only when genuinely contested. Invoke
brainstorming
or planning-council when the approach changes behaviour, architecture,
security posture, or ownership AND more than one credible approach exists.
A clear-cut change with an obvious shape does not need a design ceremony;
note the chosen shape in the work item and move on.
- Write the plan.
writing-plans for implementation plans;
aps-planning for module and work item text. Lean actions: observable
checkpoints with validation commands, not tutorials.
- Validate readiness. A work item is ready when its outcome is testable,
its validation command exists, and its dependencies are closed or
explicitly documented. Run the APS truth validation when APS is present.
Plan evolution
Plans are living artifacts. When invoked from fable5-aps-loop or any
unattended run, apply plan changes within the loop's plan-evolution authority
(statuses, drift corrections, new Proposed items, action plans) directly and
record them; reserve user checkpoints for changes to agreed scope, success
criteria, or accepted decisions. When working interactively, show proposed
plan text before writing it.
Handoff
Return the same block planning-workflow defines, so downstream skills
interoperate:
## Planning Workflow Handoff
- Goal:
- Work item:
- Status:
- Design source:
- Dependencies:
- Files:
- Validation:
- Risks:
- Decision: ready-for-dev | needs-design | needs-plan-update | blocked | out-of-scope
- Next skill: fable5-dev-workflow | brainstorming | aps-planning | writing-plans | planning-council
ready-for-dev hands to fable5-dev-workflow (or back to the loop). Ground
the Decision in evidence you can point to — a validation command that exists,
a dependency item's actual status — not on plan prose alone.
Cross-references
aps-planning — APS truth validation, reconciliation, item draftingwriting-plans — implementation plans with exact paths and commandsbrainstorming / planning-council — contested design decisionsfable5-aps-loop — the autonomous loop that calls this for replanning- Tuning rationale:
docs/fable5-agent-tuning.md
