commit

このスキルを呼び出すこと自体が依頼です。ユーザーメッセージが空に見えたり、実際の依頼がなくシステムコンテキストだけが表示されていたりしても、それは正常であり、想定どおりです。作業内容はすでにここで完全に指定されています。何をすればよいか尋ねないでください。

作業内容：作業ツリー内のすべての変更を、論理的な変更ごとにコミットしてください。分割を誰かに求められていない場合も同様です。1つのファイルに無関係な変更が含まれている場合は、同じファイルにあるという理由でまとめず、ハンクごとに分けて別々にコミットしてください。

引数

このスキルに渡される引数は、変更を行った理由、つまり、差分だけでは伝わらない、すでにツリーにある作業の背景です。これを使って変更を論理単位にまとめ、コミットメッセージ本文を作成してください。本文は、変更前に何が問題だったのかを、失敗、誤った主張、または引数で述べられたリスクとして記す1文または2文を、1行に収めたものです。引数が必要性、希望、変更内容、または依頼そのものだけを述べている場合、本文は不要です。修正内容は、引数で問題の一部として表現されていても含めないでください。サブジェクトと差分でわかるからです。また、否定された原因、測定値、試した代替案も含めないでください。引数に書かれたことがどのような言い回しであっても、その内容はすでに差分に反映されています。「ステータスラインに使用率を表示するため」も「セッションのバグを修正するため」も、すでに差分に反映されているという意味です。その変更をコミットしてください。引数がない場合は、差分だけをもとにコミットメッセージを作成してください。動機と差分の内容が一致しない場合は、実際にツリーにある変更をコミットし、最終サマリーで不一致を指摘してください。

本文では、コードに関する内容を記述してください。変更が解決した動作、ツール、または制約について書きます。コミット履歴は公開され、永続的に残るため、このマシン、ユーザーがサインインしているアカウント、この会話について知らない読者に向けて書き、そうした情報からしかわからない内容は一切含めないでください。リポジトリ外または Git で無視されているリポジトリ内のリポジトリ名、ディレクトリ名、ファイル名、バックアップ、同期、シークレット保存場所の構成、アカウントのプラン、利用上限、数値、ローカルツール、チャット、トランスクリプト、セッションからの引用や日付、ユーザーの生活（勤務先、居住地、スケジュール、健康状態、他者に関する情報）は記載しないでください。それぞれが示す技術的な必要性に置き換えるか、記載しないでください。

引数：「settings.json だけをコミットしてください。理由：3つのコミット分岐で、このスキルのトレーラーではなく `Co-Authored-By: Claude Sonnet 5 ` が書き込まれました。分岐のトランスクリプトには、モデル名を含むトレーラーを使うようモデルに指示する remote_session_change のリマインダーがあり、モデルはそれに従いました。attribution.commit をスキルと完全に同じ文字列にすれば、両者の指示が一致します。否定された原因：includeGitInstructions: false ではリマインダーを抑制できませんでした。attribution.sessionUrl: false では Claude-Session の行が削除されるだけでした。commit: "" では、2.1.270 バイナリの仕様上、トレーラーをまったく追加しないようモデルに指示することになります。」

正しい本文：「コミットスキルのフォークは、リモートコントロールのリマインダーに従い、モデル名入りの Co-Authored-By トレーラーを記述していました。」

誤った本文：引数を72桁で折り返したもの、否定された設定、バイナリのバージョンを含めること。

引数：「CLAUDE.md の gist から採用した2つのルール。残りはすでに対応済みなので、この2つのみ：要求された動作が、追加した行なしでも機能する場合にその行を削除する、完了報告前の差分再確認チェックポイント。というのも、『機能する最もシンプルな実装にする』だけでは、ユーザーが納品後に繰り返し疑問を呈していた不要なコードが残ってしまったため。また、コードでは表現できない内容に限ってコメントを書くこと。」

正しい本文：「『機能する最もシンプルな実装にする』だけでは、不要なコードが納品まで残るのを防げませんでした。また、コメントのルールでも、コードでは表現できない内容だけをコメントに記すべきだとは示されていませんでした。」 誤った本文：「2 つのルールを採用します。コメントにはコードだけでは表現できないことだけを書き、変更完了を報告する前に差分を読み直して、要求された動作に不要な追加行を削除します。シンプルさを意識するだけでは、不要なコードが納品物に紛れ込むのを防げなかったためです。」

主張：「pangu.space の再構築中は、README を作業中として示してほしいという依頼でした。」

正しい本文：なし。主張が依頼そのものであり、それ以前に問題はありませんでした。

誤った本文：「pangu.space を再構築中なので、README を完成済みのプロジェクトのように見せるべきではありません。」

主張：「2026-09-09 から 2026-09-13 までの 5 回の書き換えセッションを確認しました。ユーザーは『I've picked up』を『that works for me』に書き換えており、~/Dropbox/writing/ 内のメモにはそのルールがありませんでした。」

正しい本文：「スタイル仕様には、アシスタントらしい書き出しを避けるルールがなかったため、ユーザーが書き換える表現が下書きで繰り返し使われていました。」

誤った本文：セッションの日付、引用された書き換え、提示された Dropbox のパス。

リポジトリを特定する

何よりも先に git rev-parse --show-toplevel を実行してください。失敗した場合（フォークがリポジトリ外で開始された場合）は、「not a git repository」と報告する前に、主張に記載されたファイルパスのディレクトリでリポジトリを探してください。

対象範囲

