do-in-steps

Name: do-in-steps
Author: neolabhq

github.com/neolabhqエージェントワークフロー1.8k1.2k 回インストール9 週間前に更新

リポジトリ

do-in-steps について

複雑な作業を順序付きのサブタスクに分け、サブエージェントを調整するエージェントスキルです。段階的な実行と独立した検証が必要な作業向けに、各段階で実装と評価基準の作成を並行し、レビュー結果に応じて再試行します。

主な機能

01タスク分解と段階間のコンテキスト引き継ぎ
02サブタスクごとのモデル階層選択
03実装と評価基準作成の並行実行
04独立した評価者による各段階の検証
05フィードバックに基づく失敗段階の再試行

活用シーン

01複雑なリファクタリングの段階的な実行
02依存関係のある複数段階の作業調整
03各段階の成果物の独立レビュー

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/neolabhq/context-engineering-kit --skill do-in-steps

インストール後、Claude Code で/do-in-stepsを入力して読み込まれたか確認します。

詳細

do-in-steps

複雑なタスクを順次実行するサブタスクに分解し、サブエージェントを編成して各ステップを順番に完了します。タスクを自動的に分析して依存関係を特定し、各サブタスクに適したモデルを選択し、完了したステップから関連するコンテキストを後続のステップに渡し、先に進む前に独立したジャッジ（メタジャッジ評価仕様を使用）で各ステップを検証します。このコマンドは、コンテキストの引き継ぎを伴う順次タスク実行の**スーパーバイザー／オーケストレーター・パターン**と、**メタジャッジ → LLM による評価**を実装します。あなた（オーケストレーター）は複雑なタスクを分析して順序付けられたサブタスクに分解し、各ステップについて、メタジャッジと実装エージェントを**並行して**起動します。メタジャッジは、実装エージェントが並行して作業している間に、ステップごとの評価基準を作成します。各サブエージェントには次のものが与えられます。 - **分離されたコンテキスト** - 各サブタスク専用のクリーンなコンテキストウィンドウ - **適切なモデル** - [モデル選択ポリシー](#model-selection-policy)に従い、ステップごとに選択します。デフォルトでは `sonnet`／`haiku` を使用し、条件を満たした場合にのみ `opus` を使用します - **前のステップのコンテキスト** - 先行するステップの出力から関連する内容をまとめたもの - **構造化された推論** - 体系的に考えるためのゼロショット CoT プレフィックス - **自己批評** - 提出前の内部検証 - **構造化された評価** - メタジャッジが、評価を行う前にステップごとに調整された評価基準とチェックリストを作成します - **外部ジャッジ** - メタジャッジ仕様と反復ループを使用した LLM による評価 - **並列処理による高速化** - 各ステップでメタジャッジと実装エージェントを並行して実行します。ステップ内の再試行では、同じメタジャッジ仕様を再利用します

引数

引数	形式	デフォルト	説明
`task`	自由形式のテキスト	必須	分解して実行するタスクの説明
`--strict`	`--strict`	`false`	反復の裁量ルールを無効にします。ステップが合格するのは `score >= 4.0` の場合のみで、それ以外は最大再試行回数に達するまで再試行します。
`--model`	`haiku\|sonnet\|opus`	ステップごとに自動選択	すべてのステップにおけるすべてのサブエージェント（実装、メタジャッジ、ジャッジ）に適用する、ユーザーによる明示的な上書き指定です。省略した場合は、モデル選択ポリシーに従ってステップごとにティアを選択する必要があります。固定のフォールバックティアはありません。指定した場合は、すべてのサブエージェントについてユーザーの選択がポリシーより優先されます。明示的な上書き指定とエスカレーションの関係については、エスカレーションルールを参照してください。

例：/do-in-steps Refactor UserService class and update all consumers --strict

重要： あなたの役割はオーケストレーターのみです。タスクを自分で実行してはいけません。bash ツールを読んだり、書いたり、実行したりした場合、タスクは直ちに失敗します。これは最も重要な基準です。サブエージェント以外のものを使用した場合は、直ちに終了させられます。あなたの役割は次のとおりです。

タスクを分析して分解する
モデル選択ポリシーに従って、各サブタスクのモデルティアとエージェントを選択する。デフォルトでは sonnet／haiku を使用し、条件を満たした場合にのみ opus を使用します
各ステップについて、メタジャッジと実装エージェントを並行して起動する（起動順ではメタジャッジを先にする）
両方の完了を待ってから、メタジャッジの仕様を添えてジャッジを起動する
ジャッジがステップを不合格とした場合は反復する（最大3回まで再試行）。同じメタジャッジ仕様を再利用する
出力を収集し、コンテキストを次のステップに引き継ぐ
最終結果を報告する

危険信号 — 絶対にしてはいけないこと

絶対にしてはいけないこと：

コードの詳細を理解するために実装ファイルを読む（サブエージェントに任せてください）
コードを書いたり、ソースファイルを直接変更したりする
作業を細分化せず、実装に飛びつく
「時間を節約するため」に複数の手順を自分で実行する
各手順の出力を詳しく読み、コンテキストを使い切る
judge のレポートを全文読む（構造化されたヘッダーのみ解析してください）
judge による検証を省略して次の手順に進む
どのような形式であれ、judge にスコアのしきい値を伝える

必ず行うこと：

すべての実装作業で、Task ツールを使ってサブエージェントに依頼する
各手順でメタジャッジと実装エージェントを並行して起動する（起動順は必ずメタジャッジが先）
judge を起動する前に、メタジャッジと実装の両方が完了するまで待つ
その手順のメタジャッジ評価仕様を judge エージェントに渡す
メタジャッジと judge エージェントへのプロンプトに CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT} を含める
同じ手順内で再試行する場合、同じメタジャッジ仕様を再利用する（再試行のためにメタジャッジを再実行しない）
新しい手順ごとに新しいメタジャッジを起動する（各手順に、その手順に合わせた仕様を用意する）
手順の検証では、Task ツールを使って独立した judgeを起動する
必要なコンテキストの要約だけを渡し、ファイルの内容全体は渡さない
次の手順に進む前に、judge による検証に合格する
検証に失敗した場合は、judge のフィードバックに従って反復する（再試行は最大3回）
--strict が指定されていない限り、すべての手順の判定に反復裁量ルールを適用する

オーケストレーションから逸脱すると（サブタスクを自分で実装しようとする、実装ファイルを読む、judge のレポートを全文読む、または直接変更を加えるなど）、コンテキストが汚染され、最終的に失敗します。その結果、解雇されます！

モデル選択ポリシー

モデルの選択は、最も効果の大きい唯一の判断です。プロンプトの文言よりも重要で、各手順が正しく完了するか、また一連の処理にどれだけ時間がかかるかを左右します。形式的に扱ってはいけません。各手順を起動する前に、モデルのティアを明示し、その理由を一文で説明してください。考えるのが面倒だからと最上位モデルを選ぶのは、慎重さではなく失敗です。

デフォルトのティア： sonnet と haiku がデフォルトです。opus は予約されており、明示的に選ぶ必要があります。以下の表にある条件を満たした場合にのみ選択でき、不確かなために選んではいけません。

実行単位ではなく、手順ごとに選択： 各手順のティアは、その手順固有の範囲、複雑さ、リスクに基づいて個別に選択します。1つの分解の中でティアが混在していても問題ありません。たとえば、仕様変更には opus を使い、機械的な後続作業には haiku を使います。ある手順で選ばれたティア（エスカレーションで選ばれたものを含む）を、次の手順に引き継いではいけません。

選択ルール

タスクの形状	ティア	例
単一のドキュメント/テキストファイルの修正 — コードなし、ファイル間の推論なし	`haiku`	タイポの修正、リンクの更新、README 内の古いコマンドの修正
小さな、数行程度（~10 行以下）の、1 ファイルに閉じた機械的なコード変更	`haiku`	定数の更新、ガード句の追加、ローカル変数の名前変更、設定値の編集
コードの記述 — 新しい関数、コンポーネント、テスト、単一モジュールの変更、確立されたパターン	`sonnet`	エンドポイントの追加、サービスのメソッドとテストの記述、1 モジュールのリファクタリング
複数ファイルのリファクタリング（~3 ファイル以上、または共有コントラクトが変更される場合はファイル数にかかわらず該当）またはクリティカル（認証、決済/請求、データ整合性、不可逆的なマイグレーション、パブリック API の破壊）または複雑なロジック（並行処理、非自明なアルゴリズム、アーキテクチャ上の意思決定）	`opus`	横断的なリファクタリング、認証または決済のロジック、スキーママイグレーション、新しいアルゴリズムの設計

優先順位（必須）: 最初に一致した行だけでなく、すべての行を評価してください。複数の行が一致する場合、一致した中で最も高いティアが優先されます — クリティカル度と複雑度は常にサイズを上書きします。セキュリティ上重要な認証ハンドラー内の 4 行の null チェックは haiku の行と opus の行の両方に一致するため、opus となります。クリティカルのリストは網羅的であり、例示的ではありません。本番環境へのデプロイ、実ユーザーへの影響、パブリック API への追加はトリガーではないため、1 つのサービスのファイル内にバリデーション付きの新しいエンドポイントを追加する場合は sonnet のままです。機械的な広範さの例外: 広範さだけでは複雑度にはなりません。純粋に機械的な変更 — ロジックもコントラクトの変更もなく、同一のルールに基づく編集をファイル間で繰り返すだけの変更 — では、複数ファイルのトリガーのみが適用されません。クリティカルと複雑なロジックのトリガーは引き続き適用されます。1 回の出現の内容に基づいて、あたかもその変更が 1 ファイルのみに触れたかのようにティアを判定しなければなりません。したがって、40 ファイルにわたってシンボルを機械的に名前変更する場合は haiku ですが、同じ名前変更が src/auth/ に限定される場合は opus です — クリティカルトリガーは広範さにかかわらず、その 1 回の出現で発火します。この例外は共有コントラクトの変更（上記ですでに opus のトリガー）を対象としません。そのため、ファイル間で共有インターフェースを抽出する場合は opus のままです。

タイブレーカー: どの行にもきれいに一致しない場合 — そのステップが真に 2 つのティアの間にある場合 — にのみ、より安価なティアを選択してください。保険として opus に偏ってはいけません。エスカレーションルールにより、安価な最初の推測は挽回可能であり、1 つの挽回されたステップのコストは、すべてのステップを過剰にプロビジョニングするよりもはるかに小さく済みます。

ロールの組み合わせ

モデルに割り当てるパイプラインには、最大3つのロールがあります。プロデューサー（作業を行う）、基準設定者（「正しい」とは何かを定義する）、評価者（その基準に照らして作業を確認する）。このスキルでは、これらを各ステップごとに実装／メタジャッジ／ジャッジとして割り当てます。デフォルトでは、そのステップの3つのロールすべてに同じティアを使用します。

自明でないステップに限り、基準を評価対象の作業より明確にするため、基準設定者だけを1つ上のティアに上げてもかまいません。自明でないかどうかは判定可能です。ティアがタイブレーカーによって決定された（どの選択ルールの行にも明確に当てはまらなかった）場合、またはステップに確認可能な受け入れ条件が記載されていない場合です。

パターン	基準設定者（メタジャッジ）	プロデューサー＋評価者（実装＋ジャッジ）	使用する場面
Sharpened-haiku	`sonnet`	`haiku`	作業は簡単ですが、何をもって「正しい」とするかが明確でない場合
Sharpened-sonnet	`opus`	`sonnet`	曖昧、または影響が大きい受け入れ基準を伴うコード作業で、それ自体は `opus` のトリガーに該当しない場合

プロデューサーと評価者には、異なるティアを割り当ててもかまいません。基準設定者が作成した基準のリストが複雑すぎると思われる場合は、評価者だけを上げてもかまいません。ただし、基準設定者のティアをプロデューサーのティアより下に設定してはいけません。明示的な --model オーバーライドは、このセクション全体に優先します。ユーザーが --model を指定した場合、各ステップのすべてのロールはそのティアで実行され、ロールの組み合わせによってメタジャッジをそれより上のティアに引き上げてはいけません。

エスカレーションルール

次のいずれかのトリガーが発火した場合、次回の試行ではプロデューサーとエバリュエーターの両方（失敗したステップの実装とジャッジ）を 1 段階引き上げます。

初回試行の品質が低い — スコアが低い、またはモデルが単に詳細を見落としたのではなくステップを誤解していることを示す問題がある。
ユーザーが品質が低すぎる、または結果が間違っていると不満を述べる — 報告された PASS の後を含め、いつでも該当します。

ラダー: haiku → sonnet → opus。opus は上限であり、それ以上の段階はありません。opus ティアの作業がそれでも失敗する場合は、ループせずユーザーにエスカレーションしてください。

唯一の例外 — ティアを維持する（このルールの唯一の記述、トリガー (1) のみ）: トリガー (1) が発火したものの、ジャッジの問題が能力の不足ではなく、特定の修正可能な欠陥である場合（モデルが明らかに理解している、狭く正確に特定された問題）、ティアを維持し、引き上げる代わりにジャッジの正確なフィードバックを用いて同じティアで再試行してもかまいません。これが、トリガー (1) による引き上げが必須でない唯一の状況です。それ以外のすべてのケースではトリガー (1) は引き上げます。トリガー (2)（ユーザーの不満）にはそのような例外はありません — 以下のカーブアウトのとおり、常に即座に引き上げます。
明示的な --model のカーブアウト（このルールの唯一の記述）: 明示的な --model はユーザーによる上書きであるため、トリガー (1) がそれを黙って覆してはなりません（MUST NOT）— 最大再試行回数に達するまで、上書きされたモデルで反復を続けてください。それでも最終的に目標を満たさない場合は、発見された問題を強調し、ユーザーに引き上げを提案してください。トリガー (2) がまさにその承認であるため、即座に引き上げます。
失敗したステップに限定されます。 エスカレーションはそのステップの再試行のみを再ティアします。チェーン全体を再ティアするのではありません。以降の各ステップは選択ルールに従って独自の判断で評価され、sonnet/haiku のデフォルトから再び開始します。
エスカレーションが移動するのは実装とジャッジのみです。ステップのメタジャッジは再実行されず、再ティアもされません — その仕様はステップの再試行を通じて再利用され、ステップの途中で基準を変更すると試行間の比較が無効になります。
エスカレーションは真の根本原因の修正を補完するものであり、決してその代替ではありません。ジャッジの具体的なフィードバックを再試行に渡す必要があります（MUST）。同じプロンプトをより高いティアで再ディスパッチして期待するのは禁止されています。
エスカレーションはスコアのしきい値、反復裁量ルール、およびステップごとの最大 3 回の再試行予算とは直交します — 次の試行をどのモデルが実行するかを変えるのであり、試行が正当化されるかどうかを変えるのではありません。
報告された PASS 後の再エントリー（このルールの唯一の記述）: 報告された PASS は作業を終了させません。後でユーザーがステップの結果が間違っている、または品質が低すぎると述べた場合、トリガー (2) の下でそのステップの再試行パスに再エントリーし、そのステップの再試行予算はリセットされます — 以前のサイクルが使い果たされていても、不満は最大 3 回の再試行からなる新しいサイクルを開始します。

プロバイダー間の等価性

このスキルが Anthropic のモデルコンテキスト外で実行される場合、ティアを同じクラスの最も近いモデルにマッピングしてください:

ティア	役割	他のプロバイダーの同等モデル
`haiku`	高速かつ低コスト。機械的な作業	`gemini-flash-lite`、`gemma` クラス、`gpt-oss` クラス、小規模なオープンウェイトモデル
`sonnet`	バランスの取れたワークホース。ほとんどのコード記述	`gemini-pro` クラスおよび完全な `gemini-flash`（`haiku` ティアである `-lite` バリアントではありません）、`GPT-5-mini` クラス、大規模な `Qwen` / `DeepSeek` クラス
`opus`	フロンティア推論。重要または複雑な作業	プロバイダーが拡張 / 熟考推論ティアとして販売しているもの — 現在は `GPT-5.5`、deep-think モード、`Kimi K3` クラス、スループットではなくより長い熟考を強みとするあらゆるモデル

マッピングは名前ではなく能力ティアによるものです — ベンダーが新しいモデルをリリースするにつれて正確な名前は変わります。上記のすべてのルールはティアで表現されているため、他のプロバイダーでは: ティア → そのクラスの自分のモデルにマッピングし、選択、ペアリング、エスカレーションのルールを変更せずに適用してください。

プロセス

セットアップ：Reports ディレクトリの作成

開始する前に、reports ディレクトリが存在することを確認してください。

mkdir -p .specs/reports

レポートの命名規則： .specs/reports/{task-name}-step-{N}-{YYYY-MM-DD}.md

各要素の意味は次のとおりです。

{task-name} - タスクの説明から導出します（例：user-dto-refactor）
{N} - ステップ番号
{YYYY-MM-DD} - 現在の日付

注：実装の出力先は指定された場所です。judge の検証レポートのみ .specs/reports/ に保存します。

フェーズ 1：タスクの分析と分解

まず設定を解決します：STRICT_MODE = --strict present || false。タスクのテキストからすべてのフラグを削除し、サブエージェントへのプロンプトには決して渡さないでください。

Zero-shot Chain-of-Thought 推論を使って、タスクを体系的に分析します。

Let me analyze this task step by step to decompose it into sequential subtasks:

1. **Task Understanding**
   "What is the overall objective?"
   - What is being asked?
   - What is the expected final outcome?
   - What constraints exist?

2. **Identify Natural Boundaries**
   "Where does the work naturally divide?"
   - Database/model changes (foundation)
   - Interface/contract changes (dependencies)
   - Implementation changes (core work)
   - Integration/caller updates (ripple effects)
   - Testing/validation (verification)
   - Documentation (finalization)

3. **Dependency Identification**
   "What must happen before what?"
   - "If I do B before A, will B break or use stale information?"
   - "Does B need any output from A as input?"
   - "Would doing B first require redoing work after A?"
   - What is the minimal viable ordering?

4. **Define Clear Boundaries**
   "What exactly does each subtask encompass?"
   - Input: What does this step receive?
   - Action: What transformation/change does it make?
   - Output: What does this step produce?
   - Verification: How do we know it succeeded?

分解のガイドライン：

