sdd-context-intake

Spec-Driven Development のためのコンテキスト取り込み

ユーザーが最初から明確な一行の目標を提示することはほとんどありません。チケットやドキュメント、スレッド、ファイルなどがあります。このスキルでは、ソースに実際に書かれている内容を超えて推測することなく、そうした生の資料を SDD フローに必要な構造化されたブリーフにまとめます。

使用するタイミング

• ユーザーがチケット、要件、設計ドキュメント、メモを貼り付けて、「これをやって」と指示したとき。
• ユーザーが情報源としてファイル名、パス、URLを指定したとき。
• 目標が明示されず資料の中に埋もれている場合、sdd-clarify の前、また sdd-feature-flow の開始前。

手順

1. **ユーザーが提示したすべてのソースを、そのまま収集します。**貼り付けられたテキストに加え、参照先も含めます。指定されたファイルを Read で読み、URLを WebFetch で取得し、利用可能であればチケットを MCP／CLI で取得します。ほかの情報源が示されている場合、貼り付けられた概要だけで済ませてはいけません。
2. **分量が多い場合や複数のソースがある場合は、読み取りを委任します。**読み取り専用エージェント（Explore または general-purpose エージェント）を起動し、ソースを読み込んで簡潔な要約を返してもらいます。これにより、大量の資料でメインコンテキストが埋まるのを防げます。短いテキストが一つだけの場合は、その場で読みます。
3. **次のセクションだけでブリーフをまとめます。**根拠はソースのみに置き、推測した内容にはその旨を明記します。
   • Goal — 何をなぜ作るのかを1、2行で記述します（「何を／なぜ」であり、「どのように」ではありません）。
   • In scope / Out of scope — ソースに基づく箇条書きです。
   • Constraints — ソースに記載されたデータモデル、契約、連携、命名規則、制限事項です。
   • Load-bearing unknowns — ソースでは確定しておらず、コード、契約、テンプレート構造を変える判断事項です。これらは sdd-clarify で尋ねる質問になります。
   • Sources — 実際に読んだファイル、URL、チケットです。
4. **引き継ぎます。**不明点を sdd-clarify に渡してユーザーに確認し、解決済みのブリーフを goal として（確認済みのパラメーターがあればそれも添えて）sdd-feature-flow ワークフローに渡します。

ルール

• すべての内容はソースに基づかせます。ソースに書かれていないことは仮定ではなく不明点です。表面化させ、作り出してはいけません。（これはハーネスが後段で適用する明確性ゲートと同じ考え方です。ここで確認するほうがコストを抑えられます。）
• このスキルで仕様やコードの作成を始めてはいけません。出力するのはブリーフのみです。
• 要約は簡潔にします。目的は、ソースの内容を判断事項と不明点に絞り込むことです。