# Turn a Figma ready for dev version into a Jira handoff ticket

> When a designer marks a version ready for development, we write the handoff spec, open the Jira ticket, and link it back onto the frame in Figma.

- Workflow type: agent
- Services: Figma, Jira, Slack Bot
- Categories: Engineering, Product
- Published: 2026-08-14

## What it does

- Watches for the moment a designer names a version something like Ready for dev, so nothing fires on ordinary edits or autosaves
- Compares that version against the one before it to work out which screens actually changed, and captures a picture of each one
- Writes a plain-language handoff covering what changed, which screens and states are affected, and what is still an open question, then opens a Jira ticket with it
- Links the new ticket back onto the frame inside Figma so designers see it in Dev Mode, and posts the summary to your engineering channel

## What you'll need

- A Figma account with access to the design files you want handed off
- A Jira project where the handoff tickets should be created
- A Slack workspace and a channel for engineering announcements
- Figma design files, since FigJam boards and Slides decks are skipped

## Prompt

When a designer publishes a named version in Figma that signals the work is ready for engineering, I want an agent to assemble the whole handoff for me. Trigger this from a Figma webhook on file version updates (FILE_VERSION_UPDATE), which fires when someone deliberately names a version rather than on ordinary autosaves. Only continue when the version name contains my handoff keyword. Make that keyword configurable, default it to "Ready for dev", and match it case-insensitively. If the version name does not contain the keyword, stop without doing anything.

Before touching the file, confirm it is a Figma Design file. The file and dev resource endpoints only support Design files, so a FigJam board (/board/) or a Slides deck (/slides/) should be skipped cleanly instead of failing with a file type error.

Use Get File Versions to identify the newly named version and the version immediately before it. Use Get File Nodes to inspect the frames that changed between those two versions. Keep the scope to just those top level frames rather than pulling the whole document tree, because Get File and Render Images are the most expensive Figma endpoints and the most likely to hit rate limits. Node IDs also need converting in both directions: Figma URLs use hyphens (node-id=1-2) but the API expects colons (1:2), so send colons to the API and build hyphens back into any link you create.

Before creating anything, call Get Dev Resources for those frames. This decides the path for each frame. A frame with no linked ticket gets a brand new Jira issue. A frame that already has a linked ticket must not get a duplicate issue, so use Update Dev Resources to refresh the name or URL of the existing resource instead.

For the frames that need a new ticket, use Render Images of File Nodes to capture a PNG preview of each changed frame, and use Get Comments to pull in any designer notes sitting on those frames. Ignore comments that have already been resolved, since the point is to surface what is still open.

Then draft a plain-language handoff spec covering three things: what changed between the two versions, which screens and states are affected, and what is still an open question based on the unresolved comments. Write it for an engineer who has not been following the design work, so skip the design jargon and be specific about states such as empty, loading, and error wherever the frames show them.

Create the ticket with the Jira Create Issue operation. Put the handoff spec in the description, include the rendered frame previews, and include a deep link back to the exact Figma frame. Note that the Jira integration creates the issue and its description in one step and has no separate file upload operation, so the previews go into the description as image links rather than as uploaded attachments. Jira's description field uses Atlassian Document Format, so structure the spec as real paragraphs and headings. Figma render URLs expire after 30 days, so label the preview links with that expiry and treat the Figma deep link as the permanent reference for the ticket.

Once the issue exists, use Create Dev Resources to attach the new Jira ticket URL onto that frame inside Figma, so designers see the linked ticket in Dev Mode. Figma caps dev resources at 10 per node, so if a frame is already at the cap, update the least relevant existing resource rather than trying to add an eleventh.

Finally, post to my engineering channel using the Slack Send a Message operation. The message should name the file and the version, summarize what changed in a couple of lines, call out anything still open, and link both the Jira ticket and the Figma frame.

This needs Figma permissions for file contents, version history, comments, and dev resources, including write access to dev resources so the ticket link can be written back into the file.

## How to customize

- Change the keyword that signals a handoff, such as Ready for dev, Handoff, or Approved
- Choose which Jira project and issue type the tickets land in, and who they get assigned to
- Pick the Slack channel, and decide how much of the spec goes in the message versus the ticket

## FAQ

### What stops this from firing every time someone edits the file?

It only runs when someone deliberately names a version, and only when that name contains your chosen keyword. Everyday edits and autosaves are ignored, so the workflow fires when a designer actually declares the work done.

### What happens if the same screen gets marked ready twice?

Before creating anything, it checks the frame for a ticket that is already linked to it. If one exists, it updates that link instead of opening a second Jira ticket for the same screen, so you never end up with duplicates.

### Will this work with FigJam boards or Figma Slides?

No. It works on Figma design files only. Boards and slide decks are skipped automatically rather than causing an error.

### Do the screenshots stay in the ticket forever?

The image previews Figma generates expire after about 30 days. That is why every ticket also carries a permanent link straight to the exact frame in Figma, which stays accurate no matter how old the ticket gets.

### Can the ticket go somewhere other than Jira?

This version creates Jira issues. The same flow can be pointed at another tracker your team uses, and the rest of the handoff, including the link written back into Figma, works the same way.

Use this prompt in General Input: https://www.generalinput.com/prompts/turn-a-figma-ready-for-dev-version-into-a-jira-handoff-ticket