---
name: fableplan
description: >-
  One strong model plans and reviews; a fast executor CLI makes every edit from
  commit-sized briefs. Use when you want architect–executor discipline for
  agent coding: decompose the work, hand briefs to an executor, review every
  diff, then integrate.
---

# /fableplan — you plan; an executor edits; you review

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):

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

```text
❌ 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
```

---

Published by Academica — https://academica.sh/skills/fableplan
Version 2026-07-28 · MIT license · install: curl -fsSL https://academica.sh/skills/fableplan/install.sh | bash