Four-Step Flow: Restate, PRD, Confirm, Code
Bringing software engineering's requirements-confirmation phase into human-AI collaboration: the AI must restate requirements, write a PRD, and get explicit approval before writing a single line of code. Add bulk-edit breakpoints and duplicate-detection rules to contain the blast radius before anything is touched.
A real-world requirement — "Add an export report feature" — runs through the full flow. Click "Next Step" and pay close attention to Step 4: until you click "Approve", the AI will not write any code.
"Please confirm you understand before coding" is too vague. The AI will decide on its own that "I already understand," then immediately start. Only by specifying concrete actions like "write a PRD, wait for approval" will the AI actually pause. In practice, the AI will judge that a simple one-line change doesn't need a PRD — this flow mainly intercepts multi-file changes and new feature development, which have the highest rework cost.
The rule reads: "When modifying more than 3 files, you must first list the modification plan and wait for user confirmation before proceeding." Drag the slider to change the number of files in scope and see when the breakpoint triggers.
Which files to change
The complete file list. You first verify the scope is correct, then review the content. The list itself can expose anomalies like "why does this requirement touch a config file?"
What changes in each file
Describe the changes file by file. This prevents the AI from "conveniently" doing unrelated refactoring or cleanup alongside your actual request.
Dependencies between changes
Which file to change first, which next, who depends on whom. Prevents a chain of file edits that ends with a flawed approach and an expensive rollback.
The threshold is adjustable per project: 3 files is the author's empirical value; cautious projects can lower it to 1, and rapid prototypes can relax it to 5.
Problem: The AI Doesn't Know an Existing Wheel Is Already There
The AI's context is limited to the current conversation — it cannot see a utility function written in a different conversation three months ago. Without constraints, the same formatDate gets written four times, each with slightly different behavior.
Rule: Search First, Then Act
- Before adding a feature, you must first search the project for an existing similar implementation
- Search scope: function names, class names, and utility methods in the relevant directories
- When an existing implementation is found, prefer reusing or extending it
Set the breakpoint before any action is taken. Restate and PRD intercept misunderstandings; the modification plan intercepts cascading errors; duplicate-detection intercepts reinventing the wheel. All three checkpoints are cheaper than rolling back after the fact.
Source: corresponds to Chapter 2 "Requirements Processing & Development Workflow" in rule-opensource.mdc, repository itshen/xs_vibe_rules.