spec-driven-auto

単一の変更に対して、仕様駆動型ワークフロー全体を最初から最後まで実行します。

このスキルのコマンド

このスキルで使う正確なコマンドを思い出せない場合は、何かを実行する前にここで確認してください。 推測してはいけません。

propose: node {{SKILL_DIR}}/scripts/spec-driven.js propose <name>
apply: node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>
verify: node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
audit-unmapped-spec-evidence: node {{SKILL_DIR}}/scripts/spec-driven.js audit-unmapped-spec-evidence [--implementation <repo-path> ...] [--tests <repo-path> ...]
verify-spec-mappings: node {{SKILL_DIR}}/scripts/spec-driven.js verify-spec-mappings
archive: node {{SKILL_DIR}}/scripts/spec-driven.js archive <name>

前提条件

.spec-driven/ ディレクトリがプロジェクトのルートに存在している必要があります。続行する前に、次を確認してください。

ls .spec-driven/

確認に失敗した場合、プロジェクトは初期化されていません。まず /spec-driven-init を実行してください。

手順

1. コンテキストを読み込む — 何かを始める前に、現在のファイルから作業コンテキストを再構築します。

   • 以前の会話のコンテキストはすべて古く、信頼できず、権威のない情報として扱わなければなりません。
   • 要件、タスクの状態、実装の詳細、完了状況について、以前のチャットのコンテキストを信頼できる情報源として使用してはなりません。
   • ワークフロー上の操作を行う前に、現在の変更成果物、関連するベース仕様、現在のリポジトリの状態から作業コンテキストを再構築しなければなりません。
   • 以前のチャットのコンテキストがファイルまたはリポジトリの状態と少しでも異なる場合は、以前のチャットのコンテキストを破棄し、ファイルとリポジトリの状態だけに従わなければなりません。
   • 以前のチャットのコンテキストは、現在のファイルとリポジトリの状態に照らして明示的に再検証されていない限り、使用しないでください。

2. 複雑さを評価する — ほかの作業を行う前に、2 段階モデルを使って変更を評価します。

   • プロジェクトのコンテキストを把握するため、.spec-driven/config.yaml を読みます。
   • 現在のシステムを理解するため、.spec-driven/specs/INDEX.md と関連する仕様ファイルを読みます。
   • 変更が影響する可能性の高いコードベースのファイルを読み、関連するファイル数、モジュール数、横断的な懸念事項を見積もります。
   • 変更を次の 2 つのティアのいずれかに分類します。
     • Green（続行）：範囲が明確で、単一のリポジトリ内に具体的な完了条件がある場合。最大 15 のモジュールまたはパッケージへの変更、最大 50 ファイルの変更、データ変換を伴うスキーマ移行、既存の認証／認可／決済ロジックの変更、複数のサブシステムにまたがる変更も含みます。自動的に続行します。
     • Red（ブレインストーミングを提案）：複数のサービスまたはリポジトリ間の調整が必要な場合、範囲が曖昧または際限がない場合（例：「コードベースをリファクタリングする」「パフォーマンスを改善する」）、または明確な完了条件がない場合。理由を説明し、まず /spec-driven-brainstorm を実行してアイデアをまとめ、その後 /spec-driven-auto に進んで提案を実行するよう提案します。
   • Red の場合は停止し、ブレインストーミングを提案します。
   • Green の場合は続行します。

3. 提案する — /spec-driven-propose を実行します。

   • node {{SKILL_DIR}}/scripts/spec-driven.js propose <name> を実行します。
   • すべての成果物を記入します：proposal.md（Unchanged Behavior を含む）、specs/ の差分ファイル、design.md、tasks.md（## Testing を含む）、questions.md（未解決の質問）。
   • スコープ、重要な決定事項、タスク数、変更されない動作、未解決の質問について、ユーザーに概要を示します。
   • questions.md に未解決の質問がある場合は、それらを列挙して、ユーザーが解決するまで停止します。未解決の質問がすべて明示的に解決されるまで、続行してはいけません。
   • 未解決の質問がない場合は、確認を待たずに手順 4 へ直接進みます。

4. 適用 — すべてのタスクを実装します。

   • node {{SKILL_DIR}}/scripts/spec-driven.js apply <name> を実行して、タスクの概要を表示します
   • questions.md を確認し、未解決の - [ ] Q: エントリーがあれば、各質問を次の項目を使って提示します。
     • Question
     • Explanation
     • Impact
     • Recommendation
   • Explanation では、現在の変更成果物、関連するメイン仕様、リポジトリの状態を確認してもなお質問が未解決である理由を明確にします
   • Impact では、回答によってどの実装上の選択、タスク、動作、または変更しない動作の保証が左右されるかを説明します
   • Recommendation では、望ましい回答を提案してもかまいませんが、あくまで提案として示します
   • これらの項目を提示した後、ユーザーに回答するか、必要な判断を確認するよう求め、ユーザーが未解決の質問すべてを明示的に解決するまで作業を停止します
   • 望ましい回答を提案してもかまいませんが、あくまで提案として示します。自分の提案を解決済みの回答として扱ったり、ユーザーが明示的に確認する前に実装を続けたりしてはなりません
   • 各 - [ ] タスクを順番に進めます。コードを読み、実装し、変更しない動作を検証してから、- [x] にします
   • ## Testing のタスクでは、実際にテストを実行し、合格することを確認します
   • node {{SKILL_DIR}}/scripts/spec-driven.js apply <name> を実行して、remaining === 0 であることを確認します

