Use a Spec-Driven Workflow for Large Features

Don’t just tell Claude “build a user settings page.” Write a 10-line spec first, then hand it over. The difference in output quality is massive.

The Pattern

1. Write a spec (you or Claude in plan mode)
2. Get Claude’s sign-off on the spec
3. Claude builds to the spec
4. Review against the spec

Spec Template

Create a file like specs/user-settings.md:

## User Settings Page

**Goal:** Let users update their email, display name, and notification preferences.

**Routes:** GET /settings, PUT /settings
**Components:** SettingsForm, NotificationToggle
**Validation:** Email must be valid. Display name 2-50 chars.
**Tests:** Unit tests for validation. E2E test for save flow.
**Out of scope:** Password changes, account deletion, billing.

Hand It Off

Read specs/user-settings.md and implement it.
Work through each section. Run tests after each component.
Don't add anything not in the spec.

Why This Works

• Claude has a clear target instead of guessing your intent
• “Out of scope” prevents the over-engineering Claude is prone to
• You can review the output against concrete criteria
• If Claude drifts, point it back to the spec

When to Use

Any task that touches 3+ files or takes more than a few minutes. For quick one-file changes, just ask directly.