juanmackie/juanskills

Fable Loop

このスキルはfable-methodをオーケストレーションします。最初にfable-methodのSKILL.mdを読んでください。そのルールがすべてのステージを統治します。このスキルはfable-methodと一緒にインストールされます（このプラグインの skills/fable-method/ ディレクトリ、または手動インストールの場合は ~/.claude/skills/fable-method/）。メソッドは「何を」チェックするかを定義し、このループは「誰が」作業を行うか（メインスレッドで何を実行するか、何をサブエージェントにファンアウトするか、納品前に何を攻撃するか）を定義します。

最初にゲート。

メソッドの自明性ゲートに従い自明なタスク：単に実行し、最も明白なチェックで検証し、2文で報告します。ステージもサブエージェントも不要です。それ以外は、以下の4つのステージを順に実行します。

ステージ1 - 計画（最初のブックエンド）

1. メソッドのステップ0〜3を適用します：依頼を分類し、名前付き検証で完了を定義し、負荷のかかる前提を述べます。
2. エビデンスファンアウト。 エビデンス収集者を並列サブエージェントとして1回のメッセージで、順次ではなく起動します：
   • コードベースに関する質問：異なる領域ごとに1つのExploreエージェント（「Xはどのように動作するか」「Yに依存しているものは何か」）
   • ライブラリや事実に関する質問：最新のドキュメントを取得したりウェブを検索するリサーチエージェント
   • 各サブエージェントは、生のファイルダンプではなく、引用付きの抽出された所見を返します
   • 1バッチ＋1フォローアップバッチが予算です。3回目には理由の表明が必要です
3. 計画成果物を以下の形で作成します：
   • 分類
   • 完了の定義とその検証方法
   • 発見されたエビデンス（引用付き）
   • 1つの推奨アプローチ（代替案はそれぞれ1行で却下）
   • スコープ（作業が触れる正確なファイルまたは面）
   • リスクと前提
   • 実行チェックリスト
4. 決定ゲート。
   • タスク型で可逆的：ステージ2に進む（許可を求めない）
   • 計画優先型（スコープが曖昧、不可逆的または外部向けのアクション、またはユーザーが計画を要求した場合）：計画成果物を提示し、承認のために停止します

ステージ2 - 実行

1. メインスレッドでチェックリストを作業します（ハーネスにtodoツールがあれば使用し、完了した項目をチェックします）。決定と編集はメインスレッドに留め、検索と検証のみをファンアウトします。
2. すべての編集はメソッドのステップ4に従います：動作変更前の意図ゲート、未開封のものを初めて使用する前の想起ゲート、最小限の正しい変更、正確な編集、確認せずに破壊しない。
3. 独立した機械的な項目（多数のファイルに対する同じ変更、独立したファイル生成）は、並列サブエージェントに、1回のメッセージで、同じファイルに触れる可能性がある場合はワークツリー分離を行って、ファンアウトすることができます。
4. 実行中の予期しない問題は、メソッドのステップ2ルール7に従ってルート変更します：それを述べ、計画を更新するかステージ1に戻ります。予期しない問題に対して計画を強行してはいけません。
5. 項目途中での無知は一時停止であり、推測ではありません：編集が記憶から事実（シグネチャ、キー、数値）を引き出そうとする瞬間、その項目を停止し、メソッドの想起ゲートに従って1つのリサーチサブエージェントをファンアウトし、戻ってきたら再開します。
6. 外部向けのチェックリスト項目は、メソッドの承認ゲートに従います：引用されたユーザーの承認なしにアクションは実行しない。項目はレポート内の次のステップの提案に変換されます。
7. ターン予算のチェックポイント。 長いイテレーションを最大50エージェントターンに制限します。各制限時に、チェックポイント成果物（完了した内容、エビデンスパス、正確な次のアクション）を書き、そこから再開します。最終検証がターン制限で殺されるステップであってはなりません。予算内で検証するか、チェックポイントで保留として明示的にマークします。

ステージ3 - 検証（敵対的に）

1. 自分で名前付き検証を実行します。完了基準の観察（実行、レンダリング、カウント）と、周辺システムの健全性（ビルド、テスト、影響範囲のリント）の両方です。

2. 重要な変更には、攻撃者を起動します。 1〜3の並列サブエージェントを、それぞれ異なるレンズから作業を反駁するようにプロンプトして起動します。例：

   • 「この差分を読み、変更が間違っているか不完全であることを証明せよ」
   • 「変更された動作を実行時に実行し、それを破壊する入力を発見せよ」
   • 「この主張を仕様/ドキュメントに対してチェックし、矛盾を発見せよ」
   • 「完全な変更セットを計画の宣言されたスコープと比較し、スコープ外で何かが変更されたことを証明せよ」

   異なるレンズは同一のレビュアーよりも優れています。

3. 自身のチェックを生き延びた所見は、新しい作業としてステージ2に戻ります。メソッドに従いハードバウンド：同じ問題に対する3回の失敗した修正-検証サイクル、または制御不能なブロッカーは、停止して、出力と仮説とともに手渡すことを意味します。

ステージ4 - 監査とレポート（2番目のブックエンド）

1. fable-method監査モードに従い自己監査：各メソッドステップについて、遵守、スキップ、または偽装。1パスで修正できるものは修正します（通常は未検証の主張：今すぐ検証するか、注意事項としてラベルを変更します）。
2. メソッドのステップ6に従い納品：最初の文で結果を、検証エビデンスを示し、正直な注意事項を、フォローアップは作業から生じた場合のみ。レポートにステージ名やステップ番号を含めません。INTENT行とAUTH行だけがレポートに含めることができるメソッド成果物です。

このループを使用すべきでない場合

• 自明なタスク（ゲートが処理します）
• マルチステップ作業のない純粋な質問：通常のfable-methodで対応可能です
• すでにオーケストレーションされたGSDフェーズ内：そこではGSDがステージを所有しているため、ループを入れ子にする代わりに、その中でfable-methodルールを適用します

モデル経済性

このループはモデルに依存しません。エビデンスおよび攻撃者サブエージェントは低コストモデルに適しています。メインスレッド（決定、編集）は利用可能な最強のモデルに維持し、選択肢がある場合は、攻撃者には収集者よりも高い努力レベルを与えてください。

使用法

/fable-loop <task>   完全なオーケストレーションループを実行します