fable-loop

The Fable Loop

このスキルは fable-method をオーケストレーションします。まず、その SKILL.md を読みます。そのルールがすべての段階を統括します。このスキルは、プラグイン内の skills/fable-method/ ディレクトリ、または手動でインストールする場合は ~/.claude/skills/fable-method/ にインストールされています。このメソッドが定めるのは何を確認するかです。このループが定めるのは誰が作業するかです。メインスレッドで何を実行し、サブエージェントに何を分担させ、納品前に何を攻撃させるかを定めます。

まずゲートを確認します。 メソッドの自明性ゲートで自明と判断される場合は、そのまま実行し、明らかな確認を1つ行って、2文で報告します。ステージもサブエージェントもありません。それ以外は、以下の4つのステージを順に進めます。

Stage 1 - PLAN（最初の区切り）

1. メソッドの Steps 0-3 を適用します。依頼を分類し、名前を付けた検証方法とともに完了条件を定義し、重要な前提を明示します。
2. 根拠の分担。 根拠を集めるサブエージェントは、必ず1つのメッセージで並行して起動します。順番に起動してはいけません。
   • コードベースに関する質問：領域ごとに Explore エージェントを起動します（「X はどのように動作するか」「Y に依存しているものは何か」など）。
   • ライブラリや事実に関する質問：最新のドキュメントを取得するか、ウェブを検索するリサーチエージェントを起動します。
   • 各サブエージェントは、生のファイルダンプではなく、引用を添えた要約済みの調査結果を返します。 予算は1バッチとフォローアップ1バッチです。3回目が必要な場合は、理由を明示します。
3. 計画の成果物を、次の形式で作成します。分類、完了条件とその検証方法、見つかった根拠（引用付き）、推奨するアプローチを1つ（却下した代替案はそれぞれ1行で記載）、作業範囲（変更が及ぶ正確なファイルまたは対象領域）、リスクと前提、実行チェックリスト。
4. 判断ゲート。 タスクの形が明確で、元に戻せる場合は、確認を求めず Stage 2 に進みます。まず計画を提示する形（作業範囲が曖昧、取り消せない操作や外部に影響する操作がある、またはユーザーが計画を求めている）の場合は、計画の成果物を提示して、承認を待ちます。

Stage 2 - EXECUTE

1. チェックリストはメインスレッドで進めます（環境に todo ツールがあれば使い、完了した項目にチェックを付けます）。判断と編集はメインスレッドで行い、分担するのは検索と検証だけです。
2. 編集ではすべて、メソッドの Step 4 に従います。動作を変更する前に意図ゲートを通し、未確認のものを初めて使う前に想起ゲートを通し、正しい範囲で最小限の変更を行い、正確に編集し、実物を確認せずに破壊しないでください。
3. 独立した機械的な作業項目（同じ変更を多数のファイルに適用する作業、分離したファイルの生成）は、並行するサブエージェントに分担できます。1つのメッセージで起動し、同じファイルに触れる可能性がある場合は worktree で分離します。
4. 実行中に予想外のことが起きた場合は、メソッドの Step 2 rule 7 に従って進め方を変更します。まずそのことを伝え、計画を更新するか Stage 1 に戻ります。予想外のことを無理に計画に押し込んではいけません。
5. 作業項目の途中で不明点が生じた場合、推測せずに一時停止します。編集に記憶頼みの事実（シグネチャ、キー、数値など）が含まれると分かった時点で、その項目を止め、メソッドの想起ゲートに従ってリサーチサブエージェントを1つ起動します。結果が戻ったら再開します。
6. 外部に影響するチェックリスト項目には、メソッドの承認ゲートを適用します。ユーザーからの引用可能な承認がなければ実行せず、その項目はレポート内の提案する次のステップに変更します。

Stage 3 - VERIFY（敵対的に検証）

1. 名前を付けた検証を、自分で両方実行します。完了条件を観測すること（実行、描画、計数）と、周辺システムが引き続き正常であること（変更箇所のビルド、テスト、lint）の両方です。
2. 影響の大きい変更では、攻撃役を起動します。 1～3個のサブエージェントを並行して起動し、それぞれ異なる観点から作業を反証するよう指示します。例：「この diff を読んで、変更が誤っているか不完全であることを証明する」「変更した動作を実行時に試し、破綻する入力を見つける」「この主張を仕様やドキュメントと照らし合わせ、矛盾を見つける」「変更全体を計画で宣言した範囲と比較し、その範囲外が変更されたことを証明する」。同じ観点のレビューを繰り返すより、異なる観点を用いるほうが効果的です。
3. 自分の確認を経ても残る指摘は、新たな作業として Stage 2 に戻します。メソッドに従い、上限は明確です。同じ問題の修正・検証サイクルが3回失敗した場合、または自分では制御できないブロッカーがある場合は、作業を止め、出力と仮説を添えて引き継ぎます。

ステージ 4 - 監査と報告（2 つ目の締めくくり）

1. fable-method の監査モードに従って自己監査します。各手順について、実施した、スキップした、または実施したふりをした、のいずれかを確認します。1 回の作業で修正できるもの（通常は未検証の主張）は修正します。今すぐ検証するか、注意事項としてラベルを付け直してください。
2. fable-method のステップ 6 に従って提出します。最初の文で結果を述べ、検証の根拠を示し、注意事項を正直に記し、作業を通じて明らかになった場合に限り、フォローアップを記載します。報告にはステージ名やステップ番号を含めません。報告に含めてよい手法上の要素は、INTENT と AUTH のみです。

このループを使用しない場合

• 些細なタスク（ゲートが処理します）。
• 複数の手順を伴わない単純な質問。形式には fable-method だけを使用します。
• すでに GSD フェーズ内でオーケストレーションされている場合。そのフェーズでは GSD がステージを管理します。ループを入れ子にするのではなく、その中で fable-method のルールを適用してください。

モデルの効率的な活用

このループは特定のモデルに依存しません。エビデンス収集や攻撃者役のサブエージェントは低コストのモデルでも対応できます。メインスレッド（判断と編集）では、利用できる最も高性能なモデルを使い、選択肢がある場合は、情報収集役よりも攻撃者役に多くの労力を割り当ててください。