任意のタスク（GitHub Issue・自由記述リクエスト・口頭要件）を起点に、受け入れ条件確認・スコープ定義・影響分析・テスト戦略を含む実装計画（15セクション）と、builder エージェントへ渡す features.json を生成します。「〇〇を作って」「実装計画を作って」「Issue
インストールする前に、エージェントに与えられる指示の中身を確認できます。
任意の入力（GitHub Issue・自由記述リクエスト・口頭要件）を起点に、受け入れ条件の確認・スコープ定義・影響分析・テスト戦略を含む実装計画を作成します。
入力の種類に応じて情報を収集する：
#123, https://github.com/org/repo/issues/123）
→ gh CLI または WebFetch でタイトル・本文・ラベルを取得する収集すべき情報：
Grep/Glob/Read で関連ファイル・既存パターン・影響範囲を調査する。
以下の15セクションテンプレートを順に埋める。曖昧な点は「1. AC確認」の質問リストに追記する。
実装計画（セクション4の実装方針）が固まったら、各ステップを1機能単位に分解して features.json を生成する。
このファイルが builder エージェントへの唯一の入力となる。
出力ルール（重要）: features.json はチャット内にインライン出力すること。ファイルへの保存はユーザー承認後にユーザーが行う。エージェントは planning フェーズ中に disk へ保存しない。
生成ルール：
tests には「最初は失敗するテスト」を具体的に列挙する（TDD: Red → Green）dependencies には先行 feature の id を列挙するstatus は常に "pending" で初期化する「13. 確認事項」の未決定項目をユーザーに提示し、回答を得る。
すべての確認事項が解消され、ユーザーが承認するまで実装に進まない。
# タスク実装計画
## タスク情報
**タスクID**: [#XXX（GitHub Issue の場合）/ なし]
**タイトル**: [タスクのタイトル・リクエスト概要]
**入力形式**: [GitHub Issue / 自由記述 / 口頭リクエスト]
**優先度**: [High / Medium / Low / 未設定]
**背景・目的**: [なぜこのタスクが必要か]
---
## 1. Acceptance Criteria（受け入れ条件）の確認
### 明記されている条件
- [ ] 条件1
- [ ] 条件2
### 曖昧な点・確認が必要な項目
- [ ] 質問1
- [ ] 質問2
---
## 2. スコープ定義
### 対象（In Scope）
- 機能A
- 機能B
### 対象外（Out of Scope）
- 機能X（別Issue）
---
## 3. 調査結果
### 関連ファイル・モジュール
- `path/to/file1.ts` — [役割]
- `path/to/file2.ts` — [役割]
### 既存パターン・参考実装
- パターン1：[説明 + ファイルパス]
### 影響範囲
- **DB**: [スキーマ変更有無]
- **API**: [契約変更有無・後方互換性]
- **他システム**: [連携有無]
- **ドキュメント**: [更新対象]
---
## 4. 実装方針
### Phase 1: [フェーズ名]
1. [ステップ1] — `path/to/file1.ts`
- 変更内容: [詳細]
- 依存: なし
2. [ステップ2] — `path/to/file2.ts`
- 変更内容: [詳細]
- 依存: ステップ1
### Phase 2: [フェーズ名]
1. [ステップ3] — [詳細]
### 影響ファイル一覧
| ファイル | 変更内容 | 影響度 | 後方互換性 |
|--------|---------|------|---------|
| path/to/file1.ts | 新規メソッド | Medium | 互換 |
| path/to/file2.ts | 既存関数修正 | High | 要確認 |
---
## 5. DBスキーマ変更
- [ ] 変更なし
- [ ] 変更あり → 内容:
```sql
-- Migration内容
ALTER TABLE ...
GET /api/v1/endpoint
Request: {...}
Response: {...}
test_XXX_returns_Y_when_given_Z()test_edge_case_XXX()test_POST_creates_record_and_returns_201()test_validation_returns_400_for_invalid_input()test_user_can_complete_full_flow()リスク1: [説明]
リスク2: [説明]
実装前にユーザーへの確認が必要：
| フェーズ | 推定時間 | 根拠 |
|---|---|---|
| Phase 1: コア実装 | Xh | [根拠] |
| Phase 2: 統合・検証 | Yh | [根拠] |
| Phase 3: レビュー・修正 | Zh | [根拠] |
| 合計 | XXh |
planner-builder 分離のための外部アーティファクト。
builder エージェントはこの JSON を読み込み、status: "pending" の feature を1件ずつ実装する。
{
"task": {
"id": "#XXX",
"title": "[タスクのタイトル]",
"source": "github_issue | free_form | other",
"priority": "High | Medium | Low | unknown"
},
"meta": {
"created_at": "YYYY-MM-DD",
"total_estimated_hours": 0
},
"features": [
{
"id": "feat-001",
"title": "[短い機能名]",
"description": "[この feature が実装する内容の1〜2行説明]",
"phase": 1,
"acceptance_criteria": [
"[この feature が満たす AC の番号または文章]"
],
"files": {
"create": ["path/to/new_file.ts"],
"modify": ["path/to/existing_file.ts"]
},
"tests": {
"unit": [
{
"name": "test_[function]_returns_[expected]_when_[condition]",
"description": "[テストが検証すること]",
"file": "tests/unit/test_xxx.py"
}
],
"integration": [
{
"name": "test_[endpoint]_[action]_returns_[status]",
"description": "[テストが検証すること]",
"file": "tests/integration/test_xxx.py"
}
],
"e2e": []
},
"dependencies": [],
"risk": "Low | Medium | High",
"estimated_hours": 0,
"status": "pending"
},
{
"id": "feat-002",
"title": "[短い機能名]",
"description": "[説明]",
"phase": 1,
"acceptance_criteria": ["[AC]"],
"files": {
"create": [],
"modify": ["path/to/file.ts"]
},
"tests": {
"unit": [],
"integration": [
{
"name": "test_[name]",
"description": "[説明]",
"file": "tests/integration/test_yyy.py"
}
],
"e2e": []
},
"dependencies": ["feat-001"],
"risk": "Medium",
"estimated_hours": 0,
"status": "pending"
}
]
}
フィールド説明
| フィールド | 説明 |
|---|---|
id | 連番ID。feat-001 形式 |
title | builder が1セッションで実装する機能の名前 |
description | 何をするかの説明（実装者が読む） |
phase | 実装フェーズ番号（セクション4と対応） |
acceptance_criteria | この feature が満たす AC の一覧 |
files.create | 新規作成するファイルパス |
files.modify | 変更するファイルパス |
tests.unit | 単体テスト（最初は失敗、builder が Green にする） |
tests.integration | 統合テスト（同上） |
tests.e2e | E2Eテスト（同上） |
dependencies | 先に完了が必要な feature の id 一覧 |
risk | リスク評価 |
estimated_hours | 工数見積もり（時間） |
status | pending / in_progress / done — builder が更新する |
features.json として保存features.json を読み、status: "pending" の feature を順次実装承認されるまで実装に進まないこと。
---
## 品質チェックリスト
スキル完了前の最終確認：
- [ ] 15セクションがすべて埋まっている
- [ ] `features.json` が生成されている
- [ ] 全 feature に `tests`（最初は失敗するテスト）が列挙されている
- [ ] 「13. 確認事項」の未決定項目にユーザーが回答済み
- [ ] ユーザーの承認を得ている
## 関連スキル
- **long-running**: features.json を入力として Planner→Builder→Evaluator ループで実装まで完走する（このスキルの後続）
- **tdd-cycle**: features.json の各 feature を単体で TDD 実装するフェーズ
- **planning-tests**: より詳細なテスト計画書（TEST_PLAN.md）を生成する場合
- **analyzing-requirements**: 大規模要件から DESIGN.md を先に生成する場合
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
features.json を読み込み、pending な機能を1件ずつ tdd-guide エージェント（内部で tdd-cycle を使用）で実装するスキル。 Context anxiety（トークン上限接近による焦り）と Context rot（情報劣化）を防ぐため、 機能単位のループ・状態管理・implementation-notes.md への記録を担う。 builder エージェントが実装フェーズを開始するときは必ずこのスキルを呼ぶ。
テストカバレッジのギャップを体系的に分析し、実際に動くテストコードを提案するスキル。 以下のようなときに使う： - テストカバレッジを改善したい・不足テストを特定したい - 「テストが足りない」「カバレッジを上げたい」「どこをテストすべき」 - 「未テストの関数」「what tests am I missing」「improve test coverage」「coverage gap」 t-wada式TDDの原則に基づき、テストの抜け漏れを特定して優先度付きで補完する。 引数: 分析対象ファイル・ディレクトリ（省略時はプロジェクト全体）
フレーキーテスト（不安定なテスト）を検出・分類・修正支援するスキル。 以下のような状況で使う： - 「テストが時々失敗する」「CI が時々落ちる」 - 「同じコードなのにテスト結果が変わる」 - 「flaky test」「不確定」「再実行すると通る」 - 「テストが不安定」「テストの信頼性が低い」 t-wada式TDDの信頼性基盤を守るために使用する。 引数で実行回数を指定可能（デフォルト: 5回）。
Uncorrelated Evaluator — 4軸ルーブリック専門エージェント（functionality-reviewer・code-reviewer・design-reviewer・originality-reviewer）と security-reviewer を5並列実行し、成果物を多面的に独立評価します。PASS / NEEDS WORK / BLOCKED 判定を返します。Self-leniency 防止のため、実装エージェントのコンテキストを引き継がない新規エージェントとして起動します。「レビューして」「評価して」「実装を確認して」などのリクエストで起動します。
Iteratively detects and auto-fixes technical debt in a codebase using three quality criteria from debt-analysis references: conditional branch simplification, encapsulation, and separation of concerns. Applies fixes directly to code, runs existing tests to verify no regressions, re-analyzes, and loops until all high-severity issues are resolved or max iterations (5) reached. Use this skill when you want to automatically improve code quality with real code changes, reduce technical debt systematically, or clean up code to meet quality standards. Trigger on phrases like "fix technical debt", "clean up code quality", "refactor and fix issues", "improve code quality automatically", "apply debt fixes", "fix code problems", "eliminate debt".
日本語の概要は準備中です。原文の説明を表示しています。
Planner→Builder→EvaluatorのLong-Runningエージェントハーネスで複雑なタスクを実装します。plannerがfeatures.jsonに機能を分解し、builderがTDDで1機能ずつ実装し、evaluatorがPASSするまでbuilderを繰り返します。「〇〇を作って」「実装して」「long-running」などのリクエストで起動します。