Hire an AI developer component brief planner

Everything it can hand back

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

• 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

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

• Inventing states, token values or accessibility behavior the design does not support.
• Making a new palette or type scale when the system already has one.
• Treating proposed keyboard behavior as confirmed.
• Listing a reused component you did not find in the files.
• 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 hands over a new dropdown, date picker or card and the developer asks what happens on error.

• Reuse list. Which existing components and tokens this one can reuse, what is new, and any naming clash.
• Variants. Each variant and option, such as size, tone and with or without icon, and when each is used.
• State table. Every state with its trigger, what the user sees and how it ends, with gaps marked MISSING.
• Keyboard and focus. Proposed keys, focus order and focus ring behavior for each state.
• Token map. The approved token and value for each color, size and space, and any value not in your system.
• Developer notes. Open questions, checks for the finished build and the person who must decide each gap.

How the work is checked

• Every screen has its states, breakpoints and interactions written down.
• Colour pairs and type sizes pass the stated contrast checks.
• The handoff names components, tokens and open questions.
• 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 would. This is a way of reviewing the work. It does not mean they wrote or endorse it.

Capabilities

• Design system auditor. Lists the components, tokens and naming your system already has and finds the closest match to this component. Marks what is new and what clashes. Hands step 2 the reuse list and the gaps. Check before moving on, every reused component exists in your files.
• Screen states designer. Defines each state the component can be in and the move between states, including interruption and recovery. Writes keyboard and focus behavior for each. Hands step 3 the states with the styles each one needs. Check before moving on, loading, error and disabled are each defined or marked MISSING.
• Design token builder. Maps each color, size and space in the component to a token, using component mapping and developer handoff modes. Keeps your approved values and makes no new palette. Hands back the token map and developer notes. Check before moving on, no value appears that is not in your system or marked as new.

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 give-developers-a-complete-component-brief 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/give-developers-a-complete-component-brief/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 component design, as a Figma link, screenshot, code or a written description
• Your design system rules or token file, so the brief reuses approved values (optional, but gaps show up without it)
• The user tasks the component supports, such as pick a delivery date
• The platforms it must work on, such as web and iOS (optional)
• Any limits, such as a UI library the developers must use (optional)

Helpful context (optional)

• Approved examples of a good result.
• A named reviewer and their acceptance rules.

Tools and access

• A capable chat AI with file support: Read the full pack and supplied sources; connected actions need the corresponding authorized tools.

Functions and deliverables

• 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
• Design system reviewer: Share components and style rules. Check consistency, document variants and states, or propose a new pattern that fits the system.
  • Audit list of inconsistencies
  • Component documentation with variants
  • Design for a new pattern
  • Fixes for naming and tokens
  Source: Anthropic.
• 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

Tasks you can use it for

• A designer hands over a new dropdown, date picker or card and the developer asks what happens on error.
• Two teams are about to build their own version of the same component.
• You are moving a Figma component into code and want variants and tokens written down once.
• A component keeps coming back from review because focus, loading or disabled states were never defined.

Limits to check before starting

• You only want to find states missing from a component that changed. Use the Design handoff completeness reviewer.
• You want working code, not a brief. Use the Accessible UI builder.
• You need new colors, type sizes and spacing from one brand color. Use the Design token and handoff builder on its own.
• You want to find where a whole product drifts from its rules each month. Use the Design rule consistency reviewer.

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.

• Download the workflow pack and add it to your AI, such as Claude, ChatGPT or Gemini.
• Attach the component design and your design system rules or tokens. Add the user tasks in one or two lines.
• After step 1, check that the reuse list names components you really have. Correct any it got wrong.
• After step 2, read the state table. Anything marked MISSING needs a decision from your designer before developers start.
• Step 3 reads your token values. If your AI cannot run code it returns the token map as a table and creates no token files. Then give the brief to a developer.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/give-developers-a-complete-component-brief 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.