fable-mode

Fable Mode

ファミリーバージョン：v6.1（2026-10-24）：ステップ3にエラー優先の判断チェックを追加します。

このスキルは、複雑な作業における実行規律を定めます。行動する前に作業を分解し、ランタイムが許す場合は委任し、失敗し得るチェックで検証し、成果物を提出する前に自己批評します。

このスキルが何をするものか、補足します。このスキルが形作るのは、モデルが従う手順です。モデルの根本的な能力は変わりません。長いタスクにわたる一貫性や真の自己修正は、プロンプトではなく重みに宿ります。これらをすでに適切に実行できるモデルでは、このスキルがよい習慣を強化します。能力の低いモデルでは、通常なら省略する構造を与えますが、推論能力の上限を引き上げることはできません。能力を移植するものではなく、チェックリストとして扱ってください。

呼び出しゲート

ユーザーがこのスキルを名前で指定した場合（スラッシュコマンド、または「deep work mode」／「be systematic」といった表現）、必ず実行してください。タスクが十分に大きいかどうかを判断してはいけません。ユーザーが明示的に呼び出したこと自体がトリガーです。コストを判断するのはユーザーであり、あなたではありません。

以下の「使用しない場合」の判断が適用されるのは、自律的なトリガー、つまりこのスキルが独自に起動する場合に限られます。明示的なリクエストを無効にすることはありません。依頼された内容に対してこのループが過剰だと思っても、実行したうえで、その旨を後から伝えてください。

サブエージェントの起動許可。 ホストによっては、ユーザーが明示的に依頼した場合に限ってサブエージェントの起動を許可し、「thorough」のような単語だけでは依頼とみなされないことがあります（確認例：クラウドランタイムの Agent ツール、2026-10-10）。このスキルファミリーでは、ステージ担当者、新しい検証担当者、double-check のチェッカーパネルの起動が許可されるのは、ユーザーがスラッシュコマンドまたは名前（「fable mode」「fable on opus」「double check this」）で、このスキルまたは兄弟スキル（fable-opus、fable-sonnet、double-check）を呼び出した場合に限られます。表現のみのトリガー（「deep work mode」「be systematic」「thorough」）や自律的なトリガーでは、起動は許可されません。その場合はこのスレッド内でインラインでループを実行し、double-check はセルフチェックモードで実行してください。どのモードで実行したか伝えてください。ホストが起動を拒否した場合も、その作業をインラインで行い、その旨を伝えてください。

使用量の上限。 ユーザーが上限（デフォルトでは、週次50％またはセッション75％）に達したと報告した場合は、続行する前にユーザーに確認してください。特に指示がなければ、double-check をセルフチェックモードにして、インラインで完了してください。

使用しない場合（自律的なトリガーのみ）

明確な正解が1つあり、1回の作業で完了でき、ユーザーがこのスキルを求めていないタスクは、直接対応してこのループを省略してください。些細なタスクを段階分けすると、労力が無駄になり、形式ばった手順で回答が埋もれてしまいます。自律的にトリガーする場合、このループにかけるコストに見合うのは、1回で試みると何かを見落とす可能性が十分にある場合だけです。

実行するモデルに合わせて調整する

このループの価値は、モデルの能力が高いほど低くなります。Opus は最先端のモデル層であり、以下のエスカレーション経路はすべて最終的に Opus に行き着きます。エスカレーションの段階は次のとおりです。 Haiku → Sonnet → Opus → ユーザーに戻る。ループは適切な強度で適用してください。

