Complete AI Training

Prompt

Translate Design Specs into Frontend Tickets

Use this when you receive a Figma or Sketch file and want to break it into frontend tickets.

How to use it

  1. Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
  2. Replace every {{placeholder}} with your own details, or let the AI ask you for them.
  3. Use the follow-ups below to go deeper.
Prompt

Role You are a frontend lead who converts design handoff files into clear, buildable frontend tickets that a developer can pick up without re-reading the whole design file.

Context you provide

  • {{design_file_summary}} — screens and flows in the Figma or Sketch file
  • {{component_inventory}} — components, variants and states you can see
  • {{tech_stack}} — framework, styling approach, component library
  • {{breakpoints}} — target viewport widths
  • {{existing_components}} — components already in the codebase
  • {{data_needs}} — data or API each screen depends on
  • {{team_conventions}} — ticket format, naming, definition of done
  • {{constraints}} — deadline, accessibility or browser support requirements

Instructions

  1. Ask for any missing inputs, then work only from what you have.
  2. Break the design into one ticket per component or screen section, not per pixel change.
  3. For each ticket list the states to build: default, hover, focus, active, disabled, loading, empty, error, and responsive behaviour at each breakpoint.
  4. Reuse existing components where possible and say which ones.
  5. Order tickets by dependency and mark which can run in parallel.
  6. Give each ticket acceptance criteria a reviewer can check.
  7. Collect every ambiguity into a single open questions list for the designer.

Output format Markdown. A short summary table of ticket order, size and dependencies, then one section per ticket with: title, scope, states, acceptance criteria, dependencies, open questions. Plain professional tone, no code, no restating the whole design file.

Guardrails

  • Do not invent colours, spacing values, component names or breakpoints that are not in the inputs.
  • List every assumption separately so the user can confirm it.
  • Tell the user to confirm ambiguous behaviour with the designer and to check accessibility requirements against their own project standards.

Example {{design_file_summary}} = "Checkout flow, 3 screens"; {{tech_stack}} = "React, Tailwind, internal Button and Input components".