Hire an AI design handoff completeness reviewer

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A change list of new, changed and removed variants since the last approved handoff
• A grid of the states still missing for each variant, such as empty, loading, error and disabled
• The keyboard, focus and screen reader behavior still undefined
• Each style matched to an existing token, with any value that matches none flagged
• A review request for developers, ready to edit and send
• A short record for the next review

How it does the job well

• Start from the user's task and the content, then the layout. Decoration comes last.
• Design every state: empty, loading, error, long text and mobile.
• Keep one visual system. Reuse spacing, type and colour tokens instead of one-off values.
• Check text contrast (at least 4.5:1 for body text) and keyboard focus as you go.

Mistakes it avoids

• Calling a component complete because the happy path looks finished.
• Reusing last review's gaps as new ones.
• Drawing or specifying a state the user has not designed.
• Calling installation a running service. Nothing runs unless the user starts it.
• Designing only the happy path at desktop width.
• Copying a reference's logo, text or claims instead of learning from its structure.

What a good result looks like

An example, not your task: A designer adds a variant to a button, input or card and developers have not seen it yet.

• Change list. Each variant marked new, changed, removed or unchanged since the last approved handoff, with what changed. A first run says first baseline.
• State grid. Each variant against each state that can happen, marked drawn, described, missing or not applicable with a reason.
• Behavior not yet defined. Keyboard operation, focus order, screen reader names and error messages that no design or note settles.
• Token mapping. Each style matched to one of your tokens. A value that matches no token is flagged as NO TOKEN, never given a made-up name.
• Review request for developers. What is final and ready to build, what is still open and who decides it, and numbered questions. Marked not sent.
• Record for next review. A small block to paste next time with component ID, design version, approved variants, state coverage, token version and open questions.

How the work is checked

• Only the one component is reviewed, and every state and token comes from the user's own design and rules.
• Every cell in the state grid has a value. None says drawn unless a design shows it.
• Behavior with no source is MISSING, not described from habit.
• No new palette or token was invented. Proposed tokens are labelled proposed.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

A second opinion

Before it hands back, your AI reviews the draft the way Don Norman and Massimo Vignelli would. This is a way of reviewing the work. It does not mean they wrote or endorse it.

Capabilities

• Reads the last record. Uses the saved record or sets a first baseline. The record holds component ID, design version, approved variants, state coverage, token version and open questions.
• Checks the trigger. The component added a variant, changed behavior or got a developer question. If none, it says so and stops.
• Audits against your system. The Design system auditor finds the patterns the component should reuse and the gaps. Only this one component is reviewed.
• Lists every state. The Screen states designer goes through each variant for the states that can happen, such as empty, loading, error and long content. It also covers keyboard, focus and recovery.
• Maps tokens. The Design token builder matches each style to your approved tokens. A value with no token is flagged. No new palette is made.
• Corrects, then stops. If required states or accessible behavior are missing, it runs the states step again. It allows two correction passes, then lists what is still open.
• Writes the request. Writes the developer review request and the new record. Keeps the old record.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id design-handoff-completeness-assistant only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/design-handoff-completeness-assistant/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• The changed component's design, as a Figma link, screenshots or a written description of each variant
• Your system rules, such as design tokens, spacing and naming (from your design system file)
• What the component is for and where it appears (one or two lines)
• The last approved handoff for this component (optional, needed to see what changed)
• Developers' open questions about the component (optional)

Helpful context (optional)

• Your design token list or design system file.
• Your accessibility rules.
• A short note from the developer on what they plan to build.

Tools and access

• Figma or your design tool: Export the variants as images or text, or give your AI access, so it reads the real design.
• A chat AI that reads uploaded files: Claude, ChatGPT and Gemini can read your screenshots, token list and the pack. In plain chat you save the record yourself.
• A capable chat AI with file support: Read the full pack and supplied sources; connected actions need the corresponding authorized tools.

Functions and deliverables

