なので、わかりやすい機能追加やバグ修正は私がやります。これが仕事です。とはいえ、PRレビューが同僚の時間をあまり食い尽くさないように、いくつかの手順を踏んでいます。
その前に、ワークスペース用のグローバル CLAUDE.md にルールを追加しました。Claude は本番（production）に触ってはいけない、そしてリモートの GitHub リポジトリへプッシュしてはいけない、というものです。私がそう指示するまで、すべてローカルにとどめます。
Step 1: ローカルレビュー
Claude に「local review」と呼ばれるものを作るよう依頼しました。PR を出す前にこれを実行します。これは、私の機能ブランチのステージ済み変更を取り込み、リモートのベースブランチを取得して、差分のレビューを開始します。コマンドは次のようになります。
/local-review <repo> <base-branch> <feature-branch>
もし何かブロッカーや必ず直すべき点があると指摘されたら、それを解決してもう一度実行します。
Step 2: PR サマリー
次に、次の内容で PR サマリーを書くよう依頼します。
/pr-summary <repo> <base-branch> <feature-branch>
それは、コミットメッセージと、What、Why、テスト計画を含む適切なサマリーを返してくれます。出力はだいたい次のような感じです。
検索ドロップダウンにロード状態を追加し、タイプが速いと古い結果が新しい結果を上書きしてしまう競合状態（race condition）を修正する。
What
- 結果を取得している間、入力欄の中にスピナーを追加する
- 新しいクエリが入力されたら、進行中のリクエストをキャンセルする
- クエリで何も返ってこない場合は空の状態を表示する（以前は空のボックスを描画していた）
Why
- タイピングが速いと古い結果が新しい結果の上に表示されてしまい、混乱を招いていた
- ユーザーに「リクエストが処理中である」ことのサインがなかった
- 空の結果は、コンポーネントが壊れているように見えた
Test plan
- ビルドが通る
- ゆっくりタイプして、スピナーが表示され結果が描画されることを確認
- 速くタイプし、バックスペースしてもう一度タイプする — 最後のクエリの結果だけが表示されるはず
- 該当がないものを検索する — 空の状態が描画されるはず
<ticket link>
<asset link>
そして、これらのどれかを忘れないように、DEV_GUIDE.md にすべてを一箇所にまとめておくよう Claude に頼みました。そのおかげで、これまでのところ生活がだいぶ楽になっています。
より良くするための提案があれば、ぜひ教えてください。
