/dev-navigate

name: dev-navigate
description: This skill should be used when the user asks to "dev-navigate", "どこから始めれば", "何を使えばいい", "スキルを選んで", "ナビ", "navigate", "which skill", "how to start", "開発の進め方", "何から始める". 開発者がやりたいことをヒアリングし、最適なtsumikiスキルとその実行順序をナビゲーションする。

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 で自由入力した場合は、内容を解釈して最適なスキルを判定する