with one click
dev-impl
// 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-impl", "タスクを実装", "テストファースト実装", "implement task", "実装を開始", "クイック修正", "quick fix", "dev-impl auth 001". TDDをガードレールとしたテストファースト実装を行う。通常モード(Plan+タスク指定)とクイックモード(直接指示)に対応。
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-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-impl |
| description | This skill should be used when the user asks to "dev-impl", "タスクを実装", "テストファースト実装", "implement task", "実装を開始", "クイック修正", "quick fix", "dev-impl auth 001". TDDをガードレールとしたテストファースト実装を行う。通常モード(Plan+タスク指定)とクイックモード(直接指示)に対応。 |
| argument-hint | <plan-name> <task-id> | "<instruction>" |
TDDをガードレールとして、テストを先に書いてから実装するコアワークフロー。タスクファイルに基づく通常モードと、Plan不要の軽量クイックモードの2つの実行モードを持つ。
dev-context → dev-plan → [dev-impl] → dev-verify
↘ dev-debug (失敗時)
| モード | 引数 | 用途 |
|---|---|---|
| 通常モード | <plan-name> <task-id> | Planのタスクを1つ実装 |
| クイックモード | "修正指示" | 軽量な修正・調整(Plan不要) |
品質 > 速度 > トークン消費 の順で判断する。
/dev-impl <plan-name> <task-id> で実行。
インターフェースファーストで必要最小限のファイルだけ読み込む:
優先順位:
1. docs/dev/context.md(プロジェクト全体像)
2. タスクファイル(インターフェース定義・テスト方針)
3. 関連する型定義ファイル ← 必要時のみ
4. 関連する既存テストファイル(パターン参考)← 必要時のみ
5. 実装ファイル(関連関数のみ)← 必要時のみ
TodoWrite でタスク進捗のトラッキングを開始する。
タスクファイルの Test Strategy に基づきテストコードを生成する:
テストが先に通ってしまう場合は、要件やテストの妥当性を再確認する。
テストを通す最小限の実装を生成する:
/dev-debug の使用を案内するテストがGreenの状態で以下を実行する:
関連するすべてのファイルの行数を Bash で確認する(絶対パスを使用):
wc -l "$(git rev-parse --show-toplevel)/<ファイルの相対パス>"
500行を超えるファイルがある場合:
実装コードを確認し、以下の問題がないか検証する:
docs/dev/context.md の Test Framework セクションから Coverage Threshold を取得する[no test files] は 0% として扱うテスト再実行 → 成功維持を確認する。
実装した各ファイルに確信度を付与し、ユーザーに報告する:
## dev-impl 確信度レポート
### カバレッジ結果
| パッケージ | カバレッジ | 閾値 | 結果 |
|-----------|----------|------|------|
| internal/handler | 85.2% | 80% | OK |
### 🔵 前工程指示(レビュー低優先)
- [ファイル名](パス) — 既存パターン準拠
### 🟡 妥当な推測(要確認)
- [ファイル名](パス) — [確認すべき点]
### 🔴 AI推論補完(人間の確認必須)
- [ファイル名](パス) — [判断が必要な理由]
status を done に更新するプロジェクトルートに docker-compose.yml または docker-compose.yaml が存在するか確認する。存在する場合:
docker compose down を実行してコンテナを停止する/dev-impl "修正指示" で実行(Plan名なし)。
docs/dev/context.md を読み込む(あれば)タスクファイルの estimated_complexity に応じて戦略を切り替える。詳細は references/impl-strategies.md を参照。
| 複雑度 | 戦略 | テスト+実装 |
|---|---|---|
| low | バッチ生成 | テスト+実装を一括生成し、テスト実行で検証 |
| medium | 標準サイクル | テスト→Red確認→実装→Green確認 |
| high | 段階的 | 1テストずつ追加→1つずつGreenにする |
| 用途 | サブエージェントタイプ | モデル |
|---|---|---|
| 関連コード探索 | Explore | haiku |
| テスト雛形生成 | general-purpose | haiku |
| 標準実装 | メインで実行 | sonnet |
| 複雑なロジック | メインで実行 | opus |
生成するソースコードの各関数・メソッドに、設計判断の理由を示す Intent コメントを付与する。
言語のコメント構文に従い、関数・メソッドの直前に記述する:
// 🔵 Intent: タスクファイルで指定された TodoRepository インターフェースを実装。
// RETURNING 句で INSERT と ID 取得を1クエリで完結させる。
func (r *PostgresTodoRepository) Create(ctx context.Context, todo *model.Todo) error {
// 🟡 Intent: context.md のエラーハンドリング規約に準じて fmt.Errorf でラップ。
// リポジトリ層のエラーをサービス層で識別可能にするため。
func (s *TodoService) GetByID(ctx context.Context, id string) (*model.Todo, error) {
// 🔴 Intent: ページネーションのデフォルト値。前工程に指定なし。
// 一般的な Web API の慣習に基づき limit=20 を採用。
const defaultPageSize = 20
done であることを確認してから開始する/dev-context を案内する/dev-plan を案内する$(git rev-parse --show-toplevel) でルートを取得)references/impl-strategies.md — 複雑度別の実装戦略、インターフェースファースト読み込みの詳細、バッチモードの適用基準