cc-safety-net CLI を実行し、その出力を読んで、平易な言葉で報告します。
スキルが行うのは CC Safety Net の操作だけで、保護そのものは担いません。保護は hook が行い、スキルを読み込んでいるかどうかに関係なく動作します。
呼び出し方
スキルはプラグインに同梱されています。プラグインをインストールすれば、スキルも入ります。
Antigravity CLI と Kimi Code では、
npx skill add kenryu42/cc-safety-net で個別に追加します。インストールを参照してください。
呼び出しに続けて書いた内容が、そのまま依頼になります。
モデルが自分から起動することはありません
作業の途中でモデルがこのスキルを読み込むことはできません。エージェントの系統ごとに、次の 2 つの設定でそれを担保しています。- SKILL.md のフロントマターの
disable-model-invocation: true。Claude Code と Kimi Code がこれを尊重します。 - スキルと同じ場所に置いた
agents/openai.yamlのallow_implicit_invocation: false。Codex はフロントマターのこのフィールドを無視するため、この設定が必要です。
こんなときに使う
BLOCKED by CC Safety Netでコマンドが拒否され、その理由を順を追って知りたいとき。- ブロックが誤りに見え、トリアージしてほしいとき。判定の再現、原因となったカスタムルールの修正、組み込みルールの誤検知の報告まで対応します。
- カスタムのブロックルールを作成、編集、移行してほしいとき。
- 安全レベルの変更、保護の切り替え、パスリストの調整をしたいとき。
- 別のエージェント CLI に CC Safety Net をインストール、更新、削除したいとき。
- 追加したルールが発火しないとき、または保護が有効かどうかを確認したいとき。
explainやrule docの出力だけでは分からない、アナライザーの挙動の理由を知りたいとき。
各ワークフローの内容
スキルは依頼内容から 7 つのワークフローのいずれかを選びます。 判定を説明する。 ブロックされたコマンドそのものを取得し、手元になければlogs から探します。それを 1 つのリテラル引数として explain に渡し、トレースから一致したルールを読み取って、理由と、その理由が示す安全な代替手段を報告します。explain は許可・ブロックのどちらの判定でも終了コード 0 を返すため、スキルは終了コードではなく出力から判定を読み取ります。explain トレースを参照してください。
誤検知をトリアージする。 logs --suspect --since 7 で疑わしい拒否を一覧し、explain で判定を再現して、発火したルールを特定します。カスタムルールが発火した場合は、その rulebook を編集するか override で無効化し、explain を再実行して新しい判定を確認します。組み込みルールが発火した場合、ルールの編集で緩和することはできません。理由に記載された回避手段、たとえば linked worktree でのローカルな Git 破棄に対する CC_SAFETY_NET_WORKTREE=1 や、信頼できる transparent wrapper が実際のコマンドを隠していた場合の rule wrapper add を探します。その組み込みルールを無効にしたいとはっきり伝えると、explain --json からルール ID を読み取り、ルールごとのポリシー override を提案します。適用するのはあなたです。該当するものがなければ、そのルールが守っているリスクを説明したうえで、issue の報告先を案内します。
ルールを設定する。 スコープ（ユーザー、プロジェクト、現在のリポジトリ内の共有 rulebook）を選び、rule verify と rule list で現状を確認し、rule doc の出力をスキーマの正として JSON を書き、結果を検証します。保存した rulebook はライブファイルなので、あとから有効化する操作は必要ありません。公式 rulebook がすでにカバーしているルールを依頼した場合は、独自に書くのではなく rule add --only <rulebook...> でその rulebook を導入します。カスタムルールと公式 rulebookを参照してください。
ポリシーを設定する。 2 つの policy.json はどちらも保護対象です。スキルは提案し、適用するのはあなたです。保護されていないパスに提案ファイルを書き、policy check を実行して差分を提示します。そのうえで、自分のターミナルで実行する policy apply コマンドをそのまま渡します。policy.json のフィールドリファレンスを備えているため、提案では、安全レベルを設定し、レベルとは別に個別の機能を明示的に指定し、各保護を有効・無効に切り替え、組み込みルールを個別にオン・オフし、allow path と deny path の一覧を編集し、ユーザースコープでは監査ログの保持期間を設定できます。ポリシーを参照してください。
連携を管理する。 まず doctor を実行し、検出・設定・検証の状況を確認します。install --claude-code のように対象フラグを明示してインストールし、完了後にもう一度 doctor を実行して、該当する行が verified になっていることを確かめます。フラグなしの install は対話的なピッカーを開くため、スキルはこれをあなたのターミナルに任せます。
診断する。 status は、ランタイムが今何を強制しているかを示します。rule list が報告しない、degraded な policy.json も含みます。doctor はプラットフォームの検出と hook の設定を検証し、合成コマンドによるガードの自己テストを実行し、設定のスコープを確認します。カスタムルールが発火しない場合は、rule verify、rule list の順に実行し、そのうえで explain でコマンドを再テストします。トラブルシューティングを参照してください。
バージョンが一致するソースから答える。 CLI の出力だけでは決着しない質問には、実際に動作しているバージョンのソースを読みます。詳しくは次のセクションを参照してください。
バージョンが一致するソースの読み取り
npm で公開しているパッケージには minify 済みのdist しか含まれておらず、読めるソースはありません。そこでスキルは --version で <version> を取得し、2 つの場所を順に当たります。
プラグインとしてインストールした場合はリポジトリ全体が配置され、スキルファイルはその中の <repo>/skills/cc-safety-net/SKILL.md にあります。つまりリポジトリのルートは 2 階層上です。スキルがこの候補を採用するのは、package.json の "name" が "cc-safety-net" でバージョンも一致し、隣に src/ ディレクトリがある場合だけです。
見つからない場合は、npm view "cc-safety-net@<version>" gitHead で公開パッケージに記録されたコミットを解決します。40 桁の小文字 16 進数であることを確認したうえで、そのコミットだけを、所有者だけがアクセスできる新規の一時ディレクトリに fetch します。このとき、継承された Git の hook とテンプレートは無効化します。読み取りの前に HEAD が想定どおりのコミットかどうかを検証し、終わったらチェックアウトを削除します。
main から答えることはありません。インストール済みのバージョンにはない未リリースの挙動が含まれている可能性があるためです。回答には、どのバージョンのソースを読んだかを明記します。取得したソースは参照専用として扱い、編集もビルドも実行もしません。
読み取り専用として扱うコマンド
次のコマンドは、どのワークフローのどの時点でも、調査のために実行して差し支えないものとして扱われます。--help、--version、status、doctor、logs（--prune-legacy なし）、explain、rule list、rule verify、rule doc、policy check、help。
これ以外のコマンドは、設定またはインストール済みの連携を変更します。スキルがそれらを実行するのは、上記いずれかのワークフローの一手順としてだけです。各コマンドの内容は CLI コマンドを参照してください。
コマンド文字列の扱い
ブロックされたコマンドは、シェルを通すと壊れやすい文字列であることが少なくありません。スキルはコマンド文字列やラッパー名を argv の個別の値として CLI に渡し、シェルを経由せざるを得ない場合は全体をシェルエスケープして 1 つの引数にします。コマンド置換、バッククォート、変数は、アナライザーに届くまで展開されません。 受け取ったあとのexplain は、その文字列を解析するだけで実行しません。rulebook のフィクスチャも同様です。rule verify は rulebook_version 2 のフィクスチャをその rulebook 自身のルールに対して評価しますが、フィクスチャのコマンドはアナライザーへの入力であり、CC Safety Net が実行することはありません。
スキルが行わないこと
- CC Safety Net の回避に手を貸すこと。ブロックされたコマンドを通すためにレベルを下げる、アンインストールする、設定を編集する、保護を弱めるポリシーを提案する、といったことはしません。あなたがその結果を明示的に求め、そのブロックが何を守っているかを理解している場合は別です。
- どちらの
policy.jsonにも書き込むこと。読み取りは許可されていますが、書き込みは許可されていません。エージェントによるpolicy applyの実行は設計上ブロックされ、--yesフラグもありません。スキルがコマンドをラップしたり、別の方法でファイルを書いたりすることもありません。 - ルール作成中に GitHub の rulebook を設定元として追加するよう提案すること。GitHub の設定元からの rulebook のインストールは、このワークフローの範囲外です。既存の rulebook をインストールしたいと明示的に依頼した場合にだけ
rule add owner/repo --only <rulebook...>を使い、既定以外の ref を指定した場合にだけ--ref <ref>を添えます。 hookを実行すること。これは hook の JSON を標準入力から読む連携のエントリーポイントであり、ユーザーが直接実行するコマンドではありません。- 明示的な依頼なしに
logs --prune-legacyを実行すること。このコマンドはレガシーログを完全に削除するため、依頼された場合もまず--dry-runを実行します。 - 確認なしに
rule remove --delete-sourceを実行すること。このフラグはローカルの設定元ディレクトリを削除します。 - 検証や有効化の手順として
rule syncを実行すること。rule syncは非推奨で、以前のバージョンが残した lock とキャッシュを移行するだけです。
gui は --no-open を優先し、セッションからブラウザーを開かずに URL を渡します。
スキルは
cc-safety-net rule doc の出力を、rulebook のスキーマ、パス、GitHub の設定元、照合の挙動、検証についての完全な正としています。同じ内容はカスタムルールにも記載しています。