Sergei Gordeichuk

Building on plain markdown task files in backlog/in_progress/done, the actual technique is splitting the agent loop into three slash commands that each do exactly one thing. /roll researches the codebase and writes a task file - it implements nothing, which is what keeps planning honest and reviewable. /rock picks up one task and takes it end to end: implement, run the check suite, review the result against the task's own acceptance criteria, refresh the e2e scenarios, commit. /work is a thin loop over a list of task IDs that hands each one to a fresh subagent, so the main context never carries state from the previous task, and parks anything needing a human decision instead of stopping the whole batch. The split matters more than the commands. A single do-everything command quietly merges planning into implementation and you lose the reviewable step in the middle.

You cannot speed up an agent loop you are guessing about. A three-command shell helper - init, mark <phase>, report - stamps timestamps into a log and renders a markdown table at the end of every run. Call mark the moment a phase finishes, not when the next one starts, and let repeated labels sum. Phases worth separating: task setup, implement, check-suite runs, acceptance review, test refresh, commit. Committing the report next to the task turns wall-clock into a tracked artifact instead of a feeling. What it showed me: the coding is rarely the expensive part. It is the check-fix-recheck cycles and regenerating test scripts.

Running browser tests from the session you are working in means the test run and your own navigation fight over one browser, and you get failures that have nothing to do with the code. Define a dedicated subagent with its own isolated browser server in its frontmatter, and explicitly disallow the parent session's browser tools on it. The subagent then physically cannot reach into your browser, so a full e2e sweep can run while you keep working. Worth doing even solo - the isolation is what makes the runs reproducible.

Test scenarios live as numbered markdown files per feature area, with preconditions and expected results - readable, reviewable, diffable by anyone. The runnable scripts are generated from them, committed so they can be inspected when something fails, and regenerated only when the source scenario actually changed. The rule that makes it hold: any task that changes user-facing behaviour updates the scenario and regenerates its script in the same commit. Stale generated scripts are the single biggest source of noisy full-suite failures, and they are the thing an agent will silently skip unless you make it explicit.