Jira项目管理工具Skill：用自然语言完成 Jira 查票、建票与流转
- 一句话概括：这个技能让 AI 助手直接“说人话”操作 Jira——看问题、列票、建票、改状态、加评论、查当前 Sprint，都不用切浏览器、不用背 JQL。
- 双后端自适应：优先检测本机
jiraCLI，其次检测 Atlassian MCP 工具，两者都没有时才引导用户配置，保证在不同环境下都能跑起来。 - 覆盖高频操作：详情中给出了查看、列出我的问题、创建、移动/过渡、分配、取消分配、评论、浏览器打开、当前 Sprint、
jira me等一批快速参考命令，日常需求基本覆盖。 - 自带“安全护栏”：明确要求先取当前状态再操作、不假设过渡名称通用、不用显示名做分配、批量修改必须明确批准，减少“手滑改坏票”的风险。
- 有前置依赖：技能本身不提供 Jira 账号能力，必须先具备
jiraCLI 或 Atlassian MCP 其中一种后端，否则只能查看引导说明。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | Jira项目管理工具Skill |
| 技能英文名 | jira |
| 技能ID | 12417 |
| 核心定位 | 与 Jira 的自然语言交互，支持多个后端 |
它解决的是一个非常具体的效率问题：日常开发中，查看一张票的状态、给自己认领一张票、把票挪到“完成”、在票下补一条评论、看看当前 Sprint 里还剩什么——这些动作本身只需要十几秒，但“打开浏览器 → 登录 → 找到项目 → 搜索 → 点开票”这一串流程往往要花掉几分钟，而且频繁打断写代码的心流。这个技能把这一步压缩成一句话：告诉 AI 助手你要什么，由它去调用 Jira。
“一键安装”的整体思路
所谓“一键安装 AI 技能提升开发效率”，指的是把技能装进你的 AI 助手/客户端，让它在对话中自动识别 Jira 相关意图（例如出现 PROJ-123 这种问题键，或提到 jira、issue、ticket、sprint、backlog 等关键词）并接管操作。具体步骤建议按下面的顺序来：
- 准备 Jira 侧的前提条件：你需要有可用的 Jira 账号，以及调用 Jira 所需的凭据（CLI 通过初始化向导登录，MCP 通过配置 Atlassian 凭据）。具体授权方式与凭据类型以官方说明为准。
- 安装技能本体：在你的 AI 技能市场/技能库中搜索技能英文名
jira或技能ID12417，执行安装。不同宿主的安装入口与命令不同，请以官方说明为准。 - 准备至少一个后端（这一步是能否真正用起来的关键）：
- jira CLI（技能内推荐）：安装方式为
brew install ankitpokhrel/jira-cli/jira-cli，项目地址为https://github.com/ankitpokhrel/jira-cli，安装完成后执行jira init完成初始化。 - Atlassian MCP：在你的 MCP 设置中配置 Atlassian 凭据，使
mcp__atlassian__*系列工具可用。
- jira CLI（技能内推荐）：安装方式为
- 验证是否生效：
- 终端侧验证：执行
which jira应能找到命令；执行jira me能返回你自己的账号信息。 - 对话侧验证：对 AI 助手说“列出我的票务”或“给我展示 PROJ-123”，若返回真实票据信息，说明技能已接管成功。
- 若两者都不可用，技能会主动给出安装引导，而不是静默失败。
- 终端侧验证：执行
2. 该技能的主要功能和特点
能做什么（基于详情中的快速参考）
- 查看单个问题：
jira issue view ISSUE-KEY，或直接在浏览器中打开：jira open ISSUE-KEY。 - 列出我的票务：
jira issue list -a$(jira me)；只看进行中的：jira issue list -a$(jira me) -s"In Progress"。 - 创建问题：
jira issue create -tType -s"Summary" -b"Description"。 - 流转状态：
jira issue move ISSUE-KEY "State"。 - 分配与取消分配：
jira issue assign ISSUE-KEY $(jira me)，取消分配用x。 - 添加评论：
jira issue comment add ISSUE-KEY -b"Comment text"。 - 查看当前 Sprint：
jira sprint list --state active。 - 确认身份：
jira me。 - MCP 后端能力：JQL 搜索、查看问题、创建、更新、获取过渡列表、执行过渡、加评论、用户查找、列出可见项目。
和“普通工具/手动操作”比强在哪
- 自动后端检测：不用你操心当前环境该用 CLI 还是 MCP，技能会先跑检测流程再决定走哪条路径，两套参考文档（
references/commands.md、references/mcp.md）按需加载。 - 问题键自动识别：对话里出现
[A-Z]+-[0-9]+形式的键（如PROJ-123、ABC-1）时，会自动理解为“要操作这张票”。 - 成体系的防错规则：操作前先问四个问题——当前状态是什么、还有谁受影响、这个操作可逆吗、标识符对不对；并明确列出“永远不要”清单，例如不要在没有获取当前状态的情况下做过渡、不要用显示名称做分配（MCP 只认账户 ID）、不要在没展示原始内容的情况下编辑描述、不要在缺必填字段时使用
--no-input、不要假设过渡名称通用、不要未经明确批准批量修改。 - 工作流化的创建与更新：建票先研究上下文、起草、与用户审阅、再创建；改票先取详情、检查状态、展示“当前值 vs 建议值”、获批准后再改、并补一条说明性评论。
- 按复杂度分流：简单查看/列表不加载参考文档，复杂字段、JQL、过渡、链接才加载，避免不必要的开销。
3. 如何使用该技能？
第 1 步：确认后端。 技能启动时会先检测：which jira 能找到就走 CLI 后端；找不到则检查是否有 mcp__atlassian__* 工具；两者都没有就进入引导模式。
第 2 步：用自然语言提需求。 典型触发说法包括“创建一个 jira 票”“给我展示 PROJ-123”“列出我的票务”“将票移动到完成”“当前 sprint 中有什么”。
第 3 步：查看类操作直接执行。 例如你说“看看 PROJ-123 现在什么状态”，对应执行 jira issue view PROJ-123（MCP 模式下为 mcp__atlassian__getJiraIssue）。
第 4 步：创建类操作走“起草—确认—创建”。 你只需描述需求，例如“帮我建一个 bug 票，摘要写‘登录页在 Safari 下白屏’，描述里写上复现步骤和环境”。技能会先研究上下文（如果提到代码、票务或 PR）、起草内容、与你确认后再调用创建命令。注意：创建带描述的复杂问题时建议参考 references/commands.md，CLI 侧涉及 /tmp 模式。
第 5 步：状态流转要先取过渡。 你如果说“把 PROJ-123 挪到完成”，技能不会直接硬改，而是先获取可用过渡（MCP 下为 mcp__atlassian__getTransitionsForJiraIssue），确认“完成/关闭/已完成”在该项目里的实际叫法，再执行 jira issue move PROJ-123 "State"。因为“待办 → 完成”在需要经过“进行中”的工作流里可能静默失败。
第 6 步：分配与评论。 分配给自己用 jira issue assign PROJ-123 $(jira me)；MCP 模式下必须先 lookupJiraAccountId 拿到账户 ID，显示名称无效。加评论用 jira issue comment add PROJ-123 -b"已修复，等待回归验证"。
输出说明：查询类返回票据字段与状态；列表类返回已过滤的问题清单；变更类会先展示命令/工具调用，再在获得批准后执行，并在更新后做一次校验，确保改动真的生效。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| jira（本技能） | 面向 AI 助手的 Jira 自然语言入口 | 双后端自适应；查票、列票、建票、过渡、分配、评论、Sprint 查询；内置防错规则 | 需装技能 + 至少一种后端（CLI 或 MCP）；用 jira init 或 MCP 凭据完成认证 |
日常开发查票改票、站会看板、缺陷登记 | 优势：无需离开对话、防错设计完善、CLI/MCP 都能用；不足：依赖本地 CLI 或 MCP 环境，首次配置有成本 |
| 原生 jira CLI（手动使用） | 命令行管理 Jira | 与技能快速参考命令一致 | 需自行安装 jira-cli 并 jira init；需记命令参数 |
熟练用户的高频批量操作 | 优势：直接、可控、脚本化强；不足：要记语法，复杂字段容易踩坑，无自然语言理解 |
| 单独配置 Atlassian MCP | 通用 MCP 工具集接入 Jira | JQL 搜索、增改问题、过渡、评论、用户查找、项目列表 | 需在 MCP 设置中配置 Atlassian 凭据 | 已有 MCP 生态、希望统一接入多款 Atlassian 产品 | 优势：能力全面、可跨产品；不足：缺少面向 Jira 的工作流约束与防错提示，需要自己组织调用顺序 |
| Jira 网页端 | 官方图形界面 | 全量功能，含报表、看板、权限管理 | 浏览器登录即可，零安装 | 复杂配置、看板评审、权限与字段调整 | 优势：功能最全、可视化强；不足：操作路径长、打断心流，不适合脚本化与批量操作 |
5. 该技能的典型应用场景与实际体验情况
场景一：开发者的每日开工与站会前自查。 角色是普通开发，痛点是每天要确认自己手上有哪些在办票。使用方式是一句话：“列出我的进行中票”，技能对应执行 jira issue list -a$(jira me) -s"In Progress"。实际体验上，这是最容易上手的一类操作，详情里也明确说明简单查看/列表不需要加载参考文档，响应快、心智负担低。
场景二：测试或产品同学登记缺陷。 角色是 QA，痛点是建票要填一堆字段，还容易漏复现步骤。使用方式是把现象、环境、复现步骤口语化描述出来，由技能先起草再确认。实际体验上，“先展示再创建”的流程明显降低了填错字段的概率；需要注意的是复杂字段与多行描述属于应加载参考文档的情况，必要时让 AI 先查项目的必填字段，避免 --no-input 下静默失败。
场景三：Scrum Master 或技术负责人看当前 Sprint。 使用方式是询问“当前 sprint 中有什么”，对应 jira sprint list --state active。这类操作很轻，适合在会议中即时调用；注意事项是它只回答 Sprint 层面的现状，更深度的燃尽与统计仍需回到 Jira 界面。
场景四：状态流转与跨人协作通知。 角色是负责收尾的开发，想把票推进到“完成”。使用方式是“把 PROJ-123 移到完成”，技能会先取可用过渡、确认名称差异再执行。实际体验上，这一环节最能体现技能价值——因为“完成/关闭/已完成”在不同项目里叫法不同，直接硬改大概率失败；同时也提醒了协作影响面：技能会检查观察者、关联问题和父史诗，避免一次“简单编辑”通知十个人。
整体上手难度：一句话类操作零学习成本；创建与过渡类操作需要理解“先取状态、再确认、后执行”的节奏，习惯之后反而更省心。主要注意点集中在两处：认证配置（身份验证问题技能会明确提示，需用户自行解决）与 MCP 下必须用账户 ID 而非显示名。
6. 该技能能为用户带来的价值
- 减少上下文切换成本：把“开浏览器—登录—搜索—点开票”的多次跳转压缩成一次对话。按每天 5～10 次查票/改票估算，单次省下 1～3 分钟，一天就能回收十几到几十分钟的碎片时间。
- 降低 Jira 使用门槛：不必记住
jira issue list -a$(jira me) -s"In Progress"这类参数组合，也不必写 JQL，新手也能完成标准操作。 - 降低误操作带来的协作成本：明确禁止“未取状态就过渡”“未展示原文就改描述”“未经批准批量修改”，把最容易引发返工和通知风暴的动作提前拦住。
- 让流程可复用、可审计：创建走“研究—起草—审阅—创建”，更新走“取详情—检查—对比—批准—评论说明”，形成稳定的操作习惯，长期看比个人经验更可靠。
- 长期价值在于可扩展：后端在 CLI 与 MCP 之间可切换，团队里有人用命令行、有人用 MCP 生态，都能共用同一套自然语言入口。
7. 常见问题 FAQ
Q1：怎么安装这个技能？需要先装什么？
在技能市场/技能库中搜索英文名 jira 或技能ID 12417 安装本体（具体入口以官方说明为准）。更要紧的是准备后端：装 jira CLI（brew install ankitpokhrel/jira-cli/jira-cli，然后 jira init），或配置 Atlassian MCP 凭据。之后用 jira me 或“列出我的票务”验证。
Q2：这个技能收费吗？ 技能详情中未涉及任何价格信息，技能本身的收费情况以官方说明为准；需要单独考虑的是 Jira 账号与相关服务的授权费用，同样以官方说明为准。
Q3：CLI 和 MCP 我该选哪个？
技能会自动检测：which jira 有结果就用 CLI，否则看有没有 mcp__atlassian__* 工具就用 MCP。一般来说，习惯终端、想要脚本化就用 CLI；已经在用 MCP 生态、希望统一接入 Atlassian 多款产品就用 MCP。注意 MCP 下分配人必须用账户 ID（先 lookupJiraAccountId），显示名会静默失败。
Q4：为什么让它把票“移到完成”却没成功？ 最常见原因是没先获取可用过渡。“完成/关闭/已完成”因项目而异，且部分工作流要求先经过中间状态（如“进行中”）。正确做法是先取过渡列表，确认名称与路径再执行。
Q5：适合谁用？有没有风险点？ 适合开发、测试、产品以及 Scrum Master 等需要高频接触 Jira 的人。风险点主要有三：一是编辑描述没有撤销，必须先展示原始内容再替换；二是批量修改会触发大量通知，必须获得明确批准；三是认证问题需要用户本人处理，技能只负责清晰呈现。