twg-responsibility-routing

twg-responsibility-routing

使用根目录中的 twg 技能。使用此工作流回答“我应该让谁参与、为什么让他们参与，以及他们扮演什么角色？”不要假设宽泛的话题就是一个确切的产品。

CLI 启动器回退方案

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

划分角色

区分以下角色：

• 正式负责人：对某个实体或领域负有正式责任。
• 运营负责人或维护者：负责当前的交付或运营。
• 专家：在某项工作流中具备有来源依据的深入知识。
• 审查者或咨询方：负责评估或提供建议，但未必有决策权。
• 审批者或决策权威：可以批准具体请求或决策。
• 升级联系人或工程负责人：领导相关工程组织，或能够转交尚未解决的请求。
• 知情利益相关者：会受到决策影响，但不负责决策。

确定范围，再确定人员

对于含义模糊的话题或领域，分别执行一次有限范围的 twg rovo search "<topic>" --app confluence 查询和一次有限范围的 twg work search "<topic>" 查询。将同名结果归入不同的 计划、平台、领域、功能和团队群组。对 2-5 份核心章程、路线图、服务、项目或当前工作流进行补充信息查询，然后再对相关人员排序。 如果来源之间存在分歧，请展示不同的范围选项或询问用户。

对于明确的项目、目标、组件、服务、工作项、页面或代码仓库， 直接使用该引用。

查明职责与权限

• 使用 twg responsibility get <reference> 查询正式负责人、团队、 维护者、审批者、审查者或升级角色。
• 仅当正式职责缺失，或用户要求提供有依据的候选人时，才使用 twg responsibility infer <reference>。保留置信度、 原因代码、证据时间范围，以及正式声明与观察所得的状态区别。
• 主要根据限定范围的搜索结果、正式声明的角色和补充信息后的工作证据进行推断。 组织数据是可选的；不要仅仅因为无法获取组织数据就阻碍或削弱工作流。
• 如果已连接组织数据，且已知候选领导或经理，优先选择范围最窄且有用的树形查询：使用 org-tree 查看层级结构，使用 work-tree 查看跨界面的广度，使用 workitem-tree 查看 Jira 工作，或使用 pr-tree 查看 PR 作者身份/审查情况。树形查询的计数有助于验证涉及范围和组织范围；但仅凭计数无法证明专业能力、所有权或审批权。
• 对于审批请求，检查定义该决策的材料：项目或目标的所有权信息、Jira 工作流/审批者字段、章程、决策记录或负责团队。分别说明谁可以提出建议、必须咨询谁，以及谁可以审批。绝不要把当前贡献者擢升为审批者。
• 对于升级请求，先给出最近且已验证的负责人。只有在负责人缺失、受阻、涉及多个团队，或请求需要组织层级权限时，才添加工程领导。

只有在确定范围和人员角色后，确实需要扩展关系或依赖关系时，才使用 twg-context-discovery。它不是处理职责问题的默认途径。

证据与输出

有力的证据包括明确的所有权、承担责任的角色、工作流决策权、章程或路线图领导职责、服务所有权、持续作出的决策，或反复作出的核心贡献。个人资料文本、与组织的接近程度、一份文档、原始活动记录或自行发布的更新，单独来看都属于薄弱证据。

对于主题或 SME 映射，除非用户要求更多，否则最多返回五个工作流，每个工作流仅指定一位主要专家。只有在有跨工作流证据时，才指定总体负责人。对于审批或升级请求，请提供建议联系人、角色、职责范围、证据、置信度、适任原因，以及建议提出的问题或联络内容。若权限尚未确认，请明确说明。

如果进一步搜索不会改变职责范围、角色、权限、升级路径、置信度或建议联系人，就停止搜索。