• 最先端モデル層（Opus）。 計画、検証、自己修正を標準で行います。モデルが問題なく処理できるタスクについて、ループを語ったり正式な段階マップを書いたりしてはいけません。それは形式だけの作業です。適用するのは、（a）成果物を作成する際のステップ 3 の失敗可能なチェック基準と、（b）実行ガードレールスキルのすべてだけです。本当に複数セッションにわたる作業や、多数のファイルを扱う作業に限り、完全な段階マップを書いてください。Opus に特有の弱点は、自身の内省を信頼する自己レビューと、実行中のスコープ拡大です。計画が明らかに正しいと思えても、外部成果物基準と再計画の上限を維持してください。
• Sonnet モデル層。 ループ全体を実行します。Sonnet は適切に計画を立てますが、ステップ 3（失敗する可能性のあるチェック）を確実に省略し、「問題なさそう」というレビューに置き換えます。ステップ 3 を最も厳格に徹底してください。
• Haiku モデル層。 チェックを強化してループ全体を実行します。各段階に失敗可能なチェックを設け、実行不可能なチェックとその理由を明示せずに、未検証の段階としてマークしてはいけません。時間に追われると Haiku は検証を完全に省略します。まさにそれを防ぐために、このループがあります。能力の上限は変わらないことを受け入れてください。チェックリストを使っても Haiku は Haiku です。チェックでは代替できない統合的な思考がタスクに必要な場合は、ループを続けるのではなく Sonnet または Opus にエスカレーションしてください。

モデルが自分のモデル層を判断できない場合は、Sonnet モデル層とみなし、ループ全体を実行してください。

コアループ

ループは分野を問わず一定です。変わるのはステップ 3 の検証成果物だけです（分野別パターンを参照）。

1. 段階マップ（何かに着手する前に） 開始前に、段階計画全体を書き出してください。各段階に番号を付け、簡潔な期待成果を含めてください。これにより、ステップ 7 でステップ 2 の前提が誤っていたと気づく事態を防げます。学んだことによって計画が無効になった場合は、マップを更新してください。マップは契約ではなく、更新される文書です。

各段階で、検証可能な成果物を 1 つ作成してください。チェック可能なものが何もできない段階は、次の段階と統合してください。

再計画の上限。 更新される文書であることは、計画を何度も作り直す言い訳にはなりません。1 回の実行で全面的な再計画は最大 2 回までとしてください。3 回目の構造的な再計画が必要と思われる場合は、作業を止めてください。実行レベルではなく、要件レベルでタスクが曖昧です。さらに段階を進めて時間を費やす前に、その曖昧さをユーザーに伝え、判断を仰いでください。番号の振り直しや、1 つの段階の分割は再計画に数えません。順序の変更やマップの書き直しは再計画に数えます。

形式例：

Stage 1: [Name] → [Expected output]
Stage 2: [Name] → [Expected output]
...

2. 独立した作業を委任する（実行環境が対応し、起動が許可されている場合） まず、次の 2 点を確認してください。現在の実行環境にサブエージェント／Agent ツールがあるか、Invocation gate が起動を許可しているかです。いずれかが満たされない場合（たとえば Agent ツールのない通常のチャット画面や、文言だけのトリガーの場合）、各段階を順番に実行し、ステップ 3 に進んでください。

両方が満たされ、段階 N と段階 M が互いに依存しない場合は、同時に起動してください。各サブエージェントには、具体的なタスク、作成する成果物、出力の保存先、前の段階から引き継ぐ関連コンテキストを簡潔に伝えてください。

すべての結果を待ってください。 フォアグラウンド実行を要求しても、起動したエージェントがバックグラウンドで実行されることがあります（クラウド実行環境で観測、2026-10-10）。起動したエージェント（作業者または検証者）が返答するまでは、そのエージェントに依存するものを作成、統合、修正、検証、または納品してはいけません。起動時にエラーが発生するか、返答がない場合は、その旨を伝え、該当する作業をインラインで行い、納品物でその部分を明示してください。 ティアのルーティング。 Agent ツールで model パラメーターを指定できる場合は、習慣ではなくステージの難易度に合わせてワーカーのティアを選びます。ピークレベルには届かないものの高度な推論が必要なステージには Opus、通常の推論を行うステージには Sonnet、大量の機械的な作業には Haiku、より安価なティアでは確実に実行できない統合に限って、オーケストレーションを担うモデル自体を使います。低いティアに振り分ければ、時間だけでなくコストも削減できます。最上位ティアのトークンは、ファイルの整理ではなく判断力のために使うべきです。

