Claude Code shipped a command called /goal. You give it a condition that defines success, and it runs until it hits that condition. Not twenty minutes. Hours. Here are the seven prompts I paste to run it overnight, plus the one rule that keeps a long run honest.
For a long time the limit on agentic AI was not how smart the model was. It was how long it could stay on task before you had to step back in and steer it. Twenty minutes of real work, then it drifted, and you were back at the keyboard re-prompting.
/goal moves that limit. You describe the finished state, hand it a set of rules, and walk away. People on Codex are running these loops for three days straight. The whole method fits in one line: a clear success condition, a method, hard rules about what not to touch, and a log you can read in the morning.
The seven prompts below are that shape, filled in for the seven jobs I actually hand off overnight. Copy them, fill the brackets, run them.
What /goal Actually Does
/goal turns Claude Code into a long-running agent. You type /goal, describe the condition that means the work is done, and it works autonomously toward that condition instead of stopping after a single reply. The condition is your finish line: the feature ships and the tests pass, the bug is fixed and covered, the migration is complete. Claude keeps going, tries again when it hits a wall, and stops when the condition is met or it runs out of honest moves.
Codex had this first. Claude Code copied it, and I am glad it did, because now you can pick either tool and run the same overnight pattern.
The One Rule That Makes /goal Work
Before you ever type /goal, run plan mode first and agree on the plan with Claude.
This is the rule people skip, and it is the rule that decides whether you wake up to finished work or a mess. A long run on a vague goal produces a lot of confident, wrong output. The model does not slow down when it is unsure. It commits. Five hours of committing in the wrong direction is worse than no run at all.
A long run on a sharp, pre-agreed plan produces a finished project. So the sequence is always the same. Open plan mode. Let Claude propose how it will do the work. Read the plan, push back where it is wrong, approve it. Then turn it loose with /goal.
Plan first. Then walk away.
How to Read the Seven Prompts
Each prompt below is copy-paste ready. Fill the [BRACKETS] and go. Three things are true of all of them.
Every prompt states a clear success condition and a clear place to stop. That is what keeps an overnight run honest instead of open-ended.
Every prompt starts in plan mode. You paste it, review the plan Claude proposes, approve, then let it run.
Every prompt tells Claude to keep a log. A three-hour run you cannot audit is worthless. The log is how you check the work over coffee instead of re-reading the whole diff.
Pick the prompt that matches tonight's job.
| Prompt | Use it when |
|---|---|
| 1. Ship a feature | You have a defined feature and want it built, tested, and committed by morning. |
| 2. Hunt and fix bugs | The app works but is flaky, and you want it stabilized. |
| 3. Test coverage sweep | You need real tests across the codebase, not three token examples. |
| 4. Refactor a mess | One module is a swamp and you want it cleaned without breaking behavior. |
| 5. Research and recommend | You need a decision backed by real comparison, not a vibe. |
| 6. Document the project | You inherited or shipped something undocumented. |
| 7. Migrate or upgrade | A dependency, framework, or version needs to move. |
Prompt 1: Ship a Feature Overnight
You have a defined feature and you want it done by morning. This is the one I reach for most.
Copy the ship-a-feature prompt:
Copy this.
/goal Build [FEATURE] for this project. Success condition: the feature works end to end, all existing tests still pass, and you have added tests that prove the new behaviour. The app builds clean. Before you start: produce a plan and wait for my approval. Then work the plan. Rules: commit after each working step with a clear message. If you hit a blocker, try a different approach before giving up. If you are stuck after three real attempts, stop and write what blocked you. Do not touch [AREAS TO LEAVE ALONE]. Keep a running log in GOAL_LOG.md of every decision and why.
The mistake that kills this one is leaving [AREAS TO LEAVE ALONE] empty. Name the files, the payment path, the schema, whatever you do not want touched while you sleep. An agent with no fences will refactor things you never asked it to.
Prompt 2: Hunt and Fix Bugs
The app runs, but you do not trust it. You want the known issues gone and a test on each one so they do not come back.
Copy the bug-hunt prompt:
Copy this.
/goal Find and fix the bugs in [APP / MODULE]. Success condition: you can reproduce, fix, and verify at least the known issues in [LIST], plus any others you find, with a test for each fix so it cannot regress. Method: for each bug, write a failing test that reproduces it first, then fix it, then confirm the test passes. Never mark a bug fixed without a test that would catch it again. Stop and report if a fix would require changing [PROTECTED AREA]. Log every bug, its root cause, and the fix in BUGFIX_LOG.md.
The failing-test-first rule is doing real work here. It stops Claude from declaring a bug fixed because the symptom went away. No test, no fix.
Prompt 3: Test Coverage Sweep
You need real tests, not three token examples that assert a mock got called.
Copy the coverage prompt:
Copy this.
/goal Raise test coverage on [MODULE / PROJECT] to a genuinely useful level. Success condition: the critical paths in [LIST THE IMPORTANT FLOWS] each have tests covering the happy path and the main failure cases. All tests pass. Priorities: cover the code that handles money, auth, data writes, and external calls first. Skip trivial getters. Do not write tests that only assert mocks were called. Each test must prove real behaviour. Report coverage before and after in TEST_LOG.md.
Point it at money, auth, and data writes first. That is where a bug costs you a customer. A coverage number that comes from testing getters looks good and protects nothing.
Prompt 4: Refactor a Mess
One module has turned into a swamp and you want it readable, with zero change in behavior.
Copy the refactor prompt:
Copy this.
/goal Refactor [FILE / MODULE] so it is readable and maintainable, with zero change in behaviour.
Success condition: every existing test still passes, the public interface is unchanged, and the code is meaningfully simpler. If tests are thin, add characterisation tests that capture current behaviour BEFORE you refactor.
Hard rule: behaviour must not change. If you find a real bug while refactoring, do not fix it silently. Note it in REFACTOR_LOG.md and leave it. Commit in small steps so each one is reversible.
The rule about not fixing bugs mid-refactor sounds strange until it saves you. A refactor that also quietly changes behavior is impossible to review. Keep the two jobs separate. Note the bug, leave it, come back with Prompt 2.
Prompt 5: Research and Recommend
You need a backed decision before a meeting, not ten open tabs and a gut feeling.
Copy the research prompt:
Copy this.
/goal Research [DECISION, e.g. which queue library to use] and give me a recommendation I can act on. Success condition: a written brief that compares the real options on the criteria that matter to us ([COST, SPEED, MAINTENANCE, LOCK-IN, etc.]), with a clear recommendation and the reasoning, plus a small working proof-of-concept of the top pick if it is code. Rules: only claim things you can verify from docs or a test you ran. Mark anything uncertain as uncertain. No filler. Write it to DECISION_BRIEF.md.
Run this the night before a decision meeting. You wake up to a brief and a small working proof of concept instead of a browser full of tabs you never read. The line that earns its keep is "mark anything uncertain as uncertain." It stops the model from dressing a guess up as a fact you might act on.
Prompt 6: Document the Project
You inherited something undocumented, or you shipped it and never wrote it down.
Copy the documentation prompt:
Copy this.
/goal Document [PROJECT] so a new developer could get productive in a day.
Success condition: a README that covers what it does, how to run it locally, the architecture in plain language, and the parts that are surprising or fragile. Plus short comments on the genuinely confusing functions only.
Rules: read the code to find the truth. Do not document what you wish the code did. Flag anything that looks like a bug or a landmine in a GOTCHAS section. No comment spam on obvious code.
The GOTCHAS section is the point. Anyone can write a README that describes the happy path. What a new hire actually needs is the list of landmines, and an agent reading the whole codebase overnight finds them.
Prompt 7: Migrate or Upgrade
A dependency, a framework, or a major version has to move, and you want it done without losing behavior.
Copy the migration prompt:
Copy this.
/goal Migrate [PROJECT] from [OLD] to [NEW] (e.g. a framework or major dependency version). Success condition: the project builds and all tests pass on [NEW], with no deprecated calls left and no behaviour lost. Method: work in small, committable steps. After each step, run the full test suite. If a change breaks something you cannot fix cleanly, stop and write the blocker in MIGRATION_LOG.md rather than forcing a hack. Keep the old behaviour identical unless I told you otherwise.
The instruction to stop and log a blocker instead of forcing a hack is what makes a migration safe to leave running. A forced hack passes the build and rots for six months. A logged blocker is a five-minute decision for you in the morning.
Honest: Where a Long Run Bites You
A long run is not free, and it is not automatically good.
It is not free in tokens. On a metered plan, a three-hour autonomous session spends real money, and a bad plan can spend a lot of it going nowhere. Watch the first few runs before you trust it unattended. If you are already fighting token burn, I wrote up three fixes in the token-burn guide, and the same discipline applies double once a run is measured in hours.
It is not automatically good either. Runtime is not quality. A /goal run that goes for five hours can still hand you five hours of the wrong thing if the plan was loose. That is why plan mode is not optional and why every prompt above forces a success condition and a stop condition. The condition is the leash.
And there are nights not to use it. Anything touching production, billing, or a schema you cannot roll back is not a walk-away job. Run those with your hands on the keys. /goal is for defined work with a clear finish line and a safe blast radius, not for the risky call you would not delegate to a junior on their first week.
The Pattern Across All Seven
Read the seven prompts back to back and you will see the same skeleton every time. A clear success condition. A method. Hard rules about what not to touch. A log.
That is the whole skill. Once you see it, you can write your own /goal prompt for anything: a data cleanup, a content pass, a report. Steal the shape and fill in your finish line. If you find yourself reusing the same one, that is your cue to save it as a skill so it is one command instead of a paste.
The One Thing to Do This Week
Run Prompt 5 tonight, the night before your next real decision. Point it at a choice you have been putting off, give it the criteria that matter to you, and let it run in plan mode first. One prompt, one job.
If it comes back weak, you spent ten minutes and learned where your plan was fuzzy. If it comes back strong, you walked into a meeting with a brief and a working proof of concept you did not have to build. Either way you learn the tool on a job small enough to check. Start there, then hand it the bigger runs.