How to chain the /feature-refinement, /iterative-review, /plan-maker and /implement commands — and where to keep human review gates.
AI commandHuman review gateMUST mandatorySUGGESTED recommendedOPTIONAL optional
Review intensity:
Only mandatory and recommended gates active. The rest are dimmed.
▸ Pipeline · from brief to commit
Click a step for details · or navigate with ←→ arrow keys
How many human reviews do you keep?
Your seniority and the task's risk decide. More automation → more tokens, more AI drift. More human gates → slower, but safer.
Minimum
Quick prototype
You keep only the mandatory gates. Good for small features or throwaway POCs.
3 → 4 → 5 → 6 → 8
Balanced
Typical daily work
Mandatory + recommended reviews. The default for a senior developer.
1 → 3 → 4 → 5 → 6 → 7 → 8 → 9
Maximum
High risk / critical system
Every gate active, including optional ones. Production, security features, large refactors.
1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9
Command cheatsheet
/feature-refinement
Q&A session that also analyzes the codebase. Produces a brief md file.
/iterative-review <file>
Devil's Advocate agents attack in parallel, other agents fix. Loops until no major issues remain.
/plan-maker <brief>
Architecture, tests, acceptance criteria, detailed tasks. Often 1000+ lines.
/implement next <plan>
Implements only the next single task. Internal /iterative-review loop fixes issues. Works in any harness (Claude Code, Cursor, claude -p).
/implement all <plan>
Walks through every uncompleted task — one at a time, one commit each. Use only with a well-structured plan and lower-control tolerance.
Golden rules
01
Garbage in → garbage out. The quality of the brief determines the whole pipeline's output. Invest the time.
02
New session = clean slate. After each approved artifact, continue in a new session. Don't carry stale context.
03
One task = one commit. Never bundle. The diff stays auditable.
04
TDD is not optional. Test functionality (user story), not code. Unit + integration + e2e per task.
05
More automation = more tokens. The ratio of human review gates is your call. That's where seniority shows.
Devil's Advocate · the agent that matters most
What does the Devil's Advocate agent do, and why is it so cool?
Most AI agents look at what works. Devil's Advocate flips it: it specifically hunts for what can break. It stress-tests the plan, questions assumptions, counters claims, exposes blind spots — not to win the argument, but to crack open your own confirmation bias.
What does it look for?
Logical gaps, hidden assumptions, missing edge cases, over-optimistic estimates, hallucinated facts, and risks that aren't yet on the plan.
How does the loop work?
Multiple Devil's Advocate agents attack the artifact (brief, plan, code diff) in parallel. Other agents fix any moderate+ issues. Reruns until no major issues remain.
Why is it cool?
It removes confirmation bias from the pipeline. Your AI stops being just an agreeable partner — you get an internal critic that surfaces what you yourself wouldn't dare to say out loud.
When to use it standalone?
The workflow runs it automatically at steps 3 and 6 (brief and plan). But you can invoke it manually for code review, architecture decisions, or any proposal that looks "too good to be true."
Devil's Advocate philosophy: "I'm not looking for what works — I'm looking for what can break." Good criticism is cheaper than a bad implementation.