affinage

/affinage

对 PR 中现有的主张采取行动。 主张可能来自审查者、CI 检查或合并冲突。 通过 /age 视角对每条主张进行评估。 将接受的主张发送给 /cure。

/affinage 始终评估 PR 上已有的主张。 入口路径决定是否也会查找新的 /age 发现：

• 独立运行 — 用户在没有 handoff_context 的情况下启动 /affinage <pr>。 除非用户传入 --no-age，否则对 PR 差异运行 /age。 将新发现添加到同一份报告中。
• 链式运行 — /cook 或 /cure 提供 handoff_context。 跳过新一轮审查，因为 /age 已在此链中运行。

有关入口规则，请参阅 ## Fresh review。 有关冲突处理路径，请参阅 ## Merge-conflict resolution。

阶段入口

运行 python3 skills/affinage/scripts/affinage.pyz wheypoint-resolve --ref <slug>。 authoritative 使用记录；其 working_context 是首批批量 tilth_read 的内容。 not-found 将进行冷启动；legacy 会显示其来源和 slug，然后继续。 遇到 gated、ambiguous 和 error 时停止并显示载荷。 显示提示性的 stale-commit 和 grounded-path-missing 发现。

输入

/affinage [<pr-ref>] [--auto --stake <floor>] [--plate] [--safe] [--open-pr] [--hard] [--full] [--include-outdated]

<pr-ref> 接受 PR 编号、PR#<n> 引用或完整的 GitHub PR URL。 调用 pr-status 前先提取整数。 该命令只接受整数。 如果没有引用，则在当前分支上运行 gh pr view --json number。

标志：

• --auto --stake <floor> — 无需选择提示即可运行。 <floor> 接受 blocker、high、medium+ 或 all。 单独使用 --auto 时，默认下限为 medium+。 使用与 /cure 相同的下限规则。 发送 /cure --auto --stake <floor>。 无需提示即可发布回复。 请参阅 references/auto-mode.md。
• --safe — 在选择修复项和解决冲突前添加门控。 此标志不会移除默认的回复门控。
• --open-pr — 如果不存在 PR，则允许终端版 /plate 新建 PR。 如果没有此标志，/plate 只会更新开放的 PR。
• --plate — 运行 --auto --stake medium+ --open-pr。 评估这些主张。 修复选定的发现。 发布回复。 然后运行 /plate。 显式指定的 --stake <floor> 会取代 medium+。
• --hard — 将元认知门控标志传递给终端版 /plate。
• --full — 当低优先级发现不少于 10 条时，显示所有低优先级发现。
• --include-outdated — 包含已过时的审查讨论串。
• --no-age — 在独立运行模式下跳过新一轮审查。 此标志在链式运行模式下无效。

阅读 ../cheese/references/harness-portability.md 了解可移植性规则。 其中涵盖辅助工具解析、Agent 调度、GitHub 操作和交接转换。 优先使用捆绑版或仓库辅助工具。 不要在调用路径中使用 ${CLAUDE_SKILL_DIR} 环境变量。 以下交接块定义了可移植契约。 此处适用“斜杠命令是宿主渲染形式，而非控制模型”这条规则。

流程

阅读 references/flow-details.md，了解确切命令、退出代码和评估原因。

