Claude Code's /goal Keeps the Agent Working Until It's Actually Done
Using Claude Code's /goal command to set a measurable target the agent can't stop short of — and how I used it to cut my Astro build time in half.
Today I learned about Claude Code’s /goal command. Instead of giving the agent a task and hoping it finishes, you give it a condition — and it can’t stop until that condition holds.
How it works
/goal <condition> installs a session-scoped Stop hook. The condition itself becomes the directive, so the agent starts working immediately without asking what to do. Every time it tries to end the turn, the hook checks the condition: if it isn’t met, stopping is blocked and the agent keeps going. Once the condition holds, the hook auto-clears.
The key part is making the condition measurable. “Make the build faster” is vague. “Improve the build time by 50%” forces the agent to take a baseline, do the work, and prove the number — it can’t declare victory on vibes.
/goal improve the time it takes to build this project by 50 percentWhere I used it
I pointed it at the build time of this very blog. The agent profiled astro build, found that OG image generation was the bottleneck (~122 satori + resvg PNG routes), and made two changes:
- Memoized the font fetch. The fonts were being re-fetched from Google subset to each image’s text, so nothing was cacheable — hundreds of network round-trips per build. Fetching the full font once and caching it killed all of them.
- Cached the rasterized PNGs.
resvgrasterization costs ~140ms per image; the satori layout step is ~4ms. So it now caches each PNG on disk keyed by a hash of the SVG. Unchanged images skipresvgentirely.
Baseline was 104s. Warm builds now run in 44s — a 58% cut. The Stop hook didn’t let it settle for the easy 15% win from the font fix alone; it kept digging until it cleared the 50% bar.
Two takeaways:
/goalturns a fuzzy ask into a contract the agent has to satisfy.- A measurable target (a number, a passing test) is what makes that contract enforceable.