Here is a demo board link: https://yourroadmark.com/board/roadmark-demoThe data are mostly made up. On the board you can find all pivots, description of “why” it happened, target/completed dates, decisions log, on some milestones confidence rate or how many times date has been moved.I built a roadmap management tool that keeps “why” your plan changed and branches the plan instead of overwriting...
1. My agent writes code.
2. Then it creates tests and verifies that all of them actually work, not just pass. To do this, my agent writes the test, then it deletes the code it covers, reruns the test, confirms it goes red, and finally puts the code back.
3. I receive the ready-to-test code and environment setup.
4. I check that the business logic works as I expected it to be on a working product. Here we usually do several iterations of coding and bug fixing.
5. When the manual part is finished, the agent starts an external review using /code review skill. At that stage, it makes some additional fixes and corrections to the tests.
6. Finally, a branch is ready to be merged. We start CI/CD and wait until the run finishes successfully.
That's what I actually use because it generally works.
Note about only docs PRs: I just ask the agent to make the changes, then it runs the / code review skill, and then we merge the branch into main without CI running.
The process works the following way: the agent writes the test, then it deletes the code it covers, reruns the test, confirms it goes red, and finally puts the code back.
Here is what made me start doing this. An e2e test for a touch gesture was green for weeks. I deleted the gesture handler, and the test stayed green, because Playwright's synthetic touch isn't actually a touch, so the test had never once exercised the thing it was named after. Reading it would never have shown me that.
It's discipline, not tooling. I don't run mutation testing; it's manual and only around whatever I just changed. And to be straight about your first question: it's the agent reading that test code, not me. Which is exactly why I don't rely on reading to catch this. Breaking the code and watching the test go red doesn't care who read it.
For instance, all DB migrations and access policies are applied by me. In this case, feature flags don't help because if the read policy is too permissive, the data will be out by the time you notice it.
Before I figured it out, I shipped to issues.
The first of them was a policy that was letting anyone read a board's member list.
The second was a "with check" in the policy that pinned a column's value, so any other user's unrelated updates on that row started failing, and neither was visible in the diff. The first one showed up only in a test that asserts the attacker fails. The second one only in a test that asserts a different legitimate user still succeeds.
As for now, I pass reversible stuff to the agent, and the sensitive changes I apply myself. Also, I ask the agent to cover negative cases and make a security review before applying sensitive changes.
That's it.
First of all, the agent writes code. After that, it creates tests and verifies that all of them work correctly by cracking the checks and rerunning the test suite.
Secondly, it gives me the ready to test code + set up environment (stage). I'm checking that the code actually works, and if not, we are making some fixes until I'm fully satisfied with the result.
Thirdly, the agent starts an external review using skill for code review and usually makes some additional fixes to codebase and corrects tests again.
After all, we are ready to commit and push the feature to the main branch. Before merging, we start CI/CD - which is important because it does a type check - and wait until the run finishes successfully.
That's how it happens in my case.
Quick note: this plan was built after many iterations of coding and testing, and it has finally proved that it works.