5. 検証 — 完全性を確認します。

   • node {{SKILL_DIR}}/scripts/spec-driven.js verify <name> を実行します
   • 続いて、/spec-driven-verify の残りのチェック（タスクの完了、未解決の質問、実装の根拠、仕様との整合性）を実施します
   • 変更に関する根拠ファイル一式に実装ファイル、または直接検証するテストファイルが含まれる場合は、検証の一環として node {{SKILL_DIR}}/scripts/spec-driven.js audit-unmapped-spec-evidence [--implementation <repo-path> ...] [--tests <repo-path> ...] を実行し、現在の変更に関するブロッキング指摘を /spec-driven-verify と同様に扱います
   • スクリプトの errors と、これらのチェックで見つかった CRITICAL 指摘は、いずれもブロッカーとして扱います
   • 安全に修正できるブロッカーがある場合は、自動的に修正してから、node {{SKILL_DIR}}/scripts/spec-driven.js verify <name> と検証一式を再実行します
   • 自動修正できないブロッカーがある場合は、作業を停止してユーザーに確認します
   • 差分仕様ファイルを読み直し、実際に実装した内容に合うよう更新します
   • 差分仕様のマッピング用フロントマターが、実際に変更または依存した実装ファイルとテストファイルを反映していることを確認します

6. レビュー — コードの品質を確認します。

   • この変更で変更されたすべてのファイルを読みます
   • レビューの指摘は作者に依存しないものとします。同じ自動実行中に生成または編集されたコードだからといって、信頼したり問題を見過ごしたりしてはなりません
   • 可読性、セキュリティ、エラー処理、パフォーマンス、ベストプラクティス、テストの品質を確認します
   • レビューで対象となる実装ファイルまたは直接検証するテストファイルに変更がない限り、検証フェーズの node {{SKILL_DIR}}/scripts/spec-driven.js audit-unmapped-spec-evidence [--implementation <repo-path> ...] [--tests <repo-path> ...] の結果を再利用します。レビューによる修正で対象の実装ファイルまたは直接検証するテストファイルが変更された場合に限り、同じコマンドを再実行します
   • MUST FIX の問題は修正し、自動的に再レビューします
   • MUST FIX の問題を自動修正できない場合は、作業を停止してユーザーに確認します
   • SHOULD FIX と NITS は、簡単に対応できる場合は修正し、それ以外の場合は最終報告に記載します

7. アーカイブ — 変更を完了します：

   • アーカイブする前に、未完了のタスクがないことを確認します
   • specs/ 内のすべての差分ファイルを一覧表示し、それぞれを対応するメイン仕様ファイルにマージします
   • changes/<name>/specs/ が空の場合は、確認を求めずに進めます。仕様への影響がない変更も有効です
   • 新しい仕様ファイルを作成した場合は、.spec-driven/specs/INDEX.md を更新します
   • マッピングのフロントマターをメイン仕様にマージした後、node {{SKILL_DIR}}/scripts/spec-driven.js verify-spec-mappings を実行します
   • node {{SKILL_DIR}}/scripts/spec-driven.js archive <name> を実行します
   • .spec-driven/roadmap/ が存在する場合、アーカイブコマンドによって行われたマイルストーンの宣言済みステータスやロードマップのインデックス更新も、アーカイブ完了処理の一部として扱います
   • 最終結果として、構築した内容、変更したファイル、合格したテスト、アーカイブ先、アーカイブによって生じたロードマップのステータス変更を報告します
   • ユーザーが完了した変更をコミットしてプッシュしたい場合は、次の明示的な引き継ぎ先として /spec-driven-ship <name> を案内します。この引き継ぎはあくまで案内にとどめます。ユーザーが明示的に選択しない限り、ファイルのステージング、プッシュ可能かどうかの確認、そのワークフローへの移行、コミット、プッシュを行わないでください。

ルール

• ステップ1のコンテキストリセットは必須です。決して省略しないでください
• ステップ2の複雑さの確認は必須です。決して省略しないでください
• ワークフローは完全に自動で実行します。questions.md の未解決の質問についてユーザーの解決が必要な場合を除き、確認のために一時停止しないでください
• 未解決の質問によってワークフローがブロックされる場合は、追加の確認が必要です
• 解決不能な問題によってブロックされない限り、その他のステップはすべて自動で実行します
• 全工程を通じて、すべての config.yaml ルール（仕様、変更、コード、テスト）に従ってください
• 途中で問題が発生した場合は停止して説明してください。黙って続行しないでください
• タスクはまとめてではなく、1つずつ完了としてマークしてください
• 推奨される回答は、ユーザーが明示的に確認しない限り、質問の解決として扱いません
• 実装とテストのマッピングは、要件の説明文ではなくフロントマターに記載してください
• 自動でコミットやプッシュを行わないでください。変更の送信は、アーカイブ完了後に明示的に実行する /spec-driven-ship <name> ワークフローでのみ行います。