Level 3 ■ Black: track card

• A blank page (card 03, version C). Use the ten headings of the template as a checklist, not a form. Your outcome statement and three success checks go in word for word.
• Draw two constraint cards (card 14). Write each in as a requirement, with the check that proves it.

Sketch on paper first: the checked content and its named data section; the screens and controls; the state and reset behaviour; what it stores and where (nothing, or this browser only); the rules and files. Write three core checks and two boundary expectations before implementation.

Teacher workflow, including menu 9: your own spec names the teacher user, checked preparation steps and workflow checks. The planning prompt below still applies; your tool needs no quiz, right/wrong feedback or retrieval activity.

Then make an empty folder and start the agent in it, set to plan first (the Build Room's Tool guides and card 09 have the steps):

• Claude Code, desktop app: in the Code tab, choose Local, select your folder, and set the mode selector next to the send button to Plan.
• Claude Code, in a terminal: type claude --permission-mode plan, and check the line under the prompt box says ⏸ plan mode on. If you launched with --permission-mode plan you're already in plan mode. Shift+Tab is only for when you started with plain claude: press it until you see ⏸ plan mode on.
• Codex, desktop app: in the ChatGPT app, open Codex, add your folder as a project, leave permissions on Ask for approval (never Full access), and type /plan. If a label differs on your screen, the prompt below still asks for the plan in words.
• Codex, in a terminal: type codex --sandbox read-only. The prompt below asks for the plan in words.

Check the mode before you paste. Without plan mode, or read-only in a terminal, either agent may edit files and run commands without asking.

Then paste:

Build the classroom tool in my spec below. Follow its red lines: no login; nothing saved or sent unless my spec says so; no calls to any AI service or other website; one self-contained HTML file unless my spec says otherwise.

Plan first: list the files, what each screen does, what it stores, and how you'll check each success check. Don't write code until I say go.

MY SPEC, WITH MY TWO CONSTRAINTS AND MY SKETCH:
[PASTE]

Claude Code in a terminal: after the paste, type Follow the instructions in my paste. and press Enter.

Pasted text can contain instructions, so check what you paste: read it through before you send it, and paste only your own spec.

"Don't write code until I say go" is a request in words. Check the plan against your sketch, and correct it. Predict three things you expect to see, then say go.

• Claude Code: plan mode blocks edits until you approve the plan. When you approve it, choose Yes, manually approve edits (in the desktop app, switch the mode to Manual), then accept or reject each change.
• Codex, desktop app: the plan is your only check before edits: on Ask for approval, Codex may edit files in your folder without asking. Codex, in a terminal: if it asks to edit a file or run a command, read the request before you approve it.

Coding goal: Separate checked content, interface and state; explain two coding choices, enable a colleague content edit without logic edits, and verify boundaries and regressions.

These are planning estimates, not measured learner completion times. Keep the whole-room schedule. Use generation time to check content, write expectations or review the plan; do not fill it with cosmetic changes.

Evidence to leave with:

• A sketch distinguishes checked content, UI controls, state, rules and files; the plan matches it.
• Explain two coding choices and how they serve the user, including the content/state/UI distinction.
• A colleague changes one item in a named content-data section without editing interaction logic; the change appears correctly.
• Two boundary cases have predicted and observed results; all three original checks are rerun after the content change and any repair.
• A peer opens the final artifact unaided; the saved version, contribution, retest and any remaining failures are recorded.

Sprint 1: fifty minutes

At elapsed minute 20, save the available version, even if partial. A saved reference page, current project backup or numbered file is evidence of progress; name what still fails.

Peer testing: In the 20-minute swap, use the story/setup and two nine-minute silent tests. The peer opens the final artifact, runs the three original checks and two named boundaries, and verifies the colleague content change. You stay silent and read the recorded evidence afterwards.

Sprint 2: twenty minutes

If stuck: Save and name the blocker; keep the useful outcome and move to a working permitted tool if needed. Simplify to one screen and interaction. Finish the sketch, core test evidence and two coding-choice explanations; record an unfinished content handoff instead of claiming it passed.

If ready: Complete the content-edit and two-boundary core tasks first. Then ask a colleague to supply a second checked content pack using the same interaction code, or add repeatable behaviour tests with tools already working. Publishing is optional; deepen the same useful task.

Do not pretend a partial tool is finished. The final version is ready when its success checks pass; record every unmet check honestly. Use the four-minute retest for the changed or new case and three short core checks. Start content and access review during Sprint 1; ask a helper to review code and Network activity in parallel. If a check needs longer, record Not run, its next action and the version saved. Do not claim a pass or finished delivery from an incomplete run.

Your architecture and test evidence

Complete this sketch before implementation. Keep checked content separate from the interaction logic so your colleague knows what may be changed.

Write the expected results before generation. Record the observed result and saved version after running each check.

Content handoff (S13 is core today): my content-data section is [ ]. My colleague changed [ ] to [teacher-checked, made-up replacement]. No interaction logic changed. I compared the displayed result with the replacement and reran the three core checks.

Boundary evidence (S14 is core today): choose two relevant boundaries such as an empty list, last item, repeated Check, undo or Reset. Predict both, run both and record actual results. After a content edit or repair, rerun all three original checks. A failing boundary is useful evidence; it is not a pass until independently retested.

Explain two choices without reading the agent reply: I put [content] in [named section] so a colleague can [ ]. I keep [state] in [place] and show [UI response] because [user need]. Explain the difference between content, state and interface; show your partner where each appears in the sketch and final file.

First check that Git is there: type git --version in a terminal, or ask the agent to run it. If it prints a version number, ask the agent: "Commit this with the message: check [number] passes."

No Git? Save a numbered copy instead: index-v2.html, index-v3.html, and so on. Keep the old copies.

• Save a version: commit, or save a numbered copy (index-v2.html).
• Rate yourself. Stuck: a sticky note on your laptop lid; a helper comes. On track: carry on. Ready for more: take a stretch card (card 14).

Find your test partner before the break. Pair with anyone at a different level; if you can't, pair with someone who hasn't seen your build. Sit next to them when you come back. An odd number makes one trio, with 6-minute turns.

1. The maker hands over the tool, the canvas and this card, then says nothing until the turn ends.
2. The tester runs each success check exactly as written, then tries two relevant edge cases from card 05: for a quiz, try no answer or a right answer in another form; for a workflow, try repeated use or an empty list; test keyboard use and phone width too. For phone width: Narrow the browser window to its smallest, or send the file to your phone.
3. The tester logs each failure in the bug log below: Check / Expected / What happened.
4. Swap roles.

Bug log. The tester writes here, on the maker's card.

Fix failed checks only: no new features. If none failed, write one new boundary check or clarify an unclear requirement; test it and repair only a real failure. One change per prompt. Read what the agent says it changed, re-run the check yourself, then the others, then commit or save a numbered copy.

Success check [number] failed. When I [what I did], I expected [what should happen], but [what happened]. Fix only this.
Keep everything else unchanged. Explain what you changed and how I'd check it.

Complete the S13 content handoff and S14 two-boundary test in your learning plan first; they are core Level 3 work today. All checks pass? Choose further depth:

• Publish it on GitHub Pages (card 17), then re-run three of your checks on the live link, on a phone.
• Run the keyboard and contrast audit (card 08) and log each line.

• The install failed, or the agent is the problem? Take the same spec to Level 2 ▲ Orange (track card 11), in AI Studio or any AI chat tool. Your blank-page spec already covers the template's sections.
• Your checks before anyone else uses it: card 08, safe building, then all 12 quality checks and the audit.

The whole kit: www.deepeducationnetwork.com/courses/build-with-ai/kit