git-commit

Git Commit スキル

概要

作業ツリーの変更を Conventional Commits 1.0.0 の単位（論理単位ごとに 1 つのコミット）にまとめるか、最近の規約に準拠していないコミットの件名をその場で書き換えます。

基本原則： ユーザーの意図に合ったワークフロー（新しいコミットの作成か、履歴の書き換えか）を選びます。ユーザーが明示的に許可しない限り（例：/git-commit-rewrite の force キーワード）、破壊的なフラグで安全策を回避してはいけません。

開始時に伝える：「変更を <commit / push / rewrite> するため、git-commit スキルを使用します。」

コマンド

コマンド	スキル	アクション	対象
/git-commit	git-commit	作業ツリーの変更を Conventional Commits にまとめる	未コミットの変更（ステージ済み＋未ステージ）
/git-commit-push	git-commit-push	上記と同じ処理を行い、その後 git push を実行する（--force は使用しない）	未コミットの変更＋リモート
/git-commit-rewrite	git-commit-rewrite	最近の規約に準拠していないコミットの件名を書き換える	既存のローカル履歴

適切なコマンドの選択

作業を始める前に、次の確認を実行してください。

git status --short        # Are there working-tree changes?
git log --oneline -10     # Are recent messages already Conventional?

状況	コマンド
作業ツリーに変更があり、履歴に問題がない	/git-commit
作業ツリーに変更があり、プッシュもしたい	/git-commit-push
作業ツリーがクリーンで、最近の履歴に問題がある（「Added X」、「WIP」、「Fixed bug」など）	/git-commit-rewrite
両方に該当する：作業ツリーに変更があり、履歴にも問題がある	まずコミットし（/git-commit）、その後で別途 /git-commit-rewrite を実行する

自動振り分け： ユーザーが引数なしで /git-commit を実行したものの、作業ツリーがクリーンな場合は、最近の履歴を確認します。最近のコミットが規約に準拠していなければ、そのことを伝えて次のように尋ねます：「コミットする作業ツリーの変更がありません。最近の履歴に規約に準拠していない件名が N 件あります。/git-commit-rewrite で書き換えますか？」

Conventional Commits の形式

<type>[optional scope][!]: <description>

[optional body]

[optional footer(s)]

使用できるタイプ

タイプ	意味
feat	新機能（MINOR semver のバージョンアップ）
fix	バグ修正（PATCH semver のバージョンアップ）
docs	ドキュメントのみの変更
style	書式や空白の変更。ロジックの変更なし
refactor	バグ修正でも機能追加でもないコード変更
perf	パフォーマンスの改善
test	テストの追加または修正
build	ビルドシステムまたは外部依存関係
ci	CI 設定ファイルおよびスクリプト
chore	src またはテストを変更しないその他の変更
revert	以前のコミットを取り消す

破壊的変更 — タイプやスコープの後に ! を付ける（例：feat(api)!: drop v1 endpoints）。または BREAKING CHANGE: ... フッターを含めます。

件名のルール

• 命令形にする：「added」や「adds」ではなく「add」
• 説明の最初の単語は小文字にする
• 末尾にピリオドを付けない
• 件名は 72 文字以内を目安にする
• スコープは任意ですが、明確なモジュールや領域を対象とする場合は付けることを推奨します

例

feat(parser): add ability to parse arrays
fix(ui): correct button alignment
docs: update README with usage instructions
refactor(auth): extract token validation
chore: update dependencies
feat!: send email on registration

BREAKING CHANGE: email service is now required at boot

ワークフロー：/git-commit（既定）

手順 1：作業ツリーを確認する

git status --short
git diff
git diff --cached

変更がない場合 → ユーザーに伝え、自動振り分けの確認（上記）を実行して終了します。

ステップ 2：変更を論理的な単位にまとめる

変更された各ファイルの差分を読み、意図ごとにグループ化します。各グループは 1 つの Conventional Commit に対応します。既存のステージング状態は無視してください。ステージ済みと未ステージの変更を統合し、最初からグループ化し直します。

グループ化のルール：

• feat と fix は分けます。決してまとめないでください
• docs はコード変更と分けます（同じ変更に含まれる docstring は除きます）
• 新機能や修正のテストは、そのコミットに含めるか、無関係であれば単独のコミットにできます
• build／ci／依存関係の更新は機能開発と分けます
• refactor は feat と分けます
• 無関係なモジュールに対する修正は、モジュールごとにコミットを分けます
• 機能ファイル内の些細な空白変更は、機能のコミットに含めてもかまいません

