commit

Smart Commit

ホストに依存しないワークフローです。スキル名（commit）で呼び出します。Claude Code のスラッシュルーティング、YAML フックローダー、.claude/chain については references/claude-code.md を参照してください。

シンプルで検証済みのコミットを作成します。標準的なコミットでは、ローカルでチェックを実行し、エージェントは必要ありません。

注記： disableSkillShellExecution が有効な場合（CC 2.1.91）、git リポジトリのチェックは実行されません。このスキルには git リポジトリが必要です。

クイックスタート

commit
commit fix typo in auth module

引数の解決

COMMIT_MSG = "$ARGUMENTS"  # Optional commit message, e.g., "fix typo in auth module"
# If provided, use as commit message. If empty, generate from staged changes.
# $ARGUMENTS[0] is the first token (CC 2.1.59 indexed access)

STEP 0：コミットモードを選択する（AskUserQuestion — M118 #1465）

デフォルトは「新規コミット」ですが、音声フローでは、amend／push／stash が必要な場合に明示的な選択が必要です。

# Skip when a flag in the invocation makes the mode unambiguous:
#   commit --amend  → skip, mode=amend
#   commit --push   → skip, mode=new+push
#   commit --stash  → skip, mode=stash-first
#   ORK_COMMIT_DEFAULT_MODE=new (or amend|push|stash) → skip, use env value
#
# Otherwise, ask:
AskUserQuestion(questions=[{
  "question": "How should this commit land?",
  "header": "Commit mode",
  "options": [
    {"label": "New commit (default)", "description": "Create a new commit, leave HEAD intact"},
    {"label": "Amend HEAD", "description": "Fold staged changes into the last commit (LOCAL ONLY — refuses if HEAD is published)"},
    {"label": "New commit + push", "description": "Commit then `git push` (refuses on protected branches)"},
    {"label": "Stash first", "description": "Stash unrelated working-tree changes, then commit only what was already staged"}
  ]
}])

モード固有のガード：

• HEAD を amend — HEAD が origin にないこと（git rev-list HEAD..origin/<branch> が空であること）を確認します。公開済みの場合は拒否し、代わりに「新規コミット」を推奨します。
• 新規コミット + push — push の前に、フェーズ 1 の保護ブランチルールを再確認します。HEAD のブランチが main／master／dev の場合は中止します。
• 先に stash — git stash push -k -m "ork:commit autostash"（インデックスを保持）を実行し、コミットした後、push が成功したら git stash pop を実行します。

ワークフロー

フェーズ 0：操作対象のリポジトリがあることを確認する

ガードを実行する前に、git rev-parse --is-inside-work-tree を実行します。失敗した場合、またはこのセッションで Bash ツールを利用できない場合は、その旨を 1 文で伝え、コミットメッセージのテキストのみを作成します。フェーズ 1〜3 はすべてスキップします。

確認していないブランチガード、検証ステータス、その他のリポジトリに関する事実を決して出力しないでください。2026-09-12 に claude plugin eval で計測したところ、リポジトリも Bash もないサンドボックスで、このスキルはブランチが main で保護されていると主張する「pre-commit guard」ボックスを表示しました。何も確認されていませんでした。「ブランチや lint の状態を確認できませんでした」と伝えるメッセージのみの回答が正しく、作り上げたガードは欠陥です。

フェーズ 1：コミット前の安全性チェック

# CRITICAL: Verify we're not on dev/main
BRANCH=$(git branch --show-current)
if [[ "$BRANCH" == "dev" || "$BRANCH" == "main" || "$BRANCH" == "master" ]]; then
  echo "STOP! Cannot commit directly to $BRANCH"
  echo "Create a feature branch: git checkout -b issue/<number>-<description>"
  exit 1
fi

フェーズ 2：ローカルで検証を実行する

CI で実行されるすべてのチェックを実行します。

# Backend (Python)
poetry run ruff format --check app/
poetry run ruff check app/
poetry run mypy app/

# Frontend (Node.js)
npm run format:check
npm run lint
npm run typecheck

続行する前に、失敗したチェックを修正してください。

フェーズ 3：変更をレビューする

git status
git diff --staged   # What will be committed
git diff            # Unstaged changes

フェーズ 3b：エージェントの帰属情報（自動）

コミットの前に、ブランチのアクティビティ台帳 .claude/agents/activity/{branch}.jsonl があるか確認します。存在し、前回のコミット以降のエントリがある場合は、コミットメッセージに含めます。

1. .claude/agents/activity/{branch}.jsonl を読み込みます（1 行につき JSON オブジェクト 1 つ）。
2. 最後のコミット日時（git log -1 --format=%cI）より後の ts を持つエントリに絞り込みます。
3. duration_ms < 5000 のエージェントはスキップします（助言のみのエージェントはコミットではなく PR に記載します）。
4. コミット本文と Co-Authored-By トレーラーの間に 「Agents Involved:」 セクションを追加します。
5. エージェントごとに Co-Authored-By トレーラーを追加します：Co-Authored-By: ork:{agent} <[email protected]>

台帳が存在しない、または空の場合は、この手順をスキップして通常どおりコミットします。

フェーズ 4：ステージングしてコミットする

