> So, the tests being written are based on what?

I don't think you understand what I'm saying. If, during a session, Claude makes any change to a source file, the stop hook script FORCES Claude to run the existing tests. There is literally no way Claude can get around running the tests because the prompt will not stop being processed until the stop hook script passes.

There is no contradiction. Stop hooks (as well as all the other hook types) are the only way to force Claude to work deterministically.

Hook scripts can be as simple or as complex as you like: you define the success criteria. For example, if Claude just added a new feature but didn't create a test for it, then a stop hook would prevent Claude from stopping until the test was written.

▲

classicpsy 19 hours ago | parent [-]

Mate I still didn't understand that.

stop hook forces the claude to run the existing tests. Fine if claude added a new feature but didn't created a test for it. It will wait for it to perform that action. Fine. We can adjust the complexitiy of hook scripts. That's ok.

Tell me if I'm wrong, I am understanding it more like a compiler like if the syntax is ok, just pass. Similarly here, if the test were ran, it will look for a marker file in /tmp, it found it, and pass.

I did not understood the part of tests. Maybe my question is more clear now.

	▲	LatencyKills 19 hours ago \| parent [-]
		This is one of the simplest and most fundamental ways to manage Claude’s behavior. I genuinely can’t make it clearer. The issue you’re describing seems to center on situations where Claude becomes “stubborn” and doesn’t follow instructions. When that happens, the solution is straightforward: create a hook script that explicitly enforces the behavior you want. By doing so, you remove ambiguity and leave Claude no option but to comply. If you can share a specific case where Claude isn’t following your prompts, I can help you craft an appropriate hook to correct it.