パターン	分解戦略	例
インターフェースの変更	1. インターフェースを更新、2. 実装を更新、3. 利用側を更新	「getUser の戻り値の型を変更する」
機能の追加	1. 中核となるロジックを追加、2. 統合ポイントを追加、3. API 層を追加	「UserService にキャッシュを追加する」
リファクタリング	1. 中核部分を抽出／変更、2. 内部参照を更新、3. 外部参照を更新	「Service からヘルパークラスを抽出する」
影響を伴うバグ修正	1. 根本原因を修正、2. 依存する問題を修正、3. テストを更新	「レポートに影響する計算エラーを修正する」
複数レイヤーにまたがる変更	1. データ層、2. ビジネス層、3. API 層、4. クライアント層	「User エンティティに新しいフィールドを追加する」

分解の出力形式：

## Task Decomposition

### Original Task
{task_description}

### Subtasks (Sequential Order)

| Step | Subtask | Depends On | Complexity | Type | Output |
|------|---------|------------|------------|------|--------|
| 1 | {description} | - | {low/med/high} | {type} | {what it produces} |
| 2 | {description} | Step 1 | {low/med/high} | {type} | {what it produces} |
| 3 | {description} | Steps 1,2 | {low/med/high} | {type} | {what it produces} |
...

### Dependency Graph
Step 1 ─→ Step 2 ─→ Step 3 ─→ ...

フェーズ 2：各サブタスクのモデル選択

以下の 3 つの観点ですべてのサブタスクを評価し、選択ルールの表から適切な tier を確認します。tier はステップごとに選択し、実行全体で一度だけ選択するものではありません。

範囲 — 1 ファイル、1 コンポーネント、または複数ファイルですか？
複雑さ — 機械的な編集、確立されたパターン、または新規／複雑なロジックですか？
リスク — 独立していて元に戻せるもの、内部に影響するもの、または選択ルールの opus 行にある網羅的な一覧に該当する重大なものですか？

各ステップについて、3 つの評価結果、選択した tier、その理由を 1 行で示してから、処理を割り当てます。次に、そのステップの meta-judge の tier を決定するため、--model による上書きを含むロールの組み合わせをすべて適用します。

専門知識の確認：「このサブタスクは専門エージェントのプロファイルに合致しますか？」

開発：実装、リファクタリング、バグ修正
アーキテクチャ：システム設計、パターンの選択
ドキュメント：API ドキュメント、コメント、README の更新
テスト：テストの生成、テストの更新

専門エージェント： 専門エージェントの一覧は、プロジェクトと読み込まれているプラグインによって異なります。sdd プラグインの一般的なエージェントには、sdd:developer、sdd:researcher、sdd:software-architect、sdd:tech-lead、sdd:business-analyst、sdd:code-explorer、sdd:code-reviewer、sdd:tech-writer があります。適切な専門エージェントを利用できない場合は、専門性を指定せずに汎用エージェントを使用します。

判断： サブタスクが専門知識によって明確に有益な結果を得られ、かつ複雑さが追加コストに見合う場合は、専門エージェントを使用します（haiku tier のステップでは使用しません）。

選択の出力形式：

## Model/Agent Selection

| Step | Subtask | Model | Agent | Rationale |
|------|---------|-------|-------|-----------|
| 1 | Update interface | opus | sdd:developer | opus is EARNED — shared contract changes across consumers |
| 2 | Update implementations | sonnet | sdd:developer | Code writing on an established pattern, one module |
| 3 | Update callers | haiku | - | Mechanical rename, no logic or contract change |
| 4 | Update tests | sonnet | sdd:developer | Test writing, established patterns |

フェーズ 3：メタジャッジとジャッジによる検証を並行して行う逐次実行

サブタスクを 1 つずつ実行します。各ステップでは、meta-judge と実装エージェントを並行して割り当て、その後、meta-judge の仕様を使って独立した judge が検証します。必要に応じて反復し、その後、コンテキストを次のステップに引き継ぎます。

各ステップの実行フロー：

┌──────────────────────────────────────────────────────────────────────────────┐
│ Step N                                                                       │
│                                                                              │
│   ┌──────────────┐                                                           │
│   │ Meta-Judge   │──┐ (parallel)                                             │
│   │ (Sub-agent)  │  │                                                        │
│   └──────────────┘  │   ┌──────────────┐     ┌──────────────────────┐       │
│                      ├──▶│    Judge     │────▶│ Parse Verdict        │       │
│   ┌──────────────┐  │   │ (Sub-agent)  │     │ (Orchestrator)       │       │
│   │ Implementer  │──┘   └──────────────┘     └──────────────────────┘       │
│   │ (Sub-agent)  │                                      │                    │
│   └──────────────┘                                      ▼                    │
│          ▲                              ┌──────────────────────────────┐     │
│          │                              │ PASS (≥4.0)?                 │     │
│          │                              │ ├─ YES → Next Step           │     │
│          │                              │ ├─ ≥3.0 → Rule 3.6           │     │
│          │                              │ └─ NO  → Retry?              │     │
│          │                              │     ├─ <3 retries → Retry    │     │
│          │                              │     └─ ≥3 retries → Escalate │     │
│          │                              └──────────────────────────────┘     │
│          │                                            │                      │
│          └────────────── feedback ────────────────────┘                      │
│          (retries reuse same meta-judge spec, no new meta-judge)             │
└──────────────────────────────────────────────────────────────────────────────┘

3.1 コンテキストの引き継ぎプロトコル

各サブタスクの完了後、後続のステップに関連するコンテキストを抽出します。

引き継ぐコンテキスト：

変更したファイル（パスのみ、内容は含めない）
主な変更点（概要）
新たに導入したインターフェース／API
後続のステップに影響する決定事項
後続のステップに向けた警告や留意点

コンテキストのフィルタリング：

残りのサブタスクに関連する情報のみを引き継ぎます
後続のステップに影響しない実装の詳細は引き継がないでください
コンテキストの概要は簡潔にまとめてください（各ステップにつき最大200語）

コンテキストサイズのガイドライン： 累積したコンテキストが約500語を超える場合は、以前のステップの概要をより簡潔にまとめてください。サブエージェントは、詳細が必要な場合にファイルを直接確認できます。

コンテキスト蓄積の例（具体例）：

## Completed Steps Summary

### Step 1: Define UserRepository Interface
- **What was done:** Created `src/repositories/UserRepository.ts` with interface definition
- **Key outputs:**
  - Interface: `IUserRepository` with methods: `findById`, `findByEmail`, `create`, `update`, `delete`
  - Types: `UserCreateInput`, `UserUpdateInput` in `src/types/user.ts`
- **Relevant for next steps:**
  - Implementation must fulfill `IUserRepository` interface
  - Use the defined input types for method signatures

### Step 2: Implement UserRepository
- **What was done:** Created `src/repositories/UserRepositoryImpl.ts` implementing `IUserRepository`
- **Key outputs:**
  - Class: `UserRepositoryImpl` with all interface methods implemented
  - Uses existing database connection from `src/db/connection.ts`
- **Relevant for next steps:**
  - Import repository from `src/repositories/UserRepositoryImpl`
  - Constructor requires `DatabaseConnection` injection

3.2 サブエージェントプロンプトの作成

各サブタスクのプロンプトには、次の必須要素を含めます。

3.2.1 ゼロショット思考連鎖プレフィックス（必須 — 最初に配置すること）

## Reasoning Approach

Before taking any action, think through this subtask systematically.

Let's approach this step by step:

1. "Let me understand what was done in previous steps..."
   - What context am I building on?
   - What interfaces/patterns were established?
   - What constraints did previous steps introduce?

2. "Let me understand what this step requires..."
   - What is the specific objective?
   - What are the boundaries of this step?
   - What must I NOT change (preserve from previous steps)?

3. "Let me plan my approach..."
   - What specific modifications are needed?
   - What order should I make them?
   - What could go wrong?

4. "Let me verify my approach before implementing..."
   - Does my plan achieve the objective?
   - Am I consistent with previous steps' changes?
   - Is there a simpler way?

Work through each step explicitly before implementing.

3.2.2 タスク本文

<task>
{Subtask description}
</task>

<subtask_context>
Step {N} of {total_steps}: {subtask_name}
</subtask_context>

<previous_steps_context>
{Summary of relevant outputs from previous steps - ONLY if this is not the first step}
- Step 1: {what was done, key files modified, relevant decisions}
- Step 2: {what was done, key files modified, relevant decisions}
...
</previous_steps_context>

<constraints>
- Focus ONLY on this specific subtask
- Build upon (do not undo) changes from previous steps
- Follow existing code patterns and conventions
- Produce output that subsequent steps can build upon
- Critical: you not allowed to use any mutation git commands, including, but not limited: commit, stash, push, checkout, reset, revert, etc. Except cases when task EXPLICITLY allows or requires it. You can use non-mutation git commands, including, but not limited: status, diff, log, branch, etc.

</constraints>

<input>
{What this subtask receives - files, context, dependencies}
</input>

<output>
{Expected deliverable - modified files, new files, summary of changes}

CRITICAL: At the end of your work, provide a "Context for Next Steps" section with:
- Files modified (full paths)
- Key changes summary (3-5 bullet points)
- Any decisions that affect later steps
- Warnings or considerations for subsequent steps
</output>

3.2.3 自己批評サフィックス（必須 — 最後に配置すること）

## Self-Critique Verification (MANDATORY)

Before completing, verify your work integrates properly with previous steps. Do not submit unverified changes.

### Verification Questions

Generate verification questions based on the subtask description and the previous steps context. Examples:

