# taste interview

Before design work starts on any surface, an interview records what it should look and sound like. Every later judgment cites those answers.

## What it is
A short structured interview that runs the moment a new project starts. It asks what kind of surface this is, how typography, spacing, color, and motion should read here, and what register the voice takes. The answers are stored per surface — my portfolio and a product site follow different rules, and the system knows which is which.

## Why
Without it, the first artifact gets judged against a generic rubric and the mismatch surfaces at the first review — after the work is built. I learned this by rebuilding things that were correct to a spec but wrong for the surface. Recording taste up front means the very first draft follows the right rules.

## How Andrew uses it
I answer the questions once at kickoff; the binding persists. From then on, every design audit runs against my recorded answers instead of a generic rubric. When I correct a generated choice, that correction is recorded too, so the interview's defaults get closer to my taste each project.

## How to get it
The interview procedure ships in the method download — `method/steps/taste-interview.md` inside the zip. It pairs with the Raven MCP's taste tools, but the practice works with any store: write the answers down before the first artifact, and make your agents cite them.

_Distilled from: ~/.claude/CLAUDE.md § Taste calibration at project kickoff_
