Fable 5 to Opus 4.8 · Clief Notes

Fable 5 to Opus 4.8

I gave Opus 4.8 all the markdown files that Fable and I had created up to that point, in hopes that Opus could help me plan the model switch. And the reason Fable was so good, other than that he is the best coder on the planet, is Jake's ICM system, which I learned and built in this Skool class. The Foundation Fable built upon.

My final prompt to Opus (we had a good conversation before this, and I saved my Fable context window with /export, so if need be and Fable returns, we can restart where we left off):

--------------

Fable 5 was writing to my Obsidian Vault, and he has a Website folder with

Audit (the rebrand and rebuild was coming from a Replit project I built. So I gave Fable all my code from GitHub, and the Audit file is pertaining to the migration-audit)
Brand
PRD files
Context.md
ia-nav-structure
launch-action-plan
Would you like to read these files before helping me with a handoff.md file?
(he said yes)

Opus:

I've read all ten. This is unusually disciplined work — the layered ICM system, the keep/rework/kill audit, locked IA, five approved PRDs, and a staged runbook. A few things stand out that actually change how the handoff should be built:

The vault is the plan; the build repo is the truth. Your real build lives in port-a-insider with its own CLAUDE.md tracking milestones M0–M7. The vault tells Opus what to build; the repo + its git history tell it what's already built. So the handoff's job isn't to re-summarize the plan you've already documented beautifully — it's to bridge Opus into that repo and tell it how to figure out where Fable stopped.

Your brand-voice risk is lower than I'd feared. The insider-messaging doc is genuinely thorough — hero three-beat, the generous-club principle, the extended never-list, the Dispatch format, Porter's posture. That's the kind of concrete voice spec that survives a model switch well. The continuity risk here is build-state, not voice.

One thing I caught: CONTEXT.md's phase table still says "Build 🚧 In progress — M0 done (2026-06-12)." That's almost certainly stale now — if Fable got you to half-complete since the 12th, the build repo's CLAUDE.md and git log are ahead of it. The handoff needs to tell Opus explicitly to trust the build repo, not CONTEXT.md's status line, for current state.

And the reason this handoff is low-risk: because you've been this disciplined, Opus doesn't need Fable's memory to know where things stand. It can derive it — git log, the M0–M7 checkboxes in the build CLAUDE.md, and the acceptance checklists at the bottom of each PRD. That's a far more reliable ground truth than any summary Fable could've left.

So the file I've drafted is a thin orientation layer, not a state dump: reading order, a self-assessment routine, a no-regress guardrail list pulled from across your docs, the model-settings trap, and one slot only you can fill — anything Fable was mid-diagnosis on. Let me write it.Drop this into website/HANDOFF.md in your vault so it sits alongside CONTEXT.md and the audit.

Two things to do before you hand it to Opus:

Fill the in-flight section at the bottom — that's the one part neither the repo nor I can know. If Fable left something mid-diagnosis, pull it from memory or the exported transcript; if M-whatever finished clean, just say so. Either way, telling Opus "nothing in flight" is itself useful.

And consider whether the build repo's own CLAUDE.md needs a freshness pass. The handoff leans hard on it being the source of truth for milestone state, so if Fable was diligent about updating it, you're set; if it drifted, a quick correction there is worth more than anything in the handoff, since it loads every session.

When you bring Opus in: export the raw Fable session first, then point Opus at this file and let it run the self-assessment before it writes a line. If its read of where the build stopped matches yours, you're aligned and it can proceed. If it doesn't, you've caught the drift at the cheapest possible moment.

5 comments