Cast the brief once, start the next session by reading it, ship decisions in the repo, and check it still holds as products live on.

You've explained your user three times today. Twice to the same AI.

You prototype in Cursor, ship from a repo, and still rebuild context from scratch every session — re-explain the user, re-establish the constraints, watch the output wander from what you meant. Somewhere around message 12, the problem quietly changes and neither of you notices. The prototype works. It's also answering a question nobody asked.

The fix isn't better prompts. It's a brief that doesn't move.

I've shipped 15+ AI prototypes since 2024 — some as throwaway explorations, some as live internal tools customers use. The pattern that survived all of them: treat the brief as scaffolding. Set the stable parts once, explore against them freely, carry decisions forward explicitly. The scaffold quality determines what gets built on it.

I call it Prefix-First Design. The name comes from a prompt-caching idea — more on that in the footnote — but you don't need to know anything about caching to use it. You need five fields and three habits.

Prefix-First Design — lessons from building vibe-coded prototypes
Prefix-First Design — protecting stable context so exploration can move freely.

The brief: five fields, one screen

Before opening Figma or Cursor, write down what isn't allowed to change:

  • Problem frame — the user problem, in 1–3 sentences, with no solution language. "A dashboard that shows…" is not a problem; it's a feature request wearing a trench coat.
  • User — a real person mid-task, not a persona. "Busy professionals" holds nothing.
  • Constraints — only what genuinely can't change. Technical, business, scope. "Should feel modern" is taste, not a constraint.
  • Principles — 2–4 filters that can actually reject an idea. If a principle couldn't say no to anything, it's decoration.
  • What's already been decided — the locked decisions this session builds on.
PROBLEM FRAME — What is the user problem we are solving?
USER — Who is this for? What do they already know?
CONSTRAINTS (fixed) — What is genuinely not allowed to change?
DESIGN PRINCIPLES — What are we optimising for?
WHAT HAS ALREADY BEEN DECIDED — Load-bearing decisions from prior sessions.

If you can't fill in the brief, that's the design problem. Solve it first.

Once the brief grades clean, an optional frame pass asks up to five questions that would actually change what you build — ordered by blast radius, with options and a recommendation — then folds the answers back into the brief. Skip it when nothing qualifies. Grading checks whether the brief is sharp; the frame pass catches what the brief left open.

Everything you explore gets labeled: EXPLORING (tested against the brief) or DECIDED (locked; the next phase builds on it). When exploration reveals the brief was wrong, you stop and change it out loud — never quietly.

Not every departure is a brief crisis. An implementation detail that still serves the same problem is a deviation — log it and continue. A quiet change to the problem frame or a locked decision is drift — stop, name it, choose. Treating every pixel change as drift burns the session; riding real drift burns the product.

This is the ritual that produced four distinct tone-selector concepts in 45 minutes from one brief that never moved. The industry context, the user, the interaction model — none of it got re-explained between concepts, because none of it was allowed to drift.

Stable prefix base holds context, constraints, and system rules — variable tail holds the exploration you iterate on
Stable prefix base + variable exploration tail — the core Prefix-First model.

Ship the decisions

Here's what changed since I first wrote this framework: my work stopped living in chat sessions and started living in repos. And a brief that lives in a chat dies with the chat.

So the brief ships with the work now. Every page in the products I maintain has a ledger — a short file recording what was decided, why, and what's still open. The session rule is simple: start by reading. Last close-out, brief, ledger — mirror the state in a few lines before anyone builds. Agents read it before touching anything.

At Aampe, I run a playground of internal tools this way — shipped outside the sprint queue, used by real customers, maintained mostly by agents and me. When I asked an agent to fix a CTA gap on the Relay page, it read the page ledger first and didn't re-litigate a footer decision from three sessions ago. The ledger did the arguing for me. That's the whole point: decisions travel with the work, not in my head.

I've written about the playground setup (building an app playground) and what day-to-day designing with an agent actually looks like (designing with an AI agent at Aampe) — the short version is that one designer-builder can ship at a pace that used to need a team, but only if the decisions are readable by whoever (or whatever) shows up next.

A handoff without the brief isn't a handoff. A prototype without its problem frame is just a screen.

Close-outs are written for two readers now. The top half is for you — what the session focused on, what's left, what to do next. The bottom half is for the next agent — recommended focus, what's agent-doable, what needs a human, what's out of scope. Paste it into the next session (or leave it in the repo). The next agent starts by reading it.

Check it still holds

Live products drift away from their briefs. Users change, constraints change, and things ship that quietly contradict decisions you locked months ago.

The counter-ritual is small on purpose: once a month, 20 minutes, three questions.

  1. Is the brief still true?
  2. Did anything ship that contradicts a locked decision?
  3. What did we learn that should become a locked decision?

One dated entry in a still-holds.md log. That's the entire practice — a calendar reminder and a text file. If question one fails two months in a row, the brief needs a rewrite session, not another patch. That's a finding, not a failure.

It's how tinydesignshop.com stays coherent across agent sessions — the AI Token Cost Calculator shipped against a brief that never moved.

Where the failures show up

  • You re-explained the user in message 4. The brief was too vague to hold. Sharpen the user field and lock it.
  • The exploration quietly changed the problem frame. Stop. Name what changed. New session or brief update — either is fine, but say it.
  • You handed off the artifact without the context. The brief travels with the work, or the next person re-litigates everything.
  • The session got long and coherence dropped. Close out, open fresh, paste the decisions in as the new base.
  • Testing fails and you can't tell if it's the interaction or the problem. Test the brief first: "does this match the problem you actually have?" comes before "can you complete this task?"

Use it

The framework is open source: github.com/iruhdam1/prefix-first-design. Two ways in — same brief, different weight.

  • Light path — paste the compact brief as message one of any session. One session, one close-out.
  • Full path — drop the skill into your repo, keep a brief or page ledger with the work, run still-holds on live products. Agents start by reading, grade the brief, stop at drift, and close with a two-reader ledger.

Try it on your next session. The first time you don't re-explain your user, it's paid for itself.

Front-loading stable context maps directly to prompt-caching architecture
Design session maps to prompt cache — cache the prefix, swap the variable slice each run.

Why "prefix"? Prompt caching keeps the stable part of the context — the prefix — and only reprocesses what changes. Change the prefix, pay full cost again. Same rule, applied to design sessions. That's the whole metaphor; you never need to think about it again.