DEV Community: Abhishek Pandit

A Day in the Life: Complete Claude Code Session Walkthrough

Abhishek Pandit — Wed, 10 Jun 2026 15:15:04 +0000

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

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

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

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

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

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?

"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

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 }

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

~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

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.

"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

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

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

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:

Create ~/.claude/CLAUDE.md with four rules: think first, simplicity, surgical changes, goal-driven
Create one memory file — next time Claude does something you didn't want, write it down
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.

Context is King: How Project Files and Templates Keep Claude on Track

Abhishek Pandit — Wed, 10 Jun 2026 15:09:19 +0000

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

The Context Problem

Every developer switches between projects. Each project has its own setup, ongoing decisions, deadlines, and "why did we do it this way" history.

"Imagine a consultant who works with five different clients. Every Monday they need a full briefing — 'who are you, what are we building, why did you make that decision last week?' — before they can do anything useful. Now imagine if that briefing happened every single day."

That's Claude without project context files.

Project files and reference files give Claude the backstory before it starts. Not the code — Claude can read the code. The context behind the code.

The Project Context File

---
name: project_auth_rewrite
type: project
---

Auth system rewrite in progress. Deadline: 2026-06-20.

**Why:** Legal flagged session token storage as non-compliant
with new data regulations.

**How to apply:** Scope decisions favor compliance over
ergonomics until the audit is complete.

Every project file has three parts:

The fact — what happened or what was decided
The why — motivation (deadline, constraint, stakeholder, incident)
How to apply — what should change about Claude's behavior

"A sign that says 'do not open this door' is easy to ignore. A sign that says 'do not open this door — last person who did triggered the fire suppression system' is not."

The Why is what lets Claude judge edge cases. Without it, rules are followed blindly. With it, Claude can ask: "does this new situation actually trigger the same concern?"

What Goes in a Project File

Good content:

Architectural decisions and the trade-offs that led to them
Ongoing work — who is doing what, by when (use absolute dates, not "next Thursday")
Why a particular library was chosen over alternatives
A constraint not obvious from the code (legal, performance, security)

Bad content — don't memorize these:

Already exists	Don't put in project file
Code patterns	Read the code
File structure	Read the filesystem
Git history	Run `git log`
Things that change daily	Too stale too fast

"A map is useful. A map from three years ago of a city that's been rebuilt is worse than no map — it gives you false confidence."

Project files decay. The Why field tells you whether a memory is still load-bearing or just historical noise.

When Project Files Shine

Without a project file:

Session start:
"So just to re-explain the context — we're mid-sprint on auth,
there's a compliance deadline, the approach was chosen because..."

With a project file:

[Claude reads: auth rewrite, deadline 2026-06-20,
compliance is the priority, no ergonomics shortcuts]

You: "should we add a caching layer to the token check?"
Claude: "Given the compliance requirement, caching token validation
would complicate the audit trail — skip it until after the audit."

Claude makes the right call without being told why. That's context working.

The Reference File

---
name: reference_template_location
type: reference
---

Template path: ~/.claude/templates/ts-react-project.md

Usage: at new repo init, copy to .claude/CLAUDE.md.
Fill in [Project Name] and Architecture section.

Note: verify library versions at each project init — they drift.

Reference files are simple: where to find things that live outside the project.

Where bugs are tracked (Linear, Jira, GitHub Issues)
Where design assets live (Figma, Storybook)
Where dashboards are (Grafana, Datadog)
Where templates live (local filesystem paths)

"A good assistant knows where the filing cabinet is. They don't memorize every document inside it — they just know where to look."

The Template System

The reference file above points to a template: ~/.claude/templates/ts-react-project.md.

This is a complete project-level CLAUDE.md for TypeScript/React projects. New repo workflow:

mkdir -p .claude
cp ~/.claude/templates/ts-react-project.md .claude/CLAUDE.md
# Fill in: [Project Name], Architecture section

Instantly Claude knows: TypeScript project, pnpm, Zod for validation, TanStack Query for server state, Zustand for client state. All project-level rules in place before you write a single line.

"A chef's mise en place — everything in its place before cooking starts. Setup done right means execution can be clean."

The warning: "Verify library versions are still current at each project init — they drift." A template from six months ago might reference a library that's had a major version bump. Always check.

The Full Context Hierarchy

When Claude starts a session, it reads context in layers:

1. Global CLAUDE.md       ← who you are, universal rules
2. Project CLAUDE.md      ← this stack, this project's rules
3. Memory files (index)   ← lessons, preferences, project context
4. The code itself        ← what's actually been built

"General law → company policy → department rules → today's meeting agenda. Each layer is more specific than the last."

Writing Your First Project File

You don't write project files upfront. Write them when you notice you're re-explaining context.

Trigger: You find yourself starting a session with "so just to re-explain the context..."

Action: Stop. Write a project file:

---
name: project_[feature_name]
type: project
---

