プルリクエストではなく Issue を作成する
検出ルール、設定の変更、ドキュメントの訂正、小さなバグ修正も、すべて Issue から始めます。提案が受け入れられても、それだけでプルリクエストが認められるわけではありません。メンテナーはコーディングエージェントを使って修正を実装しているため、依頼のないパッチより、再現手順を添えた詳細な Issue のほうが早く問題を解決できます。 CC Safety Net が目指すのは 1 つだけです。rm -rf ~/ や git reset --hard のように、コーディングエージェントのうっかりした誤操作でデータが失われるのを防ぐことです。汎用のセキュリティ強化ツールや攻撃防止ツールではありません。
バグを報告する
Issue のほとんどはコーディングエージェントが書いています。ソースリポジトリのAGENTS.md は、Issue を作成する前に CONTRIBUTING.md を読むようエージェントに指示しています。エージェントでも人でも、次のルールに従ってください。
- まず既存の Issue を検索してください（
gh issue list --search "<keywords>" --state all）。すでに報告されている問題なら、新しい Issue を立てずに、その Issue に新たな根拠を追加してください。 - 1 つの Issue で報告する問題は 1 件だけにしてください。
- 問題は最新リリースで再現してください。書くのは実際に実行した再現手順だけです。実行できなかった場合はそう明記してください。
- 冒頭に問題と根拠を書いてください。何をして、何を期待し、何が起きたかです。報告は簡潔にまとめてください。
- CC Safety Net のバージョン、OS、コーディングエージェントまたは CLI とそのバージョン、CC Safety Net のインストール方法を記載してください。
npx cc-safety-net doctor --jsonでほとんどが揃い、カスタムルールが関係しているかどうかも分かります。 - 原因の分析は歓迎します。根拠の後ろに置き、テストやトレースで確認できていない場合は仮説と明記してください。
- パッチや差分は添付しないでください。提案する修正は文章で説明してください。
- 提出する前に、作業を依頼した人に Issue を確認してもらってください。
- コマンド全体。マッチしたセグメントだけでなく、チェーン全体を記載してください。
- 作業ディレクトリと安全レベル。
npx cc-safety-net explain --cwd <dir> "<command>"の出力。- すでに起きたブロックについては、
npx cc-safety-net logsのエントリ（npx cc-safety-net logs --id <id> --json）。 - 判定がどうあるべきだったか、その理由。
<project> と ~ に置き換え、コマンドが再現できるようにパスの構造は残してください。
機能を要望する
解決したい問題、望む挙動、それが役立つ具体的な場面を説明してください。上記のルールも当てはまります。まず検索すること、1 つの Issue で扱う要望は 1 件だけにすること、パッチを添付しないことです。CC Safety Net を開発する
開発環境のセットアップ、bun run check によるチェック、ローカルプラグインのテスト、コード規約、招待されたコラボレーター向けのプルリクエストの手順は、ソースリポジトリの CONTRIBUTING.md にあります。