仕様駆動開発
要件を仕様、計画、コード、追跡可能な変更記録へ。
実装を始める前に、人と Coding Agent が共有する契約を作ります。FiboCode と Fibo Skills は、最初の依頼を明示的な受け入れ基準、ひも付いた設計、順序立てた計画、レビュー済みコード、リポジトリに残る変更記録へ変えます。
速く書けたコードが、合意どおりとは限りません。
Coding Agent は短い依頼から実装へすぐ進めますが、抜けた前提はファイルが変わった後に表面化しがちです。要件、境界、完了の証拠が暗黙のままなら、レビュー担当者はコードを判断しながら意図した動作も再構築しなければなりません。
仕様駆動開発は実行前に明確な経路を作ります。要件をテスト可能な受け入れ基準にし、設計判断で満たし方を示し、計画でタスク、ファイル、検証を順序付けます。実装には見える契約ができ、最後の diff 記録が実際の変更を説明します。
ワークフローが実際の作業につながり続ける様子を見る。
追跡可能な記録がコードとともに育ち、Agent CLI が既存のターミナル作業に残る様子を示します。
最初の要件を判断、タスク、実装の証拠、その後の理解へつなぐドキュメントの連鎖を示します。
Agent CLI をターミナルに置いたまま、具体的なファイル、シンボル、スクリーンショット、移動可能な出力パスを渡します。
四つの段階で、意図から証拠へ。
段階ごとの役割を分け、疑問が暗黙の実装判断になる前に解決します。
要件と受け入れ基準を明確にする。
最初の依頼を明示的でテスト可能な結果に変え、変更しない範囲も定めます。本番コードに入る前に、開発者が契約を承認します。
基準に照らして方法を設計する。
境界、インターフェース、重要なトレードオフを含め、各基準をどう満たすか説明します。リンクで判断を対象の動作へ追跡可能にします。
順序立てた計画を作成し、実行する。
設計を対象ファイルと受け入れ方法が明確なタスクに分け、Coding Agent が合意済みのコンテキストを使って順に作業します。
コードをレビューし、実際の変更を記録する。
得られた diff と受け入れ基準を確認し、変更した内容と理由を hunk ごとに説明する記録を残します。
Agent の実行を囲む、追跡可能な契約。
実装前の受け入れ基準。
仕様が曖昧な意図を観察可能な結果に変え、開発者と Agent に共通の完了定義を与えます。
動作に結び付いた設計判断。
設計は変更の仕組みを説明し、重要な判断を、それを必要とする受け入れ基準へ結びます。
範囲を限定した順序ある実行。
計画にタスク、対象ファイル、検証方法を記し、レビュー可能な単位で実装を進めます。
実際の diff に基づく変更履歴。
実行後の記録が実装の hunk を説明し、周辺ロジックとプロジェクトの意図へ結び付けます。
ユースケース：複数のモジュールにまたがる動作を変更する。
単純に見える依頼が、ルーティング、状態、UI、検証にまたがることがあります。開発者は観察可能な結果と除外事項に合意し、設計が影響範囲へ対応付け、計画がファイル単位のタスクと検証方法へ分けます。
Agent CLI は暗黙の選択を減らして実行できます。レビュー担当者は承認済み基準と結果を比較し、実際の変更を確認し、実装と元の要件の関係を説明する diff 記録を残せます。
Agent やテストを置き換えない、ワークフローの層。
Fibo Skills は明確化、仕様、設計、計画、実行、変更記録を案内します。コーディングは選択した Agent CLI が行い、正しさは実際のテストと受け入れ方法で判断します。
価値は合意と追跡可能性にあります。プロンプト優先では意図が未解決でも実装を始められますが、仕様駆動では変更前に意図をレビューし、その証拠を変更後も残せます。
仕様駆動開発の FAQ
小さな修正にも毎回仕様が必要ですか？
動作、境界、受け入れについて合意が必要なときに利用してください。機械的な小変更は、複数モジュールにまたがる機能と同じ深さを必要としない場合があります。
Fibo Skills とは何ですか？
対応する Agent CLI 環境で、明確化、仕様、設計、計画、実行、変更記録を案内するワークフロー指示です。
承認前に Agent が実装を始めてもよいですか？
未解決の前提ではなく明示的な動作契約に基づいて本番コードを書くため、想定する流れでは開発者が先に仕様を承認します。
設計と計画の追跡可能性はどう保ちますか？
設計判断を受け入れ基準へ結び、計画タスクには関係する基準、ファイル、受け入れ方法を記します。
実装後はどうなりますか？
仕様と実際の diff に照らして結果をレビューし、変更記録で実装の hunk とその理由を残せます。