❌ git commit
❌ git push
❌ git merge (mainへのmerge)

❌ Claude が自動commit:
"Update file.py"
→ 何を変更したか不明

✅ ユーザーがcommit:
"fix: Resolve session initialization race condition in login flow (#123)"
→ 目的・影響が明確

Claude の役割:
1. 実装を完了する
2. 変更内容を説明する
3. コミットメッセージの提案をする (あくまで提案)

ユーザーの役割:
1. 変更内容を確認する
2. コミットメッセージを書く
3. commit & push を実行する

❌ mainブランチでの直接編集
❌ masterブランチでの直接編集
❌ productionブランチでの直接編集

❌ main で直接編集:
main → 編集 → バグ発見 → 本番環境に影響

✅ feature ブランチで編集:
main → feature/xxx → 編集 → テスト → レビュー → merge

必ず feature ブランチを作成:
1. git-new-feature <機能名> でブランチ作成
2. feature ブランチで作業
3. テスト・レビュー完了後にユーザーがmerge

❌ 該当スキルを読まずに実装開始
❌ スキルの手順を無視
❌ 自己流で実装

❌ スキル未確認:
実装 → テスト失敗 → デバッグ → 原因不明 → 手戻り

✅ スキル確認後:
test-driven-development 確認 → テスト先行 → 実装 → 成功

実装前の必須ステップ:
1. 該当スキルを特定
2. view ~/.claude/skills/<スキル>/SKILL.md
3. 手順を理解
4. 実装開始

❌ テストを書かずに実装
❌ 実装が先、テストが後
❌ "後でテストを書く"

❌ 実装ファースト:
実装 → 動いた → "後でテスト" → 忘れる → バグ混入

✅ テストファースト (TDD):
RED: テスト書く → 失敗 (当然)
GREEN: 実装 → テスト成功
REFACTOR: リファクタリング → テスト成功 (安全)

RED-GREEN-REFACTOR サイクル:
1. テストを先に書く (RED)
2. 最小限の実装で通す (GREEN)
3. リファクタリング (REFACTOR)

詳細: test-driven-development スキル参照

❌ "この方法で実装します" (1案のみ)
❌ "これが最適です" (比較なし)
❌ "他の方法はありません"

❌ 単一解:
"Redisでキャッシュします"
→ 他の選択肢は? コストは? デメリットは?

✅ 複数案:
案1: Redis (速度優先、コスト高)
案2: アプリケーションキャッシュ (コスト低、機能限定)
案3: DBインデックス最適化 (コスト最低、効果中)
推奨: 案1 (目標0.5秒を達成可能)

必ず複数案(2-3)を提示:
1. brainstorming-design スキルで発散
2. 各案のメリデメを明確化
3. 推奨案と理由を示す
4. ユーザーに選択を委ねる

詳細: communication-guidelines スキル参照

❌ 質問をスルーして別の話題に移る
❌ "後で答えます"
❌ 質問を無視して実装を進める

❌ 質問無視:
ユーザー: "なぜこの方法?"
Claude: "では実装を進めます"
→ ユーザーの疑問が残る

✅ 質問に回答:
ユーザー: "なぜこの方法?"
Claude: "理由は○○です。具体的には..."
→ 疑問が解決してから次へ

質問への対応優先度:
1. ユーザーの質問 (最優先)
2. 提案内容の説明
3. 実装の詳細

質問には必ず:
- 明確な回答
- 理由の説明
- 必要に応じて追加情報

詳細: communication-guidelines スキル参照

各アクション前に確認:

Git操作前:
□ これは commit または push か?
  → YES なら中断

実装前:
□ 現在のブランチは main か?
  → YES なら git-new-feature 実行
□ 該当スキルを読んだか?
  → NO なら先に読む
□ テストを書いたか?
  → NO なら先に書く
□ 複数案を検討したか?
  → NO なら brainstorming-design

回答前:
□ ユーザーの質問に答えたか?
  → NO なら先に回答

# hooks/pre_action.sh

# Git操作検知
if [[ "$ACTION" =~ ^(commit|push) ]]; then
    echo "❌ ERROR: Git commit/push is forbidden"
    echo "📖 See: forbidden-actions skill"
    exit 1
fi

# mainブランチチェック
CURRENT_BRANCH=$(git branch --show-current)
if [[ "$CURRENT_BRANCH" =~ ^(main|master|production)$ ]]; then
    if [[ "$ACTION" == "edit" ]]; then
        echo "❌ ERROR: Editing on main branch is forbidden"
        echo "💡 Run: git-new-feature <feature-name>"
        exit 1
    fi
fi

Claude Code の内部で物理的に禁止:
- commit/push コマンドの実行をブロック
- main ブランチでのファイル編集をブロック
- スキル未確認フラグでの実装開始をブロック

違反を検知 → 実行をSTOP → ユーザーに報告

"○○は禁止されています。
理由: △△
詳細: forbidden-actions スキル参照"

"代わりに以下の方法があります:
1. [代替案1]
2. [代替案2]"

❌ 検知: git commit コマンドが実行されようとしている

↓

🛑 中断: 実行を停止

↓

📢 報告:
"git commit は禁止されています。
理由: コミットメッセージの責任はユーザーにあるため
詳細: forbidden-actions スキル参照"

↓

💡 代替案:
"代わりに以下を実行してください:
1. 変更内容を確認: git diff
2. コミットメッセージを考える
3. ユーザー自身で commit を実行"

❌ 考え方:
"commit まで自動でやった方が速い"

✅ 正しい考え方:
"commit はユーザーの責任範囲。
 実装を完了し、コミットメッセージの提案まで"

❌ 考え方:
"ユーザーは全部やってほしいはず"

✅ 正しい考え方:
"禁止事項は明確に線引きされている。
 期待されても禁止は禁止"

❌ 考え方:
"main で1行だけなら問題ない"

✅ 正しい考え方:
"変更の大小に関わらず、
 feature ブランチで作業する"

❌ 考え方:
"テストは後で書けばいい"

✅ 正しい考え方:
"テストファーストは時間の節約。
 後で書くテストは書かれない"

□ これは禁止事項に該当しないか?
□ 該当する場合、代替手段は何か?
□ ユーザーに確認が必要か?

□ 即座に操作を中断したか?
□ 禁止理由を説明したか?
□ 代替手段を提案したか?
□ 必要に応じて該当スキルを参照させたか?