build-pr-descriptionlisted

# build-pr-description PR description を「reviewer が diff を読むために必要な fact の集合」として書く。 骨子は PR template の de facto（Google の CL description ガイド・Kubernetes template などが収束する Why → What → Test）に従う。how の解説は diff 自身が語るので書かない。 build-readme と同じく、匂い狩り（denylist）ではなく **書いてよい文の allowlist** で判定する。該当しない文は書かない。 publish-pr（PR 作成 flow）は body の作成をこの skill に委譲する。 body の有無で変えるのは fact の収集経路だけ。既存 body は候補の入手元にはするが、 正しい記載として継承しない。新規作成と全面再構築に同じ骨子・形式・完了チェックを適用する。 ## ルール ### allowlist — 書いてよい文は4種だけ 1. **動機** — 変更を必要とする客観事実。反復する要求・現状の欠落・守るべき契約を **現在形の叙述文**で書く（「〜の確認が必要」「〜するレイヤーが存在しない」） 2. **変更の fact** — diff から観測できる変更と、変更後の対外契約 3. **検証結果** — 実行した確認コマンドと実測値 4. **reviewer への注記** — 却下した代替案・設計の前例・migration 上の注意など、 レビューの一往復を先回りで減らすもの 判定に迷ったら: **その文を消したとき、reviewer の diff の読み方や質問が変わるか？** 変わらないなら落とす。 ### 骨子 ```markdown ## Why ## What ### <変更の面ごとに subsection> ## Test ## Notes ``` - section は **h2 で切る**（GitHub の PR body では h1 が過大に render される） - Notes は任意。書くことが無ければ section ごと落とす - allowlist の4種と section が1対1に対応する: 動機 → Why、変更の fact → What、 検証結果 → Test、注記 → Notes ### 形式 build-readme と同じ3形式（bullet list / table / code block）+ 1 fact 1 bullet。 paragraph（地の文）は全面禁止 — Why も bullet で書く（動機1つ = 1 bullet に分解できないなら 動機を理解できていない）。table は test 一覧・endpoint と契約の対応など、 行の比較に意味があるとき bullet より優先する。 例外: **Notes の bullet は理由節をぶら下げてよい**。README では理由節は弁明の 再侵入だが、Notes では rationale が fact そのもの （「Tavern も検証のうえ pure pytest を採用 — assertion が YAML から漏れるため」で1 fact）。 ### 判断の住処 — 決定の寿命で分ける - diff レビューの一往復を減らす情報（「なぜ X じゃないの？」への先回