仕様駆動機能開発
概要
このスキルは計画優先・コードゲーティングプロトコルを強制します。自律型コーディングエージェントは、ファイル編集に直接飛び込むことでコンテキストドリフト、APIの幻覚、試行錯誤によるデバッグでトークンを浪費することがよくあります。
このスキルが作動すると、正式な仕様（SPEC.md または .specs/<feature-slug>.md）がドラフトされ、リポジトリの制約に対して検証され、承認されるまで、アプリケーションコードを修正することはできません。
1. フェーズ1: コンテキストと制約の調査
仕様をドラフトする前に:
- プロジェクト内の既存の規約、データモデル、APIユーティリティを特定します。
- 型定義またはスキーマファイル（例:
schema.prisma、drizzle/schema.ts、Zodスキーマ、OpenAPI仕様）を見つけます。 - 必要な場合を除き、ファイル全体を読まないでください。エクスポート、インターフェースヘッダー、型を検査します。
2. フェーズ2: SPEC.md のドラフト
./references/spec_template.md を読み、その正確な構造に従って .specs/<feature-slug>.md（または要求されればリポジトリルートの SPEC.md）を作成します:
- 目的、成功基準、明示的な非目標: 2文程度の問題記述、決定的な合格基準、明示的なスコープ外境界。
- データ契約とシグネチャ: 正確なTypeScriptインターフェース、データベースカラム型、またはAPIスキーマ。
- ファイル変更境界マトリックス: 明示的な
Create（作成）、Modify（修正。対象の関数/行を含む）、Forbidden（禁止）パス。 - 実装チェックリストと検証プロトコル: 正確なテストコマンド、リンターチェック、エッジケース。
3. フェーズ3: ゲートチェックポイント (必須)
仕様が生成されたら:
- 対話モード（ユーザーセッション）: 仕様ファイルへのリンクを含む簡潔なサマリーを提示し、アーキテクチャ上のトレードオフを表面化させ（複数の有効なアプローチが存在する場合は
ask_questionを使用）、コードを書く前に確認を求めます:"私は
SPEC.mdに仕様をドラフトしました。提案されたデータ契約とファイル境界マトリックスを確認してください。実装を進めてよろしいですか？" - 自律サブエージェントモード: すでに承認された修復計画を提供している親リードオーケストレーター（例:
code-audit-orchestrator）によって呼び出された場合は、ファイル境界マトリックスがForbiddenパスと矛盾しないことを確認し、フェーズ4に進みます。 - ハードストップ: 対話セッションでは、承認またはフィードバックを待ちます。許可が得られるまでソースファイルに触れないでください。
4. フェーズ4: 段階的実行と途中修正プロトコル
承認後:
- オプションのサンドボックス分離: 複数ファイルの変更、またはプライマリワーキングツリーに無関係な変更がある場合は、ファイルを変更する前に
git-worktree-isolator経由で分離されたワークツリーをプロビジョニングします。 - 機能を個別のアトミックマイルストーン（例: スキーマ → コアロジック → APIハンドラ → UI/統合）で実装します。
- マイルストーンが完了するたびに、仕様ファイルのチェックボックスをマークします。
- gitコミットは個々のマイルストーンにスコープされます。
エスケープハッチ: 途中仕様修正
実装中に予期せぬ制約が発生した場合（例: Forbidden ファイルを修正する必要がある、アップストリームSDKの型がドラフトした契約と一致しない、ユーザーが途中で要件を変更するなど）:
- 影響を受けるマイルストーンの編集を直ちに停止します。
- 仕様ファイルの
## 6. 仕様修正（デルタログ）に、以下の内容を記録するエントリを追加します:- トリガー/ブロッカー: 元の契約が維持できない理由。
- 修正セクションとデルタ: データ契約またはファイル変更境界マトリックスへの正確な変更。
- デルタが以前
Forbiddenだったファイルに影響を与える場合、または公開API/スキーマ契約を変更する場合は、一時停止し、再開前に迅速なユーザー確認を要求します。デルタが純粋に内部的なもの（例: 内部ヘルパーファイルの抽出）である場合は、デルタを仕様に記録して続行します。
5. フェーズ5: 検証とアーカイブ
- フェーズ2で指定された決定的なテストスイートを実行します。
- すべての型チェックとリンターが正常にパスすることを確認します。
- 仕様ステータスを
Completedに更新し、.specs/completed/YYYY-MM-DD-<feature-name>.mdにアーカイブします（リポジトリが.specs/を追跡しない場合は、一時的な仕様ファイルを削除します）。