[mh-]

> [..] my rules do say: verify all changes with tests

I am a bit surprised that you're disappointed that it does exactly what you told it to - people usually have the opposite complaint.

If you're using it interactively and watching what it changes, I'd trigger the tests when you think it's needed. And if you want to go more hands-off, why not add try to encode the same nuance you'd use into the rule?

[iamflimflam1]

Rather than bake that into the prompt - wouldn’t it be better to just set up a pre commit hook that runs tests and linting?

[mh-]

Maybe, depends on their workflow. In my human workflow, I tend to use commits as checkpoints and then squash before pushing. I'd usually only run time-consuming tests before squash+push.

But yes, anything you want to ensure really needs to be a hook.

edit: realizing with "precommit" you probably meant a git hook not one in their harness. I'd have written the same response more or less though. :)

[iamflimflam1]

Oh yes - definitely the git kind of hook. Also, I always forget that there’s a pre-push hook as well. So you don’t need to do things every commit.

But then you could just be storing up a lot of problems…

[mh-]

Indeed. That's why I think it depends on the individual's workflow where it should live.