classmethod Dev Navigate
開発者がやりたいことを対話で把握し、最適なtsumikiスキルの開始ポイントを提案するナビゲーションスキル。提案後、ユーザーの承認があればそのスキルを起動する。
対象スキル一覧
| スキル | 概要 |
|---|---|
dcs:feature-rubber-duck |
アイデアを整理して実現可能なPRDを作成する |
dcs:incremental-dev |
既存コードへの段階的な機能追加の計画を立案する |
dcs:impact-analysis |
変更の影響範囲を分析する |
dev-plan |
要件をタスク分解して実装計画を立てる |
dev-impl |
テストファースト実装を行う（Plan指定 or クイックモード） |
dev-run |
impl → verify → debug を自動で連続実行する |
dev-verify |
Plan 単位でテスト・ビルド・Lint を一括検証する |
dev-debug |
エラーをカテゴリ別に診断して修正する（webtest エラーにも対応） |
dev-screen-spec |
ソースコードまたは受け入れ条件から画面仕様を自動生成・差分更新する |
dev-webtest-plan |
dev-plan の成果物から Web テスト計画を生成する。画面仕様の差分更新にも対応 |
dev-webtest |
Playwright で画面の動作確認・視覚テストを行い、問題を検出・記録する |
ワークフロー
Step 1: メイン質問（Q1）
AskUserQuestion で以下を質問する:
質問: 「今やりたいことに一番近いのはどれですか？」
| 選択肢 | 説明 |
|---|---|
| アイデアを整理してPRDにしたい | まだ構想段階。アイデアを実現可能なPRDに落とし込みたい |
| 既存コードに変更を加えたい | 既に動いているコードに機能追加や変更をしたい |
| すぐに実装・修正に入りたい | 要件やplanは明確。実装作業を始めたい |
| テスト・画面確認をしたい | 実装済みのコードの検証や Web 画面の動作確認をしたい |
| エラーやバグを修正したい | テスト失敗、ビルドエラー、画面の不具合などを直したい |
| 画面仕様やテスト計画を最新化したい | ソースコード変更後に画面仕様やテスト計画を差分更新したい |
Step 2: 結果の判定
Q1の回答に応じて分岐する。
Q1 = 「アイデアを整理してPRDにしたい」
提案スキル: dcs:feature-rubber-duck
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dcs:feature-rubber-duck`
アイデアを対話で深掘りし、実現可能なPRDドキュメントに整理します。
PRDが完成したら `/dev-plan` でタスク分解に進めます。
**推奨フロー:**
1. `dcs:feature-rubber-duck` — アイデアをPRDに整理
2. `dev-plan` — PRDからタスク分解
3. `dev-impl` — タスクごとに実装
Q1 = 「既存コードに変更を加えたい」
追加質問 Q2 に進む（Step 3）。
Q1 = 「すぐに実装・修正に入りたい」
提案スキル: dev-impl
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dev-impl`
- Planとタスクがある場合: `/dev-impl <plan-name> <task-id>`
- 小さな修正の場合: `/dev-impl "修正内容"`（クイックモード）
- 複数タスクを自動実行する場合: `/dev-run <plan-name> <from> <to>`
Planがまだない場合は先に `/dev-plan` でタスク分解することも検討してください。
Q1 = 「テスト・画面確認をしたい」
追加質問 Q2b に進む（Step 3b）。
Q1 = 「エラーやバグを修正したい」
提案スキル: dev-debug
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dev-debug`
- テスト失敗やビルドエラーの自動検出: `/dev-debug`
- 特定のエラーを指定: `/dev-debug "エラーメッセージ"`
- Web 画面テストで検出されたエラー: `/dev-debug webtest`
修正後は `/dev-verify` で回帰確認、Web 画面の場合は `/dev-webtest retest` で再テストできます。
Q1 = 「画面仕様やテスト計画を最新化したい」
提案スキル: dev-screen-spec
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dev-screen-spec`
ソースコードの変更を画面仕様に反映し、テスト計画も連動更新します。
**推奨フロー:**
1. `dev-screen-spec` — 画面仕様を差分更新（初回は自動で一括生成）
2. `dev-webtest-plan update` — 画面仕様の変更からテスト計画を差分更新
3. `dev-webtest` — 更新されたテスト計画でテスト実行
※ 実装前に受け入れ条件から画面仕様を作る場合: `/dev-screen-spec from-plan <plan-name>`
Step 3: 追加質問（Q2） — 既存コード変更の場合のみ
AskUserQuestion で以下を質問する:
質問: 「既存コードの変更について、今の状況に一番近いのはどれですか？」
| 選択肢 | 説明 |
|---|---|
| 影響範囲を先に把握したい | 変更がどこに波及するかわからず不安。先に調査したい |
| 段階的な実装計画を立てたい | 影響範囲はだいたいわかるが、段階的に進めたい |
| タスク分解して計画を立てたい | 要件は明確。タスクに分解して着手したい |
Q2 = 「影響範囲を先に把握したい」
提案スキル: dcs:impact-analysis（+ 連携フロー）
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dcs:impact-analysis`
まず影響範囲を可視化し、安全に変更を進められるようにします。
分析結果を踏まえて、次のステップを選択できます。
**推奨フロー:**
1. `dcs:impact-analysis` — 影響範囲を可視化
2. `dcs:incremental-dev` — 段階的な実装計画を立案（または `dev-plan` でタスク分解）
3. `dev-impl` — タスクごとに実装
Q2 = 「段階的な実装計画を立てたい」
提案スキル: dcs:incremental-dev
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dcs:incremental-dev`
既存コードへの変更を段階的に計画し、安全に機能追加を進めます。
**推奨フロー:**
1. `dcs:incremental-dev` — 段階的な実装計画を立案
2. `dev-impl` — タスクごとに実装
Q2 = 「タスク分解して計画を立てたい」
提案スキル: dev-plan
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dev-plan`
要件をインターフェースファースト設計でタスクに分解し、実装計画を作成します。
**推奨フロー:**
1. `dev-plan` — 要件からタスク分解
2. `dev-impl` — タスクごとに実装
3. `dev-verify` — 実装完了の検証
Step 3b: 追加質問（Q2b） — テスト・画面確認の場合のみ
AskUserQuestion で以下を質問する:
質問: 「テスト・確認について、今の状況に一番近いのはどれですか？」
| 選択肢 | 説明 |
|---|---|
| Plan 単位でテスト・ビルドを一括検証したい | 実装が一通り終わった。全体の整合性を確認したい |
| Web 画面の動作確認をしたい | ブラウザ上で画面が正しく動くか確認したい |
| テスト計画を作ってから体系的にテストしたい | dev-plan の成果物からテスト計画を自動生成してテストしたい |
Q2b = 「Plan 単位でテスト・ビルドを一括検証したい」
提案スキル: dev-verify
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dev-verify`
Plan 内の全タスクの完了状態を確認し、テスト・ビルド・Lint・カバレッジを一括検証します。
**推奨フロー:**
1. `dev-verify <plan-name>` — 全体検証
2. `dev-debug` — 問題があれば修正
Q2b = 「Web 画面の動作確認をしたい」
提案スキル: dev-webtest
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dev-webtest`
- テスト計画に沿ったテスト: `/dev-webtest <plan-name>`
- 単一ページのクイックチェック: `/dev-webtest check <url>`
- ランダム操作テスト: `/dev-webtest monkey <url>`
- プラン一覧から選択: `/dev-webtest`（引数なし）
問題が見つかったら `/dev-debug webtest` で修正し、`/dev-webtest retest` で再確認できます。
Q2b = 「テスト計画を作ってから体系的にテストしたい」
提案スキル: dev-webtest-plan
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dev-webtest-plan`
dev-plan の成果物から Playwright 用テスト計画を自動生成し、そのシナリオに沿ってテストします。
**推奨フロー:**
1. `dev-webtest-plan <plan-name>` — テスト計画を自動生成
2. `dev-webtest <plan-name>` — テスト計画に沿ってテスト実行
3. `dev-debug webtest` — 問題があれば修正
4. `dev-webtest retest` — 修正確認
Step 4: 起動確認
提案メッセージを出力した後、AskUserQuestion で起動確認する:
質問: 「推奨スキルを起動しますか？」
| 選択肢 | 説明 |
|---|---|
| 起動する | 推奨フローの最初のスキルを起動します |
| 起動しない | 提案内容を参考に、自分のタイミングで実行します |
- 「起動する」の場合: Skill ツールで推奨フローの最初のスキルを呼び出す
- 「起動しない」の場合: 提案内容を表示したまま終了する
ルール・制約
- 質問は最大2問（Q1 + 必要時のみQ2/Q2b）に抑える
- Q1の回答だけで特定できる場合はQ2/Q2bをスキップする
- 提案時は必ず「推奨フロー」として後続スキルの流れも示す
- 起動確認では常にフローの最初のスキルを起動対象とする
- ユーザーが Other で自由入力した場合は、内容を解釈して最適なスキルを判定する