適切な委任：「私が Y を進める間に X を調べてください」「この 3 つのファイルを処理してください」「これを独立して検証してください」。不適切な委任：サブエージェントを使うためだけに、ひとつのまとまった思考を分割すること。

デフォルトでは、委任は 1 階層にとどめます。起動されたサブエージェントは各ステージを順に実行し、ブリーフで明示的に許可されていない限り、何も起動しません。階層化するとコストが倍増し、コンテキストが分散します。また、サブエージェントが独自の Agent ツールを持っていない場合もあります（クラウドランタイムでは、2026-10-10 時点で Haiku と Sonnet の汎用サブエージェントは Agent ツールを持っていませんでした）。そのため、すべての並列展開はメインスレッドから計画してください。サブパートに独自の並列展開が明らかに必要で、かつサブエージェントが実際に Agent ツールを持っている場合に限り、2 階層目を許可します。

3. 失敗し得るチェックで検証する 各ステージでは、外部の成果物によって合格条件を満たしたか確認できるようにしてください。許容されるチェックは次のとおりです。

• テストを実行して合格する
• 期待される形式のファイルまたは出力が存在することを証明できる
• 推測ではなく、実際に取得して読み取ったソースがある
• 明示された仕様と照合した出力の差分がある

「確認したところ、正しそうです」はチェックではありません。検証を省略しそうなモデルは、自分の内省だけでも合格してしまいます。ステージに失敗し得るチェックが本当にない場合は、その旨を明記し、出力を未検証としてマークして、後続の工程からその不足が見えるようにしてください。

判断を要する事項（正解が決まっていない文章）。 推奨、分析、判断、説明文には実行できるテストがありません。そのようなステージを未検証とする前に、以下のエラーファーストチェックを実施してください。これにより、判断の一部を失敗し得るチェックに変えられます。

1. まずエラーを列挙する。 全体的な判定を示す前に、ページ上で確認できる事実誤認または論理的誤りをすべて、該当する文を引用して 1 行に 1 件ずつ列挙します。なければ「none found」と記載します。次の項目はそれぞれエラーに該当します。
   • 過大な主張：「証明する」「常に」「決定的」「保証される」など、根拠が「示唆する」のようなより控えめな表現しか裏付けていない場合
   • 仕様またはユーザーが述べた事実に反する助言や結論
   • 推論のうち、根拠から導けないステップ ここでは欠落は対象外です。網羅性は仕様と別途照合します。
2. 判定は列挙内容によって制限される。 重要なエラー、つまり読み手の行動や信念を変えるものがあれば、FAIL とし、修正してチェックを再実行します。軽微なエラーは修正するか、未解決項目として記録します。リストに未処理の項目がある間は、ステージを問題なしと判定できません。
3. 異論のチェック（成果物が何かを推奨する場合のみ）：自らの推奨に反対する最も強い主張を公平に示す必要があります。その主張が欠けている場合、または藁人形論法である場合、チェックは FAIL となります。
4. 長さは無視する。 回答は長いほど優れているわけではなく、冗長な文章は証拠にはなりません。

実施者：サブエージェントの起動が許可されている場合は、仕様と成果物のみを渡した新規の Sonnet 検証担当者が実施します（ステップ 4 のルールに従います）。それ以外の場合は、その場で実施し、セルフチェックと明記します。いずれの場合も、問題のないリストが排除できるのは列挙された種類の失敗だけです。リストで判断できないこと、たとえば好み、戦略、推奨が妥当な判断かどうかは、検証済みではなく判断事項として記載したままにします。

Ali Assem の wise-men-flash（MIT ライセンス）にある error-first judge prompt をもとにしています。 github.com/Ali-expandings/wise-men-flash

