mcpField
F
fable-execute

fable-execute

github.com/immamdouhaboammar開発355 回インストール1 週間前に更新
リポジトリ

fable-execute について

fable-executeは、承認済みで範囲が定まった変更カードを実装するエージェント向けの開発スキルです。動作を満たす最小限の差分と即時の受け入れ確認を重視し、新事実で前提が崩れた場合は停止して再計画します。

主な機能

  1. 01範囲とワークスペース状態の再確認
  2. 02変更種別ごとの実装上の懸念を分類
  3. 03動作を満たす最小限の変更
  4. 04変更後すぐに受け入れ確認
  5. 05失敗を分類してから次の編集を判断
  6. 06差分を整理して独立検証へ引き継ぎ

活用シーン

  1. 01設計が確定した範囲内の変更実装
  2. 02TDDが有効でない静的設定や文書の変更
  3. 03有効なREDテストに基づく動作実装
  4. 04レビュー指摘の修正と影響範囲の確認

インストール

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

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

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

同梱ファイル

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

skill.package.json
agents/
openai.yaml
evals/
scenarios.json
examples/
bounded-card-execution.md
references/
bounded-mutation-and-failure-classification.md
mutation-containment.md
templates/
execution-receipt.template.md

詳細

Fable Execute

レビュー不能な、際限なく続くセッションにせず、受け入れ済みの変更を1つ実装します。

ミッション

実行フェーズの責務は実装であり、アーキテクチャの調査ではありません。エージェントは、受け入れ済みのカードを満たす最小限で一貫性のある変更を行い、不変条件を明確に保ち、すぐに検証して、新たな事実によって計画が無効になった時点で停止します。

「最小限」とは、振る舞いとして完全な差分が最小であることを意味し、必ずしも変更行数が最少であることではありません。

使用する場合

  • スコープと受け入れ条件が明確である場合;
  • 重要なアーキテクチャ上の事項や外部の事実が確定している場合;
  • 新たな公開契約を作り出さずにカードを実装できる場合;
  • TDD によって意味のある証明が得られない、範囲の限定された静的ファイル/設定/ドキュメントの変更である場合;
  • TDD Skill によってすでに RED が確立され、実装の準備ができている場合。

使用しない場合

  • 動作変更に有効な RED がまだ必要な場合(fable-tdd);
  • 実装によって新たなアーキテクチャ上の判断が明らかになった場合(fable-plan);
  • 繰り返し発生する失敗の原因究明が必要な場合(fable-recover);
  • 既存の差分を独立して検証またはレビューするタスクである場合(fable-verify/fable-review)。

変更の分類

編集する前に、カードを分類します。

変更実行時の考慮事項
ローカルな動作周囲の契約を維持する
設定/マニフェスト優先順位、生成元、パッケージング
公開 API/CLI互換性と呼び出し元への影響
データ/永続化トランザクション/マイグレーションの不変条件
生成物ソース/ジェネレーターを編集し、一度だけ再生成する
依存関係の配線ライフサイクル/クリーンアップ/エラー伝播
TDD 後の修正動作を広げずに RED を解消する
レビュー後の修正根拠のある指摘と、それに関係する検証のみを修正する

プロトコル

ステージ 1 — 現在のワークスペースを踏まえてカードを再確認する

次の項目を確認します。

  • 目的;
  • 担当範囲;
  • 対象外の範囲;
  • 依存関係/前提;
  • 受け入れを示す証拠;
  • 現在の git/ワークスペースの状態。

計画後にワークスペースが変更され、前提が無効になっている場合は、古いカードを無理に進めず、停止して計画を立て直します。

ステージ 2 — 変更前に調査する

対象コードと、その直近の契約/呼び出し元/テストを正確に読みます。広範な再調査は避けますが、古い記憶を頼りに編集してはいけません。

変更中も維持すべき不変条件を特定します。

ステージ 3 — 最小限で一貫性のある変更を選ぶ

次を優先します。

  • リポジトリ内にある既存のパターン;
  • 生成物よりも信頼できるソース;
  • 推測に基づく抽象化よりもローカルな互換性;
  • 不確実性が残る場合は、元に戻しやすい変更;
  • 一度に1つの動作変更。
ステージ 4 — 変更を加え、影響を記録する

次の項目を記録します。

  • 変更したファイル/領域;
  • 新規または変更された契約;
  • 影響を受ける生成物;
  • この変更後に必要な受け入れコマンド。

編集がカードの範囲を越える場合は、続行する前に一時停止し、その理由を説明します。

ステージ 5 — 直ちに受け入れ確認を行う

一貫性のある変更ができたら、意味のある最小範囲の受け入れ証拠をすぐに実行します。

変更された動作を検証していない場合、コマンドの終了コードだけでは不十分です。

ステージ 6 — 再編集する前に失敗を分類する

失敗した場合は、次を確認します。

  • 継続中の TDD において想定された RED か;
  • 今回の編集で発生したタイプミス/コンパイルエラーか;
  • 実装に関する仮説の誤りか;
  • 古いビルド/設定/テストハーネスの問題か;
  • 隠れた依存関係/アーキテクチャの変更か。

