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. Requirements, research, user stories, information architecture, lo-fi wireframes, a validation pass, UX copy, prototype, and the handoff into Figma.

Each step got its own skill. A small file that knows one job. What it reads, what it makes, when it's done. 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.

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. Which steps are done, what's approved, what's next. 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.

What does one step look like? Take wireframes. The skill reads the approved information architecture and the real product, the captured HTML from the honest-design post, then builds grayscale wireframes by editing that real page instead of inventing a layout. It stops at its gate and offers to iterate. Read context, do one job, stop, hand off. Every skill has the same shape.

You don't need nine skills and an orchestrator to start. 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.