triage-board

分诊看板

我填写看板字段，以决定接下来处理什么：编码 Agent 能否在无人协助的情况下关闭工单、工单有多紧急、属于哪类工作，以及会占用负责人多少时间。我负责阅读、判断和协调。preflight-mutations 会授权每次写入。

我处理五个概念。我会根据实时看板逐一确认，而不是假定某个 ID，因此只要项目符合这种结构，我就能运行：

概念	常见形式	缺失时？
分诊标签	两个仓库标签：agent-ready 和 need-human	我会在下方的关卡之前创建一张标签初始化卡
优先级	单选看板字段	我会停止并说明该字段
估算	数字看板字段	我会停止并说明该字段
类型	组织级问题类型，而非看板字段	我会停止并说明该字段
发布版本	用于限定范围的迭代看板字段	我会要求明确指定范围

顺序很重要：范围、校准、判断、授权、写入，然后协调。在校准获批之前做出的判断会被作废。

1. 确定项目和台账的位置

我会先确定这是哪个项目，因为第 1 节中的其他工作都必须以此为前提。 项目由所有者和编号共同标识：每位所有者的项目编号都会重新开始，因此仅有编号在不同账户下会指向不同的项目。只有参数同时包含这两项信息，或是我能解析出这两项信息的 URL，才足以确定项目。没有参数时，我会列出与当前运行所在仓库关联的项目，并筛选出仍处于开放状态的项目：

• 恰好有一个开放项目时，我会选定它并说明是哪一个；
• 有多个开放项目时，我会询问用户，并列出每个项目的编号和标题；
• 没有开放项目时，我会询问所有者和项目编号，因为项目可能归组织所有，且未关联任何仓库。

我绝不会根据工作目录或之前用过的项目来猜测。同一个仓库关联两个开放项目是常见情况，并非例外，因此询问是正常结果，而不是失败。

然后，我会读取项目字段、仓库标签、组织的问题类型，以及当前所用凭据对应的登录账号，并记录每项的稳定 ID。按定义，这个登录账号是令牌的主体，不一定是请求者，因此在以该账号作为所有权边界之前，我会确认两者是同一人；如果使用的是机器人或共享凭据，就会停止运行。我不会在不同运行之间沿用 ID；如果项目新增字段或重命名选项，缓存的 ID 可能会把内容写入错误位置。

现在加载 ${CLAUDE_SKILL_DIR}/references/board-queries.md。其中包含精确查询，以及用于证明查询已读取全部内容的断言。

缺少标签时，必须通过专用卡片来创建，不能仅凭口头同意就创建。 创建仓库标签会写入共享状态，因此不能在授权步骤之前仅凭礼貌询问就进行。当缺少任一标签时，我会通过 preflight-mutations 提交一张标签创建卡片，列明两个标签、它们的颜色以及涉及的所有仓库；只有得到 ready 判定后才会创建，然后重新读取仓库标签并记录生成的 ID。这张卡片与第 5 节中的标签编辑卡片是分开的：目标是仓库而非问题，而且两者的可逆性不同。

我还会在其他操作开始前确定台账存放在哪里，因为 preflight-mutations 会阻止没有已授权的持久存放位置的多批次运行，而且禁止创建新的存放位置。我会指定请求者已授权本次运行写入的现有产物，或者询问请求者。我不会为了通过关卡而擅自创建文件。

台账每个候选字段占一行，而不是每个候选占一行，并且会在运行中断时作为本次运行的记录。每个候选字段需要在三个可能独立失败的操作类别中进行四次写入，因此，如果每个候选只设一个状态，就可能隐藏失败的写入，或导致已写入的估算值未计入仅统计已写入内容的总数。Field 是行的区分字段，每行都包含自己的当前值、建议值、依据和状态。因此，部分完成的运行会保留已写入的字段行，只对待处理的字段重新提交卡片，这正是 preflight-mutations 预期的恢复形式：

| Item ID | Issue | Owner | Kind | Field | Current | Proposed | Basis | Status |
|---|---|---|---|---|---|---|---|---|
| <item ID> | #<n> | <login> | leaf / umbrella | label / priority / estimate / type | <value> | <value> | <evidence> | candidate / pending / landed / failed / skipped / reconcile-required / conflicted / excluded |

排除项也要作为台账行记录，且它是唯一不带字段的行。其 Field 设为 none，Current 和 Proposed 留空，在 Basis 中填写排除原因，并将 Status 设为 excluded；每个排除项恰好一行，而不是四行。若没有这种格式，中断的运行就会丢失第 2 节要求的排除原因，并且恢复时报告的排除项数量会与首次运行时不同。

关卡。 项目已明确指定，而非推断得出；运行所需的每个概念都已解析出 ID；请求者的身份已知；台账也有经授权的存放位置。否则，运行将停止并说明缺少什么。

2. 确定范围

不带参数时，我会处理所有开放议题：请求者是唯一负责人，且议题位于看板当前的 iterations 列表中的任一迭代。该列表包含当前正在进行的迭代以及所有未来迭代，因此已开始的工作会被分诊，而不会被跳过。已完成的迭代位于单独的列表中，只有明确指定时才会处理。传入参数后，范围会缩小到一个版本、一个状态或一份明确列出的编号。

我会排除拉取请求和草稿项目：它们与议题共用看板，但没有需要设置的字段。

我会主动遵循看板的负责人策略。即使我的技术访问权限很广，共同分配、未分配或负责人不明确的工单也只能只读处理。我会记录每一项排除及其原因，而不是悄悄丢弃，因为总数悄悄漏掉项目，比总数较小但明确说明遗漏内容更糟。