失敗から得られた新たな情報によって変更が正当化される場合に限り、次の変更を行います。

ステージ 7 — 差分を整理する

引き渡す前に、次を行います。

  • デバッグ出力/不要な実験コードを削除する;
  • 意図しない整形や生成物のノイズを確認する;
  • 無関係なファイルが変更されていないことを確認する;
  • 必要に応じて、ソースから決定論的な出力を再生成する;
  • ユーザーが並行して行った変更を保持する。
ステージ 8 — 独立した検証に引き渡す

fable-verify に次を伝えます。

  • カードの目的;
  • 差分/変更した領域;
  • 受け入れコマンド/結果;
  • 考慮した不変条件;
  • 生成物/設定への影響;
  • 残るリスクと未検証の領域。

判断ルール

  • 新たに重要な未知事項が判明した場合 → 停止し、調査/リサーチ/計画に引き継ぎます。
  • 新たなアーキテクチャまたは公開契約に関する判断が必要な場合 → fable-plan に引き継ぎます。実装の詳細として隠してはいけません。
  • 実現可能な範囲で有効な回帰テストがない状態で動作を変更する場合 → fable-tdd に引き継ぎます。
  • 生成ファイルを変更するよう求められた場合 → ジェネレーター/ソースを特定してソースを変更し、その後に出力を再生成します。
  • 対象ファイルに既存のユーザー変更や無関係な変更がある場合 → それらを保持し、文脈に沿った最小限の編集を行います。ファイル全体をリセット/上書きしてはいけません。
  • 明らかに今回加えた構文/型エラーが原因で受け入れ確認に失敗した場合 → 直接修正して再実行し、範囲を限定します。
  • 類似の実装仮説が繰り返し失敗する場合 → fable-recover に引き継ぎます。根拠のない「もう一度試す」ループは禁止です。
  • 受け入れ確認コマンドが成功しても、変更した経路を実行していない場合 → カードの完了を主張してはいけません。受け入れ確認を強化するか、その不足を明記して引き継ぎます。

不変条件

  • カードの範囲を暗黙のうちに拡大してはいけません。
  • ユーザーによる変更や無関係な変更を保持します。
  • 該当する場合は、派生出力ではなく信頼できるソースを編集します。
  • 意味のある変更を加えるたびに、それ以前の検証結果は古くなります。
  • 正確性のために必要でない限り、修正に無関係なクリーンアップを含めてはいけません。
  • 受け入れ確認の証拠は、変更した動作に対応している必要があります。

失敗の分類

局所的な実装不備

現在の編集が直接の構文/型/アサーションエラーを引き起こしています。カードの範囲内で修正します。

仮説の失敗

コードは有効ですが、動作が依然として正しくありません。仮説を見直し、類似の失敗が繰り返された場合はリカバリーに引き継ぎます。

隠れた依存関係

正しい動作の実現に、承認済みカードの範囲外にあるコンポーネント/契約が必要です。停止してスコープを再計画します。

ハーネス/成果物の不一致

コマンドが古いビルド、誤った環境、誤ったブランチ、または生成済み成果物を使用しています。原因を示す証拠が不明瞭になる場合はリカバリーに引き継ぎます。

受け入れ確認の不備

変更を実行していないのに確認が成功しています。完了前に証拠を強化します。

並行作業の競合

対象に、このカードの担当ではない正当な変更が含まれています。それらを保持して編集範囲を絞るか、担当を調整します。手軽さを理由に上書きしてはいけません。

アンチパターン

  • 「ついでに」リファクタリングすること。
  • 生成ファイルを直接編集すること。
  • 実行開始後に広範な検索/アーキテクチャ調査を行うこと。
  • 表面的な構文変更を加えて同じパッチを再試行すること。
  • 小さな修正のために、ユーザーが変更したファイル全体を置き換えること。
  • 動作を実行していないのに、ビルド成功を機能の証拠として受け入れること。
  • カードで求められていない抽象化/設定可能性を追加すること。
  • アーキテクチャ上の判断を実装に紛れ込ませること。

実行パケット

Card:
Owned scope:
Files/surfaces changed:
Behavior/contract delta:
Acceptance command/result:
Invariants checked:
Generated/config impacts:
Unexpected facts:
Residual risk:
Recommended verify scope:

完了条件

実行は、以下を満たしたときに完了します。

  • 明示された範囲内で、承認済みの動作が実装されていること。
  • 直近の受け入れ確認が成功しているか、証明上の不足があれば明示して引き継いでいること。
  • 差分に、意図しない変更や無関係な変更が含まれていないこと。
  • 新たなアーキテクチャ上の判断が実装に紛れ込んでいないこと。
  • 検証担当者が、変更箇所と、反証すべき残りの事項を正確に把握できること。

段階的なリソース

  • 詳細な封じ込めガイド:references/bounded-mutation-and-failure-classification.md
  • 既存の封じ込めに関するリファレンス:references/mutation-containment.md
  • 例:examples/bounded-card-execution.md

コメント