細かく分けすぎないでください（機能に伴う 1 行だけの些細な整理はまとめてもかまいません）。また、まとめすぎないでください（feat と fix は別々のコミットにします）。

シークレットの確認 — 次のいずれかに該当するものを検出し、ユーザーが明示的に許可しない限り、デフォルトでは除外してください：.env*、credentials.*、*_rsa、*.pem、*.key、*.p12、パスに secret という語を含むファイル。正確なベース名が .env.example のファイルは、.env* に一致するという理由だけでは検出しないでください。これは公開テンプレートです。それ以外のシークレットに関するルールは引き続き適用されます。機密性の高い親ディレクトリや、ほかの一致するファイル名パターンも対象です。シークレットの疑いが残るファイルについては、ユーザーに警告してください。コミットすべきではありません。

ステップ 3：コミット計画を提示する

コミットを作成する前に計画を表示し、ユーザーが異議を申し立てられるようにします：

Plan: 3 commits

1. feat(auth): add OAuth login flow
   - src/auth/oauth.ts
   - src/auth/index.ts

2. fix(api): handle null response in user fetch
   - src/api/users.ts

3. docs: update README with auth setup
   - README.md

ステップ 4：コミットを 1 つずつ作成する

計画の順に、各単位について：

git add path/one path/two   # explicit paths only
git commit -m "$(cat <<'EOF'
type(scope): description

optional body explaining the why
EOF
)"

ルール：

• 決して git add . や git add -A を使わないでください。必ずパスを明示してください
• 決して --no-verify、--no-gpg-sign、--amend を使わないでください（ユーザーが明示的に依頼した場合を除きます）
• 依頼がない限り、絵文字や Co-Authored-By: Claude を追加しないでください
• 複数行のメッセージでは、引用符を正しく扱えるよう HEREDOC を使ってください
• 各コミットの後に git status --short を実行し、意図したファイルだけが移動したことを確認してください

pre-commit フックが失敗した場合は、--no-verify を付けて再試行しないでください。原因を調査して根本的な問題を修正するか（または報告し）、新しいコミットを作成してください。

ステップ 5：最終サマリー

git log --oneline -<N>

（N は作成したコミット数です）を作成し、ユーザーに表示します。

実行例

User: 변경사항 의미 단위로 커밋해줘

git status --short →
 M src/auth/oauth.ts
 M src/auth/index.ts
 M src/api/users.ts
 M README.md
?? src/api/.env

→ Detect .env (secret) — exclude, warn
→ Group:
   1. feat(auth): add OAuth login flow  (oauth.ts, auth/index.ts)
   2. fix(api): handle null response in user fetch  (users.ts)
   3. docs: update README with auth setup  (README.md)
→ Show plan, wait for confirmation
→ For each: git add <paths> && git commit -m "..."
→ git log --oneline -3

ワークフロー：/git-commit-push

デフォルトのワークフローを実行します。各コミットが成功するたびに：

git push

現在のブランチにアップストリームが設定されていない場合：

git push -u origin "$(git branch --show-current)"

決して --force や --force-with-lease を使わないでください。プッシュが拒否された場合（fast-forward でない場合）は停止して報告し、自動で解決しないでください。何らかの理由でプッシュに失敗した場合は、エラーを提示し、ユーザーの判断を仰いでください。

実行例

User: /git-commit-push

(Same workflow as default, then:)
→ git push
   error: failed to push some refs (non-fast-forward)
→ STOP. Report:
   "Push rejected: branch is behind origin. Run `git pull --rebase`
    first, then re-push manually. I will not auto-resolve."

ワークフロー：/git-commit-rewrite

直近の履歴にある Conformant ではないコミットメッセージを書き換えます。これは破壊的な操作です。コミット SHA が変更されます。デフォルトのポリシーでは、リモートにすでに存在するコミットには手を加えません。

Force モード（force キーワード）

呼び出しに単独のトークン force または --force（大文字と小文字を区別しません）が含まれている場合（例：/git-commit-rewrite force、「これらのコミットを force rewrite して」、「force로 다시 써줘」）、Force モードで実行します。このキーワードは、破壊的なインプレース書き換えに対する明示的かつ事前に与えられた同意です。そのため、すべての対話型ゲートをスキップして、直ちに適用します。（トリガーとなるのは英語のトークン force／--force です。韓国語の「강제로」だけではトリガーされません。）

