A Day in the Life: Complete Claude Code Session Walkthrough

Part 7 of 7 · Series: Building Your AI Developer Handbook · GitHub

The Scenario

You’re building a password reset feature. User enters email → gets a reset link → clicks link → enters new password. Standard flow. Medium complexity.

Let’s walk through every step using the full workflow — as if you’re looking over the shoulder of someone who built this system.

“Show me your workflow and I’ll show you your output quality.”

Before You Even Type

Claude loads automatically in the background:

✓ ~/.claude/CLAUDE.md loaded           ← the global handbook
✓ .claude/CLAUDE.md loaded             ← project rules (TypeScript, pnpm)
✓ memory/MEMORY.md scanned             ← all lessons and preferences

Enter fullscreen mode Exit fullscreen mode

You haven’t typed anything yet. Claude already knows:

• Feature-based folder structure
• State management ladder
• No mocking the database
• No AI attribution in commits
• No useCallback without profiler evidence

“A doctor who reviews your file before you enter the room is more useful than one who asks ‘so, remind me who you are?'”

Step 1: /status — Confirm the Setup

/status

Enter fullscreen mode Exit fullscreen mode

Model:   claude-sonnet-4-6
Effort:  normal
Plugins: security-guidance ✓

Enter fullscreen mode Exit fullscreen mode

Thirty seconds. Sometimes the wrong model loads due to overload fallback. Sometimes a plugin fails silently. This check costs 30 seconds and prevents a surprise 30 minutes later.

“A pilot’s first action after sitting in the cockpit isn’t to take off. It’s to check all instruments are reading correctly.”

Step 2: /cost — Baseline

/cost
→ Tokens used: 2,847 | Estimated cost: $0.004

Enter fullscreen mode Exit fullscreen mode

Note this number. You’ll compare it later before the expensive code review step. A surprise spike means something went wrong.

Step 3: /plan — Design Before Coding

/plan

Build a password reset feature:
- User enters email on /forgot-password
- System sends a reset link (token, expires in 1 hour)
- User clicks link → /reset-password?token=xxx
- User enters new password
- Token validated, password updated, token invalidated

Enter fullscreen mode Exit fullscreen mode

Claude responds with a plan — no code yet:

Proposed approach:

1. DB: Add password_reset_tokens table
   - id, user_id, token (hashed), expires_at, used_at

2. API:
   - POST /api/auth/forgot-password — generate token, send email
   - POST /api/auth/reset-password  — validate token, update password

3. UI:
   - /features/auth/ForgotPasswordForm.tsx
   - /features/auth/ResetPasswordForm.tsx
   - usePasswordReset.ts hook

4. Tests:
   - Unit: token generation/validation logic
   - Integration: full flow with real test DB
   - No E2E (not a critical path)

Questions before I start:
- Email provider?
- Token length and hashing algorithm preference?
- Should used tokens be deleted or marked used?

Enter fullscreen mode Exit fullscreen mode

“A plan that asks questions is more valuable than a plan that assumes answers.”

You answer the questions. You approve the plan. Only now does coding start.

Step 4: Code — Supervised Implementation

Claude implements. Because the preferences are loaded, it automatically:

• Creates /features/auth/ForgotPasswordForm.tsx — not /components/ForgotPassword.tsx
• Uses useState for form fields, TanStack Query for the API calls
• Writes catch blocks that console.error and surface toasts
• Does NOT add useCallback to handlers without profiler evidence

You watch. You redirect if something drifts.

“Supervision isn’t distrust — it’s how you catch small course corrections before they become major detours.”

Step 5: pnpm test — The Blocking Gate

pnpm test

Enter fullscreen mode Exit fullscreen mode

Must exit 0. Not “mostly passing.” Not “the one failing test is unrelated.” All tests pass.

If they fail:

FAIL features/auth/usePasswordReset.test.ts
  ✗ handles expired token correctly
    Expected: { error: 'Token expired' }
    Received: { error: undefined }

Enter fullscreen mode Exit fullscreen mode

You stop. You fix it. You run tests again. Only when green do you proceed.

“You wouldn’t send a letter before proofreading it. You wouldn’t ship code before testing it. The test gate is the proofread.”

Step 6: /cost — Delta Check

/cost
→ Tokens used: 18,492 | Delta: +15,645 | Cost: $0.026

Enter fullscreen mode Exit fullscreen mode

~15k tokens for a medium feature is normal. If you saw +80k tokens, that’s a red flag — Claude may have scanned the whole codebase or looped a tool call. Investigate before spending on the code review.

Step 7: /code-review — Bug and Design Audit

/code-review

Enter fullscreen mode Exit fullscreen mode

Claude reviews the diff — not the whole codebase, just what changed:

⚠ HIGH  usePasswordReset.ts:47
  Token comparison uses === (timing attack surface).
  Fix: use crypto.timingSafeEqual() instead.

ℹ LOW   ResetPasswordForm.tsx:23
  Loading state not shown during submission.
  Fix: disable submit button while isPending is true.

Enter fullscreen mode Exit fullscreen mode

“A second pair of eyes catches what the first pair stopped seeing. Even if both pairs belong to the same AI.”

Fix the HIGH immediately. Decide on the LOW.

Step 8: /simplify — Readability Cleanup

/simplify

Enter fullscreen mode Exit fullscreen mode

Code review found bugs. Simplify finds clutter:

usePasswordReset.ts: resetForm() called in 3 places — extract to reset handler
ForgotPasswordForm.tsx: inline styles on 2 elements — move to className

Enter fullscreen mode Exit fullscreen mode

This pass doesn’t hunt for bugs. It hunts for code that works but could be cleaner.

“A code review checks if the bridge is safe. Simplify checks if the bridge is elegant. Both matter.”

Step 9: /code-review –comment — Post to PR

/code-review --comment

Enter fullscreen mode Exit fullscreen mode

Posts findings as inline comments directly on the GitHub PR. Reviewers see the notes in context — right on the lines that matter.

PR is ready for human review.

The Full Session, Compressed

Step Command Time 1 /status 30 sec 2 /cost 5 sec 3 /plan 10–20 min 4 Code varies 5 pnpm test 2–5 min 6 /cost 5 sec 7 /code-review 5–10 min 8 /simplify 5–10 min 9 /code-review --comment 2 min

Total gate overhead: ~30–40 minutes. Defects reaching production: dramatically fewer.

“The gates don’t slow you down. They stop you from having to go back.”

What This Looks Like Without the Workflow

Without the gates, the same feature might take 45 minutes to implement. But:

• The token comparison vulnerability reaches production ← timing attack
• A test failure was “unrelated” and got ignored ← it wasn’t
• Folder structure drifted from feature-based ← scattered files
• PR has no inline notes ← reviewer has no context
• Session cost 3x more ← nobody checked the delta

“Fast and wrong is slower than right the first time.”

Your Turn — Start With Three Things

You don’t need to implement this entire workflow today. Start here:

1. Create ~/.claude/CLAUDE.md with four rules: think first, simplicity, surgical changes, goal-driven
2. Create one memory file — next time Claude does something you didn’t want, write it down
3. Add the test gate — never proceed past failing tests

The rest follows naturally.

The Full Series

Part Topic Part 1 Overview — the full system Part 2 The Handbook (CLAUDE.md) Part 3 The Memory System Part 4 Battle Scars as Rules (Feedback Files) Part 5 Your Coding DNA (User Preferences) Part 6 Context is King (Project + Reference Files) Part 7 A Day in the Life (Complete Walkthrough)

All workflow files on GitHub

“Discipline is not the enemy of creativity. It’s the foundation that lets creativity build something that lasts.”

Thanks for following the series. If you build your own version of this workflow, share it — I’d love to see how others adapt these ideas.