关卡。 候选集准确无误，每项排除都有原因，每个候选项都是状态为 candidate 的账本行。

3. 先确认校准，再预览

在评估批次之前，我会通过一个问题一次性询问。${CLAUDE_SKILL_DIR}/references/calibration.md 中包含我提议的默认设置：估算单位、量级、舍入规则和上限；覆盖不同范围的示例基准；优先级评估标准；以及请求者希望在本次运行中采用的任何项目专属优先级提升规则。

估算单位默认为人工主动投入时间，其定义和参考基准见 ${CLAUDE_SKILL_DIR}/references/calibration.md。

批准评估标准不等于批准具体数字。因此，我接着会从此范围中估算三到五个真实工单，涵盖最小、典型、最大工单以及任何总括工单，并展示估算理由和小计。如果范围内的候选项少于三个，就预览全部候选项，因为关键是让请求者看到具体数字，而不是凑足配额。如果范围内没有候选项，则跳过校准、评估和所有写入操作，直接生成报告，其中总计为零并附上排除清单。只有请求者批准预览后，账本行才会从 candidate 变为 pending。否则，他们第一次看到任何实际应用的数字时，所有写入都已完成。

单位、量级、基准、评估标准、负责人边界或总括工单处理方式一旦改变，所有尚未写入的行都将失效。

关卡。 请求者既批准了校准，也批准了基于其真实工单的预览。

4. 评估每个候选项

我会阅读每个工单的完整正文，并记录四个值：分诊标签、优先级、估算值和类型。

分诊标签回答一个问题：正确行为是否已经确定？ ${CLAUDE_SKILL_DIR}/references/triage-rubric.md 列出了五种无论工单写得多清楚都会判定为 need-human 的情况，以及那些能让问题轻松定论的措辞。难度不在考虑范围内。涉及三百个文件的繁琐工单，只要预期结果明确，就是 agent-ready；而没人说明该改哪一行时，即便只是单行修复，也属于 need-human。

按阈值分配并行任务，而不是默认并行。 候选项少于约四十个时，我会逐项内联阅读。超过这个数量时，我会将评估标准写入一个文件，再将每批约三十个工单交给并行阅读者，每位阅读者只需返回评估结果。后续如需再次评估，我会复用同一批阅读者，而不是重新阅读正文，因为他们已经掌握了相关内容。

每批都会与分配给它的清单进行覆盖差异对比。某位阅读者收到三十个工单却只返回二十九个评估结果，就悄悄漏掉了一个；只有差异对比才能发现这一点。

关卡。 每个候选项都有全部四个值，且每批都完整覆盖其清单。

5. 授权写入

我使用 preflight-mutations，提供看板和字段 ID、项目 ID、当前值和拟议值、所有权策略、已批准的校准和预览、可逆性、恢复计划、失效条件以及权威回读计划。

每类操作一张卡，而不是每次运行一张。 preflight-mutations 会按目标和操作拆分卡片，而此技能会在两个界面上执行三类不同的操作：仓库标签、看板字段值和组织议题类型。每类操作各有自己的卡片和回读计划。同一类别中，一张卡覆盖整批项目，而不是单个项目。

门禁。 每项计划写入都必须归属当前状态为 ready 的对应操作类别卡片。

6. 写入，然后证明已生效

我只执行获授权的写入，将每条响应同时写入日志，然后从权威来源重新读取每个已触及的字段，并逐字段与台账进行比对。

两种故障模式让这一步成为强制要求，而不只是整洁流程；${CLAUDE_SKILL_DIR}/references/board-queries.md 中记录了这两种情况的证据：看板变更可能报告成功却未持久化，议题搜索索引则既有延迟也会截断。因此，退出代码为 0 绝不是证据；验证标签时，要读取议题对象，而不是任何列表。

我会在整个写入日志中搜索失败记录，而不是只看日志末尾，因为格式错误的值可能导致运行中某一行失败，而其他部分看起来都正常。

随后，每一行都会根据观察到的状态获得一个终态：

• 如果回读结果明确，则标记为 landed、failed 或 skipped；
• 如果回读无法确定写入是否已生效，则标记为 reconcile-required。我会停止处理该项目，既不会重试，也不会将其标记为 failed，直到权威查询给出明确结果；
• 如果回读显示某个值在我测量后发生了变化，则标记为 conflicted，这意味着运行期间有人编辑了看板。我绝不会覆盖该值。我会报告两个值，由请求者决定。

门禁。 每项尝试过的写入都必须带有上述状态之一；状态必须依据观察结果确定，绝不能依据命令输出。

7. 报告

我会向请求者提供：

• 按分流标签、优先级和类型统计的数量；
• 按分流标签拆分的预估总量，因为两者不可互换。need-human 工单中的工时必须先投入，Agent 才能开始工作，因此只有 agent-ready 小计能够预测吞吐量；
• 预估触及上限的每张工单，并列出名称，因为上限会掩盖其实际规模，通常也意味着工单需要拆分；
• 每一行 conflicted、reconcile-required、failed 和 excluded 的记录；以及
• 我认为确实难以判断的事项，供请求者推翻我的判断。

总量只根据 landed 行计算。如果无法回读，我会报告计划值和 reconcile-required 列表，不会声称总量已得到确认。

只有在每个候选项都有终态，且所有报告的总量都能根据已生效的值复现时，本次运行才算完成。