• 安全性チェック A と B をスキップ（作業ツリーの変更／detached HEAD） — 事前に処理を停止しないでください。Git は引き続き独自のルールを適用します。git filter-branch は実際に変更がある作業ツリーを拒否します（「Cannot rewrite branches: You have unstaged changes」）。git でエラーが発生した場合は、回避策を講じず、そのまま表示してください。
• ステップ 2 のプッシュ済みコミットのメニューをスキップ — コミットがすでにリモートに存在していても、インプレース書き換えを自動選択します。確認を求めないでください。
• ステップ 5 の待機をスキップ — 透明性を保つため、以前の内容 → 新しい内容の計画は表示したうえで、待たずに直ちに適用します。
• プッシュ： 書き換え後、書き換えられたコミットがリモートに存在していた場合は、最後に git push --force（引数なし）を実行します。引数なしの --force が許可されるのはここだけであり、ユーザーがこのキーワードでオプトインした場合に限ります。何もプッシュされていなかった場合、書き換えはローカルにとどめ、プッシュしないでください。
• クリーンアップは変更なし — refs/original/ のバックアップ参照を保持し、その旨を報告します（ステップ 8）。

force キーワードがない場合は、以下の慎重なワークフロー全体に従ってください。

ステップ 1：書き換え範囲を決定する

デフォルトのベース：

upstream=$(git rev-parse --abbrev-ref --symbolic-full-name '@{u}' 2>/dev/null || true)
if [ -n "$upstream" ]; then
  base=$(git merge-base HEAD "$upstream")
elif git rev-parse --verify main >/dev/null 2>&1; then
  base=$(git merge-base HEAD main)
elif git rev-parse --verify master >/dev/null 2>&1; then
  base=$(git merge-base HEAD master)
else
  echo "Could not determine a base. Ask the user for an explicit range." >&2
  exit 1
fi

ユーザーが件数を指定した場合（例：「直近 5 件を書き換えて」）、代わりに HEAD~5 をベースとして使用します。--root は使用しないでください。

ステップ 2：安全性チェック

Force モードでは、このステップ全体をスキップします（上記の「Force モード」を参照）。ステップ 3 に進んでください。

インプレースで書き換える前に、次の 3 つのチェックに合格する必要があります。

チェック A — 作業ツリーがクリーン：

[ -z "$(git status --porcelain)" ]

失敗した場合 → まずコミットまたは stash するようユーザーに伝え、停止します。

チェック B — HEAD がブランチに接続されている：

git symbolic-ref -q HEAD >/dev/null

失敗した場合 → ブランチを checkout するようユーザーに伝え、停止します。

チェック C — 範囲内のコミットがリモートに存在しない：

for sha in $(git rev-list "$base..HEAD"); do
  if [ -n "$(git branch -r --contains "$sha")" ]; then
    pushed_commits+=("$sha")
  fi
done

pushed_commits が空でない場合：黙って拒否しないでください。 次のメニューをユーザーに表示します。

Found N commits in <base>..HEAD whose subjects are non-Conformant.
M of them are already pushed to a remote:

  abc1234  origin/main  "Added User-Agent Parser"
  def5678  origin/main  "Fixed bug"
  ...

Rewriting published history breaks pulls for collaborators. Options:

  1. Cancel — keep history as-is
  2. Rewrite locally + force-push (destructive; coordinate with team first)
  3. Cherry-pick onto a NEW branch with rewritten messages (safe; original branch untouched)

Which option? (default: 1)

• オプション 1 → 正常終了
• オプション 2 → 続行する前に「yes force push」のような明示的なフレーズを要求します。書き換え後、git push --force-with-lease を実行します（--force は絶対に使用しないでください）。
• オプション 3 → 下記の「ブランチベースの書き換え」を参照してください。

ステップ 3：規約に準拠していないコミットを特定する

<base>..HEAD の各コミットについて、件名が次に一致するか確認します。

^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\([^)]+\))?!?: .+

すでに一致しているコミットはスキップします。マージコミットもスキップします（git rev-list --no-merges を使用）。

ステップ 4：新しいメッセージを生成する

規約に準拠していない各コミットについて：

