C9PG
Claude Code Docs

The Six-Step Loop

This tutorial mirrors the workflow chapter, but with a single concrete task: add input validation to an existing form or API handler.

EXPLORE

Prompt:

text
Read the current validation flow and explain what happens today when invalid input arrives.
Do not edit yet.

What you should see: a read-only explanation of the current behavior and the likely files involved.

PLAN

Prompt:

text
Create a detailed plan for adding the missing validation with the smallest possible change.

What you should see: a plan that names the handler, the validation location, and the test or repro that should fail first.

RED

Prompt:

text
Write the smallest failing verification for invalid input. Run it and confirm the failure.

What you should see: a clearly failing test or repro that proves the gap.

GREEN

Prompt:

text
Implement the validation so the existing RED check turns GREEN.

What you should see: the change stays close to the failing verification instead of branching into unrelated cleanup.

REVIEW

Prompt:

text
/simplify focus on error handling

What you should see: a post-implementation review that checks whether the validation path is clear, safe, and not duplicated unnecessarily.

SHIP

Prompt:

text
Commit the validation change with a descriptive message and summarize the verification that passed.

What you should see: a commit backed by evidence, not a vague claim that the fix works.

Advanced: Match the Starter Files

The starter project turns this tutorial into committed repo structure.

The starter CLAUDE.md workflow contract

Starter CLAUDE.md.template
markdown
# Project Working Rules

## Default workflow
- For features, bug fixes, and behavior changes: explore → plan → RED → GREEN → review.
- Use Plan Mode (Shift+Tab or /plan) for multi-file or ambiguous work.
- No production behavior change until a failing verification artifact exists.
- After every production code change, run the smallest relevant verification.
- Before stopping, run the full repo gate.

## Verification policy
- Backend/domain logic: failing automated test first.
- UI work: failing E2E, screenshot expectation, or repro script first.
- Migrations/ops/config: failing smoke/repro command first.
- After implementation: run /simplify before opening a PR.

## Scope discipline
- No opportunistic refactors outside the task unless explicitly asked.
- Keep diffs small. Explain any unavoidable architectural fallout.
- One logical change per commit.

## Project commands
- Test (targeted):  pnpm test -- <target>
- Lint:             pnpm lint
- Typecheck:        pnpm typecheck
- Fast gate:        pnpm lint && pnpm typecheck
- Full gate:        pnpm test && pnpm lint && pnpm typecheck

## Architecture notes
<!-- Add 2-3 sentences about key architectural decisions -->
<!-- Add test framework, ORM, router, state management specifics -->
<!-- Add naming conventions or file organization rules -->

The starter scoped rule files

Starter frontend-testing.md
md
---
globs: ["apps/web/**", "src/components/**", "src/pages/**"]
---
# Frontend Testing Rules
- Use Playwright for E2E tests. Use React Testing Library for component tests.
- Before implementing a UI component, create a failing E2E or screenshot test.
- Visual changes must be verified with the Chrome extension or screenshot comparison.
- Never mock fetch in component tests; use MSW (Mock Service Worker) instead.
- Prefer testing user-visible behavior over implementation details.
Starter backend-testing.md
md
---
globs: ["services/api/**", "src/server/**", "src/lib/**"]
---
# Backend Testing Rules
- Write failing request/response or domain tests before handler changes.
- Use real database in integration tests (test containers), not mocks.
- Every new endpoint needs: unit test, integration test, error case test.
- Test error responses and edge cases, not just happy paths.
- Use factories for test data, not inline object literals.

How the starter project maps the loop

Loop stepStarter file or surfaceWhat it does
ExploreCLAUDE.mdMakes explore-first the default repo expectation
PlanCLAUDE.mdReinforces Plan Mode for ambiguous or multi-file work
REDtest-forward skill + require-test-first.shRequires a failing verification and a RED token before source edits
GREENrequire-test-first.sh + run-related-tests.shAllows implementation only after RED exists, then gives fast test feedback
ReviewCLAUDE.md + /simplifyMakes review an expected step, even though it is not fully hook-enforced
ShipStop hook in settings.jsonBlocks completion until the repo gate is complete

The exact starter skill is shown in Using Skills. The exact hook code is shown in Your First Hook.

Commands and Prompts Worth Repeating

text
/plan
/simplify focus on error handling
/context
/compact retain the TDD state, current test failures, and the validation plan

When you want the full reference behind this tutorial, go back to Daily Workflow.

If you want the next layer of tooling around this loop, continue with Review and Debug Commands.