Planning Mode: Think Before You Build
For features longer than a few lines, use /plan before building. This tells Claude Code to think through the implementation, identify what files need to change, and show you the approach — without making any edits yet.
claude
> /plan I want to add a user notification system.
Users should be able to receive notifications when:
- Someone comments on their post
- They get a new follower
- A post they liked gets edited
Notifications should be stored in the database,
marked as read/unread, and returned via a
GET /api/notifications endpoint. The frontend
should show an unread count in the nav.
# Claude Code will:
# - Map out what files need to be created/modified
# - Identify dependencies and potential conflicts
# - Ask clarifying questions if the spec is ambiguous
# - Give you a chance to adjust before any code is written
> Looks good. Build it.
The /plan step catches problems early. If Claude Code identifies a conflict with your existing architecture, better to know that in 30 seconds than to untangle it after 200 lines of generated code.
💡
Ask Claude Code questions during planning. "What would you need to change to make this backwards-compatible?" or "Is there a simpler approach that doesn't require a new database table?" Claude Code's planning analysis is often the most valuable part of the whole session.
Building a Complete API Endpoint
The key to getting good results on full features: be specific about inputs, outputs, edge cases, and what the feature must NOT do. Vague specs produce vague code.
claude "Build a POST /api/invites endpoint:
Input:
{
email: string (required, must be valid email)
role: 'admin' | 'editor' | 'viewer' (required)
message: string (optional, max 500 chars)
}
Behavior:
- Only users with admin role can call this endpoint
- Check if the email already has an account — if so,
return 409 with message 'User already exists'
- Create an Invite record in the database with a
secure random token (expires in 72 hours)
- Send an invitation email using the email service
in src/services/email.ts
- Return 201 with { inviteId, expiresAt }
Error handling:
- Invalid email: 400
- Invalid role: 400
- Unauthorized: 403
- Email send failure: still return 201 but log the error
Write the endpoint, the Prisma schema update, and
tests. Follow the patterns in src/routes/users.ts."
Building a Frontend Component
Same approach, different output. The more you describe the behavior and constraints, the better the component.
claude "Build a NotificationBell component for
the nav bar:
Behavior:
- Shows a bell icon with a red badge showing
unread count
- Badge hidden when count is 0
- Clicking the bell opens a dropdown showing
the last 10 notifications
- Each notification shows: type icon, message,
timestamp (relative: '2 hours ago')
- Clicking a notification marks it as read and
navigates to the relevant page
- 'Mark all as read' button at the top of the dropdown
Data: Use the useNotifications hook from
src/hooks/useNotifications.ts (create it if it doesn't exist).
The hook should fetch from GET /api/notifications.
Styling: Match the existing nav components in
src/components/Nav.tsx. Use Tailwind classes.
Write the component and the hook. Include tests
for the mark-as-read logic."
The Iteration Workflow
Claude Code rarely gets everything perfect on the first pass. The iteration workflow is the most important skill in this course:
# Don't start a new session — keep iterating
# in the same conversation
> That's close, but the dropdown closes when I click
outside of it, which is correct, but it doesn't
close when I click on a notification. Fix that.
> The timestamp format is fine but I want it to show
the full date if the notification is more than
7 days old. Update just that logic.
> I changed my mind about the position — the dropdown
should open to the left instead of right so it
doesn't go off screen on small viewports.
> The tests are passing but the TypeScript compiler is
complaining: [paste the error]. Fix it.
# Claude Code maintains context of everything
# it built — you're iterating, not starting over
ℹ️
Iteration is not failure. Professional Claude Code use looks like: rough description → first build → 3-5 rounds of refinement → code review → ship. The first build is never the final build. Don't expect it to be.
💻 Day 4 Exercise
Build a Complete Feature Using Only Natural Language
Pick a feature from your project backlog — something you've been meaning to build but haven't started. You're going to build the full thing: API and frontend.
- Write a clear feature spec: inputs, outputs, behavior, edge cases, what it must NOT do. Be as specific as a real requirements doc.
- Run
/plan with your spec. Read the plan carefully. Ask at least one question before building.
- Approve the plan and watch Claude Code build it. Resist the urge to write any code yourself.
- When it's done, run your test suite. If tests fail, tell Claude Code and let it fix them.
- Iterate: make at least 3 refinements based on looking at the actual implementation.
- Do a final code review pass:
claude "review this feature for quality and correctness"
Day 4 Summary
- Use
/plan before building anything significant. Review and refine the approach before a single line of code is written.
- Specific specs produce specific code. Include inputs, outputs, edge cases, and constraints in your description.
- Iterate in the same conversation — Claude Code remembers everything it built and can refine without starting over.
- The full loop: plan → build → review → iterate → ship. Expect 3-5 rounds of iteration. That's normal.
Challenge
Build something you've always wanted in your project but kept pushing off because it felt too large. Use everything from this week: CLAUDE.md for context, /add for the relevant files, /plan before building, iteration until it's right, and a final security review. The goal: a complete, tested feature you'd be comfortable shipping — built without writing the implementation code yourself.