I got a notification when I opened it, indicating that the default had changed, and I can see it on /model.

Only on a max (20x) account, not there on a Pro one.

Don’t rely entirely on CC. Once a milestone has been reached, copy the full patch to clipboard and the technical spec covering this. Provide the original files, the patch and the spec to Gemini and say ~a colleague did the work and does it fulfill the aims to best practices and spec?

Pick among the best feedback to polish the work done by CC—-it will miss things that Gemini will catch.

Then do it again. Sometimes CC just won’t follow feedback well and you gotta make the changes yourself.

If you do this you’ll be more gradual but by nature of the pattern look at the changes more closely.

You’ll be able to realign CC with the spec afterward with a fresh context and the existing commits showing the way.

Fwiw, this kind of technique can be done entirely without CC and can lead to excellent results faster, as Gemini can look at the full picture all at once, vs having to force cc to consume vs hen and peck slices of files.

In my experience it works better if you create one plan at a time. Create a prompt, make claude implement it and then you make sure it is working as expected. Only then you ask for something new.

I've created an agent to help me create the prompts, it goes something like this: "You are an Expert Software Architect specializing in creating comprehensive, well-researched feature implementation prompts. Your sole purpose is to analyze existing codebases and documentation to craft detailed prompts for new features. You always think deeply before giving an answer...."

My workflow is: 1) use this agent to create a prompt for my feature; 2) ask claude to create a plan for the just created prompt; 3) ask claude to implement said plan if it looks good.

My system is to create detailed feature files up to a few hundred lines in size that are immutable, and then have a status.md file (preferably kept to about 50 lines) that links to a current feature that is used as a way to keep track of the progress on that feature.

Additionally I have a Claude Code command with instructions referencing the status.md, how to select the next task, how to compact status.md, etc.

Every time I'm done with a unit of work from that feature - always triggered w/ ultrathink - I'll put up a PR and go through the motions of extra refactors/testing. For more complex PRs that require many extra commits to get prod ready I just let the sessions auto-compact.

After merging I'll clear the context and call the CC command to progress to the next unit of work.

This allows me to put up to around 4-5 meaningful PRs per feature if it's reasonably complex while keeping the context relatively tight. The current project I'm focused on is just over 16k LOC in swift (25k total w/ tests) and it seems to work pretty well - it rarely gets off track, does unnecessary refactors, destroys working features, etc.

I use Gemini-cli (free 2.5 pro for an undetermined time before it self-lobotomises and switches to lite) to keep the specs up to date.

The actual tasks are stored in Github issues, which Claude (and sometimes Gemini when it feels like it) can access using the `gh` CLI tool.

But it's all just project management, if what the code says drifts from what's in the specs (for any reason), one of them has to change.

Claude does exactly what the documentation says, it doesn't evaluate the fact that the code is completely different and adapt - like a human would.

I do this all the time in Claude Code, you hit Escape twice and select the conversation point to 'branch' from.