crear-guardrail

ガードレールの作成

目標

ルール（「誰も main に push しない」）を、使用中のエージェントにネイティブに設定された、環境の実際の制限に変換します。このスキルにはエージェントごとの手順は含まれません。エージェントが最新のドキュメントを参照して、自ら設定する方法を学ぶための手順が含まれています。

入力

• 適用するルール（自然言語）。複数のエージェントに共通するガードレールの例：
  • メインブランチへの git push と git push --force をブロックする；
  • プロジェクト外のファイルシステムに対する破壊的なコマンドをブロックする；
  • デプロイやリモートサービスへの書き込みの前に、確認を求める；
  • シークレットファイル（.env など）の読み取りや書き込みを禁止する。
• 任意：プロジェクト単位（チーム全体）で適用するか、ユーザー単位で適用するか。

ルールが明確でない場合（どの操作か、どのような例外があるか）は、先に質問してください。

ワークフロー

1. このセッションで実行中のエージェントを特定する（エージェント自体の識別情報、環境変数、またはプロジェクト内に存在する設定ファイルを使用）。一行でユーザーに伝えてください。

2. そのエージェントのフック、権限、ポリシーに関する最新の公式ドキュメントを確認する。references/puntos-de-partida.md は出発点としてのみ使用してください。現在のドキュメントと異なる場合は、現在のドキュメントを優先します。エージェントがウェブにアクセスできない場合は、その旨を伝え、ドキュメントのリンクまたは該当箇所をユーザーに求めてください。

3. ルールを適用できる、最もシンプルな仕組みを選択する：

   • エージェントに十分な宣言型の権限（allow／deny／ask）がある場合は、それを使用する；
   • 不十分な場合は、該当するイベント（例：コマンドの実行前）に対するフックを使用する；
   • エージェントに仕組みがない場合は、その旨を明示し、最も脆弱でない代替案を提案する（さらに、ルールを AGENTS.md にも記載する）。

4. 何も書き込む前に、ガードレールをユーザーに提案する：

   • どのイベントが起動条件になるか；
   • 何をブロックし、確認を求め、または実行するか；
   • どの設定ファイルに、どの適用範囲（プロジェクト／ユーザー）で設定するか；
   • 誤ってブロックする可能性があるもの（誤検知）。 明示的な承認を待ってください。

5. 既存の設定を削除せずに、エージェントのネイティブな設定ファイルで設定する。

6. イベントを安全な方法で発生させてテストする（例：テストブランチでの main への git push、またはシミュレーションモード）。ガードレールが機能したことをユーザーに示してください。機能しなかった場合は、完了とする前に修正してください。

7. AGENTS.md の ## Guardrails セクションに記録する：ルール、仕組み、設定ファイルの場所、テスト方法。これにより、チームの他のメンバー（人間またはエージェント）がガードレールの存在を把握できます。

制約

• ユーザーが承認していないものはインストールしません。
• 新しいガードレールを作成するために、既存のガードレールを無効にしません。
• テストしていないガードレールは、作成済みとみなしません。
• エージェントがルールを適用できない場合は、その旨を伝えます。ルールは文章として記載されるだけであり、実際には機能しないガードレールです。