1 / 27

Free, step-by-step slide guide

The Claude CodePlaybook.

Combine terminal and Git fundamentals, advanced Claude Code, and meta-prompting into one operating loop you can trust, repeat, and lead.

9 steps27 slidesAbout 65 minutesMac + WindowsProgress saved

The operating loop

Orient

Open the right project and inspect the state.

Shape

Turn the outcome into a reviewable brief.

Execute

Work in small, reversible slices.

Verify

Prove the result before committing.

Leave with one verified workflow and the toolkit to repeat it.

Free, step-by-step slide guide

The Claude CodePlaybook.

Combine terminal and Git fundamentals, advanced Claude Code, and meta-prompting into one operating loop you can trust, repeat, and lead.

9 steps27 slidesAbout 65 minutesMac + WindowsProgress saved

The operating loop

Orient

Open the right project and inspect the state.

Shape

Turn the outcome into a reviewable brief.

Execute

Work in small, reversible slices.

Verify

Prove the result before committing.

Leave with one verified workflow and the toolkit to repeat it.

Before you begin

Build the operating system around Claude Code, not just a collection of tricks.

Keep a terminal and Claude Code open beside this guide. You will build the workflow while you learn it.

Bring one low-risk task

Choose something useful enough to care about, but safe enough to inspect, revise, and discard while learning.

1A bounded project folder and clean Git checkpoint
2A concise CLAUDE.md with working agreements
3The meta-prompting command and planning skills installed
4A brief and plan with observable acceptance criteria
5A verified diff, focused commit, and context reset decision

The guide

Move from a safe project folder to a verified, reusable AI workflow.

Step 1 of 9 · 5 min

Choose a low-risk practice project and make sure the terminal is operating inside it.

Open the right project

Claude Code starts with the folder you launch it from. That folder defines the first trust boundary, so location is the first decision in every session.

Do this

1Choose an existing practice project or create a new folder for low-risk work. Do not begin in your entire home folder.
2Open Terminal on macOS or PowerShell on Windows.
3Use pwd on macOS or Get-Location on Windows to see where you are.
4Use cd to enter the project, then list the files and confirm the folder name before continuing.

Remember: If the folder contains secrets, production data, or unrelated personal files, choose a safer practice folder.

macOS / Linux

pwd
ls
cd path/to/your-project
pwd

Windows PowerShell

Get-Location
Get-ChildItem
Set-Location path\to\your-project
Get-Location

Step 1 checkpoint

Confirm the workspace boundary

You are done when

Your terminal shows the intended project folder, and you can name what Claude should and should not touch.

Step 2 of 9 · Mental model

Record a clean checkpoint before Claude changes anything.

Git makes AI work inspectable and reversible

Git turns every change into something you can inspect, compare, keep, or reverse. It is the workspace's audit trail, not just a tool for programmers.

Inspect

git status

Compare

git diff

Verify

tests + browser

Record

focused commit

Step 2 of 9 · 7 min

Record a clean checkpoint before Claude changes anything.

Record the state before Claude changes it

Do this

1Run git status. If Git says this is not a repository, run git init once.
2Review the files before staging. Make sure secrets and generated folders are excluded.
3Create a checkpoint commit only if the starting work is ready to save.
4Run git status again. Know whether you are starting clean or intentionally carrying existing changes.

Remember: Do not use git add . until you understand everything it would stage. Specific paths make the checkpoint easier to trust.

Checkpoint commands

git status
# Run this only if the folder is not already a repository:
git init

# Review before staging:
git add [specific-files]
git commit -m "Checkpoint before Claude Code"
git status

Step 2 checkpoint

Can you recover the starting point?

You are done when

You can see the starting state in git status and have a recoverable checkpoint for the practice task.

Step 3 of 9 · 6 min

Launch Claude inside the project, inspect permissions, and begin with a read-only orientation.

Start with orientation, not implementation

Claude Code can read files, edit them, and run commands. A good leader gives it enough authority for the task while keeping irreversible actions behind an explicit approval.

Do this

1Run claude --version to confirm Claude Code is available, then run claude to start an interactive session.
2Review the workspace trust prompt carefully. Trust only the project you intentionally opened.
3Run /permissions. Keep destructive commands, deployments, pushes, credentials, and production access behind approval.
4Ask Claude to read the project and explain its current state without making changes.

Start the session

claude --version
claude

First message

Read this project without changing anything.

Explain:
1. What it does
2. How it is organized
3. How to run and test it
4. Any risks or missing setup you see

Cite the files that support your answer.

Step 3 checkpoint

Claude understands the project without changing it

You are done when

Claude can describe the project, and no file changed during the orientation pass.

Step 4 of 9 · Mental model

Create a concise CLAUDE.md that carries your working agreements into every session.

Put durable context in the right layer

A prompt guides one task. CLAUDE.md holds the facts and rules Claude should remember every time it enters this project.

This taskPrompt + conversationWhat changes right now

This project./CLAUDE.mdCommands, architecture, conventions, definition of done