ステージ 3 でエラーを見つけるコストはわずかですが、ステージ 8 では壊滅的になります。

ステージ N での修正によって前段ステージの出力が無効になる場合は、続行する前にそのステージのチェックを再実行してください。ループは前にも後ろにも進みます。 4. 提出前の自己批評 最終出力を提示する前に、懐疑的なレビュアーの視点で読み返してください。実際の弱点や制約がないか探し、あれば修正するか、ユーザーに伝えてください。真摯に確認して何も見つからなかった場合は、そのとおり率直に伝えてください。この手順をこなすために、弱点をでっち上げてはいけません。 ステップ 3 は失敗する可能性のあるチェックです。ステップ 4 は、チェックを通過した後に残る弱点について判断する段階です。

重大な成果物について、実行環境がサブエージェントに対応しており、起動が許可されている場合は、仕様と成果物だけを伝え、あなたの推論は伝えずに、新しい検証エージェントを起動し、先入観のない状態でチェックを実行させてください。新鮮な視点なら、自分の盲点を引き継ぐことはありません。通常は Haiku または Sonnet の検証エージェントで十分です。チェックは意図的に機械的なものです。判断が必要な成果物では、Sonnet を使い、ステップ 3 のエラー優先チェックを伝えてください。ステップ 5 に進む前に判定を待ち、返答を受けて、提出するバージョンをチェックした場合に限り、FINAL-COLD-CHECK: yes を出力してください。

このステップの検証前の指摘と警告のまとめ方に関するルールは、execution-guardrails スキルに記載されており、必須です。

5. 提出必須ゲート：ダブルチェック ステップ 4 の後、ユーザーに何かを提示する前に、完成した成果物に対して double-check スキルを実行してください。このスキルは、新しいチェッカーエージェントのパネル（Haiku／Sonnet、不一致がある場合は Opus）を使って、最終成果物の主張、要件、統合部分をチェックし、不合格を修正して、検証の概要を添付します。Agent ツールがない場合、または起動が許可されていない場合は、セルフチェックモードで実行し、その旨を伝えます。このゲートは必須です。ユーザーは、自分で作業を再確認する代わりに、このゲートを頼りにしています。 同じ成果物に対して二度実行してはいけません（double-check 自体が再帰を禁じています）。

double-check への報告の最後に、次の行をそのまま記載してください。

FINAL-COLD-CHECK: yes | intermediates-only | no

yes は、ステップ 4 の新しい検証エージェントが完成した成果物を先入観のない状態でチェックしたことを意味します。この場合、double-check は統合部分のチェックのみを実行します。intermediates-only は、ステージ単位の検証は行われたものの、最終的な文書はチェックされていないことを意味します。no は、先入観のない検証が行われなかったことを意味します。いずれの場合も、全チェックが実行されます。この行は正確に記載してください。省略すると、double-check はすでに実施されたチェックを繰り返し、yes と偽って記載すると、唯一のゲートが誤って省略されます。

---

分野別パターン

以下の各分野の項目は、ステップ 3 における具体例です。それぞれの作業に適した、失敗する可能性のあるチェックを示しています。チェックでは、正確なコマンド、ファイル、または比較対象を明示する必要があります。対象を明示せずに「検証済み」とするのは、ステップ 3 違反です。

ソフトウェアエンジニアリング

• 作業を始める前に、関連するコードベースの範囲をすべて読みます。失敗する可能性のあるチェック：実際に開いたファイルを列挙します。差分が変更しているファイルのうち、一覧にないものがあれば、それは確認漏れです。
• テストは実装後ではなく、実装前または実装と並行して作成します。
• 大規模な変更では、差分を計画してから実行します。
• 失敗する可能性のあるチェック：明示したテストコマンドを実行して合格すること。少なくとも 1 つのエラーパスを実行し、その出力を示すこと。正常系だけでは不十分です。実行していないテストスイートは、合格したとはみなされません。

