A prompt pattern for working an epic to completion

I have been using Claude Code’s /goal command to set a standing objective for a session and let it run. Some of those runs were excellent: one worked through an entire epic on my static-analysis project, filed tickets for bugs it found along the way, fixed those too, and stopped only when the feature worked on every test repository. Others fizzled after a ticket or two. I searched my conversation history for every /goal invocation (19 of them, across five projects) to work out what separated the good runs from the bad. This post documents the answer, mostly so I can stop rediscovering it.

Six ingredients

The weak goals were one-liners: “implement 134”, “fix I4”. The agent did the ticket, then stopped or drifted. The strong ones, the multi-day autonomous runs, all combined six things.

A concrete entry point. An epic URL or explicit ticket IDs. Obvious, but it anchors everything else: the agent can always answer “what is the next unit of work?” by consulting the tracker rather than its own fading memory of the conversation.

An explicit autonomy grant. The words “autonomously”, “keep going” or “do not stop until” appear in every long run. Without them the agent reverts to its default politeness and checks in after each ticket, which in an unattended session means stalling.

A review cadence with a named model. “Use opus for reviews every two tickets.” This clause proved durable: reading the transcripts back, the session repeatedly says things like “two tickets complete — spawning the review checkpoint per the goal directive”, hours and many context compactions after the goal was set. A cadence tied to a countable event (tickets closed) survives; “review regularly” would not.

A self-feeding loop. The clause that turns an epic from a fixed list into a generator: “file tickets for bugs or features you identify, and then action them autonomously.” My best run generated more follow-on tickets than the epic started with, and fixed most of them. This is also the clause that most needs a leash, of which more below.

A verifiable termination condition. The best goal I wrote ended: “complete when the entire epic is implemented and the feature is shown to work on all of our test repos.” Done means a checkable state of the world (CI green, tickets closed, work pushed), not the agent’s opinion that it has finished.

A decisions log instead of interruptions. “Instead of asking me questions, make the call and keep a running list of decisions for me to review at the end, as comments on the epic.” This is what makes the autonomy grant safe. The agent still surfaces judgment calls; it just batches them for review rather than blocking on them.

One more clause earned its place for resumed work: audit first. “Audit origin/main, open PRs and local work before proceeding.” Without it, an agent resuming a half-done epic will happily re-implement tickets that merged last week.

The template, in two variants

The bounded variant is the default. The self-feeding loop is the ingredient that most often goes wrong (an exploratory epic can generate tickets faster than they close), so the leash is built in:

Goal: work through EPIC autonomously until it is fully done.

Audit first: before implementing anything, audit origin/main, open PRs and local worktree state so already-finished or in-flight work is folded in, not redone.

Loop: pick the next open ticket on the epic, implement it, verify (tests/build), commit, close the ticket, move on.

Self-feed (bounded): file tickets for bugs, improvements and follow-on features you discover and link them to the epic, but only action ones that block or directly improve the epic’s outcome. Park everything else in the backlog untriaged. At each review checkpoint, have the reviewer rank the parked tickets and drop any not worth keeping.

Review cadence: after every N completed tickets, run an adversarial MODEL review of the accumulated diff; file and fix anything it finds before continuing.

Done when: every ticket on the epic (original + actioned generated) is closed, verification is green, and everything is committed and pushed.

Decisions log: instead of asking questions, make the call and record decisions, tradeoffs and anything needing human judgment as comments on the epic for review at the end. If two reasonable implementations diverge, comment both options on the ticket, pick the simpler, and flag it.

The full variant swaps one clause. Use it when the discovered work is the point (a quality or exploration epic rather than a delivery one):

Self-feed (full): file tickets for bugs, improvements and follow-on features you discover, link them to the epic, and action them in the same loop: the goal covers generated work, not just the original tickets.

The choice is a judgment about risk. A delivery epic with a crisp outcome wants the bounded variant, because scope creep is the failure mode. An audit or hardening epic wants the full variant, because the tickets you generate are the deliverable. And the variants compose over time: if a full run starts generating faster than it closes, switch to bounded mid-run and park the tail.

I have packaged both variants as a small Claude Code skill (/epic-goal <ref> [bounded|full] [model] [cadence]), and the same template lives as a runbook prompt in the projektor workspace I use to track these epics — now shipped as a proper playbook, fetchable over MCP (get_playbook, compose_playbook) instead of copy-pasted from a wiki page.

For anyone who wants the raw prompt without either wrapper, I have also published it as a plain markdown file at tom-dickson.com/templates/epic-goal.md (something an LLM can fetch and inject directly, no skill required).

The pattern is not specific to my setup, though: any tracker the agent can query for “next open ticket” will do. The tracker matters more than the template: the reason the loop survives long sessions is that the source of truth for what remains is outside the conversation.