freeze

freeze skill の概要

freeze skill が何をするか

freeze は、セッション中のファイル編集を1つのディレクトリに制限するガードレール系の skill です。許可されたパスの外では Edit と Write をブロックするため、ワークフロー自動化エージェントをモジュール単位、機能フォルダ単位、あるいはデバッグ用サンドボックス内に閉じ込めたいときに役立ちます。freeze skill を使って、うっかり広範囲を変更されるのを防ぎたいなら、まさに適した選択です。

どんな人に向いているか

エージェントに、狭い範囲のコードをデバッグ、リファクタリング、パッチ適用させることが多く、「親切心で」関係ないファイルまで触られるのを避けたいなら、freeze を入れる価値があります。特に、保守担当者、レビュー担当者、そして編集範囲の明確さが広い自律性より重要な、混在したコードベースやリスクの高いコードベースで作業する人に向いています。

何が違うのか

最大の違いは、単なる指示ではなく強制である点です。freeze は pre-tool hook を使って、選んだディレクトリの外への編集を拒否します。これは、モデルに「集中して」とお願いするだけのプロンプトよりも強力です。そのため、freeze guide は実際の囲い込みに向いており、特に少しの逸脱が高くつくセッションで実用的です。

freeze skill の使い方

インストールして境界を初期化する

freeze install では、まずリポジトリの skill manager でこの skill を環境に追加し、そのうえで固定したいディレクトリを選びます。許可パスはセッションごとに変わるため、セットアップは対話式です。実際には、「どのディレクトリを freeze するか?」と聞かれたら、「backend 付近」ではなく、正確なパスで答えられるようにしておくべきです。

まず読むべきファイル

最初に SKILL.md を読んで制御フローを把握し、次に bin/check-freeze.sh を見て境界がどう強制されるかを確認してください。skill を調整するなら、生成される構造を理解するために SKILL.md.tmpl も確認します。これらのファイルを見ると、freeze の使い方で実際に何が許可され、何がブロックされるのか、そしてどこでパス解析が失敗したり寛容になったりするのかが分かります。

skill に正確なプロンプトを与える

最適なのは、焦点の定まった作業内容と明確な境界をセットで渡すことです。たとえば、「apps/payments の編集を freeze して、shared libraries は変更せずに、その中の failing unit tests を直してください」のように伝えます。これは「この app をデバッグして」よりずっと良い依頼です。なぜなら、freeze には対象ディレクトリと、その中で完結するタスクが必要だからです。スコープが具体的であるほど、エージェントが例外を求める可能性は下がります。

実務上のワークフローのコツ

freeze は、最初の1回を外科手術のように進めたいときに使うのが効果的です。つまり、バグを特定し、1つのフォルダ内で修正し、スコープを広げずに検証する、という流れです。もし本当にディレクトリ横断の変更が必要なら、無理に freeze に押し込まないでください。許可パスを広げるか、別のワークフローを使うべきです。この skill が最も力を発揮するのは、要求された変更セットが自然に境界づけられていて、リポジトリ構成も明快なときです。

freeze skill のFAQ

freeze はデバッグ専用ですか?

いいえ。デバッグはよくある用途ですが、freeze skill は制約付きのリファクタリング、機能の切り分け、レビューで安全な編集にも役立ちます。重要なのは、作業中にエージェントを1つのディレクトリ内に留めたいかどうかです。

通常のプロンプトと何が違いますか?

通常のプロンプトは、モデルが指示に従うことを前提にしています。freeze は hook による強制があるため、範囲外の編集はモデルが試みてもブロックされます。そのため、ガードレールが重要な Workflow Automation のジョブでは、より信頼性が高くなります。

freeze は初心者向けですか?

はい、ユーザーがディレクトリを自信を持って指定できるなら向いています。初心者がやりがちなミスは、境界を広くしすぎるか、逆に狭くしすぎることです。ディレクトリが曖昧だと、スコープ確認のためにセッションが止まることがあります。

どんなときに freeze を使うべきではありませんか?

複数のモジュール、共有設定、あるいはリポジトリ全体の整形にまたがる作業では使わないでください。そうしたケースでは、制限が作業を遅らせたり、不要なブロックを引き起こしたりします。freeze が向いているのは、単なる好みではなく、本当に境界を決める必要があるときです。

freeze skill を改善する方法

境界を明示する

品質を最も大きく上げるのは、正確なディレクトリ名と期待する成果をセットで伝えることです。良い入力例は、「services/auth の編集を freeze して、shared/ には触れずに token refresh flow を更新してください」です。逆に「auth を直して」のような弱い依頼では推測が増え、ブロックや中途半端な編集が起きやすくなります。

ファイル、症状、制約を添える

freeze skill をうまく使うには、失敗しているファイル、観測された挙動、そして変更禁止のファイルを含めると効果的です。たとえば、「apps/admin だけを編集してください。バグは src/table.ts にあります。API contracts は変更しないでください。」という形です。これにより、エージェントは凍結された範囲の中に留まりながら、実際の問題を解決しやすくなります。

境界の不一致に注意する

最もよくある失敗は、タスクが実は frozen directory より広いスコープを必要としているのに、それを最初は見抜けないことです。エージェントが denied writes に繰り返し当たるなら、対処法はたいてい境界を広げるか、タスクを段階に分けることです。これはバグではなく、むしろ機能です。freeze は、計画とスコープが一致していないことを教えてくれています。

1回目の結果を踏まえて反復する

最初の出力を見たら、解決策が frozen path の外側にある前提に依存していなかったか確認してください。依存していた場合は、対象ディレクトリ、許可するファイルタイプ、触ってはいけないものを1つか2つ具体的に追加して、プロンプトを引き締めます。freeze skill で最良の結果を出すには、創造性を増やすのではなく、スコープを明確化して反復することが大切です。