Agile vs waterfall workflows

[jakedee]

I've noticed that the workflow follows a mostly waterfall rather than agile path.
Planning is done up-front and there doesn't seem to be a fully-defined flow for how to change direction mid implementation, or updating the plan as you go.

Whilst spec-driven development naturally lends itself more to waterfall than agile, hopefully we can mostly agree that waterfall doesn't work well for projects over a certain size, or with more than one stakeholder.

Either way it'd be great to have more emphasis on updating the plan/direction/specs on the fly, as you would with the agile methodology.

[mikelittle]

I have successfully told Claude to update both the product description and specs to change things part way through a project.

When I first started I ignored the fluff about target audiences and all the "product for the public" stuff. But I was building an internal tool that really didn't need half that stuff. I just told it to remove features and descriptions from those files, and it stopped trying to plan and build things I didn't want.

[amirkiarafiei]

+1 on the need for more agility. While the current workflow is heavily optimized for Spec-Driven Development (waterfall-ish by nature), I think we could support disciplines like TDD, BDD, or API-First without changing the core tool.

We could use the existing Profiles feature to swap out the methodology. For example, a tdd profile could replace the current test-writing.md standard (which currently mandates "Write Minimal Tests During Development") with one that enforces "Red/Green/Refactor". Similarly, we could swap out the write-spec.md workflow for a write-feature-file.md workflow for BDD.

Instead of just one "default" profile, maybe we could ship distinct starter profiles for these different disciplines?