# Taste Feedback

> Use during the build phase to show the user intermediate visual output and ask for taste direction before the full build completes — enables mid-flight course correction so taste mismatches are caught early, not in review

- Skill: `owl-listener/taste-feedback` (Agent Skill)
- Install (CLI): `npx skillmds@latest add owl-listener/taste-feedback`
- Raw SKILL.md: https://api.skillmd.com/api/skills/owl-listener/taste-feedback/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Owl Listener (https://skillmd.com/u/owl-listener)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/owl-listener/taste-feedback

---


# Live Taste Feedback

The standard Designpowers pipeline catches taste mismatches at critique — after the full build is done. That's expensive. A wrong colour palette discovered after 8 components are built means rebuilding all 8. This skill interrupts the build at strategic moments to show intermediate output and ask: "Is this heading in the right direction?"

## When to Use

- During `design-builder` execution, at natural visual checkpoints
- When the build involves subjective aesthetic decisions (colour, typography, spacing, tone)
- When this project's taste direction (`design-taste`) is ambiguous on the decision at hand
- When the project is new and there's little explicit direction yet for this decision
- When the design-lead's direction was based on interpretation, not explicit user instruction

## Do Not Use When

- The user is in auto mode and hasn't opted into taste checks
- The build is purely structural (data models, API integration, routing)
- This project's `design-taste` direction already settles this decision clearly
- The user has explicitly said "just build it, I'll review at the end"

## Process

### Step 1: Identify Checkpoints

Before the build begins, identify 2-4 moments where taste feedback is most valuable. More than 4 interruptions becomes annoying. Choose wisely.

**High-value checkpoints:**

| Checkpoint | Why It Matters | When to Show |
|------------|---------------|-------------|
| **Colour and typography applied** | The foundational visual layer — everything else builds on this | After the first component is styled |
| **Layout structure visible** | Spatial relationships, density, whitespace | After the primary screen scaffold is built |
| **First interaction implemented** | How the interface moves and responds | After the first stateful component works |
| **Content integrated** | How real words look in the design | After content-writer's copy is in place |

**Low-value checkpoints (avoid):**

| Checkpoint | Why It's Low Value |
|------------|-------------------|
| Unstyled HTML structure | Nothing to react to aesthetically |
| Individual component in isolation | Context-free judgement is unreliable |
| After every small change | Interruption fatigue kills the creative flow |

### Step 2: Prepare the Checkpoint

At each checkpoint, capture the current state:

