My 4-step workflow with Claude Code: plan, build, understand and continue

The most common mistake when coding with AI is asking for everything at once: "build the sign-up flow with validation, the endpoint and the tests". Claude Code tries, fills the gaps with assumptions, and hands back a lot of code you then read line by line to find out what it decided for you. A staged Claude Code workflow works better: decide first, then build, then understand what was built, and finally leave everything ready to carry on. It works the same for frontend, backend, web apps, scripts or ecommerce.

Each stage uses a different Claude Code skill. A skill is a folder with a SKILL.md instruction file that Claude loads when you call it with /name. This is not a list of skills: it is the order I use them in, and why. If you want another skill that changes how Claude works, we also wrote about Ponytail, which makes it write less code.

The example: a sign-up form

To keep this concrete, the whole post follows one case: adding a sign-up form to a web app, with validation in the frontend, a backend endpoint that creates the account, and automated tests covering both. It is small, but it touches all three layers and has enough edge cases to go wrong if nobody thinks them through.

The whole workflow

The diagram shows four stages in a column, each with its skill and what it delivers, and an arrow from the last one back to the first:

1. Plan with /grill-me: every decision answered before any code.
2. Build with /caveman: code and tests, with short replies.
3. Understand with /wait-what: you can explain the diff in your own words.
4. Continue with /handoff: a summary to open a fresh chat, which starts again at step 1 with the next feature.

Step 1: plan with /grill-me

What it does

Matt Pocock's /grill-me changes the order of the conversation: instead of writing code, Claude interviews you one branch of the decision at a time until nothing is ambiguous. The result is a plan with the rules written down, not a file full of hidden assumptions.

Install

npx skills@latest add mattpocock/skills

When the installer asks which skills you want, select grill-me and also grilling: grill-me now only calls grilling, which is where the interview lives. For Claude Code the repository README now recommends the plugin from the official marketplace, which updates itself and includes the Matt Pocock skills used here except claude-handoff:

claude plugin install mattpocock-skills@claude-plugins-official

Use one method, not both, or you get every skill twice.

The questions it asks in the example

/grill-me I want to add a sign-up form with validation,
an endpoint that creates the account, and automated tests.

These are the kinds of questions that come back, grouped by topic:

• Fields: name, email and password, or a phone number too? Which are required? Do users have to accept terms?
• Validation rules: minimum password length? Is the email format checked only in the browser or on the server too? Does the rule live in one place?
• Error handling: what does the user see if the email already exists? And if the server fails? Does the form keep its data after an error?
• Edge cases: are Ana@Mail.com and ana@mail.com the same account? What about leading or trailing spaces? What if someone double-clicks "Create account"?
• What must not break: the existing login, existing accounts, the form's analytics events? Which tests already exist and have to keep passing?

When you finish answering, the rules are written down. That text is what you hand Claude in step 2.

Step 2: build with /caveman

What it does

While building you read a lot of Claude's replies, and most come with a greeting, a recap and your request restated. Julius Brussee's Caveman strips that: short sentences, the answer first, and code, commands and errors untouched. For a security warning or an irreversible action it switches back to full sentences.

Install

claude plugin marketplace add JuliusBrussee/caveman
claude plugin install caveman@caveman

In the example

With the plan from step 1 you ask Claude to build in parts: validation first, then the endpoint, then the tests. One key point of the plan was that the rule lives in one place, used by both the form and the endpoint:

type Signup = { email: string; password: string };

export function validateSignup({ email, password }: Signup) {
  const errors: Partial<Record<keyof Signup, string>> = {};
  const normalized = email.trim().toLowerCase();
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(normalized)) errors.email = "Invalid email";
  if (password.length < 12) errors.password = "At least 12 characters";
  return { normalized, errors };
}

And when a test fails, instead of three paragraphs you get something like:

Test fails: endpoint compares email unnormalized.
Use normalized from validateSignup before lookup. Fix:

What it really saves

Caveman saves output tokens, meaning what Claude writes. The project's current measurement, ten development questions on Claude Opus 5.5, is 6,983 output tokens with no instruction, 4,119 with /caveman and 2,693 with /ultracave. The same README notes that against simply asking for concise answers, /caveman cuts 3% more and /ultracave 35% more, and that its rules cost about 1,160 input tokens.

Over a whole session the saving is smaller than any of those percentages, because most of what you pay for is input: the files Claude reads, command output and the conversation history.

When not to use it

When you need to understand why the code is the way it is, not only what it is. If Claude makes a design decision you did not expect, a two-line reply will not explain it. Turn it off with stop caveman or move to step 3. It is also a poor fit when Claude is writing for someone else: docs, a PR description, an email.

Step 3: understand with /wait-what

What it does

If you do not understand code that will stay in your project, you are not done. /wait-what, also by Matt Pocock, tells Claude to stop and re-explain its last message with the context you are missing, in plain language: ASD-STE100 Simplified Technical English.

Install

npx skills add mattpocock/skills --skill wait-what

