Session 2: Workflows

In Session 1 you learned how to write clear, specific prompts and iterate on responses. This session builds on those skills by organizing them into repeatable workflows: structured exploration before coding, feature building with clear requirements, and systematic debugging. You will practice each one against your own codebase.

Explore-Plan-Code-Commit Workflow

What it is: The single most important habit for AI-assisted development. Instead of asking Claude to write code immediately, you break the work into four phases: Explore (read and understand the existing code), Plan (have Claude propose an approach before writing anything), Code (implement the agreed-upon plan in focused steps), and Commit (review the diff and commit with a clear message). This prevents the most common failure mode — Claude jumping to implementation before understanding your codebase’s conventions, which produces code that works in isolation but clashes with everything around it. For trivial changes (a one-line fix, renaming a variable), you can skip straight to Code. The full four-phase process pays off when the task touches multiple files, unfamiliar code, or requires choosing between approaches.

Demo prompt:

I need to add a new feature. Let's use the full Explore-Plan-Code-Commit
workflow.

Step 1 — Explore: Read the files in src/services/ and explain how
services are structured in this project. What patterns do they follow
for error handling, logging, and dependency injection?

Step 2 — Plan: Based on those patterns, outline how you would add a
new NotificationService. Don't write code yet, just describe the approach.

I'll review the plan before we move to Step 3 (Code) and Step 4 (Commit).

Try it now: Pick a directory in your project you have not touched recently. Ask Claude to explore it and explain the patterns. Then ask it to plan a small addition (a new method, a new file) that follows those patterns. Review the plan before letting it write any code.

Go deeper: Explore-Plan-Code-Commit — the full workflow with examples for each phase and tips for when to reset context.

Building Features with AI

What it is: When building a feature, the quality of Claude’s output depends on two things: the quality of your requirements (which you practiced in Session 1) and the structure of your workflow. A good feature prompt includes: what the feature does (in specific, testable terms), where the code goes (which files and directories), constraints (follow existing patterns, use specific libraries, no external dependencies), and verification (run the tests after). Numbering your requirements gives Claude a checklist to satisfy. Referencing existing code with @filename tells it to match your conventions rather than invent its own. For large features, break the work into steps and verify each one before moving on.

Demo prompt:

I need to add input validation to the user registration endpoint.
Read @src/api/users.ts to understand the current structure, then:

1. Add validation for email (must be valid format)
2. Add validation for password (min 8 chars, at least one number)
3. Return a 400 with specific error messages for each validation failure
4. Follow the same error response format used by other endpoints

Run the tests after making changes.

Try it now: Identify a small feature or enhancement in your project backlog. Write a prompt that includes numbered requirements, at least one @file reference to existing code, a constraint about following existing patterns, and a verification step. Compare the output to what you would get from “add validation to the registration endpoint.”

Go deeper: Prompting Patterns — reusable prompt structures for feature building, including templates for endpoints, components, and services.

Finding and Fixing Bugs

What it is: Claude is most effective at debugging when you give it concrete evidence: an error message, a stack trace, a failing test, or a description of expected vs. actual behavior. The debugging workflow mirrors Explore-Plan-Code-Commit: reproduce the bug (get a failing test or error output), feed Claude the evidence (paste the error plus point it at the relevant code with @filename), diagnose (ask for the root cause, not just a patch), fix (one bug at a time, running tests after each fix), and verify (confirm the fix and check for similar issues elsewhere). Fixing bugs one at a time is more reliable because later failures sometimes disappear once earlier ones are resolved.

Demo prompt:

Here is my test failure:

  UserService#createUser
    validates email format (FAILED)
    Expected: 400 status with error message
    Got: 500 status with "Cannot read property 'match' of undefined"

Read @src/services/UserService.ts and @test/services/UserService.test.ts.
Identify the root cause — what is undefined and why? Fix it, then run
the tests.

Try it now: Find a bug, a TODO, or a known rough edge in your codebase. If you do not have a failing test, write one that exposes the problem. Then feed Claude the failure output along with @file references to the relevant source code. Ask it to diagnose the root cause and fix it. Run the tests to verify.

Go deeper: Debugging Workflow — the full debugging workflow with examples for test failures, stack traces, logic errors, and performance issues.

Managing Your Session

What it is: Structured workflows like EPCC generate long conversations. When Claude’s responses start feeling slower or less focused, your context window is filling up. Use /compact to compress the conversation while keeping key findings, or /clear when switching to an unrelated task. Between EPCC phases, /compact focus on the plan we agreed to preserves your plan while freeing space for implementation.

Demo prompt:

/compact focus on the implementation plan we agreed to and the
three files we identified for changes. Forget the exploration
details — I just need the plan going forward.

Try it now: Run /context to see how full your context window is. If you have been working through this session’s exercises, it may already be substantial. Try /compact with instructions focused on what you need for your next task. Compare the response quality before and after compacting.

Go deeper: Sessions & Context — managing context, resuming sessions, and the phase-compact pattern for long workflows.

Key Takeaways

• Always explore before coding. Asking Claude to read existing code first produces output that matches your project’s conventions.
• Break features into steps and verify each one. Small, verifiable increments are more reliable than asking for everything at once.
• When debugging, give Claude evidence (error messages, stack traces, failing tests) rather than descriptions from memory.
• Fix bugs one at a time and run tests after each fix. Later failures often resolve once earlier ones are fixed.
• Use @filename references to point Claude at existing code — this is the single highest-leverage habit for matching your project’s conventions.
• Number your requirements so Claude has a checklist to satisfy, and add explicit constraints (“follow existing patterns,” “no new dependencies”) to keep output on track.
• Use /compact between EPCC phases to free context while preserving your plan, and /clear when switching to an unrelated task.

Practice

Put these workflows into action with the Foundations Scenarios — practice building features, exploring codebases, and debugging using the patterns from Sessions 1 and 2.