You should set things like this in Claude's settings.json rather than just asking the model and hoping it will obey. That way it will be enforced by the harness.

As some other comments have said, there are various other options like hooks which are run by the harness and can be used to always enforce certain things (running a formatter for example).

But for your examples, settings are the correct solution. Set an ask permission on git commit and it will always prompt you before committing. For commit messages, just set attribution commit to an empty string and it will stop adding its own attribution. https://code.claude.com/docs/en/settings#attribution-setting...

Two tiny changes; problem solved permanently.

Thanks, that's helpful, although I can't help but appreciate I had to get this suggestion from a person rather than the AI..

Totally. For anything like this, I find asking people or just reading the docs way quicker and much, much more reliable than asking AI. It's interesting that the models seem to know very little about their own abilities.

A couple of notes for anyone reading this comment and thinking of implementing something similar:

- You should use skills instead of commands (commands still work, but they've been rolled into skills) https://code.claude.com/docs/en/skills

- Hardcoding git diff against main isn't always ideal (depending on your git workflow). If you branch off of branches, the agent will figure it out, but it often has to go through a few hops to determine what to actually diff. You're better to ask it to diff 'the commits on this branch' or similar.

- You might not necessarily want to enter plan mode for a review. I don't personally as I don't see any benefit to it writing a markdown plan file for a review.

Thanks for this, I’d agree and elaborate a little

- Skills over commands: agreed - but they are more complex than a single file. I’m suggesting a command because it’s a great way to start and build up that checklist. Over time, migrate it to a skill. But one thing I’d say is keep it in your repo. That way, PRs can include new bullet points with the code that gave rise to them. Opinions will differ on this: it muddies the PR a little in the present. But OTOH future folks can git blame to see where that bullet came from.

- Hardcoding against main: yes, this is a very good catch - a better prompt is to tell the agent to compare to the branch’s merge base. Again a detail left off for simplicity to encourage folks to start somewhere. Your suggestion is a quick win fast follow for correctness.

(side note - 90% of the time Opus 4.8 guesses the intent and decides to use the merge base on its own! Opus 4.6 didn’t do that. These things are smart if you set them up for success!)

- Plan mode for review I would say personal choice. It is crucial in my experience because some of my list makes it overzealous in planning cleanups and the like. YMMV. Yes plan mode is optional and I sometimes have to reread and discuss a review plan after a context switch in my day - but at least it didn’t spray bad cleanups all over a decent PR.

A skill is a single file too thought right? Just `.claude/skills/review/SKILL.md` instead of `.claude/commands/review.md`. I think the format is more or less identical as well? I may be missing some subtle difference though. As you say, either will work fine for this, but in general Anthropic's advice is to just use skills now.

Agreed on the plan mode. I think it's personal choice and also situation-dependent. When I've already reviewed everything the agent has written and made changes along the way, I'm pretty confident a review is only going to throw up minor tweaks. When reviewing someone else's code or if you've got a load of changes you haven't reviewed yourself yet, plan mode is probably useful. I always think it's worth highlighting that plan mode isn't just 'don't make changes', it's a fundamentally different mode with a different prompt and objectives.