> ## Documentation Index
> Fetch the complete documentation index at: https://ccsafetynet.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# /cc-safety-net スキル

> /cc-safety-net スキルを呼び出すと、ブロックの理由の説明、誤検知のトリアージ、rulebook のルール作成、ポリシー変更の提案、連携の管理、保護の診断を任せられます。呼び出したときだけ動作します。

CC Safety Net には、コーディングエージェントをこのツールのオペレーターに変えるスキルが同梱されています。コマンドが拒否された理由を尋ねる、rulebook のルールを書かせる、インストール状態を確認させる、といった使い方ができます。スキルは `cc-safety-net` CLI を実行し、その出力を読んで、平易な言葉で報告します。

スキルが行うのは CC Safety Net の操作だけで、保護そのものは担いません。保護は hook が行い、スキルを読み込んでいるかどうかに関係なく動作します。

## 呼び出し方

スキルはプラグインに同梱されています。プラグインをインストールすれば、スキルも入ります。

| エージェント        | 呼び出し方                                                 |
| ------------- | ----------------------------------------------------- |
| Claude Code   | プラグインの名前空間の下に `cc-safety-net:cc-safety-net` として表示されます |
| Pi と OpenCode | 各連携が組み込みコマンドとして登録する `/cc-safety-net`                  |

Antigravity CLI と Kimi Code では、`npx skill add kenryu42/cc-safety-net` で個別に追加します。[インストール](/docs/ja/installation)を参照してください。

呼び出しに続けて書いた内容が、そのまま依頼になります。

```text theme={"dark"}
/cc-safety-net why was my last git command blocked
/cc-safety-net block terraform destroy in this project
```

## モデルが自分から起動することはありません

作業の途中でモデルがこのスキルを読み込むことはできません。エージェントの系統ごとに、次の 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 トレース](/docs/ja/reference/explain-trace)を参照してください。

**誤検知をトリアージする。** `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 を導入します。[カスタムルール](/docs/ja/configuration/custom-rules)と[公式 rulebook](/docs/ja/configuration/rulebooks)を参照してください。

**ポリシーを設定する。** 2 つの `policy.json` はどちらも保護対象です。スキルは提案し、適用するのはあなたです。保護されていないパスに提案ファイルを書き、`policy check` を実行して差分を提示します。そのうえで、自分のターミナルで実行する `policy apply` コマンドをそのまま渡します。`policy.json` のフィールドリファレンスを備えているため、提案では、安全レベルを設定し、レベルとは別に個別の機能を明示的に指定し、各保護を有効・無効に切り替え、組み込みルールを個別にオン・オフし、allow path と deny path の一覧を編集し、ユーザースコープでは監査ログの保持期間を設定できます。[ポリシー](/docs/ja/configuration/policy)を参照してください。

**連携を管理する。** まず `doctor` を実行し、検出・設定・検証の状況を確認します。`install --claude-code` のように対象フラグを明示してインストールし、完了後にもう一度 `doctor` を実行して、該当する行が verified になっていることを確かめます。フラグなしの `install` は対話的なピッカーを開くため、スキルはこれをあなたのターミナルに任せます。

**診断する。** `status` は、ランタイムが今何を強制しているかを示します。`rule list` が報告しない、`degraded` な `policy.json` も含みます。`doctor` はプラットフォームの検出と hook の設定を検証し、合成コマンドによるガードの自己テストを実行し、設定のスコープを確認します。カスタムルールが発火しない場合は、`rule verify`、`rule list` の順に実行し、そのうえで `explain` でコマンドを再テストします。[トラブルシューティング](/docs/ja/guides/troubleshooting)を参照してください。

**バージョンが一致するソースから答える。** 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 コマンド](/docs/ja/reference/cli-commands)を参照してください。

## コマンド文字列の扱い

ブロックされたコマンドは、シェルを通すと壊れやすい文字列であることが少なくありません。スキルはコマンド文字列やラッパー名を 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 を渡します。

<Note>
  スキルは `cc-safety-net rule doc` の出力を、rulebook のスキーマ、パス、GitHub の設定元、照合の挙動、検証についての完全な正としています。同じ内容は[カスタムルール](/docs/ja/configuration/custom-rules)にも記載しています。
</Note>