Sharing a few things that worked in my agent setup this week. The throughline this time came from one practical question: how do I work elegantly with Fable and long-running loops without torching my weekly usage? The answer kept coming back to boundaries. Where the plan stays decided, where “done” actually counts, and where the lessons go after the work ships.
1. Writing great /goal prompts with Supergoal
I have enough reps now to feel good about writing solid implementation plans. The muscle I am still building is writing a great /goal prompt: the thing that hands a plan to an agent and drives it to completion without me babysitting every phase.
So after a plan is written, I started having Fable run Supergoal (Robert Courson’s skill). It takes my plan doc as authoritative and builds the execution packet around it: repo recon, memory preload, risk scan, phase specs, state files, verification commands, recovery rules, a self-critique pass, and a preflight check. What comes out is a tight /goal prompt with the scaffolding already in place.
The boundary that matters is what Supergoal is told not to do. If I pass in an approved plan, it treats that plan as authoritative. It decomposes the milestones, preserves sequencing and acceptance criteria, and adds per-phase verification, but it does not reopen the architecture. Agents love to re-plan, because the context window makes every decision feel negotiable. Most of the time, if I already did the decision work, I want execution, not a second planning meeting disguised as phase one.
The usage angle is the reason this earns its place. The expensive model writes the loop once. After that, I can hand the /goal prompt to 5.5, Opus, or Sonnet to actually run it, and the bounded loop executes without me re-explaining the plan every few turns.
Example use: “Here is the approved plan doc. Run Supergoal against it. Treat the plan as authoritative, do not reopen the architecture, decompose the milestones with sequencing and acceptance criteria intact, add per-phase verification, then emit the /goal command.”
What it’s helped with: My split of responsibility got cleaner. I own the decisions. The agent owns the execution detail. The /goal prompt is the contract between the two, and Supergoal writes a far better contract than I do by hand.
2. PR reviews with no-mistakes
I can have a coding agent run a PR review skill, and it catches a lot. But even Fable misses things. A skipped check, stale docs, a PR description that no longer matches the current state of the branch. An agent finishing a branch and me trusting that branch are two different events, and I kept being the gap between them.
This week I set up no-mistakes (Kun Chen) as the gate. It is a local git proxy: instead of pushing straight to origin, the work runs through a fixed sequence in a disposable worktree. Intent, rebase, review, tests, docs, lint, push, PR, CI. Safe, mechanical fixes can land inside the gate. Intent-sensitive findings come back to me. The PR only opens or updates after the branch passes the local gate.
I wired it across Claude Code, Codex, and Hermes. The interesting part was Hermes, which is not one of no-mistakes’ native targets. Hermes has a native ACP server, so I can register it as a custom gate agent through “hermes acp —accept-hooks”. For now my default stays conservative: Claude and Codex do most of the feature work, and Hermes keeps the gate available as a latent capability rather than a standing habit.
One honest caveat: the setup checks pass, including “hermes acp —check” and “no-mistakes doctor”, but I have not yet pushed a real feature branch through the full Hermes-driven gate end to end. That first real run is the actual test, and I am not going to claim it works until it has.
Example use: “I have changes on this branch. Run them through no-mistakes before anything reaches origin. Apply the safe fixes yourself, pause on anything intent-sensitive, and only open the PR once the branch clears the local gate.”
What it’s helped with: A passed gate now has a concrete meaning. Fresh upstream first, local checks before push, human approval for the judgment calls, and a PR that only exists after the branch earned it. That is the part of the workflow I most wanted between an agent and a real pull request, and it is no longer living in my head.
3. Closing out work with /agent-retro and /doc-audit
Most of my work happens across many sessions with agents. A feature takes a long set of conversations to land. By the time it ships, two things have rotted. The lessons are buried in the transcripts, and if I am in a repo, the docs can describe a state that no longer exists. The next agent inherits both gaps, and it inherits them worst in the instruction files that load into every session.
So I started ending most large pieces of work with two skills in sequence. First /agent-retro (Gianni Massi) mines the sessions for what did and did not work, and a follow-up pass proposes skill updates, preferring edits to skills I already have over inventing new ones. Then /doc-audit fans out read-only subagents to flag stale claims across the docs, verifies every claim before touching a file, and defers any number that needs a real run rather than guessing it. I approve the changes, and they land.
The pass that sold me on this ran on my prayer app’s repo, one I thought was well kept. It found 20 stale files. Old build numbers, references to deleted modules, finished plans still marked active. None of it was load-bearing on its own, and all of it was the kind of quiet drift that sends the next agent down a wrong path. That audit is the reason the method is now a skill instead of a thing I sometimes remember to do.
Example use: “We just shipped this. Run /agent-retro across the sessions, then /doc-audit on the repo. Propose skill updates from the retro and stale-doc fixes from the audit, verify each claim before editing, and show me the diff before anything lands.”
What it’s helped with: The end of a feature now produces two artifacts I used to lose: the lessons, captured as concrete skill updates, and the docs, corrected to match reality. The next agent starts smarter than the last one instead of inheriting yesterday’s stale context.
If there is a theme this week, it is that more autonomy mostly creates more boundary work. Agents can run longer and touch more of my system now, and the highest-leverage thing I had the expensive model do was draw the boundaries, not the work inside them. The plan that stays decided, the gate that decides when done counts, and the close-out that records what the work taught. The execution ran on cheaper loops, and my usage lasted the week.