アイデアから仕様へ は何をしますか？
アイデアを計画準備が整った仕様に変換する手助けをします。あなたが会話をリードし、相手は回答を提供します。
成果物とステータス
- 各作業アイテムは
docs/specs/<YYYYMMDD>-<タイプ>-<名前>/に配置されます。タイプは Conventional Commits（feat、fix、refactor、docs…）に従い、名前はケバブケースとします。そのディレクトリが既に存在する場合は-2を追加します。 spec.mdとplan.mdには、フロントマターにstatus: draft | approved | obsoleteが含まれます。approvedを設定できるのは人のみです。- 承認済みの成果物を変更した場合は、ステータスを
draftに戻し、その旨を宣言します。 - 作業管理（優先度、担当者、完了）はこのスキルの役割ではありません。それはトラッカーに記載されます。イシューが存在する場合、そのIDは
issue:に記述します。
動作
- 最初に、アイデアを短い段落で要約します。
- 適切な仕様を書くために不足しているものを特定し、最小限の有用な質問をブロックするものから先に行います。
- 「どのように」ではなく「何を」「なぜ」に焦点を当てます。フレームワークやアーキテクチャは、相手から求められた場合以外は扱いません。これらは
spec-to-planに属します。 docs/ARCHITECTURE.mdが存在する場合は読み込み、用語集の語彙を使用し、原則との矛盾点を特定します。
ラウンドごとの質問
- 問題と期待される成果
- ユーザーとアクター
- ユーザーストーリー（各ユーザーが必要とするものとその理由）
- スコープと対象外
- 動作とエッジケース：空、無効、または大量のデータ。外部依存関係の障害。同時実行アクション。
- 非機能制約
- セキュリティ（データ、認証、または外部入力に触れる場合）：データの機密性、誰が何をできるか、どの入力が信頼できないか、どのようなネガティブテストが必要か。
- 受け入れ基準（「Given…、when…、then…」）
あるラウンドを終えてもまだ曖昧な点がある場合は、その部分についてのみ質問します。
未解決の質問
回答を暗黙に仮定してはいけません。 未解決の質問ごとに：
[質問]
- A) [あなたのデフォルト提案（ある場合）]
- B) [明白な代替案]
- C) 仕様の未解決質問として残す
- D) その他の回答
相手が回答するか、未解決のままにすることを選択した場合にのみ、解決とみなします。
各返信の形式：理解したこと · 未解決の質問 · 次のステップ
サイズ
変更の深さに合わせます。パスを提案し、相手に決定させます：
| 変更 | 成果物 |
|---|---|
| 一行のバグ | なし、または tasks.md のみ |
| 複雑なバグ | spec.md + tasks.md |
| 小さな機能 | spec.md + plan.md + tasks.md |
| プロダクション機能またはアーキテクチャリファクタリング | すべて。仕様と計画のレビューを含む |
終了条件
以下に十分な情報が揃った時点で終了します：目標、問題、ユーザー、ユーザーストーリー、スコープと対象外、機能要件と非機能要件、エッジケース、受け入れ基準。
その後：
- ディレクトリ名を提案し、
assets/spec-template.mdからstatus: draftでspec.mdのドラフトを作成します。該当しないオプションセクションは削除します。 - ドラフトを表示し、相手が承認した場合にのみ書き込みます。
- 推奨される次のステップ：
review-specでレビューします。小規模で相手が満足している場合は、approvedとマークしてspec-to-planに進むことができます。