用途
jira-qa-scope 面向手动 QA 工程师。它解决的核心问题是：工单是写给开发者的，代码 diff 测试人员看不懂，而测试人员真正需要的是两者之间的差距——工单承诺了什么、团队后来在评论里决定了什么、代码实际改了什么。该技能用非技术测试人员能执行的语言把这一差距补齐。
主要能力
- 通过 Jira 连接器完整读取工单，包括摘要、描述、状态、类型、父工单、问题链接和全部评论。
- 把评论当作决策日志来读，区分「已决定」「已放弃」「未决」三类信息。
- 用只读 git（fetch、log、show、diff、branch）和只读 gh（pr view、pr diff、pr list、api）读取变更，逐提交阅读提交信息与 diff。
- 生成一份 Markdown 草稿，包含摘要、变更内容、工单评论决策、范围内、范围外、测试场景（Given/When/Then）和未决问题。
- 在用户明确批准后，向 Jira 工单发布一条新评论。
使用方式
技能按六个步骤工作：
- 检查 Jira 并声明范围：按顺序查找 Jira 连接器（会话中的 Jira MCP 服务器、PATH 上的 Jira CLI、仓库说明指定的脚本）。通过读取工单摘要验证其可用。若没有连接器或需要登录授权，则停止。随后以 YAML 形式打印假设和范围。
- 完整加载工单：获取工单全部字段与评论，把评论读成决策日志。
- 阅读变更：逐提交阅读信息与 diff，获取合并后的文件列表，阅读变更文件，确认路由、角色、状态分支、无界面变更以及覆盖该行为的自动化测试。
- 撰写草稿：按术语表用词，用简单英语（可用时调用 /cortex:simple-english），保存到 docs/qa-scope/YYYY-MM-DD-<KEY>-qa-scope.md。
- 评审循环：在对话中展示文件路径和完整草稿，请用户评审，应用修改并重复，直到用户认可。
- 发布到 Jira：用户批准草稿后，直接询问是否作为新评论发布到该工单。只有明确回答「是」才发布，且一次同意只对应一次发布。
适用场景
- 手动 QA 工程师需要为某个 Jira 工单制定测试范围。
- 需要把工单、评论决策和代码变更三者对齐，找出测试重点。
- 需要为测试人员生成通俗的 Given/When/Then 场景，并标注哪些场景已有自动化测试覆盖。
限制
- Jira 是硬性前提。没有可用的 Jira 连接器时，技能在第一步停止，不会根据猜测或分支名重建工单。
- 只做只读操作：git fetch 只更新远程跟踪引用，不触碰工作区；不暂存、不提交生成的 Markdown 文件。
- 只发布一条新评论，绝不编辑描述、已有评论、字段或状态。
- 不审计代码，这是测试计划而非代码评审。
- 草稿中除自动化测试块外，不出现类名、端点、字段名、文件路径或供应商对象 ID。
- 关于收费、价格、平台支持范围等具体信息，资料中暂未提供。