Issueは「事実」と「期待」を分ける

不具合の報告で最も多い失敗は、起きたことと、起きてほしかったことが混ざることです。見出しで分けてしまえば自然に整理されます。

## 何が起きたか

送信ボタンを押しても画面が変わらない。

## 期待していたこと

完了画面に遷移する。

## 再現手順

1. 問い合わせフォームを開く
2. すべて入力する
3. 送信ボタンを押す

## 環境

Chrome 129 / macOS / 画面幅 1440px

原因は断定しない

「たぶんJavaScriptのエラーです」と書きたくなりますが、推測を書くと、受け取った側の調査がその方向に引っ張られます。 観察した事実（エラーメッセージ、ステータスコード）はそのまま貼り、判断は委ねてください。

Pull Requestは「何を」より「なぜ」

変更内容はコードの差分を見れば分かります。差分から読み取れないのはなぜそうしたかです。

## 背景

問い合わせが月13件あるのに、どこにも通知されていなかった。

## やったこと

保存後に通知を送る。通知が失敗しても問い合わせは残す。

## 確認したこと

通知が例外を投げても完了画面が出ることをテストで固定した。

テンプレートに従う

多くのリポジトリには .github/ISSUE_TEMPLATE や PULL_REQUEST_TEMPLATE.md が置かれています。見出しを勝手に変えないでください。 揃っているからこそ、レビューする側が必要な情報を探さずに済みます。

• Issueは事実と期待を分ける
• Pull Requestは意図を書く
• テンプレートを使う