I turned my design process into a dozen small skills, not one giant prompt

The first version of my design workflow was one enormous prompt. Thousands of words describing every step of how we design. I was pretty proud of it. It held together for about three steps and then quietly fell apart.

Not with an error. It failed the way a big prompt always does. The model lost the thread halfway down, blended two steps into one, skipped the one in the middle, and handed me something that looked like process but wasn't. And I couldn't fix it, because touching one part broke three others. One block of text, no seams.

The deeper problem was worse than maintenance. A single prompt gave the AI nowhere to stop. It ran from requirements straight to a prototype in one breath, sailing past every point where a human should have said "wait." It was automating the exact thing I'd promised to keep human.

Think of it as a team, not a prompt

The fix was to stop treating it as a prompt and start treating it as a team. A team isn't one person holding the whole job in their head. It's small roles with clear handoffs, and a check before the next person picks it up. Obvious if you've built software. It wasn't obvious to me, and I learned it the slow way, watching that giant prompt collapse under its own weight.

So I cut our process into its actual steps. At Xflow that's nine of them.

1. Requirements
2. Research
3. User stories
4. Information architecture
5. Lo-fi wireframes and task flows
6. Validate design
7. UX copy
8. UX prototype
9. Prototype to canvas, which is the handoff into Figma

Each step got its own skill. A small file that knows one job. On top sits a thin orchestrator that doesn't know how to do research or draw a wireframe. It only knows the order, that research comes after requirements, and hands off between the skills.

What a skill actually looks like

This is the part I'd have wanted to see, so here it is. Every one of those files opens with the same five-line contract before it says anything else:

inputs:     what must already exist before this step may start
outputs:    the files this step is responsible for writing
gate:       the question it stops and asks the designer
hard rules: the things it must never do, stated as prohibitions
not for:    the work that looks like this step's job and isn't

The first three are the obvious ones. The last two earn their keep constantly.

Hard rules are prohibitions rather than guidance, because "prefer the real component" is a suggestion and "never invent a component that isn't in the product" is a rule. And not for is the one I'd never have thought to write. Steps bleed. The copy step starts making layout calls, the wireframe step starts writing microcopy, and each of them is being helpful. Naming the adjacent job that isn't yours stops more drift than any amount of describing your own.

The part that actually mattered

Three things came out of the split. The first two I expected. I can rewrite the research step without touching the other eight. And I can run one step on its own to check it still behaves.

The third one is the whole point. Every skill ends at a checkpoint. The AI makes its thing, stops, and asks. Requirements done? It shows me and waits. I say yes, and only then does research start. The gates aren't a nicety. They're where the judgment lives. It's the augment-don't-automate rule turned into structure, because the AI physically can't roll past a decision when the step ends right before one.

The small thing that made it feel like a collaborator

There's a little state file for each project, one per feature. Which steps are done, what's approved, what's next, which route this feature is taking. Sounds boring. It's the thing that flipped this from a tool into a collaborator.

Because now I can shut the laptop mid-flow, come back a week later, and the AI reads that state and picks up exactly where we stopped. No re-explaining, no "remind me where we were." If you read the earlier post, this is the re-explaining tax finally paid off. The process remembers itself.

That file turned out to matter for a second reason I didn't see coming, which is that a cheaper model can read a fact but can't infer a mood. I wrote about that in a later post, because it changed how I write every instruction now.

One step, end to end

Take wireframes, step five.

It reads the approved information architecture from step four, plus the real captured page from the honest-design post. It writes grayscale wireframes by editing that real page rather than inventing a layout, one file per iteration, plus a note per iteration saying which mental model it's testing and what would make it win.

Its hard rule is that it never draws a control the product doesn't have. Its not for is copy, which belongs to step seven, so the wires carry placeholder text on purpose. And its gate is a plain question: here are the iterations, which do you want to take forward, and should any of the rejected ones stay parked with a note about what would revive them?

Read context, do one job, stop, hand off. Every skill has that shape.

Where to start

You don't need nine skills and an orchestrator. Take the longest prompt you use today and find the first natural seam, the spot where you'd genuinely want to check the output before going on. Cut it there. Put a plain "does this look right before I keep going?" between the two halves.

That's your first gate. You just turned a monologue into a workflow.

---

Part of a series on building an AI collaborator for our design team at Xflow. Each post stands on its own, and I'll link the rest as they go up.

Earlier: I gave the AI my design process, not my design decisions.