taste-report

name

taste-report

description

Use when the user wants to see how they design — "what's my taste", "show me my taste report", "how do I decide", "what are my patterns", or periodically as the personal profile matures. Generates a longitudinal, reflective report from the PERSONAL taste profile (design-memory) — recurring moves, tells, evolution, blind spots — that helps a designer understand their own instincts. Personal layer only: it never reports client-specific signals from any project's DESIGN.md

Taste Report

A taste report turns the personal taste profile from a lookup table into a mirror. design-memory accumulates a designer's portable instincts over many projects; this skill reads that accumulation and reflects it back as something the designer can actually learn from — how you decide, what you reach for, what you reject, and how that's changed. It's the moment the system stops just remembering your taste and starts helping you see it.

Scope: Personal Layer Only

This report describes the portable taste in ~/.designpowers/taste-profile.md — the instincts that travel with the designer regardless of client. It must not include client- or project-specific signals (the contents of any project's DESIGN.md). A client's required teal accent is that client's taste, not the designer's. If the personal profile is clean (it should be — design-memory's Promotion Gate keeps client specifics out), this is automatic. If you notice client-bound entries that leaked into the personal profile, flag them as contamination rather than reporting them as the designer's taste.

When to Use

• The user asks: "what's my taste?", "how do I design?", "show me my patterns", "what do I always do?"
• Periodically, as the profile matures — offer it after a project's retrospective once the profile has 3+ projects of history (below that, there isn't enough signal; say so).
• When a designer wants to articulate their own style — for a portfolio, a team, a client pitch.

What the Report Contains

Read ~/.designpowers/taste-profile.md and the project history, then synthesise — don't just reformat the tables. Look for the patterns across entries that the designer might not see themselves.

# How You Design — Taste Report
_Generated [date] · based on [N] projects · [X] strong opinions, [Y] soft patterns_

## In one line
[The single sharpest characterisation of their taste. e.g. "You're a restraint-first
designer who earns every accent and trusts whitespace to do the work."]

## How you decide
[3-5 observations about their decision-making, each with evidence from the profile.
Not what they like — HOW they choose. e.g.:
- "You subtract before you add — your overrides almost always remove an element
   rather than restyle it (4 of 5 recorded overrides)."
- "You decide colour last. Type and spacing are settled before accent appears."]

## What you reach for
[Recurring moves — the defaults they return to across projects. The strong opinions
and confirmed soft patterns, framed as instincts not rules.]

## What you reject
[The anti-patterns, synthesised into a point of view. e.g. "You reject anything that
performs friendliness — confetti, mascots, exclamation marks, skeleton 'delight'."]

## How your taste is evolving
[Movement over time from the project history. What's hardened from soft to strong,
what you've changed your mind about, what's newly appearing. e.g. "Your tolerance
for density has risen — early projects favoured sparse layouts, recent ones trust
the user with more on screen."]

## Possible blind spots
[Gentle, honest. Tendencies that could become ruts, or places the profile is thin.
e.g. "Every project leans editorial-serif for personality — worth testing whether
that's taste or habit." Frame as questions, not judgements.]

## Where the signal is thin
[What the profile doesn't yet know — areas with little evidence, so the designer
knows what's well-established vs. a guess. Honesty about confidence.]

How to Write It Well

1. Synthesise, don't transcribe. The value is in patterns across entries — "you always subtract," "you decide colour last" — not in re-listing the table rows. If you're just reformatting the profile, you haven't done the work.
2. Every claim cites evidence. Tie each observation to specific projects, overrides, or repeated decisions in the profile. No evidence, no claim — this is design-memory, and the same "evidence over claims" rule applies.
3. Describe decision-making, not just preference. "Prefers muted palettes" is a lookup. "Decides colour last, after structure is settled" is insight. Reach for the second.
4. Be honest about confidence and thinness. Distinguish strong, well-evidenced patterns from thin ones. Don't manufacture a richer picture than the data supports.
5. Blind spots are a gift, not a verdict. Surface ruts and gaps gently, as questions. The goal is self-awareness, never a grade.
6. Stay in the personal layer. If a "preference" is really one client's brand requirement, it does not belong here.

Integration

• Reads from: ~/.designpowers/taste-profile.md and its project history (via design-memory)
• Never reads: any project's DESIGN.md as personal taste (that's client taste — see design-md)
• Offered after: design-retrospective, once the profile has enough history
• Pairs with: design-memory (the store), design-taste (per-project calibration)
• Produces: a report for the user — not a profile edit. It reflects; it does not rewrite the profile.