Every project~/.claude/CLAUDE.mdYour personal working preferences

Step 4 of 9 · 8 min

Create a concise CLAUDE.md that carries your working agreements into every session.

Write the instructions you should not repeat

Do this

1Run /init and review what Claude proposes. If CLAUDE.md already exists, ask for improvements instead of replacing it.
2Keep project purpose, verified commands, architecture facts, conventions, safety boundaries, and definition of done.
3Remove generic advice and anything you cannot verify. Keep the file concise and resolve conflicting instructions.
4Run /memory and confirm the intended CLAUDE.md is loaded.

Starter CLAUDE.md

# Project

## Purpose
- [What this project does and who it is for]

## Working agreements
- Explain the plan before making a large change.
- Never delete data, deploy, or push without explicit approval.
- Keep changes focused on the requested outcome.

## Commands
- Develop: [project command]
- Test: [project command]
- Build: [project command]

## Definition of done
- The requested behavior works.
- Relevant checks pass.
- The final response lists changed files, verification, and remaining risks.

Step 4 checkpoint

Claude can find the project's working agreements

You are done when

CLAUDE.md contains specific, verifiable instructions and /memory shows that Claude loaded it.

Step 5 of 9 · 7 min

Two commands + two skills

Install the prompt and planning toolkit

The pack separates prompt design from execution. That gives you a reusable brief you can review before an implementation session spends time or changes files.

Choose your system

/create-prompt

Shape a brief

/run-prompt

Reuse a brief

create-meta-prompts

Build prompt chains

create-plans

Make atomic plans

Note: The pack stores reusable prompts inside the current project's prompts folder so the work can travel with the project.

01
Download and unzip the pack
Download claude-meta-prompting.zip, find it in Downloads, and double-click it. macOS creates a claude-meta-prompting folder beside the zip.
02
Open your Claude configuration folder
In Finder, press Command + Shift + G, type ~/.claude, and press Return.
03
Install the commands
Move the two .md files from the pack's commands folder into ~/.claude/commands. If commands does not exist, move the entire commands folder into ~/.claude.
04
Install the skills
Move the create-meta-prompts and create-plans folders into ~/.claude/skills. If skills does not exist, move the entire skills folder into ~/.claude.
05
Confirm Claude can see them
Return to Claude Code and type /create-prompt. If it appears in the command menu, the install worked. Restart Claude Code if this is the first skills folder you created.

Step 5 checkpoint

The new command appears in Claude Code

You are done when

/create-prompt appears in Claude Code, and you know where the installed command and skill files live.

Step 6 of 9 · Mental model

Use meta-prompting and plan mode to clarify outcome, scope, constraints, and verification before implementation.

Separate shaping the work from doing the work

Advanced work usually fails from an unclear finish line, not a weak model. Planning makes assumptions and verification visible while changes are still cheap.

Idea

What might we do?

/create-prompt

Clarify the brief

/plan

Inspect and sequence

Execute

One verified slice

Step 6 of 9 · 9 min

Use meta-prompting and plan mode to clarify outcome, scope, constraints, and verification before implementation.

Turn a fuzzy idea into a brief you can inspect

Do this

1Run /create-prompt followed by a real task. Answer only questions that materially change the work.
2Read the saved prompt. Add the user outcome, in-scope files, constraints, non-goals, and evidence required for completion.
3Start plan mode with /plan for a large change. Ask Claude to inspect the project before proposing edits.
4Approve the plan only when each task has a concrete verification method.

Start the meta-prompt

/create-prompt How might we add a clear empty state to the customer dashboard?

The work should match the existing design system, include a useful next action, work on mobile, and be verified in the browser.

Plan-mode request

/plan

Read the saved brief and inspect the relevant project files. Propose the smallest implementation plan that satisfies the brief. For every task, name the files, expected behavior, verification, and stop conditions. Do not edit yet.

Step 6 checkpoint

The finish line is observable

You are done when

You have a saved brief and an approved plan whose completion can be proven, not merely claimed.

Step 7 of 9 · 8 min

Let Claude work, but keep each loop bounded by an observable result.

Execute one reviewable slice at a time

A plan is not a handoff into a black box. Short loops let you correct direction before the diff, context, and cost become hard to reason about.

Do this

1Give Claude the approved brief and let it complete one coherent slice at a time.
2When a decision is ambiguous, tell Claude what evidence to gather before choosing.
3Interrupt early when the work drifts. State what to preserve, what to change, and how you will judge the next pass.
4After each slice, inspect the changed files and run the narrowest relevant check.

Execution brief

Implement the approved plan for the dashboard empty state.

Before editing:
1. Read CLAUDE.md and the relevant dashboard files.
2. Restate the acceptance criteria.
3. Show me the files you expect to change.

While working:
- Keep the change focused.
- Run the relevant checks.
- Stop and ask before any destructive action or major architecture change.

When finished:
- Verify the behavior at desktop and mobile sizes.
- Show me the diff summary, checks run, and any remaining risks.

