commit

コミット

ゲートを検証してから、コミットします。コミットはプルリクエストではなく、プルリクエストはマージではありません。 このスキルはコミット後に停止します。--pr を指定した場合、またはユーザーが依頼した場合にのみプッシュしてプルリクエストを作成し、マージは決して行いません。マージは、ユーザーがそのプルリクエストをマージするよう明示した場合にのみ行われます（下記の「マージ」を参照）。Codex や Copilot などのレビュアーはプルリクエストの作成後にコメントします。レビュアーからの報告前にマージすると、レビューを受けずに済ませることになります。

手順

ステップ 0：品質ゲート（コミット前）

ブランチを作成する前に実行します。 品質ルーブリックがある変更済みの .qmd、.tex、.R ファイルすべてについて、次を実行します。

python3 scripts/quality_score.py <changed-file-paths>

• いずれかのファイルのスコアが 80 未満の場合は、停止して指摘事項を報告します。ユーザーは問題を修正するか、「そのままコミット」や「品質ゲートをスキップ」などの表現で明示的に上書きする必要があります。./scripts/install-hooks.sh の実行後は、.githooks/pre-commit がステージ済みの .qmd／.tex／.R ファイルに対して同じ 80 以上のゲートを再実行します。そのため、承認済みの上書きはステップ 4 に引き継ぎ、SKIP_QUALITY_GATE=1 git commit ... として指定し、上書きの理由をコミットメッセージに記録してください。この変数がスキップするのは品質スコアのみです。バックテストは引き続き実行されます。git commit --no-verify に頼ることは決してしないでください。
• すべてのファイルのスコアが 80 以上の場合は、続行します。

verifier エージェント（Agent ツールで subagent_type=verifier を指定）を起動して、変更済みファイルのコンパイル／レンダリングチェックを実行します。コミット前に合否を報告してください。

ステップ 0b：整合性ゲート（コミット前）

必ず実行します。 10 個すべてのゲートを含むバックテストスイートを実行します（「18 agents, 61 skills, 37 rules, 11 hooks」のような surface-sync の件数主張とマーク付きテーブル、スキルの整合性、モデルの最新性、リンク、仕様への準拠、古さ、リポジトリの衛生状態、派生件数、台帳のカバレッジ、フックのテスト一式）。

./scripts/backtest.sh

• 終了コード 0： すべてのゲートが成功しています。続行します。
• 0 以外： 少なくとも 1 つのゲートが失敗しています。出力を表示して停止します。修正してから再実行してください。「そのままコミット」と指示されても、失敗した状態でこのゲートを通過してはいけません。ゲートの失敗は、次の読者に引き継がれる不整合です。件数のわずかな不整合でも、後続のプルリクエストが何度も必要になっています。

ステップ 0c：パスポートチェック（コミット前）

差分が、quality_reports/passports/ にパスポートがある原稿（.tex／.qmd）、パスポートに記載された source_file、またはクレームが表示として宣言しているファイル（location:、または appears_in の path:）に触れる場合は、そのパスポートを読みます。根拠を支えるクレームの status: FAIL または STALE は必ず修正が必要です。停止してクレーム名を示し、コミット前に /audit-reproducibility（または古くなったスクリプト）を確認するよう案内してください。表示ファイルに変更があった場合も、スクリプトに変更があった場合と同じ理由でチェックが必要です。成果物の 1 つで数値を編集すると、その数値を表示するほかの箇所との不整合が生じます。同じ値を含む補足資料やスライドが、同じコミットで必ず更新されているとは限りません。パスポートがなければ、何もせずにスキップします。

ステップ 1：現在の状態を確認する

git status
git diff --stat
git log --oneline -5

ステップ 2：ブランチを作成する（main 上にいる場合）

main に直接コミットしてはいけません。現在のブランチが main の場合は新しいブランチを作成し、すでに機能ブランチ上にいる場合は、そのブランチでコミットします。

git checkout -b <short-descriptive-branch-name>

ステップ 3：ファイルをステージする

個別のファイルを追加します（git add -A は決して使わないでください）。

git add <file1> <file2> ...

.claude/settings.local.json や秘密情報を含むファイルはステージしないでください。

ステップ 4：内容が伝わるメッセージでコミットする

$ARGUMENTS が指定されている場合は、それをコミットメッセージとして使います。指定されていない場合は、ステージ済みの変更を分析し、単に「何を」ではなく「なぜ」を説明するメッセージを作成します。

サブジェクト行には、コミット後に成立する事実を記載します。読者が実際に確認できる挙動について、平易な文で記述してください。「レビューの指摘を修正」や「チェッカーを更新」は作業経緯を述べるだけで、読者には何も伝わりません。一方、「パリティゲートは、ハッシュが登録されていないフィクスチャを拒否する」は、コードで確認できる主張です。どのレビューラウンドから来たか、誰に依頼されたか、何回試したかといった作業経緯を書く場合は、本文に記載します。本文では引き続き「なぜ」を説明し、サブジェクトでは主張を伝えます。

