Your first hour with the playbook.

Give Claude a short set of rules

Claude Code reads a file called CLAUDE.md in your project at the start of every session. It is the one place to tell Claude how your project works and how you want it to work with you. Start small. Twenty lines you mean beat two hundred you copied.

Open it and fill in the parts in <angle brackets>: what the project is, and the commands to run and test it. Leave "Rules for this codebase" almost empty. It fills up as Claude makes mistakes. You can also run /init inside Claude Code to have it draft one from your code, then cut it down to the same shape. More in the docs on CLAUDE.md files.

Start a lessons log Claude reads every session

Claude does not remember yesterday's session. So when it makes a mistake, write the lesson down once, in a file, and have it read automatically every time a session starts. That is what a hook is for: a command Claude Code runs at a fixed moment. Whatever a session-start hook prints, Claude reads.

If you already have a .claude/settings.json, do not overwrite it. Open the starter's copy and paste its "hooks" block into yours. The hook is only this:

// .claude/settings.json
{ "hooks": { "SessionStart": [ { "hooks": [
  { "type": "command", "command": "node scripts/show-lessons.mjs" }
] } ] } }

The lessons file comes with one example entry, so you can see the shape. Replace it with your own when the first real mistake happens.

Turn your first mistake into a guard

A lesson someone has to remember is a reminder. A script that fails when the mistake comes back is a guard. Guards are the heart of this playbook, because they work even when nobody remembers. The starter's example guard catches debug console.log lines left in src/.

Add it to the scripts section of your package.json, so one command runs every check:

"check": "node scripts/check-no-debug-logs.mjs"

Now prove it can fail. This is the step people skip, and a guard that has never been red has never been tested.

• Add console.log("test") to any file in src/.
• Run npm run check. It should print FAIL with the file and line, and exit with an error.
• Remove the line and run it again. It should print OK.

Not using JavaScript? Keep the idea and change the details: the folder, the file extensions, and the pattern are three settings at the top of the script.

Plan before you build

For anything bigger than a small fix, ask Claude for a plan before any file changes. In the terminal, press Shift+Tab to switch to plan mode, describe what you want, and read the plan before you approve it. It is far cheaper to fix a wrong plan than wrong code.

Ask for one thing in every plan: a Verification section written as checkboxes, not a numbered list.

## Verification
- [ ] Tests pass, with the count shown
- [ ] The new page works in the browser
- [ ] Error message shown when the form is empty

A checkbox has a state you can see. A numbered list does not, and that is exactly how a planned feature quietly never gets built. Tick each box only with the evidence written next to it.

Get a second opinion before you commit

The session that wrote the code is the worst reviewer of it, because it already believes the code is right. Before committing anything that matters, open a new session and ask it to review the change:

When you want this on demand, copy the playbook's reviewer into your project as a subagent. Claude then runs it in its own fresh context whenever you ask for a review.

Edit the line in its first paragraph that describes your project, and it is ready.

Level up when something hurts

Do not install the rest of the playbook on day one. Each piece exists because of a specific failure. Add it when you hit that failure yourself: