This is a practical guide for anyone using AI to move an idea towards something real. It gives you five ways to keep the people, context, decisions, and quality connected as the work moves.
What you’ll find here
Each move includes a clear takeaway, something you can try tomorrow, and an example of what it can look like in practice. Read the guide from start to finish, or jump to the point that feels most useful for your next piece of work.
Why it matters
AI makes it easier for more people to build, and to build faster. But speed can pull the work apart. Context gets lost, decisions become harder to trace, generated code moves forward without enough review, and people get involved too late to shape the outcome.
You don’t need a new process or a team-wide rollout to fix that. Start with the next piece of work in front of you. Use these five moves to help the next person see what matters, understand the thinking, and make a good decision.
Use this when
- You’re starting with a prompt, a rough idea, or an incomplete brief.
- The prototype is moving faster than the team’s shared understanding.
- The design, code, and decisions are starting to drift apart.
- You’re passing work to another craft, team, or production workflow.
- You want to move quickly without making the next decision harder.
The five moves
| Move | In practice | Ask yourself |
|---|---|---|
| Teach AI your design language | Give AI the language, tokens, patterns, and rules that make your product feel like your product. | Would this use our design language correctly? |
| Bring the team’s context together | Connect the knowledge and work people need as they move from the brief to design, prototype, code, and launch. | Could someone keep working on this without starting over? |
| Make room for judgement | Bring people together at useful moments to look at the work, question it, and improve it. | Where could human judgement change the direction? |
| Check the work before handoff | Use agents and skills to make prototype code safer and closer to production, not just to create more code. | What needs to be true before we can trust this? |
| Re-imagine the ‘ | Share the thinking, decisions, unknowns, and next questions—not just a file or link. | What does the next person need to know to make a good decision? |
Use this guide with your AI teammate
Psst. You don’t have to read this guide from top to bottom. Give it to your agent instead. Copy the prompt below into the AI tool you use, add the link to this page, and it will walk you through the five moves on a piece of your own work.
Read this guide in full. Ask me up to five questions, one at a time, about one real piece of work and where it stands. Then take me through the five moves, starting with the one that will help most. Keep one work record as we go. Never guess: mark anything assumed, missing or for me to decide. Pause after each move. If I stop, give me a summary to pick up from. End with one thing to try tomorrow.
Teach AI your design language
Give AI the right context. Without it, AI can create an interface that looks believable but feels wrong for your product. Use your design system to show how the product handles hierarchy, interaction, tone, accessibility, and design choices—not just which components to use.
What this looks like
Scenario: A designer needs to explore a new account settings flow quickly. A generic prompt produces a polished screen, but it uses the wrong components, spacing, content patterns, and interaction states.
AI tool, skill, or feature: An AI prototyping tool connected to the team’s design system library, tokens, examples, and written guidance.
Job to be done: Create a first pass using the real design language, and flag any gaps instead of inventing new patterns.
Try this tomorrow
- Give the tool a short, reliable source of truth: foundations, tokens, components, patterns, content rules, and examples.
- Be clear about what it must not invent, including colour roles, spacing, typography, interaction states, accessibility needs, and responsive behaviour.
- Show it both the preferred pattern and an edge case. The contrast helps AI understand where the boundaries are.
- Ask it to explain which tokens and components it used, not just show the finished result.
- Add useful corrections back to the shared context so you don’t have to fix the same mistake in every prompt.
Good signal: the result feels like it belongs in the product, uses the right building blocks, and avoids unnecessary new decisions.
Watch for: screens that look convincing but use random values, duplicate components, miss important states, or have poor contrast.
Read [our design system] and use only its tokens, components, patterns and content rules for this work. If you cannot see it, ask me for it rather than guess. Never invent new ones. Where nothing fits, stop and give me options to choose from. Finish by listing anything assumed, missing or for me to decide.Each move ends with a prompt you can copy into any AI tool. Where you see [square brackets], paste or attach your own material.
Bring the team’s context together
Keep the context with the work. Don’t put everything in one huge repository. Connect the few sources people need to move from the brief to design, prototype, code, and launch without losing the thinking along the way.
What this looks like
Scenario: A product manager, designer, and engineer are working on onboarding. The brief, research, prototype, decisions, and code live in different places, so each person spends time rebuilding the same context.
AI tool, skill, or feature: An AI assistant or search tool connected to the team’s live briefs, research, decisions, prototypes, and code.
Job to be done: Bring together the latest context, show where a decision came from, and tell the next person what is settled and what is still open.
Connect the chain
Problem and intent → brief → design language → prototype → implementation → evidence → launch learning
At each stage, keep a link to the last decision and the next question. A prototype shouldn’t have to explain itself from scratch. Code shouldn’t be the first place someone learns how the interaction works. A launch update should include the unknowns that shaped the work, not hide them.
Try this tomorrow
- Write a short context header with the problem, audience, outcome, limits, and open questions.
- Link the important work together. A few live sources are better than a large folder of disconnected exports.
- Write down decisions while they’re fresh. Include options you rejected when they help explain an important limit or choice.
- When moving work from one format to another, ask the tool to keep the original thinking and flag anything it can’t carry across.
- Make the unknowns clear. Label what is decided, assumed, being tested, and not yet safe to reuse.
Good signal: someone new can understand why the work exists, what has been decided, and where they can help within a few minutes.
Watch for: a polished prototype with no clear problem, a ticket that only links to a screenshot, or documentation that shows the final answer but not the thinking behind it.
Read [the brief and notes] and start a one-page work record: the problem, what is decided, why and by whom, what is still unknown, and the evidence for each point. Mark anything assumed, missing or for me to decide. Finish by checking that someone new could follow it in five minutes.
Make room for judgement
Use automation to move faster, but bring people in when their judgement can improve the work. Skip meetings that only report activity. Create moments where the right people can look at the work, question an assumption, and improve what happens next.
What this looks like
Scenario: An AI-generated prototype looks finished, but the team hasn’t agreed on the main user need, the difficult edge cases, or which trade-offs they’re willing to make.
AI tool, skill, or feature: An AI review skill that summarises the current approach, calls out assumptions, and prepares the open questions for a short working session.
Job to be done: Help the team spend its time making the decisions that need human judgement, rather than using the meeting to share updates.
Use judgement moments, not status meetings
| Moment | Bring | Decide |
|---|---|---|
| Shape | The problem, early work, and different ways of looking at it | What are we solving, and what is out of scope? |
| Inspect | The working prototype or code, including the awkward states | What should change before we invest more? |
| Prepare | The proposed approach, risks, and production limits | What is safe to take forward? |
| Reflect | The result, evidence, and anything that surprised us | What should we repeat, change, or stop? |
Try this tomorrow
- Invite the person who owns the problem, the person shaping the experience, and the person who will make it real.
- Look at the work together. Don’t rely on a pre-read that people may not open.
- Ask each person to name one thing that is clear, one thing that is uncertain, and one thing they would change.
- Finish with a decision, an owner, or a clear reason to keep exploring.
Good signal: working together changes the work, and everyone leaves knowing what needs to be decided next.
Watch for: reviews that only happen once the work looks finished, feedback that isn’t tied to the work, or meetings where everyone agrees, but no one knows what happens next.
Help me plan a review of [this work] that ends in a decision, not a status update. Ask me who is involved, then give each person the two or three questions they are best placed to answer. Draft a short agenda. Leave every call to us. Afterwards, turn my notes into the decision, an owner and the next step.
Check the work before handoff
Use prototype code to make an idea real enough to see and try. But don’t let speed hide unfinished thinking, fragile code, accessibility problems, or a path to production that no one owns.
Use generated code, but don’t trust it by default. Review it, test it, and make it safer one step at a time.
What this looks like
Scenario: A prototype proves that an idea works, and the team wants to move it into the product. The generated code has hard-coded values, repeated logic, missing states, and no tests.
AI tool, skill, or feature: A coding agent that can follow repository guidance and run the team’s linting, testing, accessibility, and security checks.
Job to be done: Inspect and strengthen the prototype, explain what still isn’t production-ready, and suggest the smallest safe changes before handoff.
Use agents to improve the work, not only extend it
- Inspect: ask the agent to map the code, dependencies, states, assumptions, and known gaps.
- Constrain: give it the repository rules, component APIs, token rules, accessibility needs, and test commands.
- Harden: ask it to cover error, loading, empty, keyboard, responsive, and recovery states.
- Verify: run the checks. Ask the agent to explain any failures and suggest the smallest safe fix.
- Review: have a person review the code changes, not just the screen. Look for repeated code, hidden state, unnecessary dependencies, and unclear ownership.
- Record: write down what is ready for production, what is only for the prototype, and what still needs a decision.
Good signal: the prototype becomes easier to understand and safer to change as it gets closer to production.
Watch for: generated code that no one can explain, repeated logic, hard-coded content, missing tests, ignored warnings, or a growing gap between the demo and the real product.
Review [this prototype code] before handoff. If you cannot see it, ask me to paste it, and ask what it is for: a demo, user testing or production. Look for missing states (loading, empty, error), hard-coded values, accessibility problems and repeated code. Sort findings into safe fixes and design decisions for me. Tell me what you could not check. Change nothing until I approve.
Re-imagine the ‘handover’ handshake
Treat handover as a shared step, not the moment one person finishes and passes the work on. AI-assisted work makes building more continuous. Stay involved in the choices, states, quality, and details that shape how the work gets built.
What this looks like
Scenario: A designer shares a finished prototype with engineering. The screens look clear, but the decisions, rejected options, edge cases, and open questions aren’t visible.
AI tool, skill, or feature: An AI handoff skill that gathers the brief, design decisions, prototype states, system references, and unresolved questions into one implementation-ready summary.
Job to be done: Carry the thinking with the work so the next person can make good decisions without guessing or rebuilding the context.
Pass on the thinking, not just the work
Give the next person what they need to keep the work moving:
- Intent: What are we trying to make better?
- Evidence: What did we see, test, or learn?
- Decisions: What did we agree on, and why?
- Uncertainty: What is still open, risky, or being tried?
- Constraints: What does the implementation need to respect?
- Quality bar: What does good look like for behaviour, accessibility, content, and fit with the system?
- Next move: What happens next, who owns it, and what needs to be decided?
Try this tomorrow
- Instead of saying, “Here is the file,” say, “Here is what we’re solving, what we decided, and what still needs judgement.”
- Include the states people often miss: empty, loading, error, permission, edge, and recovery states.
- Show how the work connects to the system, including components, tokens, content, data, and implementation limits.
- Stay involved when the original thinking could get lost or the quality could slip. That’s a better stopping point than simply sending the file.
- Bring the next craft into the work before the approach becomes hard to change.
Good signal: the next person can keep the work moving without guessing what you meant or rebuilding the context.
Watch for: “handoff complete,” meaning only that someone sent a link, or a designer being asked to approve something they had no chance to shape.
Using [this work and its record], write a handshake note so [the next person] can carry on without guessing. Cover intent, evidence, decisions and why, open questions, constraints, the quality bar and the next move. Use only what I have given you. Mark anything assumed, missing or for me to decide, and ask me before you finish.A field guide for your next piece of work
Before you build: What is the problem? What context does the tool need? What must it not invent?
While you build: Who needs to see this now? Whose judgement could make it better? Which choices are becoming harder to change?
Before you share: What is decided, uncertain, experimental, reusable, or not ready?
Before you ship: Has someone reviewed the code? Has it been strengthened, tested, and connected to the real system?
After you ship: What did we learn, and where should we keep that learning?
Move quickly, but leave the work clearer than you found it. Give AI enough context to be useful. Give people enough information to use their judgement. Give the next person what they need to keep the work moving.
