fableplan

curl -fsSL https://academica.sh/skills/fableplan/install.sh | bash

You (the planning model) own design, decomposition, review, and integration. A fast executor CLI owns the mechanical edits. You never skip the review step.

When to use

• Multi-file product changes where design must stay consistent
• “Plan this, then execute” work you want reviewed like a PR between steps
• Any change where inventing decisions mid-edit would drift the outcome

Do not use this for a one-line fix you can do yourself, or for work that must stay entirely inside one chat without an external executor.

Phase 1 — Plan (you, alone)

1. Read every file the change touches. Prefer absolute paths. 2. Decide the design fully before any brief runs: names, API shapes, payload keys, file ownership, what is out of scope. The executor inherits zero decisions. 3. Decompose into briefs — one brief is one self-contained, commit-sized edit with no judgment left in it: - Exact file paths to create or edit - Anchor snippets of surrounding code so the edit lands in the right place - What “done” looks like for that brief (compile, typecheck, or a specific behaviour) - Hard boundaries: files and behaviours the executor must not touch 4. Present a short numbered plan to the human if the work is multi-phase or crosses a product boundary. Wait for go-ahead when the change is irreversible or publicly visible.

No product edits in Phase 1.

Phase 2 — Execute (supervised)

For each brief, invoke your executor CLI with the full brief text. Example shape (adapt to your harness):

your-executor -p "<BRIEF>"
# Cursor example: agent -p --force --model <fast-model> "<BRIEF>"

Brief rules:

• Absolute paths only
• Paste enough anchor code that the edit cannot land in the wrong function
• One concern per brief — do not combine “rename + redesign + ship”
• State the verification the executor should run before returning

If a brief fails or the diff is wrong: fix the brief, re-run. Do not pile a second ambiguous brief on top of a broken first one.

Phase 3 — Review every diff

Treat each executor return like a PR:

Check	Fail if
Scope	Touched files outside the brief
Design fidelity	Invented names, shapes, or behaviour you did not specify
Safety	Secrets, destructive ops, or half-wired callers
Build	Typecheck / compile of the affected layer is red

Reject and re-brief on failure. Approve only when green.

Phase 4 — Integrate

1. Commit with a message that states the why of the brief set. 2. Run the project’s ship path for the surfaces you touched (app deploy, backend binary, or docs-only — whatever your repo’s ship functions are). 3. Verify on the real host or local stack the plan named. 4. Report outcomes in past tense: what shipped, what was verified.

Judgment boundary

Executor gets	You keep
Surgical edits from a closed brief	Design, naming, scope
Local typecheck / build of its edit	Product decisions, ship approval
File creates named in the brief	Review of every diff

Anti-patterns

❌ BAD — Vague brief (“clean up auth”) and hope the executor invents the design
❌ BAD — Skip review because the executor “usually gets it”
❌ BAD — One mega-brief that renames, redesigns, and deploys
❌ BAD — Let the executor choose public API names

✅ GOOD — Closed brief with paths, anchors, and a done check
✅ GOOD — Review every diff before the next brief
✅ GOOD — Human gate on irreversible or public changes