Step 7 checkpoint

One slice works before the next begins

You are done when

One meaningful slice works, its diff is understandable, and the relevant check passes before the next slice begins.

Step 8 of 9 · Mental model

Extend Claude only when the next decision needs evidence the project folder cannot provide.

Add context only when it closes a named gap

Screenshots make visual quality inspectable. MCP can bring in external systems. Both are useful because they add evidence, but every new connection also expands context and trust.

Project files

Screenshot

One MCP source

Claude Code

Reason with the evidence

Reviewable output

Diff, checks, rendered result

Step 8 of 9 · 8 min

Extend Claude only when the next decision needs evidence the project folder cannot provide.

Use a screenshot or one narrow MCP connection

Do this

1For visual work, paste a screenshot, drag in an image, or provide its file path. Ask Claude to compare the rendered result against it.
2For external data or actions, choose one approved MCP server that solves a specific gap. Start with local scope and the narrowest permissions.
3Keep credentials out of the repository. Review a project .mcp.json before approving it.
4Run /mcp to confirm connection status, test one read-only action, and document how to disable the server.

Remember: Do not add MCP because it is available. Add it when the task has a named information or action gap that the connection closes.

Visual review

Compare the current page with the attached reference.

List the three most important visible gaps first. Then fix them in order.

After each pass, verify:
- hierarchy and spacing
- mobile behavior
- keyboard focus and contrast
- no horizontal overflow

Do not call it complete until you have checked the rendered page.

MCP boundary

I want to connect one MCP server for this project.

Before changing configuration:
1. Explain exactly what data and actions the server can access.
2. Recommend the narrowest scope and permissions that satisfy this task.
3. Keep credentials out of version control.
4. Show me how to disable or remove the server.

Wait for my approval before installing or authenticating it.

Step 8 checkpoint

The extra access has a specific job

You are done when

Claude used one necessary source of external evidence, and you can explain its scope, permissions, and removal path.

Step 9 of 9 · Mental model

Close the loop with evidence, a focused commit, and a clean context decision.

A final answer is a report. Evidence is the proof.

Claude's final message is a report, not proof. The proof is the diff, passing checks, rendered behavior, and a workspace state you can explain.

Inspect

status + diff

Run

tests + build

Observe

real behavior

Record

focused commit

Reset

/compact or /clear

Step 9 of 9 · 8 min

Close the loop with evidence, a focused commit, and a clean context decision.

Inspect, verify, commit, then choose the next context

Do this

1Run git status and review the diff. Remove unrelated changes and look for secrets, generated files, or unsupported claims.
2Run the tests, checks, build, and user-facing verification named in the brief and CLAUDE.md.
3Stage specific files and commit only the verified slice. Push or deploy only when that external action is explicitly intended.
4Use /compact when you want to continue the same task with more room. Use /clear when starting a genuinely new conversation.
5Use claude -p only after the manual workflow is stable and the output is bounded, reviewable, and safe to automate.

Pre-commit review

Review the work before I commit it.

1. Show git status and summarize the diff.
2. Run the relevant tests, type checks, lint, and build commands from CLAUDE.md.
3. Verify the user-facing behavior, including mobile if this is UI work.
4. Flag unsupported claims, skipped checks, security concerns, or unrelated changes.
5. If everything passes, propose a concise commit message. Do not commit or push yet.

Bounded automation example

git diff --cached | claude -p "Review this staged diff for correctness, security concerns, missing tests, and unrelated changes. Return findings only; do not modify files."

Step 9 checkpoint

You can explain every changed file

You are done when

The diff is focused, required checks pass, the commit contains only intended files, and the next session starts with an intentional context choice.

The Claude CodePlaybook.

The Claude CodePlaybook.

Build the operating system around Claude Code, not just a collection of tricks.

Move from a safe project folder to a verified, reusable AI workflow.

Open the right project

Create a Git safety net

Start Claude Code with boundaries

Give the project durable instructions

Install the meta-prompting toolkit

Turn the idea into an executable brief

Execute in small, reviewable loops

Add visual context or one MCP connection

Verify, commit, and reset deliberately

Open the right project

Confirm the workspace boundary

Git makes AI work inspectable and reversible

Record the state before Claude changes it

Can you recover the starting point?

Start with orientation, not implementation

Claude understands the project without changing it

Put durable context in the right layer

Write the instructions you should not repeat

Claude can find the project's working agreements

Install the prompt and planning toolkit

Download and unzip the pack

Open your Claude configuration folder

Install the commands

Install the skills

Confirm Claude can see them

The new command appears in Claude Code

Separate shaping the work from doing the work

Turn a fuzzy idea into a brief you can inspect

The finish line is observable

Execute one reviewable slice at a time

One slice works before the next begins

Add context only when it closes a named gap

Use a screenshot or one narrow MCP connection

The extra access has a specific job

A final answer is a report. Evidence is the proof.

Inspect, verify, commit, then choose the next context

You can explain every changed file