spec-to-backlog

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Spec to Backlog

规范转待办事项

Overview

概述

Transform Confluence specification documents into structured Jira backlogs automatically. This skill reads requirement documents from Confluence, intelligently breaks them down into logical implementation tasks, creates an Epic first to organize the work, then generates individual Jira tickets linked to that Epic—eliminating tedious manual copy-pasting.

自动将Confluence规范文档转换为结构化的Jira待办事项。该技能从Confluence读取需求文档，智能将其拆分为逻辑清晰的实施任务，先创建一个Epic来统筹工作，再生成与该Epic关联的独立Jira工单——彻底消除繁琐的手动复制粘贴工作。

Core Workflow

核心工作流

CRITICAL: Always follow this exact sequence:

Fetch Confluence Page → Get the specification content
Ask for Project Key → Identify target Jira project
Analyze Specification → Break down into logical tasks (internally, don't create yet)
Present Breakdown → Show user the planned Epic and tickets
Create Epic FIRST → Establish parent Epic and capture its key
Create Child Tickets → Generate tickets linked to the Epic
Provide Summary → Present all created items with links

Why Epic must be created first: Child tickets need the Epic key to link properly during creation. Creating tickets first will result in orphaned tickets.

重要提示：必须严格遵循以下顺序：

获取Confluence页面 → 获取规范内容
询问项目密钥 → 确定目标Jira项目
分析规范 → 拆分为逻辑任务（仅内部处理，暂不创建）
展示拆分结果 → 向用户展示计划创建的Epic和工单
先创建Epic → 建立父级Epic并记录其密钥
创建子工单 → 生成与Epic关联的工单
提供汇总信息 → 展示所有已创建的项目及链接

为何必须先创建Epic： 子工单在创建时需要Epic密钥来建立关联。如果先创建工单，会导致工单成为无关联的孤立项。

Step 1: Fetch Confluence Page

步骤1：获取Confluence页面

When triggered, obtain the Confluence page content:

触发技能时，获取Confluence页面内容：

If user provides a Confluence URL:

如果用户提供Confluence URL：

Extract the cloud ID and page ID from the URL pattern:

Standard format:

https://[site].atlassian.net/wiki/spaces/[SPACE]/pages/[PAGE_ID]/[title]

The cloud ID can be extracted from

[site].atlassian.net

or by calling

getAccessibleAtlassianResources

The page ID is the numeric value in the URL path

从URL格式中提取cloud ID和页面ID：

标准格式：

https://[site].atlassian.net/wiki/spaces/[SPACE]/pages/[PAGE_ID]/[title]

cloud ID可从

[site].atlassian.net

提取，或调用

getAccessibleAtlassianResources

获取

页面ID是URL路径中的数值部分

If user provides only a page title or description:

如果用户仅提供页面标题或描述：

Use the

search

tool to find the page:

search(
  cloudId="...",
  query="type=page AND title~'[search terms]'"
)

If multiple pages match, ask the user to clarify which one to use.

使用

search

工具查找页面：

search(
  cloudId="...",
  query="type=page AND title~'[search terms]'"
)

如果找到多个匹配页面，请用户明确选择要使用的页面。

Fetch the page:

获取页面内容：

Call

getConfluencePage

with the cloudId and pageId:

getConfluencePage(
  cloudId="...",
  pageId="123456",
  contentFormat="markdown"
)

This returns the page content in Markdown format, which you'll analyze in Step 3.

调用

getConfluencePage

并传入cloudId和pageId：

getConfluencePage(
  cloudId="...",
  pageId="123456",
  contentFormat="markdown"
)

该接口会返回Markdown格式的页面内容，供你在步骤3中分析。

Step 2: Ask for Project Key

步骤2：询问项目密钥

Before analyzing the spec, determine the target Jira project:

在分析规范之前，确定目标Jira项目：

Ask the user:

询问用户：

"Which Jira project should I create these tickets in? Please provide the project key (e.g., PROJ, ENG, PRODUCT)."

"我应该在哪个Jira项目中创建这些工单？请提供项目密钥（例如：PROJ、ENG、PRODUCT）。"

If user is unsure:

如果用户不确定：

Call

getVisibleJiraProjects

to show available projects:

getVisibleJiraProjects(
  cloudId="...",
  action="create"
)

Present the list: "I found these projects you can create issues in: PROJ (Project Alpha), ENG (Engineering), PRODUCT (Product Team)."

调用

getVisibleJiraProjects

展示可用项目：

getVisibleJiraProjects(
  cloudId="...",
  action="create"
)

向用户展示列表："我找到了你可以创建问题的项目：PROJ（Alpha项目）、ENG（工程部）、PRODUCT（产品团队）。"

Once you have the project key:

获取项目密钥后：

Call

getJiraProjectIssueTypesMetadata

to understand what issue types are available:

getJiraProjectIssueTypesMetadata(
  cloudId="...",
  projectIdOrKey="PROJ"
)

Identify available issue types:

Which issue type is "Epic" (or similar parent type like "Initiative")
What child issue types are available: "Story", "Task", "Bug", "Sub-task", etc.

Select appropriate issue types for child tickets:

The skill should intelligently choose issue types based on the specification content:

Use "Bug" when the spec describes:

Fixing existing problems or defects
Resolving errors or incorrect behavior
Addressing performance issues
Correcting data inconsistencies
Keywords: "fix", "resolve", "bug", "issue", "problem", "error", "broken"

Use "Story" when the spec describes:

New user-facing features or functionality
User experience improvements
Customer-requested capabilities
Product enhancements
Keywords: "feature", "user can", "add ability to", "new", "enable users"

Use "Task" when the spec describes:

Technical work without direct user impact
Infrastructure or DevOps work
Refactoring or optimization
Documentation or tooling
Configuration or setup
Keywords: "implement", "setup", "configure", "optimize", "refactor", "infrastructure"

Fallback logic:

If "Story" is available and content suggests new features → use "Story"
If "Bug" is available and content suggests fixes → use "Bug"
If "Task" is available → use "Task" for technical work
If none of the above are available → use the first available non-Epic, non-Subtask issue type

Store the selected issue types for use in Step 6:

Epic issue type name (e.g., "Epic")
Default child issue type (e.g., "Story" or "Task")
Bug issue type name if available (e.g., "Bug")

调用

getJiraProjectIssueTypesMetadata

了解可用的问题类型：

getJiraProjectIssueTypesMetadata(
  cloudId="...",
  projectIdOrKey="PROJ"
)

识别可用的问题类型：

哪个问题类型是“Epic”（或类似的父级类型，如“Initiative”）
可用的子问题类型：“Story”、“Task”、“Bug”、“Sub-task”等

为子工单选择合适的问题类型：

技能会根据规范内容智能选择问题类型：

当规范描述以下内容时使用“Bug”：

修复现有问题或缺陷
解决错误或异常行为
处理性能问题
修正数据不一致
关键词：“fix”、“resolve”、“bug”、“issue”、“problem”、“error”、“broken”

当规范描述以下内容时使用“Story”：

新的用户面向功能
用户体验改进
客户要求的功能
产品增强
关键词：“feature”、“user can”、“add ability to”、“new”、“enable users”

当规范描述以下内容时使用“Task”：

无直接用户影响的技术工作
基础设施或DevOps工作
重构或优化
文档或工具相关工作
配置或设置
关键词：“implement”、“setup”、“configure”、“optimize”、“refactor”、“infrastructure”

降级逻辑：

如果“Story”可用且内容涉及新功能 → 使用“Story”
如果“Bug”可用且内容涉及修复 → 使用“Bug”
如果“Task”可用 → 用于技术工作
如果以上都不可用 → 使用第一个可用的非Epic、非Subtask问题类型

存储选定的问题类型供步骤6使用：

Epic问题类型名称（例如：“Epic”）
默认子问题类型（例如：“Story”或“Task”）
可用的Bug问题类型名称（例如：“Bug”）

Step 3: Analyze Specification

步骤3：分析规范

Read the Confluence page content and internally decompose it into:

读取Confluence页面内容并在内部将其分解为：

Epic-Level Goal

Epic级目标

What is the overall objective or feature being implemented? This becomes your Epic.

Example Epic summaries:

"User Authentication System"
"Payment Gateway Integration"
"Dashboard Performance Optimization"
"Mobile App Notifications Feature"

要实现的整体目标或功能是什么？这将作为你的Epic。

Epic摘要示例：

"User Authentication System"
"Payment Gateway Integration"
"Dashboard Performance Optimization"
"Mobile App Notifications Feature"

Implementation Tasks

实施任务

Break the work into logical, independently implementable tasks.

Breakdown principles:

Size: 3-10 tasks per spec typically (avoid over-granularity)
Clarity: Each task should be specific and actionable
Independence: Tasks can be worked on separately when possible
Completeness: Include backend, frontend, testing, documentation, infrastructure as needed
Grouping: Related functionality stays in the same ticket

Consider these dimensions:

Technical layers: Backend API, Frontend UI, Database, Infrastructure
Work types: Implementation, Testing, Documentation, Deployment
Features: Break complex features into sub-features
Dependencies: Identify prerequisite work

Common task patterns:

"Design [component] database schema"
"Implement [feature] API endpoints"
"Build [component] UI components"
"Add [integration] to existing [system]"
"Write tests for [feature]"
"Update documentation for [feature]"

Use action verbs:

Implement, Create, Build, Add, Design, Integrate, Update, Fix, Optimize, Configure, Deploy, Test, Document

将工作拆分为逻辑独立、可单独实施的任务。

拆分原则：

规模： 每个规范通常拆分为3-10个任务（避免过度细化）
清晰性： 每个任务应具体且可执行
独立性： 任务应尽可能可独立开展工作
完整性： 按需包含后端、前端、测试、文档、基础设施相关任务
分组： 相关功能放在同一个工单中

考虑以下维度：

技术层：后端API、前端UI、数据库、基础设施
工作类型：实施、测试、文档、部署
功能：将复杂功能拆分为子功能
依赖关系：识别前置工作

常见任务模式：

"Design [component] database schema"
"Implement [feature] API endpoints"
"Build [component] UI components"
"Add [integration] to existing [system]"
"Write tests for [feature]"
"Update documentation for [feature]"

使用动作动词：

Implement, Create, Build, Add, Design, Integrate, Update, Fix, Optimize, Configure, Deploy, Test, Document

Step 4: Present Breakdown to User

步骤4：向用户展示拆分结果

Before creating anything, show the user your planned breakdown:

Format:

I've analyzed the spec and here's the backlog I'll create:

**Epic:** [Epic Summary]
[Brief description of epic scope]

**Implementation Tickets (7):**
1. [Story] [Task 1 Summary]
2. [Task] [Task 2 Summary]  
3. [Story] [Task 3 Summary]
4. [Bug] [Task 4 Summary]
5. [Task] [Task 5 Summary]
6. [Story] [Task 6 Summary]
7. [Task] [Task 7 Summary]

Shall I create these tickets in [PROJECT KEY]?

The issue type labels show what type each ticket will be created as:

[Story] - New user-facing feature
[Task] - Technical implementation work
[Bug] - Fix or resolve an issue

Wait for user confirmation before proceeding. This allows them to:

Request changes to the breakdown
Confirm the scope is correct
Adjust the number or focus of tickets

If user requests changes, adjust the breakdown and re-present.

在创建任何内容之前，向用户展示你的计划拆分：

格式：

我已分析规范，以下是我将创建的待办事项：

**Epic:** [Epic摘要]
[Epic范围的简要描述]

**实施工单（7个）：**
1. [Story] [任务1摘要]
2. [Task] [任务2摘要]
3. [Story] [任务3摘要]
4. [Bug] [任务4摘要]
5. [Task] [任务5摘要]
6. [Story] [任务6摘要]
7. [Task] [任务7摘要]

是否要在[PROJECT KEY]中创建这些工单？

问题类型标签表示每个工单的创建类型：

[Story] - 新的用户面向功能
[Task] - 技术实施工作
[Bug] - 修复或解决问题

等待用户确认后再继续，这允许用户：

请求修改拆分结果
确认范围是否正确
调整工单数量或重点

如果用户请求修改，调整拆分结果后重新展示。

Step 5: Create Epic FIRST

步骤5：先创建Epic

CRITICAL: The Epic must be created before any child tickets.

重要提示： 必须在创建任何子工单之前创建Epic。

Create the Epic:

创建Epic：

Call

createJiraIssue

with:

createJiraIssue(
  cloudId="...",
  projectKey="PROJ",
  issueTypeName="Epic",
  summary="[Epic Summary from Step 3]",
  description="[Epic Description - see below]"
)

调用

createJiraIssue

：

createJiraIssue(
  cloudId="...",
  projectKey="PROJ",
  issueTypeName="Epic",
  summary="[步骤3中的Epic摘要]",
  description="[Epic描述 - 见下文]"
)

Epic Description Structure:

Epic描述结构：

markdown

undefined

markdown

undefined

Overview

[1-2 sentence summary of what this epic delivers]

[1-2句话总结该Epic交付的内容]

Source

Confluence Spec: [Link to Confluence page]

Confluence Spec: [Confluence页面链接]

Objectives

[Key objective 1]
[Key objective 2]
[Key objective 3]

[关键目标1]
[关键目标2]
[关键目标3]

Scope

[Brief description of what's included and what's not]

[简要描述包含和不包含的内容]

Success Criteria

[Measurable criterion 1]
[Measurable criterion 2]
[Measurable criterion 3]

[可衡量的标准1]
[可衡量的标准2]
[可衡量的标准3]

Technical Notes

[Any important technical context from the spec]

undefined

[来自规范的重要技术上下文]

undefined

Capture the Epic Key:

记录Epic密钥：

The response will include the Epic's key (e.g., "PROJ-123"). Save this key—you'll need it for every child ticket.

Example response:

json

{
  "key": "PROJ-123",
  "id": "10001",
  "self": "https://yoursite.atlassian.net/rest/api/3/issue/10001"
}

Confirm Epic creation to user: "✅ Created Epic: PROJ-123 - User Authentication System"

响应将包含Epic的密钥（例如："PROJ-123"）。保存该密钥——每个子工单都需要用到它。

响应示例：

json

{
  "key": "PROJ-123",
  "id": "10001",
  "self": "https://yoursite.atlassian.net/rest/api/3/issue/10001"
}

向用户确认Epic已创建： "✅ 已创建Epic: PROJ-123 - User Authentication System"

Step 6: Create Child Tickets

步骤6：创建子工单

Now create each implementation task as a child ticket linked to the Epic.

现在将每个实施任务创建为与Epic关联的子工单。

For each task:

每个任务的处理：

Determine the appropriate issue type for this specific task:

If the task involves fixing/resolving an issue → use "Bug" (if available)
If the task involves new user-facing features → use "Story" (if available)
If the task involves technical/infrastructure work → use "Task" (if available)
Otherwise → use the default child issue type from Step 2

Call

createJiraIssue

with:

createJiraIssue(
  cloudId="...",
  projectKey="PROJ",
  issueTypeName="[Story/Task/Bug based on task content]",
  summary="[Task Summary]",
  description="[Task Description - see below]",
  parent="PROJ-123"  # The Epic key from Step 5
)

Example issue type selection:

"Fix authentication timeout bug" → Use "Bug"
"Build user dashboard UI" → Use "Story"
"Configure CI/CD pipeline" → Use "Task"
"Implement password reset API" → Use "Story" (new user feature)

确定该任务的合适问题类型：

如果任务涉及修复/解决问题 → 使用"Bug"（如果可用）
如果任务涉及新的用户面向功能 → 使用"Story"（如果可用）
如果任务涉及技术/基础设施工作 → 使用"Task"（如果可用）
否则 → 使用步骤2中的默认子问题类型

调用

createJiraIssue

：

createJiraIssue(
  cloudId="...",
  projectKey="PROJ",
  issueTypeName="[根据任务内容选择Story/Task/Bug]",
  summary="[任务摘要]",
  description="[任务描述 - 见下文]",
  parent="PROJ-123"  # 步骤5中的Epic密钥
)

问题类型选择示例：

"Fix authentication timeout bug" → 使用"Bug"
"Build user dashboard UI" → 使用"Story"
"Configure CI/CD pipeline" → 使用"Task"
"Implement password reset API" → 使用"Story"（新用户功能）

Task Summary Format:

任务摘要格式：

Use action verbs and be specific:

✅ "Implement user registration API endpoint"
✅ "Design authentication database schema"
✅ "Build login form UI components"
❌ "Do backend work" (too vague)
❌ "Frontend" (not actionable)

使用动作动词并保持具体：

✅ "Implement user registration API endpoint"
✅ "Design authentication database schema"
✅ "Build login form UI components"
❌ "Do backend work"（过于模糊）
❌ "Frontend"（不可执行）

Task Description Structure:

任务描述结构：

markdown

undefined

markdown

undefined

Context

[Brief context for this task from the Confluence spec]

[来自Confluence规范的该任务简要上下文]

Requirements

[Requirement 1]
[Requirement 2]
[Requirement 3]

[需求1]
[需求2]
[需求3]

Technical Details

[Specific technical information relevant to this task]

Technologies: [e.g., Node.js, React, PostgreSQL]
Components: [e.g., API routes, database tables, UI components]
Dependencies: [e.g., requires PROJ-124 to be completed first]

[与该任务相关的特定技术信息]

Technologies: [例如：Node.js, React, PostgreSQL]
Components: [例如：API routes, database tables, UI components]
Dependencies: [例如：需要先完成PROJ-124]

Acceptance Criteria

Confluence Spec: [Link to relevant section if possible]
Epic: PROJ-123

undefined

Confluence Spec: [尽可能链接到相关章节]
Epic: PROJ-123

undefined

Acceptance Criteria Best Practices:

验收标准最佳实践：

Make them testable and specific:

✅ "API returns 201 status on successful user creation"
✅ "Password must be at least 8 characters and hashed with bcrypt"
✅ "Login form validates email format before submission"
❌ "User can log in" (too vague)
❌ "It works correctly" (not testable)

确保可测试且具体：

✅ "API returns 201 status on successful user creation"
✅ "Password must be at least 8 characters and hashed with bcrypt"
✅ "Login form validates email format before submission"
❌ "User can log in"（过于模糊）
❌ "It works correctly"（不可测试）

Create all tickets sequentially:

按顺序创建所有工单：

Track each created ticket key for the summary.

记录每个已创建工单的密钥，用于汇总。

Step 7: Provide Summary

步骤7：提供汇总信息

After all tickets are created, present a comprehensive summary:

✅ Backlog created successfully!

**Epic:** PROJ-123 - User Authentication System
https://yoursite.atlassian.net/browse/PROJ-123

**Implementation Tickets (7):**

1. PROJ-124 - Design authentication database schema
   https://yoursite.atlassian.net/browse/PROJ-124

2. PROJ-125 - Implement user registration API endpoint
   https://yoursite.atlassian.net/browse/PROJ-125

3. PROJ-126 - Implement user login API endpoint
   https://yoursite.atlassian.net/browse/PROJ-126

4. PROJ-127 - Build login form UI components
   https://yoursite.atlassian.net/browse/PROJ-127

5. PROJ-128 - Build registration form UI components
   https://yoursite.atlassian.net/browse/PROJ-128

6. PROJ-129 - Add authentication integration to existing features
   https://yoursite.atlassian.net/browse/PROJ-129

7. PROJ-130 - Write authentication tests and documentation
   https://yoursite.atlassian.net/browse/PROJ-130

**Source:** https://yoursite.atlassian.net/wiki/spaces/SPECS/pages/123456

**Next Steps:**
- Review tickets in Jira for accuracy and completeness
- Assign tickets to team members
- Estimate story points if your team uses them
- Add any additional labels or custom field values
- Schedule work for the upcoming sprint

所有工单创建完成后，展示全面的汇总：

✅ 待办事项创建成功！

**Epic:** PROJ-123 - User Authentication System
https://yoursite.atlassian.net/browse/PROJ-123

**Implementation Tickets (7):**

1. PROJ-124 - Design authentication database schema
   https://yoursite.atlassian.net/browse/PROJ-124

2. PROJ-125 - Implement user registration API endpoint
   https://yoursite.atlassian.net/browse/PROJ-125

3. PROJ-126 - Implement user login API endpoint
   https://yoursite.atlassian.net/browse/PROJ-126

4. PROJ-127 - Build login form UI components
   https://yoursite.atlassian.net/browse/PROJ-127

5. PROJ-128 - Build registration form UI components
   https://yoursite.atlassian.net/browse/PROJ-128

6. PROJ-129 - Add authentication integration to existing features
   https://yoursite.atlassian.net/browse/PROJ-129

7. PROJ-130 - Write authentication tests and documentation
   https://yoursite.atlassian.net/browse/PROJ-130

**Source:** https://yoursite.atlassian.net/wiki/spaces/SPECS/pages/123456

**Next Steps:**
- Review tickets in Jira for accuracy and completeness
- Assign tickets to team members
- Estimate story points if your team uses them
- Add any additional labels or custom field values
- Schedule work for the upcoming sprint

Edge Cases & Troubleshooting

边缘情况与故障排除

Multiple Specs or Pages

多个规范或页面

If user references multiple Confluence pages:

Process each separately, or ask which to prioritize
Consider creating separate Epics for distinct features
"I see you've provided 3 spec pages. Should I create separate Epics for each, or would you like me to focus on one first?"

如果用户引用多个Confluence页面：

分别处理每个页面，或询问优先处理哪个
考虑为不同功能创建独立的Epic
"I see you've provided 3 spec pages. Should I create separate Epics for each, or would you like me to focus on one first?"

Existing Epic

已存在的Epic

If user wants to add tickets to an existing Epic:

Skip Epic creation (Step 5)
Ask for the existing Epic key: "What's the Epic key you'd like to add tickets to? (e.g., PROJ-100)"
Proceed with Step 6 using the provided Epic key

如果用户希望将工单添加到现有Epic：

跳过Epic创建（步骤5）
询问现有Epic密钥："What's the Epic key you'd like to add tickets to? (e.g., PROJ-100)"
使用提供的Epic密钥继续步骤6

Custom Required Fields

自定义必填字段

If ticket creation fails due to required fields:

Use

getJiraIssueTypeMetaWithFields

to identify what fields are required:

getJiraIssueTypeMetaWithFields(
  cloudId="...",
  projectIdOrKey="PROJ",
  issueTypeId="10001"
)

Ask user for values: "This project requires a 'Priority' field. What priority should I use? (e.g., High, Medium, Low)"

Include in

additional_fields

when creating:

additional_fields={
  "priority": {"name": "High"}
}

如果工单创建因必填字段失败：

使用

getJiraIssueTypeMetaWithFields

识别必填字段：

getJiraIssueTypeMetaWithFields(
  cloudId="...",
  projectIdOrKey="PROJ",
  issueTypeId="10001"
)

向用户询问值："This project requires a 'Priority' field. What priority should I use? (e.g., High, Medium, Low)"

在创建时包含在

additional_fields

中：

additional_fields={
  "priority": {"name": "High"}
}

Large Specifications

大型规范

For specs that would generate 15+ tickets:

Present the full breakdown to user
Ask: "This spec would create 18 tickets. Should I create all of them, or would you like to adjust the scope?"
Offer to create a subset first: "I can create the first 10 tickets now and wait for your feedback before creating the rest."

如果规范将生成15+个工单：

向用户展示完整的拆分结果
询问："This spec would create 18 tickets. Should I create all of them, or would you like to adjust the scope?"
提议先创建子集："I can create the first 10 tickets now and wait for your feedback before creating the rest."

Subtasks vs Tasks

子任务 vs 任务

Some projects use "Subtask" issue types:

If metadata shows "Subtask" is available, you can use it for more granular work
Subtasks link to parent tasks (not Epics directly)
Structure: Epic → Task → Subtasks

某些项目使用"Subtask"问题类型：

如果元数据显示"Subtask"可用，可用于更细化的工作
子任务链接到父任务（不直接链接到Epic）
结构：Epic → Task → Subtasks

Ambiguous Specifications

模糊的规范

If the Confluence page lacks detail:

Create fewer, broader tickets
Note in ticket descriptions: "Detailed requirements need to be defined during refinement"
Ask user: "The spec is light on implementation details. Should I create high-level tickets that can be refined later?"

如果Confluence页面细节不足：

创建更少、更宽泛的工单
在工单描述中注明："Detailed requirements need to be defined during refinement"
询问用户："The spec is light on implementation details. Should I create high-level tickets that can be refined later?"

Failed API Calls

API调用失败

If
createJiraIssue
fails:

Check the error message for specific issues (permissions, required fields, invalid values)
Use
```
getJiraProjectIssueTypesMetadata
```
to verify issue type availability
Inform user: "I encountered an error creating tickets: [error message]. This might be due to project permissions or required fields."

如果
createJiraIssue
失败：

检查错误消息中的具体问题（权限、必填字段、无效值）
使用
```
getJiraProjectIssueTypesMetadata
```
验证问题类型是否可用
告知用户："I encountered an error creating tickets: [error message]. This might be due to project permissions or required fields."

Tips for High-Quality Breakdowns

高质量拆分技巧

Be Specific

具体明确

❌ "Do frontend work"
✅ "Create login form UI with email/password inputs and validation"

❌ "Do frontend work"
✅ "Create login form UI with email/password inputs and validation"

Include Technical Context

包含技术上下文

Mention specific technologies when clear from spec
Reference components, services, or modules
Note integration points

当规范中明确时提及特定技术
引用组件、服务或模块
注意集成点

Logical Grouping

逻辑分组

Related work stays in the same ticket
Don't split artificially: "Build user profile page" includes both UI and API integration
Do split when different specialties: Separate backend API task from frontend UI task if worked on by different people

相关工作放在同一个工单中
不要人为拆分："Build user profile page"包含UI和API集成
当工作由不同人员负责时拆分：将后端API任务与前端UI任务分开

Avoid Duplication

避免重复

Don't create redundant tickets for the same functionality
If multiple features need the same infrastructure, create one infrastructure ticket they all depend on

不为同一功能创建冗余工单
如果多个功能需要相同的基础设施，创建一个基础设施工单供所有功能依赖

Explicit Testing

明确测试

Include testing as part of feature tasks ("Implement X with unit tests")
OR create separate testing tasks for complex features ("Write integration tests for authentication flow")

将测试作为功能任务的一部分（"Implement X with unit tests"）
或为复杂功能创建单独的测试任务（"Write integration tests for authentication flow"）

Documentation Tasks

文档任务

For user-facing features: Include "Update user documentation" or "Create help articles"
For developer tools: Include "Update API documentation" or "Write integration guide"

面向用户的功能：包含"Update user documentation"或"Create help articles"
开发者工具：包含"Update API documentation"或"Write integration guide"

Dependencies

依赖关系

Note prerequisites in ticket descriptions
Use "Depends on" or "Blocks" relationships in Jira if available
Sequence tickets logically (infrastructure → implementation → testing)

在工单描述中注明前置条件
如果可用，在Jira中使用"Depends on"或"Blocks"关系
按逻辑顺序排列工单（基础设施 → 实施 → 测试）

Examples of Good Breakdowns

优秀拆分示例

Example 1: New Feature - Search Functionality

示例1：新功能 - 搜索功能

Epic: Product Search and Filtering

Tickets:

[Task] Design search index schema and data structure
[Task] Implement backend search API with Elasticsearch
[Story] Build search input and results UI components
[Story] Add advanced filtering (price, category, ratings)
[Story] Implement search suggestions and autocomplete
[Task] Optimize search performance and add caching
[Task] Write search integration tests and documentation

Epic: Product Search and Filtering

Tickets:

[Task] Design search index schema and data structure
[Task] Implement backend search API with Elasticsearch
[Story] Build search input and results UI components
[Story] Add advanced filtering (price, category, ratings)
[Story] Implement search suggestions and autocomplete
[Task] Optimize search performance and add caching
[Task] Write search integration tests and documentation

Example 2: Bug Fix - Performance Issue

示例2：Bug修复 - 性能问题

Epic: Resolve Dashboard Load Time Issues

Tickets:

[Task] Profile and identify performance bottlenecks
[Bug] Optimize database queries with indexes and caching
[Bug] Implement lazy loading for dashboard widgets
[Bug] Add pagination to large data tables
[Task] Set up performance monitoring and alerts

Epic: Resolve Dashboard Load Time Issues

Tickets:

[Task] Profile and identify performance bottlenecks
[Bug] Optimize database queries with indexes and caching
[Bug] Implement lazy loading for dashboard widgets
[Bug] Add pagination to large data tables
[Task] Set up performance monitoring and alerts

Example 3: Infrastructure - CI/CD Pipeline

示例3：基础设施 - CI/CD流水线

Epic: Automated Deployment Pipeline

Tickets:

[Task] Set up GitHub Actions workflow configuration
[Task] Implement automated testing in CI pipeline
[Task] Configure staging environment deployment
[Task] Implement blue-green production deployment
[Task] Add deployment rollback mechanism
[Task] Create deployment runbook and documentation

Epic: Automated Deployment Pipeline

Tickets:

[Task] Set up GitHub Actions workflow configuration
[Task] Implement automated testing in CI pipeline
[Task] Configure staging environment deployment
[Task] Implement blue-green production deployment
[Task] Add deployment rollback mechanism
[Task] Create deployment runbook and documentation

spec-to-backlog

Original

Translation

Spec to Backlog

规范转待办事项

Overview

概述

Core Workflow

核心工作流

Step 1: Fetch Confluence Page

步骤1：获取Confluence页面

If user provides a Confluence URL:

如果用户提供Confluence URL：

If user provides only a page title or description:

如果用户仅提供页面标题或描述：

Fetch the page:

获取页面内容：

Step 2: Ask for Project Key

步骤2：询问项目密钥

Ask the user:

询问用户：

If user is unsure:

如果用户不确定：

Once you have the project key:

获取项目密钥后：

Step 3: Analyze Specification

步骤3：分析规范

Epic-Level Goal

Epic级目标

Implementation Tasks

实施任务

Step 4: Present Breakdown to User

步骤4：向用户展示拆分结果

Step 5: Create Epic FIRST

步骤5：先创建Epic

Create the Epic:

创建Epic：

Epic Description Structure:

Epic描述结构：

Overview

Overview

Source

Source

Objectives

Objectives

Scope

Scope

Success Criteria

Success Criteria

Technical Notes

Technical Notes

Capture the Epic Key:

记录Epic密钥：

Step 6: Create Child Tickets

步骤6：创建子工单

For each task:

每个任务的处理：

Task Summary Format:

任务摘要格式：

Task Description Structure:

任务描述结构：

Context

Context

Requirements

Requirements

Technical Details

Technical Details

Acceptance Criteria

Acceptance Criteria

Related

Related

Acceptance Criteria Best Practices:

验收标准最佳实践：

Create all tickets sequentially:

按顺序创建所有工单：

Step 7: Provide Summary

步骤7：提供汇总信息

Edge Cases & Troubleshooting

边缘情况与故障排除

Multiple Specs or Pages