build-pr-descriptionlisted

# build-pr-description PR description は reviewer が diff を読むための文書。**Why は論証、What / Test は fact の集合** として書く。Why = 変更を必要とする主張（判断）+ それを支える検証可能な根拠。 根拠だけ並べて結論の復元を読み手に委ねない。骨子は 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 — 書いてよい文は5種だけ 1. **主張** — 変更を必要とする判断を現在形の叙述文で書く（「DB 移行に伴い legacy resource を 解体する必要がある」「AWS が SLA で保証する可用性を自前で観測して metrics 化するのは無駄」）。 1 PR に 1〜3 個。それ以上必要なら PR が大きすぎる 2. **根拠** — 主張を支える検証可能な客観事実。どの主張を支えるかが明示される位置 （主張の直下）に置く 3. **変更の fact** — diff から観測できる変更と、変更後の対外契約 4. **検証結果** — 実行した確認コマンドと実測値 5. **reviewer への注記** — 却下した代替案・設計の前例・migration 上の注意など、 レビューの一往復を先回りで減らすもの 主張の判定: **この主張が偽なら、この PR は不要になるか？** ならないなら動機ではない。 根拠のない主張はただの意見 — 根拠を見��けるか、主張ごと落とす。 どの主張も支えない fact は Why に置かない（Notes 行きか削除）。 文単位で迷ったら: **その文を消したとき、reviewer の diff の読み方や質問が変わるか？** 変わらないなら落とす。 ### 骨子 ```markdown ## Why ## What ### <変更の面ごとに subsection> ## Test ## Notes ``` - section は **h2 で切る**（GitHub の PR body では h1 が過大に render される） - Notes は任意。書くことが無ければ section ごと落とす - allowlist と section の対応: 主張 + 根拠 → Why、変更の fact → What、 検証結果 → Test、注記 → Notes ### 形式 - **Why は主張 → 根拠の2段 bullet**。主張が top-level、根拠をその直下に nest する。 nest を使ってよいのは Why だけ - What / Test / N