[What's being built, current status]

**Why:** [The motivation — constraint, deadline, stakeholder ask]

**How to apply:** [What Claude should do differently because of this]

Add it to MEMORY.md. Next session, Claude already knows.

Key Takeaway

Project files carry the backstory — decisions, motivations, and constraints not in the code but shaping every line of it.

Reference files carry the map — where to find things outside the project.

Together they turn a new session from a cold start into a warm handoff.

"Context isn't just helpful. Without it, the right answer and the wrong answer can look identical."

Next: Part 7 — A Day in the Life: Complete Claude Code Session Walkthrough

All workflow files on GitHub

Your Coding DNA: The Three Files That Shape Every Line Claude Writes

Abhishek Pandit — Wed, 10 Jun 2026 15:03:52 +0000

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

What User Preference Files Are

Feedback files record mistakes. User preference files record who you are as a developer.

"Two carpenters given the same wood will build different tables — same tools, same materials, different hands, different results. User preference files are what make Claude build YOUR table, not the generic one."

Three preference files cover the three decisions you make on every single feature:

How you organize code — architecture
How you manage data — state management
How you verify correctness — testing

Preference 1: Architecture — Feature-Based Folders

/features/auth/
  AuthForm.tsx
  AuthForm.test.tsx
  useAuth.ts
  auth.types.ts
/components/ui/
  Button.tsx
  Input.tsx

Two competing philosophies:

Layer-based (what most tutorials teach):

/components/
/hooks/
/types/
/tests/

Feature-based (what this workflow uses):

/features/auth/
/features/payment/
/features/dashboard/

"In a layer-based structure, adding a 'login' feature means touching four separate folders. In a feature-based structure, you touch one."

Layer-based groups files by what they are. Feature-based groups by what they do.

The difference becomes obvious when you need to delete a feature:

Layer-based: hunt through /components, /hooks, /types, /tests — find and delete each file individually, hope you didn't miss anything
Feature-based: delete the /features/auth/ folder. Done.

The shared primitives rule:
Buttons, inputs, modals — building blocks shared across all features — live in /components/ui/ only. Never copy a Button into a feature folder.

"The kitchen is shared. Your desk is yours."

No barrel exports on large modules:

// Avoid on large modules — slows TS server, hurts tree-shaking
export { AuthForm } from './AuthForm'
export { useAuth } from './useAuth'

Import directly from the file. The extra path is worth it.

Preference 2: State Management — The Ladder

1. useState    — local UI state, one component
2. Zustand     — shared client state across components  
3. TanStack Query — anything from a server

"State management is like choosing a vehicle. A bicycle for the corner shop, a car for the city, a truck for cross-country. The mistake is driving a truck to the corner shop."

Step 1: useState — Start Here, Always

const [isOpen, setIsOpen] = useState(false)

If state is local to one component and doesn't need to be shared — useState is perfect. Simple, readable, zero overhead.

"Don't add complexity until complexity is required."

Step 2: Zustand — Shared Client State Only

// Good: client-only shared state
const useUIStore = create((set) => ({
  sidebarOpen: false,
  toggleSidebar: () => set((s) => ({ sidebarOpen: !s.sidebarOpen })),
}))

When state needs sharing across multiple components and it's client-only — not from a server — Zustand is right. Modal state, sidebar flags, user preferences.

The hard rule: never put server data in Zustand.

// WRONG — server data in Zustand
const useUserStore = create((set) => ({
  user: null,
  fetchUser: async () => {
    const user = await api.getUser()
    set({ user })
  }
}))

This creates a second copy of the data. They get out of sync. You add refresh logic. Then invalidation logic. Then loading states. You've just rebuilt TanStack Query, badly.

Step 3: TanStack Query — Anything From a Server

// RIGHT — server data belongs here
const { data: user } = useQuery({
  queryKey: ['user'],
  queryFn: () => api.getUser()
})

Loading states, error states, caching, background refetching, cache invalidation — all free.

"Zustand is a drawer. TanStack Query is a real-time window to the outside world. Don't put windows in drawers."

Preference 3: Testing — The Pyramid

Unit tests:        pure logic, no side effects, no internal mocks
Integration tests: real database, real data flows
E2E tests:         critical paths only (login, checkout, core flow)

"Testing is like quality control on a car assembly line. You don't test the whole car every time you tighten one bolt. You test the bolt, then the subsystem, then the full car before it ships."

Unit Tests — Pure Logic Only

// Perfect unit test — pure function, no external dependencies
test('formats currency correctly', () => {
  expect(formatCurrency(1000, 'USD')).toBe('$1,000.00')
})

Belongs here: validators, formatters, reducers, pure utility functions.
Doesn't belong here: anything touching a database, API, filesystem, or network.

Integration Tests — Real Database, Always

"A flight simulator is great for training. But the first time you land a real plane, you discover the simulator lied about the crosswind."

Mocked database tests pass even when the real migration fails. Integration tests must use a real test database. Yes, they're slower. That's the point — they're testing real behavior.

E2E Tests — Critical Paths Only

E2E opens a real browser and clicks through the UI. Most accurate, slowest, most brittle.

"You don't test every road in the country to verify the highway exists. You just drive the highway."

E2E for: login, checkout, the one flow that makes you money. Not for edge cases — those belong in unit and integration tests.

How These Three Work Together

When Claude builds a new feature with these files loaded, it automatically:

Creates /features/feature-name/ — not scattered layer folders
Starts with useState, reaches for Zustand only if state needs sharing
Writes unit tests for logic, integration tests for data layer
Never adds barrel exports or server data to Zustand

You don't say any of this. It's already loaded.

"The best rule is one you never have to repeat."

Key Takeaway

User preference files transform Claude from a generic code generator into a collaborator that builds code the way you would build it.

Architecture: feature-based, co-located, no barrel exports
State: useState → Zustand → TanStack Query, never server state in Zustand
Testing: unit for logic, real DB for integration, E2E for critical paths only

Three files. Every feature they shape.

Next: Part 6 — Context is King: How Project Files and Templates Keep Claude on Track

All workflow files on GitHub

Battle Scars as Rules: Inside the Feedback Files

Abhishek Pandit — Wed, 10 Jun 2026 14:52:10 +0000

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

What Are Feedback Files?

Every rule in a feedback file was born from either a mistake or a win.

"The safety rules on a construction site weren't written by lawyers. They were written in blood — each rule marks the spot where something went wrong."

A feedback file looks like this:

**Rule:** [what to do or not do]
**Why:** [the incident or reason behind it]
**Apply:** [when and where this kicks in]

The Why is the most important part. Without it, you follow rules blindly. With it, you can judge edge cases — "does this situation actually trigger this rule, or is it different enough?"

Here are 8 real feedback rules, what they say, and the story behind each one.

Rule 1: Never Mock the Database in Tests

Rule: Integration tests must hit a real database. No mocks.
Why: Mocked tests passed. Prod migration broke.
Apply: Never mock the DB layer in integration tests.

"A fire drill with a fake fire teaches you nothing about real smoke."

Tests were passing. The mock was set up correctly. The code looked clean. But the mock didn't simulate a specific edge case in the actual database — a constraint that only exists in production. The migration ran, the constraint triggered, and production broke while all tests were green.

The lesson: mocks are lying witnesses. They tell you what you told them to say, not what the real system does.

For unit tests (pure functions, no side effects) — mocks are fine. For integration tests that touch data — always use a real test database.

Rule 2: No useCallback/useMemo by Default

Rule: Don't add useCallback/useMemo unless:
  1. The child is wrapped in React.memo
  2. React Profiler shows a real re-render problem
Why: Premature optimization clutters code and rarely helps.
Apply: Strip default memoization in code review.

"Putting armor on a bicycle because 'it might get hit by a car' doesn't make it safer — it just makes it heavier and harder to ride."

Developers add useCallback/useMemo "just in case" — wrapping every handler by default. Result: harder-to-read code with reference tracking overhead, solving performance problems that don't exist.

React's default re-render behavior is fast. Most re-renders take under 1ms. The profiler will tell you when something is actually slow. Optimize then — not before.

Rule 3: Never Write API Tokens Into Config Files

Rule: Never write tokens, passwords, or secrets into settings.json or any config file.
Why: Config files are plaintext. Plaintext gets committed. Committed secrets get stolen.
Apply: Use .zshrc, secrets managers, or wrapper scripts instead.

"Writing your password on a sticky note is convenient until someone walks past your desk."

settings.json files are convenient — set them once, forget. But they're plaintext files that often end up in git. Bots scan GitHub constantly for exposed credentials. An exposed key can be exploited within minutes.

The safe pattern:

Config files → key names only, no values
.env → values, never committed, in .gitignore
Shell profile (.zshrc) → exported env vars that tools pick up automatically

Rule 4: CLAUDE.md — Global vs Project

Rule: Global CLAUDE.md = universal rules only. Stack-specific rules go in project CLAUDE.md.
Why: Hardcoding React/TypeScript rules globally broke Python project sessions.
Apply: Reject stack-specific content in global CLAUDE.md.

"The company handbook says 'be on time.' It doesn't say 'use a blue pen' — that's a department rule."

One CLAUDE.md tried to cover everything: TypeScript rules, React patterns, pnpm commands, Zod schemas. Then a Python project opened. Suddenly Claude was suggesting pnpm commands for a pip project.

The fix: two levels. Global = who you are. Project = what this stack is.

Rule 5: Dependency Protocol — Check Before You Add

Rule: Before any new dependency:
  1. bundlephobia → check bundle size impact
  2. pnpm audit → check known vulnerabilities
  3. Repo activity → last commit within 1 year?
Why: Dependencies are long-term liabilities.
Apply: Include audit command whenever suggesting pnpm add.

"Adopting a pet is easy. Feeding it for 10 years is the commitment you're actually making."

Every dependency you add is a dependency you maintain — security patches, breaking changes, version conflicts. A package that solves a problem today but gets abandoned tomorrow is a liability.

Three checks, 2 minutes, every time. The cost of skipping: potentially hours debugging a supply chain issue.

Rule 6: Error Handling — Never Swallow Silently

Rule: Every catch block must at minimum console.error(err).
      User-visible errors go to toast or error boundary.
Why: Silent failures look like missing features — hardest bugs to diagnose.
Apply: Never write catch (e) { /* ignore */ }

"A smoke alarm with dead batteries doesn't mean there's no fire. It means you won't know about it until it's too late."

catch (e) {} — empty catch blocks are the most dangerous pattern in production code. An error occurred. Something failed. And you told the computer to pretend nothing happened.

The user sees a broken UI with no error message. You see no logs. The error is invisible. You spend three hours debugging something that would have taken three seconds with a console.error.

Minimum: log it. Better: show a toast. Best: let it bubble to an error boundary.

Rule 7: Skip Removed Tools Silently

Rule: If a tool has been deliberately removed, never suggest or reference it.
Why: The removal was intentional. Asking about it is friction.
Apply: Skip silently, continue with available tools.

"If a chef removes an ingredient from their kitchen, they don't want the sous-chef asking 'but what about the cilantro?' every time they cook."

Sometimes you remove an integration — for cost, privacy, or preference. The decision was deliberate. You don't want Claude asking about it or suggesting you re-add it every session.

Rule 8: Separate Work and Personal Git Identities

Rule: Always use the correct git identity (work vs personal) for the project context.
      Never add AI co-author lines to commits.
Why: Work and personal projects need separate attribution.
Apply: Confirm user.email matches context before every commit.

"You wouldn't sign a personal letter with your work signature."

Two contexts, two identities. The wrong email in a commit doesn't just look sloppy — it can create audit trail problems. The co-author rule: commit history should reflect human authorship decisions.

Building Your Own Feedback Files

---
name: feedback_rule_name
description: one-line summary
metadata:
  type: feedback
---

**Rule:** [what Claude should do or not do]

**Why:** [the story — what happened or what you observed]

**How to apply:** [when does this rule trigger]

The trigger for writing a new one: if you've corrected Claude twice for the same thing, it belongs in a feedback file.

"The first mistake is an accident. The second is a pattern. The third is a choice."

Key Takeaway

Feedback files are the institutional memory of your AI workflow. They capture hard-won knowledge that would otherwise reset every session. Each rule has a story. Each story prevents a future mistake.

Next: Part 5 — Your Coding DNA: The Three Files That Shape Every Line Claude Writes

All workflow files on GitHub

Teaching an AI to Never Forget: How the Memory System Works

Abhishek Pandit — Wed, 10 Jun 2026 14:45:23 +0000

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

The Goldfish Problem

By default, every Claude session starts completely fresh. No memory of last week's conversation. No memory of the rule you explained three times. No memory of the mistake you made together and fixed together.

"Imagine if your doctor forgot everything about you every time you walked into the clinic. You'd spend 10 minutes re-explaining your history before they could help you."

That's Claude without memory files.

The memory system fixes this. It's a folder of plain markdown files that Claude reads at the start of every session — carrying forward the lessons, preferences, and decisions that would otherwise reset.

Where Memory Lives

~/.claude/projects/your-project/memory/
  MEMORY.md              ← the index (loads automatically every session)
  feedback_rules.md      ← lessons from mistakes
  user_preferences.md    ← how you like to work
  project_context.md     ← what's happening in the project right now
  reference_links.md     ← where to find things outside the project

Think of it like a filing cabinet:

MEMORY.md is the table of contents — one line per memory, always loaded
Each individual file is a folder in the cabinet — loaded when relevant

The Four Types of Memory

1. Feedback Memory — "Rules Born From Mistakes"

"Every rule in a safety manual was written in response to an accident." — Aviation saying

These files store corrections and confirmations. Every time Claude does something you didn't want — or something you want it to repeat — that lesson becomes a feedback file.

Example: You discover mocked database tests passed while a real production migration failed. You tell Claude: "never mock the database in tests." That becomes a rule that applies to every future session.

**Rule:** Integration tests must hit a real database.
**Why:** Mocked tests passed; prod migration broke.
**Apply:** Never suggest mocking the DB layer in tests.

2. User Memory — "How You Think and Work"

"A good assistant doesn't just do tasks — they understand how their manager thinks."

These files capture your preferences, style, and philosophy — folder structure, state management approach, testing philosophy. Claude reads these and adjusts its suggestions to match your way of working.

3. Project Memory — "What's Happening Right Now"

"Context switches are expensive. The more context you can offload to a file, the less you re-explain every session."

These files track ongoing work — what feature is being built, why a particular decision was made, what the deadline is. Without these, you start every session re-explaining the backstory.

4. Reference Memory — "Where to Look Things Up"

Simple pointers to external resources:

"Bug tracker is at Linear project INGEST"
"Design tokens are in Figma file XYZ"
"Oncall dashboard is at grafana.internal/api-latency"

"A good assistant knows where the filing cabinet is. They don't memorize every document — they know where to look."

The MEMORY.md Index

# Memory Index

- [No DB mocks](feedback_db_testing.md) — integration tests use real DB; mocks missed prod migration bug
- [State ladder](user_state_management.md) — useState→Zustand→TanStack Query; no server state in Zustand
- [Current feature](project_auth_sprint.md) — building OAuth login, deadline 2026-06-20

This is the only file that loads automatically on every session. Intentionally short — one line per memory.

"A good index tells you whether you need to open the drawer. You shouldn't need to read the whole drawer just to find out."

Each line has three parts:

The name (links to the full file)
A one-line hook (enough to know if it's relevant right now)

How It Works in Practice

Session 1 (no memory):

You: "How should I structure the auth feature?"
Claude: [gives generic advice based on training data]
You: "I use feature-based folders, not layer-based"
Claude: [adjusts, gives feature-based advice]

Same question, Session 2 (with memory):

[Claude reads: "feature-based folders — /features/auth/, /features/payment/"]
You: "How should I structure the auth feature?"
Claude: [immediately gives feature-based advice — no re-explaining needed]

What NOT to Put in Memory

Memory files are for things that aren't in the code itself.

Already exists	Don't memorize
Code patterns	They're in the code
Git history	`git log` knows
File structure	Read the filesystem
Debugging solutions	Fix is in the commit

"A post-it note on your monitor says 'check Figma before coding UI.' It doesn't copy the entire Figma file onto the post-it."

Memory files decay. The older they are, the more likely they describe something that's changed. The Why field is what tells you whether a memory is still load-bearing.

Starting Your Own Memory System

Start with one file: feedback.md. Every time you correct Claude, add a line:

- Don't use barrel exports in large modules — slows TS server
- Always check bundlephobia before adding a dependency  
- State management order: useState first, Zustand only if shared

Over a few weeks you'll have a precise record of how you like to work. Split into separate files when it gets large. Build the MEMORY.md index.

Key Takeaway

Memory files turn Claude from a stateless tool into a contextual collaborator.

The difference between "Claude that needs re-teaching every session" and "Claude that gets better the more you use it" is a folder of markdown files.

"Experience is just lessons that were written down. Wisdom is lessons that were read again."

Next: Part 4 — Battle Scars as Rules: Inside the Feedback Files

All workflow files on GitHub

Your AI's Employee Handbook: A Deep Dive Into CLAUDE.md

Abhishek Pandit — Wed, 10 Jun 2026 14:44:38 +0000

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

The Problem This File Solves

Imagine hiring a brilliant intern — photographic memory, types 500 words per minute, knows every programming language. But there's a catch: every morning they walk in with zero memory of yesterday. They don't know your name, your project, your rules, or what you told them last week.

That's Claude without a CLAUDE.md file.

CLAUDE.md is the handbook you hand that intern on Day 1. It loads automatically at the start of every session. Claude reads it before doing anything else.

"Rules written down are remembered. Rules spoken once are forgotten." — Every manager ever.

Where This File Lives

~/.claude/CLAUDE.md          ← loads for EVERY project (global)
your-project/.claude/CLAUDE.md  ← loads only for this project

Two levels:

Global = rules about you (who you are, how you work, what you never break)
Project = rules about this codebase (which framework, which patterns, which shortcuts)

Section 1: Who I Am

Senior full-stack engineer. macOS. Read code first.
Verify external API/library behavior with context7 — training data may be stale.

This two-line description changes everything. Claude adjusts its explanations based on who it's talking to. Tell it you're a senior engineer — it skips the basics and goes straight to trade-offs.

It's like the difference between explaining a recipe to a chef versus a 10-year-old. Same recipe. Very different explanation.

The context7 note tells Claude: "Before you answer anything about an external library, go look it up — don't trust your memory."

Section 2: Four Core Principles

1. Think before coding
2. Simplicity first
3. Surgical changes
4. Goal-driven

These four rules prevent the four most common AI coding mistakes.

Think Before Coding — AI models are eager. Ask Claude to "fix the login bug" and it will immediately start editing files — even if it misunderstood the bug. This rule forces Claude to state its assumptions out loud before touching anything.

"A surgeon who cuts before diagnosing is a butcher with a medical degree."

Simplicity First — AI models default to comprehensive. Ask for a button — get a button with loading states, error handling, animations, analytics, and an accessibility wrapper. This rule enforces: write the minimum code that solves the problem.

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away." — Antoine de Saint-Exupéry

Surgical Changes — Claude will "helpfully" clean up adjacent code, rename variables, update unrelated comments. Every change outside the task scope wasn't asked for, wasn't tested for, and could break something unrelated.

"If you ask a cleaner to mop the floor, you don't expect them to rearrange your furniture while they're at it."

Goal-Driven — Define a verifiable success criterion before writing code. "Add a login button" is not a goal. "Users can click the login button and be redirected to the dashboard" is.

"Done means it works, not that you finished typing."

Section 3: Model Rules — Cost Control

Main thread: claude-sonnet-4-6
Sub-agents:  claude-haiku-4-5-20251001  (cheap, fast, simple tasks)
Opus:        only when explicitly asked

Model	Speed	Cost	Best For
Haiku	Fast	Cheap	Search a file, lint, simple edits
Sonnet	Balanced	Moderate	Features, debugging, reviews
Opus	Slower	Expensive	Deep architecture, hard trade-offs

"You don't hire a senior architect to alphabetize your files."

Using Opus for everything is like driving a Formula 1 car to the grocery store. Sub-agents always use Haiku — that one rule cuts session costs by ~40%.

Section 4: The Session Workflow

1. /status   → confirm model
2. /cost     → baseline
3. /plan     → design first, never skip
4. Code
5. pnpm test → BLOCKING
6. /cost     → delta check
7. /code-review
8. /simplify
9. /code-review --comment

This is a pilot's pre-flight checklist.

"Pilots don't skip checklist items because they're in a hurry. The checklist exists because being in a hurry is when mistakes happen."

Each step catches a different failure. Step 5 is blocking — if tests fail, you fix them before proceeding. No exceptions.

Section 5: Universal Rules

Never commit .env

"Your .env file is like your house key. You wouldn't nail it to your front door for strangers to copy."

Bots scan GitHub 24/7 for exposed credentials. An exposed key can be exploited within minutes. Keep .env.example (key names, no values) in the repo. Keep .env only on your machine.

Conventional commits

feat: add login button
fix: correct password validation
chore: update dependencies

"A well-labeled filing cabinet takes 10 seconds to search. A pile of random papers takes 10 minutes."

WCAG 2.1 AA accessibility — every interactive UI must work for screen readers, keyboard-only navigation, and low-contrast displays. Both an ethical standard and a legal requirement in many countries.

Never touch code outside task scope — every change outside scope wasn't reviewed, wasn't tested for, wasn't asked for.

Write Your Own CLAUDE.md

Here's the minimum viable version for a beginner:

# My Claude Handbook

## Who I Am
[Your role, experience level, languages/frameworks you use]

## Rules
1. Ask before assuming anything
2. Write the simplest code that works
3. Never change code I didn't ask you to change
4. Don't say done until I can verify it works

## Never Do
- Commit .env files
- Add features I didn't ask for
- Change files I didn't mention

Start simple. Add rules every time Claude does something you didn't want. Over time, it becomes a precise description of how you work.

Key Takeaway

CLAUDE.md doesn't make Claude smarter. It makes Claude consistent. Consistent with your standards. Consistent with your rules. Consistent whether it's your first session or your hundredth.

"Intelligence without discipline is just chaos at high speed."

Next: Part 3 — Teaching an AI to Never Forget: How the Memory System Works

All workflow files on GitHub

How I Turned Claude Into a Disciplined Senior Developer (Not Just a Fast One)

Abhishek Pandit — Wed, 10 Jun 2026 14:09:11 +0000

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

The Full Series

Part	Title	What you'll learn
1	Overview — the full system	Why discipline matters, how all 7 layers fit together
2	Your AI's Employee Handbook: CLAUDE.md	How to write the file Claude reads every session
3	Teaching an AI to Never Forget	The memory system — lessons that survive sessions
4	Battle Scars as Rules	The 8 feedback rules and the stories behind them
5	Your Coding DNA	Architecture, state management, and testing preferences
6	Context is King	Project context files and the template system
7	A Day in the Life	Complete 9-step session walkthrough with a real feature

All workflow files on GitHub

A plain-English walkthrough of my Claude Code workflow — written so anyone, including students, can understand what's happening and why.

The Problem With AI Coding Tools Out of the Box

AI coding assistants are fast. Dangerously fast.

They write code before they understand the problem. They touch files you didn't ask them to touch. They say "done!" before verifying anything works. They forget everything you told them last session.

Speed without discipline isn't productivity — it's just faster ways to create bugs.

This is the system I built to fix that.

What is Claude Code?

Claude Code is an AI assistant that runs in your terminal — not a chat window. It reads your files, runs your tests, writes and edits code, and operates as a real collaborator inside your project. Think of it as a pair programmer that never sleeps, but needs clear rules to not go rogue.

The files in this walkthrough are the rules I give Claude at the start of every session.

Layer 1 — The Handbook (`~/.claude/CLAUDE.md`)

Every employee gets an onboarding handbook. This file is Claude's.

It loads automatically at the start of every session, regardless of which project I'm in. It tells Claude who it's working with, how to behave, and what it's never allowed to do.

Four Core Principles That Prevent the Most Common AI Mistakes

1. Think before coding
2. Simplicity first
3. Surgical changes
4. Goal-driven

Think before coding — Claude will happily implement the wrong solution perfectly. This rule forces it to state its assumptions and ask when something is unclear, before writing a single line.

Simplicity first — AI models default to comprehensive. Ask for a button, get a button + loading state + error boundary + animation + accessibility wrapper. This rule enforces: write the minimum code that solves the problem. Nothing speculative.

Surgical changes — Claude will refactor your entire codebase if you let it. The rule: touch only what the task requires. Never improve unrelated code.

Goal-driven — Define a verifiable success criterion. Loop until it passes. Don't declare done until the goal is confirmed met — not assumed met.

Layer 2 — Model Rules (The Cost Control System)

Not all AI tasks need the same horsepower.

Main work:   Sonnet   (mid-tier — capable, cost-efficient)
Simple tasks: Haiku   (cheapest — search, lint, single-file edits)
Hard problems: Opus   (most powerful — only when explicitly needed)

Why this matters:

Claude models bill per token — roughly per word of input and output. Three tiers exist at very different price points. Using the most powerful model for every task is like hiring a senior architect to alphabetize your files.

The rule: Haiku for boring sub-tasks (searching files, running checks), Sonnet for real coding work, Opus only when Sonnet genuinely isn't enough. This keeps costs sane without sacrificing quality where it counts.

Layer 3 — The 9-Step Session Workflow

This is the most important part of the whole system.

Every coding session follows this exact sequence:

Step 1 — /status       Confirm which model is loaded and at what effort level
Step 2 — /cost         Snapshot current token spend (baseline before work starts)
Step 3 — /plan         Design the solution BEFORE touching any code
Step 4 — Code          Actual implementation
Step 5 — pnpm test     BLOCKING. All tests must pass. Zero exceptions. Fix failures here.
Step 6 — /cost         Check spend delta (don't burn budget reviewing broken code)
Step 7 — /code-review  AI reviews the diff for bugs and design issues
Step 8 — /simplify     AI cleans up messy code (not bug hunting — readability only)
Step 9 — /code-review --comment   Post review findings as inline GitHub PR comments

Why this order matters:

Imagine building a house by picking up a hammer, building walls, then realizing you skipped the blueprint — so you tear it down and start over. That's what most developers do with AI: prompt, get code, ship, find bugs in production.

Each step in this sequence is a gate that catches a different class of failure:

Plan first catches wrong solutions before any code is written
Tests catch logic bugs — broken behavior
Code review catches design bugs — bad structure, security issues, edge cases missed
Simplify catches readability debt — code that works but nobody can maintain
Second review confirms the cleanup didn't introduce new issues

Skipping any gate means that class of failure makes it further down the pipeline — where it costs more to fix.

Layer 4 — Universal Rules (The Non-Negotiables)

These rules apply to every project, every session, no exceptions.

Never Commit `.env`

Your .env file holds API keys, database passwords, and secrets. Committing it to GitHub means handing those keys to anyone who can view your repository — including strangers, bots, and automated scrapers that watch GitHub 24/7.

The pattern: maintain a .env.example file that shows the shape of your config (key names, no values). Anyone cloning the project knows what to fill in without getting your credentials.

Conventional Commits

feat: add user login flow
fix: correct token expiry check
chore: update dependencies
refactor: extract auth middleware

This naming convention makes git history readable by both humans and machines. Changelogs write themselves. CI pipelines can trigger on feat: commits but skip chore: ones. Future-you can scan three months of history in 30 seconds.

WCAG 2.1 AA Accessibility

Every interactive UI element must meet this accessibility standard. That means: screen readers can navigate it, keyboard-only users can operate it, color contrast is sufficient for low-vision users.

This is both an ethical baseline (your product should work for everyone) and a legal requirement in many countries. It's not optional.

Never Touch Code Outside Task Scope

The single biggest risk when using AI tools. Claude will "helpfully" refactor adjacent code, rename variables for consistency, or update comments in files you never mentioned. Every change outside scope is a change that wasn't reviewed, wasn't tested for, and wasn't asked for.

The rule keeps diffs reviewable and trust maintainable.

Layer 5 — Skills (Specialized Playbooks for Specific Situations)

Skills are structured workflows that Claude invokes when specific situations arise. Instead of improvising, it follows a proven checklist.

Building a new feature?    → brainstorming → architecture decision → written plan → wait for approval
Found a bug?               → systematic-debugging skill
UI change?                 → frontend-design → accessibility audit → performance check
Adding a dependency?       → security audit first, always

Why not just ask Claude directly?

Because improvised AI work skips steps. Without structure, Claude jumps straight to implementation. The /brainstorming skill, for example, forces Claude to explore the problem space — alternative approaches, trade-offs, edge cases — before suggesting a solution.

Without it: technically correct solution to the wrong problem. With it: you catch misalignment before writing a single line.

Skills turn Claude from an improviser into a disciplined practitioner who follows proven processes for high-stakes situations.

Layer 6 — Token Hygiene (Performance and Cost Management)

Claude's "memory" within a session is like RAM — it's limited, and what you put in it matters.

`.claudeignore`

Every project gets this file:

node_modules/
dist/
.git/
*.log
coverage/
.next/
build/

node_modules/ alone can contain millions of lines of code. If Claude reads those files, it wastes its context window on irrelevant third-party code and charges you for every token. This file tells Claude "don't look here" — same idea as .gitignore.

`/compact` Command

After a long debugging session, Claude may have read 50 files, run 20 commands, and accumulated thousands of lines of context. That context slows responses and costs money to process.

/compact summarizes the session history, keeps the essential context, and frees space — like clearing browser tabs when your machine starts slowing down.

Targeted Reads

Never ask Claude to scan the entire codebase. Always point it at specific files. This keeps context clean, responses fast, and costs low.

Layer 7 — Memory (Lessons That Survive Sessions)

By default, Claude remembers nothing between sessions. Every conversation starts fresh. This is the biggest limitation of AI tools — you re-explain preferences, re-establish context, re-teach lessons from past mistakes.

The memory system fixes this. A folder of markdown files stores things Claude should remember across all future conversations.

Examples from Real Sessions

"Never mock the database in tests"
Mocked tests passed. Real production migration failed. The mocks didn't reflect actual DB behavior. Lesson: integration tests must hit a real database — no shortcuts.

"No useCallback/useMemo by default"
Premature optimization adds noise to every component. Only add memoization after a profiler confirms there's an actual re-render problem. Assumption-based optimization makes code harder to read and maintain.

"State management ladder: useState → Zustand → TanStack Query"

useState: local UI state, one component
Zustand: shared client state (modal flags, user preferences)
TanStack Query: anything from a server (fetching, caching, mutations)

Never put server/async state in Zustand. This rule prevents the classic bug: stale server data living in a client store, getting out of sync with what the API actually returns.

"Feature-based folder structure"

/features/auth/
  AuthForm.tsx
  AuthForm.test.tsx
  useAuth.ts
  auth.types.ts

Everything related to a feature lives together. When you delete a feature, you delete one folder — not hunt through six directories for scattered files.

Putting It All Together

Here's what a typical session looks like in practice:

Open terminal, navigate to project
Claude loads the handbook (CLAUDE.md) automatically
Run /status — confirm correct model
Run /cost — note starting spend
Run /plan — describe the task, Claude designs the solution before coding
Review and approve the plan
Claude implements, using Haiku sub-agents for simple search/read tasks
Run tests — if any fail, fix before moving on
Check /cost — note delta
Run /code-review — AI reviews the diff
Run /simplify — clean up the code
Run /code-review --comment — post findings to the PR

Total time per feature: slower than just prompting Claude and shipping. But the defect rate is dramatically lower, the code is actually maintainable, and nothing has ever reached production broken because a test gate was skipped.

The One-Paragraph Summary

Most AI coding tools are fast but undisciplined — they write code before understanding the problem, touch things they shouldn't, and forget everything between sessions. This workflow treats Claude like a disciplined senior developer: give it a handbook (CLAUDE.md), have it follow a process (9-step session workflow), use specialist playbooks for specialist problems (skills), remember lessons from past work (memory), and control costs by matching tool power to task complexity (model tiers). The result is an AI collaborator that's genuinely faster than working alone — without the "it worked on my machine" false confidence.

Built and refined over multiple projects. The system evolves — but the discipline doesn't.

The Full Series

Part	Title	What you'll learn
1	Overview — the full system	Why discipline matters, how all 7 layers fit together
2	Your AI's Employee Handbook: CLAUDE.md	How to write the file Claude reads every session
3	Teaching an AI to Never Forget	The memory system — lessons that survive sessions
4	Battle Scars as Rules	The 8 feedback rules and the stories behind them
5	Your Coding DNA	Architecture, state management, and testing preferences
6	Context is King	Project context files and the template system
7	A Day in the Life	Complete 9-step session walkthrough with a real feature

All workflow files on GitHub

Next: Part 2 — Your AI's Employee Handbook: A Deep Dive Into CLAUDE.md

All workflow files on GitHub

DEV Community: Abhishek Pandit

A Day in the Life: Complete Claude Code Session Walkthrough

The Scenario

Before You Even Type

Step 1: /status — Confirm the Setup

Step 2: /cost — Baseline

Step 3: /plan — Design Before Coding

Step 4: Code — Supervised Implementation

Step 5: pnpm test — The Blocking Gate

Step 6: /cost — Delta Check

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

Step 8: /simplify — Readability Cleanup

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

The Full Session, Compressed

What This Looks Like Without the Workflow

Your Turn — Start With Three Things

The Full Series

Context is King: How Project Files and Templates Keep Claude on Track

The Context Problem

The Project Context File

What Goes in a Project File

When Project Files Shine

The Reference File

The Template System

The Full Context Hierarchy

Writing Your First Project File

Key Takeaway

Your Coding DNA: The Three Files That Shape Every Line Claude Writes

What User Preference Files Are

Preference 1: Architecture — Feature-Based Folders

Preference 2: State Management — The Ladder

Step 1: useState — Start Here, Always

Step 2: Zustand — Shared Client State Only

Step 3: TanStack Query — Anything From a Server

Preference 3: Testing — The Pyramid

Unit Tests — Pure Logic Only

Integration Tests — Real Database, Always

E2E Tests — Critical Paths Only

How These Three Work Together

Key Takeaway

Battle Scars as Rules: Inside the Feedback Files

What Are Feedback Files?

Rule 1: Never Mock the Database in Tests

Rule 2: No useCallback/useMemo by Default

Rule 3: Never Write API Tokens Into Config Files

Rule 4: CLAUDE.md — Global vs Project

Rule 5: Dependency Protocol — Check Before You Add

Rule 6: Error Handling — Never Swallow Silently

Rule 7: Skip Removed Tools Silently

Rule 8: Separate Work and Personal Git Identities

Building Your Own Feedback Files

Key Takeaway

Teaching an AI to Never Forget: How the Memory System Works

The Goldfish Problem

Where Memory Lives

The Four Types of Memory

1. Feedback Memory — "Rules Born From Mistakes"

2. User Memory — "How You Think and Work"

3. Project Memory — "What's Happening Right Now"

4. Reference Memory — "Where to Look Things Up"

The MEMORY.md Index

How It Works in Practice

What NOT to Put in Memory

Starting Your Own Memory System

Key Takeaway

Your AI's Employee Handbook: A Deep Dive Into CLAUDE.md

The Problem This File Solves

Where This File Lives

Section 1: Who I Am

Section 2: Four Core Principles

Section 3: Model Rules — Cost Control

Section 4: The Session Workflow

Section 5: Universal Rules

Write Your Own CLAUDE.md

Key Takeaway

How I Turned Claude Into a Disciplined Senior Developer (Not Just a Fast One)

The Full Series

The Problem With AI Coding Tools Out of the Box

What is Claude Code?

Layer 1 — The Handbook (~/.claude/CLAUDE.md)

Layer 1 — The Handbook (`~/.claude/CLAUDE.md`)

Never Commit `.env`

`.claudeignore`

`/compact` Command