出す前のチェック
テストや CI では見つからないものを見つけます。ブラウザのコンソール、誰もクリックしていない所、そして失敗したときに何が起きるか。
コマンド 1 つ、1 分ほど
/kaeru:check — /kaeru:submit の前に実行します。見るだけで、何も変更しません。
テストは「誰かがテストを書いたもの」を見つけます。CI は、そのテストが見つけるものを見つけます。それでもレビューまで届いてしまうのは、そのどちらも見ていない短いリストです。しかもその 1 つひとつは、1 分あれば自分で確かめられるものばかりです。
> /kaeru:check
出す前のチェック
テストと lint ................. ✅ 3 件通過
ブラウザのコンソール ............ ⚠️ /pricing に hydration の警告が 2 件
変更した所をクリック ............ ✅ サインインのリンクは /sign-in に移動
失敗したらどうなる .............. ⚠️ エラーを受け止める処理がまだない
毎回呼ばれるか .................. ✅ 結果は覚えている
自信がない所 .................... ボタンの文言
⚠️ は「出す前に見ておくとよい」という意味で、間違えたという意味ではありません。実際のプロジェクトで動かしたところです。小さな静的サイトに「Sign in」リンクを 追加した変更を確認しています。日本語で書けば、答えも日本語で返ってきます。
それぞれの行の意味
テストと lint
プロジェクトにもともとあるチェックです。CI が赤くなってからではなく、出す前に実行するだけの違いですが、その順番に意味があります。
ブラウザのコンソール
あなたの変更を実際のブラウザで開いて、コンソールを読みます。
ここがいちばん大事です。ほかのどこにも出てこない問題があるからです。 hydration の警告はテストを落としませんし、URL を確認しても出てきませんし、スクリーンショットでもページは正しく見えます。コンソールにだけ出て、たいていは「誰かのスマートフォンでおかしくなる」の最初のサインです。
変更した所をクリック
リンクを追加したなら、実際にたどって、どこへ行ったかを教えます。ボタンなら押します。フォームなら入力して送信します。
行き先が間違っているリンクは、差分で見ても完璧に見えますし、スクリーンショットでも完璧に見えます。確かめる方法はクリックすることだけなので、このチェックはクリックします。
失敗したらどうなる
サーバーと通信する変更や、データを取ってくる変更のときだけ確認します。その通信が失敗したら何が起きますか？ エラーになったり、時間切れになったり、何も返ってこなかったとき、ページはそれでも動きますか、それとも壊れますか。受け止める処理がなければ、そう言います。
開発中に動くのは、通信相手が自分のパソコンで、遅くならないからです。失敗はそれ以外の場所で起きます。
毎回呼ばれるか
同じ場面での質問です。それは誰かがページを開くたびに毎回動きますか。結果を覚えている仕組みはありますか。 1 回の表示ごとに動く通信は、サイトが混むまで誰にも見えず、混んだときに「サイトが重い理由」になります。
自信がない所
チェックでは決められなかったことを、あなたのことばで書き出します。/kaeru:submit がそれをプルリクエストに入れます。
自信がないと書くのは、やり残しを認めるようで気が引けるかもしれません。実際は逆です。レビューする人の判断が必要な場所を、探させずにそのまま指し示せます。「ここは『Welcome』と『ようこそ』のどちらがいいか迷いました」の 1 行は、黙っているより確実にレビューを速くします。
忘れても実行されます
/kaeru:submit は、コミットの前に同じチェックを実行し、未解決のものがあれば止まります。「それでも進めて」と言うこともできます。それはあなたの判断ですが、知らないまま進むのとは違います。
「誰かが思い出したときだけ実行されるチェック」は、やがて実行されなくなるからです。
プラグインを使わない場合
プラグインを使っていない、あるいは .kaeru/where.md がないリポジトリなら、プルリクエストを開く前にこれを貼ってください。同じリストをプロンプトにしたものです。
PR を開く前に、この変更を自分でレビューして、結果を表で見せてください。
1. 変更が影響するページを、開発サーバーのブラウザですべて開いてください。新しい
コンソールのエラーや警告、特に hydration の警告はありませんか。触っていない
ページと比べて、もともと出ていたものを報告しないようにしてください。
2. 変更した所をクリックしてください。新しいリンクはたどり、新しいボタンは押し、
変更したフォームは送信してください。「こうなるはず」ではなく、実際に何が
起きたかを教えてください。
3. プロジェクトの lint、型チェック、テストを実行してください。
4. この変更がサーバーや API、外部サービスを呼ぶなら、2 つの質問に正直に答えて
ください。その呼び出しが失敗したら何が起きますか。毎回呼ばれて、結果を覚える
仕組みはありませんか。
5. 確認できなかったこと、自信がないことを、PR の説明に書けるように普通のことばで
挙げてください。
まだ何も直さないでください。先に表を見せてください。実行しなかったチェックは
「通過」ではなく「未実施」と書いてください。実行しなかったチェックに ✅ をつけない理由
このチェックは、実際に実行したことだけを報告します。誰も確かめていない ✅ は、警告よりたちが悪いのです。レビューする人の時間だけでなく、信頼も使ってしまうからです。
どちらの仕事か
/kaeru:check はあなたの仕事で、プルリクエストができる前に行います。目に見える範囲で何か壊していないか、という確認です。
そのあとプルリクエストを検証すること — 最新の main と合わせてみる、機能をひと通り通す、変更前と変更後を並べて比べる — は開発者の仕事で、あなたが出したあとに開発者のパソコンで行われます。そこまでやる必要はありません。