# Same Same But Different

> Produce N genuinely different versions of one thing — ten takes on the same page, screen, document, deck, logo, name, or plan — by holding the content fixed and varying exactly ONE named axis at a time (BONES = layout/architecture, SKIN = type/colour/surface, FRAME = scale/proportion/crop). Use whenever the user says "same same but different", "show me 10 versions", "give me variations", "other ways this could look", "mix it up", "remake this a bunch of different ways", "different layouts", "different styles", or asks for a set of options to choose between. Carries the shape catalogues that make variants actually different, a cheap build-and-verify pipeline, and a numbered gallery so the user picks or mixes by number. NOT for refining one design toward a single answer (that is ordinary iteration) and not for generating new content.

- Skill: `idealockin/same-same-but-different` (Agent Skill)
- Install (CLI): `npx skillmds@latest add idealockin/same-same-but-different`
- Raw SKILL.md: https://api.skillmd.com/api/skills/idealockin/same-same-but-different/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: idealockin (https://skillmd.com/u/idealockin)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/idealockin/same-same-but-different

---


# same-same-but-different

Ten versions of the same thing, each one genuinely a different idea — not one
idea wearing ten outfits.

That last clause is the whole skill. The natural failure, every time, is to
build one design and then re-colour it N times; the person asking gets a
gallery where every picture is the same picture, and they cannot tell you why
it is wrong. This skill exists to prevent that.

## The one law

> **Vary ONE axis. Freeze everything else — including the content.**

A variant set is only readable if exactly one thing differs. Ten layouts in
ten different colour schemes teach nothing, because no two can be compared.
Ten layouts in the *identical* skin teach everything.

## The three axes (visual work)

| Axis | What changes | What must NOT change |
|---|---|---|
| **BONES** | Where each block lives, what dominates, what shape the thing is, what gets promoted or deleted from view | Type, colour, corners, content |
| **SKIN** | Typefaces, weights, case, colour palette, borders, radius, shadow, density | Where everything sits |
| **FRAME** | Overall scale, margins, inset, crop, proportion between panes, how much of the canvas the work occupies | Layout and style |

Non-visual work has the same three, renamed: **structure** (order and grouping
of the parts), **voice** (register, vocabulary, rhythm), **scale** (length,
density, level of detail).

Most people asking for "different versions" mean BONES and get shown SKIN.
When the ask is ambiguous, **default to BONES** — it is the rarer, harder, and
more useful answer.

## Run it in five steps

### 1 — Write the inventory, out loud

Before generating anything, list every element that must appear in **every**
variant. Show the list to the user in your reply. Example for a screen:

> title · one-paragraph summary · three stats · six timed steps · one video ·
> four files · a 28-item directory · search · a progress meter · five links ·
> notes · previous / complete / next

The inventory is the contract. A variant that quietly drops the notes field or
invents a new stat is not a variant — it is a different product, and it
poisons the comparison. Content stays byte-identical across the set.

### 2 — Name the axis, once

State which axis you are varying and that the others are frozen. One sentence,
in the reply, before the work:

> "Ten layouts. Same content, same skin, same 18px frame — only the
> architecture changes."

If genuinely ambiguous and the user is available, ask exactly one question
(bones / skin / both-in-sequence). Never ask more than one; never ask if the
answer is inferable. If they are away, pick BONES, say so, and proceed.

### 3 — Choose N distinct positions

Pick the N positions **before** building anything, and write a one-line
description of each. Then apply the discrimination test:

> **If one sentence describes two of your variants, one of them is wasted.**
> Delete it and pick something further away.

For BONES, the fastest way to real distance is to **name a familiar shape** —
a form the reader already has in their head — and build that:

- **Single column** — no rail at all; secondary tools become a strip on top or
  a dock at the bottom
- **Sidebar navigator** — navigation becomes a full-height rail (often dark),
  content gets the rest
- **Media-first / player** — one asset owns the top of the screen edge to edge;
  everything else is a row of columns beneath it
- **Index-first** — the thing that was a small widget (calendar, list, map,
  table of contents) becomes half the screen; the "main" content shares
- **Bento** — no columns at all; tiles on a grid, each sized by importance
- **Board / kanban** — parallel columns you scan across, one per category
- **Metrics dashboard** — numbers first, title demoted to a page header
- **Timeline / stepper** — one spine; every step carries its own material, and
  the "materials" section stops existing
- **Three-pane (mail client)** — icons, a scrollable list, the detail, and a
  side panel for one secondary job
- **Focus mode** — one thing at a time fills the screen, everything else
  collapses into a dock
- **Split screen** — two equal halves that stay in sync
- **Overlay / modal-first** — the page is a background, the work happens in a
  sheet
- **Wizard** — one question per screen with a progress rail
- **Canvas / spatial** — pannable surface, objects placed rather than stacked

For SKIN, the dimensions worth crossing: display face vs text face vs
label/number face · weight and case of micro-labels · palette ground (paper /
white / cool grey / dark / brand colour) · accent count (one, two, or a family)
· border radius (0 → 16) · how surfaces are defined (fill, hairline, heavy
border, shadow, nothing) · density. A kit is only a kit if it decides all of
them; half-specified skins look like accidents.

For FRAME: inset from the window edge · corner radius of the whole surface ·
shadow depth · overall scale up/down a few percent · type scale up/down one
notch · proportion between the panes · full-bleed vs capped width.

### 4 — Build cheaply, then verify

