pr

PR 本文

レビューを経て作業を取り込む場合、セッション外のレビュアーが読む唯一の成果物は PR 本文です。必要な情報はすでに記録にそろっており、このスキルはそれらをまとめるだけで、すでに確立された内容以外は追加しません。要約にビジュアルを用いる方針は show-me に着想を得ています（クレジットはフロントマターに記載）。

テンプレート

## Summary
<one-line claim, then the smallest visual that proves it>

## Evidence
- **Before:** <output / failing check>
  **After:** <output / passing check>

## Reversibility
<Rollback: cheap via <mechanism> | expensive because <reason>>
<Blast radius: one line>

セクション

概要

変更内容を一文で述べた後、要点が伝わる最小限の図を示します。変更内容に合ったビジュアルを選びます。

• ロジックやアルゴリズム → 疑似コード
• 実行時の制御フロー → 呼び出しツリー
• UI 構造 → コンポーネントツリー
• ファイルの役割や大規模なリファクタリング → 簡潔なファイルツリー
• コンポーネント間の連携やデータフロー → Mermaid 図
• 差分そのもの → 変更の形に合わせた差分（コンポーネント、レイアウト、呼び出しツリー、状態機械）

大部分が新規の場合、省略したコンテキストによって責任範囲が分からなくなる場合、またはレビュアーがコピーできる完成形を必要とする場合に限り、ブロック全体を示します。通常はビジュアル一つで十分です。すべての形式を並べることは避けてください。

エビデンス

verify プロトコルの出力（BUILD、TEST、LINT、FUNCTIONALITY のエビデンス）を使用します。鮮度に関するルールも引き継ぎます。変更前後のペアを示し、変更前は失敗し変更後は成功した正確なチェック内容を、出力から引用します。変更が視覚的な場合は、キャプチャしたスクリーンショットを優先します。qa-tester を使えば、実行中の環境を操作して撮影できます。ここでエビデンスを再収集してはいけません。また、verify の実行で得られていないエビデンスを主張してはいけません。

可逆性

差分そのものに ADR テストを適用します。launch が意思決定に用いるのと同じ三つの質問です。元に戻すのが難しいか。文脈なしでは意外に感じるか。実際のトレードオフの結果か。すべて「いいえ」なら、ロールバックは簡単です。方法（マージをリバートする、フラグを切り替える）を記載します。一つでも「はい」なら、ロールバックにはコストがかかります。その理由を記載します。まず、変更が二方向ドア（元に戻すのが簡単で一般的）か、一方向ドアかを分類します。二方向ドアには、戻し方を記す以上の手順は不要です。一方向ドアの場合は、その旨を明記し、何によって不可逆になるかを示します。変更が ADR を実装する、または ADR に関わる場合は、その ADR へのリンクを記載します。最後に、影響範囲を一行で締めくくります。この変更がほかに何を動かし得るかを示します。

用語

用語集がある場合は GLOSSARY.md の用語を使用します（まだ移行されていないレガシーな領域では、引き続き CONTEXT.md を使用します）。PR はセッション外で読まれます。用語集は、読者と PR が共有する唯一の語彙です。

トリガー

• プラットフォームが PR を通じてレビューする場合、launch のフェーズ 5 で、このスキルが作成した PR 本文を完了レポートに含めます。
• PR を新規作成する、または実質的な更新を行うすべてのセッション。

出力

• そのまま貼り付けられる PR 本文
• 参照する記録へのリンク（verify のエビデンス、ADR、仕様）