claude-permissions-optimizer

Claude Permissions Optimizer

不要な権限確認の原因となっている安全な Bash コマンドを見つけ、settings.json で自動許可します。推測ではなく、実際の使用履歴に基づいています。

このスキルは、実際のセッション履歴に基づいて自動許可しても安全なコマンドを特定します。特定の危険なコマンドを許可リストに追加するリクエストには対応しません。ユーザーが破壊的な操作（例：rm -rf、git push --force）の許可を求めた場合、このスキルは安全なコマンドのみを対象として最適化するものであり、許可リストは settings.json で直接手動変更できることを説明してください。

事前確認：環境を確認する

現在 Claude Code 内で実行しているか、それとも別のコーディングエージェント（Codex、Gemini CLI、Cursor など）内で実行しているかを確認します。

Claude Code 内で実行している場合： そのままステップ 1 に進みます。

別のエージェント内で実行している場合： 続行する前にユーザーに知らせます。

「このスキルは Claude Code のセッション履歴を分析し、Claude Code の settings.json に書き込みます。現在は [agent name] 内ですが、ここから Claude Code の権限を最適化できます。結果は次回 Claude Code を使用するときに適用されます。」

その後、通常どおりステップ 1 に進みます。マシン上に ~/.claude/（または $CLAUDE_CONFIG_DIR）があれば、どの環境からでもこのスキルを利用できます。

ステップ 1：分析範囲を選択する

プラットフォームの選択式質問ツール（Claude Code では AskUserQuestion、Codex では request_user_input、Gemini では ask_user）を使って、どの範囲を分析するかユーザーに尋ねます。質問ツールが利用できない場合は、番号付きの選択肢を提示し、ユーザーの返答を待ちます。

1. すべてのプロジェクト（推奨）— すべてのプロジェクトのセッション
2. このプロジェクトのみ — 現在の作業ディレクトリのセッション
3. カスタム — ユーザーが条件（期間、セッション数など）を指定

ユーザーが単一のプロジェクトを明示的に指定しない限り、すべてのプロジェクトを既定とします。データが多いほど、より適切な推奨ができます。

ステップ 2：抽出スクリプトを実行する

付属のスクリプトを実行します。このスクリプトはすべての処理を行います。現在の許可リストを読み込み、最近のセッション記録をスキャンし（直近 500 セッションまたは過去 30 日間のうち、より制限の厳しい方）、すでに対象となっているコマンドを除外し、最小カウントのしきい値（5 回以上）を適用し、Bash(pattern) ルールに正規化して、それぞれを安全／要確認／危険に事前分類します。

すべてのプロジェクト：

node <skill-dir>/scripts/extract-commands.mjs

このプロジェクトのみ — プロジェクトのスラッグ（英数字以外のすべての文字を - に置き換えた絶対パス）を渡します。例：/Users/tmchow/Code/my-project は -Users-tmchow-Code-my-project になります。

node <skill-dir>/scripts/extract-commands.mjs --project-slug <slug>

オプション：--days <N> を指定すると、直近 N 日間に限定できます。省略すると、利用可能なすべてのセッションが分析されます。

出力 JSON には以下が含まれます。

• green：推奨する安全なパターン { pattern, count, sessions, examples }
• redExamples：ブロックされた危険なパターンの上位 5 件 { pattern, reason, count }（または空）
• yellowFootnote：自動許可しても安全ではない、頻繁に使われるコマンドの概要 1 行（または null）
• stats：totalExtracted、alreadyCovered、belowThreshold、patternsReturned、greenRawCount など

モデルの役割は、スクリプトの出力を提示することであり、再分類することではありません。

スクリプトの結果が空の場合、ユーザーの許可リストはすでに十分に最適化されているか、セッション履歴がまだ不足していることを伝えます。数回作業した後に再実行するよう提案してください。

ステップ 3：結果を提示する

3 つのパートに分けて提示します。書式は見やすく、ひと目で把握できるようにします。

パート 1：分析の概要

スクリプトの stats を使って実施内容を示します。分析範囲を改めて明記します。4～5 行に収めます。

例：

## Analysis (compound-engineering-plugin)

