Distill Your Own Collaboration Spec
A four-step flow comparison; three tasks: write your first Rule, walk a real requirement through the flow, export the Build Log and shape it into spec v1
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Distill Your Own Collaboration Spec”?
A four-step flow comparison; three tasks: write your first Rule, walk a real requirement through the flow, export the Build Log and shape it into spec v1
Follow the handoffs, not the demo. A system becomes dependable at the boundaries between model, tools, state, permissions, and people. Read each handoff as a place where you can observe, test, and recover.
Name the input, owner, approval, and recovery action for one automated step.
A successful run that cannot explain what happened or be safely repeated.
This chapter's four-step flow (restate, PRD, confirm, code) solves two faces of the same problem: the AI misunderstood the requirement and charged ahead anyway, and by the time you notice it has already changed twenty files. The breakpoint has to sit before it starts working. Any correction after that is rework.
Same requirement, two ways to hand it over
AI restates the requirement
In its own words, what it is supposed to do — if it's off, you see it on the spot
Write a PRD
The plan, the boundaries, what not to do — in black and white
Wait for your confirm
Human gate: no nod, no coding
Start coding
Only now does it start. What it writes is the thing you already confirmed
You don't have to write rules from scratch
The xs_vibe_rules this chapter unpacks is something you can Fork directly. Just don't copy the whole set. A rule is valuable because a real crash sits behind it. A crash you never had — paste the rule and you still won't keep it. The right move: pick three to five rules from the pits you hit in the first five squares, then borrow from the repo the ones where you understand the "why."
This Chapter's Hands-on Checklist
0 / 3 done
Write your first Rule
15 min EveryoneFrom the first five squares, pick the pit that hurt the most and write it as a rule. Use the format this chapter taught: first the why (that crash), then the how (a concrete instruction). If format drift burned you at M1, the rule is "every output must match template XX; if it isn't in the materials, write 'not mentioned'."
What counts as done
Walk a real requirement through the four-step flow
1 hour Anyone who works with AINext real requirement, don't toss it straight to the AI. First ask it to restate; if the restate is off, correct it. Then have it write a one-page mini PRD. Only after you confirm do you let it go. Feel the whole thing: after you move the breakpoint forward, how much smaller is the gap between the result and what you expected.
What counts as done
Export the Build Log, shape it into spec v1
Half a day Anyone walking the full trackGo back to the Build Log, fill in all six milestones, export Markdown. Then the last step: shape it into your own AI collaboration spec: how you set requirements (M0), how you write prompts (M1), how you wire tools (M2), how you evaluate (M3), how you run long (M4), how the flow goes (M5). Send it to a colleague. See if they can build something similar from it.
What counts as done
How “See it first · Put the breakpoint before it starts working, and rework disappears” becomes executable
“This chapter's four-step flow (restate, PRD, confirm, code) solves two faces of the same problem: the AI misunderstood the requirement and charged ahead anyway, and by the time you…” is not about a magic phrase. It is about giving the model enough information to know who the work is for, what must be done, and what counts as acceptable.
Background sets direction; constraints set the boundary
“In its own words, what it is supposed to do — if it's off, you see it on the spot” shows why a useful request separates the task, audience, source material, output format, and constraints. Without background, the model guesses. Without acceptance criteria, fluent text is not evidence that the task is complete.
More words do not guarantee a better result
Turn “M5 is the last square.” into a small experiment: change only one of background, requirements, or constraints while keeping the rest fixed, then observe which layer actually changes the output.
From “See it first · Put the breakpoint before it starts working, and rework disappears” to “Hands-on checklist · Pick one, start it, tick it off”
“See it first · Put the breakpoint before it starts working, and rework disappears” grounds the problem in “This chapter's four-step flow (restate, PRD, confirm, code) solves two faces of the same problem: the AI misunderstood the requirement and charged ahead anyway, and by the time you notice it has already changed…”. “Hands-on checklist · Pick one, start it, tick it off” then moves it toward “From the first five squares, pick the pit that hurt the most and write it as a rule. Use the format this chapter taught: first the why (that crash), then the how (a concrete instruction) . If format drift burne…”. 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
Build a request layer by layer: task and audience first, material and output rules next, constraints and acceptance checks last. Change one layer at a time so you know what actually helped.
- “See it first · Put the breakpoint before it starts working, and rework disappears”: This chapter's four-step flow (restate, PRD, confirm, code) solves two faces of the same problem: the AI misunderstood the requirement and charged ahead anyway, and by the time you notice it has already changed…
- “Hands-on checklist · Pick one, start it, tick it off”: From the first five squares, pick the pit that hurt the most and write it as a rule. Use the format this chapter taught: first the why (that crash), then the how (a concrete instruction) . If format drift burne…
- “The closing point”: Go back to the Build Log, fill in all six milestones, export Markdown. Then the last step: shape it into your own AI collaboration spec : how you set requirements (M0), how you write prompts (M1), how you wire…
The final “The closing point” brings the discussion to “Go back to the Build Log, fill in all six milestones, export Markdown. Then the last step: shape it into your own AI collaboration spec : how you set requirements (M0), how you write prompts (M1), how you wire…”. 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.