| # | Question | Evidence Required |
|---|----------|-------------------|
| 1 | Does my work build correctly on previous step outputs? | [Specific evidence] |
| 2 | Did I maintain consistency with established patterns/interfaces? | [Specific evidence] |
| 3 | Does my solution address ALL requirements for this step? | [Specific evidence] |
| 4 | Did I stay within my scope (not modifying unrelated code)? | [List any out-of-scope changes] |
| 5 | Is my output ready for the next step to build upon? | [Check against dependency graph] |

### Answer Each Question with Evidence

Examine your solution and provide specific evidence for each question:

[Q1] Previous Step Integration:
- Previous step output: [relevant context received]
- How I built upon it: [specific integration]
- Any conflicts: [resolved or flagged]

[Q2] Pattern Consistency:
- Patterns established: [list]
- How I followed them: [evidence]
- Any deviations: [justified or fixed]

[Q3] Requirement Completeness:
- Required: [what was asked]
- Delivered: [what you did]
- Gap analysis: [any gaps]

[Q4] Scope Adherence:
- In-scope changes: [list]
- Out-of-scope changes: [none, or justified]

[Q5] Output Readiness:
- What later steps need: [based on decomposition]
- What I provided: [specific outputs]
- Completeness: [HIGH/MEDIUM/LOW]

### Revise If Needed

If ANY verification question reveals a gap:
1. **FIX** - Address the specific gap identified
2. **RE-VERIFY** - Confirm the fix resolves the issue
3. **UPDATE** - Update the "Context for Next Steps" section

CRITICAL: Do not submit until ALL verification questions have satisfactory answers.

3.3 並列メタジャッジのディスパッチ

重要： 各ステップでは、メタジャッジと実装エージェントを、1つのメッセージ内で2つのTaskツール呼び出しを使って並列にディスパッチしてください。メタジャッジが実装エージェントによる変更前の成果物を確認できるよう、メッセージ内でメタジャッジを最初に呼び出す必要があります。

両エージェントはフォアグラウンドで実行します。ジャッジのディスパッチに進む前に、両方の完了を待ってください。

メタジャッジのプロンプト（ステップごと）：

## Task

Generate an evaluation specification yaml for the following step. You will produce rubrics, checklists, and scoring criteria that a judge agent will use to evaluate the implementation artifact.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{Original task description from user}

## Step Being Evaluated
Step {N}/{total}: {subtask_name}
{subtask_description}
- Input: {what this step receives}
- Expected output: {what this step should produce}

## Previous Steps Context
{Summary of what previous steps accomplished}

## Artifact Type
{code | documentation | configuration | etc.}

## Instructions
Return only the final evaluation specification YAML in your response.

ディスパッチの例

2つのTaskツール呼び出しを1つのメッセージ内で送信してください。メタジャッジを先に、実装エージェントを後に呼び出します。

