## Summary {1〜2行で「何を変えたか」を要約} Closes #{issue番号} ## Why {なぜこの変更が必要か。背景・課題・ユーザー価値} ## How - {主要な実装方針 1} - {主要な実装方針 2} - {採用しなかった案とその理由（あれば）} ## Test plan - [ ] {ユニットテストを追加・更新した} - [ ] {手元で動作確認: {手順}} - [ ] {既存テストが通る} - [ ] {Storybook / スクショで UI 確認} ## Screenshots | Before | After | | --- | --- | | {画像} | {画像} | ## Deploy notes {マイグレーション、env 追加、feature flag、ロールバック手順 など / なければ「特になし」} ## Reviewer hint {重点的に見てほしいファイル・観点}

## 概要 {1行で何が起きているか} ## 再現手順 1. {手順1} 2. {手順2} 3. {手順3} ## 期待する挙動 {こうなるはず} ## 実際の挙動 {こうなってしまう} ## 影響範囲 - 発生頻度: {毎回 / 時々 / 1回のみ} - 影響ユーザー: {全員 / 特定セグメント / 自分のみ} - 重要度: {Critical / High / Medium / Low} ## 環境 - OS: {macOS 15.x / iOS 18.x / Android 14} - ブラウザ / アプリバージョン: {Chrome 130 / v2.3.1} - ユーザーID（あれば）: {uid} - 発生日時: {YYYY-MM-DD HH:MM JST} ## ログ・スクショ ``` {エラーログ} ``` {スクショを添付} ## 暫定回避策 {あれば}

## 解きたい課題（Problem） {誰が、どんな状況で、何に困っているか} ## ユーザーストーリー {ユーザータイプ}として、{したいこと}したい。なぜなら{価値}だから。 ## 提案する解決策（Solution） {どう解決するか。UI イメージや導線} ## 代替案（Alternatives） - {案A}: {採用しなかった理由} - {案B}: {採用しなかった理由} ## 受け入れ基準（Acceptance Criteria） - [ ] {検証可能な条件 1} - [ ] {検証可能な条件 2} - [ ] {計測指標が改善する: {KPI}} ## スコープ外（Non-goals） - {今回はやらないこと} ## 参考 - 関連 Issue: #{番号} - ドキュメント: {URL}

# Conventional Commits 1.0.0 — よく使うパターン ## feat（新機能） feat({scope}): add {機能名} to {対象} 例) feat(auth): add Google OAuth sign-in ## fix（バグ修正） fix({scope}): prevent {問題} when {条件} 例) fix(api): prevent NPE when user has no profile ## docs（ドキュメントのみ） docs({scope}): update {対象} for {理由} 例) docs(readme): update setup steps for Node 22 ## refactor（挙動変更なし） refactor({scope}): extract {関数名} from {元の場所} 例) refactor(billing): extract calcTax from invoice service ## perf（パフォーマンス改善） perf({scope}): reduce {対象} from {Before} to {After} 例) perf(query): reduce list fetch from 2.1s to 0.4s ## test（テスト追加・修正） test({scope}): add unit tests for {対象} ## build / ci / chore build(deps): bump {package} from {old} to {new} ci: add {workflow} for {目的} chore: bump version to {x.y.z} ## BREAKING CHANGE（破壊的変更） feat({scope})!: {変更内容} BREAKING CHANGE: {何が壊れるか、移行方法}

# Code Review コメント プレフィックス集 ## nit:（細かい指摘・任意） nit: {変数名}より{提案}のほうが意図が伝わりやすいかもしれません。 → マージブロックしません。 ## question:（質問） question: ここで{処理}を行っているのは、{推測}という理解で合っていますか？コメントがあると後で読み返したときに助かります。 ## suggestion:（コード提案） suggestion: ```ts {改善後のコード} ``` {理由} ## blocking:（マージ前に必ず対応） blocking: {問題点}。{セキュリティ / データ整合性 / パフォーマンス}の観点で、マージ前に修正が必要です。 ## praise:（良いコードへの称賛） praise: {ポイント}の設計、わかりやすくて好きです。次回も真似させてもらいます。 ## thread:（議論を別途） thread: 範囲が大きくなりそうなので、別Issue #{番号} で議論しませんか？このPRはこのままLGTMで構いません。

:pray: PRレビューお願いします {PRタイトル} {PR URL} *概要* {1〜2行} *重点的に見てほしい点* • {観点1} • {観点2} *規模*: +{追加行数} / -{削除行数} / {ファイル数} files *緊急度*: {今日中 / 今週中 / 急がない} *マージ希望日*: {YYYY-MM-DD} お手すきの時で構いません、よろしくお願いします :bow:

LGTM :rocket: {良かった点を一言: 例「テストカバレッジが上がっていて安心です」} {細かい指摘があれば nit として} nit: {軽微な指摘}（次回でも、別PRでも、対応不要でもOK） {マージ後のフォロー事項があれば} マージ後に: {本番反映後の確認事項 / Issue化したい改善点}

:construction: WIP / Draft PR ## 現状 {今どこまで実装したか} ## 残タスク - [ ] {残り1} - [ ] {残り2} - [ ] テスト追加 - [ ] ドキュメント更新 ## 早めに相談したいポイント - {設計判断 1}: {A案 vs B案、どちらが良さそうか} - {設計判断 2}: {懸念事項} 方向性だけでも先にコメントいただけると嬉しいです :pray: