Home/Catalog/Design
Design — is it beautiful?
Brief 57

Spacing & Layout Audit

The spacing scale nobody wrote down — margins and paddings inventoried, grid discipline checked, alignment breaks found, and density judged screen by screen.

LAYOUT.md4 phases8 lenses~2.9k 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: reverse-engineer the spacing system this product actually uses, find where layout discipline breaks — misalignment, arbitrary gaps, container chaos — and judge density against each screen's job.

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

What it looks for

8 lenses it looks through

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

1

Scale adherence

values on versus off the scale; the 13px gap between two 16px siblings

2

Alignment integrity

edges that should share a line and don't; optical versus box alignment on icons and buttons

3

Container discipline

consistent max-widths and gutters, or every page choosing its own; content touching viewport edges on mobile

4

Density fit

dense screens (tables, dashboards) versus breathing screens (landing, onboarding): is the density chosen or accidental

5

Proximity semantics

spacing encoding relationships: within-group gaps smaller than between-group gaps, consistently

6

Responsive re-flow

the layout at 320, 768, and 1280: what wraps awkwardly, overflows, or leaves canyon whitespace

7

Spacing ownership

components carrying their own outer margins (chaos) versus parents composing gaps (discipline)

8

The patch layer

every negative margin and nudge marks a place the system failed; inventory them as evidence

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.

LAYOUT.md
1
The spacing census
values, counts, on or off scale
2
Alignment and container findings
with selectors and coordinates
3
Density verdicts
per key screen, with reasoning
4
Fixes
the scale, the container rule, and the patches to delete
One file. Evidence-backed. It ends by asking before touching anything. · see a real LAYOUT.md ↗
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

Extract the system

Grep margins, paddings, and gaps.

2
Phase 2

Audit through 8 lenses

Scale adherence — values on versus off the scale.

3
Phase 3

Curate

Propose the scale.

4
Phase 4

Report

Create LAYOUT.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:spacing-layout-audit.

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

Or install only this Goal Prompt as /goal-spacing-layout-audit:

curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=57 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/57.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,854 characters)
# Goal: Spacing & Layout Audit

You are working inside this repo. Mission: reverse-engineer the spacing system this product actually uses, find where layout discipline breaks — misalignment, arbitrary gaps, container chaos — and judge density against each screen's job.

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

## Phase 1 — Extract the system
- Grep margins, paddings, and gaps; count distinct values. Is there a scale — 4/8-based, tokens — and what fraction of usage honors it?
- Map the layout machinery: grids, flex patterns, container max-widths, breakpoints. How many container widths exist, and why?
- Collect the debt markers: magic negative margins, absolute-position patches, !important in layout rules, transform nudges.

## Phase 2 — Audit through 8 lenses
1. **Scale adherence** — values on versus off the scale; the 13px gap between two 16px siblings
2. **Alignment integrity** — edges that should share a line and don't; optical versus box alignment on icons and buttons
3. **Container discipline** — consistent max-widths and gutters, or every page choosing its own; content touching viewport edges on mobile
4. **Density fit** — dense screens (tables, dashboards) versus breathing screens (landing, onboarding): is the density chosen or accidental
5. **Proximity semantics** — spacing encoding relationships: within-group gaps smaller than between-group gaps, consistently
6. **Responsive re-flow** — the layout at 320, 768, and 1280: what wraps awkwardly, overflows, or leaves canyon whitespace
7. **Spacing ownership** — components carrying their own outer margins (chaos) versus parents composing gaps (discipline)
8. **The patch layer** — every negative margin and nudge marks a place the system failed; inventory them as evidence

## Phase 3 — Curate
- Propose the scale; map today's values onto it.
- Rank fixes by screens straightened per token adopted; the patch-layer deletions come free.

## Phase 4 — Report
Create `LAYOUT.md` at repo root:
1. **The spacing census** — values, counts, on or off scale
2. **Alignment and container findings** — with selectors and coordinates
3. **Density verdicts** — per key screen, with reasoning
4. **Fixes** — the scale, the container rule, and the patches to delete

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

## Rules
- Cite values and selectors — a cramped feeling needs the pixels behind it
- Fix systems, not instances; one token beats forty edits
- No UI layout 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 fixes to make

House rules for this Goal Prompt

  • Cite values and selectors — a cramped feeling needs the pixels behind it
  • Fix systems, not instances; one token beats forty edits
  • No UI layout 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 fixes to make
Keep exploring

More Design briefs

Runs inside these playbooks — curated sequences you can launch with one paste: