Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From tsumiki
Test-first implementation workflow with TDD guardrails. Runs in normal mode (plan + task) or quick mode (direct instruction). Generates tests, implements, refactors, checks coverage and quality.
npx claudepluginhub classmethod/tsumiki --plugin tsumikiHow this skill is triggered — by the user, by Claude, or both
Slash command
/tsumiki:dev-impl <plan-name> <task-id> | "<instruction>"<plan-name> <task-id> | "<instruction>"The summary Claude sees in its skill listing — used to decide when to auto-load this skill
TDDをガードレールとして、テストを先に書いてから実装するコアワークフロー。タスクファイルに基づく通常モードと、Plan不要の軽量クイックモードの2つの実行モードを持つ。
Implements segmented tasks sequentially or by user specification, leveraging TDD commands for high-quality code. Integrates with Claude Code task system and documentation.
Autonomous implementer agent that executes a single task end-to-end using TDD and verifies with Agent Validator. Activates for requests like "implement this task" or "finish this ticket".
Implements task specs via TDD (RED-GREEN-REFACTOR cycle), one test at a time from PLAN-*.md files. Collaborative mode pauses per step; auto mode runs autonomously.
Share bugs, ideas, or general feedback.
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 — 複雑度別の実装戦略、インターフェースファースト読み込みの詳細、バッチモードの適用基準