1. 解析 PR。 使用 <pr-ref> 或 gh pr view --json number。 将 PR#<n> 引用或 PR URL 规范化为整数。 从 Git 远程仓库解析 <owner>/<repo>。
2. 获取 PR 状态。 运行 python3 skills/affinage/scripts/affinage.pyz pr-status <pr>。 如果存在 logs_expired: true 字段，则停止并设置 status: halt: pr-status-logs-expired。 如果退出码非零，则停止并设置 status: halt: pr-status-unavailable。 将存在冲突或脏状态的合并转至 ## Merge-conflict resolution。
3. 检出 PR。 运行 gh pr checkout <pr>。 全新审查和 /cure 从工作树读取 PR 的 head。 如果 ## Merge-conflict resolution 已检出 PR，则跳过此步骤。 切换分支前，如果工作树不干净，则停止并设置 status: halt: pr-checkout-dirty-tree。 使用 --safe 时，先询问是否执行检出。 如果检出失败，则停止并设置 status: halt: pr-checkout-failed。
4. 获取评论。 从 pulls/<pr>/comments 获取行内讨论串。 除非用户传入 --include-outdated，否则跳过 position: null 的评论。 从 pulls/<pr>/reviews 获取审查正文。 保留每条非空正文。 根据 pull_request_review_id 去重。
5. 跳过已答复的讨论串。 从 GraphQL reviewThreads 读取讨论串的解决状态。 跳过 GitHub 标记为已解决的讨论串。 如果已解决该讨论串的 GitHub 用户名在根评论之后回复，也跳过该讨论串。
6. 运行全新审查。 仅在未使用 --no-age 的独立模式下运行此步骤。 构建带上下文的审查输入，并调用捆绑的 age-route 命令。 加入第 5 步中未解决的讨论串数量和 CI 失败类别。 使用完整的主题计划及其证据运行 /age。 为每项新发现添加 [from-age:<dimension>] 标签。
7. 评估主张。 按 /age 维度和严重程度规则对每项主张分类。 不要因为审查者选择了 CHANGES_REQUESTED 而提高严重程度。 将可直接修复的问题放入严重程度分区。 将需要外部证据的主张放入 ## Needs-investigation。 将错误、缺乏依据或影响范围较大的主张放入 ## Reviewer-rejected。 将当前 head 已修复的主张放入 ## Already-addressed。
8. 编写报告。 写入 .cheese/affinage/pr-<n>.md。 以四行交接标识开头。 添加 /age 报告正文和 affinage 分区。 参见 ## Output。
9. 执行或询问。 遵循 ## Handoff。
10. 起草非 cure 回复。 为驳回的主张和需调查的主张起草回复。 不要回复 CI 或全新审查发现的问题。
11. 起草 cure 回复。 仅在 /cure 之后运行此步骤。 从 .cheese/cure/pr-<n>.md 读取 ### Applied 和 ### Deferred。 对已应用的评论问题，起草 Fixed — <applied summary>.。 对已延后的评论问题，起草 Attempted fix reverted — <reason>.。
12. 重新审查 cure 差异。 仅在未使用 --auto 运行 /cure 后运行此步骤。 /cure --auto 会运行自己的限定范围 /age 链。 运行 .cheese/cure/pr-<n>.md 建议的 /age <slug> --scope <touched-path> 命令。 每个 reviewer 工作线程提示词都以 Review mode: severity-report 这一行开头。 使用 /age 的发现，而不是其交接门控。 按照 ## Handoff 规则，将新发现交给另一次 /cure 处理。 不要重新审查第二次 /cure。 不要为这些发现起草回复。 将每项仍存在的发现报告为残留问题。
13. 发布回复。 展示一个回复确认门控，其中列出每条已起草的回复和每个已处理的讨论串。 仅当启用 --auto 时跳过此门控。 使用 python3 skills/affinage/scripts/affinage.pyz post-reply 发布已批准的回复。 对每个已批准且已处理的讨论串，不附带回复直接将其标记为已解决。
14. 发布更改。 仅在所有已批准的回复发布后运行此步骤。 如果 /cure 应用至少一项修复，则发布。 如果 /melt 解决了合并冲突，也要发布。 执行终端命令 /plate [--open-pr] [--hard] [--safe]。 然后按照 ../cure/SKILL.md 执行 PR 后的学习回写。 如果工作树没有更改，则跳过发布和回写。

全新审查

独立模式会以 entry="affinage" 调用路由器。 将 PR 引用和路由器值传递给 /age。 这样可以避免 /age 使用 entry="age" 计算出更小的路由。 将每项结果添加到对应的严重性部分，并标注 [from-age:<dimension>]。 像处理其他发现一样，将这些发现发送给 /cure。 不要为这些发现发布 GitHub 回复。

在评估外部声明之前，先进行全新审查。 这样可以移除重复发现。 使用与评估步骤相同的 Agent 门控。 每个 reviewer 工作器提示词都以这一行开头：Review mode: severity-report。

合并冲突解决

当 pr-status 报告存在冲突时，将 PR 交给 /melt。 /melt 使用 mergiraf、rerere 和 kdiff3。 不要手动解决冲突。

默认模式和 --auto 模式会在 /cure 之前执行 checkout 和 /melt。 --safe 要求先通过交接门控。 如果 /melt 失败，写入 status: halt: merge-conflicts-need-human 并停止。 /melt 不会提交解决结果。 终端 /plate 会提交并推送该解决结果。 参见 references/merge-conflict.md。

子 Agent 上下文门控

在父上下文中保留对话、选择、审批状态和回复发布。 只要满足以下任一限制，就使用全新的只读 reviewer：

• 输入超过 10 个。
• diff 超过约 25 KB。
• 线程涉及超过 5 个文件。

通过共享的 Agent 解析器解析 reviewer。 reviewer 提示词以这一行开头：Review mode: severity-report。 如果缺少这一行，reviewer Agent 会返回 blocked: missing-contract。 仅在 degraded: true 时使用通用工作器。 reviewer 会返回已分级发现的精简摘要。 每项发现都包含其维度、严重性、置信度、证据和反驳草稿。 父上下文负责撰写报告、控制选择、调用 /cure 并发布回复。 有关摘要限制，请参见 ../age/references/sub-agent-gate.md。

首选工具与备用方案

源代码操作请使用 code-intelligence-routing.md。 使用以下 affinage 工具：

