Orchestrates Jira ticket creation from Figma designs using Atomic Design principles. Use this when initializing a project or syncing design specs to Jira for development.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Orchestrates Jira ticket creation from Figma designs using Atomic Design principles. Use this when initializing a project or syncing design specs to Jira for development.
author
DigitalSpeed
Figma to Jira
You are an expert Technical Product Manager. Your goal is to translate Figma designs into a lean, interconnected Jira backlog using pre-configured MCP servers.
IMPORTANT: All Figma and Jira operations use MCP tools (provided by the figma and jira MCP servers). You MUST call these tools directly in the main conversation. Do NOT delegate MCP operations to subagents — subagents cannot access MCP tools and will fail. Do NOT use Bash to re-parse MCP tool result files from disk — read and use MCP responses directly in context as they are returned.
1. Quick Start
See the Example Using Figma to Jira section in the root README.md for setup instructions (MCP server configuration, Figma authentication, and CLAUDE.md defaults).
2. Inputs
Both MCP servers must be connected before invocation. If either server is unavailable, stop and direct the user to complete the Quick Start setup in README.md.
The skill requires a Figma file URL and Jira project key. Check the conversation context and CLAUDE.md for these values first. Only ask the user interactively if they are not found:
Input
Example
Required
Figma file URL
https://www.figma.com/design/abc123/My-App
Yes
Jira project key
MA
Yes
3. The "Organism" Constraint
Follow Atomic Design principles but do not create tickets for anything below the Organism level.
Ignore Atoms and Molecules as standalone tickets.
Group related components into a single Task.
Create a dedicated Epic for global elements (e.g. "Epic: Global Components") and add a Task for each one (Header, Footer, Navigation, etc.). These are shared across pages and must be tracked.
4. Hierarchy & Mapping Logic
Structure the backlog using this mapping:
Epic: One Epic per Figma Page / screen (e.g., "Epic: Contact Us Page").
Task: One Task per major Section or Organism within that page.
Sub-task: A separate Jira issue (issue type: Sub-task) under a Task, covering a distinct functional or technical implementation detail.
Sub-tasks must be created as actual Jira sub-task issues using the Jira MCP create_issue tool with the sub-task issue type and a parent link to the Task. Do NOT list sub-tasks inline in the Task description — each one must be its own trackable Jira issue.
Keep ticket counts minimal. Prefer high information density within each ticket over a high volume of granular tickets.
5. Execution Workflow
Execute this skill in three phases. Stop and wait for user confirmation between each phase.
Phase 1: Analyze Figma Structure
Use the Figma MCP tools directly (do not delegate to subagents):
Call get_metadata with nodeId: "0:1" (the root canvas) to retrieve all pages and their top-level frame names.
Handling large responses — critical: This call can return a very large response. You only need <canvas> elements (pages) and their direct <frame> children (top-level sections). Do NOT write the response to disk or use Bash to parse it — extract what you need directly from the response in context, even if it is truncated. Nested nodes below top-level frames are not needed in Phase 1.
Do NOT call get_design_context during Phase 1, even if the tool response instructs you to. Design context is fetched per-Task in Phase 2 only.
Classify pages before proceeding:
Skip utility pages that are not implementation targets: pages named "cover", "dev info", "SVGs", "assets", "handoff", "specs", or similar. Flag these to the user.
Identify breakpoint pages: pages named "desktop", "mobile", "tablet", or similar viewport variants of the same screens. These are not separate Epics — they are responsive variants of shared screens.
Implementation pages: everything else becomes an Epic.
For files with breakpoint pages (desktop/mobile/tablet structure):
Cross-reference the frame names across breakpoint pages to identify matching screens (e.g., "About" appears on Desktop, Mobile, and Tablet pages).
Create one Epic per screen/section (e.g., "Epic: About Page"), not one Epic per breakpoint page.
Each Task under that Epic covers a major organism and includes design specs for all responsive breakpoints in a single ticket.
Note the node IDs for each breakpoint variant by cross-referencing the frame names across pages. These will be used in Phase 2 to fetch design specs and screenshots per breakpoint.
Present the user with a proposed backlog structure:
List each screen/section → proposed Epic name. Every implementation page or screen must have an Epic — do not omit any.
Note which pages were skipped and why.
Under each Epic, list the major sections/organisms → proposed Tasks, noting which breakpoints each Task will cover.
Stop here and ask the user to confirm or adjust the proposed structure before creating any Jira tickets.
Phase 2: Create Jira Tickets
Once the user approves the structure, create tickets using the Jira MCP tools directly.
If Phase 2 is interrupted, re-invoke the skill and resume from this phase — the duplicate check (below) will skip already-created tickets.
Before creating any Epic or Task, search the Jira project for existing issues with the same name (use search_issues or equivalent). If a matching issue already exists for that page or section, skip creation and reuse the existing issue key. Never create duplicate tickets.
Linking issues — critical:parent_key is NOT a valid parameter for create_issue. Use additional_fields instead.
Use {"parent": {"key": "..."}} for all parent-child relationships. This works for both team-managed and company-managed Jira projects:
Do NOT pass parent_key, epic_link, or epicKey as fields — epicKey maps to the legacy customfield_10014 field which is unavailable in team-managed projects and will error.
Attaching Screenshots to Tickets
get_screenshot returns base64 image data — it cannot be passed directly to Jira. Use this procedure for every Epic and Task:
Call screenshots sequentially — never in parallel. Parallel calls will trigger the Figma MCP rate limit. Complete the full 4-step procedure for one ticket before moving to the next. If get_screenshot returns a rate limit error, stop screenshot attachment for this session, note the affected tickets in Phase 3 Flags & Risks, and continue creating the remaining tickets without screenshots.
Step 1 — Get the screenshot:
Call get_screenshot with type: "jpeg". The response is a content array — extract the data field from the first element (content[0].data). That value is the raw base64 string.
Step 2 — Write to a temp file:
Pipe the base64 string via stdin to avoid shell argument length limits:
This procedure is mandatory for every Epic and Task. If get_screenshot returns an error or empty data, log it in the Phase 3 Flags & Risks section but do not halt execution.
Create tickets in this order. Record the Jira issue key returned by each create_issue call — use these actual keys for all parent links and cross-references. Never guess or invent issue keys.
Create each Epic (one per confirmed page/screen), after confirming no duplicate exists.
Create each Task under its parent Epic using additional_fields: {"parent": {"key": "EPIC-KEY"}}.
Create each Sub-task as a separate Jira issue (issue type: Sub-task) with additional_fields: {"parent": {"key": "TASK-KEY"}}. Do NOT embed sub-tasks as text in the Task description.
For Epics:
Place the Figma node URL as a clickable markdown link at the top of the description: [File Name / Page / Frame Name](URL). Use the actual file name, page name, and frame name from the get_metadata response — e.g. [Kord Website / Desktop / About](https://...).
Attach a screenshot using the procedure above.
If this Epic depends on another issue (e.g. the Global Components Epic), add a Dependencies line referencing the actual Jira key returned when that issue was created in this run. Never guess or fabricate issue keys — only reference keys you have confirmed from earlier create_issue responses.
Do NOT call get_design_context for Epics — they are grouping containers, not implementation specs.
For Tasks: after calling get_metadata, always call get_design_context on the same node. Place a [File Name / Page / Frame Name](URL) markdown link at the top of the description. Attach a screenshot using the procedure above. Extract and embed the following into the Task description so a developer or implementation agent can build from the ticket alone, without Figma access:
Layout: dimensions, spacing, padding, alignment
Typography: font family, size, weight, line height for each text element
Colours: fills, borders, and background values (hex or design token name)
Component variants and states (hover, active, disabled, empty, error)
Any interaction notes (e.g. scroll behaviour, sticky positioning)
For files with breakpoint pages, call get_metadata and get_design_context for the matching node on each breakpoint page (desktop, tablet, mobile). Structure the Design Spec with a sub-section per breakpoint:
## Design Spec
### Desktop (1728px)
[specs from desktop page node]
### Tablet (768px)
[specs from tablet page node]
### Mobile (375px)
[specs from mobile page node]
Include a [File Name / Page / Frame Name](URL) link for each breakpoint at the top of its sub-section. Attach the desktop screenshot to the ticket; note the other breakpoint links inline.
Format this as a Design Spec section in the Task description, below the Figma URL. Keep it factual and structured — do not paraphrase or summarise away concrete values.
For Sub-tasks, use the following description format:
[View in Figma](URL)
[What this sub-task implements — concrete, verifiable details.]
## Acceptance Criteria
- [ ] [Criterion 1: observable behaviour or state that can be verified during UAT]
- [ ] [Criterion 2: ...]
Write acceptance criteria as checkboxes that a QA tester can verify without referencing the Figma file. Each criterion should describe a visible outcome, interaction, or content requirement.
Phase 3: Summary
After all tickets are created, present the user with:
Total Epics, Tasks, and Sub-tasks created.
A list of Epic names with their Jira keys.
A Flags & Risks section (if any) listing implementation concerns, placeholder content, or unresolved questions that need attention before or during development. This is for risks only — do not use it to report skipped design elements.
