// 対話的計画コマンド。requirements-analyzing-requirementsとimplementation-planning-tasksスキルを統合実行してDESIGN.mdとTODO.mdを生成
| name | workflow-spec |
| description | 対話的計画コマンド。requirements-analyzing-requirementsとimplementation-planning-tasksスキルを統合実行してDESIGN.mdとTODO.mdを生成 |
| argument-hint | [タスク説明] |
| allowed-tools | Skill, AskUserQuestion, Read |
このコマンドは、Claude Code組み込みのplan modeと同等の機能を提供します。 ユーザーのタスク説明から自動的にDESIGN.md（設計ドキュメント）とTODO.md（タスクリスト）を生成します。
requirements-analyzing-requirementsとimplementation-planning-tasksスキルを統合実行し、対話的に計画を洗練します。
/spec ユーザー認証にOAuth2を追加
/spec
事前の会話でタスクが明確な場合、コンテキストから理解します。
引数からタスク説明を取得します：
$ARGUMENTSが存在する場合: そのまま使用$ARGUMENTSが空の場合: ユーザーに質問タスク説明: $ARGUMENTS
$ARGUMENTSが空の場合、以下の質問をしてください：
「どのようなタスクの計画を作成しますか？具体的なタスク説明を入力してください。
例：
Readツールでdocs/DESIGN.mdとdocs/TODO.mdの存在を確認してください。
既存ファイルが存在する場合、AskUserQuestionツールで確認してください：
AskUserQuestion({
questions: [
{
question: "既存の計画ドキュメントが見つかりました：\n- docs/DESIGN.md\n- docs/TODO.md\n\nどのように進めますか？",
header: "既存ドキュメント",
options: [
{
label: "新規作成",
description: "既存のドキュメントを上書きして新規作成"
},
{
label: "更新",
description: "既存のドキュメントを読み取って差分更新"
},
{
label: "キャンセル",
description: "コマンドを終了"
}
],
multiSelect: false
}
]
})
「更新」を選択された場合：
「キャンセル」を選択された場合：
requirements-analyzing-requirementsスキルを実行してDESIGN.mdを生成します。
以下の情報をrequirements-analyzing-requirementsスキルに渡してください：
タスク説明: [取得したタスク説明]
更新モード: [新規/更新]
既存DESIGN.md: [存在する場合は内容を含める]
Skillツールを使用してrequirements-analyzing-requirementsスキルを実行してください。
スキル実行後、docs/DESIGN.mdの存在と内容を確認してください。
生成されたDESIGN.mdの主要セクションを表示してください：
AskUserQuestionツールを使用してユーザー承認を取得してください：
AskUserQuestion({
questions: [
{
question: "DESIGN.mdが生成されました。内容を確認してください。\n\n生成場所: docs/DESIGN.md\n\nこのまま次のフェーズ（インタビューによる深掘り）に進めてよろしいですか？",
header: "DESIGN.md承認",
options: [
{
label: "承認",
description: "次のフェーズ（インタビュー）に進む"
},
{
label: "却下",
description: "コマンドを終了"
}
],
multiSelect: false
}
]
})
「承認」を選択された場合：
「却下」を選択された場合：
ユーザーが修正内容を入力した場合（Other選択）：
requirements-interviewスキルを実行してDESIGN.mdをブラッシュアップします。
Skillツールを使用してrequirements-interviewスキルを実行してください：
Skill({
skill: "requirements-interview",
args: "docs/DESIGN.md"
})
requirements-interviewスキルが以下を実行します：
インタビュー完了後、以下の条件を満たすまで繰り返しインタビューを実施する：
繰り返しごとにDESIGN.mdを更新し、より詳細な仕様を蓄積していく。
すべてのインタビューが完了したら、次のフェーズ（検証手順の確認と補完）に進みます。
DESIGN.mdに記載された「ゴールと検証手順」セクションを精査し、不足を補完する。
以下のソースから検証に関する情報を収集する：
以下の観点で検証手順の充実度を評価する：
不足がある場合、AskUserQuestionツールで確認する：
AskUserQuestion({
questions: [
{
question: "検証手順について確認させてください。\n\n現在のゴール:\n[DESIGN.mdから抽出したゴール一覧]\n\n以下の点が不明です:\n- [不明点1]\n- [不明点2]\n\nどのように検証しますか？",
header: "検証手順",
options: [
{ label: "選択肢1", description: "..." },
{ label: "選択肢2", description: "..." }
],
multiSelect: false
}
]
})
具体的な質問例：
収集した情報でDESIGN.mdの「ゴールと検証手順」セクションを更新する。
AskUserQuestionツールで確認：
AskUserQuestion({
questions: [
{
question: "検証手順を更新しました。確認してください。次のフェーズ（TODO.md生成）に進めてよろしいですか？",
header: "検証手順承認",
options: [
{
label: "承認",
description: "次のフェーズ（TODO.md生成）に進む"
},
{
label: "却下",
description: "コマンドを終了"
}
],
multiSelect: false
}
]
})
「承認」を選択された場合：
「却下」を選択された場合：
ユーザーが修正内容を入力した場合（Other選択）：
implementation-planning-tasksスキルを実行してTODO.mdを生成します。
以下の情報をimplementation-planning-tasksスキルに渡してください：
DESIGN.mdの場所: docs/DESIGN.md
更新モード: [新規/更新]
既存TODO.md: [存在する場合は内容を含める]
Skillツールを使用してimplementation-planning-tasksスキルを実行してください。
スキル実行後、docs/TODO.mdの存在と内容を確認してください。
生成されたTODO.mdの主要セクションを表示してください：
AskUserQuestionツールを使用してユーザー承認を取得してください：
AskUserQuestion({
questions: [
{
question: "TODO.mdが生成されました。内容を確認してください。\n\n生成場所: docs/TODO.md\n\nこのタスクリストで問題ありませんか？",
header: "TODO.md承認",
options: [
{
label: "承認",
description: "このタスクリストで完了"
},
{
label: "却下",
description: "コマンドを終了"
}
],
multiSelect: false
}
]
})
「承認」を選択された場合：
「却下」を選択された場合：
ユーザーが修正内容を入力した場合（Other選択）：
以下の情報を表示してください：
✓ 計画が完成しました
生成されたファイル:
- docs/DESIGN.md (設計ドキュメント)
- docs/TODO.md (タスクリスト)
更新モードで実行された場合、両ファイルの先頭に変更履歴コメントを追記してください：
<!-- 変更履歴
[YYYY-MM-DD]: [変更内容の要約]
-->
TODO.md承認後、自動的に implementation-developing スキルを実行して実装を開始します。
Skill({
skill: "implementation-developing"
})
ライブラリやフレームワークのドキュメントを検索する際は、context7 MCPサーバーを使用する：
resolve-library-idを呼び出してContext7互換のライブラリIDを取得get-library-docsを呼び出す/org/project形式でライブラリIDを提供した場合適切な使用例:
禁止:
計画ドキュメントは以下のルールを参照します：
rules/core/tdd.mdrules/core/commit.mdrules/core/design.md更新モードが選択された場合：
React 19 + Vite+ (`vp`) + TypeScript + Tailwind CSS v4 + React Router v7 (HashRouter) でモバイル向け静的SPAデモサイトをTDDで構築し、Cloudflare Workers (Static Assets) へ自動デプロイするまでの標準ワークフローを提供する。テンプレートリポジトリ `skanehira/demo-site-template` を `gh repo create --template` で clone することで scaffold を省略する。`localStorage` でフロントエンドのみ完結する"フロントのみ完結デモ"に特化。デザインコンセプトの確立には `frontend-design` スキルを呼び出して連携する。起動トリガー：「デモサイトを作りたい」「モバイル向け静的デモ」「SPAを作ってCloudflareにデプロイ」「静的プロトタイプを公開」「localStorage でフロントだけ完結」。ユースケース：(1)クライアント提案用のUI/UXたたき台、(2)新機能のプロトタイプ、(3)モバイル向けランディング。ツールチェーンは Vite+ (`vp`) で統合（内部 PM は pnpm）。
ローカルのコミット履歴と差分からDraft PRを作成する。ブランチ未作成・コミット未作成の状態でも、必要に応じてブランチ作成とコミットを行ってからPRを作成する。`.github/` にPRテンプレートがあれば内容を埋めて、なければ作業内容から本文を生成し、`AskUserQuestion`で作成可否を確認してから `gh pr create --draft` を実行する。「PRを出したい」「draft PRを作成」「プルリクを作って」「PR本文を生成」などのリクエストで起動。
TDD（RED→GREEN→REFACTOR）でフェーズ単位の新機能実装やバグ修正を行う。docs/TODO.md があるとフェーズ管理し、なければ単独タスクとしてサイクルを回す。テストファーストを厳格に遵守。「実装したい」「TDDで実装」「機能を追加」「バグを修正」などで起動。
TDD方法論に従ってテストを作成します。テスト対象コードの分析、AAA/Given-When-Thenパターンの適用、正常系・エッジケース・エラー系のカバレッジを確保します。「テストを書いて」「テストを作成」「単体テストを追加」などのリクエストで起動します。
複数サブエージェントに異なる立場を与えて議論を反復し、相違が収束するまで議題を検証して結論を提示する。設計妥当性検証・実装方針比較・原因分析のセカンドオピニオン・アイデアの壁打ちに使用。「議論したい」「壁打ちしたい」「セカンドオピニオン」「複数視点で検証したい」などで起動。
変更内容を分析し、Conventional Commit形式でコミットする (pushはユーザが手動)