mcpField
F
fixflow

fixflow

github.com/majiayu000開発28850 回インストール今日更新
リポジトリ

fixflow について

fixflow は、エンドツーエンドの開発作業を行うコーディングエージェント向けスキルです。事前の計画、順序立てた実装、継続的な検証を定め、必要に応じて BDD や TDD を取り入れます。

主な機能

  1. 01編集前の全体計画
  2. 02段階的な実行と継続検証
  3. 03各段階のコミット記録
  4. 04必要に応じた BDD と TDD
  5. 05引き渡し前の検証

活用シーン

  1. 01計画から実装までの開発作業
  2. 02検査後に各段階をコミット
  3. 03曖昧な要件を振る舞いシナリオで明確化
  4. 04引き渡し前のテスト証拠の提示

インストール

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

$npx skills add https://github.com/majiayu000/spellbook --skill fixflow

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

同梱ファイルreferences/bdd-guide.mdreferences/delivery-base.md

詳細

Fixflow

概要

このスキルを使うと、エンドツーエンドのエンジニアリング作業を一度の実行で完了できます。

  • 計画を完全に立てます。
  • 厳密な順序で実行します。
  • 継続的に検証します。
  • 明示的なコミットポリシーを使用します(デフォルトは per_step、要求に応じて final_only/milestone)。
  • 要求された場合、または要件が曖昧な場合は、BDD の振る舞い仕様を追加します。

トリガーとなる要望

ユーザーが次のいずれかを求めた場合、このスキルを使用します。

  • 完全な計画と順序に沿った実行。
  • 後方互換性を考慮しないこと。
  • 引き渡し前にすべてをテストすること。
  • 完了後にコミットすること、または各ステップの前にコミットすること。
  • 振る舞い駆動型の開発(BDD)または受け入れシナリオ。

ワークフロー

1. Ready Criteria(DoR)を定義する

共通のデリバリーベースを参照してください:references/delivery-base.md

2. 編集前に完全な計画を立てる

共通のデリバリーベースを参照してください:references/delivery-base.md

3. 必要に応じて BDD/TDD レイヤーを追加する

ユーザーから要求された場合、または要件が不明確な場合は、BDD を使用します。

3.0 TDD モード(RED -> GREEN -> IMPROVE)

ユーザーが TDD またはテスト駆動型の開発を求めた場合:

  1. RED — まず失敗するテストを書く

    • 要件からテスト可能な振る舞いを抽出します
    • 期待する振る舞いを検証する最小限のテストケースを書きます
    • テストを実行し、失敗すること(赤)を確認します
    • 予期せずテストが成功した場合 -> 要件はすでに満たされているか、テストが誤っています
  2. GREEN — 最小限の実装を書く

    • テストを成功させるのに必要な最小限のコードを書きます
    • 余分な改善や「ついで」の変更はしません
    • テストを実行し、成功すること(緑)を確認します
  3. IMPROVE — テストが成功している状態でリファクタリングする

    • 重複をなくし、命名を改善し、ロジックを簡潔にします
    • 各リファクタリングの後にテストを実行し、リグレッションがないことを確認します
    • リファクタリングで外部から見える振る舞いを変更してはいけません

カバレッジ目標:新規コードは行カバレッジ 80%、クリティカルパスは 100%。

TDD モードのトリガーとなる要望:

  • ユーザーが「TDD」、「テスト駆動」、「まずテスト」と言う
  • ユーザーが「コードを書く前にテストを書く」と言う
  • 入力と出力が明確で、要件が十分に定義されている

BDD Lite、Scenario Quality Checklist、Scenario Outline、Test Layer マッピングについては、共通リファレンスを参照してください。

references/bdd-guide.md

4. ステップごとに実行する

共通のデリバリーベースを参照してください:references/delivery-base.md

per_step(デフォルト)の場合:

  • 現在のステップに必要なファイルのみをステージングします。
  • ステップ単位のチェックを実行します。
  • チェックが成功したら、すぐにコミットします。
  • ステップとコミットハッシュの対応関係を記録します。
5. 後方互換性を考慮しないモードを適用する(要求された場合)

共通のデリバリーベースを参照してください:references/delivery-base.md

6. テストマトリックスで検証する(検証ループ)

共通のデリバリーベースを参照してください:references/delivery-base.md

7. コミットして引き渡す

共通のデリバリーベースを参照してください:references/delivery-base.md

ガードレール

  • 実装が期待されている場合、計画だけで終わらせないでください。
  • 計画のステップを未完了のまま残さないでください。
  • 今すぐ実行できる必須テストを先送りしないでください。
  • final_only をデフォルトにしないでください。ユーザーが明示的に別の方法を求めない限り、per_step を使用してください。
  • commit_policy = per_step の場合、コミットする前に次の計画ステップへ進まないでください。
  • ユーザーが互換性対応をしないよう明示的に求めた場合、互換性があると主張しないでください。
  • 無関係な既存の変更ファイルをコミットに含めないでください。
  • 具体的な検証結果なしに引き渡さないでください。

コメント