"Do something" to prevent massive commits

[fgrehm]

First of all: 2.0 is amazing! Thanks a lot for that, started using on a new side project and it did "lots of great stuff".

My only "complaint" is that we don't not have anything around "drawing the line" of when commits should be made / PRs be created.

Some initial thoughts for discussion:

• Maybe agent-os could encourage some kind of "multi step PR approach" for large specs
• Suggesting stopping points for commits based on tasks / task groups could be a good start
• Encouraging commits after /new-spec / /create-spec would be amazing too
• Maybe we could have /implement-spec handle the "commit / PR slicing"?

I'm kinda new to this "spec-driven agentic development" world, so not sure how others are approaching this "problem". I just feel like the agents try to do too much in one go.

Do others experience(d) this as well? If so, were you able to work around it?

---

Related to #160 and #202

[fgrehm]

Here's my take on this #214, going to test that out in a project and report back my findings 🤞

[smaugho]

Agent-OS is using a quite generic (and very simplistic) implementation workflow, and this is where the commit issues lies.

I'm giving it a try and adjusting to my own workflows, which are much more complex, but also, I recognize that workflows could be very different between developers.

On the workflows I'm implementing at the moment on a custom profile, I have ATDD, TDD, Source Refactor, Test Refactor and Documentation workflows (probably I'll add later others, like Pipeline workflows), each one of those workflows have its own moment to commit, i.e. on TDD, you perform Red-Green-Refactor, I personally like to commit within each cycle twice, on Green, and after Refactor (as the code is compiling anyway, and I'm a big enthusiast of actual Continuous Integration / Delivery.

But I know that commits can get much more complicated in a heavy CI environment with multiple developers / agents working on different features at the same time, because then you have to perform merges (and solve conflicts), and take into account the state of the pipeline. I personally handled all this in the past with a lot of Cursor rules and precise task management, but since I'm migrating to Claude Code, and found out Agent OS initiative, decided to try it out with it (using custom profiles)... I hope to be sharing my findings with the members working on the project, and hopefully contributing to it.

Note: Distinction of workflows depends on tasks of course, i.e. any UI-related task would follow ATDD, creating Playwright / Cypress BDD-style tests first, and following with TDD cycles using unit / integration tests. But if you are just refactoring tests, mutation tests are the best protection before any change (and tests themselves for any code refactoring - behavior-preserving change).