update-allowed-tools

このスキルを呼び出すこと自体がリクエストです。ユーザーメッセージが空に見えても、問題ありません。想定どおりであり、タスクはここですべて指定されています。何をすればよいか尋ねないでください。

手順 5 のルールは完全に機械的です。そのまま適用して編集してください。アドバイザーに相談したり、セカンドオピニオンを求めたりしないでください。判定は変わらず、実行時間が 2 倍になるだけです。

概要

スキルの全コンテンツ（SKILL.md と同じディレクトリにある関連ファイル）を分析し、参照または必要としているツールを特定したうえで、スキルの allowed-tools フロントマターと比較し、不足しているエントリーと何の権限も付与しないエントリーを見つけます。

allowed-tools は権限の仕組みに限ったものです。スキルがなければ発生する権限プロンプトを抑止するエントリーにのみ意味があります。スキルが使用するツールの一覧ではありません。また、何かを制限するものでもありません。すべてのツールは引き続き呼び出し可能であり、権限の付与はスキルを呼び出したターンの間だけ有効です。

使い方

/update-allowed-tools <skill name>
/update-allowed-tools @path/to/SKILL.md

手順

1. 引数を解析する：引数は、SKILL.md ファイルのパス、またはスキル名／説明のいずれかです。ファイルパスが指定されていない場合は、現在の作業ディレクトリ内の **/skills/**/<name>/SKILL.md を Glob で検索し、次に ~/.claude/skills/<name>/SKILL.md を検索します。引数がまったくない場合は git status を実行し、作業ツリー内で最後に更新されたスキルファイルを対象にします。

2. スキルファイルを読む：YAML フロントマターと本文を分けます。また、同じディレクトリにある他のファイル（スキルから参照されているファイル、またはスキルに同梱されているファイル）も読みます。

3. 宣言された allowed-tools を抽出する：フロントマターの allowed-tools: 以下にあるすべてのエントリーを解析します。

