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