twg-engineering-work

twg-engineering-work

与根目录 twg 配合使用。遵循文档中的命令格式；仅在命令、参数或输出约定缺失或不确定时，才针对性查看实时 twg help。

CLI 启动器回退

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

适用场景

• “哪些 PR 正在等待我审核？”
• “这个 API 在哪里实现或使用？”
• “哪些仓库依赖这个包？”
• “此问题的最新 PR”
• “谁对这个仓库／主题贡献最多？”
• “我创建过 PR 的仓库”
• “长期未更新的审核”
• “审核流程或瓶颈”
• “某个用户、团队或仓库的 PR 状态”，“此人的 PR”，“我本周的 PR”
• “有 PR 正在处理中、尚未解决的 bug／任务”

首要步骤

确定工程锚点：

• 仓库：根据 URL、本地检出目录或仓库查询，确定工作区和仓库。
• PR：确定准确的 PR URL、ID、工作区和仓库。
• Workitem：获取 Jira workitem 的信息／上下文，以查找关联的 PR、提交、分支和仓库。
• 主题：解析／搜索一次，然后查找关联的仓库、PR 和 workitem。
• 代码：确定包、API、符号或仓库锚点，然后加载 references/code-search.md。

提供商原生的 PR 命令仅适用于对应托管平台；Bitbucket 活动／评论／任务命令绝不适用于 GitHub PR。

路由选择

• 仅在明确指定或代码审核需要更多上下文时，使用 ../twg-code-review/SKILL.md。测试时排除常规审核。
• 对于从问题查找 PR，先使用 workitem 上下文，再进行广泛的 PR 文本搜索。
• 对于仓库贡献者和热点区域，结合 PR／提交／文件区域信号与所有权和审核证据。
• 对于 PR 负责人／团队／组织汇总，使用 twg-status-rollups；此技能会补充 PR 详情。
• 对于个人／仓库状态，收集相关人员、仓库和时间范围内已合并／未合并的 PR。
• 代码：加载 references/code-search.md。
• 对于超出 PR 范围的个人汇总（Jira、文档、会议、规划、通知），使用 twg-status-rollups 和 ../twg-status-rollups/references/personal-work-summary.md。

批量处理 PR 集合

一次调用批量获取整个 PR 集合的数据，切勿逐个 PR 调用。

• 审核者、批准、时长、合并状态：一次 pull-requests get <pr-url…> 即可涵盖整个集合。使用 PR URL（查询结果中的 url）；ARI 会返回 approved: null。
• 候选项：使用 bitbucket pull-requests query（作者、审核者、状态、时间范围）或 pull-requests query（用户／组织）。
• pr-tree 的审核者计数表示“被列为审核者”，不表示已批准。
• 流水线：bitbucket pipeline query 仅列出近期运行（--limit 默认值为 15）；提高该值并检查返回的时间戳，然后再声称涵盖了指定时间范围。只有在需要查看失败日志时，才使用 pipeline get。commits／deployments 按 ARI 批量查询。
• 只有批准／评论时间戳需要逐个 PR 调用 bitbucket pull-requests activity；超过约 10 个 PR 时，进行抽样并说明。未指定 --type 时，该命令会一并返回批准、更新和评论事件，因此切勿按事件类型重复调用。

证据策略

• 仅对长期未更新、受阻、核心或影响较大的 PR，获取评论、任务、流水线状态和差异信息。
• 对于 PR 汇总，在确定主题、仓库／服务、负责人和近期情况后即可停止；同主题的更多 PR 不会增加价值。
• 对于审核状态，在信息可用时，包含时长、指定审核者、评论／任务、批准状态、CI／流水线状态和最近活动。
• 对于仓库／团队报告，按仓库、服务或工作流分组，而非按人数统计。
• 根据 PR 标题、描述和关联问题推断主题，而非根据 PR 数量推断。
• 将 Bitbucket、GitHub 和 Atlassian 的身份验证失败分别处理。
• 如果 PR 图谱或全仓库查询反复失败，则基于已知仓库、人员、workitem 或搜索锚点进行一次范围更窄的回退查询；随后根据成功获取的信息作答，并指出 PR 覆盖范围的缺口。

操作指南

Review Queue

查询按审阅者筛选的未完成 PR；按等待时间、请求的操作、未解决任务／评论、CI 失败情况和相关性排序。仅补充获取需要采取行动的 PR 的信息。

过期审阅／审阅瓶颈

查找已超过阈值仍处于打开或等待状态的 PR；按仓库、作者、审阅者和阶段分组。瓶颈模式：缺少审阅者、存在未解决任务、CI 失败、反复请求更改、负责人无法处理。

Issue PR

使用 workitem 上下文查找关联的 PR、提交、分支和仓库。仅在用户询问详情、状态或下一步操作时获取 PR。

仓库贡献者／活跃领域

查询指定仓库和时间范围内的 PR／提交；按文件／领域、作者、审阅者和主题分组。活跃领域按变更领域、频率和归属进行排序。

基于 PR 的状态汇总

先确定组织／团队，再收集时间范围内成员或仓库的 PR。按主题和仓库／服务分组，并指出仅凭 PR 证据可能遗漏 Jira、文档、规划或客户上下文。对于提出更广泛问题的单个人，使用 twg-status-rollups。

输出格式

队列：PR、仓库、负责人、状态、原因、下一步操作、证据。 报告：工作流、贡献者、瓶颈、风险、信息缺口，以及稳定的工件 URL／ID。

反模式

• 不要猜测 Bitbucket 工作区或仓库。
• 如果批量或查询方式可以覆盖目标集合，不要针对每个 PR 或每条流水线分别调用单实体命令。
• 不要获取大型队列中每个 PR 的正文、差异或评论。
• 不要将 PR 数量视为影响力。
• 不要混淆 Bitbucket、GitHub 和 Atlassian 的身份验证失败。