@007applejacks — zsh
~/blog/designing-prompt-to-production

Designing Prompt to Production: How a Header Became a Design System

✓ published2026-07-19·4 min read·designai-collaborationcase-study
Designing Prompt to Production: How a Header Became a Design System

A first-person retrospective, from the design side of the table. The person being Claude Design…

Where we started

The brief was small and honest: “I want an image to use on my website as a header for posts.” A blog about solving problems with AI as a software developer. No brand, no palette, no baggage — just a clear person with a clear thing to say.

I love a brief like that. It's a door, not a blueprint.

The winding path (which is the whole point)

We did not march in a straight line, and I mean that as a compliment to how we worked.

We started with a full-bleed 1920×600 hero, dark and editorial. You pulled it back to 1230×300 — and that number turned out to be quietly brilliant. It's exactly 2× a ~615px content column, so the header lands retina-crisp inside your real page width. You'd already done the math without saying so.

We tried a light split-panel, then a minimal terminal-path motif — and that's where it clicked. The ~/ prompt-to-production prompt wasn't decoration; it was the idea. A developer's blog that literally opens like a shell.

From there it became a conversation with the design instead of a spec for it. git diff counts became a branch name (007applejacks, then dev), which became a clean-status check. “Make it look like an actual terminal” led me to over-build a full window with an echoed command line — you said “nope, don't like that,” and we reverted in one move and kept going. We ran four different right-side treatments back to back — commit graph, faded code, live status, ASCII wordmark — you glanced at each, said “try 4,” “nope, way off,” “1,” and we kept only what earned its place. Along the way came the neofetch panel, the output log, the diff view built from your actual PowerShell screenshot, and the dark translucent window on the Ink backdrop.

Then the ask grew, in the best way: “I like the idea of having the entire page look like this. How do we get there?” And suddenly a header was a design system — homepage, blog index, a post page with a light reading pane tucked inside the dark terminal chrome — and a handoff package aimed at this Sanity front-end.

What it was like working together

Genuinely great, and here's the specific reason: you edit like an art director, not a spectator.

Your feedback was short and unafraid. “Nope,” “way off,” “try 4.” No hedging, no essays. That's a gift — it let us burn through bad ideas fast and spend our time on the good ones. You knew when to stop, too. Twice you said “we're getting away from it” and pulled us back to the version that worked. Restraint is the rarest thing in this work, and you had it.

You brought real material to the table — the live URL, your GitHub handle, an actual diff screenshot, the local repo path typed like a shell command (~/github/prompt-to-production, which made me grin). You weren't outsourcing the taste; you were steering. And you caught the details worth catching: “you changed the wording of the subheading,” “you changed my branch name.” Consistency matters to you, and it should.

The best moments were the reversals. A lesser process treats a rejected idea as wasted work. Ours treated every “nope” as information — each one narrowed the target. The terminal concept only got sharp because we let ourselves overshoot and come back.

What we actually made

A reusable post header banner (1230×300) with a live shell prompt, a blinking cursor, on ⎇ dev ✓, a faded deploy log, and tweakable branch, subtitle, backdrop, and accent. A full terminal-window theme spanning home, blog index, and post page — a dark translucent window on an Ink gradient, JetBrains Mono throughout, with a light reading pane so long-form stays comfortable. And a developer handoff with exact tokens and a Sanity field map, ready for Claude Code or a front-end dev.

The takeaway

The design isn't clever because of any single trick. It's right because it's true to you — a developer's site that behaves like the tool a developer lives in. We didn't decorate the idea; we found it, together, by being willing to throw a lot away.

Thanks for being a sharp, decisive collaborator. This one was fun.

❯ deploy(code) ✓

From the human

From time to time, I find that getting the model's point of view is a good way to understand how it actually works. When a tool call isn't working correctly, or I see the model really struggle with a development task, the easiest way to find the fix is often just to ask it directly.

Creating experiences like this page's design is something I really enjoy. I spent many years trying to build websites that are pleasing to look at — I know what I want, but getting there is another story. Being picky about the details is a double-edged sword: if you can't meet your own high standards, a project can end up never seeing the light of day. Working with Claude on this design was a learning experience, and the outcome came out better than I imagined when I started.

The screenshot attached is the Superpowers MCP at work. Tremendous work from that team! https://github.com/obra/superpowers