Fablize

fablize — run Opus like Fable

Principle: a harness cannot raise a model's ceiling. It makes the model go all the way to its own ceiling — by enforcing verification, completion, and investigation as procedure. When the capability ceiling is the blocker (open-ended creative detail, self-driven discovery), escalate (§4).

Apply only what the task signals (smallest matching discipline; overlap only when genuinely multi-category). When installed always-on, this routing is automatic.

0. First run — set up automatically (once)

Before doing the requested task, check whether fablize has been onboarded on this machine:

cat ~/.fablize/progress.json 2>/dev/null

• If the file exists — skip onboarding, go straight to the task.
• If it is missing — onboard once with a single AskUserQuestion. Phrase the question and options in the user's current conversation language (detect it from recent messages — Korean, English, Japanese, etc.).
  • Question (meaning, translate to the user's language): "Set up fablize?"
  • Options (meaning, translate): "Local — this project only (recommended)" / "Global — all projects" / "Skip".
  • On Local/Global — run setup (it injects the block and writes progress.json; it never stars anything by itself), then continue with the task:

    bash ${CLAUDE_PLUGIN_ROOT}/setup/setup.sh <local|global>

    After setup, run bash ${CLAUDE_PLUGIN_ROOT}/setup/setup.sh ask — if it prints STAR_ASK <lang>, ask once via AskUserQuestion (in the user's language) whether they'd like to give the repo an optional GitHub ⭐, then run setup.sh star yes or setup.sh star no accordingly. If it prints nothing, skip silently.
  • On Skip — record it so it won't ask again, then continue:

    mkdir -p ~/.fablize && printf '{"setup_done":false,"skipped":true}' > ~/.fablize/progress.json

This means the user can just run /fablize (or trigger it) without running setup first — the first run onboards itself, once, with one question.

1. Multi-story loop (2+ sequential stories)

Decompose into sequential stories and complete one at a time, producing evidence as you go. Self-contained — no external goal system required. Run from the repo root; state persists in ./.fablize/ (resume with status even across sessions).

python3 ${CLAUDE_PLUGIN_ROOT}/scripts/goals.py create --brief "<summary>" \
  --goal "title::verifiable objective" --goal "title::..."   # the last goal must be a verification story
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/goals.py next         # activate a story + handoff
# ... work that story only ...
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/goals.py checkpoint --id G001 --status complete --evidence "<concrete evidence>"
# the final story is a verification gate: --verify-cmd "<command>" --verify-evidence "<result>" are required
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/goals.py status       # first command when resuming

Rules: complete requires non-empty evidence; the final goal cannot complete without a verify command and its result (the engine refuses). If blocked, record --status blocked and report. Single-step tasks skip this loop.

2. Deep investigation (debugging / unknown cause / review)

Read and follow ${CLAUDE_PLUGIN_ROOT}/packs/investigation-protocol.txt: reproduce first → form 3+ competing hypotheses → gather evidence per hypothesis → trace the full causal chain (removing the symptom is not removing the defect) → verify before and after → report the hypotheses you rejected. For reviews, report everything including low-confidence findings and filter in a separate step.

3. Verification grounding (render/executable artifacts — always)

For artifacts whose correctness only shows when run (HTML, SVG, games, UI, charts), follow ${CLAUDE_PLUGIN_ROOT}/packs/verification-grounding-pack.txt: run it in the real renderer → observe the actual output → fix what the observation reveals → re-run. A static parse confirms well-formed, not correct.