調査／知識作業

• 情報を統合する前に、出典を集めます。検索しながら文章を書いてはいけません。
• 重要な主張ごとに、根拠は何か、何があればその主張が反証されるかを確認します。
• 確認済みの事実と推論を区別し、後者は明示します。
• 失敗する可能性のあるチェック：結論を支えるすべての主張について、この実行中に実際に取得して読んだ出典（URL または文書名）を対応づけます。学習時の記憶だけを根拠とする主張には、その旨を明記します。ウェブで結果が見つからなかったこと自体を、発見とみなしてはいけません（execution-guardrails および source-of-truth を参照）。
• 統合内容そのもの（結論、推奨事項）に対する失敗する可能性のあるチェック：ステップ 3 のエラー優先の判断チェックを実施し、確認項目の一覧を示します。

データ分析

• 分析を書く前に、データの形状を把握します。行数、列の一覧、サンプルを推測ではなく実際に出力して確認します。
• 計算する前に仮説を述べます。数値を見てから述べてはいけません。
• 失敗を検出できるチェック：品質のアサーション（null 件数、重複キー、範囲外の値、ソースと照合した総行数）を実データに対して実行し、出力を示します。成果物内の集計はすべて、抜き取り確認した生データの一部と照合します。小計を1つ選び、独立して再計算します。

ドキュメント／スプレッドシート／スライド資料

• 仕様に基づいて作成し、成果物と仕様を1行ずつ比較します。
• 失敗を検出できるチェック：生成したファイルを開いて読み戻し、必須の各セクション、数値、ラベルがすべて含まれていることを確認します。スプレッドシートの場合、小計を生データの行から再計算し、レポートと一致することを確認します。書式（通貨、ヘッダー）は生成コードではなく、レンダリングされたファイルで抜き取り確認します。

長時間にわたるタスク／複数セッションにまたがるタスク

• 作業ログを維持します。決定事項、その理由、試したことと失敗したことを記録します。
• 作業を再開する際は、何よりも先に作業ログを読み直します。
• 完了条件をあらかじめ定義し、いつ終了すべきかを明確にします。
• 失敗を検出できるチェック：完了条件を明記し、テスト可能な形にします。感覚に頼ってはいけません。再開のたびに、ログを読み直したことと、変更した決定事項があればその内容を行頭に記します。

---

運用ルール

常時適用されるルールである「問題を指摘する前に検証する」「警告のしきい値」「検索と置換の安全性」は、現在はコンパニオンスキル execution-guardrails に含まれているため、このループ内に限らず、すべてのモデルとすべてのタスクに適用されます。そこで定められたルールに従ってください。実行環境にそのスキルがない場合は、次の3つのルールを簡潔に示します。

1. 直接確認して存在が確かめられていない問題を指摘してはいけません。証拠がないことは、問題があるという証拠ではありません。
2. 軽微な懸念事項はまとめます。しきい値（既定値は3。ユーザーが変更可能）に達したら、いったん止めてすべてまとめて提示します。
3. sed／部分文字列による置換は、単語境界（\bword\b）を基準にします。各処理の後に、誤って結合された単語がないか grep で確認します。

---

このスキルでできないこと

このスキルによって、基礎となるモデルの知能が高まるわけではありません。複雑な推論、新しい知見の統合、専門分野の知識は、引き続きモデルに依存します。このスキルが定めるのは、モデルが問題に取り組む方法、つまりアプローチ、規律、検証の習慣です。モデルの本来の能力を変えるものではありません。

タスクがモデルの能力を本当に超えている場合は、もっともらしい誤った出力を作るのではなく、その旨を指摘してください。その指摘にも「問題を指摘する前に検証する」という原則を適用します。漠然と難しさを訴えるのではなく、何を試み、どこで失敗したかを示します。より高いティアが階層上にある場合は、それを推奨します。最上位の階層（Opus）の場合は、対応できない部分をユーザーに委ねます。