git commit -m "$(cat <<'EOF'
<commit message here>
EOF
)"

ステップ 5: push してプルリクエストを開く — --pr がある場合、またはユーザーが依頼した場合のみ

--pr がなく、ユーザーがプルリクエストを依頼していない場合は、このステップをスキップします。コミットはローカルにとどまり、レポートにもその旨が記載されます。

git push -u origin <branch-name>
gh pr create --title "<short title>" --body "$(cat <<'EOF'
## Summary
<1-3 bullet points>

## Changed defaults
<"None", or each default a forker will notice changing: a setting, a threshold, a hook that now fires, a path that moved>

## Test plan
<checklist>

🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

ステップ 6: レポート

コミット（ハッシュと件名）、ブランチ、そしてプルリクエストを開いた場合はその URL を報告します。何もマージされていないことをはっきりと伝えます。

マージ — ユーザーがそう言った場合のみ

マージがこのスキルのステップになることは決してありません。マージするのは、ユーザーが特定のプルリクエストのマージを明示的に依頼した場合（「#155 をマージして」）だけです。「ship it」「done」「commit」はマージの指示ではありません。マージする前に、プルリクエストの CI がグリーンであること、およびそのレビュー（人間、Codex、Copilot）を読み、回答済みであることを確認してください。

gh pr merge <pr-number> --merge --delete-branch
git checkout main
git status --porcelain          # must print nothing before the next line runs
git pull

ここでツリーがダーティであることは想定内です — そのためにステップ 3 があります。 特定のファイルをステージングするということは、セッションが触れたがステージングしなかったものすべて、加上び追跡されていないすべての成果物が、このステップに到達した時点でもツリーに残っているということです。このテンプレートが同梱する git-guardrails フックは、git status --porcelain が空でない場合は常に git pull（および merge、rebase）を拒否します。なぜなら、コミットされていない作業の上に解決される pull は後からレビューできないからです — どのハンクがリモート由来だったのか、もはや判別できません。stash を同じコマンドラインにつなげても助けにはなりません。フックはツリーを読み取るのであって、その行がツリーに対して何をするかを予測するわけではありません。

ツリーを意図的にクリアしてから、pull します:

git stash push -u -m "post-merge: unstaged leftovers"   # -u, or untracked files stay behind
git pull
git stash pop

git pull --autostash は 1 コマンドの代替手段ですが、ダーティな状態が完全に追跡済みのツリーでのみ使えます。git stash は追跡されていないファイルを stash しないため、?? エントリの上で autostash すると、チェックが拒否するために存在するのと同じダーティなツリーで pull が始まります — したがってフックは porcelain を読み取り、?? エントリが 1 つでもある場合は --autostash を拒否します。このステップではそれが通常の状態なので、上記の明示的な -u 付き stash がデフォルトの経路であり、--autostash は git status --porcelain に ?? 行がまったく表示されない場合のショートカットです。Git も独立して同じ見解です。取り込まれるコミットが、追跡されていない状態で保持しているパスにファイルを追加する場合、autostash がすでに取得された後にマージを中止します（「untracked working tree files would be overwritten」）。どちらの経路も単独のコマンドでなければなりません — stash と pull を 1 行につなげることは完全に拒否されます。識別された履歴操作がツリーの読み取りに到達するのは、単独の単純なコマンドとしてのみだからです。

ALLOW_DIRTY_MERGE=1 は、自分で確認し、声に出して正当化できるダーティな状態のための抜け道です。これは日常的な対処法ではなく、ブロックが不便だからといってこれに手を伸ばすことは、このチェックが防ぐために存在する行為です。

重要

• ステップ 0 を決してスキップしないでください。 品質ゲートは、壊れたコンパイル、不正な引用、ハードコードされたパスが main に到達する前に捕捉します。ユーザーがスキップを主張する場合は、その override の理由をコミットメッセージに記録してください。
• main に直接コミットしないでください。まずそこからブランチを切ってください。
• 依頼されない限り、push、プルリクエストの作成、マージをしないでください — ステップ 5 と「マージ」を参照してください。
• settings.local.json および機密ファイルはステージングから除外してください。
• ユーザーが実際にマージを依頼した場合は、別段の指示がない限り --merge（--squash や --rebase ではない）を使用してください。
• $ARGUMENTS からのコミットメッセージが提供されている場合は、それを正確に使用してください。

フラグ

フラグ	効果
--pr	コミット後にブランチを push し、プルリクエストを開きます（ステップ 5）。マージは決して行いません。