mcpField
L
list-open-work

list-open-work

github.com/outthislife开发20939 次安装6 天前更新
代码仓库

关于 list-open-work

list-open-work 是用于当前 Git 仓库的 Agent 技能，汇总本人在该仓库远程源上的未关闭 MR 或 PR，并关联工单。它还要求核查影响后续处理的冲突、CI 和评审问题。

主要功能

  1. 01限定当前仓库及其 origin
  2. 02列出本人未关闭的 MR 或 PR
  3. 03从标题、分支或描述识别工单
  4. 04核查冲突、流水线和评审阻碍
  5. 05按指定 Markdown 格式输出

适用场景

  1. 01查看当前仓库尚未关闭的代码审查
  2. 02确认 MR 或 PR 对应的工单
  3. 03发现冲突或失败流水线以安排后续工作

安装

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

$npx skills add https://github.com/outthislife/brooklyn-skills --skill list-open-work

安装后在 Claude Code 中输入/list-open-work确认已加载。

详细介绍

/list-open-work

回答一个问题：在此仓库中，我有哪些未关闭的事项，各自关联哪个工单？先列清单，其他内容放在清单之后，用散文说明。

仅限此仓库

范围是你当前所在的 git 检出（工作树或主检出）。读取其 origin。 仅列出我针对该远程仓库发起的未关闭 MR/PR。到此为止。

  • 如果不是 git 仓库 → 说明这一点并停止。不要去找其他项目。
  • 不要凭记忆、其他会话或其他工作树列出其他 origin、组织、代码托管平台或工单跟踪系统。
  • 根据此仓库的分支名/标题推断工单键（例如 feat/PROJ-123-slug 中的 PROJ-123）。绝不要重用在别处看到的前缀。
git rev-parse --show-toplevel
git remote get-url origin

输出格式

直接在聊天中以普通渲染后的 Markdown 输出。绝不要用代码围栏包起来——链接必须可点击。

每项之间空一行。 Markdown 会把单个换行视为空格，因此相邻行会变成同一段。这是错误的。每个 MR 都必须单独成段：换行、空行、下一行。

严格使用以下格式。标题为 Open MRs: 或 Open PRs:。不要用项目符号或表情符号。编号和工单键都必须是链接。工单放在末尾的 [KEY] 中。

Open MRs:

!42 - 缩短保存路径 [PROJ-101]

!41 - 默认启用新标志 [PROJ-99]

!30 - 在公共 API 中公开状态历史记录

  • 按编号降序排列。GitLab 使用 !N，GitHub 使用 #N。“MRs”或“PRs”也要相应使用。
  • 每项单独成段：<!|#><N> - <title> [<KEY>]。不要加粗。
  • 工单放在末尾的 [KEY] 中。如果作者把它放在标题中间，就移到末尾： perf: PROJ-77 — cut over-fetch 应改为 perf: cut over-fetch [PROJ-77]。
  • 没有工单 → 省略 [KEY]。不要编造，也不要写 (no ticket)。
  • 保持 MR/PR 标题原样（仅移除调换位置的工单键）。不要改写。

错误示例（会渲染成一行）：

Open MRs:
!42 - shorten the save path [PROJ-101]
!41 - default the new flag on [PROJ-99]

粘贴到 Slack 是另一项需求。代码托管平台/工单跟踪系统的集成会自动将 !42 和 PROJ-101 转为链接，因此该版本只需去掉链接语法，行内容保持不变——仍然每项一行。

收集

“我”指作者是我。通过 API 获取我的用户名——绝不要猜测。

GitLab origin：

glab api user
glab api "projects/<url-encoded-path>/merge_requests?state=opened&scope=all&per_page=100"

按作者 = 我筛选。<url-encoded-path> 是此 origin 的路径，不是其他仓库的路径。

GitHub origin：gh pr list --author @me --state open --json number,title,headRefName,body

工单 = 标题中第一个 \b[A-Z][A-Z0-9]+-\d+\b，其次是分支名，再其次是描述。使用此仓库所用的该工单键对应的工单跟踪主机——不要猜测其他公司的站点。

Jira 账户验证

根据仓库的工单跟踪项目验证实际 Jira 结果；仅运行 acli jira auth status 可能会显示预期站点，但搜索仍可能访问其他账户。如果项目键或 API 主机与预期工作区不符，请明确使用 acli jira auth switch --site <repo-tracker-host> --email <verified-email> 选择已保存的账户，然后读取一个已知工单，再信任列表结果。不要重用错误站点的结果。

使用 acli jira workitem search --paginate，并将实际获取的不同工单数与相同 JQL 的 --count 结果进行比较。搜索可用的字段受限；请改用 workitem view --fields summary,description,status,priority,assignee,updated,comment,issuelinks --json 获取时间戳、描述和评论。在将 Testing 工单归类为新的实现工作之前，先阅读评论。

然后，用文字说明

只提会影响我下一步行动的事项：

  • 与默认分支存在冲突——已阻塞，尚未进入审核。GitLab 会延迟重新计算可合并状态，因此普通的 MR GET 会直接返回过时的 has_conflicts: false。强制重新计算并读取 merge_status：
glab api "projects/<path>/merge_requests/<iid>?include_diverged_commits_count=true"
# cannot_be_merged + has_conflicts → needs a rebase; diverged_commits_count = how far behind
  • 流水线失败（head_pipeline.status）。
  • 工单状态与 MR 矛盾：所有讨论串都已解决且检查通过，但工单仍显示 In Progress。
  • 没有关联工单且已搁置数月——说明搁置时长，并提出关闭建议。

除非有人要求，否则跳过审批信息。不要描述没有影响的字段变化。

对于 GitHub 就绪状态检查，除了分页获取的行内讨论串，还要读取已提交的审核意见正文和人工 PR 评论。即使未解决的行内讨论串数量为零且 CI 检查通过，COMMENTED 审核意见中也可能包含明确的合并阻塞项。将每条审核意见与其审核的提交版本对应起来；较早的发现需要重新核查，不能直接断言为当前缺陷。

将 CI 结论、冲突状态和实质性的审核阻塞项分开处理。针对每个当前提交版本查询 gh pr checks；合并状态为 UNKNOWN 表示尚未验证，并非没有冲突。在报告总数之前，以编程方式保存清单并汇总计数。

如果此仓库使用 GitHub issue 而不是跟踪器键，则除了检查 closingIssuesReferences，还要检查 PR 正文中明确链接的 issue。非关闭式引用也可能是实际关联的工单。更改 issue 状态前，先阅读其状态和讨论；部分修复或等待实时验证，都可能意味着应保持开启。

评论

支持 Markdown