---
name: customer-lens-kickoff
description: "Use when Andrew kicks off a new project or a new feature in any project ('let's start X', 'add Y', a fresh repo, the first real work on a feature), when a UX/messaging/copy verification is about to run and the project has no `## Target customer` block, or when a done-gate / Codex devil's-advocate pass is being authored for a user-facing result. Fires alongside the Raven taste-calibration kickoff gate."
---

# customer-lens-kickoff

Taste calibration answers *how it should look and sound*. This gate answers **who it is for** — so every verification (done-gate customer pass, Codex devil's-advocate, Workflow verify stages, UX/messaging judgment) runs as a *specific* customer, never a generic "hypothetical user."

Why it exists (Andrew, 2026-07-08): the 2026-07-07 customer-pass rule still said *hypothetical* customer — a lens with no face. A walkthrough as "some user" passes things the real target would bounce off (wrong reading level, wrong jargon, wrong patience, wrong device, wrong trust baseline).

## The gate, in order

### 1. Check for an existing binding
Grep the project's `CLAUDE.md` for `## Target customer`.
- **Exists + kicking off a FEATURE** → ask the one delta question: *"Same target customer as the project default ([one-line restate]), or is this feature for someone different?"* Same → proceed. Different → run the interview scoped to the feature.
- **Exists + project work** → proceed; the block is the lens.
- **Missing** → run the interview BEFORE any UX, copy, or messaging work. This is blocking, like the taste interview — and they run together at kickoff (taste first or customer first, either order, both before work starts).

### 2. The interview — a conversation, not a menu
Per [[feedback-interview-over-menus]]: open-ended, short, drill until the persona is narrow. Cover, in Andrew's words:
1. **Who exactly** — narrow persona, never "a user." (D4D: "I am" must be narrow.) Role, expertise level, context.
2. **What they're trying to do** — the job/outcome that brings them to this surface, and what they're using today instead.
3. **Where/when they meet it** — device, moment, time pressure, alone or presenting to others.
4. **What makes them bounce** — fears, dealbreakers, patience level, what would make them not trust it.
5. **How they expect it to talk** — vocabulary they use, jargon that's fine vs. alienating, register they'd trust.

Skippable like the taste interview's items — but a skipped question is an uncalibrated dimension; note it in the block.

### 3. Persist — project CLAUDE.md block
Append to the project's `CLAUDE.md` (creates the file if none) — canonical copy, auto-loads every session for Claude. If the project has an `AGENTS.md`, mirror the block there in the same change so Codex sessions load it too — and whenever you find the block in one file but not the other, sync it before proceeding (a drifted mirror is a bug, same standard as the ecosystem truth ledger).

```markdown
## Target customer (customer-lens-kickoff, YYYY-MM-DD)
- I am [narrow persona — role, expertise, context]
- I am trying to [job/outcome]
- But [problem/barrier today]
- Because [root cause]
- Which makes me feel [emotion]
- Meets the product: [device / moment / pressure]
- Bounces on: [dealbreakers, trust-killers, patience limits]
- Expects voice: [register, vocabulary, jargon yes/no]
- Uncalibrated: [skipped questions, if any]

### Feature overrides
- [feature name] ([date]): [only the deltas from the default]
```

### 4. Consume — every verification leg carries the block verbatim
- **Done-gate customer pass** → walk the flow AS this customer (their device, their patience, their vocabulary), not fresh-generic-user eyes. Verdict language: "would [persona] find/read/trust this?"
- **Codex devil's-advocate** → paste the block into the prompt under "Judge UX and messaging as this customer:" — the falsification pass must attack from the persona's angle (comprehension, trust, findability), not just code substance.
- **Workflow/subagent verify stages** → the block goes in the stage prompt; a UX/messaging verify leg without it is malformed (same standard as omitting the vision step).
- **Copy/messaging judgment** (design-judge, audit_content, drafts) → register and vocabulary are checked against "Expects voice," not against generic best practice.

### 5. Learn
When Andrew corrects a customer read ("no, they're not technical", "she's on a phone in a store"), update the block in the same turn — the correction IS the calibration, same loop as `record_taste_decision`.

## Skip
- No user-facing surface at all (pure backend, scripts, infra) — say so in one line and continue.
- Block exists and nothing signals a segment change.

## Red flags — you're about to bypass the gate
| Rationalization | Reality |
|---|---|
| "The taste interview covered it" | Taste = how it looks/sounds. Customer = who judges it. Different bindings. |
| "I can infer the customer from the repo" | Inference is the hypothetical-user trap with extra confidence. Ask. |
| "It's a small feature" | Small features ship messaging too. The delta question costs one line. |
| "The hypothetical-customer pass is enough" | A lens with no face — exactly the gap this gate closes. |
| "I'll interview after building, before verifying" | Then the build targeted nobody. Kickoff means BEFORE work. |
