mcpField
T
twg-jira-resolve-merged-work

twg-jira-resolve-merged-work

github.com/atlassian生产力2487 次安装7 周前更新
代码仓库

关于 twg-jira-resolve-merged-work

用于根据已合并 PR 证据审查 Jira 工作项并制定安全解决计划的技能。默认先进行试运行，修改 Jira 或 PR 数据前须获批准。

主要功能

  1. 01选择 Jira 范围并读取工作项
  2. 02查找已合并 PR 证据
  3. 03置信度评估与试运行计划
  4. 04经批准后更新状态和链接
  5. 05变更后重新核验

适用场景

  1. 01审查有已合并工作成果的过期 Jira 项
  2. 02为迭代或看板制定解决计划
  3. 03更改工作项状态前核对 PR 证据

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/atlassian/twg-cli --skill twg-jira-resolve-merged-work

安装后在 Claude Code 中输入/twg-jira-resolve-merged-work确认已加载。

附带文件LICENSE.txt

详细介绍

twg-jira-resolve-merged-work

仅在合并 PR 的证据充分时，才解决过期的 Jira 工作项。先制定计划； 获得批准后再修改。

严格遵循实时 twg help / twg help describe <path> 提供的命令语法；不要 猜测看板、冲刺、转换、工作区、仓库、PR 或字段的语法。

CLI 启动器备用方案

运行 twg <command>。如果 shell 提示 command not found，则使用 $HOME/.local/bin/twg （macOS/Linux）/ $env:LOCALAPPDATA\Programs\twg\bin\twg.exe（PowerShell），然后 告知用户将该目录添加到 PATH。不要将身份验证或命令错误视为 PATH 故障。

范围

接受一个 Jira 范围：

  • 一个 Jira 工作项键/URL。
  • 明确列出的少量 Jira 工作项键/URL。
  • 看板或冲刺 ID/URL。
  • Epic 键。
  • Jira 空间/项目键。

默认采用试运行。除非用户要求经审核后执行，否则修改前先征求同意。使用有界时间窗口；否则检查近期的活动/已完成冲刺工作和相近的 PR 合并日期。

工作流

  1. 加载 Jira 候选项。

    • 单项/列表：直接加载提供的每个工作项详情。
    • 冲刺：jira sprint workitems query。
    • 看板：使用实时帮助中列出的看板/待办事项/冲刺命令。
    • Epic 或空间：使用基于 JQL 的 jira workitem query。
    • 加载键、标题、状态/类别、经办人、更新时间、父项、 子任务/阻碍项和 URL。

  2. 划分集合。

    • 候选项尚未完成/解决。同一看板、冲刺、 Epic 或空间中已完成的项为参照项。
    • 排除 Epic/父项。除非用户明确允许，否则跳过存在未解决阻碍项或未完成子任务的项。

  3. 按集合发现共享仓库上下文。

    • 即使只有一个工作项或一个短列表，也要为整个集合共同推断上下文。
    • 从关联的 PR、提交、分支、项目链接、 Compass/组件、上下文查询和已解决的参照项中提取仓库/工作区。
    • 利用已完成的参照项推断常见仓库、经办人、Jira 键的标题/分支 规范、PR 链接，以及从合并到状态转换的时间差。

  4. 检查可选的发现信号。

    • 如果 rovo list-apps 显示已连接 Bitbucket 或 GitHub，则使用 Rovo 搜索 键、标题、PR URL、分支和仓库。在通过 TWG/提供方/Jira 证据加载详情前，将其视为发现线索。
    • 如果 search-code 可用，先搜索精确键，再在已发现的仓库中搜索有辨识度的标题词。强证据包括分支名称、提交文本、变更文件或符号；宽泛的模糊匹配仍属弱证据。

  5. 扩展可能的实现者范围。

    • 优先考虑已完成参照项和候选项的经办人。将报告人和评论者仅视为较弱线索。
    • 在时间窗口内查询这些经办人创建的已合并 PR，优先限定在已发现的仓库；如果仓库未知，则根据作者/日期结果推断仓库。

  6. 分批搜索已合并的 PR。

    • 优先对每个仓库/时间窗口执行一次已合并 PR 查询，然后在本地匹配所有候选键。一个 PR 可匹配多个精确键。
    • 在 PR 标题、描述、分支、提交和关联问题元数据中匹配精确键。
    • 只有在缺少证据、项目优先级较高或存在歧义时，才针对单个工作项查询。

  7. 评估置信度。

    • 高：已合并 PR 或关联 PR 元数据中包含精确键，时间合理，没有同键未关闭 PR，没有阻碍项/子任务，且存在目标状态转换。
    • 中：经办人/仓库相同且标题高度相似，或精确键仅出现在提交/search-code 证据中。
    • 低：相似度模糊、仅作者相同、仓库未知或存在歧义。

  8. 生成试运行计划。

    • 表格列：工作项键/标题、当前状态、建议的状态转换、置信度、简要理由、PR 标题/URL、合并日期、Jira 最后更新时间、链接/仓库建议、PR 标题修正建议、跳过原因和验证。
    • 仅在通过实时帮助验证后提供精确命令。绝不将低置信度行列为可执行项。

变更

只有在获得对确切行或计划的明确批准后，才能执行变更。

  • 状态转换：先列出可用转换，然后只能使用已批准的完成/已解决目标状态。
  • 链接补充：如果缺少链接，在查询现有链接并核实帮助信息后，针对 PR/仓库 URL 提供 jira workitem link weblink。不要声称这会创建原生开发面板链接。
  • PR 标题修正：对于 Bitbucket，只有在经核实的 bitbucket pull-requests get 叶节点能够读取 PR、已核实写入权限、确认 PR 与工作项相关，并且用户已批准时，才更新标题。对于 GitHub，只有在存在经过身份验证的写入工具且已核实访问权限时才更新；否则跳过并说明原因。
  • 验证：重新读取每个已变更的工作项和 PR。报告已变更的键、状态、URL 和失败行。

不要自动转换中等置信度项目的状态。不要转换已拒绝/已取代的 PR，也不要处理仅由作者相同、仓库相同或模糊相似性支持的行。

输出

先给出决策摘要：

  • 可执行的高置信度行，
  • 需要审核的中等置信度行，
  • 因安全原因跳过的行，
  • 仓库/身份验证/权限覆盖缺失情况。

然后提供试运行表格和确切的批准问题。为每个用作证据的工作项和 PR 提供 URL 或稳定 ID。

评论

支持 Markdown