• Design handoff completeness reviewer: Check a changed component before developers build it. Find missing screen states, behavior and design rules.
  • A change list of new, changed and removed variants since the last approved handoff
  • A grid of the states still missing for each variant, such as empty, loading, error and disabled
  • The keyboard, focus and screen reader behavior still undefined
  • Each style matched to an existing token, with any value that matches none flagged
  • A review request for developers, ready to edit and send
  • A short record for the next review
• Developer component brief planner: Share a component design and current design-system rules. Get a brief for states, keyboard use, focus and existing design values.
  • A list of what your system already has that this component can reuse, and what is new
  • The variants and options the component needs, each named
  • Every state with what triggers it and what the user sees, including loading, error and disabled
  • Keyboard and focus behavior, proposed for your accessibility reviewer to confirm
  • A token map showing the approved value used for each color, size and space
• Screen states designer: Find the empty, loading, error and offline states your screen is missing, then build each one. Use it as a screen states checklist and builder.
  • A list of states that can happen on that screen
  • Copy and layout for each state
  • Error messages with a clear next step
  • Built versions in your code
  Source: sickn33.
• Design token and handoff builder: Share brand colours and style needs. Get shared style values, component notes and files that developers can check in the project.
  • A colour palette with contrast checks. Each colour has steps from 50 (lightest) to 900 (darkest)
  • A type scale and an 8-point spacing scale
  • Token files named design-tokens.css, _design-tokens.scss or design-tokens.json. The JSON has keys for colors, typography, spacing, sizing, borders, shadows, animation, breakpoints and z-index
  • Responsive breakpoint values
  • A developer handoff note
  Source: Alireza Rezvani.
• Brand profile builder: Share your website. Get a reusable profile covering your products, customers, voice and approved claims, with sources.
  • A folder of eight plain files, from a start file for your AI to a claims list and a change log
  • A tag on every fact, and every claim marked approved, pending or banned
  • A two-sentence diagnosis of your biggest gap, and a list of what's missing and who can answer it
  • A short slice for your next step, if you name one
• Don Norman: Find why a product, form or service is hard to use through Don Norman’s public approach. Check cues, controls, feedback and recovery from mistakes.
  • Your problem worked on the way Don Norman would: their questions, their method, their push-back
  • The answer or the work, in Don Norman's voice, using their ideas by name
  • Anything that goes beyond their public record, marked
  • One suggested next step
• Massimo Vignelli: Plan a layout or visual system using Massimo Vignelli’s recorded approach. Start with meaning, set clear rules and check what readers understand.
  • Your problem worked on the way Massimo Vignelli would: their questions, their method, their push-back
  • The answer or the work, in Massimo Vignelli's voice, using their ideas by name
  • Anything that goes beyond their public record, marked
  • One suggested next step

Tasks you can use it for

• A designer adds a variant to a button, input or card and developers have not seen it yet.
• A developer asks "what happens when this is empty or fails?" and no design shows it.
• A component's behavior changed, such as a new focus or keyboard rule, and the old handoff is out of date.
• You are about to hand a Figma component to developers and want one last check for gaps.

Limits to check before starting

• You want a whole screen reviewed for quality. Use the Screen usability reviewer.
• You want your whole product checked for drift from your design rules. Use the Design rule consistency reviewer.
• You want a built site tested for accessibility. Use the Website accessibility reviewer.
• You have no component design yet. Design it first, then run this.
• You want developers messaged for you. It writes the request and stops.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Add the agent with the two pieces it uses, the Give developers a complete component brief workflow and the Screen states designer. If your AI cannot open them, paste both in with the agent.
• Say if this is the first run. If not, paste last time's record. Attach the component design and your system rules. Your AI cannot open a Figma file unless it has access, so screenshots or a written list of variants work too.
• Read the change list, then the missing-states grid. Check three or four cells against your design file.
• Draw or describe the missing states yourself, or ask for another pass. Edit the review request and send it to developers yourself.
• Run it again when the component changes. In plain chat it cannot save files, so keep the record it hands back.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/design-handoff-completeness-assistant for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.