How I Built a /goal Command and How It Works for Me

Most of my AI coding sessions used to end the same way: a long chat, half-finished work, and me trying to remember what was done and what was not. So I built a command called /goal. You give it one big goal, and it keeps working until the goal is done and checked, or until it hits a real blocker.

Today is November 9, 2026. This matters right now because AI assistants can write a lot of code quickly, and the hard part has moved from writing code to trusting it. /goal is my answer to that problem.

What /goal actually is

It is not a program. It is a set of written instructions that the assistant follows when I type /goal followed by a goal. The instructions describe a process, the same way a checklist describes how to do a release.

The goal can be one sentence. My latest one was: "Implement the v1.1 plan for my browser extension in full, phase by phase, commit once per phase, and do not push or deploy without my go-ahead." That one sentence covered ten phases of work, about twenty-five commits.

The idea in one line

Different jobs get different models, and nobody marks their own homework.

• Planning goes to the strongest planning model. It reads the project, ranks what is pending, splits the goal into phases, and writes a tracker file.
• Building goes to a fast, cheaper coding model. Each phase gets a fresh agent that starts from the tracker, so no phase depends on a worn-out memory of an earlier one.
• Critical code goes to the most careful coding model. I mark a task critical when it touches things like deleting user data, overwriting files, or release scripts.
• Review goes to a separate read-only reviewer. It never wrote the code. It reads the diff and reports problems; it cannot edit anything.

How it runs, step by step

Step 1: The planning pass

Before any code, the planner checks the project: open notes, unfinished work, git state and the commands used to build and test. It then writes a tracker file with the goal, a checklist, and for every item a one-line check that can be proven, such as a command that must pass. Each item also gets a model tag. The tracker is the single source of truth. If the conversation gets too long and the assistant forgets, the tracker still knows.

It also records decisions. When my plan had open questions I had not answered, the tracker listed the default it chose for each one, so I can overrule them later.

Step 2: One fresh agent per phase

Each phase is built by a new agent. It writes the code, runs the build and tests, fixes failures, and makes one commit with a plain message. It ticks its items in the tracker. Then it stops, and the next phase starts with a clean slate.

Step 3: The review gate

When a phase is committed, a separate reviewer reads the diff against the tracker's checks. It looks at four things in order: does the code really meet the acceptance checks, is it safe, does it handle odd cases, and do the docs match what the code does. It returns a ranked list of problems, each with a file, a line and a one-sentence failure scenario.

Step 4: Fix and re-review

Confirmed problems go to a fresh agent as fix tasks. After the fix, the reviewer looks again. A phase with an open confirmed problem cannot be marked done, and the whole goal cannot be called complete.

Step 5: The honest report

At the end I get a report that says COMPLETE only if every criterion is met and every check is green. Otherwise it says PARTIAL and lists exactly what is missing. The report never rounds up.

What it caught on a real project

The project was a personal browser extension that records the audio of a browser tab. The new version stored recordings in the browser's private file system, let me save into folders by name, repaired video files, and added a library page.

The reviewers found real bugs that tests had not:

• The folder-save feature would have silently fallen back to the old Save As dialog every time. The background page where the save ran cannot read extension settings, so the code quietly chose the default. The tests passed because they used a fake settings store.
• A repair step could produce a shortened file that still passed its own checks and then replace the original.
• Recovered recordings got the wrong length in their file names, because a repaired file has a new modification date.
• A failed write could silently drop the rest of a recording.

None of these were exotic. Each one would have shown up weeks later as a recording that was missing, short or misnamed.

Rules I wrote into it

• Do not stop to ask questions. Decide, write the decision in the tracker, and continue.
• The exceptions are outward-facing or destructive actions: pushing, deploying, sending messages, deleting data, or anything that needs my password. Those become blocked items with the exact command I would run.
• Never disable a failing check to make it pass, and never delete a failing test.
• No unrelated clean-ups. Only code that serves the goal.
• Never push or release unless I pass a flag or say so.

Conclusion

/goal works for me because it turns a vague wish into a tracked list of provable steps, and because the person who builds a piece is never the person who approves it. It does not make the assistant smarter. It makes the result more trustworthy and my own attention less necessary.

Merits

• One sentence of input can drive a large, multi-phase piece of work.
• The tracker survives long sessions and context loss.
• Independent review finds bugs that the author's own tests miss.
• Each phase is one small commit, so history is easy to read and undo.
• The final report is honest about what was and was not verified.
• Risky actions such as pushing and deploying stay under my control.

Demerits

• It is slow. This project took many hours because every phase has a build, review and fix loop.
• It uses a lot of tokens, since several agents read the same code.
• Reviewers can find endless small edge cases, so you need a limit on review rounds.
• Tests that run in a fake environment cannot prove real-device behaviour. Some checks still need a person.
• A weak goal statement produces a weak plan. The command cannot fix a goal that is unclear.

Caution

This article is educational and describes my own setup. Names, paths and project details are generalised, and any placeholder values in your own commands must be replaced with your own. Model names and tool behaviour change often, so verify every claim and test the process on a small, low-risk project before relying on it for important work.

Frequently asked questions

• What is a /goal command? — It is a saved set of instructions that makes an AI coding assistant plan, build, review and verify one large goal, then report honestly.
• Is it a program or a plugin? — No. It is a written process in a command file that the assistant follows, so you can edit it like any text document.
• Why use a different model for each job? — Planning, routine coding and careful review need different strengths, and using the right one for each saves cost and improves quality.
• Why a fresh agent for every phase? — A new agent starts from the tracker instead of a long, partly forgotten conversation, which avoids drift and stale assumptions.
• Why must the reviewer be separate from the builder? — An author tends to trust their own work, so a reader who did not write the code finds problems the author overlooks.
• Does it deploy or push code by itself? — No. Pushing, releasing and deploying need my explicit approval, and the command lists them as blocked steps instead.
• What does it do when it cannot finish something? — It marks the item blocked, writes the exact error and what would unblock it, and moves on to independent work.
• Is it worth the extra time? — For large or risky changes, yes, because the review rounds catch bugs early. For a small fix, a normal chat is faster.

Tags

#ClaudeCode #AICoding #DeveloperWorkflow #CodeReview #Automation #SoftwareEngineering #AIAgents #Productivity #DevTools #BuildInPublic