features.json を読み込み、pending な機能を1件ずつ tdd-guide エージェント(内部で tdd-cycle を使用)で実装するスキル。 Context anxiety(トークン上限接近による焦り)と Context rot(情報劣化)を防ぐため、 機能単位のループ・状態管理・implementation-notes.md への記録を担う。 builder エージェントが実装フェーズを開始するときは必ずこのスキルを呼ぶ。
中文简介正在准备中。当前显示原文说明。
Planner→Builder→EvaluatorのLong-Runningエージェントハーネスで複雑なタスクを実装します。plannerがfeatures.jsonに機能を分解し、builderがTDDで1機能ずつ実装し、evaluatorがPASSするまでbuilderを繰り返します。
「〇〇を作って」「実装して」「long-running」などのリクエストで起動します。
中文简介正在准备中。当前显示原文说明。
安装前可以查看交给 AI 代理的指令内容。
3つの専門エージェントをループ構造で連携し、複雑なタスクを品質保証しながら実装します。
Planner ──→ Builder ──→ Evaluator
↑ NEEDS REVISION │
└──────────────────┘ (最大3回/機能)
全 feature PASS → FINAL-SUMMARY
Harness(orchestrator)とは: このスキルを実行しているセッション自身(Claude Code の main セッション)がハーネスです。ハーネスは
Agentツールで各専門エージェントを順次起動し、フェーズ間でfeatures.jsonの状態管理を担います。Planner・Builder・Evaluator はそれぞれ別のAgent(subagent_type="planner" / "builder" / "evaluator")呼び出しとして起動されます。
迷ったら: 「機能を複数に分解できるか?」を問え。NOなら本スキル不要。
planner エージェントが Read/Grep/Glob のみでじっくり仕様をほぐしてから builder へ渡す。
1機能 = 1セッション原則。状態は features.json に外部化し、新しいコンテキストでは JSON を読み直して再開する。
evaluator エージェントは builder のコンテキストを一切引き継がない新規エージェントとして起動する。Self-leniency(実装者による甘い自己評価)を防ぐ。
⚠️ Context anxiety 対策: コンテキスト制限に近づいても、タスクを「完了」とマークしてはならない。 必ず外部ファイルに現在状態を保存してから
/compactすること。
同一リポジトリで複数タスクを並行・逐次に扱えるよう、実行ごとにサブディレクトリを切る。
.claude/orchestrate/
├── {session-slug}/ ← タスクごとのディレクトリ
│ ├── features.json
│ ├── plan.md
│ ├── builder-notes-*.md
│ ├── evaluation-*.md
│ ├── FINAL-SUMMARY.md
│ └── skill-usage.json
└── {another-session}/
└── ...
session-slug の決め方:
{kebab-case-task-name} (例: user-auth){YYYY-MM-DD}-{kebab-case-task-name} (例: 2026-05-12-user-auth)起動時の処理:
ls .claude/orchestrate/ で確認し、再開候補があればユーザーに提示する全エージェントの共有状態ファイル。.claude/orchestrate/{session-slug}/features.json に配置する。
planner エージェントが生成するスキーマに、harness がランタイム状態フィールドを追加する:
{
"version": "1.0",
"metadata": {
"plan_ref": "plan.md",
"generated_at": "ISO8601"
},
"features": [
{
"id": "FEATURE-001",
"name": "機能名",
"sequence": 1,
"description": "詳細説明",
"scope": {
"files_to_create": [],
"files_to_modify": [],
"files_to_delete": []
},
"acceptance_criteria": ["テスト項目1", "テスト項目2"],
"test_strategy": {
"unit_tests": ["test_foo_success"],
"integration_tests": [],
"edge_cases": ["invalid_input"]
},
"pre_conditions": [],
"post_conditions": [],
"rollback_strategy": "緊急対応手順",
"status": "pending",
"loop": 0,
"evaluator_feedback": null
}
],
"implementation_notes": {
"skill_usage_ref": ".claude/orchestrate/skill-usage.json",
"context_checkpoints": [
{
"after_feature": "FEATURE-001",
"save_artifacts": ["src/example.py", "tests/test_example.py"]
}
]
}
}
status の遷移:
pending → in_progress → done
→ blocked (loop >= 3 かつ NEEDS REVISION 残存)
エージェント: planner
目的: タスクを最小機能単位に分解し features.json と plan.md を生成する
出力:
.claude/orchestrate/{session-slug}/plan.md(15セクション実装計画).claude/orchestrate/{session-slug}/features.json(builder への入力)実行内容:
planner エージェントは内部で issue-plan スキルを使用して計画を作成するfeatures.json の各 feature に status: "pending", loop: 0, evaluator_feedback: null を追加する完了後:
features.json をユーザーに提示し承認を得るAskUserQuestion で確認してから進むエージェント: builder
目的: features.json の status: "pending" な feature を 1件だけ TDD で実装する
出力: コード変更 + .claude/orchestrate/{session-slug}/builder-notes-{FEATURE-ID}.md
実行内容:
features.json を読み込み、status: "pending" かつ pre_conditions の feature が全て done なものを sequence 順に1件選択するfeatures.json の該当 feature の status を "in_progress" に更新するbuilder エージェントは内部で build-cycle スキルを使用して TDD 実装するbuilder-notes-{FEATURE-ID}.md に保存するbuilder エージェントへ渡すプロンプトには必ず SESSION_DIR を含めること:
SESSION_DIR: .claude/orchestrate/{session-slug} features.json のパス: {SESSION_DIR}/features.json skill-usage.json のパス: {SESSION_DIR}/skill-usage.json 出力ノート: {SESSION_DIR}/builder-notes-{FEATURE-ID}.mdbuild-cycle スキルは
features.jsonを相対パスで参照するため、エージェントは作業ルートから当該パスで読むこと。
evaluator_feedback がある場合(ループバック時):
features.json の evaluator_feedback を読み、指摘事項に対応するbuilder-notes-{FEATURE-ID}-v{N}.md(上書き禁止)完了後: builder-notes-{FEATURE-ID}.md を保存し、Evaluator フェーズへ渡す
エージェント: evaluator
⚠️ Uncorrelated Evaluator:
evaluatorエージェントはbuilderのコンテキストを一切引き継がない。 新規エージェントとして起動すること。Self-leniency 防止が目的。
目的: 実装した feature を4軸ルーブリックで定量評価し、Builder ループを制御する
入力:
features.json(feature の acceptance_criteria・DoD)builder-notes-{FEATURE-ID}.mdplan.md(DoD セクション参照用)出力: .claude/orchestrate/evaluation-{FEATURE-ID}.md
evaluator エージェントの評価軸(4軸×5段階):
| 軸 | 概要 | PASS 基準 |
|---|---|---|
| 機能性 | DoD・AC 達成度 / Playwright UI 検証 | 全 DoD 項目達成、主要機能すべてOK |
| 技術的実行 | テストカバレッジ・コード品質・全テスト PASS | カバレッジ ≥ 70%、全テスト PASS |
| デザイン品質 | 視覚一貫性・UX・アクセシビリティ(FE のみ) | 基本レイアウトOK(N/A 許容) |
| 独創性 | 問題解決のアプローチ・コードの洗練度 | 標準的な実装以上 |
総合スコアの計算: 4 軸の算術平均(各軸 1〜5 点)。デザイン品質が N/A の場合は残り 3 軸で平均を算出する。
判定基準(evaluator エージェントの出力に従う):
| 条件 | 判定 | 次のアクション |
|---|---|---|
| 即 NEEDS REVISION 条件(任意軸1点 / 軸2が2点以下 / DoD 未達 / Critical UI バグ)または 総合スコア < 4.0 かつ feature.loop < 3 | NEEDS REVISION | features.json を更新して Builder へループバック |
| 総合スコア ≥ 4.0 かつ 即 NEEDS REVISION 条件なし | PASS | features.json の status を done に更新、次 feature へ |
| feature.loop >= 3 かつ NEEDS REVISION | BLOCKED | status を blocked に更新、ユーザーへエスカレーション |
features.json の更新(Harness が evaluator 結果を受けて更新する):
// NEEDS REVISION 時
{
"status": "pending",
"loop": 2,
"evaluator_feedback": "機能性 2/5: パスワードリセット未実装(DoD 項目あり)。技術的実行 3/5: カバレッジ 68%"
}
// PASS 時
{
"status": "done",
"loop": 1,
"evaluator_feedback": null
}
// BLOCKED 時
{
"status": "blocked",
"loop": 3,
"evaluator_feedback": "未解決: ..."
}
features.json を読む
↓
pending feature が残っている?
├── YES
│ ↓
│ builder で実装(build-cycle 経由)
│ ↓
│ evaluator で評価(4軸ルーブリック + Playwright)
│ ├── PASS → status = done → 次のループへ
│ ├── NEEDS REVISION → status = pending, loop++, feedback 記録 → builder へ戻る
│ └── BLOCKED → status = blocked → ユーザーへ通知、次の feature へ
└── NO
↓
全 feature が done / blocked?
├── 全 done → FINAL-SUMMARY 生成して完了
└── blocked あり → blocked 一覧をユーザーへ報告して完了
# 既存セッション確認
ls .claude/orchestrate/ 2>/dev/null || echo "(なし)"
2026-05-12-user-authSESSION_DIR=".claude/orchestrate/{session-slug}" として以降のパスに使うmkdir -p "$SESSION_DIR"
planner エージェントを起動
→ {SESSION_DIR}/plan.md + {SESSION_DIR}/features.json を生成
→ ユーザー承認を得る
{SESSION_DIR}/features.json から pending feature を sequence 順に 1件選択
↓
builder エージェントを起動(build-cycle スキル経由で TDD 実装)
→ {SESSION_DIR}/builder-notes-{FEATURE-ID}.md を出力
↓
evaluator エージェントを起動(Uncorrelated、新規コンテキスト)
→ {SESSION_DIR}/evaluation-{FEATURE-ID}.md を出力
├── PASS → features.json 更新(done)→ 次の feature へ
├── NEEDS REVISION → features.json 更新(feedback 記録)→ builder へ戻る
└── BLOCKED → features.json 更新(blocked)→ 次の feature へ
全 feature が done または blocked
↓
{SESSION_DIR}/FINAL-SUMMARY.md を生成
# Final Summary
**完了日時**: YYYY-MM-DD HH:MM
**完了率**: N/M features (XX%)
## 完了した機能
| ID | 名前 | ループ数 | 総合スコア |
|---|---|---|---|
| FEATURE-001 | ... | 1 | 4.3/5 |
## ブロックされた機能
| ID | 名前 | 未解決の問題 |
|---|---|---|
| FEATURE-003 | ... | ... |
## 成果物一覧
- `{SESSION_DIR}/features.json` — 機能仕様と最終ステータス
- `{SESSION_DIR}/plan.md` — 実装計画
- `{SESSION_DIR}/builder-notes-{id}.md` — 各機能の実装ノート
- `{SESSION_DIR}/evaluation-{id}.md` — 各機能の evaluator レポート
- `{SESSION_DIR}/skill-usage.json` — スキル呼び出しログ(tdd-cycle の RED/GREEN/REFACTOR 実行履歴)
/long-running Claude.ai のクローンを作りたい
.claude/orchestrate/{session-slug}/ が作成された{SESSION_DIR}/features.json が生成され、ユーザーに承認されたdone または blocked{SESSION_DIR}/evaluation-{id}.md が存在する{SESSION_DIR}/FINAL-SUMMARY.md が生成されている{SESSION_DIR}/skill-usage.json に各 feature の RED/GREEN/REFACTOR ログが記録されているissue-plan スキル経由で features.json を生成build-cycle スキル経由で TDD 実装还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
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".
中文简介正在准备中。当前显示原文说明。
任意のタスク(GitHub Issue・自由記述リクエスト・口頭要件)を起点に、受け入れ条件確認・スコープ定義・影響分析・テスト戦略を含む実装計画(15セクション)と、builder エージェントへ渡す features.json を生成します。「〇〇を作って」「実装計画を作って」「Issue
中文简介正在准备中。当前显示原文说明。