1. 確認：git show --stat <sha> と、必要に応じて diff の本文
2. 変更内容に基づき、上記の表から type を選択
3. 任意の scope（モジュール／ファイル領域）を選択 — 判断に迷う場合は省略
4. 新しい件名を作成：命令形、小文字、72 文字以内、末尾にピリオドを付けない
5. 元のコミット本文をそのまま保持してください。 書き換えるのは件名の行だけです。元の本文が空の場合は、空のままにしてください。

一般的な翻訳例については、下記の「一般的な規約不適合パターンの対応付け」セクションを参照してください。

ステップ 5：変更前 → 変更後の計画を表示する

Rewrite plan: 3 commits

abc1234  added login feature
       → feat(auth): add login feature

def5678  Fixed bug
       → fix(api): handle null response in user fetch

ghi9012  WIP
       → chore: work-in-progress checkpoint

適用する前に、明示的な確認を待ちます。（Force モードではこの計画を表示しますが、待たずに直ちに適用します。）

Step 6: 書き換えを適用する（インプレース）

マッピングファイルを /tmp/cc-rewrite-map.tsv に作成します。規約に準拠していないコミットごとに 1 行記述します。

<full-40-char-sha>\t<new full message including preserved body>

新しい完全なメッセージは <new subject>\n\n<original body>（本文がない場合は <new subject> のみ）です。メッセージ内の改行は TSV では \n としてエスケープします。rewrite_msg.py がエスケープを解除します。

次を実行します（スクリプトには絶対パスを使用してください）。

script="$HOME/.claude/skills/git-commit/scripts/rewrite_msg.py"
# Plugin install path may differ; resolve via:
#   script=$(find ~/.claude -name rewrite_msg.py -path '*git-commit*' | head -1)
FILTER_BRANCH_SQUELCH_WARNING=1 git filter-branch -f \
  --msg-filter "python3 '$script'" \
  "$base..HEAD"

スクリプトは $GIT_COMMIT を読み取り、/tmp/cc-rewrite-map.tsv で該当するコミットを検索して、新しいメッセージを出力します。マップにないコミットは変更されずに通過します。

git filter-repo が利用できる場合（非推奨の filter-branch より推奨）：代わりにこれを使用します。ただし、同梱のマッピングフローは現在 filter-branch に依存しています。ユーザーが filter-repo を利用でき、かつ希望する場合にのみ切り替えてください。

Step 7: ブランチベースの書き換え（Step 2 のオプション 3）

コミットがプッシュ済みで、ユーザーがオプション 3 を選んだ場合は、インプレースで書き換える代わりに、次のようにします。

# 1. Note current branch
src=$(git branch --show-current)

# 2. Create a fresh branch off the upstream/base
git checkout -b "${src}-cc" "$base"

# 3. Cherry-pick each commit, rewriting message as you go
for sha in $(git rev-list --reverse --no-merges "$base..$src"); do
  new_msg=$(lookup_in_map "$sha")   # from Step 4 plan; or compose interactively
  git cherry-pick "$sha"
  git commit --amend -m "$new_msg"  # only the cherry-pick we just made
done

# 4. Verify, then push the new branch
git log --oneline "$base..HEAD"
git push -u origin "${src}-cc"

元のブランチには手を加えません。ユーザーは ${src}-cc から PR を作成し、準備ができたら元のブランチを放棄できます。強制プッシュも破壊的な操作もありません。

Step 8: 書き換え後のクリーンアップ

インプレースで書き換えた後（Step 6）：

• git log --oneline "$base..HEAD" を実行し、結果を表示します。
• バックアップ参照が refs/original/refs/heads/<branch> に保持されていることと、問題ないと確認できた後に削除する方法をユーザーに伝えます。

  git update-ref -d refs/original/refs/heads/<branch>
  

  自動的に削除してはいけません。
• 一時ファイルを削除します。

  rm -f /tmp/cc-rewrite-map.tsv
  

ブランチベースで書き換えた後（Step 7）：

• 気が変わった場合に元に戻す方法をユーザーに伝えます。

  git checkout <original-branch>
  git branch -D <branch>-cc
  

作業例：整理されていない履歴

User: 커밋 메시지 다시 써줘
       (User shares git log:)
       96b6be8  gnhf #43: Added User-Agent Parser ...
       eda73c5  gnhf #42: Added JSON Schema Generator ...
       e943794  gnhf #41: Added IPv4 Subnet Calculator ...
       0a7e01e  gnhf #40: Added Markdown TOC Generator ...