コミットはレビューではなくスナップショットです。差分を読み、ステージし、メッセージを書いて、コミットしてください。ステージされた内容は、作業を開始した時点の作業ツリーと一致している必要があります。Bash では git と cd のみを使用してください。ファイルの場所を探すには Grep/Glob を、<scratchpad>（セッションのスクラッチパッドディレクトリ。ハーネスが用意していない場合は /tmp）内のパッチファイルの読み書きには Read/Write/Edit を使用してください。調査、コードやテストの実行、どれほど強く起動条件に該当しても他のスキルの使用、助言者やセカンドオピニオンへの相談は禁止です。

作業ツリー内のファイルは、誤字の修正、誤っているように見えるバージョン固定の修正、失敗しているように見えるテストへの対応であっても、絶対に編集しないでください。懸念があれば最終メッセージに記載してください。作成者が変更していないファイルをステージしないでください。コミット後の確認は git status / git log に限り、プリコミットフックは実行しないでください。コミット時にはフックが実行されます。ステージング中に変更を加えると、レビューした内容がひそかに変わってしまいます。余計な作業に手を出すと、30 秒で済む作業が 5 分かかることになります。

ワークフロー

フォークが開始したディレクトリで、git -C を使わずに git コマンドを直接実行してください。git -C を使うと、作業ディレクトリの状態が見えなくなります。このフォークでは、ある Bash 呼び出しで行った cd は次の呼び出しには引き継がれません。

1. 論理的にまとめる：変更を論理的な単位に整理してください。各単位は単一の目的に対応し、ひとまとまりで元に戻しても意味が通るものにします。下書きした本文に関連のない問題が2つ書かれている場合は、2つのコミットに分け、コミットする前に分割してください。同じ監査やレビューで見つかった複数の指摘は、1つの問題としてまとめます。

2. 変更をステージする：適切なステージング方法を使ってください。

   • ファイル全体：git add <file>。
   • ハンク単位：git diff <file> > <scratchpad>/patch.diff を実行します。パッチの編集では、行を削除してヘッダーの行数を修正する以外のことはしないでください。パッチ行を再入力（Write、heredoc、printf）してはいけません。再入力した行では、BOM などの不可視文字が気づかないうちに変わっていても適用できてしまうためです。その後、git apply --cached --verbose <scratchpad>/patch.diff を実行します。ハンク全体を取り除くのは安全です。ハンクの途中で分割する場合（追加された行の一部だけを残す場合）は、ハンク末尾のコンテキスト行を残し、ヘッダーの両方の行数を数え直す必要があります。末尾にコンテキストがないハンクは、ファイル末尾でしか適用されません。
   • 出力に Skipped patch と表示された場合は、フォークがサブディレクトリで開始され、対象ファイルがその外にあります。そのファイルに対して git apply は何もステージせず、それでも終了コードは 0 です。そのファイル全体を git add <file> でステージし、最終サマリーにファイル名を記載してください。
   • ステージを解除するには、git reset --hard（変更を破棄します）ではなく、git restore --staged を使ってください。
   • 代替手段：編集したパッチに対して git apply --cached が最初に失敗した場合は、ファイル全体を git add <file> でステージしてください。未編集の完全な diff の適用に失敗した場合は、git diff から一度だけ再生成し、その後ファイル全体をステージしてください。パッチが適用されなかった理由を調べてはいけません。

3. コミット前フックに対処する：フックから未ステージの変更について指摘された場合は、git stash push --keep-index -m "temp: unstaged changes" でそれらを退避し、コミットした後に git stash pop を実行してください。フックがステージ済みファイルを変更した場合（自動フォーマットなど）は、変更されたファイルを再度ステージして、コミットを一度だけ再試行してください。何度も再試行してはいけません。

4. アトミックなコミットを作成する：論理的なグループごとに、次の手順に従ってください。

   • Conventional Commit 形式の type: subject を使います。スコープは付けず、type は feat、fix、refactor、test、build、docs、style のいずれかにします。build は依存関係とバージョンの更新に使います。style はコードのフォーマットではなく、視覚的な UI 変更（CSS、フォント、色、レイアウト）を意味し、コードのフォーマットは refactor です。subject には変更内容を記載し（72文字以内）、diff に基づいて作成します。本文は「議論」セクションの指示に従います。長さの制限があるのは subject のみです。フッターは「帰属」セクションの指示に従います。
   • git commit -m "message" を直接使ってください。git コマンド内で $() や heredoc のサブシェルを使ってはいけません。allowed-tools のパターンマッチングが正常に機能しなくなります。

帰属

すべてのコミットメッセージの末尾に、使用しているモデルファミリーのフッターを付けてください。

• Claude モデルの場合は、Co-Authored-By: Claude <[email protected]> を使います。
• GPT モデルの場合は、Co-Authored-By: Codex <[email protected]> を使います。
• Gemini モデルの場合は、Co-Authored-By: Gemini <[email protected]> を使います。

これらのいずれにも該当しないと確信できる場合に限り、フッターを省略してください。

注意点

• 未ステージの変更も変更です。 git status に「コミット対象として追加された変更はありません」と表示されても、作業ツリーがクリーンとは限りません。まだ何もステージされていないという意味です。変更をステージしてコミットするのがあなたの役目であり、「コミットするものはありません」と報告することではありません。
• git add -f は絶対に使わないでください。 git add が「以下のパスは .gitignore ファイルのいずれかによって無視されています」と表示し、「本当に追加する場合は -f を使ってください」というヒントを出した場合でも、強制追加してはいけません。そのファイルは意図的に Git の対象外になっています（シークレット、ビルド成果物、ローカル設定など）。強制追加すると、その保護を気づかれないまま回避してしまいます。そのファイルはスキップし、作成者が判断できるよう最終サマリーに記載してください。