Small loops, checked work, honest commits
Build your first real slice with Claude Code: plan it, build it, check it, read it, save it. Then do it again.
By the end of tonight you can
- Run plan → build → verify → review → commit on one slice with Claude Code
- Read a diff and explain in plain English what changed, why, and what could go wrong
- Ask Claude for tests by name: happy path, bad input, not allowed, edge case, regression
- Undo safely with checkpoints (/rewind) and Git commits, and say when to use each
- Turn a briefing you keep repeating into a custom /slice command
OUTPUT · Slice 1 working end to end, with tests and a commit history
The build loop
- PLANClaude proposes files, steps and tests in plan mode; you approve or push back
- BUILDClaude edits in small steps; you read each permission prompt before saying yes
- VERIFYRun the tests and try it yourself in the browser; Claude’s summary is not proof
- REVIEWRead the diff: what changed, why, and anything outside the slice
- COMMITSave a named point in Git with a message that says why, then start the next loop
One small change, one loop, one commit. Small loops make mistakes cheap to find and cheap to undo.
One giant prompt vs five small loops
“Build TutorDesk bookings: requests, confirmations, reminders, payments and a dashboard.” 40 files later…
Slice 1 in five loops: request form → save the request → the tutor’s list → only she can see it → the learner sees “Requested”. Each is planned, tested, read and committed before the next.
Ask
- If loop 3 breaks, how far back do you have to go?
- Where in 40 changed files would a privacy bug hide?
- Which loop could you show a tutor tonight?
- What do you learn after loop 1 that changes loop 2?
Reading a diff: five questions
- WHAT CHANGEDWhich files, and roughly how many lines were added (+) and removed (−)
- WHYEach change traces back to the story or the plan; ask Claude to explain any that don’t
- SCOPENothing outside the slice: no surprise rewrites, new packages or changed settings
- RISKLook hardest at logins, permissions, payments, deleting, and anything that saves data
- TESTSNew behaviour has a new test, and no test was deleted or weakened to make it pass
You don’t need to read code fluently to read a diff well. You need to ask these five questions every time.
What tests are for, in plain English
A test is…
- A small program that uses your product and checks the answer, the same way, every time
- A written promise: “a learner can’t request a slot in the past”
- Fast: hundreds run in seconds, so you can run them after every change
Tests let you…
- Change things without fear: if you break an old feature, a test goes red
- Check Claude’s work with something other than Claude’s word
- Show a reviewer, investor or contractor the product does what you claim
Tests are how you know it still works tomorrow, after you, Claude or a contractor change something.
Tests worth asking for
- HAPPY PATHA learner requests Tuesday 4pm with a name and email; the request is saved
- BAD INPUTEmpty name, broken email, a date in the past: a clear error and nothing saved
- NOT ALLOWEDAnother tutor, or a visitor who isn’t logged in, can’t see this tutor’s requests
- EDGE CASETwo learners request the same slot at once; a slot at midnight; a very long name
- REGRESSIONWhen you fix a bug, add a test that would have caught it, so it stays fixed
Ask for tests by name. “Write tests” gets happy paths; these five kinds get confidence.
Two safety nets: checkpoints and /rewind vs Git commits
Checkpoints and /rewind
- Claude Code saves your code automatically before each of its edits
- Undo with /rewind, or press Esc twice, then choose a point to return to
- Ideal for “that last idea was wrong, go back five minutes”
- They live in your Claude Code sessions and don’t replace Git
Git commits
- A named save point you make on purpose, with a message that says why
- Permanent history you can push to GitHub, share and review
- Lets anyone on the team undo any change, from any day
- Made after verify and review: commit only work you’ve checked
Checkpoints for minutes, Git for history. Rewind freely; commit every loop that ends green.
Make it repeatable: a custom /slice command
- NOTICEYou’ve pasted the same build briefing for the third time
- WRITESave it in plain words as .claude/commands/slice.md in your repository
- RUNType /slice in Claude Code; it asks which story, then plans before building
- SHARECommit the file; anyone who clones the repository gets /slice too
- IMPROVEWhen a loop goes wrong, add one line to the command so it doesn’t happen again
A slash command is a briefing you write once and improve like code.
Build Slice 1 with plan mode, tests and an honest report
I’m building TutorDesk, a booking tool for independent tutors. Tonight I want Slice 1 working end to end, because I need to see a real request saved before I build anything else. Here is the story and its acceptance criteria: <story>[PASTE STORY AND CRITERIA]</story> First, plan: the files you’d change, the tests you’d write (happy path, bad input, not allowed, edge case) and any questions. Wait for my approval. Then build it in small steps, run the tests, and report like this: Ran: [command] → [what happened] Changed: [file] – [why] Unsure: [what I should check] If a test fails or you couldn’t run something, say so plainly; that is more useful to me than a tidy summary. Done means every criterion has a passing test.
Check the response
- The plan names tests for all four kinds before code
- The report shows the real command and its output
- You tried the slice yourself and read the diff
Workshop: build Slice 1 end to end
Take the first vertical slice from your product/04-backlog.md all the way round the build loop with Claude Code, in at least three small loops.
- Save the Studio briefing as .claude/commands/slice.md and commit it
- Run /slice in plan mode; push back on one thing before you approve the plan
- After each loop: run the tests, try it in the browser, read the diff with the five questions
- Commit every loop that ends green; use /rewind or Esc twice when a loop goes wrong
- Explain one diff to your neighbour in plain English: what, why and the risk
Slice 1 working, tested and committed; linked from product/04-backlog.md
Slice rubric
- Slice 1 runs end to end, demonstrated live on the learner’s machine to a peer
- An approved plan exists for the slice, saved or linked in product/04-backlog.md
- Tests cover at least happy path, bad input and not allowed, and the run is shown passing
- Git log shows three or more small commits whose messages say why
- The learner explains one diff in plain English: what changed, why, and the risk
- .claude/commands/slice.md is committed and was used to build the slice
HOMEWORK · Finish and commit Slice 1; bring one test that failed and what it taught you.
© 2026 MVP Studios Ltd. MVPAI™ and the MVP Founders Programme materials are original works of MVP Studios Ltd. All rights reserved. No copying, redistribution or commercial use without written permission. Course terms