Step 1 (range):
   upstream = origin/gnhf/prd-chann-tools-2026-8f2964
   base = $(git merge-base HEAD origin/main)

Step 2 (safety):
   ✓ working tree clean
   ✓ HEAD attached
   ✗ all 4 commits exist on origin/<branch>
   → Show menu (Cancel / Force-push / New branch). User picks 3.

Step 3 (regex): all 4 fail the regex (start with "gnhf #N:")

Step 4 (mapping):
   "gnhf #43: Added User-Agent Parser..."   → feat(api-network): add user-agent parser
   "gnhf #42: Added JSON Schema Generator"  → feat(data-format): add JSON schema generator
   "gnhf #41: Added IPv4 Subnet Calculator" → feat(api-network): add IPv4 subnet calculator
   "gnhf #40: Added Markdown TOC Generator" → feat(text): add Markdown TOC generator

   Drop the "gnhf #N" prefix (ticket-tracker noise; belongs in the body or a footer).
   To preserve the ticket reference, add a footer:
       Refs: gnhf#43

Step 5: show old → new plan, wait for confirmation.

Step 7 (branch-based):
   git checkout -b feature-tools-cc origin/main
   for sha in (cherry-pick each, --amend with new message)
   git push -u origin feature-tools-cc

よくある規約違反パターンの対応表

Step 4 で新しいサブジェクトを生成する際は、次の対応を使用してください。

元のパターン	一般的な Conventional 形式への書き換え
Added X / Add X	feat: add X（または feat(scope): add X）
Fixed X / Fix X / Bugfix: X	fix: <imperative>
Updated X（外観の変更／依存関係の更新）	chore: update X または build(deps): bump X
Updated X（実際のリファクタリング）	refactor: <imperative>
Cleanup / Clean up X	refactor: <imperative> または chore: <imperative>
Renamed X to Y	refactor: rename X to Y
Removed X / Delete X	refactor: remove X（または破壊的変更の場合は feat!:）
WIP / wip / tmp	chore: work-in-progress checkpoint
Initial commit	chore: initial commit
Merge branch 'X'	スキップ（マージコミットは除外されます）
[TICKET-123] Added X	feat: add X + フッター Refs: TICKET-123
proj #N: Added X	feat(scope): add X + フッター Refs: proj#N
Tests for X	test: add tests for X
Docs: <anything>	docs: <imperative>
Refactor X（すでに命令形に近い）	refactor: <imperative form>

判断の目安：

• 過去形 → 命令形（「Added」→「add」、「Fixed」→「fix」）
• 大文字 → 小文字
• 末尾のピリオドを削除
• チケット管理システムのプレフィックス → Refs: フッターに移動（関連付けを削除しない）
• chore、refactor、style のどれに該当するか本当に曖昧な場合は、ツール／設定には chore、コード構造の変更には refactor、空白や書式設定のみには style を優先します

クイックリファレンス

判断に迷った場合は、次のように対応します。

症状	対応
作業中の変更なし + 整理されていない履歴	/git-commit-rewrite を提案する
作業中の変更あり + 整理されていない履歴	まずコミットし、その後 /git-commit-rewrite を実行する
プッシュ済みの履歴を修正したい	Step 7（ブランチベースの書き換え）を使用する
pre-commit フックが失敗する	根本的な問題を修正する。--no-verify は絶対に使用しない
プッシュが拒否された（non-FF）	停止してエラーを伝える。明示的な同意なしに --force を使用しない
git filter-branch が非推奨の警告を表示する	FILTER_BRANCH_SQUELCH_WARNING=1 はすでに設定されています。無視してください

よくある間違い

feat と fix を 1 つのコミットにまとめる

• 問題: feat(auth): add OAuth and fix null response のように、種類が混在しています
• 修正: feat と fix をそれぞれ 1 つずつ、別々のコミットにします

過去形の件名

• 問題: 「added login flow」「fixed bug」
• 修正: 命令形にします。「add login flow」「handle null response」

すべてをステージするために git add . を使う

• 問題: シークレットや無関係な変更を誤ってステージする可能性があります
• 修正: グループごとに、常に git add <explicit-paths> を使います

--no-verify でフックを回避する

