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 の場合は、その出所とスラッグを表示してから進めます。 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 — cure の選択とコンフリクトの解決の前にゲートを追加します。 このフラグを指定しても、デフォルトの返信ゲートは省略されません。
• --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 を読んでください。 ヘルパーの解決、エージェントのディスパッチ、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 で停止します。 終了コードが 0 以外の場合は、status: halt: pr-status-unavailable で停止します。 マージ状態に競合または未コミットの変更がある場合は、## Merge-conflict resolution に進みます。
3. PR をチェックアウトします。 gh pr checkout <pr> を実行します。 最新のレビューと /cure は、作業ツリーから PR のヘッドを読み取ります。 ## 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 に記載します。 現在のヘッドですでに修正されている指摘は ## Already-addressed に記載します。
8. レポートを作成します。 .cheese/affinage/pr-<n>.md を作成します。 4 行のハンドオフスラッグから始めます。 /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 に送ります。 2 回目の /cure は再レビューしないでください。 これらの指摘への返信は下書きしないでください。 残っている各指摘を残存課題として報告します。
13. 返信を投稿します。 下書きしたすべての返信と、すでに対応済みのすべてのスレッドを一覧にした返信確認ゲートを 1 つ表示します。 --auto が有効な場合にのみ、このゲートをスキップします。 承認された返信は python3 skills/affinage/scripts/affinage.pyz post-reply で投稿します。 返信なしで、承認された対応済みスレッドをそれぞれ解決済みにします。
14. 公開します。 承認された返信をすべて投稿した後にのみ、この手順を実行します。 /cure で少なくとも 1 つの修正が適用された場合は公開します。 /melt でマージ競合を解決した場合も公開します。 ターミナルで /plate [--open-pr] [--hard] [--safe] を実行します。 次に ../cure/SKILL.md の PR 後の学習内容の書き戻しを実行します。 作業ツリーに変更がない場合は、公開と書き戻しをスキップします。

新規レビュー

スタンドアロンモードでは、entry="affinage" を指定してルーターを呼び出します。 PR の参照情報とルーターの値を /age に渡します。 これにより、/age が entry="age" でより小さなルートを計算するのを防ぎます。 各結果を [from-age:<dimension>] を付けて、該当する重大度セクションに追加します。 ほかの指摘と同様に、これらの指摘を /cure に送ります。 これらの指摘について、GitHub の返信は投稿しないでください。

外部の主張を評価する前に、新規レビューを実行してください。 この順序にすると、重複する指摘を削除できます。 評価ステップと同じエージェントゲートを使用します。 各 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 を参照してください。

サブエージェントのコンテキストゲート

会話、選択、承認状態、返信の投稿は親コンテキストで管理してください。 次のいずれかの制限に該当する場合は、読み取り専用の新しい reviewer を使用します。

• 入力が 10 件を超える。
• 差分が約 25 KB を超える。
• スレッドが 5 ファイルを超える。

共有エージェントリゾルバーを通じて reviewer を解決します。 reviewer のプロンプトは、Review mode: severity-report の行で始めてください。 この行がない場合、reviewer エージェントは 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 に書き込みます。 4 行のハンドオフスラッグから始めます。 続けて /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 を設定します。

少なくとも 1 つの調査結果が medium+ の下限を満たす場合は、next: cure を設定します。 重大度の調査結果がない場合は、next: done を設定します。 選択された調査結果が空の場合も、next: done を設定します。

自動モード

--auto または --plate が有効な場合は、references/auto-mode.md を読みます。 ここでは、選択、cure チェーン、返信、公開の手順を定義しています。

--hard モード

終端の /plate に --hard を渡します。 /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 を使用します。

エージェントの解決

各ディスパッチは ../cheese/references/agent-resolution.md に従って解決します。

作業	推奨タイプ	権限／分離	最小能力	労力	フォールバック
レビューの主張と CI の証拠をトリアージする	reviewer	読み取り専用、新しいコンテキスト	強力	高	互換性のある reviewer、その後 general

正規の affinage レポートには、共有の agent_resolution ブロックが含まれます。