Team — can others build on it?
Brief 15

Design System Consolidation

Census the drifted colors, spacing, and duplicate components; propose the token set and migration order to unify them.

DESIGN-SYSTEM.md4 phases6 lenses~2.8k chars

Free & open · no signup · read-only — it ends by asking · nothing leaves your machine

What it does

You are working inside this repo. Mission: census the visual drift — every near-duplicate color, arbitrary spacing value, and re-implemented component — and propose the token system and migration order that unifies them.

This is for a codebase with no system yet: census the drift, propose the tokens. If tokens already exist, 105 audits their adoption; for color and contrast alone, 56 computes the ratios.

Read-only pass. Your only write is the report file.

What it looks for

6 lenses it looks through

Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.

1

Color sprawl

cluster near-duplicates; name the intended color each cluster wants to be

2

Spacing drift

arbitrary values vs an implied scale; propose the scale the code is already reaching for

3

Type chaos

sizes/weights outside any scale; heading styles re-declared per page

4

Component duplicates

for each cluster: which implementation wins and why

5

System bypasses

inline styles and one-off overrides defeating existing tokens/components

6

State inconsistency

hover, focus, disabled, error styled differently across components

The deliverable

What lands in your repo

One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.

DESIGN-SYSTEM.md
1
Census numbers
the before: counts per category
2
Proposed tokens
colors, spacing scale, type scale, radii/shadows — derived from what the code already wants
3
Component consolidation list
keep/merge/kill with usage counts and winning implementation
4
Migration order
sequenced lowest-risk first, each step shippable
5
Projected after-numbers
the census once complete
One file. Evidence-backed. It ends by asking before touching anything.
How it works

What it makes the agent do

Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.

1
Phase 1

Take the census

Count, don't estimate.

2
Phase 2

Audit through 6 lenses

Color sprawl — cluster near-duplicates.

3
Phase 3

Curate

Every consolidation names keep / merge / kill per variant, with usage counts.

4
Phase 4

Report

Create DESIGN-SYSTEM.md at repo root.

Get started

Three ways to run this Goal Prompt

01 · COPY

Paste it in

Copy it and paste it into your agent inside the repo you want checked.

02 · INSTALL

As a slash command

Install the goal plugin once — two commands — then just type /goal:design-system-consolidation.

1/plugin marketplace add GhostlyGawd/goal-prompts
2/plugin install goal@goal-prompts

Or install only this Goal Prompt as /goal-design-system-consolidation:

curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=15 sh
03 · AGENT

From an agent (MCP)

Let an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.

https://goal-prompts.vercel.app/raw/15.md
Transparency

The exact prompt

Nothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.

Read the full brief (2,793 characters)
# Goal: Design System Consolidation

You are working inside this repo. Mission: census the visual drift — every near-duplicate color, arbitrary spacing value, and re-implemented component — and propose the token system and migration order that unifies them.

This is for a codebase with no system yet: census the drift, propose the tokens. If tokens already exist, 105 audits their adoption; for color and contrast alone, 56 computes the ratios.

Read-only pass. Your only write is the report file.

## Phase 1 — Take the census
Count, don't estimate. Grep the styles and components:
- Distinct color values (how many near-identical grays and brand shades?)
- Distinct font sizes, weights, and line heights
- Distinct spacing values, radii, shadows, z-indexes
- Component duplicates: how many button/input/modal/card implementations exist?

## Phase 2 — Audit through 6 lenses
1. **Color sprawl** — cluster near-duplicates; name the intended color each cluster wants to be
2. **Spacing drift** — arbitrary values vs an implied scale; propose the scale the code is already reaching for
3. **Type chaos** — sizes/weights outside any scale; heading styles re-declared per page
4. **Component duplicates** — for each cluster: which implementation wins and why
5. **System bypasses** — inline styles and one-off overrides defeating existing tokens/components
6. **State inconsistency** — hover, focus, disabled, error styled differently across components

## Phase 3 — Curate
- Every consolidation names keep / merge / kill per variant, with usage counts
- Order migration by risk: tokens first (mechanical), shared components second, page cleanups last

## Phase 4 — Report
Create `DESIGN-SYSTEM.md` at repo root:
1. **Census numbers** — the before: counts per category
2. **Proposed tokens** — colors, spacing scale, type scale, radii/shadows — derived from what the code already wants
3. **Component consolidation list** — keep/merge/kill with usage counts and winning implementation
4. **Migration order** — sequenced lowest-risk first, each step shippable
5. **Projected after-numbers** — the census once complete

Start the report with today's date. If `DESIGN-SYSTEM.md` already exists from a previous run, read it first and lead with what changed since.

## Rules
- Derive the system from the code's existing center of gravity — don't import a foreign aesthetic
- Mechanical, reviewable migrations beat big-bang rewrites
- No design system or shared UI components in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
- If a `reports/` directory exists at the repo root, write the report there instead of the root.
- Before asking, present the top findings as a ranked list in plain words
- Report only — end by asking which migration step to take

House rules for this Goal Prompt

  • Derive the system from the code's existing center of gravity — don't import a foreign aesthetic
  • Mechanical, reviewable migrations beat big-bang rewrites
  • No design system or shared UI components in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
  • If a reports/ directory exists at the repo root, write the report there instead of the root.
  • Before asking, present the top findings as a ranked list in plain words
  • Report only — end by asking which migration step to take
Keep exploring

Pairs well with

Curated neighbors — briefs that answer the adjacent question, worth running in the same session.

More Team briefs