mcpField
F
fable-method

fable-method

github.com/immamdouhaboammarエージェントワークフロー355 回インストール1 週間前に更新
リポジトリ

fable-method について

fable-methodは、複数段階のエンジニアリング作業や計画、監査に使う構造化スキルです。完了条件と証拠を定め、必要最小限の変更を行い、観察による検証後に結果を報告する手順を示します。

主な機能

  1. 01質問・作業・計画の分類
  2. 02完了条件と検証方法の定義
  3. 03変更前の証拠収集
  4. 04範囲を絞った最小限の変更
  5. 05観察に基づく結果検証
  6. 06結果を優先した報告

活用シーン

  1. 01範囲が曖昧なエンジニアリング作業の開始
  2. 02範囲が不明確な作業の計画
  3. 03ライフサイクル規則に沿った既存作業の監査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/immamdouhaboammar/get-fable --skill fable-method

インストール後、Claude Code で/fable-methodを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

skill.package.json
agents/
openai.yaml
evals/
scenarios.json
references/
examples.md
failure-modes.md
flowcharts.md
references/domains/
business-ops.md
data-analysis.md
design-ux.md
devops.md
finance.md
legal-compliance.md
marketing.md
research.md
TEMPLATE.md

詳細

The Fable Method

このループに従う中堅モデルは、自由に回答するよりも強力なモデルを上回ります。品質を左右するのはモデルではなく、構造、根拠、誠実さです。このループはそれだけで完結しています。記載どおりに実行してください。

目的

あらゆる種類の問題に対応する、普遍的で規律あるエンジニアリングループを提供します。依頼を分類し、完了の定義を明確にし、根拠を集め、判断し、必要最小限の変更を行い、観察によって検証し、結果を最初に報告します。

使用する場合

  • ユーザーが Fable Method を明示的に依頼した場合(/fable-method、「Fable のように取り組んで」)。
  • 専門の担当が事前に割り当てられていない、曖昧で複数段階にわたるエンジニアリングタスクを開始するとき。
  • 構造化された計画を実行するとき(/fable-method plan <task>)。
  • 既存の会話で行われた作業を、ライフサイクルの不変条件に照らして監査するとき(/fable-method audit)。

使用しない場合

  • 変更内容が明白で自己完結している、簡単な1行の編集(そのまま実行します)。
  • 完全に自律的なバックグラウンドでのロングポーリングやテストループ(fable-loop を使用します)。
  • 複数ホストへのインストールやセットアップ手順(fable-release またはインストーラーを使用します)。

入力

  • task_description:問題のプロンプト、仕様、またはバグ報告です。
  • domain_adapter:コード以外の分野向けの任意のセクターアダプター(references/domains/*)です。

期待される出力

  • verified_solution:仕様に合致する、必要最小限の実装変更です。
  • execution_evidence:意図どおりにソリューションが機能することを示す、観察可能な根拠です。

手順

  1. 簡易タスク判定:タスクが1つのファイル内で完結し、変更が約10行未満で、新しい動作を追加せず、編集箇所も分かっている場合は、そのまま実行し、1つの確認で検証します。
  2. 適合性判定:答えの所在を判断します。到達可能なソースにある場合は実行ループに進み、未知の外部手法にある場合は先に調査し、推論でしか得られない場合は信頼度が低いことを明示します。
  3. ステップ 0 — 依頼を分類する:
    • 質問/評価:調査結果を報告し、何も変更しません。
    • タスク:実装して検証します。
    • 先に計画:スコープが曖昧な場合、または操作を元に戻せない場合は、計画を提示し、承認を待ちます。
  4. ステップ 1 — 完了を定義する:完了の状態と、その検証方法を明確に宣言します。
  5. ステップ 2 — 根拠を集める:状態を変更する前に、ソースを開き、関連コードを読み、信頼できるドキュメントを確認します。
  6. ステップ 3 — 判断する:実行可能な最小限の計画を立てます。
  7. ステップ 4 — 必要最小限の操作を行う:他に影響を及ぼさず、必要な行だけを変更します。
  8. ステップ 5 — 観察によって検証する:コードを実行し、テストを実施し、副作用を観察します。
  9. ステップ 6 — 結果を最初に報告する:最初の文で結果を伝えます。

判断ルール

  • 先に計画する優先ルール:元に戻せない操作、破壊的なコマンド、または曖昧なスコープが含まれる場合は、タスクの実行よりも先に計画を立てます。
  • スコープ判定:範囲が限定された問題領域の外にあるファイルには触れません。
  • 根拠判定:新たに取得した、合格を示す機械的な根拠を確認するまで、タスクは完了ではありません。

ツールの方針

  • コンパイラー、リンター、テストランナーを実行するために、シェルコマンドを使用します。
  • 対象を絞ったファイルの読み取り・編集ツールを使用します。
  • コード以外のタスク(マーケティング、運用、財務、DevOps)に取り組む場合は、references/domains/ のドメインアダプターを参照します。

根拠の要件

  • テストランナーまたはビルドツールからの、ターミナル出力そのもの。
  • バグの仕組みと修正を裏付ける、ソースコードの行番号。

失敗への対応

  • ステップが失敗した場合、同じ操作を闇雲に繰り返すのではなく、失敗の仕組みを診断します。
  • 失敗が2回連続した場合は、直ちに fable-recover に引き継ぎます。

完了条件

  • ステップ 1(「完了を定義する」)で定めたすべての条件が満たされていること。
  • 新たに取得した、合格を示すテストの根拠があること。
  • 余計な説明を加えず、結果を最初に伝える最終報告を行っていること。

コメント