메뉴
This skill should be used when the user asks to "dev-debug", "テストが失敗する", "ビルドエラーを直して", "デバッグ", "debug failing tests", "fix build error", "エラーを修正", "コンパイルエラー", "環境の問題を解決". テスト失敗、ビルドエラー、環境問題など様々なエラーパターンをカテゴリ別に診断し、最小コンテキストで修正する。
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-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互換のコンテキストファイルを生成する。承認制でプロジェクトスキャフォールディングも実行可能。
This skill should be used when the user asks to "dev-navigate", "どこから始めれば", "何を使えばいい", "スキルを選んで", "ナビ", "navigate", "which skill", "how to start", "開発の進め方", "何から始める". 開発者がやりたいことをヒアリングし、最適なtsumikiスキルとその実行順序をナビゲーションする。
| name | dev-debug |
| description | This skill should be used when the user asks to "dev-debug", "テストが失敗する", "ビルドエラーを直して", "デバッグ", "debug failing tests", "fix build error", "エラーを修正", "コンパイルエラー", "環境の問題を解決". テスト失敗、ビルドエラー、環境問題など様々なエラーパターンをカテゴリ別に診断し、最小コンテキストで修正する。 |
| argument-hint | <error description> |
テスト失敗、コンパイルエラー、環境問題など、様々なエラーパターンに対応する集中デバッグスキル。エラーをカテゴリ分類し、それぞれに最適な診断・修正戦略を適用する。最小コンテキストでの高速解決を目指す。
dev-context → dev-plan → dev-impl → dev-verify
↘ [dev-debug] ↗
↑
dev-webtest → [dev-debug webtest] → 「/dev-webtest retest で再テストしてください」
↑ │
└──────── retest ────────────────────────────┘
dev-impl で解消できないエラーが発生した場合、dev-verify で問題が検出された場合、または dev-webtest で検出された画面系エラーの修正に使用する。
/dev-debug # 自動検出モード
/dev-debug "エラーメッセージや状況の説明" # 手動指定モード
/dev-debug webtest # webtest エラー修正モード
| カテゴリ | 例 | 診断アプローチ | 典型的な修正 |
|---|---|---|---|
| コンパイル/型エラー | 型不一致、missing import、構文エラー | エラーメッセージの直接分析 | 型定義修正、import追加 |
| テスト失敗 | assertion失敗、タイムアウト | 期待値と実際の差分分析 | ロジック修正 or テスト修正 |
| ランタイムエラー | null参照、パニック、未処理例外 | スタックトレース分析 | エラーハンドリング追加 |
| 環境・設定 | 依存関係エラー、設定ミス、パス問題 | 設定ファイル・環境変数チェック | 設定修正、依存追加 |
| Lint/フォーマット | スタイル違反、未使用変数 | Lint出力分析 | 自動修正 or コード調整 |
| 依存関係 | バージョン競合、パッケージ不足 | lock file/パッケージ分析 | バージョン調整、パッケージ追加 |
| webtest エラー | 視覚崩れ、a11y違反、レスポンシブ不備、フォームバリデーション不備、シナリオ失敗 | error.md の検出内容・再現手順を分析 | CSS/HTML修正、バリデーション追加、機能バグ修正 |
docs/dev/context.md からテスト実行コマンドを取得するユーザーが提供したエラー情報を分析する。
webtest）docs/dev/webtests/errors/ を Glob で走査し、全 error.md を取得するstatus: open のものだけ収集するseverity 順にソートする（critical → major → minor）/dev-webtest retest での再テストを案内）エラーメッセージのパターンマッチでカテゴリを判定する:
TypeError, SyntaxError, Cannot find module, missing import → コンパイル/型エラーAssertionError, expect(, assert, test failed → テスト失敗null, undefined, panic, NullPointerException, segfault → ランタイムエラーENOENT, Permission denied, port already in use, env → 環境・設定eslint, prettier, clippy, unused variable → Lint/フォーマットERESOLVE, version conflict, peer dependency → 依存関係最小コンテキスト: エラー箇所のファイルのみ読み込む。
最小コンテキスト: テストファイル + 対象実装ファイル。
最小コンテキスト: スタックトレースに含まれるファイル。
最小コンテキスト: 設定ファイル群。
最小コンテキスト: Lint出力のみ。
最小コンテキスト: パッケージ定義ファイル + lock file。
最小コンテキスト: error.md + 関連するソースファイル。
error.md の step フィールドに応じて診断アプローチを切り替える:
| step | 主な修正対象 | 診断アプローチ |
|---|---|---|
3-visual | CSS、テンプレート | error.md の検出内容からレイアウト崩れの原因を特定し、CSS/テンプレートを修正 |
4-a11y | HTML属性 | 不足している alt、label、aria 属性、heading 階層を特定して追加 |
5-responsive | メディアクエリ、CSS | 問題のビューポートサイズに対応するメディアクエリやレイアウト CSS を修正 |
6-form | バリデーションロジック | サーバー/クライアントのバリデーション処理を特定して修正。XSS/SQLi はサニタイズ処理を追加 |
2a-scenario / 2b-monkey | 機能実装 | 再現手順と期待される状態から機能バグを特定し、実装を修正 |
報告フォーマット（通常モード）:
## dev-debug 結果
### 検出されたエラー
- カテゴリ: [エラーカテゴリ]
- 原因: [根本原因の説明]
### 適用した修正
- [ファイル](パス): [修正内容]
### 検証結果
- 対象エラー: 解消
- 回帰テスト: passed / failed
### 確信度
- 🔵/🟡/🔴: [修正の確信度と理由]
報告フォーマット（webtest モード）:
## dev-debug webtest 結果
### 修正したエラー
| # | error.md | severity | step | 修正内容 |
|---|----------|----------|------|---------|
| 1 | docs/dev/webtests/errors/.../ | critical | 2a-scenario | [修正内容] |
### 修正できなかったエラー
| # | error.md | severity | step | 理由 |
|---|----------|----------|------|------|
（なければ「なし」）
### 次のステップ
`/dev-webtest retest` で再テストし、修正が反映されているか確認してください。
3サイクルで解決できない場合:
コード修正時に、既存の Intent コメント（🔵🟡🔴）を維持し、修正箇所には適切に追加・更新する。
// 🟡 Intent: nil チェックを追加。元のコードではリポジトリが nil を返すケースが
// 未考慮だったため、エラーとして返却するガード句を追加。
func (s *TodoService) GetByID(ctx context.Context, id string) (*model.Todo, error) {
$(git rev-parse --show-toplevel) でルートを取得）