4. スキルの全コンテンツをスキャンする（SKILL.md の本文と関連ファイル）：ツールの使用箇所を探します。以下を確認してください。

   • デフォルトでプロンプトを表示する明示的なツール名：Write、Edit、Bash、WebFetch、WebSearch、および mcp__* ツール。
   • Bash コマンドのパターン：git commit、make、npm、docker、python、curl など。エントリー形式は Bash(<command>:*) です（git stash push には Bash(git stash:*) が必要です）。1 つのパターンでそのサブコマンドも対象になります。Bash(<command> *) は権限ダイアログに表示される形式で、同じルールです。一方の形式をもう一方に書き換えてはいけません。
   • Bash ルールは複合コマンド内の各サブコマンドにも個別に適用されます。判定時には &&、||、;、|、および改行で分割します。そのため、本文に cd X && git commit や git commit -m "$(...)" と記述されている場合、Bash(git commit:*) ではカバーされません。このようなコマンドは、ルールを広げるのではなく、本文の修正として報告してください。timeout、time、nice、nohup、stdbuf、およびコマンド名のない xargs ラッパーは、マッチング前に取り除かれるため、個別のエントリーは不要です。npx、docker exec などの実行ツールは取り除かれないため、エントリーには実行ツールと内部コマンドの両方を含めます。
   • リダイレクト先（> file、< file）は Bash ルールではなく、Edit または Read のルールと作業ディレクトリに照らして確認されます。そのため、git diff > /tmp/x.diff には Edit(//tmp/**) が必要であり、Bash エントリーは不要です。
   • 同梱スクリプトは、Bash(${CLAUDE_SKILL_DIR}/scripts/<name> *) によってプロンプトなしで実行できます。${CLAUDE_PLUGIN_ROOT} も同様に機能しますが、.claude-plugin/plugin.json を含むディレクトリが先祖にあるプラグインスキルでのみ置換されます。それ以外の場所では何にもマッチしません。
   • スキルが読み取る、または編集するファイルパス。パスルールは、作業ディレクトリからの相対パスなら ./path、ホームディレクトリ基準なら ~/path、絶対パスなら //path として記述します。単一スラッシュの Edit(/path) は設定ソースを基準とし、スキル内では曖昧になります。置き換えてください。

5. 比較する：本文で検出したツールごとに、allowed-tools のエントリーでカバーされているか確認します。完全一致はカバーされているものとみなします（WebSearch は WebSearch と一致します）。その後、以下のルールを適用してください。いずれかのルールで無効と判定されたエントリーは、決して追加せず、すでに存在する場合は削除します。 無効なエントリ：

   • Read、Grep、Glob、および作業ディレクトリ内のすべての Read(path)：このディレクトリ内の読み取りでは、プロンプトは表示されません。作業ディレクトリ外の Read(path)（Read(//tmp/**)、Read(~/.claude/**)）は実際に許可が必要です。ディレクトリ外での最初の読み取り時にプロンプトが表示されるためです。
   • Write(path)、Glob(path)、NotebookEdit(path)、MultiEdit(path)：Claude Code はファイルのアクセス許可を Edit(path) および Read(path) のルールに照らして確認するだけで、これらは参照しません。ファイルの作成にも Edit(path) を使用してください。
   • 保護対象パスへの Edit、および保護対象パスを対象とする Bash のファイル操作コマンド（rm、mv、cp、sed -i、> リダイレクト）：どのモードでも、どの許可ルールによっても、これらのパスへの書き込みが事前承認されることはありません。保護対象ディレクトリには、場所を問わない .git、.claude（~/.claude/** と .claude/** の両方。ただし .claude/worktrees を除く）、.vscode、.idea、.husky、.cargo、.devcontainer、.yarn、.mvn、.config/git が含まれます。保護対象ファイルには、.gitconfig、.gitmodules、.zshrc や .bashrc などのシェル rc ファイル、.npmrc、.pre-commit-config.yaml、.mcp.json、.claude.json が含まれます。完全な一覧は https://code.claude.com/docs/en/permission-modes#protected-paths にあります。これらのパスの読み取りは保護対象ではありません。
   • 組み込みの読み取り専用セットに含まれる Bash コマンド：どのモードでもプロンプトなしで実行されます。ls、cat、echo、pwd、head、tail、grep、find、wc、which、diff、stat、du、作業ディレクトリ内での cd、および git status、git diff、git log、git branch、git show、git rev-parse などの読み取り専用の git 形式が該当します。例外：本文で引用符なしの glob を指定して実行する場合、Manual モードでは find、sort、sed、git にプロンプトが表示されるため、その場合に限りエントリを残してください。
   • Bash(*)、Bash(python*)、および任意のコード実行を許可するその他のルール：auto モードでは開始時に削除され、包括的な許可を追加しても、そのスキルをインストールする他のユーザーの設定が緩和されるだけです。単独の Edit、単独の Write、Edit(**) も同様です。編集の許可は、スキルが変更する対象パスに限定してください（Edit(CLAUDE.md)、Edit(~/.config/**)）。スキルが実行時にしかわからないパスを編集する場合は、何も追加せず、プロンプトが表示されるようにしてください。
   • Skill(...)、AskUserQuestion、Agent、Agent(<name>)：スキルの呼び出し、ユーザーへの質問、サブエージェントの起動では、デフォルトでプロンプトは表示されません。また、ユーザーが ask または deny ルールでこれらを制限している場合、許可を追加してもそのルールを上書きできません。

6. スキルファイルを更新する：スキルの YAML フロントマターにある allowed-tools リストに不足しているエントリを追加し、許可を与えないエントリを削除します。Edit ツールを使用してください。リストが空になった場合は、allowed-tools フィールドを削除します。その後、追加した内容、削除した各エントリが無効となる理由、および残した各エントリに上記のルールが適用されないことを確認した根拠を報告してください。

7. 検証する：更新したファイルを再度読み込み、YAML フロントマターが構文的に有効であること（適切なインデント、重複のないエントリ、正しいリスト形式）を確認してください。