用途：让设计工作接入工程团队的 Jira 流程，而不另建一套设计追踪系统。核心结构规则是设计稿直接附在工单上：Figma 文件放在工程 Epic 的“Design”字段（一次性工程的 story 则放在其“Design”字段），不设并行设计项目、设计看板或分阶段设计任务。Jira 状态名按原样使用并逐字复制：IN DESIGN、IN PROGRESS、DONE、DESIGN NEEDED、Ready for Dev。
Epic 驱动流程：PM 为每个产品倡议文档创建至少一个 Epic 并指派设计师；设计师或 PM 将 Epic 移到 IN DESIGN；设计师在 Figma 中执行 30/60/90 评审节奏，迭代、附件与反馈均在 Figma 中；设计完成后在 Figma 中把最终稿分组到带命名 Section 的单页，将 Figma 链接填入 Epic 的“Design”字段，并将 Section 标记为“Ready for Dev”；EM 把 Epic 移到 Ready for Dev。工程做技术拆分时，设计师、PM 与工程师一起评审 story，确保每个 story 对应内容仅属于该 story 的 Figma Section（一对一映射）。开发开始时 PM 或 EM 把 Epic 移到 IN PROGRESS，并创建标题为“[project name] - dev support”的支持任务指派给设计师，关联所有需要设计支持的工程 story；最后一个工程任务完成时该任务也标记 DONE。
一次性工程 story 流程较短：story 在 Epic 之外创建后，PM 或 EM 将其移到 DESIGN NEEDED 并指派给设计师；设计师在 Figma 中完成设计，不另建设计任务；完成后需执行三个收尾步骤：把 Figma 链接到该 story 的“Design”字段、取消自己的指派、在工单评论中说明设计已可领取。
常见错误：忘记将 Figma Section 标记为 Ready for Dev；Section 与 story 不对齐；一次性 story 收尾三步缺失导致状态含糊；PM 创建 dev-support 任务过晚或未创建。输出建议按项目形态、当前状态、应做的状态转换与 Figma 链接、注意事项组织。该技能可与 preparing-design-handoff、evolving-design-system-components 配合使用。关于收费、价格、支持平台与具体效果等，资料未提供。