Brief Claude like a colleague you trust and check
Tonight your Product Book moves into a repository, Claude Code reads it through CLAUDE.md, and you approve your first plan.
By the end of tonight you will
- Explain what Claude needs from you and how Claude.ai and Claude Code differ
- Rewrite a list of prohibitions as a working agreement with reasons
- Set up a repository and Claude Code, and run /init
- Write a CLAUDE.md that imports your Product Book and states how you work
- Plan your walking skeleton in plan mode, then approve it or ask for changes
OUTPUT · Repository + CLAUDE.md + approved walking-skeleton plan
Claude.ai vs Claude Code
Claude.ai: thinking partner
- Chat, Projects and Artifacts: you bring the context, ideas come back
- Best for discovery, strategy, design and writing the Product Book
- Sees only what you paste in or upload to the chat or Project
Claude Code: in your files
- Works in your project folder: from the terminal, an IDE or the desktop app
- Reads files, runs commands and edits code, asking permission first
- Reads CLAUDE.md at the start of every session, so your context carries over
Think in Claude.ai, build in Claude Code, and keep the Product Book as the bridge between them.
What Claude needs from you
- CONTEXTWho it’s for, what exists, what you decided: the Product Book, not your memory
- GOALThe outcome you want: “a learner can request a slot”, not “write some code”
- REASONSWhy it matters, so Claude makes sensible calls on cases you didn’t mention
- EXAMPLESOne sample of good output: a test name, a screen layout, a commit message
- DONEHow you’ll check it: criteria pass, tests run, a report of what actually happened
Claude cannot read your mind or your last chat. Brief it the way you would brief a capable new colleague.
Before and after: a fenced prompt vs a briefing
“Act as a senior developer. Build a booking system. Do not use frameworks. Do not make mistakes.”
“I’m building TutorDesk for solo tutors. Plan Slice 1, a learner requests a slot and the tutor confirms it, so I can show a tutor on Friday. Criteria: [PASTE]. Ask if unclear.”
Ask
- What does Claude have to guess in the first version?
- Which ‘do not’ line gives a reason Claude could use?
- How would you know the second version had succeeded?
- Where do the criteria come from?
Lists of prohibitions vs a working agreement
A list of prohibitions
- “Do not add libraries. Never delete. Do not lie. Do not overcomplicate.”
- No reasons, so no help with situations the list didn’t foresee
- Grows after every surprise and still misses the next one
A working agreement
- Says how you work together and why: “Ask before adding dependencies”
- Reasons let Claude apply the intent to situations nobody listed
- Short, kept in CLAUDE.md, revised when something goes wrong
Replace “never do X” with “do Y, because Z”. Reasons travel further than rules.
What goes in CLAUDE.md
- PRODUCTTwo lines on who it’s for, then @ imports of your Product Book files
- STACKWhat it’s built with, pointing to your ADR so Claude follows that decision
- COMMANDSHow to run the app and the tests, exactly as typed, so Claude can verify
- CONVENTIONSNaming, folder layout, slice size: the habits you want repeated
- WORKING AGREEMENTHow you work together: questions, uncertainty, what needs your OK first
CLAUDE.md is read every session, so keep it short and true: every line should earn its place.
An example CLAUDE.md
# TutorDesk Booking tool for solo tutors with 5–30 learners. A learner requests a lesson slot; the tutor confirms it. ## Product Book @product/01-discovery.md @product/02-strategy.md @product/03-design.md @product/04-backlog.md ## Stack As decided in @product/decisions/0001-architecture.md ## Commands Run the tests: [TEST COMMAND] ## Conventions One vertical slice at a time. Use the names from the data model. ## Working agreement Challenge my assumptions. Tell me when you’re unsure, and separate what you know from what you’re guessing. Explain trade-offs in plain English. Ask before adding dependencies, touching data or deleting anything, because I review every change. Report what you actually ran and what actually happened.
Check the response
- Imports the Product Book instead of copying it
- Gives the exact test command Claude should run
- The agreement gives reasons, not only rules
Set-up in five steps
- INSTALLFollow the current install guide at docs.claude.com, sign in, check it starts
- REPOSITORYMake a project folder, run git init, copy your product/ folder in, commit
- /INITStart Claude Code in that folder and run /init to draft a starter CLAUDE.md
- CLAUDE.MDEdit it: add your @product imports, commands and working agreement
- FIRST PLANTurn on plan mode with Shift+Tab and ask for the walking-skeleton plan
Set-up is the fiddliest part of the course. Pair up: nobody leaves without a repository.
Plan mode vs straight to code
Straight to code
- Claude starts editing before you have agreed what done means
- Wrong assumptions arrive as code you then have to read and undo
- Fine for a one-line fix you could describe exactly
Plan mode first
- Claude reads your files and proposes a plan without editing anything
- You check it against your stories, criteria and ADR, and ask for changes
- Approve it and Claude builds, still asking before edits and commands
A plan is cheap to change; code is not. Approve the plan before Claude touches a file.
Plan the walking skeleton in plan mode
This is my TutorDesk repository. Read CLAUDE.md and the Product Book it imports, especially stories [STORY IDS] in product/04-backlog.md. I want a plan for the walking skeleton, a learner requests a slot and the tutor confirms it, so I can review it before any code is written. Plan the thinnest version that works end to end: the screens, the data it stores, and one test for each Given/When/Then criterion. List the files you would create and any dependency you would add, with the reason. Propose the test command for CLAUDE.md. If the backlog and the ADR disagree, or you’re unsure about anything, say so and ask me. Done is a numbered plan of at most 10 steps that I can approve.
Check the response
- Plan mode is on before you send it
- Every criterion maps to a test in the plan
- Each new dependency has a reason you accept
Set up, write CLAUDE.md, approve your plan
Set up your repository, write a CLAUDE.md that imports your Product Book, and approve a walking-skeleton plan you understand.
- Install Claude Code, create a repository, copy in product/ and commit (15 min)
- Run /init, then edit CLAUDE.md: imports, commands, conventions, agreement (15 min)
- In plan mode, ask for your walking-skeleton plan and revise it at least once (15 min)
- Save the approved plan under ‘Sprint 1 plan’ in product/04-backlog.md and commit (5 min)
- If time allows, let Claude build, reading each permission prompt before you say yes (10 min)
Repository with CLAUDE.md and the approved plan in product/04-backlog.md
Setup rubric
- The repository has at least one commit and contains the product/ folder
- CLAUDE.md imports at least three Product Book files with @product/ paths
- CLAUDE.md states the stack, the test command or its placeholder, and the agreement
- The plan builds only the walking skeleton and maps each criterion to a test
- Every new dependency in the plan has a written reason
- The saved plan shows at least one change the learner asked for before approving
NEXT · Week 5: the build loop. Bring a working set-up and your approved walking-skeleton plan.
© 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