Your builder path
4 / 6 chaptersThis chapter
Slide 1 of 4This slide
What a Work Card is
One card is one small, checkable job
A Work Card describes one piece of the build and how you will know it worked. The coach implements one, then stops for you.
For this step
A Work Card lives in work-cards/ and holds one job: what to build, the rules
it must respect, and the check that proves it works.
| A good card | A bad card |
|---|---|
| Adds one screen or one action | "Build the app" |
| Says how to verify it | Leaves "done" to opinion |
| Fits in one sitting | Runs until something breaks |
The coach writes them one at a time on purpose. If you ask it to write ten and implement them all, you get ten unchecked changes and no idea which one broke the thing.
Approve one card at a time
If the coach offers to keep going, it is fine to say no. Finishing one checked card beats starting three.
For this step
The loop
Spec → Build → Check → Ship
One small loop, repeated. Each pass finishes one Work Card, not the whole product.
Spec
Say what good means
Build
One Work Card
Check
Test the main action
Ship
Save the proof
↺ Then repeat for the next Work Card, not the whole product.
| Stage | You do | The coach does |
|---|---|---|
| Spec | Say what one card must do | Writes the card with its check |
| Build | Approve the card | Implements only that card |
| Check | Use it yourself | Fixes the smallest blocker |
| Ship | Record the evidence | Updates build-status.md |
When the coach finishes a card it will tell you how to open the preview, usually
a command in the terminal and a localhost address in your browser.
Open it and use it. Not "does the page load", but "does the thing my user came for actually work".
| Signal | Does it mean done? |
|---|---|
| The coach says "done" | No |
| The code has no errors | No |
| The page loads | Not yet |
| You used the main action and it worked | Yes |
For this step
Chats get long, sessions end, and models forget. Files do not. That is why the coach writes every confirmed decision into your project instead of leaving it in the conversation.
If your chat gets unwieldy, or you come back tomorrow, this is all it takes to put the coach back to work:
Read build-status.md, build-blueprint.md, design.md,
and the current work card listed in build-status.md.
Implement only that work card.
Run its verification steps.
Update build-status.md and stop for my check.Core rule
The chat is not the source of truth. The files are.
For this step
Your starter ships a prompt at prompts/07-review-mirror.md. It makes the coach
check the build against your own brief, design and blueprint, then answer with
PASS, NEEDS FIX or REDRAFT, the top one to three issues, and the single smallest
useful fix.
If it lists five problems, fix the one that blocks the main action. The rest go
in build-status.md under a later list.
A card is not done because nobody found a problem. It is done when its own check passes.
Before you move on
Common mistakes
- Letting the coach implement three cards because they looked quick.
- Trusting "done" without opening the preview and using it.
- Fixing every review finding instead of the one that blocks the action.
- Keeping progress in the chat instead of build-status.md.
- Starting a new session without pointing the coach back at its files.
Work through one step at a time. Ticking a step marks it for this page view only, so nothing is saved when you leave.