commit

リポジトリで既に使われている規約に沿って、短く読みやすいメッセージで git コミットを作成します。

rules/convention-detection.md が Tier 3 に到達し、マニフェストが一致する場合に限り、エコシステムガイドを読み込みます：references/go.md、references/swift.md、references/python.md、references/systems.md。

ルールの概要

ルール	影響度	ファイル
規約の検出	HIGH	rules/convention-detection.md
メッセージ形式	HIGH	rules/message-format.md
コミット種別の選択	HIGH	rules/commit-type.md
イシュー参照	MEDIUM	rules/issue-references.md
変更範囲	MEDIUM	rules/change-scope.md

コミット前のセキュリティチェック

コミットの前に毎回、プロジェクトのシークレットスキャナーを使ってステージ済みの変更をスキャンします。デフォルトは GitLeaks です。プロジェクトですでに TruffleHog を使用している場合は、TruffleHog も使用できます。

1. ステージング後、ステージ済み差分を stdin モードにパイプしてスキャナーを実行します。GitLeaks の場合：git diff --cached | gitleaks stdin --redact --verbose。TruffleHog の場合：git diff --cached | trufflehog stdin --results=verified,unknown --fail（TruffleHog がオンラインで検証できない認証情報もコミットをブロックするよう、GitLeaks と同様に unknown を含めます）。パイプを使うことで git は通常のコマンドとして扱われるため、worktree で分離されたセッションでも受け入れられます。gitleaks git と trufflehog git は git をオペランドとして渡すため、そのようなセッションでは拒否されます。
2. スキャナーが漏えいを検出した場合は、必ず停止します。コミットせず、検出内容を報告して、シークレットを削除するようユーザーに依頼します（公開済みの場合はローテーションも依頼します）。
3. シークレットスキャナーがインストールされていない場合（コマンドが見つからない場合）、暗黙にインストールしてはいけません。プロジェクトの pre-commit フックがスキャナーを実行する場合は、コミットしてフックにスキャンさせます。それ以外の場合は、スキャナーが利用できないことをユーザーに伝え、インストールを提案し（brew install gitleaks または同等の方法）、スキャンなしでコミットしてよいか確認します。

コミットの一環として .husky/、commitlint、その他のプロジェクトツールを編集してはいけません。pre-commit フックがない場合は、その旨を報告し、自分で設定せずに setup スキルを案内します。

ワークフロー

コミットの依頼ではステージングとコミットのみを行います。pull、stash、stash の復元、プロジェクトツールの書き換えは決して行いません。

1. 現在の git status を表示し、すべての変更を分析します
2. リポジトリのコミット規約を検出します（rules/convention-detection.md を参照）
3. 会話のコンテキストからイシュー参照を確認します（rules/issue-references.md を参照）
4. 変更範囲を評価します（rules/change-scope.md を参照）
5. この変更に関連する、明示されたパスのみをステージングします。無関係な変更をまとめてステージングしてはいけません
6. ステージ済み差分だけでなく、ブランチのコンテキストからコミット種別または先頭の動詞を選びます（rules/commit-type.md を参照）
7. 上記のコミット前のセキュリティチェックを実行します
8. rules/message-format.md に従ったメッセージでコミットを作成します

規約の検出で Tier 3 または Tier 4 が使われた場合（強制されたツールや明確な履歴ではなく、エコシステムのデフォルトまたは一般的なフォールバックを使用した場合）は、どの規約を、なぜ使用したのかを明示し、推測が誤っていた場合に分かるようにします。