**One generator, shared atoms, per-variant deltas.** Write the content atoms
once (in a small builder script, a template, or a component file) and have each
variant import them and override only its own rules. Never hand-copy the whole
thing N times — the copies drift and the comparison dies. For web work a ~200
line Python or Node script that writes N standalone HTML files is right; every
file stays independently openable, and rebuilding all N after a fix takes
seconds.

**Do NOT spawn one agent per variant.** N full-model subagents for N pictures
is the classic waste — building them from one script is faster, cheaper, and
keeps the content identical, which is the entire point.

**Then look at them.** Screenshot every variant at one fixed viewport (1440×900
is a good default for desktop work), assemble the shots into 2-up contact
sheets, and review the sheets. You are looking for breakage, not taste:
unreadable contrast, wrapped buttons, collapsed columns, an element that
vanished. Fix and re-shoot before delivering. A broken variant does not just
fail on its own — it makes the user distrust the whole set.

Python + Playwright is the low-friction path when it is available:

```python
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
    b = p.chromium.launch()
    pg = b.new_page(viewport={"width": 1440, "height": 900})
    for f in files:                      # local .html paths
        pg.goto(f.as_uri()); pg.wait_for_timeout(1000)
        pg.screenshot(path=f"shots/{f.stem}.png")
    b.close()
```

A browser automation MCP does the same job if you have one; so does any
headless-Chrome CLI. If nothing can screenshot, say so and deliver the files
plus a contact page — never claim you verified something you did not see.

### 5 — Deliver numbered, with one line each

- **Number every variant, continuing from any earlier round.** Numbers are how
  the conversation happens afterwards: "76 but with 81's rail". Never renumber.
- Give each variant a **short name and exactly one line** saying what changed.
  If you need a paragraph, the variant is not distinct enough.
- Build a **gallery page** — a plain HTML file with each screenshot, its
  number, its name, its line, and a link to the live file. Cheap, scannable,
  and it lets the user reply with numbers.
- Close by inviting the pick: *"Tell me which numbers to keep, or mix them —
  bones from one, skin from another."*

## The two-number handoff

Once a set exists on more than one axis, the user's fastest possible answer is
two numbers: **"structure 108 with kit 86."** Build the pairing immediately —
it is a mechanical merge (take variant A's markup, append variant B's style
block), and it is usually the moment the real design appears. Teach the user
this phrasing explicitly the first time you deliver two axes.

## Give the user the words

People often cannot articulate this ask — they say "different" and get skins,
then feel unable to explain why it is wrong. That is a vocabulary gap, not
their failure. Hand them the phrasebook, once, when the confusion shows:

- **Bones:** *"Same content, completely different layout each time. Nothing in
  the same place twice. Freeze the style."*
- **Skin:** *"Same layout, different skin — fonts, colours, corners."*
- **Frame:** *"Same design, just change how much of the window it takes up."*
- **Fastest of all:** *"Show it as a mail client / a player page / a bento / a
  board / a dashboard / a timeline / a focus mode."*
- **Combining:** *"Structure 4 with the style of 9."*

## How many

Default **10**. Below six the set stops feeling like a spread and starts
feeling like a recommendation; above about twelve the user cannot hold them in
their head. If the user names a number, use theirs. Deliver them all at once —
a variant set is a comparison, and a comparison delivered in instalments is
just iteration wearing a costume.

## Failure modes, in order of how often they happen

1. **Re-skinning instead of re-architecting.** Ten files, one skeleton. Test:
   cover the colours — can you still tell them apart by the wireframe alone?
   If not, start over on BONES.
2. **Drifting content.** Variant 7 has an extra button, variant 3 lost the
   summary. Now nothing is comparable. Generate from shared atoms.
3. **Two axes at once.** New layout *and* new palette per variant — the user
   cannot tell which change they are reacting to.
4. **Undelivered breakage.** A variant with unreadable text or a wrapped button
   reads as carelessness across the whole set.
5. **Variants that are settings, not ideas.** 4px vs 6px radius is not a
   variant. If a change would not survive being described out loud, cut it.
6. **Silent taste.** Shipping a set with no notes forces the user to reverse-
   engineer your intent. One line each, always.
7. **Burning the budget.** One agent per variant, or one full rebuild per tweak.
   One generator; re-run it.

## Recipes

**Web page / app screen** — inventory the blocks; ten BONES from the shape
catalogue; one builder script emitting standalone HTML; screenshot at
1440×900; contact sheets; gallery page. Then optionally a second round on SKIN
with the bones frozen.

**Document / report** — vary structure: executive-summary-first · narrative ·
Q&A · problem/solution pairs · timeline · one-pager + appendix · annotated
table · memo · FAQ · slide-style spreads. Same words, re-arranged.

**Slide deck** — vary the unit: one idea per slide · build-up sequence · full-
bleed image with a line · data-first · quote-driven · storyboard strip ·
comparison table · single-slide summary with layers.

**Logo / mark** — vary construction: wordmark · lettermark · pictorial ·
abstract mark · badge/seal · monoline · geometric · stacked lockup ·
horizontal lockup · negative-space. Freeze the palette so form is the variable.

**Naming / copy lines** — vary the mechanism, not the synonym: literal ·
metaphor · compound · verb phrase · borrowed word · invented word · initialism
· sound-first · opposite · understatement.

**Code / architecture** — vary the shape: single module · layered · event-
driven · pipeline · plugin registry · state machine · actor · data-first ·
functional core + imperative shell. Same behaviour and tests every time.

---

Built by [@ideaLOCKIN](https://x.com/ideaLOCKIN) · more at
[TakeonAI.com](https://TakeonAI.com)