The most annoying part of using a coding agent is often not whether it can write code. It is that a human has to keep standing nearby and feed it the next step.

Supergoal tries to compress that into a small number of fixed gates. First, run /supergoal <what you want>. It recons the codebase, loads saved preferences from memory, decomposes the work, and writes specs for each phase. After the plan is confirmed, it prints one ready-to-paste /goal. The human pastes it once; the agent runs the rest sequentially.

The important part is not “it writes a plan.” Plain planning prompts already do that. Supergoal moves the plan out of the chat box and into the filesystem: ROADMAP.md, STATE.md, and phase-N.md all live under .supergoal/, so the execution phase can read stable specs instead of relying on a fragile conversation context.

Mogu butts in:

SP-208 covered /goal itself: how to define “done” as something verifiable. Supergoal wraps one layer above that. It handles the handoff before /goal: if a task is too large for the human to manually slice into phases, acceptance criteria, and baseline checks, can that preparation also be delegated to an agent?

So this is not another version of “good goals need evidence.” It adds a new position in the workflow: before a long autonomous task starts, you need a handoff protocol that turns vague intent into executable specs.

One paste, not a chain of batons

Supergoal’s README contrasts it with a familiar loop: ask for a plan, execute step one, re-prompt, execute step two, re-prompt again. Every step requires the human to come back and catch the ball.

Supergoal instead uses the shape of /goal. In both Claude Code and Codex, /goal is not a container for a giant prompt. It is a short end-state condition. After each turn, the host evaluator checks the transcript against that condition; if it is not satisfied, execution continues.

That is why Supergoal does not stuff the whole long plan into /goal. It hands /goal the endpoint — all phases complete, final audit passed, SUPERGOAL_RUN_COMPLETE printed — while the actual phase details stay in files.

This design avoids two common traps. First, long prompts hit size limits or get diluted by later context. Second, slash commands do not recursively trigger themselves, because slash commands require user input. Supergoal accepts that boundary honestly: the last planning step gives the human one /goal line to paste.

Once pasted, the execution loop begins. Each phase reads its spec, does the work, runs SUPERGOAL_PHASE_VERIFY, and writes phase memory. Failure is not an immediate handoff. The first failure injects a probe and retries. The second writes a focused fix spec and executes it inline. The third stops with a blocker handoff.

Specs on disk feel more like real tickets

The .supergoal/ directory is the more interesting part of the workflow.

ROADMAP.md holds the overall plan. STATE.md tracks progress. THINKING.md captures risks, dependencies, and applied memories. tools.md records which MCPs, search tools, skills, or host capabilities were detected in this session. Each implementation slice gets its own phase-N.md.

That turns “explain it clearly to the agent” into something closer to a ticket system. The human does not need to keep re-summarizing the project, and the agent does not need to pretend it will remember everything forever. State is written to files, so the next loop has something concrete to inspect.

Supergoal also runs a pre-flight smoke check before dispatch. It deduplicates mandatory commands and runs them once. If the baseline is already red, it surfaces that before launch instead of throwing the agent into a guaranteed three-strike failure loop.

The final audit does not only trust that the last phase said it passed. It rereads the original ROADMAP, reruns mandatory build, typecheck, lint, or test commands, and compares every declared deliverable against the Baseline ref across the whole working tree: committed, staged, unstaged, deleted, and untracked. That is meant to catch the classic “the agent said it was done, but the file never appeared” failure.

Mogu murmur:

The Baseline ref detail is charming because it hits a very plain but very real agent problem: sometimes AI does not do the wrong thing; it only thinks it did the thing. Humans do this too, but humans usually get humbled by git status. Supergoal turns that humbling step into process design. (⁠◕⁠‿⁠◕⁠)

Claude Code gets a plugin; Codex gets a skill

The install paths also reveal where the agent ecosystem is right now.

In Claude Code, Supergoal uses the plugin marketplace: add the GitHub repo, install supergoal@supergoal, reload plugins, and /supergoal appears. The README also warns that the owner/repo shorthand depends on GitHub SSH keys, so the HTTPS URL is the safer install path.

In Codex CLI, there is no plugin marketplace, so installation means copying skills/supergoal into ~/.codex/skills. The same workflow has different packaging depending on the host: closer to a plugin in Claude Code, closer to a skill in Codex.

That is not a minor implementation detail. It shows that agent workflows are becoming portable operational knowledge, while the platform layer has not fully converged. Some hosts use marketplaces, some use local skill directories, some capabilities are built-in slash commands, and some are assembled from prompts and scripts inside a repo.

Supergoal sits right in that middle layer. It is not a model, not an IDE, and not merely a prompt library. It is an operating protocol that both Claude Code and Codex can follow.

The real product problem is trust in handoff

Supergoal’s tagline is: “Plan deeply, then autonomously build until it’s done.” The underlying product problem is more human: how do you make someone comfortable leaving the keyboard?

That requires more than an agent that can edit code. It needs task boundaries, acceptance criteria, failure recovery, stop conditions, and final proof. Those things usually live in the human’s head or get scattered across a long chat.

Supergoal turns them into a handoff flow: load memory first, detect tools first, list risks first, write phases first, run pre-flight first, recover failures through three levels, and finish with an audit.

It is less flashy than a new model release, but it is close to where autonomous coding actually gets stuck. The question is not only “can AI generate the next patch?” It is “can I hand off the whole job and come back to evidence instead of a confident report?”

If coding agents are going to become engineering process instead of toys, the next layer of competition may not be who completes code most accurately. It may be who designs the best handoff: intent into specs, specs into phases, phases into evidence, and evidence into permission to stop.