guard

guard skill の概要

guard の役割

guard skill は Workflow Automation のためのフル安全モードです。破壊的コマンドの警告と、ディレクトリ単位の編集制限を組み合わせています。実際には、rm -rf、force-push、許可されたフォルダ外への想定外の書き込みなど、危険な操作の直前で agent を止めるのに役立ちます。

どんな人に向いているか

本番環境、ライブデータ、あるいは範囲が厳密に区切られたコード領域の近くで作業し、agent にデフォルトで慎重に動いてほしい場合は guard を導入してください。特に、「guard mode」「maximum safety」「lock it down」のような振る舞いを、汎用的な prompt だけに頼らず実現したいときに有効です。

何が優れているのか

guard は単なる注意喚起ではありません。hook を使って tool 使用時に安全チェックを強制するため、制約が会話上のお願いではなく運用上のルールになります。Workflow Automation に対して、一度きりの警告ではなく、再現性のあるガードレールが必要な場合により適しています。

guard skill の使い方

インストールと依存関係の確認

まず親スタックに対する guard のインストール手順を実行し、そのうえで補助 skill がそろっているか確認してください。guard は、hook が両方の script を呼び出すため、兄弟ディレクトリの /careful と /freeze に依存します。これらが欠けていると、安全チェックは意図どおりに動きません。

agent に範囲を限定したタスクを与える

guard をうまく使うには、まずスコープを明確にします。たとえば、「services/api/ の中だけで deployment script を更新し、破壊的コマンドの前には警告してほしい」といった形です。ディレクトリ境界、変更の種類、求める慎重さのレベルを含めることで、skill が適切な制限をかけるための文脈がそろいます。

先に読むべきファイル

最初に読むのは SKILL.md と SKILL.md.tmpl です。前者には実際の挙動が書かれており、後者は生成される skill がどう組み立てられるかを理解する助けになります。この repo には guard フォルダ内に追加ルール、参照ファイル、補助 script がないため、この 2 つが主な正本です。

うまく機能する prompt の形

よい依頼は、やることと安全要件の両方を具体的に書きます。たとえば、「Workflow Automation で guard を使い、infra/prod/ だけを編集し、破壊的な Bash command の前には警告し、フォルダ外へ書き込みが発生しそうなら停止してほしい」といった形です。これなら「気をつけて」とだけ伝えるよりも、境界と期待動作が明確になります。

guard skill の FAQ

guard は上級者向けだけですか？

いいえ、ただしミスの代償が大きい場面で特に価値があります。初心者でも、安全用のラッパーとして使えます。特に、ある command や edit が危険かどうか自信がないときに有効です。

guard は通常の prompt と何が違いますか？

通常の prompt でも慎重さを求めることはできますが、guard は hook によってチェックを強制します。agent に危険な操作を「説明」してもらうだけでなく、実際に「止める」ことが必要なときに、この違いが重要です。

どんなときに guard を使わないほうがいいですか？

複数の folder にまたがる広範な探索的編集が必要な場合、または意図的に破壊的で、すでにレビュー済みの作業であれば guard は使わないでください。ディレクトリ単位の制御は、厳密な境界が不要な作業では、かえって速度を落とすことがあります。

使っている最中は何が起こりますか？

破壊的 command の前には警告が出て、許可された directory の外にある edit や write にはチェックが入ると考えてください。タスクが設定された境界の外にある場合、workflow はそのまま進まず、一時停止します。

guard skill の改善方法

実行前にスコープを絞る

最も効果が大きいのは、正確な directory、file、そして望む結果を指定することです。たとえば「apps/web/src/ の中だけで auth migration を修正してほしい」と伝えるほうが、「app をより安全にしてほしい」よりも成果が良くなります。skill が適切な freeze 境界を適用できるからです。

安全な変更と危険な変更を分ける

workflow に通常の edit と危険な操作の両方が含まれるなら、agent に別々に段階化して依頼してください。たとえば、まずは読み取り専用の確認と計画を依頼し、次に最小限の write set を承認し、破壊的な操作は確認後にだけ実行する、という流れです。こうすると guard skill の挙動を検証しやすくなります。

境界の不一致に注意する

よくある失敗は、広すぎる task 説明が freeze scope と食い違うことです。agent が何度も停止するなら、対象 path を狭めるか、保護対象に含まれる file が明確になるよう request を書き直してください。

明示的な guardrail で反復する

初回実行のあと、守りたい command、folder、失敗条件を具体的に絞り込んで prompt を調整してください。guard の使い方は反復が前提です。制限と承認ルールを具体的にするほど、skill 側の推測は減り、automation はより安定します。