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
- Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
- Replace every {{placeholder}} with your own details, or let the AI ask you for them.
- 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
- Ask for any missing inputs, then work only from what you have.
- Break the design into one ticket per component or screen section, not per pixel change.
- For each ticket list the states to build: default, hover, focus, active, disabled, loading, empty, error, and responsive behaviour at each breakpoint.
- Reuse existing components where possible and say which ones.
- Order tickets by dependency and mark which can run in parallel.
- Give each ticket acceptance criteria a reviewer can check.
- 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".