CC 2.1.113 のイディオム： 先頭に # intent: コメントを付けた複数行の Bash は、全コマンドがトランスクリプトに表示されるようになりました。複雑なスクリプトには 1 行の意図コメントを付けてください。これにより、後から読む人（および /recap のスキャン）が差分を読み直さずに、何が行われたかトランスクリプトを grep で検索できます。

# intent: stage the hook change + its test + built artifacts
# Stage files
git add <files>
# Or all: git add .

# Commit with conventional format (with agent attribution if ledger exists)
git commit -m "<type>(#<issue>): <brief description>

- [Change 1]
- [Change 2]

Agents Involved:
  backend-system-architect — API design + data models (2m14s)
  security-auditor — Dependency audit (0m42s)

Co-Authored-By: Claude <[email protected]>
Co-Authored-By: ork:backend-system-architect <[email protected]>
Co-Authored-By: ork:security-auditor <[email protected]>"

# Verify
git log -1 --stat

CC 2.1.183 — attribution.sessionUrl： Web セッションと Remote Control セッションでは、CC がコミット／PR の帰属情報に claude.ai のセッションリンクを追加します。これを省略するには attribution.sessionUrl: false（/config attribution.sessionUrl=false）を設定します。セッションリンクを公開リポジトリに漏らしたくない場合に便利です。上記の Co-Authored-By トレーラーには影響しません。

ハンドオフファイル

コミットが成功したら、ハンドオフを書き込みます。

Write(".claude/chain/committed.json", JSON.stringify({
  "phase": "commit", "sha": "<commit-sha>",
  "message": "<commit-message>", "branch": "<branch>",
  "files": [<staged-files>]
}))

コミットの種類

種類	用途
feat	新機能
fix	バグ修正
refactor	コードの改善
docs	ドキュメント
test	テストのみ
chore	ビルド／依存関係／CI

クイックルール

1. 検証はローカルで実行する - lint/test の実行をエージェントに依頼しないでください
2. ファイルを作成しない - MD ファイルやドキュメントを作成しないでください
3. 1 コミットにつき論理的な変更は 1 つ - コミットの対象を絞ってください
4. イシューを参照する - コミットメッセージでは #123 形式を使用してください
5. 件名は 72 文字未満 - 簡潔にしてください

クイックコミット

軽微な変更（誤字、1 行の修正）の場合：

git add . && git commit -m "fix(#123): Fix typo in error message

Co-Authored-By: Claude <[email protected]>"

検証ゲート

コミットする前に、5 ステップのゲートを適用してください：Read("../../shared/rules/verification-gate.md")。テストを新たに実行してください。出力を確認してください。テストに合格した場合のみコミットしてください。「問題ないはず」は根拠になりません。

品質基準

次のすべてを満たせば完了です：

• コミットがフィーチャーブランチにあり、dev/main/master にはない（フェーズ 1 のガードが機能している）
• 件名に差分の内容に合った従来型のタイプ（feat/fix/docs/refactor/test/chore）を使用し、72 文字以内である
• HEAD がイシューブランチにある場合、メッセージにイシュー参照（#N）が含まれている
• 変更対象のスタックに対するローカル検証（lint/type/test）をコミット前に実行し、合格している
• Co-Authored-By: Claude のトレーラーがあり、エージェントごとのトレーラーは、アクティビティ台帳に前回のコミット以降のエントリーがある場合にのみ追加されている
• git log -1 --stat に意図したファイルのみが表示され、シークレットがなく、生成物だけの不要なコミットもない

関連スキル

• ork:create-pr：コミットからプルリクエストを作成する
• ork:review-pr：コミット前に変更をレビューする
• ork:fix-issue：イシューを修正し、修正をコミットする
• ork:issue-progress-tracking：コミットの進捗で GitHub イシューを自動更新する

ルール

各カテゴリには、必要に応じて読み込まれる個別のルールファイルが rules/ にあります：

カテゴリ	ルール	影響度	主なパターン
アトミックコミット	rules/atomic-commit.md	CRITICAL	1 コミットにつき論理的な変更は 1 つ、アトミック性のテスト
ブランチ保護	rules/branch-protection.md	CRITICAL	保護されたブランチ、必須の PR ワークフロー
コミットの分割	rules/commit-splitting.md	HIGH	git add -p、対話的なステージング、分離の戦略
従来型フォーマット	rules/conventional-format.md	HIGH	type(scope): description、破壊的変更
履歴の整理	rules/history-hygiene.md	HIGH	WIP のスカッシュ、fixup コミット、クリーンな履歴
イシュー参照	rules/issue-reference-required.md	HIGH	イシューブランチ上のコミットでイシュー #N を参照
マージ戦略	rules/merge-strategy.md	HIGH	リベース優先、競合解決、force-with-lease
積み重ねた PR	rules/stacked-pr-workflow.md	HIGH	スタック計画、PR 作成、依存関係の追跡
積み重ねた PR	rules/stacked-pr-rebase.md	HIGH	リベース管理、force-with-lease、ターゲット変更

全 8 カテゴリに 9 つのルール

参考資料

Read("references/<file>") で必要に応じて読み込みます：

ファイル	内容
references/conventional-commits.md	従来型コミットの仕様
references/recovery.md	復旧手順