checkpoint について
初めてプロダクトをリリースする開発者向けのGitチェックポイントスキルです。エージェントに適切なタイミングで状態を保存させ、変更を平易に伝え、安全な復元を支援します。
主な機能
- 01開発の節目でコミット
- 02利用者目線のコミットメッセージ
- 03プッシュの説明と管理
- 04以前の状態への安全な復元支援
- 05秘密情報を含むコミットの防止
活用シーン
- 01リスクの高い編集前に動作状態を保存
- 02セッション終了前に進捗を記録
- 03回帰後に以前のチェックポイントへ復元
- 04認証情報のコミットを防止
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/checkpointを入力して読み込まれたか確認します。
詳細
チェックポイント
動いているアプリも、コミットされていなければ、たった一度のよくない編集で消えてしまいます。作っている人は、まだそれに気づいていないかもしれません。でも、あなたは知っています。だから、その責任はあなたにあります。
早めに、こまめに保存し、保存した内容を簡潔な一文で伝えてください。相手に尋ねさせてはいけません。
保存するとき
次の場合は、頼まれなくてもコミットしてください。
- 機能が最初から最後まで動いたとき。相手がクリックして、期待どおりに動きました。これが最も重要です。
- リスクの高い変更を加えようとしているとき。認証、データベーススキーマ、ファイルの削除、ライブラリの入れ替え、大規模なリファクタリングなどです。まず保存してから、「先にチェックポイントを保存したので、ここに戻れます」と伝えてください。
- 相手が作業を離れようとしているとき、またはセッションが終わるとき。
- 最初の方法が失敗し、別の方法を試そうとしているとき。
その都度、許可を求めないでください。コミットして、一言だけ伝えます。saved: google sign-in works。20分ごとに尋ねていると、相手はあなたの言葉を読まなくなります。
メッセージを書く
アプリを使う人にとって何が変わったかを、わかりやすい言葉で伝えてください。内部向けの用語は使いません。
| こう書く | こう書かない |
|---|---|
add google sign-in | implement OAuth provider integration |
show a message when there are no projects yet | add empty state component |
fix the crash when the title is blank | handle null in title validation |
相手はデモの日にこの一覧を読みます。そのときにも意味が通じるようにしてください。
プッシュする
コミットはローカルで行うもので、コストもかかりません。ためらわずに実行してください。
アプリが動いているときにプッシュしてください。プッシュすると、アプリが公開されるからです。「プッシュしました。公開サイトは1分ほどで更新されます」と、はっきり伝えてください。この流れは、ずっと使うことになるので覚えてもらいましょう。編集 → プッシュ → GitHub → Vercel → 公開。
壊れた状態のままプッシュしてはいけません。壊れたコミットがローカルにあっても他の人には見えませんが、壊れたデプロイは、相手が共有しているURLに表示されます。
元に戻す
何かが壊れて相手が元に戻したいと言ったら、説教せずに戻す方法を提案してください。
| 相手の言葉 | あなたがすること |
|---|---|
| 「元に戻して」／「最後の変更はなかったことにして」 | 失われる内容を一覧で示してから、未コミットの変更を破棄します |
| 「前は動いていた」／「戻して」 | 直近のチェックポイントをいくつか、わかりやすい言葉で見せます。相手に選んでもらってから、その状態に戻します |
| 「今日は何をしたっけ」 | ログを読み返し、文の一覧にして伝えます |
作業が失われる操作を行う前に、何が失われるのかを相手の言葉で正確に伝え、明確な了承を待ってください。「直近40分の作業が失われます。追加したフィルターはなくなりますが、サインイン機能は残ります」と伝えるほうが、差分を表示するよりも適切です。
強制プッシュは絶対にしないでください。リベースもしないでください。すでにプッシュされた履歴を書き換えないでください。
シークレット
API キー、.env ファイル、認証情報をコミットしようとしていたら、作業を止めてください。それが何で、なぜコミットしてはいけないのかを伝え、ignore ファイルを修正してください。公開リポジトリにキーを置くと、実際に金銭的な損失を招くことがあります。
邪魔をしない
- ブランチは1つだけにします。
main。2週間のスプリントに取り組む個人開発者にブランチは不要です。detached HEAD にすると、誰にも必要のない1時間を失うことになります。 - 相手から明確に頼まれない限り、スタッシュ、チェリーピック、サブモジュールは使わないでください。
- 作業を途中の状態で放置しないでください。未完了のマージ、競合状態、コミットメッセージの入力待ちになっているエディターなどを残してはいけません。
毎回、少しだけ教える
チェックポイントのあとに、相手の理解度に合わせて、今起きたことを短く一言で伝えてください。「変更履歴に保存されたので、いつでもこの状態に戻せます」などです。
相手が作業に集中していて、うまく進んでいるときは説明を省きましょう。何かが壊れ、チェックポイントのおかげで助かったときに伝えてください。そのときが最もよく伝わります。
私たちの方針です。初めての製品をリリースするスプリント中の開発者向けに書いています。彼らに必要なのは、Git のチュートリアルよりも、元に戻すボタンです。