需求	首选	备用方案
PR 状态	python3 skills/affinage/scripts/affinage.pyz pr-status	gh pr checks 和 gh pr view
GitHub 获取	gh api	无；停止该技能
发布回复	python3 skills/affinage/scripts/affinage.pyz post-reply	无；直接调用 gh api 会遗漏归属信息

输出

将报告写入 .cheese/affinage/pr-<n>.md。 以四行交接标识开头。 然后添加 /age 报告正文和 ## PR status 部分。 使用 /age 中的严重性部分。 添加来自 /affinage 的 ## Needs-investigation 和 ## Reviewer-rejected 部分。 参见 references/report-template.md。

status: <canonical status field>
next: cure | done
artifact: <path-to-prior-cure-or-press-report-if-any>
<one-line orientation: what the PR does and what was graded>

使用 交接契约 中的规范 status: 语法。 只有 next: 和额外的键值行因阶段而异。 省略空部分。 评估完成后使用 status: ok。 如果 gh 或 pr-status 失败，则使用 status: halt: <reason>。 按照 ## Handoff 中的规则设置 next:。

交接

流程： culture → mold → cook (⇄ press) → age → cure → plate。 /affinage 与 /age 并行运行，并将发现发送给 /cure。

默认情况下，affinage 无需提示词即可运行。 仅当选定的修复较大、发现相互冲突或启用 --safe 时才询问。

• 存在严重性发现。 计算建议的 all-medium, cheap 选择。 若没有需要询问的原因，宣布该选择。 然后将锁定的 handoff_context 发送给 /cure。 然后为每条拟定的回复显示一个回复确认选项。 该确认选项涵盖已应用、暂缓、反驳和调查类回复。 若有需要询问的原因，则改为显示 cure 选择确认选项。 使用 ../cheese/references/handoff-gate.md 中的共享确认选项。 预选组合项并标明较大的条目。 --auto 会跳过这两个确认选项。
• 仅存在被驳回或调查类主张。 不要调用 /cure。 显示回复确认选项。 然后等待选择。 --auto 会跳过此确认选项。

然后继续执行 Flow 第 10 至 14 步。 无待处理操作时，将 status: ok / next: done。

至少有一条发现达到 medium+ 门槛时，将 next: cure。 不存在严重性发现时，将 next: done。 选定的发现为空时，也将 next: done。

自动模式

启用 --auto 或 --plate 时，阅读 references/auto-mode.md。 该文件定义选择、cure 链、回复和发布步骤。

--hard 模式

将 --hard 传递给终端 /plate。 /plate 验证最终产物后会运行 /hard-cheese。 此调用链中的 /cure 不会调用 /plate。 因此，该确认选项只会在发布环节运行一次。

规则

• 每项评级都要以代码证据为依据。
• 优先采用范围明确的修复，而非反驳。
• 将有效且范围明确的质量修复作为 Low 发送给 /cure。
• 仅将错误、缺乏依据或较大的主张归入 ## Reviewer-rejected。
• 切勿在 affinage 中应用代码修复。
• 将代码修复发送给 /cure，将合并冲突发送给 /melt。
• 未经批准，切勿发布回复或解决讨论串，除非启用了 --auto。
• 仅通过 python3 skills/affinage/scripts/affinage.pyz post-reply 发布回复。
• 每条回复都以 agent on behalf of <handle> 结尾。
• 从 RESPOND_GH_HANDLE、gh api user --jq .login 或 git config user.name 获取 <handle>。
• 仅使用 GraphQL 读取 reviewThreads 状态并解决已处理的讨论串。
• 遵循 ../age/references/voice.md 中的语气规则。
• 使用 certain、speculating 或 don't know 表示置信度。
• 无需对任何主张进行评级时，说明不存在发现。

参考资料

在适用触发条件时，阅读对应的 affinage 参考资料：

• references/flow-details.md — 执行 Flow 第 2、3、5、6、7、10 或 13 步时阅读。
• references/merge-conflict.md — pr-status 报告合并冲突或脏合并状态时阅读。
• references/report-template.md — 在 Flow 第 8 步编写报告时阅读。
• references/handoff-templates.md — 显示 cure 选择确认选项或回复确认选项时阅读。
• references/auto-mode.md — 启用 --auto 或 --plate 时阅读。
• references/commands.md — 需要了解捆绑命令的确切标志时阅读。 该文件是生成的命令清单。

使用 ../age/references/sub-agent-gate.md 中的共享 Agent 确认选项。

Agent 解析

通过 ../cheese/references/agent-resolution.md 解析每项调度。

工作	首选类型	权限/隔离	最低能力	工作量	后备方案
分流审查主张和 CI 证据	reviewer	只读、全新上下文	强	高	兼容的 reviewer，然后是通用类型

规范的 affinage 报告包含共享的 agent_resolution 区块。