Four Steps: Restate, PRD, Confirm, Code
Bringing requirements confirmation into human-AI collaboration; batch changes need a plan first, new features need a duplicate check first
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Four Steps: Restate, PRD, Confirm, Code”?
Bringing requirements confirmation into human-AI collaboration; batch changes need a plan first, new features need a duplicate check first
Turn taste into a behavior the product can repeat. The useful outcome is not a nice opinion. It is a visible rule, a small example, and a way to tell when the experience falls below the bar.
Capture one before-and-after example that shows the quality bar without extra explanation.
Polish that improves the surface while leaving the user's uncertainty untouched.
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.
Turn the feeling in “Interactive Demo 1 · Five-Step Flow Simulator” into a judgment
“A real-world requirement — "Add an export report feature" — runs through the full flow.” points out that AI has lowered the bar for making something usable. The skill readers need is noticing what is wrong and turning that feeling into an actionable requirement.
Watch the user's next action, not just the surface
Turn “"Please confirm you understand before coding" is too vague.” into observable questions: does the user know what happened, what to do next, and how to recover from an empty or failed state? Does the hierarchy make the important information visible first?
- 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
Pretty is not the same as usable
Apply “Set the breakpoint before any action is taken.” to a second screen or flow. Record one moment of hesitation and the user action after the change; observable behavior is stronger evidence than polish alone.
From “Interactive Demo 1 · Five-Step Flow Simulator” to “Why You Must Specify Concrete Steps”
“Interactive Demo 1 · Five-Step Flow Simulator” grounds the problem in “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”. “Why You Must Specify Concrete Steps” then moves it toward “"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 app…”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For experience work, turn abstract impressions into user actions: did the person understand the state, find the next step, recover from an error, and want to continue?
- “Interactive Demo 1 · Five-Step Flow Simulator”: 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
- “Why You Must Specify Concrete Steps”: "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 app…
- “The closing point”: When an existing implementation is found, prefer reusing or extending it
The final “The closing point” brings the discussion to “When an existing implementation is found, prefer reusing or extending it”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.