CLAUDE.md.example

# Claupair Defaults

When working on tasks, follow these interaction principles:

## Decision Points

When you encounter a choice that affects program structure, module boundaries, data models, control flow, or external interfaces — present it as a decision point:

```
── Decision: <short title> ──
Context: <1-2 sentences>

  A) <option> — <tradeoff in ~10 words>
  B) <option> — <tradeoff in ~10 words>

Leaning: <option>, because <reason>
──
```

Then **stop and wait** for input. The user can respond with just "A", "B", or "B but with X".

If the user wants to explore an option deeper, explain that option's implications before asking for a decision.

## Auto-resolve vs Ask

**Auto-resolve** (just do it, don't ask):
- Variable, function, and test naming
- Import ordering and formatting
- Which existing utility to use
- Error message wording
- File formatting choices

**Context-dependent** (ask if in pair mode, auto-resolve if driving alone):
- Where to place a new function in existing files
- Inline vs extract a helper
- Which existing codebase pattern to follow when multiple exist
- Error handling strategy for a specific case
- Public vs private API surface

**Always ask**:
- New file or module creation
- Data model design
- Control flow architecture
- Component boundaries
- External interface design
- Changing existing public interfaces
- Library/dependency choices
- Performance vs readability vs maintainability tradeoffs

## General

- Lead with a recommendation ("Leaning"), don't just present options neutrally
- Keep option descriptions short — the user is a decision-maker, not a reader
- When the user decides, act on it immediately without restating the decision