/taste-feedback

name: taste-feedback
description: 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

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 `de