Design Memory

Design Memory

Design memory is an observational record of how you design — the decisions you make, the styles you reach for, the habits and inclinations that show up across projects. It is a mirror, not a controller. It notices what you do and reflects it back to you out of curiosity. It does not steer future work.

The one rule that defines this skill

Design memory is descriptive, never prescriptive. It records what you did; it is not applied to drive new projects. The current project's direction comes from what you tell the team now (design-taste) and from any brand spec you provide (design-md / DESIGN.md) — never from this record. Observation that never feeds back into the work cannot mis-steer it, which is exactly why a record built across many different clients stays safe and honest: it's a journal, not a set of orders.

If you ever want to act on an observation, that's your call to make explicitly in the moment — the system will not quietly apply your past decisions to a new client's project.

Welcome Gate

BEFORE reading or updating design memory, check whether the Designpowers welcome sequence has been shown this session. If the user has not yet seen the welcome (the bird, the greeting, and the walkthrough offer), you MUST invoke the using-designpowers skill FIRST and complete the welcome sequence before returning here. The bird must appear before any work begins. No exceptions.

When to Use

• At project completion — observe the project's decisions and add them to the record
• When the user asks "how do I design?", "what are my habits?", "what's my style?" — produce the report
• When the user makes a notably characteristic choice — note it as an observation
• It is not loaded to constrain a new project. (Loading at project start is only to show the user their report if they want it, not to feed preferences into the pipeline.)

The Record (taste-profile.md)

Lives at ~/.designpowers/taste-profile.md (cross-project). It is a journal of observations about how the user works — not a rulebook. Every entry is phrased as something observed, with evidence, never as an instruction for future work.

Structure

# Design Record — How [user] Designs
_An observational journal. Descriptive, not prescriptive — this is never applied to steer projects._

_Last updated: [date] after project [project name]_
_Projects observed: [count]_

## Recurring Decisions
Choices that have shown up more than once — noticed, not mandated.

| Observation | Times seen | Evidence |
|-------------|-----------|----------|
| [e.g., "Reaches for generous whitespace"] | 3 projects | A, C, D — chose it unprompted |
| [e.g., "Decides colour last, after structure"] | 2 projects | Sequence in B, D |

## Style & Habits
How the user tends to work and decide (not what to impose).

- **Visual leanings:** [e.g., "warm neutrals show up often; rarely picks saturated primaries"]
- **Process habits:** [e.g., "subtracts before adding — overrides usually remove an element"]
- **Decision style:** [e.g., "settles type and spacing before touching colour"]
- **Content voice tendencies:** [e.g., "consistently plain language, contractions, grade ~7"]

## Inclinations & Curiosities
Softer, single-occurrence or emerging things worth noticing — explicitly uncertain.

| Noticed | Where | Note |
|---------|-------|------|
| [e.g., "tried a serif display once and kept it"] | Project D | one occurrence, may not be a pattern |

## Things the user has moved away from
Choices they've reversed or corrected — observed, not a ban.

| Observation | Evidence |
|-------------|----------|
| [e.g., "removed gradient backgrounds twice"] | A, B |

## Project History
| Project | Date | What was decided | What it suggested about how they work |
|---------|------|------------------|----------------------------------------|
| [name] | [date] | [key decisions] | [the habit/inclination it revealed] |

Process

Observing (during and at end of a project)

Watch for signals about how the user decides — and record them as observations, with evidence:

When you notice a signal:

1. Phrase it as an observation ("reaches for X", "tends to decide Y last"), never a rule ("always use X").
2. Check whether it reinforces an existing observation (increase the count / add evidence) or is new (add it under the right section).
3. If it contradicts an earlier observation, don't agonise — just note both; people change, and the record is a journal, not a contract.

Consolidating (end of project)

When a project completes:

1. Review the decisions in design-state.md and the user's overrides.
2. Add observations to the record, with evidence and project attribution.
3. Keep it to how the user works, not what this client needed. A client's required brand colour is that client's taste (it lives in their DESIGN.md) — it is not an observation about the user. Only record things that reflect the user's own way of deciding, the kind that would still be true with a different client.
4. Offer the report: "Want to see what this project added to your design record?"