Scanned **24 sessions** for this project.
Found **312 unique Bash commands** across those sessions.

- **245** already covered by your 43 existing allowlist rules (79%)
- **61** used fewer than 5 times (filtered as noise)
- **6 commands** remain that regularly trigger permission prompts

パート 2：推奨事項

green パターンを番号付きの表で提示します。yellowFootnote が null でない場合は、表の後に 1 行で記載します。

### Safe to auto-allow
| # | Pattern | Evidence |
|---|---------|----------|
| 1 | `Bash(bun test *)` | 23 uses across 8 sessions |
| 2 | `Bash(bun run *)` | 18 uses, covers dev/build/lint scripts |
| 3 | `Bash(node *)` | 12 uses across 5 sessions |

Also frequently used: bun install, mkdir (not classified as safe to auto-allow but may be worth reviewing)

redExamples が空でない場合は、推奨事項の後に簡潔な「ブロック済み」表を表示します。分類器が適切に機能していることを示すためのものです。最大 3 件を表示します。

### Blocked from recommendations
| Pattern | Reason | Uses |
|---------|--------|------|
| `rm *` | Irreversible file deletion | 21 |
| `eval *` | Arbitrary code execution | 14 |
| `git reset --hard *` | Destroys uncommitted work | 5 |

パート 3：結論

一文のみ。 スクリプトの統計情報を使い、現在のカバー率と比較した影響を示します。それ以外は何も書かないでください。パターン名、使用回数、詳しい説明も不要です。直後に表示される質問ツールの UI では末尾のテキストが視覚的に切り詰められるため、短い一行に収めてください。

Adding 22 rules would bring your allowlist coverage from 65% to 93%.

統計情報から割合を計算します：

• 適用前： alreadyCovered / totalExtracted * 100
• 適用後： (alreadyCovered + greenRawCount) / totalExtracted * 100

正規化されたパターンの数にすぎない patternsReturned ではなく、green パターンがカバーする一意な生コマンドの数である greenRawCount を使います。

ステップ 4：ユーザーの確認を得る

推奨事項の表はすでに表示されています。プラットフォームのブロッキング質問ツールを使って、次のいずれかを選ぶよう尋ねます：

1. すべてユーザー設定に適用（~/.claude/settings.json）
2. すべてプロジェクト設定に適用（.claude/settings.json）
3. スキップ

特定の項目を除外したい場合は、自由記述で返信できます（例：「3 と 7 以外をすべてユーザー設定に適用」）。番号付きの表はすでに表示されているため、質問ツールで項目を再掲する必要はありません。

ステップ 5：設定に適用

対象となる各設定ファイルについて：

1. 現在のファイルを読み込みます（存在しない場合は { "permissions": { "allow": [] } } を作成します）
2. 重複を避けながら、新しいパターンを permissions.allow に追加します
3. allow 配列をアルファベット順に並べ替えます
4. 2 スペースのインデントで書き戻します
5. 書き込みを検証します。このコマンドを実行する前に、たとえば「settings.json が有効な JSON か検証しています...」とユーザーに伝えてください。前置きがないと、このコマンドは不審に見えます：

   node -e "JSON.parse(require('fs').readFileSync('<path>','utf8'))"
   

   失敗した場合、ファイルは無効な JSON です。ステップ 1 で読み込んだ内容から直ちに復元し、エラーを報告してください。他のファイルの処理は続行しないでください。

検証に成功したら：

Applied N rules to ~/.claude/settings.json
Applied M rules to .claude/settings.json

These commands will no longer trigger permission prompts.

.claude/settings.json を変更し、そのファイルが git で追跡されている場合は、コミットするとチームメイトにも役立つことを伝えてください。

エッジケース

• プロジェクトコンテキストがない（プロジェクト外で実行）：書き込み先として提示するのはユーザーレベルの設定のみです。
• 設定ファイルが存在しない：{ "permissions": { "allow": [] } } を使って作成します。.claude/settings.json の場合は、必要に応じて .claude/ ディレクトリも作成します。
• 拒否ルール：コマンドがすでに拒否ルールでブロックされている場合は、許可ルールを追加せず警告してください（Claude Code では拒否ルールが優先されます）。