If you installed Matt's plugin in step 1, you already have it.

In the example: a confusing explanation against a clear one

You ask how the endpoint handles a duplicate email and Claude replies:

"The handler normalizes the email pre-lookup to avoid casing collisions and returns 409 on conflict to preserve client retry semantics."

All correct, and useless if you do not know the terms. You type:

/wait-what

And the answer becomes:

"Before the endpoint checks if the email exists, it changes the email to lowercase and removes the spaces. Thus Ana@Mail.com and ana@mail.com are the same account. If the account exists, the endpoint sends code 409, which means conflict, not error 500. Then the form shows 'That email already has an account' and not 'Something went wrong'."

Now you can review the diff knowing what to look for, and explain it to whoever reviews your PR.

Step 4: continue with /handoff

Why it is needed

After planning, building and reviewing, the conversation is long: the context is full, Claude starts to forget early decisions and every reply costs more. The healthy move is a fresh chat for the next feature, say email confirmation, without losing what was decided.

Matt Pocock's claude-handoff

claude-handoff writes a summary of the conversation and also launches a background agent with claude --bg that carries on immediately. It is in development: it is not in the plugin, and the author warns it can change or disappear without notice.

npx skills add mattpocock/skills --skill claude-handoff

If you prefer something stable, Matt's plugin includes handoff, which only writes the handoff document to your system's temp folder.

Alternative: your own /handoff

I prefer something simpler: a summary to copy and paste into a fresh chat, with no files and no agents. Create ~/.claude/skills/handoff/SKILL.md with this content:

---
name: handoff
description: Summarise the current conversation as one block ready to paste into a new chat and continue the work.
argument-hint: "[what the next chat will focus on]"
disable-model-invocation: true
---

Write a summary to continue this conversation in a new chat.
Do not create files or launch agents: return the summary as a single
code block the user can copy.

Include, in this order:

1. Goal: what we are doing and why, in two sentences.
2. State: what is done and verified, and what is not.
3. Decisions: what was decided and why, so it is not argued again.
4. Files and commands: relevant paths, branches and commands, verbatim.
5. Next step: the next concrete action.
6. Open items: open questions and anything not verified.

Rules:

- 300 words at most.
- Do not copy code that is already in files; give the path.
- Remove API keys, passwords and personal data.
- If the user passed arguments, focus the summary on them.

The disable-model-invocation: true line means it only runs when you type /handoff. Claude Code picks up the new skill without a restart; if the skills folder did not exist when the session started, run /reload-skills.

In the example, the summary would say that sign-up already validates in the form and the endpoint with the same function, that the email is normalized, that a duplicate email returns 409, which tests pass, and that the next step is email confirmation. Paste it into a fresh chat and go back to step 1.

How it adapts to your kind of project

Frontend

In step 1 the questions move to states and accessibility: loading, error, empty, focus after submit, error messages tied to each field. In step 3, /wait-what earns its keep on effects and unexpected re-renders, where a short explanation tends to fall short.

Backend

Step 1 covers contracts and failure: what the endpoint returns in each case, what happens with duplicate requests, what changes in the database and how it rolls back. In step 2, ask for the contract tests first and the implementation second.

Ecommerce

On a Shopify theme, step 1 asks which settings and blocks the section needs, what the merchant should be able to edit, and what must not break: checkout, analytics events and the sections the store already uses. In step 2, check each change with shopify theme check and test locally with shopify theme dev before pushing anything.

A checklist for your next project

Copy this into your notes or your task description:

[ ] 1. Plan: /grill-me until no question is left open
[ ]    Rules, errors, edge cases and "what must not break" written down
[ ] 2. Build: /caveman, in parts, with tests for each part
[ ]    Run the tests and the linter after each part
[ ] 3. Understand: /wait-what on any decision you cannot explain
[ ]    Review the whole diff before accepting it
[ ] 4. Continue: /handoff and open a fresh chat for the next feature

Frequently asked questions

Do I have to use all four skills every time?

No. On a small, clear change you can skip step 1, and a short session does not need step 4. The order is what matters: do not build before deciding, and do not accept code you do not understand.

Does it work with any language or framework?

Yes. The skills change how Claude works, not the code it produces. The same workflow fits a React app, a Python API, an automation script or a Shopify theme.

Do skills cost tokens when I am not using them?

A little. The name and description take some context so Claude knows they exist, and the full content loads only when used. Caveman, which changes the style of the whole session, does carry a fixed cost of about 1,160 input tokens according to its README.

Where do installed skills live?

Your own go in ~/.claude/skills/<name>/SKILL.md for all your projects, or .claude/skills/<name>/SKILL.md for one repository. npx skills installs into the current project by default; add -g for every project. Plugins are managed by Claude Code.

Is it safe to install other people's skills?

As safe as any code you run: a skill tells Claude what to do with your permissions. Read the SKILL.md before installing and use only the author's official repository.

Keep learning

I post short tips on Claude Code, Shopify and web development on Instagram. Follow @lgmdevtl to see this workflow running on video.