Ask First, Build Later: An Interview Workflow for Claude Code

I wanted caching for an API. Claude built a solution with Redis, but I needed in-memory with invalidation. So delete everything, start over.

The real problem isn’t Claude. It’s the guessing.

Why Claude Doesn’t Ask

Claude Code has an undocumented tool called AskUserQuestion.¹ It interrupts the workflow for multiple-choice questions. This way I decide before implementation, not after through correction.

But Claude rarely uses the tool. When facing ambiguity, it decides on its own and builds what seems plausible.

Getting Claude to Ask

The questioning behavior can be controlled via the CLAUDE.md file. My rules:

## Interview Behavior

For new features or changes with decision space:
- ALWAYS clarify requirements before writing code
- Use AskUserQuestion proactively for:
  - Multiple possible implementations
  - Unclear scope
  - Decisions affecting other system parts
- Ask 1-2 questions per round
- Ask about edge cases and error behavior
- Ask what explicitly should NOT happen

The rules go in the repository root or globally under ~/.claude/CLAUDE.md.

The Interview Command

These rules improve questioning behavior, but for multi-step tasks I use a custom slash command. It lives under .claude/commands/interview.md:

You are a requirements engineer. Your ONLY task: Interview me.

## Context
$ARGUMENTS

## Rules
1. Use ONLY the AskUserQuestion tool
2. Ask 1-2 questions per round
3. Ask about:
   - Technical decisions
   - Edge cases
   - Error behavior
   - What explicitly should NOT happen
4. No obvious questions
5. Do not write code

## Process
1. Read relevant files in the project (if needed)
2. Conduct interview until everything is clarified
3. At the end: Write specification as Markdown file

## Output
Save the spec in the project (e.g. specs/, docs/ or project root)

Calling /interview Improve error handling starts the interview. The key instruction is not to write code, because without it Claude implements immediately after the questions.

If you include project context, you get better questions. For an API the command could look like this:

You are an API designer. Interview me about a new endpoint.

## Context
$ARGUMENTS

Read first:
- The existing controllers in src/controllers/
- The error handling in src/middleware/error.ts
- The API conventions in docs/api-conventions.md

## Questions you should ask
- HTTP method and path
- Request/response schema
- Authentication needed?
- What errors can occur?
- Rate limiting?

The result is a Markdown file: the spec for implementation.

When It’s Worth It

An interview is worthwhile when more than one plausible solution path exists. Bug fixes with clear causes don’t need one, nor do tasks with documented requirements.

The real value isn’t the spec at the end, but the thinking that the questions force.

In Practice

Without an interview, Claude builds a generic error schema with logging and is done. With an interview, things look different:

Me: “I want to improve the error handling in my API.”

Claude asks:

1. Error types: “What categories of errors should be distinguished?” (Validation vs. Business Logic vs. System)
2. Client communication: “How should errors be communicated to the client?” (Just HTTP status or detailed error object?)
3. Logging: “Should structured logging be integrated?”
4. Unexpected errors: “What happens with unexpected exceptions?”

The resulting spec:

# Error Handling Refactoring

## Scope
- Validation Errors: 400 with field-specific messages
- Business Logic Errors: 422 with error code
- System Errors: 500 with correlation ID

## Response Schema
{
  "error": "ERROR_CODE",
  "message": "Human-readable description",
  "details": [{"field": "email", "message": "Invalid format"}],
  "correlationId": "uuid"
}

## Logging
- Log all errors with correlation ID
- System Errors: Alert to monitoring

## Out of Scope
- Retry mechanisms
- Circuit breaker

Without rules in CLAUDE.md, Claude rarely asks on its own. But the five minutes for setup pay off at the latest with the next feature that works on the first try.