Here's what I find myself typically doing (over a 25 minute session or so):
Examine the code
...and memory if you have it, around the vicinity of the blast radius of code that you're going to touch, so the context window has stuff you need.
/architecture-review examine in detail where we handle wake pattern for concurrent agents in the system
Perform a monologue; get interviewed
Go in to plan mode, tell the agent what you want to do, tell it how you want to do it the best you can.
It is quintessential to provide as much information as possible. You want to favor the quantity of information over quality here, it doesnt matter if its messy or contradict somewhat, as long as its there. Its always preferable to just turn on dictation and ramble a bunch of stuff.
Then tell it to make a plan and call out unresolved design choices to make or concerns.
i want to ....... (omit many words). thoroughly examine code, make a plan, /interview me for unclear stuff or need design decision
Pressure the plan
Straightforward, another round of reviewing the plan and ask more clarifying questions
/critique the plan and see if there is any concern, /interview me again if you need
Implement
Get a coffee and wait 15 minutes depends on what model youre using
Test
Run test, tell the agent to implement tests, do human test, etc. This has existed before LLMs came along
If you're yoloing and have no checks and balances and the project becomes sloppy, theres no one else to blame
Retrospect
Quite optional, but I have found it useful time and time again.
Use a fresh agent session, examine the implementation we just did and point out any problem, concern, missed consideration, etc. and propose fixes.
This gives yourself a much better chance in discovering something not thought of before. You're essentially creating a critic. Because it does not share context with the implementer, it can be much more unbiased and much less prone to sycophancy.
/retrospective on the previous commit, and tell me what we should do