Lock design before code:
the theme file holds every color, size, and spacing as a named value
components get built once, from the theme
screens become arrangements, not inventions
Decisions made calm beat choices made tired.
Flat icons beat emoji in product UI for three boring reasons:
they render the same on every device
they follow your color palette
you own the files
Emoji are someone else's design system living inside yours.
By the time code starts, design is a solved problem. The agents building screens reference the theme file the same way image generation references a canon file.
Same trick everywhere: write it down once, point everything at it.
Second: pick the components before building screens. List every button, card, and input the feature needs. Build each one once, from the theme.
Screens then become arrangements, not inventions.
Third: the no list. Same idea as the PRD, but for design. No gradients. No emoji as icons. No new colors mid-build.
A rule you wrote calmly in advance beats a choice you make at 11pm in a code editor.
First artifact: a theme file. Colors, type sizes, spacing, corner radius. Named values, nothing hardcoded.
Mine is five colors, and it is allowed to feel limiting. Limits are the system working.
Part 3 of idea to PRD to build: lock the design before the code.
Every design decision made during coding is made tired, in a hurry, and out of context. So I make them all first.
I generated a group shot of 9 characters and every single one came out slightly wrong.
Group generations degrade each character. Now I generate each one solo against their spec, then compose the group in layout.
Solo on canon, compose after.
One person, three agents:
the content agent makes the thing
the deploy agent ships the thing
the security agent checks the thing
None of them can do the others' jobs. That is the feature, not the limitation.
A design token is a name for a design decision.
Instead of pasting the same hex code in forty places, you write it once as accent-lime and reference the name.
Change the value, everything updates. That is the whole idea, and it scales from one app to a whole brand.
The pattern is older than software: separation of duties.
One agent with all three jobs would trade safety for convenience every time it got stuck. Three narrow agents beat one clever one.
I run three AI agents with three different jobs: one makes content, one deploys, one guards security.
Splitting them was the single biggest upgrade to my solo workflow. Here is why.
The security agent, I named him Tecumseh, reviews anything touching auth, payments, or user data. He audits and hardens.
He does not build features, so he has no reason to go easy on the code.
My posting script writes a checkpoint file after every API request.
Feels like overkill until a batch dies at post 40 of 58 on a rate-limited API.
Re-running picked up at 41. No double posts, no cleanup. Boring code saves weekends.
My build process is four handoffs:
the idea becomes one page
the page becomes a plan
the plan becomes the build, checked chunk by chunk
the build ships when the done sentence is true
The page does the steering. The code just follows.
An agent skill is a saved instruction file your AI agent loads on demand.
Write the workflow once: the steps, the rules, the gotchas. After that, one short command runs the whole thing the same way every time.
A recipe card for your agent.
Ship test: hand the phone to someone who was not in the room. If they hit play and it works in airplane mode, the done sentence is true and we ship.
Part 3 next: locking design decisions before code.
Last time I showed how a messy idea becomes a one-page PRD.
Part 2: how that page drives the actual build. Same real feature, an offline song player for a kids app.
Then the build runs step by step, and I check the app preview after each chunk. Not at the end. Each chunk.
Catching a wrong turn at step 2 costs minutes. At step 9 it costs the afternoon.