Goal, loop, brainstorm: three ways to run the agent's loop

Three things get grouped under “Claude Code skills” in the workflow conversations I have: /goal, /loop, and brainstorming. Two of them are skills and one is not, and the label hides the distinction that matters: each runs at a different phase of a task. One runs before I build, one runs until a condition holds, one runs on a cadence.

First, what they are on paper. /loop is one of the bundled skills that ship with Claude Code, listed next to /debug and /code-review. /goal is a built-in command; the docs describe it as a wrapper around a session-scoped Stop hook. Brainstorming is a third-party plugin skill from Jesse Vincent’s superpowers framework, installed separately. So the honest grouping is one command, one bundled skill, one plugin skill. The grouping I find useful ignores all of that and asks when each one fires.

Brainstorming before implementation

The brainstorming skill opens with an instruction to itself: “You MUST use this before any creative work.” It “explores user intent, requirements and design before implementation,” asking questions one at a time rather than in a batch, and it holds a hard gate: no code, no scaffolding, until it has presented a design and I have approved it. It proposes two or three approaches with trade-offs, presents the design in sections, and writes a spec file before any implementation skill runs. This is the loop that runs when there is nothing to iterate on yet, and its output is the spec the later phases build against.

/goal and its completion condition

/goal (Claude Code v2.1.139 and later) sets a completion condition and keeps working across turns until the condition is met. After each turn a small fast model, Haiku by default, checks whether the condition holds; a “no” sends the model back with the reason as guidance for the next turn. The evaluator judges only what the main model has already surfaced in the conversation, so the condition has to be something the transcript can demonstrate, such as a test result or a clean git status. I dissected this loop against a days-long model run in a separate note on /goal; the short version is that an external check is more reliable than the model’s own sense of done, a pattern I keep returning to in agentic coding best practices.

/loop and its schedule

/loop re-runs a prompt on a schedule while the session stays open. Give it an interval and a prompt (/loop 5m check the deploy) and it runs on a fixed cadence. Give it a prompt with no interval and Claude picks the delay each iteration, between one minute and one hour, waiting less while a build is finishing and more when nothing is pending. Give it nothing and it runs a built-in maintenance prompt: continue unfinished work, tend to the branch’s pull request, run cleanup passes. Recurring loops expire seven days after creation, which bounds how long a forgotten one can run. The keep-or-discard shape here is the same one I used for parameter optimization, and the SKILL.md format /loop rides on is the portable one I traced across agents.

Which one to reach for

The /goal docs put the three side by side by the question that matters, which is what starts the next turn. /goal’s next turn starts when the previous one finishes and stops when a model confirms the condition. /loop’s starts when an interval elapses and stops when I stop it or Claude judges the work done. Brainstorming, however, sits before both, where the next turn is another question and it stops when I approve the design. So the rule I use: (1) brainstorm before there is code, (2) /goal when done has a testable definition, (3) /loop when the work arrives on a clock. The packaging determines the install step, and the phase determines which one I reach for. Next I will run one task through all three in sequence: brainstorm to a written spec, run /goal until the tests pass, run /loop to keep them passing, and note where the handoffs lose information.