• 問題: 実際の問題が隠れ、ローカルではコミットが「機能」しても CI で失敗します
• 修正: フックの失敗を調査し、根本原因を修正して、新しいコミットを作成します

プッシュ済みの履歴の書き換えを、理由を伝えずに拒否する

• 問題: 先に進む方法を示さずに「できません」と伝えます
• 修正: ステップ 2 の 3 つの選択肢（キャンセル／強制プッシュ／ブランチベース）を提示します

書き換え時にチケット参照を削除する

• 問題: 「gnhf #43: Added X」から「feat: add X」にすると、gnhf#43 との関連付けが失われます
• 修正: チケットを Refs: gnhf#43 フッターに移し、失わないようにします

マージコミットを書き換える

• 問題: マージに対する filter-branch は親コミットとの関連付けを乱します
• 修正: 常に git rev-list --no-merges を使います

危険信号

絶対にしないこと:

• git add . または git add -A（明示的なパスを指定してください）
• ユーザーの明示的な同意なしに --no-verify、--no-gpg-sign、--amend を使うこと
• --force でプッシュすること — 例外: /git-commit-rewrite の強制モード（force キーワードは明示的な同意です）。それ以外の場合は、明示的な同意を得た後に限り --force-with-lease を使います
• ユーザーから明示的な上書き許可を得ずに、.env* ファイル（正確なベース名が .env.example のものを除く）、credentials.*、*_rsa、*.pem、*.key、または *.p12 のうち、シークレットの可能性があるファイルをコミットすること
• feat と fix を 1 つのコミットにまとめること
• 最初に 3 つの選択肢を提示せずに、プッシュ済みのコミットを書き換えること — 例外: 強制モードでは、force キーワードが事前同意となります
• git filter-branch --root を使うこと
• 書き換え時にチケット参照を削除すること（Refs: フッターに移してください）

必ず行うこと:

• コミットを作成する前に、コミット計画を提示します
• 各コミットの後に git status --short を実行して確認します
• 書き換え時に、元のコミット本文を一字一句そのまま維持します
• 書き換えるコミットを一覧表示するときは --no-merges を使います
• プッシュ済みコミットについて確認する際は、デフォルトで「キャンセル」を選びます
• リポジトリの既存のスコープ規則に合わせます（最初に git log -20 --oneline を実行します）

動作に関する注意事項

リポジトリの既存のスタイルに合わせます。 最初に git log -20 --oneline を確認します。リポジトリが Conventional Commits を使っている場合は、そのスコープ規則に合わせます。既存のメッセージが混在している場合は、小文字の説明と簡潔なスコープをデフォルトにします。

会話での説明とコミットメッセージの言語。 会話での更新にはユーザーのプロンプトの言語を使います。コミットメッセージには、git log で優勢な言語を使います（判断がつかない場合は英語）。

スコープは慎重に使います。 スコープには、実在するモジュールまたは領域を指定する必要があります。判断がつかない場合は、作り出すよりもスコープを省略します。

本文で過剰に説明しないでください。 本文には、件名だけでは伝えられない背景（理由、扱いに注意が必要なトレードオフ、関連する問題）を補足します。件名だけで明確な場合は、本文は不要です。

回避せず、拒否します。 安全性チェックに失敗した場合（同意のないプッシュ済みコミット、作業ツリーがクリーンでない、detached HEAD、シークレットの可能性があるファイル）は、その旨を報告して停止します。破壊的なフラグを使って回避しないでください。例外: /git-commit-rewrite の強制モードでは、ユーザーが force キーワードで明示的に選択できます（「強制モード」を参照）。

ユーザーの明示的な上書き指示に従います。 「強制プッシュして」「プッシュ済みだと分かっているけれど、とにかく書き換えて」「今回は .env を含めて」などの指示があれば、まずリスクを 1 行で伝えてから進めます。/git-commit-rewrite では、force キーワードがその正式な形式です（「強制モード」を参照）。

統合

連携先:

• code-review — 最終的な品質確認として、コミット前に /code-review を実行します
• git-merge-to-main / git-merge-to-dev — コミット後にブランチを統合します
• あらゆるプラグインのコミットフック（commitlint、husky） — --no-verify を使わずに違反を修正します

呼び出し元: ユーザーによる手動呼び出しのみです。他のスキルのワークフロー中に自動実行してはいけません。