jira-plan-ticket

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Jira Ticket Workflow

Jira工单工作流

This skill automates the "start working on a Jira ticket" workflow.

Note: This skill is limited to the CMK project to avoid interfering with sensitive customer data. Only
CMK-
prefixed tickets are supported.

本Skill可自动化处理“开始处理Jira工单”的工作流。

注意： 本Skill仅限CMK项目使用，以避免干扰敏感客户数据。仅支持以
CMK-
为前缀的工单。

Arguments

参数

The user provides a Jira ticket key as the argument (e.g.,

/jira-plan-ticket CMK-12345

用户需提供Jira工单密钥作为参数（例如：

/jira-plan-ticket CMK-12345

）。

Workflow

工作流

1. Fetch ticket context

1. 获取工单上下文

Run the helper script to retrieve the full ticket context:

bash

.venv/bin/python3 .claude/skills/jira-plan-ticket/fetch_jira_context.py <TICKET_KEY>

This fetches the ticket's description, comments, linked tickets, and metadata from Jira.

If the script fails, report the error to the user and stop.

运行辅助脚本以获取完整的工单上下文：

bash

.venv/bin/python3 .claude/skills/jira-plan-ticket/fetch_jira_context.py <TICKET_KEY>

该脚本会从Jira获取工单的描述、评论、关联工单及元数据。

若脚本执行失败，需向用户报告错误并终止流程。

2. Check for uncommitted changes

2. 检查未提交的更改

Before switching branches, check whether the working tree is dirty:

bash

git status --porcelain

If there are uncommitted changes, warn the user and ask whether to:

Stash them (

git stash push -m "auto-stash before <TICKET_KEY>"

)

Commit them first
Abort the workflow

Do not proceed to branch creation until the working tree is clean or the user has chosen an option.

在切换分支前，检查工作区是否有未提交的更改：

bash

git status --porcelain

若存在未提交的更改，需向用户发出警告并询问用户选择以下操作：

暂存更改（

git stash push -m "auto-stash before <TICKET_KEY>"

）

先提交更改
终止工作流

在工作区清理完成或用户选择对应操作前，不得继续创建分支。

3. Create a working branch

3. 创建工作分支

Derive a short branch name from the ticket key and summary:

<TICKET_KEY>-<very_short_summary>

(e.g.,

CMK-12345-fix-login-crash

). Use lowercase, hyphens, and at most 3-4 words for the summary part.

Determine the base branch from the ticket's "Affects Versions" field:

If the script output contains an "Affects Versions" section, use it to determine the base branch:
- Version
```
2.4.0bX
```
  /
```
2.4.0pX
```
  /
```
2.4.0
```
  → base branch
```
2.4.0
```
- Version
```
2.5.0bX
```
  /
```
2.5.0pX
```
  /
```
2.5.0
```
  → base branch
```
2.5.0
```
- If multiple versions are listed, use the oldest (lowest) version branch.
If no affects version is set, ask the user which base branch to use. Present curated choices via
```
AskUserQuestion
```
:
- ```
master
```
  (development branch)
- ```
2.5.0
```
  (latest stable)
- ```
2.4.0
```
  (previous stable)

Create and switch to the branch based on the determined base branch:

bash

git fetch origin <BASE_BRANCH> && git checkout -b <TICKET_KEY>-<very_short_summary> origin/<BASE_BRANCH>

If the branch already exists, switch to it instead:

bash

git checkout <TICKET_KEY>-<very_short_summary>

根据工单密钥和摘要生成简短的分支名称：

<TICKET_KEY>-<very_short_summary>

（例如：

CMK-12345-fix-login-crash

）。使用小写字母和连字符，摘要部分最多包含3-4个单词。

从工单的“影响版本”字段确定基准分支：

若脚本输出包含“影响版本”部分，据此确定基准分支：
- 版本
```
2.4.0bX
```
  /
```
2.4.0pX
```
  /
```
2.4.0
```
  → 基准分支
```
2.4.0
```
- 版本
```
2.5.0bX
```
  /
```
2.5.0pX
```
  /
```
2.5.0
```
  → 基准分支
```
2.5.0
```
- 若列出多个版本，使用**最旧（版本号最低）**的版本分支。
若未设置影响版本，询问用户使用哪个基准分支。通过
```
AskUserQuestion
```
工具提供预设选项：
- ```
master
```
  （开发分支）
- ```
2.5.0
```
  （最新稳定版）
- ```
2.4.0
```
  （上一稳定版）

根据确定的基准分支创建并切换至新分支：

bash

git fetch origin <BASE_BRANCH> && git checkout -b <TICKET_KEY>-<very_short_summary> origin/<BASE_BRANCH>

若分支已存在，则直接切换至该分支：

bash

git checkout <TICKET_KEY>-<very_short_summary>

4. Review attachments

4. 查看附件

Skip this step entirely if the script output contains no attachment sections.

If there are attachments, launch at most 2 Task agents (subagent_type:

general-purpose

) in parallel:

Images agent (only if there are image attachments): One agent receives ALL image file paths. It should read each image with the Read tool and describe what it shows (UI state, error messages, annotations, etc.). Return a concise summary per image.
Other files agent (only if there are non-image attachments): One agent receives ALL other file paths. For text-based files (logs, configs, CSVs), read and summarize key findings. For archives (tar, zip, gz), extract via Bash and summarize structure. Return a concise summary per file.

Incorporate the returned summaries into your understanding of the ticket.

若脚本输出中无附件部分，直接跳过此步骤。

若存在附件，并行启动最多2个Task Agent（subagent_type:

general-purpose

）：

图片Agent（仅当存在图片附件时）：向该Agent传入所有图片文件路径。它需使用Read工具读取每张图片，并描述图片内容（UI状态、错误信息、注释等）。返回每张图片的简洁摘要。
其他文件Agent（仅当存在非图片附件时）：向该Agent传入所有其他文件路径。对于文本类文件（日志、配置文件、CSV），读取并总结关键信息。对于归档文件（tar、zip、gz），通过Bash解压并总结结构。返回每个文件的简洁摘要。

将返回的摘要整合到对工单的理解中。

5. Clarify uncertainties

5. 澄清不确定性

Before planning, review the gathered context (ticket description, comments, attachments, linked tickets) and identify any uncertainties or gaps:

Ambiguous requirements: If the ticket description is vague, contradictory, or open to multiple interpretations, ask the user to clarify the intended behavior.
Missing context: If the ticket lacks sufficient detail to determine the scope, affected components, or expected outcome, ask the user for the missing information.
Conflicting information: If comments or linked tickets contradict the description, surface the conflict and ask which version is correct.
Implementation choices: If there are multiple reasonable approaches and the ticket doesn't indicate a preference, present the options to the user.

Use the

AskUserQuestion

tool to present your questions. Only proceed to planning once the uncertainties are resolved or the user explicitly tells you to proceed with your best judgment.

Skip this step if the ticket context is clear and complete.

在制定计划前，回顾收集到的上下文（工单描述、评论、附件、关联工单），找出任何不确定性或信息缺口：

模糊需求：若工单描述模糊、矛盾或存在多种解读，询问用户澄清预期行为。
缺失上下文：若工单缺乏足够细节以确定范围、受影响组件或预期结果，向用户询问缺失的信息。
信息冲突：若评论或关联工单与描述存在矛盾，指出冲突并询问以哪个版本为准。
实现选择：若存在多种合理的实现方式且工单未指明偏好，向用户展示选项。

使用

AskUserQuestion

工具提出问题。只有在不确定性解决或用户明确指示按最佳判断推进后，方可进入计划阶段。

若工单上下文清晰完整，跳过此步骤。

6. Draft an implementation plan

6. 草拟实施计划

Enter plan mode and create an implementation plan based on the Jira ticket context. The plan should:

Summarize the ticket's requirements from the description and comments
Identify relevant files and components in the codebase
Outline the implementation steps
Note any open questions or blockers from linked tickets
If the ticket is a bug: Explore options for easily reproducing the bug using unit tests. This helps verify the fix and prevents regressions.
If the ticket is a feature: Explore adding sufficient unit test coverage for the new functionality.

Present the plan for user approval before proceeding with implementation.

进入计划模式，基于Jira工单上下文创建实施计划。计划应包含：

总结工单描述和评论中的需求
识别代码库中的相关文件和组件
列出实施步骤
记录关联工单中的未解决问题或阻塞点
若为Bug工单：探索通过单元测试轻松复现Bug的方法。这有助于验证修复效果并防止回归。
若为功能工单：探索为新功能添加足够的单元测试覆盖率。

在开始实施前，将计划提交给用户审批。