The goal of this worfklow is to make the process more intentional and reliable. Agents are slow, for an agent to properly do the job it needs to go and gather enough context, do the research, it doesn't make sense the be interrupted by agent finishing his job half way to ask for user intervention.
The work should be intentional or be completely automated, nothing in between. Almost is a bitch. That means the agent should work with me to come up with a spec. For small well defined things I might finish the spec myself, for others there might be more back and forth, for third it might require a whole research to compare multiple approaches then my decision and only after that the implementation.
Plan mode is the moment when you have my full attention, I'm fully immersed, working on a single thing. At that point we should figure out the plan what to build, if I didn't specify that, research questions draft the implementation, sudocode or very light implementation examples. That's not the whole implementation that should not be very slow, again, remember, I'm here with full attention, You will have a lot of time to figure things out on your own when I'm gone. But draft implementation should be enough of highfidelity, explain what, how and why this spec should be build this way. First to verify the implementation itself, second to be able to explain why implementation differed. We've planned to build this way, but I've tried and done other way, because of this and that, this were the assumptions when we've started working, but they've changed.
Assumptions is the main word
Think about how to verify you work in advance, don't wait for the work to be done to check how to check, also do not assume you know how to check it yourself. You can not possibly have enough context, even I might not have immediately. So be rigorous. Assume the spec would be done by somebody else in the best possible way, how would you verify that? How the whole flow suppose to work? is there any specific parts of the system which can be checked and verified automatically? Which tests to write? Is it possible to write falling tests first, to later fill the implementation and verify if it's working? DO NOT LEAVE THAT STEP WITHOUT A PERFECT UNDERSTANDING OF ACCEPTANCE CRITERIAS You will inevitable forget all the conversations and inherit context of the execution, at any point you should be able to determine if the system is behaving according to spec, by JUST 3 things the state of the system, spec and acceptance criteria.
I don't care how exactly you split the tasks, that's mostly for you to be able to control and track the flow of execution, so when you inevitable run out of the context, or sessions gets interrupted, or another agent without any of the context comes to you it should be able to fully backtrack all the progress and continue without thinking too much. That means the tasks should be verbose, finished tasks should include refferences to files and changes. Sometimes you will change the same thing. So it's important that every single checkbox corresponds to git commit so if conflicting implementation arrise, you can backtrack what happened. But tasks are for you more than for me. I will only pay attention on the progress
At that point you have a spec, acceptance criteria and tasks. You should be able to go and do the implementation without ever bothering me, something diverge from the initial assumptions a lot and we need to redo the spec or you are done. At that stage, I will fully focused on another task. You should bother me if something critical happens, but you should not assume I'm available. Things are so different you think it doesn't make sense to build until I get back, or you are finished and require my review. You are on your own
Things do not always work according to the plan for 100%. Software is soft, that means you should prepare the review information in a prioritised manner, highlight things which didn't exactly worked the way we assumed first. Things which took you more time should be highlighted as well
Assume that I never have enough time for a full review, things will constantly require my attention elsewhere, meaning everything should be priorities in the order of importance, if I stop 15% into the review, that should be the most crucial 15%.
Once done the spec implementation, contruct a pullrequest and submit for review to me.