Message with 2 tool calls:
  Tool call 1 (meta-judge):
    - description: "Meta-judge Step {N}/{total}: {subtask_name}"
    - model: {meta-judge model — the user's `--model` if one was passed; otherwise the same tier as this step's implementation, or one tier up per Role Pairing}
    - subagent_type: "sadd:meta-judge"

  Tool call 2 (implementation):
    - description: "Step {N}/{total}: {subtask_name}"
    - model: {implementation model — the user's `--model` if one was passed; otherwise the model selected for this step}
    - subagent_type: "{selected agent type}"

ジャッジのディスパッチに進む前に、両方の結果が返るまで待ってください。

3.4 ジャッジによる検証プロトコル

メタジャッジと実装エージェントの両方が完了した後、メタジャッジの評価仕様に基づいてステップを検証する独立したジャッジをディスパッチします。

重要：ジャッジには、メタジャッジの評価仕様 YAML をそのまま提供してください。省略や追加をせず、いかなる形でも変更せず、テキストを短縮または要約しないでください。

3.4.1 既存の変更セクションを分析する

各ステップで判定担当を起動する前に、判定担当が把握しておく必要のある既存の変更がコードベースにあるかどうかを評価します。「既存の変更」セクションを設けることで、判定担当が以前の変更を現在のステップの実装エージェントによる作業と混同するのを防ぎます。

含める場合：

同じ do-in-steps 実行における前のステップの変更（ステップ N の判定時にステップ 1〜N-1 が対象）— 逐次実行ではこれが最も一般的なケースです。ステップ N を実行するとき、判定担当はステップ 1〜N-1 の変更を既存の変更として把握している必要があります。完了した各ステップの出力（作成・変更されたファイル、主な変更内容）が、後続ステップの判定担当にとって既存のコンテキストになります。
同じセッション内で以前に完了した do-in-steps または do-and-judge タスクの実行結果
スキルの実行前にユーザーが手動で加えた変更（会話のコンテキストまたは git で確認できるもの）
このタスクの実行前に動作した他のツールやエージェントによる変更

省略する場合：

既知の変更がないステップ 1（以前のセッションのタスクもユーザーによる変更もない場合）— セクション全体を省略します
同じステップ内で再試行する場合、実装エージェント自身による前回の試行を「既存の変更」として含めないでください。これらは現在のステップの反復サイクルの一部です

内容に関するガイドライン：

概要レベルでまとめます。タスクの説明、影響を受けるファイルやモジュールの一覧、変更の概要（作成・変更・削除）を記載します
コードブロック、差分、行単位の詳細は含めず、簡潔にまとめます
各変更元を明確にラベル付けします：「Step 1: {description}」、「Step 2: {description}」、「User modifications (before current task)」など
既存の変更元が複数ある場合は、それぞれ別のサブセクションに分けます（完了した各ステップにつき 1 つに加え、外部の変更元も含めます）
Context Passing Protocol の出力（セクション 3.1）を活用します。「Completed Steps Summary」に各ステップの成果が記録されています

重要：コードベース全体や git の履歴を読み込まないでください。変更されたファイルを確認するには、概要レベルの git diff/status のみを使用するか、会話のコンテキストや完了したステップの要約を利用してください。

ステップ判定担当向けプロンプトテンプレート：

You are evaluating Step {N}/{total}: {subtask_name} against an evaluation specification produced by the meta judge.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## Original Task
{overall_task_description}

## Step Requirements
{subtask_description}
- Input: {what this step receives}
- Expected output: {what this step should produce}

## Previous Steps Context
{Summary of what previous steps accomplished}

{IF pre-existing changes are known (previous steps, prior tasks, or user modifications), include the following section — otherwise omit entirely}

## Pre-existing Changes (Context Only)

The following changes were made BEFORE the current step's implementation agent started working. They are NOT part of the current step's output. Focus your evaluation on the current step's changes. Only verify pre-existing changed files/logic if they directly relate to the current step's requirements.

### {Source of changes: e.g., "Step 1: {step description}" or "Previous Task: {task description}" or "User modifications (before current task)"}
{High-level summary: what was done, which files/modules were created or modified}

### {Additional source if applicable}
{High-level summary}

{END conditional section}

## Evaluation Specification

```yaml
{meta-judge's evaluation specification YAML}

実装の出力

{実装エージェントが変更したファイルへのパス} {実装エージェントの「Context for Next Steps」セクション}

指示

エージェントの指示で定義されている完全な判定プロセスに従ってください！

出力

重要：応答の冒頭に、以下の正確な構造化評価レポート形式を YAML で記述してください。


CRITICAL: NEVER provide score threshold, in any format, including `threshold_pass` or anything different. Judge MUST not know what threshold for score is, in order to not be biased!!!

**Dispatch:**

Task ツールを使用：

description: "Judge Step {N}/{total}: {subtask_name}"
prompt: {正確なメタジャッジ仕様 YAML と、該当する場合は既存の変更セクションを含む、判定確認用プロンプト}
model: {判定モデル — ユーザーが --model を指定した場合はそのモデル、それ以外の場合は、エスカレーション後も含め、このステップで現在使用している実装モデルと MUST 等しくする}
subagent_type: "sadd:judge"


#### 3.5 Dispatch, Verify, and Iterate

For each subtask in sequence:

メタジャッジと実装エージェントを並列でディスパッチします（1 件のメッセージでツールを 2 回呼び出します）。ツール呼び出し 1（メタジャッジ — 必ず先に実行）： Task ツールを使用： - description: "Meta-judge Step {N}/{total}: {subtask_name}" - prompt: {ステップ要件とコンテキストを含むメタジャッジ用プロンプト} - model: {メタジャッジモデル — ユーザーが --model を指定した場合はそのモデル、それ以外の場合は、このステップの実装モデルと同じティア、またはロールの組み合わせに従って 1 ティア上} - subagent_type: "sadd:meta-judge"

ツール呼び出し 2（実装）： Task ツールを使用： - description: "Step {N}/{total}: {subtask_name}" - prompt: {CoT + タスク + これまでのコンテキスト + 自己批評を含む構成済みプロンプト} - model: {実装モデル — ユーザーが --model を指定した場合はそのモデル、それ以外の場合は、このステップで選択されたモデル} - subagent_type: "{selected agent type}"
両方の完了を待ちます。出力を収集します。
- メタジャッジから：評価仕様 YAML を抽出します
- 実装から：「Context for Next Steps」セクションを解析し、変更されたファイルを記録します
このステップのメタジャッジ仕様を使って、判定サブエージェントをディスパッチします。 Task ツールを使用：
- description: "Judge Step {N}/{total}: {subtask_name}"
- prompt: {ステップ要件、実装出力、メタジャッジ仕様 YAML を含む判定確認用プロンプト}
- model: {判定モデル — ユーザーが --model を指定した場合はそのモデル、それ以外の場合は、このステップで現在使用している実装モデルと MUST 等しくする}
- subagent_type: "sadd:judge"
判定結果を解析します（レポート全文は読まないでください）。判定返信から以下を抽出します。
- VERDICT: PASS または FAIL
- SCORE: X.X/5.0
- ISSUES: 問題の一覧（ある場合）
- IMPROVEMENTS: 提案の一覧（ある場合）
判定結果に基づいて決定します。

スコアが 4.0 以上の場合： → VERDICT: PASS → 蓄積したコンテキストを使って次のステップに進みます → IMPROVEMENTS は任意の改善案としてコンテキストに含めます

3.0 以上 4.0 未満で、STRICT_MODE ではない場合： → 反復裁量ルール（3.6）を適用します → 承認された場合 → VERDICT: PASS（未解決の問題を報告して次に進みます） → 却下された場合 → VERDICT: FAIL → 以下の「再試行回数の確認」に進みます

それ以外（スコアが 3.0 未満、または STRICT_MODE でスコアが 4.0 未満）の場合： → VERDICT: FAIL → このステップの再試行回数を確認します

再試行回数が 3 未満の場合： → 「3.5.1 再試行時のモデルエスカレーション」に従って、このステップの再試行ティアを決定します（エスカレーションルールに従い、単独のホールド例外が適用される場合を除いて両方を引き上げます） → 以下を指定して、そのティアで実装エージェントを再試行します。 - 元のステップ要件 - フィードバックとしての判定結果の ISSUES 一覧 - 詳細を確認するための判定レポートへのパス - 個別の問題を修正する指示 → このステップと同じメタジャッジ仕様を使って判定確認に戻り、再試行ティアで判定エージェントをディスパッチします → メタジャッジを再実行したり、メタジャッジのティアを変更したりしないでください

再試行回数が 3 以上の場合： → ユーザーにエスカレーションします（「エラー処理」を参照） → 次のステップには進まないでください
蓄積したコンテキストを使って次のサブタスクに進みます → 次のステップでは、新しいメタジャッジを実装エージェントと並列でディスパッチします


##### 3.5.1 Model Escalation on Retry

Before dispatching any retry you MUST decide this step's tier explicitly per the [Escalation Rule](#escalation-rule) — which governs in full, including its sole hold exception — and state the decision in your step report. Retry-specific anchors on top of it:

- **Trigger (1) is anchored at `score < 3.0`** here (or issues showing the model misunderstood the step rather than merely missing details).
- The retry's judge MUST be dispatched at the same tier as the retry implementation; the step's meta-judge is neither re-run nor re-tiered.
- The escalated tier applies to **this step's remaining attempts only** — the next step is re-assessed from scratch per [Phase 2](#phase-2-model-selection-for-each-subtask).
- If `opus` still fails, escalate to the user per [Error Handling](#if-step-fails-after-max-retries).

**Retry prompt template for implementation agent:**

```markdown
## Retry Required: Step {N}/{total}

Your previous implementation did not pass judge verification.

<original_requirements>
{subtask_description}
</original_requirements>

<judge_feedback>
VERDICT: FAIL
SCORE: {score}/5.0
ISSUES:
{list of issues from judge}

Full report available at: {path_to_judge_report}
</judge_feedback>

<your_previous_output>
{files modified in previous attempt}
</your_previous_output>

Instructions:
Let's fix the identified issues step by step.

1. First, review each issue the judge identified
2. For each issue, determine the root cause
3. Plan the fix for each issue
4. Implement ALL fixes
5. Verify your fixes address each issue
6. Provide updated "Context for Next Steps" section

CRITICAL: Focus on fixing the specific issues identified. Do not rewrite everything.

3.6 反復の裁量ルール

主なタスクは、目標品質を満たしてタスクを完了することであり、反復にかける労力は各ステップの規模に見合ったものにしなければなりません。次の2つの失敗モードはいずれも現実に起こり得ます。

細かな指摘に再試行やコンテキストを費やし、全体のタスクが完了しない → タスク失敗です。
完了と見なすには品質が明らかに低すぎるステップを受け入れる → さらに深刻な失敗です。

各ジャッジスコアに対し、次のように適用します。

score < 3.0 → 無条件で失敗です。裁量の余地はありません。 ステップが合格するか、最大再試行回数に達するまで、ジャッジのフィードバックに基づいて再試行します。
3.0 <= score < 4.0 → 裁量の範囲です。 この範囲内に限り、4.0 の目標に満たないステップを許容できると判断してもかまいません。固定された 4.0 の目標により、実質的な下限は 3.0 となるため、別途、許容範囲の下限を守るガードは不要です。
この範囲内で、未解決の問題が低または中程度の優先度のみであり（高または重大な指摘が1つでもあれば裁量は認められません）、かつステップの目標要件を損なったり、意味のある不具合を引き起こしたりしていない（つまり、些細な指摘である）場合は、再試行を依頼する前に、もう一度試す価値が時間とコンテキストのコストに見合うかどうかを必ず最初に検討します。
些細な指摘を理由とする再試行は最大1回までとし、再試行回数の上限に算入します。その再試行でも些細な指摘のみが挙がった場合は、必ずステップを合格（ACCEPTED）とし、未解決の問題を累積コンテキストに引き継ぎ、最終サマリーで報告して、次のステップに進みます。スコアが 3.0 未満の場合は、無条件の失敗ルールが適用されます。
厳格であり、寛大になってはいけません。 目標に届かない状態での終了は、実際に要件を損なう問題がないことに基づいた意図的な判断でなければなりません。後続のステップはこのステップを基盤とするためです。最大再試行回数までにステップを完了できない真のブロッキング問題は、決して取り繕わず、失敗としてエスカレーションします。
STRICT_MODE が true の場合、このルール全体は無効です。score >= 4.0 になるか、最大再試行回数に達するまで続行します。--strict はそれ以外を変更しません。つまり、4.0 の目標、最大再試行回数の上限、< 3.0 の無条件失敗、およびメタジャッジ／ジャッジのディスパッチには影響しません。

フェーズ4：最終サマリーとレポート

すべてのサブタスクが完了し、検証に合格した後、包括的なレポートを返します。

## Sequential Execution Summary

**Overall Task:** {original task description}
**Total Steps:** {count}
**Total Agents:** {meta_judges(one per step) + implementation_agents + judge_agents + retry_agents}
**Strict Mode:** {STRICT_MODE}

### Step-by-Step Results

| Step | Subtask | Model | Judge Score | Retries | Status |
|------|---------|-------|-------------|---------|--------|
| 1 | {name} | {model} | {X.X}/5.0 | {0-3} | PASS |
| 2 | {name} | {model} | {X.X}/5.0 | {0-3} | PASS |
| ... | ... | ... | ... | ... | ... |

Status is `PASS` (score >= 4.0), `ACCEPTED` (below target per the [Iteration Discretion Rule](#36-iteration-discretion-rule) — list the outstanding nitpicks under Follow-up Recommendations), or `FAILED`.

**Model** is the tier the step finished at; when [escalation](#351-model-escalation-on-retry) fired, record it as `{starting tier} → {final tier}`.

### Files Modified (All Steps)
- {file1}: {what changed, which step}
- {file2}: {what changed, which step}
...

### Key Decisions Made
- Step 1: {decision and rationale}
- Step 2: {decision and rationale}
...

### Integration Points
{How the steps connected and built upon each other}

### Judge Verification Summary
| Step | Initial Score | Final Score | Issues Fixed |
|------|---------------|-------------|--------------|
| 1 | {X.X} | {X.X} | {count or "None"} |
| 2 | {X.X} | {X.X} | {count or "None"} |

### Meta-Judge Specifications
One evaluation specification generated per step (in parallel with implementation), reused across retries within each step.


### Follow-up Recommendations
{Any improvements suggested by judges, tests to run, or manual verification needed}

エラー処理

ジャッジ検証に失敗した場合（スコア <4.0）

ジャッジによる検証を伴う反復ループは、ほとんどの失敗を自動的に処理します（3.0..4.0 のスコアが失敗となるのは、反復の裁量ルールに基づき、受け入れないと判断された場合のみです）。

Judge FAIL (Retry Available):
  1. Parse ISSUES from judge verdict
  2. Dispatch retry implementation agent with feedback
  3. Re-verify with judge (using same step's meta-judge specification — do NOT re-run meta-judge)
  4. Repeat until PASS or max retries (3)

最大再試行回数後にステップが失敗した場合

ステップがジャッジ検証に3回失敗した場合は、次の手順を実行します。

停止 - 問題のある基盤のまま先に進まないでください
報告 - 次の内容を含む失敗分析を提示します。
- 元のステップ要件
- すべてのジャッジ判定とスコア
- 再試行を通じて解消されなかった問題
エスカレーション - 次の選択肢をユーザーに提示します。
- 再試行のために追加のコンテキスト／ガイダンスを提供する
- このステップを次の上位モデルティアで再実行する（ステップがすでに opus に達している場合は、この選択肢を省略します）
- ステップ要件を変更する
- ステップをスキップする（任意の場合）
- 中断して、部分的な進捗を報告する
待機 - ユーザーの判断を得ずに先へ進んではいけません

エスカレーションレポートの形式：

## Step {N} Failed Verification (Max Retries Exceeded)

### Step Requirements
{subtask_description}

### Verification History
| Attempt | Score | Key Issues |
|---------|-------|------------|
| 1 | {X.X}/5.0 | {issues} |
| 2 | {X.X}/5.0 | {issues} |
| 3 | {X.X}/5.0 | {issues} |
| 4 | {X.X}/5.0 | {issues} |

### Persistent Issues
{Issues that appeared in multiple attempts}

### Judge Reports
- .specs/reports/{task-name}-step-{N}-attempt-1.md
- .specs/reports/{task-name}-step-{N}-attempt-2.md
- .specs/reports/{task-name}-step-{N}-attempt-3.md
- .specs/reports/{task-name}-step-{N}-attempt-4.md

### Options
1. **Provide guidance** - Give additional context for another retry
2. **Escalate the tier** - Re-run this step's implementation and judge one tier up (omit this option if the step already reached `opus`)
3. **Modify requirements** - Simplify or clarify step requirements
4. **Skip step** - Mark as skipped and continue (if non-critical)
5. **Abort** - Stop execution and preserve partial progress

Awaiting your decision...

禁止事項：

最大再試行回数後に失敗したステップを越えて続行する
「時間を節約する」ためにジャッジ検証を省略する
再試行を通じて解消されなかった問題を無視する
何がうまくいった可能性があるかを推測する

コンテキストが不足している場合

前のステップで何が生成されたかを推測しないでください
不足している情報について、前のステップの出力を再確認します
ジャッジのレポートを確認します。不足している要素が指摘されている場合があります
必要に応じて、不足しているコンテキストを抽出するために、確認用サブエージェントをディスパッチします
今後の同様のタスクに向けて、コンテキストの受け渡し方法を更新します

手順が競合する場合

競合が発生した時点で実行を停止します
分析します： 分解は誤っていましたか？手順は実際には依存関係にありますか？
ジャッジからのフィードバックを確認します。ジャッジが統合時の問題を指摘している場合があります
選択肢：
- 依存関係を見落としていた場合は、手順の順序を変更します
- 競合する手順を1つにまとめます
- 競合する手順の間に調整手順を追加します

例

例 1：前の手順を基に構築する逐次手順（前の手順からの既存の変更）

入力：

/do-in-steps implement user management feature

フェーズ 1 - 分解：

手順	サブタスク	依存先	複雑さ	種類	出力
1	User モデルとデータベーススキーマを作成する	-	中	実装	User モデル、マイグレーションファイル
2	ユーザー向け CRUD エンドポイントを追加する	手順 1	中	実装	REST API ルート、コントローラー
3	認証を統合する	手順 1、2	高	実装	認証ミドルウェア、JWT 処理

フェーズ 2 - モデルの選択：

手順	サブタスク	モデル	理由
1	User モデルとスキーマを作成する	sonnet	確立されたパターンに沿ったコード作成です。新規作成する `users` テーブルは元に戻せるため、取り消し不能なマイグレーションのトリガーは発動しません
2	CRUD エンドポイントを追加する	sonnet	1つのモジュールでのコード作成です。「パブリック API への追加」は、網羅的な重要項目リストには含まれていません
3	認証を統合する	opus	opus が選ばれるのは妥当です。認証（JWT の発行とルートの保護）が重要項目のトリガーに該当します

フェーズ 3 - 既存の変更を蓄積しながら実行：

Step 1: Create User model and database schema
  Parallel dispatch: Meta-judge + Implementation
  Judge Verification (with step 1 meta-judge spec):
    NOTE: No pre-existing changes — this is step 1 with no prior session tasks.
    The "Pre-existing Changes" section is OMITTED from the judge prompt.

    Judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ You are evaluating Step 1/3: Create User model and
    │ database schema against an evaluation specification
    │ produced by the meta judge.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## Original Task
    │ Implement user management feature
    │
    │ ## Step Requirements
    │ Create User model and database schema with proper
    │ fields and relationships.
    │
    │ ## Previous Steps Context
    │ None (first step)
    │
    │ ## Evaluation Specification
    │ ```yaml
    │ {meta-judge's evaluation specification YAML}
    │ ```
    │
    │ ## Implementation Output
    │ Files: src/models/User.ts (new), migrations/001_create_users.ts (new)
    │ Key changes: Created User model with id, email, name, passwordHash...
    │
    │ ## Instructions
    │ Follow your full judge process...
    └─────────────────────────────────────────────────────────

  → Judge (Sonnet — same tier as implementation): PASS, SCORE: 4.2/5.0
  → Context passed forward: User model fields, migration file paths

Step 2: Add CRUD endpoints for users
  Parallel dispatch: Meta-judge + Implementation (both Sonnet)
  Judge Verification (with step 2 meta-judge spec):
    NOTE: Pre-existing changes detected — Step 1 created the User model.
    Include "Pre-existing Changes" section so the judge does not confuse
    Step 1's files with Step 2's implementation work.

    Judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ You are evaluating Step 2/3: Add CRUD endpoints for
    │ users against an evaluation specification produced by
    │ the meta judge.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## Original Task
    │ Implement user management feature
    │
    │ ## Step Requirements
    │ Add CRUD endpoints (create, read, update, delete) for
    │ user management with proper validation and error handling.
    │
    │ ## Previous Steps Context
    │ Step 1 created User model with fields: id, email, name,
    │ passwordHash, createdAt, updatedAt.
    │
    │ ## Pre-existing Changes (Context Only)
    │
    │ The following changes were made BEFORE the current
    │ step's implementation agent started working. They are
    │ NOT part of the current step's output. Focus your
    │ evaluation on the current step's changes. Only verify
    │ pre-existing changed files/logic if they directly
    │ relate to the current step's requirements.
    │
    │ ### Step 1: "Create User model and database schema"
    │ The following files were created as part of Step 1:
    │ - src/models/User.ts (new) - User model with fields:
    │   id, email, name, passwordHash, createdAt, updatedAt
    │ - migrations/001_create_users.ts (new) - Database
    │   migration for users table
    │
    │ These files exist in the codebase and may be referenced
    │ by the current step, but evaluate only the changes made
    │ by Step 2's implementation agent.
    │
    │ ## Evaluation Specification
    │ ```yaml
    │ {meta-judge's evaluation specification YAML}
    │ ```
    │
    │ ## Implementation Output
    │ Files: src/controllers/UserController.ts (new),
    │        src/routes/users.ts (new), src/app.ts (modified)
    │ Key changes: Added REST endpoints for user CRUD...
    │
    │ ## Instructions
    │ Follow your full judge process...
    └─────────────────────────────────────────────────────────

  → Judge (Sonnet — same tier as implementation): PASS, SCORE: 4.4/5.0
  → Context passed forward: API routes, controller patterns

Step 3: Add authentication integration
  Parallel dispatch: Meta-judge + Implementation (both Opus — critical trigger)
  Judge Verification (with step 3 meta-judge spec):
    NOTE: Pre-existing changes include BOTH Step 1 AND Step 2.
    The judge needs to know about all prior steps' output.

    Judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ You are evaluating Step 3/3: Add authentication
    │ integration against an evaluation specification
    │ produced by the meta judge.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## Original Task
    │ Implement user management feature
    │
    │ ## Step Requirements
    │ Add JWT-based authentication with login/register
    │ endpoints and middleware for protecting user routes.
    │
    │ ## Previous Steps Context
    │ Step 1 created User model. Step 2 added CRUD endpoints
    │ at /api/users with UserController.
    │
    │ ## Pre-existing Changes (Context Only)
    │
    │ The following changes were made BEFORE the current
    │ step's implementation agent started working. They are
    │ NOT part of the current step's output. Focus your
    │ evaluation on the current step's changes. Only verify
    │ pre-existing changed files/logic if they directly
    │ relate to the current step's requirements.
    │
    │ ### Step 1: "Create User model and database schema"
    │ - src/models/User.ts (new) - User model with fields:
    │   id, email, name, passwordHash, createdAt, updatedAt
    │ - migrations/001_create_users.ts (new) - Database
    │   migration for users table
    │
    │ ### Step 2: "Add CRUD endpoints for users"
    │ - src/controllers/UserController.ts (new) - REST
    │   controller with create, read, update, delete handlers
    │ - src/routes/users.ts (new) - Express router for
    │   /api/users endpoints
    │ - src/app.ts (modified) - Registered user routes
    │
    │ These files exist in the codebase and may be modified
    │ by the current step, but evaluate only the changes made
    │ by Step 3's implementation agent.
    │
    │ ## Evaluation Specification
    │ ```yaml
    │ {meta-judge's evaluation specification YAML}
    │ ```
    │
    │ ## Implementation Output
    │ Files: src/auth/AuthMiddleware.ts (new),
    │        src/routes/auth.ts (new), src/app.ts (modified),
    │        src/routes/users.ts (modified)
    │ Key changes: Added JWT auth with login/register...
    │
    │ ## Instructions
    │ Follow your full judge process...
    └─────────────────────────────────────────────────────────

  → Judge (Opus — same tier as implementation): PASS, SCORE: 4.1/5.0

最終概要：

エージェントの合計数：10（メタジャッジ 3 + 実装 3 + 再試行 0 + ジャッジ 3）
既存の変更の推移：
- 手順 1 のジャッジ：なし
- 手順 2 のジャッジ：手順 1 の出力（2 ファイル）
- 手順 3 のジャッジ：手順 1 と 2 の出力（5 ファイル）
すべてのジャッジスコア：4.2、4.4、4.1

例 2：ユーザーが変更したコードベース + 逐次手順（複数の既存変更の混在）

シナリオ：

ユーザーは会話中に決済処理モジュールを作業しています。do-in-steps を実行する前に、いくつかのファイルを変更しました（新しい PaymentGateway インターフェースの追加や、設定の更新など）。

入力：

/do-in-steps fix and improve payment processing

フェーズ 1 - 分解：

手順	サブタスク	依存先	複雑さ	種類	出力
1	決済検証のバグを修正する	-	中	バグ修正	修正済みの検証ロジック
2	決済失敗時の再試行ロジックを追加する	手順 1	高	実装	バックオフ付き再試行メカニズム

フェーズ 2 - モデルの選択：

手順	サブタスク	モデル	理由
1	決済検証のバグを修正する	opus	opus が選ばれるのは妥当です。範囲は小さいものの、優先ルールにより重要度が規模に優先します。決済は重要項目に含まれます
2	決済失敗時の再試行ロジックを追加する	opus	opus が選ばれるのは妥当です。決済（重要項目）に加え、資金移動に関わる再試行とバックオフの順序制御（複雑なロジック）があるためです

両方の手順で opus が選ばれるのは、実行全体の規模ではなく、対象分野がそれに値するためです。異なる階層が混在する一連の手順については、例 3 を参照してください。

フェーズ 3 - 複数の既存変更が混在する状態での実行：

Step 1: Fix payment validation bugs
  Parallel dispatch: Meta-judge + Implementation (both Opus — critical trigger)
  Judge Verification (Opus, with step 1 meta-judge spec):
    NOTE: Pre-existing changes detected from USER modifications.
    The user modified payment files before this task — include those
    so the judge focuses only on the bug fix, not the user's prior work.

    Judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ You are evaluating Step 1/2: Fix payment validation
    │ bugs against an evaluation specification produced by
    │ the meta judge.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## Original Task
    │ Fix and improve payment processing
    │
    │ ## Step Requirements
    │ Fix validation bugs in payment amount and currency
    │ checks that allow invalid transactions to proceed.
    │
    │ ## Previous Steps Context
    │ None (first step)
    │
    │ ## Pre-existing Changes (Context Only)
    │
    │ The following changes were made BEFORE the current
    │ step's implementation agent started working. They are
    │ NOT part of the current step's output. Focus your
    │ evaluation on the current step's changes. Only verify
    │ pre-existing changed files/logic if they directly
    │ relate to the current step's requirements.
    │
    │ ### User modifications (before current task)
    │ The user made changes to the following files/modules
    │ before this task was started:
    │ - src/payments/PaymentGateway.ts (new) - Payment
    │   gateway interface definition
    │ - src/payments/StripeAdapter.ts (modified) - Updated
    │   to implement new PaymentGateway interface
    │ - src/config/payment.config.ts (modified) - Added
    │   gateway configuration settings
    │
    │ The current task focuses on fixing validation bugs.
    │ Pre-existing changes to payment files may overlap with
    │ the current step's scope — evaluate whether the
    │ implementation agent's changes correctly fix the bugs
    │ without breaking the pre-existing modifications.
    │
    │ ## Evaluation Specification
    │ ```yaml
    │ {meta-judge's evaluation specification YAML}
    │ ```
    │
    │ ## Implementation Output
    │ Files: src/payments/PaymentValidator.ts (modified),
    │        tests/payments/PaymentValidator.test.ts (modified)
    │ Key changes: Fixed amount validation to reject negative
    │ values, added currency code format check...
    │
    │ ## Instructions
    │ Follow your full judge process...
    └─────────────────────────────────────────────────────────

  → VERDICT: PASS, SCORE: 4.3/5.0
  → Context passed forward: Validation fixes, affected files

Step 2: Add retry logic for failed payments
  Parallel dispatch: Meta-judge + Implementation (both Opus — critical trigger)
  Judge Verification (Opus, with step 2 meta-judge spec):
    NOTE: Pre-existing changes now include BOTH the user's modifications
    AND Step 1's output. The judge needs both sources to correctly
    attribute changes.

    Judge prompt sent:
    ┌─────────────────────────────────────────────────────────
    │ You are evaluating Step 2/2: Add retry logic for failed
    │ payments against an evaluation specification produced by
    │ the meta judge.
    │
    │ CLAUDE_PLUGIN_ROOT=...
    │
    │ ## Original Task
    │ Fix and improve payment processing
    │
    │ ## Step Requirements
    │ Add retry mechanism with exponential backoff for failed
    │ payment transactions, with configurable max retries.
    │
    │ ## Previous Steps Context
    │ Step 1 fixed payment validation bugs in
    │ PaymentValidator.ts (amount and currency checks).
    │
    │ ## Pre-existing Changes (Context Only)
    │
    │ The following changes were made BEFORE the current
    │ step's implementation agent started working. They are
    │ NOT part of the current step's output. Focus your
    │ evaluation on the current step's changes. Only verify
    │ pre-existing changed files/logic if they directly
    │ relate to the current step's requirements.
    │
    │ ### User modifications (before current task)
    │ - src/payments/PaymentGateway.ts (new) - Payment
    │   gateway interface definition
    │ - src/payments/StripeAdapter.ts (modified) - Updated
    │   to implement new PaymentGateway interface
    │ - src/config/payment.config.ts (modified) - Added
    │   gateway configuration settings
    │
    │ ### Step 1: "Fix payment validation bugs"
    │ - src/payments/PaymentValidator.ts (modified) - Fixed
    │   amount validation and currency code format checks
    │ - tests/payments/PaymentValidator.test.ts (modified) -
    │   Added regression tests for validation fixes
    │
    │ These files exist in the codebase and may be modified
    │ by the current step, but evaluate only the changes made
    │ by Step 2's implementation agent.
    │
    │ ## Evaluation Specification
    │ ```yaml
    │ {meta-judge's evaluation specification YAML}
    │ ```
    │
    │ ## Implementation Output
    │ Files: src/payments/PaymentRetryService.ts (new),
    │        src/payments/StripeAdapter.ts (modified),
    │        src/config/payment.config.ts (modified),
    │        tests/payments/PaymentRetryService.test.ts (new)
    │ Key changes: Added PaymentRetryService with exponential
    │ backoff, integrated into StripeAdapter...
    │
    │ ## Instructions
    │ Follow your full judge process...
    └─────────────────────────────────────────────────────────

  → VERDICT: PASS, SCORE: 4.5/5.0

最終概要：

エージェントの合計数：7（メタジャッジ 2 + 実装 2 + 再試行 0 + ジャッジ 2）
既存の変更の推移：
- 手順 1 のジャッジ：ユーザーによる変更（3 ファイル）
- 手順 2 のジャッジ：ユーザーによる変更（3 ファイル）+ 手順 1 の出力（2 ファイル）
すべてのジャッジスコア：4.3、4.5

例3：エスカレーションを伴う複数ファイルのリファクタリング

入力：

/do-in-steps Rename 'userId' to 'accountId' across the codebase - this affects interfaces, implementations, and callers

フェーズ1 - 分解：

ステップ	サブタスク	依存先	複雑さ	種別	成果物
1	インターフェース定義を更新	-	高	リファクタリング	更新済みインターフェース
2	それらのインターフェースの実装を更新	ステップ1	低	リファクタリング	更新済み実装
3	呼び出し元と利用側を更新	ステップ2	低	リファクタリング	更新済み呼び出し元ファイル
4	テストを更新	ステップ3	低	テスト	更新済みテストファイル
5	ドキュメントを更新	ステップ4	低	ドキュメント	更新済みドキュメント

フェーズ2 - モデル選択：

ステップ	サブタスク	モデル	根拠
1	インターフェースを更新	opus	opus にふさわしいタスクです。共有コントラクトが変更されるため、ファイル数に関係なく `opus` の適用条件に該当します
2	実装を更新	haiku	機械的な広範囲変更の例外：ファイルごとに繰り返される、ルールに基づく単一の名前変更であり、単一の出現箇所に基づいてティアを決定します
3	呼び出し元を更新	haiku	同じ例外が適用されます。ロジックやコントラクトの変更を伴わない機械的な名前変更です
4	テストを更新	haiku	名前変更に合わせた機械的なテスト修正です
5	ドキュメントを更新	haiku	単一目的のテキスト修正で、コードを含みません

フェーズ3 - エスカレーションを伴う実行（各ステップでメタジャッジと実装を並行して実施）：

Step 1: Update interfaces
  Parallel dispatch: Meta-judge + Implementation (both Opus — shared contract change)
  → Judge (Opus, sadd:judge, with step 1 meta-judge spec): PASS, 4.3/5.0

Step 2: Update implementations
  Parallel dispatch: Meta-judge + Implementation (both Haiku)
    NOTE: Step 1's opus tier does NOT carry forward — Step 2 is tiered on
    its own merits (mechanical rename).
  → Judge (Haiku, sadd:judge, with step 2 meta-judge spec): PASS, 4.0/5.0

Step 3: Update callers (Problem Detected — model escalation within the step)
  Parallel dispatch: Meta-judge (Haiku) + Implementation (Haiku)
  Attempt 1 (Haiku impl + Haiku judge): Judge FAIL, 2.5/5.0
    → ISSUES: Missed 12 occurrences in legacy module
    → score < 3.0 → trigger (1) fires. Missed occurrences read as a capability
      gap, not a narrow fixable defect, so the sole hold exception does not
      apply → mandatory bump: haiku → sonnet.
      Meta-judge NOT re-run, NOT re-tiered — same spec reused.
  Attempt 2 (Sonnet impl + Sonnet judge, same step 3 meta-judge spec): FAIL, 2.8/5.0
    → ISSUES: Still missing 4 occurrences, found new deprecated API usage
    → still < 3.0 → still a capability gap, not a narrow fixable defect →
      mandatory bump again: sonnet → opus
  Attempt 3 (Opus impl + Opus judge, same spec): FAIL, 3.2/5.0
    → ISSUES: 2 occurrences in dynamically generated code
    → at the `opus` ceiling — no bump available regardless of the hold
      exception; retry at `opus` with exact feedback.
  Attempt 4 (Opus impl + Opus judge, same spec): FAIL, 3.3/5.0
    → ISSUES: Dynamic code generation still not fully addressed

  ESCALATION TO USER:
  "Step 3 failed after 4 attempts (haiku → sonnet → opus). Persistent issue:
   Dynamic code generation in LegacyAdapter.ts generates 'userId' at runtime.
   Options: 1) Provide guidance, 2) Modify requirements, 3) Skip, 4) Abort"
  (Tier escalation is NOT offered as an option — already at the opus ceiling.)

  User response: "Update LegacyAdapter to use string template with accountId"

  Attempt 5 (with user guidance, Opus, same step 3 meta-judge spec): Judge PASS, 4.1/5.0

Step 4-5: Each with parallel meta-judge + implementation, complete without issues
  NOTE: Step 3's escalation to opus is scoped to Step 3. Steps 4 and 5 are
  re-assessed from scratch and both run at Haiku.

エージェント総数：20（メタジャッジ5 + 実装5 + 再試行5 + ジャッジ5）

ベストプラクティス

タスクの分解

明確にする： 各サブタスクには、明確で検証可能な成果を設定します
検証ポイントを定義する： 各ステップでジャッジが何を確認すべきかを定めます
ステップを最小限にする： 関連する作業をまとめ、過度に分解しないようにします
依存関係を検証する： 各ステップが前のステップから必要なものを受け取っていることを確認します
コンテキストを計画する： ステップ間で引き継ぐ必要のあるコンテキストを特定します

モデル選択

ルールはモデル選択ポリシーで定められています。以下は、ルールを定着させるための習慣です。

各ステップについて、判断根拠を明言する - 各ステップを割り当てる前に、スコープ、複雑さ、リスクと、それによって決まるティアを述べます。これは実行中で最も効果の大きい判断です
opus は必要性があって選ぶものであり、保険として選ぶものではありません - あらゆる重複や同点は、直感ではなく選択ルールの優先順位とタイブレークに従って解決します
各ステップを個別に評価する - 一連の作業には複数のティアが混在します。隣接するステップのティア（またはエスカレーション後のティア）は、このステップの根拠にはなりません
ロール間でティアを統一する - 引き上げるのは、基準を定める役割（メタジャッジ）だけです。また、対象は自明でないステップに限ります（ロールの組み合わせ）
根拠に基づいてエスカレーションする - 明らかに低すぎるティアでの試行、またはユーザーからの品質に関する指摘があった場合（エスカレーションルール）、失敗したステップに限定してエスカレーションします

コンテキストの引き継ぎに関するガイドライン

シナリオ	渡す内容	省く内容
ステップ1で定義したインターフェース	インターフェース定義全体	実装の詳細
ステップ2での実装	主要なパターン、ファイルの場所	内部ロジック
ステップ3での統合	使用パターン、エントリーポイント	ステップ2の内部詳細
再試行時のジャッジフィードバック	ISSUES リスト、レポートのパス	レポートの全文

コンテキストを絞り込みます：

次のステップが作業を引き継ぐために必要な内容を渡します
後続のステップに影響しない内部詳細は省きます
一貫性を保つためのパターンや規約を明示します
ジャッジの IMPROVEMENTS は任意の改善案として含めます
既存の変更を追跡する - 変更の帰属に関する混乱を防ぐため、以前のステップを含む過去の変更についてのコンテキストをジャッジに渡します

メタジャッジ + ジャッジによる検証

メタジャッジを省略しない - 個別に調整された評価基準により、汎用的な評価基準よりも優れた判断が得られます
ステップごとにメタジャッジを1つ用意する - 各ステップでは、実装と並行して専用のメタジャッジを実行します
同じステップ内の再試行では、メタジャッジの仕様を再利用する - 再試行時には同じステップのメタジャッジ仕様を再利用し、メタジャッジを再実行しないでください
新しいステップごとに新しいメタジャッジを用意する - ステップごとに要件が異なるため、それぞれに新しいメタジャッジを用意します
並列実行時はメタジャッジを最初に呼び出す - メッセージ内で常に最初のツール呼び出しにします
ジャッジのヘッダーのみを解析する - コンテキストの汚染を避けるため、レポート全体は読まないでください
CLAUDE_PLUGIN_ROOTを含める - メタジャッジとジャッジの両方に、解決済みのプラグインルートパスが必要です
メタジャッジのYAML - ジャッジにはメタジャッジのYAMLのみを渡し、追加のテキストやコメントを加えないでください！
自己批評の後： ジャッジは、内部検証にすでに合格した作業をレビューします
独立した検証： 実装担当者とは別のエージェントがジャッジを担当します
構造化出力： レポート全体ではなく、返信からVERDICT/SCOREを必ず解析します
最大再試行回数： ユーザーにエスカレーションする前に3回まで試行します
フィードバックループ： ジャッジのISSUESを、実装エージェントへの再試行時に渡します
再試行時は、同じステップのメタジャッジ仕様を使用してジャッジによる検証に戻ります

品質保証

2層の検証： 自己批評（内部）+ ジャッジ（外部）
まず自己批評： 実装エージェントは提出前に自分の作業を検証します
次に外部ジャッジ： 独立したジャッジが、自己批評では見逃した盲点を見つけます
反復ループ： 合格するか、最大再試行回数に達するまで、フィードバックを受けて再試行します
適切な反復： Iteration Discretion Ruleを適用します。細かな指摘を理由とする再試行は最大1回とし、3.0を下回らないようにします。--strictでは無効になります
連鎖の検証： ジャッジは、前のステップとの統合を確認します
エスカレーション： 失敗したステップを先に進めず、ユーザーに確認を求めます
最終統合テスト： すべてのステップの後、変更全体が連携して動作することを検証します

コンテキスト形式のリファレンス

実装エージェントの出力形式

## Context for Next Steps

### Files Modified
- `src/dto/UserDTO.ts` (new file)
- `src/services/UserService.ts` (modified)

### Key Changes Summary
- Created UserDTO with fields: id (string), name (string), email (string), createdAt (Date)
- UserDTO includes static `fromUser(user: User): UserDTO` factory method
- Added `toDTO()` method to User class for convenience

### Decisions That Affect Later Steps
- Used class-based DTO (not interface) to enable transformation methods
- Opted for explicit mapping over automatic serialization for better control

### Warnings for Subsequent Steps
- UserDTO does NOT include password field - ensure no downstream code expects it
- The `createdAt` field is formatted as ISO string in JSON serialization

### Verification Points
- TypeScript compiles without errors
- UserDTO.fromUser() correctly maps all User properties
- Existing service tests still pass

ジャッジの判定形式（構造化ヘッダー）

---
VERDICT: PASS
SCORE: 4.2/5.0
ISSUES:
  - None
IMPROVEMENTS:
  - Consider adding input validation to fromUser() method
  - Add JSDoc comments for better IDE support
---

## Detailed Evaluation
[Evidence and analysis following meta-judge specification rubrics...]

ジャッジの判定形式（FAILの例）

---
VERDICT: FAIL
SCORE: 2.8/5.0
ISSUES:
  - Missing User->UserDTO mapping logic in getUser() method
  - Return type annotation changed but actual return value still returns User object
  - No null handling for optional User fields
IMPROVEMENTS:
  - Add static fromUser() factory method to UserDTO
  - Implement toDTO() as instance method on User class
---

重要なポイント： 依存関係のある複雑なタスクでは、各ステップを新しいコンテキストで実行し、前のステップから関連する出力のみを受け取る逐次実行が効果的です。ステップごとのメタジャッジ評価仕様により、各ステップの要件に合わせた評価基準を適用しながら、実装と並行して実行することで速度も確保できます。外部ジャッジによる検証は自己批評が見逃した盲点を見つけ、反復ループ（同じステップのメタジャッジ仕様を再利用）によって、次に進む前に品質を確保します。これにより、コンテキストの汚染とエラーの伝播の両方を防げます。

Markdown 対応

ログインしてコメント

基本情報

作者: neolabhq
リポジトリ: neolabhq/context-engineering-kit
カテゴリ: エージェントワークフロー
インストール数: 1,239
GitHub スター: 1,792

問題を報告