name: forbidden-actions description: 絶対禁止事項の詳細と理由を明確化。hooksと連携して物理的に禁止操作を防ぐ。

Forbidden Actions Skill

目的

絶対禁止事項の詳細と理由を明確化し、違反を防止する。hooks と連携して物理的に禁止操作を防ぐ。

絶対禁止事項

1. Git操作の禁止

禁止内容

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

理由

コミットメッセージと履歴の責任はユーザーにある

• コミットメッセージはプロジェクトの重要な記録
• 誰が何のために変更したかを正確に記録する必要がある
• AIが自動生成したメッセージは不正確・不完全な可能性
• Git履歴はコードレビュー・トラブルシューティングで重要

具体例:

❌ 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 を実行する

2. mainブランチでの作業禁止

禁止内容

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

理由

本番環境への影響リスクを排除

• mainブランチは本番環境と直結している可能性
• 直接編集は他の開発者への影響が大きい
• レビュープロセスをバイパスしてしまう
• ロールバックが困難

具体例:

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

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

代替手段

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

3. スキル未確認での実装禁止

禁止内容

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

理由

品質低下と手戻りを防ぐ

• スキルは試行錯誤の結果蓄積されたベストプラクティス
• スキルを無視すると同じ失敗を繰り返す
• 手戻りが発生し、時間の無駄
• 品質が不安定になる

具体例:

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

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

代替手段

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

4. テスト前の実装禁止

禁止内容

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

理由

TDD原則の遵守

• テストファーストで要件を明確化
• リグレッションを防ぐ
• リファクタリングの安全性を確保
• "後で書く"テストは書かれない

具体例:

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

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

代替手段

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

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

5. 単一解の押し付け禁止

禁止内容

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

理由

多角的思考の欠如

• 複数の選択肢を検討していない証拠
• トレードオフを理解していない
• ユーザーの選択の余地を奪う
• より良い案を見逃す可能性

具体例:

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

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

代替手段

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

詳細: communication-guidelines スキル参照

6. ユーザーの質問無視禁止

禁止内容

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

理由

コミュニケーション崩壊

• ユーザーの疑問が解決されない
• 誤解が蓄積する
• 信頼関係が損なわれる
• 間違った方向に進む

具体例:

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

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

代替手段

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

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

詳細: communication-guidelines スキル参照

違反検知と防止

レベル1: 自己チェック

各アクション前に確認:

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

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

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

レベル2: hooks による自動検知

# 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

レベル3: Claude Code本体の制約

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

違反時の対応フロー

ステップ1: 即座に操作を中断

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

ステップ2: 禁止理由を説明

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

ステップ3: 代替手段を提案

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

例: Git commit を試みた場合

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

↓

🛑 中断: 実行を停止

↓

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

↓

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

よくある違反パターン

パターン1: "効率化のため"

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

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

パターン2: "ユーザーの期待"

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

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

パターン3: "小さな変更だから"

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

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

パターン4: "時間がないから"

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

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

チェックリスト

実行前の確認

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

違反検知時

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

関連スキル

• git-workflow - Git操作の正しい手順
• test-driven-development - TDD の実践
• brainstorming-design - 複数案の発散
• communication-guidelines - コミュニケーション原則

まとめ

禁止事項は絶対

1. Git操作 (commit/push) は禁止
2. main ブランチでの作業は禁止
3. スキル未確認での実装は禁止
4. テスト前の実装は禁止
5. 単一解の押し付けは禁止
6. ユーザーの質問無視は禁止

違反検知 → 即中断 → 理由説明 → 代替提案

これらのルールは品質と安全性のため。例外は認めない。