1. **Take a screenshot** of the running output (or describe the visual state precisely if screenshots aren't available)
2. **Identify the taste-sensitive decisions** visible in the current output
3. **Prepare specific questions** — do not ask "does this look good?" (too vague)

Good taste questions are specific and answerable:

| Bad Question | Good Question |
|-------------|--------------|
| "Does this look good?" | "The heading is set in 32px Inter Medium — is that weight right, or do you want bolder/lighter?" |
| "Any feedback?" | "The cards have 16px padding and 8px radius. Does this density feel right, or do you want more breathing room?" |
| "Is this the right direction?" | "I went warm grey (#F5F3F0) for the background instead of pure white. Does this warmth match what you had in mind?" |

### Step 3: Present the Checkpoint

Show the user the intermediate state with targeted questions:

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  TASTE CHECK  [1 of 3]
  Phase: [e.g., "Colour & Typography"]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  [Screenshot or detailed visual description]

  DECISIONS VISIBLE:
  • [Decision 1 — e.g., "Sage green (#8FAE8B) as primary"]
  • [Decision 2 — e.g., "Space Grotesk for headings, Inter for body"]
  • [Decision 3 — e.g., "Generous padding, low density"]

  TASTE QUESTIONS:
  1. [Specific question about a visible decision]
  2. [Specific question about a visible decision]

  Quick responses welcome:
  • "Looks right" → continue building
  • "Warmer/cooler/bolder/quieter" → adjust and continue
  • "Stop — wrong direction" → pause build, discuss
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

### Step 4: Process the Response

The user's response determines what happens next:

| Response | Action | Taste Signal |
|----------|--------|-------------|
| "Looks right" / "Yes" / "Continue" | Resume building. No changes needed | Moderate positive — note in design-memory as confirmed direction |
| Specific adjustment ("make it warmer") | Apply the adjustment, show confirmation, then continue | Strong — record the adjustment and the direction they moved from/to |
| "Wrong direction" / "Stop" | Pause the build. Ask what feels off. This is the most valuable taste data | Very strong negative — record what was rejected and why |
| Detailed feedback ("I like the type but the colour feels too muted") | Apply partial changes. Acknowledge what works, adjust what doesn't | Mixed signal — record both the positive and negative separately |
| "Skip these checks" | Disable further taste checks for this build. Respect the preference | Meta-preference — they want to review at the end instead |

### Step 5: Adjust and Confirm

When the user requests a change:

1. Make the adjustment
2. Show the updated state briefly — do not re-present the full checkpoint
3. Confirm: "Updated [what changed]. Continuing the build."
4. Do not ask for re-approval unless the change was ambiguous

If the change cascades (e.g., new colour palette affects multiple components already built):

1. Flag the cascade: "This colour change will affect the 3 components already built. I'll update them all."
2. Update everything before continuing
3. Optionally show the cascaded result at the next checkpoint

### Step 6: Record Taste Data

After each checkpoint interaction, update taste signals:

1. Record confirmed decisions as positive signals in `design-memory`
2. Record adjustments with before/after — these are the richest taste data
3. Record rejections as anti-pattern candidates
4. Note the *direction* of adjustments — "wanted warmer", "wanted more contrast", "wanted tighter spacing" — these directional signals generalize across projects

## Checkpoint Frequency

Adapt based on user behaviour:

| User Behaviour | Adjust To |
|---------------|-----------|
| Approves every checkpoint quickly | Reduce to 1-2 checkpoints — they trust the direction |
| Gives detailed feedback at every checkpoint | Maintain 3-4 — they want to shape the output |
| Says "skip" or seems impatient | Drop to 1 checkpoint or none — ask at the end |
| Requests more checkpoints | Add checkpoints — they want more control |

The system should learn this preference over time via `design-memory`.

## Integration With Pipeline Modes

| Mode | Behaviour |
|------|-----------|
| **Direct** | Taste checkpoints are shown naturally — they fit the approval flow |
| **Auto** | Taste checkpoints are **disabled by default** in auto mode. The user chose speed. If the user opts in ("auto but check my taste"), enable minimal checkpoints (1-2 max) |

## Integration

- **Called by:** `design-builder` (at visual checkpoints during build), `using-designpowers` (can be enabled/disabled)
- **Calls:** `design-memory` (to record taste signals from feedback)
- **Reads from:** Taste profile (to determine checkpoint frequency and known preferences), `design-state.md` (for current decisions)
- **Pairs with:** `design-memory`, `ui-composition`, `designpowers-critique`

## Anti-Patterns

| Pattern | Why It Fails |
|---------|-------------|
| Asking "does this look good?" | Too vague. The user can't give actionable feedback without specific questions |
| Checking after every change | Interruption fatigue. 2-4 checkpoints per build, maximum |
| Showing unstyled output | There's nothing to react to. Wait until visual decisions are visible |
| Ignoring "skip" signals | If the user wants to review at the end, respect that. Don't force mid-flight checks |
| Not recording feedback | Every checkpoint interaction is taste data. If you don't record it, you'll ask the same questions next project |
| Presenting in auto mode without consent | Auto mode means "don't interrupt me." Only show taste checks if the user explicitly opted in |
| Asking about non-visual decisions | "Is this the right React component pattern?" is not a taste question. Keep checks visual and aesthetic |