5.1.2 - Where Do You Stop, For Now?

Decide what this project asks of you in a normal week, and write down what would make you open it again.

Stopping point

It is running, nothing is wrong, so why are you still in there?

The call

Stop by writing down what is left rather than by deciding you are finished. Everything still open is either out of scope on purpose or a deferred decision with the condition that unpauses it.

Sharpen stopping point with AI

This is a Run idea, so the AI move is Run it for real. You can sharpen the decision here, but it only proves out against a system that is actually live.

New here? Let your AI do this with you. Paste your problem into Guide me and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt.

Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see how to use vibe2value.

Or copy this prompt into AI chat, replace the bracketed lines with your real project and keep the instruction exactly as visible here. It helps you put your deferred-decisions.md together by refining your three lines until somebody who did not build this could act on them.

You are checking whether you have decided to stop, or only run out of energy.

Constraint:
Everything you are still carrying must be written down as either out of scope on purpose or a deferred decision with a named condition that unpauses it. Nothing important is left in your head.

Example of the standard:
Vague: "It is basically done, I just want to tidy a few things up."
Sharp: "It runs on about twenty minutes a week: read the failures nobody reported and clear the review queue. Two things are paused. A second skill is deferred until somebody asks for it. Writing the post, scheduling and analytics are out of scope on purpose. I open it again if two digests in a row fail, or if someone asks for a second skill."
The sharp version names the running cost, the paused things and the trigger for each. The vague one names none of them, which is why it never ends.

Working draft:
What it asks of you in a normal week: [the real ongoing cost]
Paused, plus what unpauses each one: [the deferred decisions]
Out of scope on purpose: [and why]

Task:
Decide whether this is a stopping point or a pause in the tinkering. Anything you are still carrying that does not appear in one of those three lines is the thing to write down before you stop.

Check:
- Is there anything you mean to get back to that is not written down?
- For each paused thing, could someone else tell when it should restart?
- Is what you are still doing making the thing better, or making you feel better?

Return:
- Verdict: stopped, or still going
- The corrected three lines
- Anything you are carrying in your head that is not on the page yet

Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it.

Putting it down and keeping it running are the same skill from two ends. That is Yours to keep running plus Better from real signal.

The same idea on a recipe card

A kitchen closes. It does not finish. The plates are done, the pass is wiped and tomorrow's order goes up on the board.

What is not done tonight is written on the board rather than remembered, which is exactly why the chef can go home. A kitchen where the outstanding jobs live in somebody's head never really closes. It just gets quiet for a while.

The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See the recipe card.

What it really means

Every other part of this framework has a gate. Shape ends when the decision is sharp. Build ends when there is a working thing. Launch ends when real people are looking at it.

Running has no natural end at all. Nothing arrives to tell you it is over, so the work continues at whatever rate your attention allows. It is the stage that quietly takes the most hours because it is the only one with no edge on it.

The gate is not whether you are finished, because you will not be. It is whether everything still open has been written down. Something written as a deferred decision with a trigger can be put down and picked up deliberately. Something carried in your head cannot be put down at all, which is why you keep opening the project to check on it.

Make stopping point concrete

Compare the version that sounds responsible with the version somebody could act on.

Too vague: It is basically done, I just want to tidy a few things up.
Concrete enough to act on: Each week it asks me to read the failures nobody reported. A second skill is paused until somebody asks for it. Writing the post, scheduling and analytics are out of scope on purpose.

The second version has an end in it. The first has no way of ever being finished, which is why it never is.

Both versions come from consideredContent, the one project carried through all 35 ideas. See the project.

Stopping is not deciding you are finished. It is getting everything still open onto the page, either as out of scope on purpose or as a deferred decision with the condition that unpauses it. What is written down can be put down. What is in your head is why you keep opening the project.

Check stopping point

Pass: Everything you are not doing is written down, either as out of scope on purpose or as a deferred decision with a named condition that unpauses it. Nothing is being carried in your head.
Fail: What is left lives in your head, or the answer is "I will know when I am done".

Stopping is something you write down. It is not something you feel.

What you'll walk away with

This post is about the running decision: what has to be true once the thing is already live. You'll come out with your own knowledge-base/product/deferred-decisions.md written and sharpened: the real weekly cost of keeping it alive, every paused thing with the condition that restarts it, what is out of scope on purpose and why, plus a clear answer to whether you have stopped.

Write it down

Your deferred-decisions.md is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again.

knowledge-base/product/deferred-decisions.md is just a suggested name and place for this information. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI.

Risk and mitigation

Risk: The project never ends, it only gets quieter. It keeps taking hours you never decided to give it.
Mitigation: Write the deferred decisions down with their triggers. What is written down can be put down.

Key takeaway

You have not stopped until what is left is on the page instead of in your head.

How to document your stopping point

Write it up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this.

# Stopping point

## Answer
What it asks of you in a normal week: [the real ongoing cost]
Paused, plus what unpauses each one: [the deferred decisions]
Out of scope on purpose: [and why]

## Evidence
What you have actually spent on it in the last month, not what you meant to.

## Decision
What you are optimising for now that it runs. What you are deliberately leaving alone.

## Risk
What breaks if this is wrong.

## Standing instruction
What the AI should do every time it touches this. For example: if I ask for something that is not in the answer above, ask whether it is a deferred decision being unpaused or a new one, before building it.