菜单
This skill should be used when the user asks to "dev-verify", "実装の検証", "完了チェック", "verify implementation", "全テスト実行", "run all tests", "dev-verify auth". Plan単位で全タスクの完了状態とテスト・ビルド・Lintの整合性を検証し、レポートを出力する。
用 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-verify |
| description | This skill should be used when the user asks to "dev-verify", "実装の検証", "完了チェック", "verify implementation", "全テスト実行", "run all tests", "dev-verify auth". Plan単位で全タスクの完了状態とテスト・ビルド・Lintの整合性を検証し、レポートを出力する。 |
| argument-hint | <plan-name> |
Plan単位ですべてのタスクの完了状態を確認し、全テスト実行・ビルド・Lint・ファイルサイズチェックを行い、検証レポートを docs/dev/plans/<plan-name>/reports/ に出力する。
dev-context → dev-plan → dev-impl → [dev-verify]
↘ dev-debug
/dev-verify <plan-name>
docs/dev/plans/<plan-name>/tasks/ 内の全タスクファイルを読み込み、フロントマターの status を確認する。
done → Step 2 へ進むpending / in_progress のタスクがある → ユーザーに未完了タスクの一覧を報告し、続行するか確認する（AskUserQuestion）docs/dev/context.md からテスト実行コマンドを取得し、全テストを実行する。
# context.md の Test Framework セクションからコマンドを取得
<test-command>
テスト結果を記録する: passed / failed / skipped の件数。
docs/dev/context.md の Test Framework セクションから Coverage Command と Coverage Threshold を取得し、プロジェクト全体のカバレッジを計測する。
[no test files] は 0% として扱うコンパイル言語やビルドステップがある場合、ビルドコマンドを実行する（context.md から取得）。
インタープリタ言語でビルドステップがない場合はスキップする。
context.md に Lint コマンドが記載されている場合、実行する。記載がない場合はスキップする。
Planで変更・作成されたファイル（各タスクファイルの Files セクションから収集）の行数を確認する（絶対パスを使用）:
wc -l "$(git rev-parse --show-toplevel)/<ファイルの相対パス>"
500行を超えるファイルがあれば警告として記録する。
Plan内の全タスクの確信度レポートを集約する:
🔴 が残っている場合は明確に警告する。
検証結果を docs/dev/plans/<plan-name>/reports/verify-YYYY-MM-DD.md に出力する。
# Verification Report - YYYY-MM-DD
## Plan: <plan-name>
## Summary
| Item | Result |
|------|--------|
| Tasks | X/Y completed |
| Tests | Z passed, W failed, V skipped |
| Coverage | X/Y packages above threshold (threshold: 80%) |
| Build | OK / NG / N/A |
| Lint | OK / NG / N/A |
| 500-line rule | OK / X files over limit |
## Task Status
| ID | Title | Status |
|----|-------|--------|
| 001 | ... | done |
| 002 | ... | done |
## Test Results
[テスト実行の出力サマリー]
[失敗テストがある場合は詳細]
## Coverage Results
| パッケージ | カバレッジ | 閾値 | 結果 |
|-----------|----------|------|------|
| internal/handler | XX.X% | 80% | OK / NG |
[閾値未達パッケージの詳細（ある場合）]
## File Size Check
[500行超過ファイルの一覧（ある場合）]
## Confidence Summary
### 🟡 妥当な推測（要確認）
- [ファイル](パス) — [確認すべき点]
### 🔴 AI推論補完（人間の確認必須）
- [ファイル](パス) — [判断が必要な理由]
## Issues Found
[検出された問題の詳細]
## Recommendations
[問題がある場合の次アクション提案]
- テスト失敗 → `/dev-debug` の使用を推奨
- 500行超過 → `/dev-impl` のリファクタリングを推奨
- 🔴 残存 → 該当ファイルの人間レビューを推奨
プロジェクトルートに docker-compose.yml または docker-compose.yaml が存在するか確認する。存在する場合:
docker compose down を実行してコンテナを停止する$(git rev-parse --show-toplevel) でルートを取得）