fable-method について
fable-methodは、複数段階のエンジニアリング作業や計画、監査に使う構造化スキルです。完了条件と証拠を定め、必要最小限の変更を行い、観察による検証後に結果を報告する手順を示します。
主な機能
- 01質問・作業・計画の分類
- 02完了条件と検証方法の定義
- 03変更前の証拠収集
- 04範囲を絞った最小限の変更
- 05観察に基づく結果検証
- 06結果を優先した報告
活用シーン
- 01範囲が曖昧なエンジニアリング作業の開始
- 02範囲が不明確な作業の計画
- 03ライフサイクル規則に沿った既存作業の監査
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ immamdouhaboammar/ get-fable --skill fable-methodインストール後、Claude Code で/fable-methodを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
skill.package.jsonagents/openai.yamlevals/scenarios.jsonreferences/examples.mdfailure-modes.mdflowcharts.mdreferences/domains/business-ops.mddata-analysis.mddesign-ux.mddevops.mdfinance.mdlegal-compliance.mdmarketing.mdresearch.mdTEMPLATE.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つのファイル内で完結し、変更が約10行未満で、新しい動作を追加せず、編集箇所も分かっている場合は、そのまま実行し、1つの確認で検証します。
- 適合性判定:答えの所在を判断します。到達可能なソースにある場合は実行ループに進み、未知の外部手法にある場合は先に調査し、推論でしか得られない場合は信頼度が低いことを明示します。
- ステップ 0 — 依頼を分類する:
- 質問/評価:調査結果を報告し、何も変更しません。
- タスク:実装して検証します。
- 先に計画:スコープが曖昧な場合、または操作を元に戻せない場合は、計画を提示し、承認を待ちます。
- ステップ 1 — 完了を定義する:完了の状態と、その検証方法を明確に宣言します。
- ステップ 2 — 根拠を集める:状態を変更する前に、ソースを開き、関連コードを読み、信頼できるドキュメントを確認します。
- ステップ 3 — 判断する:実行可能な最小限の計画を立てます。
- ステップ 4 — 必要最小限の操作を行う:他に影響を及ぼさず、必要な行だけを変更します。
- ステップ 5 — 観察によって検証する:コードを実行し、テストを実施し、副作用を観察します。
- ステップ 6 — 結果を最初に報告する:最初の文で結果を伝えます。
判断ルール
- 先に計画する優先ルール:元に戻せない操作、破壊的なコマンド、または曖昧なスコープが含まれる場合は、タスクの実行よりも先に計画を立てます。
- スコープ判定:範囲が限定された問題領域の外にあるファイルには触れません。
- 根拠判定:新たに取得した、合格を示す機械的な根拠を確認するまで、タスクは完了ではありません。
ツールの方針
- コンパイラー、リンター、テストランナーを実行するために、シェルコマンドを使用します。
- 対象を絞ったファイルの読み取り・編集ツールを使用します。
- コード以外のタスク(マーケティング、運用、財務、DevOps)に取り組む場合は、
references/domains/のドメインアダプターを参照します。
根拠の要件
- テストランナーまたはビルドツールからの、ターミナル出力そのもの。
- バグの仕組みと修正を裏付ける、ソースコードの行番号。
失敗への対応
- ステップが失敗した場合、同じ操作を闇雲に繰り返すのではなく、失敗の仕組みを診断します。
- 失敗が2回連続した場合は、直ちに
fable-recoverに引き継ぎます。
完了条件
- ステップ 1(「完了を定義する」)で定めたすべての条件が満たされていること。
- 新たに取得した、合格を示すテストの根拠があること。
- 余計な説明を加えず、結果を最初に伝える最終報告を行っていること。
コメント
Markdown 対応