メニュー
This skill should be used when the user asks to "dev-navigate", "どこから始めれば", "何を使えばいい", "スキルを選んで", "ナビ", "navigate", "which skill", "how to start", "開発の進め方", "何から始める". 開発者がやりたいことをヒアリングし、最適なtsumikiスキルとその実行順序をナビゲーションする。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
IPA「安全なウェブサイトの作り方 改訂第7版」「安全なSQLの呼び出し方」「ウェブ健康診断仕様」「セキュリティ実装チェックリスト」「安全なウェブサイトの運用管理に向けての20ヶ条」に基づき、ソースコードを静的に検査して脆弱性候補を検出する。発見した問題には IPA 原典の出典 (文書名・章・ページ・URL) を必ず付与する。
ipa-security-check をはじめとするセキュリティ診断ツールが出力したレポートを読み込み、各検出項目を優先順位付きの dev-debug 依頼リストに変換する。対象プロジェクトの言語・FWを問わず汎用的に使える。コードベースを直接読んでアーキテクチャ判断を行う。
This skill should be used when the user asks to "dev-context", "プロジェクトコンテキストを生成", "プロジェクトを分析", "generate project context", "analyze project", "コンテキストを更新". プロジェクトの技術スタック・テストフレームワーク・コーディング規約・アーキテクチャを自動分析し、コンパクトなコンテキストファイルを生成する。
This skill should be used when the user asks to "dev-debug", "テストが失敗する", "ビルドエラーを直して", "デバッグ", "debug failing tests", "fix build error", "エラーを修正", "コンパイルエラー", "環境の問題を解決". テスト失敗、ビルドエラー、環境問題など様々なエラーパターンをカテゴリ別に診断し、最小コンテキストで修正する。
This skill should be used when the user asks to "dev-impl", "タスクを実装", "テストファースト実装", "implement task", "実装を開始", "クイック修正", "quick fix", "dev-impl auth 001". TDDをガードレールとしたテストファースト実装を行う。通常モード（Plan+タスク指定）とクイックモード（直接指示）に対応。
This skill should be used when the user asks to "dev-init", "技術スタックを選定", "新規プロジェクト初期化", "initialize tech stack", "プロジェクトをセットアップ", "setup project", "scaffold project", "プロジェクト作成", "tech stackを決める". インタラクティブなヒアリングでプロジェクトの技術スタックを決定し、dev-context互換のコンテキストファイルを生成する。承認制でプロジェクトスキャフォールディングも実行可能。
| name | dev-navigate |
| description | This skill should be used when the user asks to "dev-navigate", "どこから始めれば", "何を使えばいい", "スキルを選んで", "ナビ", "navigate", "which skill", "how to start", "開発の進め方", "何から始める". 開発者がやりたいことをヒアリングし、最適なtsumikiスキルとその実行順序をナビゲーションする。 |
開発者がやりたいことを対話で把握し、最適な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 で画面の動作確認・視覚テストを行い、問題を検出・記録する |
AskUserQuestion で以下を質問する:
質問: 「今やりたいことに一番近いのはどれですか？」
| 選択肢 | 説明 |
|---|---|
| アイデアを整理してPRDにしたい | まだ構想段階。アイデアを実現可能なPRDに落とし込みたい |
| 既存コードに変更を加えたい | 既に動いているコードに機能追加や変更をしたい |
| すぐに実装・修正に入りたい | 要件やplanは明確。実装作業を始めたい |
| テスト・画面確認をしたい | 実装済みのコードの検証や Web 画面の動作確認をしたい |
| エラーやバグを修正したい | テスト失敗、ビルドエラー、画面の不具合などを直したい |
| 画面仕様やテスト計画を最新化したい | ソースコード変更後に画面仕様やテスト計画を差分更新したい |
Q1の回答に応じて分岐する。
提案スキル: 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` — タスクごとに実装
追加質問 Q2 に進む（Step 3）。
提案スキル: dev-impl
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dev-impl`
- Planとタスクがある場合: `/dev-impl <plan-name> <task-id>`
- 小さな修正の場合: `/dev-impl "修正内容"`（クイックモード）
- 複数タスクを自動実行する場合: `/dev-run <plan-name> <from> <to>`
Planがまだない場合は先に `/dev-plan` でタスク分解することも検討してください。
追加質問 Q2b に進む（Step 3b）。
提案スキル: dev-debug
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dev-debug`
- テスト失敗やビルドエラーの自動検出: `/dev-debug`
- 特定のエラーを指定: `/dev-debug "エラーメッセージ"`
- Web 画面テストで検出されたエラー: `/dev-debug webtest`
修正後は `/dev-verify` で回帰確認、Web 画面の場合は `/dev-webtest retest` で再テストできます。
提案スキル: 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>`
AskUserQuestion で以下を質問する:
質問: 「既存コードの変更について、今の状況に一番近いのはどれですか？」
| 選択肢 | 説明 |
|---|---|
| 影響範囲を先に把握したい | 変更がどこに波及するかわからず不安。先に調査したい |
| 段階的な実装計画を立てたい | 影響範囲はだいたいわかるが、段階的に進めたい |
| タスク分解して計画を立てたい | 要件は明確。タスクに分解して着手したい |
提案スキル: dcs:impact-analysis（+ 連携フロー）
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dcs:impact-analysis`
まず影響範囲を可視化し、安全に変更を進められるようにします。
分析結果を踏まえて、次のステップを選択できます。
**推奨フロー:**
1. `dcs:impact-analysis` — 影響範囲を可視化
2. `dcs:incremental-dev` — 段階的な実装計画を立案（または `dev-plan` でタスク分解）
3. `dev-impl` — タスクごとに実装
提案スキル: dcs:incremental-dev
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dcs:incremental-dev`
既存コードへの変更を段階的に計画し、安全に機能追加を進めます。
**推奨フロー:**
1. `dcs:incremental-dev` — 段階的な実装計画を立案
2. `dev-impl` — タスクごとに実装
提案スキル: dev-plan
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dev-plan`
要件をインターフェースファースト設計でタスクに分解し、実装計画を作成します。
**推奨フロー:**
1. `dev-plan` — 要件からタスク分解
2. `dev-impl` — タスクごとに実装
3. `dev-verify` — 実装完了の検証
AskUserQuestion で以下を質問する:
質問: 「テスト・確認について、今の状況に一番近いのはどれですか？」
| 選択肢 | 説明 |
|---|---|
| Plan 単位でテスト・ビルドを一括検証したい | 実装が一通り終わった。全体の整合性を確認したい |
| Web 画面の動作確認をしたい | ブラウザ上で画面が正しく動くか確認したい |
| テスト計画を作ってから体系的にテストしたい | dev-plan の成果物からテスト計画を自動生成してテストしたい |
提案スキル: dev-verify
提案メッセージ:
## Nav 結果
**推奨スキル:** `/dev-verify`
Plan 内の全タスクの完了状態を確認し、テスト・ビルド・Lint・カバレッジを一括検証します。
**推奨フロー:**
1. `dev-verify <plan-name>` — 全体検証
2. `dev-debug` — 問題があれば修正
提案スキル: 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` で再確認できます。
提案スキル: 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` — 修正確認
提案メッセージを出力した後、AskUserQuestion で起動確認する:
質問: 「推奨スキルを起動しますか？」
| 選択肢 | 説明 |
|---|---|
| 起動する | 推奨フローの最初のスキルを起動します |
| 起動しない | 提案内容を参考に、自分のタイミングで実行します |