implement-task

Name: implement-task
Author: neolabhq

github.com/neolabhq開発1.8k1.2k 回インストール9 週間前に更新

リポジトリ

implement-task について

仕様ファイルに基づく実装を編成するスキルです。各ステップに実装エージェントを割り当て、完了したフェーズをsdd:code-reviewerで審査します。続行や差分再検証、品質しきい値、人間による確認ポイントに対応します。

主な機能

01タスクのステップごとにエージェントを割り当て
02実装フェーズごとのコードレビュー
03作業の続行や差分再検証
04レビューしきい値と反復回数の設定
05人間による確認ポイント

活用シーン

01複数ステップの仕様を実装
02中断した実装を続行
03プロジェクトファイル変更後にフェーズを再検証
04節目で人間のレビューを実施

インストール

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

$npx skills add https://github.com/neolabhq/context-engineering-kit --skill implement-task

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

詳細

検証を伴うタスクの実装

タスクの仕様とサブエージェントを活用して、最高品質のソリューションを実装してください。重大な理由がある場合、または完了するまでは、作業を中断してはいけません。重大な理由がない限り、質問は避けてください。各ステップにつき実装エージェントを1つ割り当ててください。その後、実装フェーズのすべてのステップが完了したら、そのフェーズにつき sdd:code-reviewer を1つ起動し、問題が解決するまで修正を繰り返してから、次のフェーズへ進んでください。

実装フェーズごとに sdd:code-reviewer エージェントを1つ使用し、自動品質検証を伴うタスク実装ステップを実行してください。

ユーザー入力

$ARGUMENTS

用語（最初にお読みください。「phase」は2つの異なる意味で使われています）

用語	意味
ワークフローフェーズ 0-5	このスキルの段階（タスクの選択、読み込み、実行、DoD、移動、報告）です。
実装フェーズ / `Phase N`	TASK ファイルの `### Phase Overview` にあるマイルストーンです。ステップをまとめ、レビュアーモデルを指定し、そのマイルストーンで満たすべき受け入れ基準を列挙します。コードレビューの単位です。
ステップ	`.specs/sub-tasks/<task-name>/<NN>-<step-slug>.md` にあるサブタスクファイルです。実装エージェントを割り当てる単位です。ステップ名は、`.md` を除いたそのファイルのベース名です。

コマンド引数

$ARGUMENTS から以下の引数を解析します。

引数の定義

引数	形式	デフォルト	説明
`task-file`	パスまたはファイル名	自動検出	タスクファイル名またはパスです（例：`add-validation.feature.md`）。
`--continue`	`--continue`	なし	最後に完了したステップから実装を続行します。進行中の実装フェーズを特定し、未完了のステップを完了してから、そのフェーズをレビューします。詳しくは「--continue」のコンテキスト解決を参照してください。
`--refine`	`--refine`	`false`	段階的な改善モードです。git との差分から変更を検出してステップに対応付け、最も早く影響を受けたステップを含む実装フェーズから再検証します。
`--human-in-the-loop`	`--human-in-the-loop [Phase 1,Phase 3,...]`	なし	レビュー後に人による検証のため一時停止する実装フェーズを指定します。フェーズが指定されていない場合は、実装フェーズごとに一時停止します。
`--target-quality`	`--target-quality X.X`	`4.0`	各実装フェーズのレビューに適用される単一の目標しきい値（5.0 点満点）です。
`--max-iterations`	`--max-iterations N`	`3`	実装フェーズごとの修正→再レビューサイクルの最大回数です。デフォルトは3回です。制限なしにするには `unlimited` を指定します。
`--skip-reviews`	`--skip-reviews`	`false`	すべてのフェーズレビューをスキップします。品質ゲートなしでステップを進めます。
`--model`	`opus\|sonnet\|haiku`	未設定	すべてのサブエージェント（実装エージェントと `sdd:code-reviewer`）に使用するモデルです。タスクファイル内のすべてのモデル設定より優先されます。省略した場合、ステップのモデルは Parallelization Overview から、レビュアーのモデルは Phase Overview から取得されます。
`--strict`	`--strict`	`false`	反復裁量ルールを無効にします。フェーズは `combined_score >= THRESHOLD` の場合にのみ PASS と判定され、それ以外の場合は `MAX_ITERATIONS` に達するまで反復します。

設定の解決

$ARGUMENTS を解析し、以下のとおり設定を解決します。

# Extract task file (first positional argument, optional - auto-detect if not provided)
TASK_FILE = first argument that is a file path or filename

# Single quality threshold — there is exactly one, and it is NEVER read from the task file
THRESHOLD = --target-quality value || 4.0

# Initialize other defaults
MODEL_OVERRIDE = --model value (opus|sonnet|haiku) || none  # none = no override; models come from the task file
MAX_ITERATIONS = --max-iterations || 3  # default is 3 iterations
HUMAN_IN_THE_LOOP_PHASES = --human-in-the-loop || [] (empty = none, "*" = all implementation phases)
SKIP_REVIEWS = --skip-reviews || false
REFINE_MODE = --refine || false
CONTINUE_MODE = --continue || false
STRICT_MODE = --strict || false

# Special handling for --human-in-the-loop without a phase list
if --human-in-the-loop present without phase identifiers:
    HUMAN_IN_THE_LOOP_PHASES = "*" (all implementation phases)

THRESHOLD は、このワークフローにおける唯一の品質しきい値です。 別個の標準／クリティカル／寛容な値や、カンマ区切り形式はありません。また、タスクファイル内にしきい値はなく、計画エージェントがしきい値を記述することは禁止されています。

`--continue`のコンテキスト解決

--continueを使用すると、状態は実装フェーズ、次にステップの順に解決されます。

フェーズとステップの解決：
- タスクファイルの### Parallelization Overviewのステップ表と### Phase Overviewを読みます。
- ステップ表の行に[DONE]と記されている場合、そのステップは完了です。
- 実装フェーズの#### Phase N見出しに、[REVIEWED]（レビューが実行され、合格した）または[REVIEWED-SKIPPED]（ステップは完了し、以前の--skip-reviews実行によってレビューが意図的に省略された）のいずれかのマーカーが付いている場合、そのフェーズは完了です。
- RESUME_PHASE = [REVIEWED]も[REVIEWED-SKIPPED]も付いていない、最初の実装フェーズです。[REVIEWED-SKIPPED]を未完了として扱うと、ユーザーが省略したレビューをそのまま再実行することになります。
- RESUME_STEPS = RESUME_PHASE内で[DONE]ではないステップを、依存関係の順に並べたものです。
再開するフェーズの既存作業を確認します：
- RESUME_PHASEに[DONE]のステップがいくつかあるものの、どちらのマーカーも付いておらず、RESUME_STEPSが空（すべてのステップが完了しており、レビューは未実施）の場合：
  - SKIP_REVIEWSがtrueの場合：何も起動しません。 フェーズに[REVIEWED-SKIPPED]を付け、次の実装フェーズから再開します。
  - そうでない場合：Workflow Phase 2に記載されている4つの入力を渡して、RESUME_PHASEのsdd:code-reviewerを起動します — Model：MODEL_OVERRIDEが設定されていればその値、そうでなければそのフェーズのReviewer modelを使用します。
    - Iteration Discretion Ruleに従ってフェーズが合格した場合：フェーズに[REVIEWED]を付け、次の実装フェーズから再開します。
    - それ以外の場合：そのフェーズについてFailure Handlingフローに進みます。
- RESUME_STEPSが空でない場合：まずそれらのステップをディスパッチし、その後通常どおりフェーズをレビューします — ただし、SKIP_REVIEWSがtrueの場合は引き続きそのレビューを省略し、フェーズに[REVIEWED-SKIPPED]を付けます。
状態の復元：
- タスクファイルの場所（in-progress/、todo/、done/）を確認します。
- todo/にある場合は、続行する前にin-progress/へ移動します。
- 既存の成果物から取得した値を事前に入力します。

Refine モードの動作（`--refine`）

--refine を使用すると、タスクファイルではなくプロジェクトファイルの変更を検出してステップに対応付け、最も早い影響対象ステップを担当する実装フェーズから再検証します。

変更されたプロジェクトファイルを検出する：

まず、git の状態に基づいて比較対象を判断します。

# Check for staged changes
STAGED=$(git diff --cached --name-only)

# Check for unstaged changes
UNSTAGED=$(git diff --name-only)

比較ロジック：

ステージ済み	未ステージ	比較対象	コマンド
はい	はい	ステージング領域（未ステージの変更のみ）	`git diff --name-only`
はい	いいえ	最後のコミット	`git diff HEAD --name-only`
いいえ	はい	最後のコミット	`git diff HEAD --name-only`
いいえ	いいえ	変更なし	メッセージを表示して終了

ステージ済みと未ステージの両方がある場合：作業ディレクトリとステージング領域を比較します（未ステージの変更のみ）
ステージ済みまたは未ステージのどちらか一方のみの場合：最後のコミットと比較します
これにより、refine は最も新しい作業中の変更を対象にします

変更をステップに対応付ける：
- タスクファイルの ### Parallelization Overview を読み、すべてのステップ名、その実装フェーズ、および Sub-Task File のパスを取得します。
- refine モードはサブタスクファイルを読んでもよい唯一のケースです。サブタスクファイルは実装成果物ではなく、タスクファイルと同様の仕様成果物であり、各ステップのファイルパスが記録されているのは #### Expected Output セクションのみです。必要な #### Expected Output セクションと #### Subtasks セクションだけを読みます。
- 次のマッピングを作成します：{changed_file → step name → implementation phase}
影響範囲を特定する：
- 変更されたファイルが関連付けられているすべてのステップを特定します
- REFINE_FROM_PHASE = 影響対象のステップを含む最も早い実装フェーズ
- そのフェーズ以降のすべての実装フェーズを再検証する必要があります
- それ以前の影響を受けていないフェーズはそのまま保持します
refine の実行：
- 影響を受ける実装フェーズごとに、順番に以下を行います：
  - フェーズを検証するため、sdd:code-reviewer エージェントを1つ起動し、ユーザーの変更も含めて4つの標準入力を渡します。Model：MODEL_OVERRIDE が設定されている場合はその値、そうでない場合はそのフェーズの Reviewer model
  - Iteration Discretion Rule に従ってフェーズが合格した場合は、[REVIEWED] とマークして次のフェーズに進みます
  - それ以外の場合は、Failure Handling のフローに進んでから、再レビューします
- ユーザーによる手動修正は保持されます。実装エージェントは上書きせず、それを基に作業します

例：

# User manually fixed src/validation/validation.service.ts
# (This file is the Expected Output of step `02-validation-service`, in Phase 1)

/implement my-task.feature.md --refine

# Detects: src/validation/validation.service.ts modified
# Maps to: step `02-validation-service` → Phase 1
# Action: Launch ONE sdd:code-reviewer for Phase 1
#   - If PASS: User's fix is good, proceed to Phase 2
#   - If FAIL: reason about blast radius, dispatch fixes for the affected
#     steps only, without overwriting the user's changes, then re-review
# Continues: Phase 2, Phase 3... (re-verify all subsequent phases)

複数のファイルが変更された場合：

# User edited an output of a Phase 1 step AND an output of a Phase 3 step

/implement my-task.feature.md --refine

# Earliest affected phase: Phase 1
# Re-verifies: Phase 1, Phase 2, Phase 3...
# (Phase 2 re-verified even though no direct changes, because it builds on Phase 1)

ステージ済みと未ステージの変更：

# Scenario: User staged some changes, then made more edits
# Staged: src/validation/validation.service.ts (git add done)
# Unstaged: src/validation/validators/email.validator.ts (still editing)

/implement my-task.feature.md --refine

# Detects: Both staged AND unstaged changes exist
# Mode: Compares unstaged only (working dir vs staging)
# Only email.validator.ts is considered for refine

# --

# Scenario: User only has staged changes (ready to commit)
# Staged: src/validation/validation.service.ts
# Unstaged: none

/implement my-task.feature.md --refine

# Detects: Only staged changes
# Mode: Compares against last commit

Human-in-the-Loop の動作

人間による検証チェックポイントは、個々のステップではなく実装フェーズを単位として設定されます。

トリガー条件：
- HUMAN_IN_THE_LOOP_PHASES に含まれる実装フェーズのレビューで、オーケストレーターによるPASSが出た後
- 該当するフェーズの修正イテレーションが完了した後（次の再レビューの前）
- HUMAN_IN_THE_LOOP_PHASES が "*" の場合は、すべての実装フェーズの後
チェックポイントで行うこと：
- フェーズのステップ結果の概要を表示します
- 生成された成果物とそのパスを表示します
- レビュアーの combined_score と統合された問題を表示します
- ユーザーに「フェーズの出力を確認してください。続行しますか？ [Y/n/feedback]」と尋ねます
- ユーザーからフィードバックがあった場合は、次のイテレーションまたはフェーズに反映します
- ユーザーが「n」と答えた場合は、ワークフローを一時停止します

チェックポイントメッセージの形式：

---
## 🔍 Human Review Checkpoint - Phase N

**Phase:** {phase heading}
**Steps:** {step names}
**Reviewer model:** {model used}
**Combined Score:** {combined_score}/5.0 (threshold: {THRESHOLD})
**Status:** ✅ PASS / ☑️ ACCEPTED / 🔄 ITERATING (attempt {n})

**Artifacts Created/Modified:**
- {artifact_path_1}
- {artifact_path_2}

**Reviewer Feedback (top issues):**
{feedback summary — High/Medium issues from reviewer.issues, with the step each belongs to}

**Action Required:** Review the above artifacts and provide feedback or continue.

> Continue? [Y/n/feedback]:
---

タスクの選択とステータス管理

タスクステータスフォルダー

タスクのステータスはフォルダーの場所によって管理されます。

.specs/tasks/todo/ - 実装待ちのタスク
.specs/tasks/in-progress/ - 現在作業中のタスク
.specs/tasks/done/ - 完了したタスク

タスクのサブタスクフォルダー .specs/sub-tasks/<task-name>/ は、タスクファイルがこれらのフォルダー間を移動しても移動しません。そのため、タスクファイルに記録されている Sub-Task File のパスは有効なままです。

ステータスの遷移

タイミング	アクション
実装開始時	タスクを `todo/` から `in-progress/` に移動する
最終検証が PASS の場合	タスクを `in-progress/` から `done/` に移動する
実装失敗（ユーザーが中止）	`in-progress/` に維持する

重大：あなたの役割はオーケストレーターのみです

あなたの役割はディスパッチと集約です。作業自体は行いません。

サブエージェントが適切にコンテキストを構築できるようにしてください。

重大：ディスパッチする各サブエージェントには、必ず次の情報を渡してください。

実装エージェント（ステップごとに1つ）：

タスクファイルのパス
そのステップのサブタスクファイルのパス — Parallelization Overview の Sub-Task File 列から取得した、正確に1つのパス
${CLAUDE_PLUGIN_ROOT} の値。エージェントが @${CLAUDE_PLUGIN_ROOT}/scripts/create-scratchpad.sh のようなパスを解決できるようにします

sdd:code-reviewer（実装フェーズごとに1つ）：

タスクファイルのパス
フェーズ識別子
そのフェーズの実装エージェントが報告した成果物のパス
CLAUDE_PLUGIN_ROOT

あなたが行うこと

タスクファイルを1回だけ読み取る（ワークフローのフェーズ1のみ）
Task ツールを使ってサブエージェントを起動する
サブエージェントから報告を受け取る
レビュアーの出力に対するオーケストレーター側の PASS ルールを満たした後、ステップと実装フェーズを完了として [DONE] にする
フェーズレビューが失敗した場合、影響範囲を考慮し、修正／再レビューに使うモデルを選択する
結果を集約してユーザーに報告する

あなたが絶対に行わないこと

禁止されている行為	理由	代わりに行うこと
実装の出力を読む	コンテキストの肥大化 → コマンドの喪失	サブエージェントに作成したものを報告させる
サブタスクファイルを読む（`--refine` のマッピングを除く）	実装エージェントが自分のサブタスクファイルを読む	Parallelization Overview にあるパスをサブエージェントのプロンプトに渡す
参考ファイルを読む	パターンを理解するのはサブエージェントの役割	サブエージェントのプロンプトにパスを含める
成果物を「確認」するために読む	コンテキストの肥大化 → 検証内容の失念	`sdd:code-reviewer` エージェントを起動する
自分でコード品質を評価する	あなたの役割ではなく、手順の失念につながる	`sdd:code-reviewer` エージェントを起動する
ステップごとに個別レビューする	レビューはフェーズ単位のゲート	フェーズの最後に一度だけレビューする
「簡単だから」という理由でフェーズレビューを省略する	`--skip-reviews` が指定されていない限り、すべてのフェーズでレビューが必須	それでも `sdd:code-reviewer` を起動する
レビュー、スクラッチパッド、反復作業などの結果について、タスクファイルにコメント／印／メモを追加する	タスクファイルは仕様の成果物であり、ログではありません。タスクが未完了の場合は、コードだけを見れば分かる状態にする必要があります。	書き込めるのは `[DONE]` の印のみです。それ以外は何も書き込まないでください。

合理化を防ぐルール

次のように考えたら：「何が作成されたか理解するために、このファイルを読もう」 → STOP。 何が作成されたかはサブエージェントの報告に記載されています。その情報を使ってください。

次のように考えたら：「さっと確認して、問題なさそうか見てみよう」 → STOP。 sdd:code-reviewer エージェントを起動してください。それはあなたの役割ではありません。

次のように考えたら：「このフェーズは簡単すぎるので、検証は必要ない」 → STOP。 SKIP_REVIEWS が true でない限り、すべての実装フェーズでレビューを正確に1回行います。例外はありません。

次のように考えたら：「このステップはリスクが高そうなので、フェーズが終わる前にレビューしよう」 → STOP。 ステップごとのレビューは、このワークフローで廃止されたものです。フェーズが完了するまで待ってください。

次のように考えたら：「良いプロンプトを書くために、サブタスクファイルを読む必要がある」 → STOP。 サブエージェントのプロンプトにサブタスクファイルのパスを記載してください。ファイルはサブエージェントが読みます。

これが重要な理由

オーケストレーターが自分でファイルを読むと、コンテキストがあふれ、コマンドを失い、手順を忘れます。毎回そうなります。

オーケストレーターが「さっと確認」すると、sdd:code-reviewer エージェントを起動しなくなり、品質が崩れ、成果物が不合格になります。

あなたのコンテキストウィンドウは貴重です。大切に守り、すべてを委任してください。

重大

設定ルール

モデルの優先順位（MODEL_OVERRIDE）：--model が指定されている場合、そのモデルはタスクファイル内のモデルや、このスキルのすべてのデフォルトより優先されます。すべてのサブエージェント（あらゆる種類の実装エージェントおよび sdd:code-reviewer）をそのモデルでディスパッチし、Parallelization Overview の Model 列と Phase Overview の Reviewer model は無視してください。これはオーバーライドであり、フォールバックではありません。--model が指定されていない場合（MODEL_OVERRIDE = none）、モデル選択に変更はありません。各ステップでは Parallelization Overview の該当行に記載された Model を使用し、各フェーズのレビューではそのフェーズの Reviewer model を使用します。いずれも、ディスパッチブロックに記載されたデフォルトをフォールバックとして使用します。
すべての実装フェーズのレビューで、単一の THRESHOLD（デフォルトは 4.0）を使用してください。コンポーネント別、重要度別、または寛容なバリアントはありません。
タスクファイルからしきい値を読み取ってはいけません。 計画エージェントはしきい値を記載しません。万一記載されていても、無視してください。
しきい値は、コードレビュー担当者から返された combined_score に対して、このオーケストレーター層で適用します。コードレビュー担当エージェントにしきい値を渡してはいけません。渡すと、目標スコアに到達しようとして、主観的な判断をするようになります。
combined_score >= THRESHOLD の場合、フェーズは合格です。3.0 <= combined_score < THRESHOLD の場合は、Iteration Discretion Rule に従う場合に限りフェーズは合格となります。固定下限の 3.0 を下回ってはいけません。combined_score < 3.0 の場合、フェーズは無条件で不合格です。
デフォルトは 3 回の反復です。 実装フェーズの修正→再レビューを 3 サイクル行ったら、警告を添えて次のフェーズに進んでください。
MAX_ITERATIONS が unlimited に設定されている場合：品質しきい値を満たすまで、回数の制限なく反復します。
HUMAN_IN_THE_LOOP_PHASES に含まれる実装フェーズ（または "*" の場合はすべてのフェーズ）の後に限り、human-in-the-loop のチェックポイントを実施してください。
SKIP_REVIEWS が true の場合： コードレビュー担当者のディスパッチをすべてスキップし、各実装フェーズのステップが完了したら、直接次の実装フェーズに進んでください。
CONTINUE_MODE が true の場合： RESUME_PHASE / RESUME_STEPS にスキップし、すでに完了したステップを再実装しないでください。
REFINE_MODE が true の場合： 変更されたプロジェクトファイルを検出してステップに対応付け、REFINE_FROM_PHASE から再検証してください。ユーザーによる修正は保持してください。
STRICT_MODE が true の場合： Iteration Discretion Rule は無効になります。フェーズは combined_score >= THRESHOLD の場合に限り合格となり、それ以外は MAX_ITERATIONS まで反復します。

実行と評価のルール

フォアグラウンドエージェントのみを使用すること：バックグラウンドエージェントは使用しないでください。可能な場合はエージェントを並列で起動してください。バックグラウンドエージェントは、権限の問題やその他のエラーが常に発生するためです。
並列処理はタスクファイルに従うこと：Parallel with:列で互いのステップが指定されている場合は、必ず1つのメッセージで同時にディスパッチしてください。計画で並列とされているステップを、決して順番に実行しないでください。
フェーズの境界を越えて並列処理しないこと：Phase N+1のステップは、Phase Nがレビューされて[REVIEWED]とマークされるまで（またはSKIP_REVIEWSがtrueの場合は[REVIEWED-SKIPPED]とマークされるまで）、開始できません。

以下の場合は、有効な結果が得られるまでcode-reviewerを再起動してください。

長すぎるレポートを却下する：code-reviewerが、指示どおりスクラッチパッドを使用せずに非常に長いレポートを返した場合、その結果を却下してください。これは、エージェントが「スクラッチパッドを使用する」という指示に従わなかったことを示しています。
Combined Score 5.0は幻覚です：code-reviewerがcombined_scoreとしてちょうど5.0/5.0を返した場合、幻覚または手抜きの評価とみなし、結果を却下してエージェントを再実行してください。これは加重集計値のみに適用されます。個別の評価基準が5点になることは問題なく、スコアを割り振る必要もありません。ただし、仕様への準拠、コード品質、Mudaの無駄分析のすべての評価基準が同時に、それぞれのscore_4の基準を厳密に上回ることは、妥当なレビュー結果とは考えられません。個別の評価基準が高得点であることを疑う理由として、この点を決して使わないでください。
スコアの欠落を却下する：code-reviewerのレポートにcombined_score（またはいずれかのサブスコア：spec_compliance_score、builtin_score）が欠けている場合、その結果を却下してください。これは、エージェントが評価基準の指示に従わなかったことを示しています。
レポート内のPASS/FAIL判定を却下する：出力にPASS/FAIL判定またはしきい値への言及が含まれている場合、その結果を却下してください。判定はオーケストレーターが行うため、エージェントにしきい値を意識させてはいけません。
対象範囲外の指摘を却下する：レビュー担当者が、そのフェーズの#### Phase Nブロックに記載されていない受け入れ基準を減点した場合、結果を却下してエージェントを再実行してください。後続フェーズで提供される作業を「不足」または「未完了」として報告した場合も同様です。そのフェーズはチェックポイントであり、最終段階ではないことを改めて伝えてください。

反復に関する裁量ルール

主なタスクは、目標品質を満たしてタスクを完了することです。次の2つの失敗パターンは、どちらも現実に起こり得ます。

細かな指摘に反復とコンテキストを費やし、全体のタスクが完了しない → タスクは失敗です。
完了とみなすには品質が本当に不十分な結果を受け入れる → さらに深刻な失敗です。

各実装フェーズの combined_score に適用します。

combined_score < 3.0 → 無条件で FAIL。裁量の余地はありません。 フェーズが合格するか、MAX_ITERATIONS に達するまで、レビュアーのフィードバックに基づいて反復します。
3.0 <= combined_score < THRESHOLD → 裁量の範囲です。 この範囲内に限り、目標を下回るフェーズを許容できると判断してもかまいません。下限は固定で 3.0、上限は THRESHOLD です。--target-quality によって THRESHOLD <= 3.0 に設定されている場合、裁量の範囲は空です。すべてのスコアは無条件の FAIL（< 3.0）か PASS のいずれかとなり、裁量を行使する余地はありません。
この範囲内で、未解決の問題が Low／Medium 優先度のみであり（High または Critical の指摘が1つでもあれば裁量の余地はなくなります）、かつ、フェーズが担う受け入れ基準に違反せず、意味のある欠陥も生じさせない（つまり、細かな指摘である）場合は、次の反復を開始する前に、反復する価値が時間とコンテキストのコストに見合うか、まず必ず判断してください。
細かな指摘を理由にした反復は最大1回までで、MAX_ITERATIONS にカウントされます。再度の反復でも細かな指摘のみが挙がった場合、フェーズを PASS（サマリーテーブルでは ☑️ ACCEPTED）とし、未解決の問題を最終レポートに記載して、次のフェーズに進まなければなりません。combined_score が 3.0 未満になった場合は、FAIL の手順が適用されます。
ビルド、リント、テストのいずれかが成功しないフェーズは、スコアにかかわらず、裁量の範囲には決して入りません。各フェーズは、正常に動作し、コミット可能で、CI がグリーンの状態で完了しなければなりません。
寛大ではなく、厳格に判断してください。 目標未満で終了する場合は、要件に違反する実質的な問題がないことを根拠とした、意図的な判断でなければなりません。MAX_ITERATIONS 内にフェーズを完了できない真のブロッキング問題は、決して見過ごさず、失敗として報告しなければなりません。
STRICT_MODE が true の場合、このルール全体は無効です。 combined_score >= THRESHOLD になるか、MAX_ITERATIONS に達した場合にのみ終了します。--strict はほかの設定を変更しません。THRESHOLD、MAX_ITERATIONS、< 3.0 の無条件 FAIL、人間参加型チェックポイント、コードレビュー担当者のディスパッチ、--skip-reviews は影響を受けません。--skip-reviews では combined_score が生成されないため、このルールと --strict はどちらも適用されません。

概要

このコマンドは、複数の手順からなるタスクの実装を、次のように調整します。

手順の依存関係に従った順次実行
計画の Parallel with: 列で許可されている場合の並列実行
各手順につき実装エージェントを1つ起動し、タスクファイルのパスとサブタスクファイルのパスを両方渡します
各実装フェーズにつき自動検証を1回実行します。使用するモデルは、そのフェーズの Reviewer model です
フェーズのレビューが失敗した場合に、修正モデルと再レビュー用モデルを選ぶための影響範囲の推論
各オーケストレーター階層の PASS 後に確認を行う進捗追跡

ワークフローの全体像

Workflow Phase 0: Select Task & Move to In-Progress
    │
    ├─── Use provided task file name or auto-select from todo/ (if only 1 task)
    ├─── Move task: todo/ → in-progress/
    │
    ▼
Workflow Phase 1: Load Task
    │   Parse ### Parallelization Overview (steps, models, agents, sub-task paths)
    │   Parse ### Phase Overview (phases, steps, reviewer models, criteria due)
    │
    ▼
Workflow Phase 2: Execute Implementation Phases
    │
    ├─── For each implementation phase, in order:
    │    │
    │    ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ For each step of the phase, in dependency order │
    │    │ (parallel steps dispatched simultaneously):     │
    │    │   Launch its agent at its Model with            │
    │    │   task file path + sub-task file path           │
    │    └─────────────────┬───────────────────────────────┘
    │                      │  all steps of the phase reported complete
    │                      ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Launch ONE sdd:code-reviewer for the PHASE      │
    │    │ at the phase's Reviewer model                   │
    │    └─────────────────┬───────────────────────────────┘
    │                      │
    │                      ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Orchestrator reads combined_score and applies   │
    │    │ THRESHOLD:                                      │
    │    │  PASS → Mark phase [REVIEWED], next phase       │
    │    │  FAIL → Reason about BLAST RADIUS, choose fix   │
    │    │         model + scope + re-review model,        │
    │    │         re-review (max MAX_ITERATIONS)          │
    │    └─────────────────────────────────────────────────┘
    │
    ▼
Workflow Phase 3: Definition of Done Verification
    │
    ├─── Verify all Definition of Done items
    │    │
    │    ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ Launch sdd:developer agent                      │
    │    │ (verify all DoD items)                          │
    │    └─────────────────┬───────────────────────────────┘
    │                      │
    │                      ▼
    │    ┌─────────────────────────────────────────────────┐
    │    │ All DoD PASS? → Proceed to Workflow Phase 4     │
    │    │ Any FAIL? → Fix and re-verify (iterate)         │
    │    └─────────────────────────────────────────────────┘
    │
    ▼
Workflow Phase 4: Move Task to Done
    │
    ├─── Move task: in-progress/ → done/
    │
    ▼
Workflow Phase 5: Final Report

ワークフローフェーズ 0：ユーザー入力の解析とタスクの選択

ユーザー入力を解析し、タスクファイルのパスと引数を取得します。

Step 0.1: タスクファイルを解決する

$ARGUMENTS が空、またはフラグのみの場合：

まず進行中フォルダーを確認します：
```
ls .specs/tasks/in-progress/*.md 2>/dev/null
```
- ファイルが1つだけの場合 → $TASK_FILE をそのファイルに、$TASK_FOLDER を in-progress に設定します
- 複数のファイルがある場合 → ファイルを一覧表示し、ユーザーに「進行中のタスクが複数あります。どれを続行しますか？」と尋ねます
- ファイルがない場合 → ステップ2に進みます
todo フォルダーを確認します：
```
ls .specs/tasks/todo/*.md 2>/dev/null
```
- ファイルが1つだけの場合 → $TASK_FILE をそのファイルに、$TASK_FOLDER を todo に設定します
- 複数のファイルがある場合 → ファイルを一覧表示し、ユーザーに「todo にタスクが複数あります。どれを実装しますか？」と尋ねます
- ファイルがない場合 → 「利用可能なタスクがありません。まず /add-task で作成してください。」と報告して停止します

$ARGUMENTS にタスクファイル名が含まれる場合：

次の順序でファイルを検索します：in-progress/ → todo/ → done/
それに応じて $TASK_FILE と $TASK_FOLDER を設定します
見つからない場合は、エラーを報告して停止します

Step 0.2: 進行中に移動する（必要な場合）

タスクが todo/ フォルダーにある場合：

git mv .specs/tasks/todo/$TASK_FILE .specs/tasks/in-progress/
# Fallback if git not available: mv .specs/tasks/todo/$TASK_FILE .specs/tasks/in-progress/

$TASK_PATH を .specs/tasks/in-progress/$TASK_FILE に更新します

タスクがすでに in-progress/ にある場合： $TASK_PATH を .specs/tasks/in-progress/$TASK_FILE に設定します

サブタスクフォルダーは移動しないでください。 .specs/sub-tasks/<task-name>/ は、計画時に作成された場所にそのまま残します。タスクファイル内の Sub-Task File パスは、すでにその場所を指しています。

Step 0.3: フラグを解析して設定を初期化する

$ARGUMENTS のすべてのフラグを解析し、設定を初期化します。 解決された設定を表示します：

### Configuration

| Setting | Value |
|---------|-------|
| **Task File** | {TASK_PATH} |
| **Model Override** | {MODEL_OVERRIDE or "None (models from task file)"} |
| **Threshold** | {THRESHOLD}/5.0 |
| **Max Iterations** | {MAX_ITERATIONS or "3"} |
| **Human Checkpoints** | {HUMAN_IN_THE_LOOP_PHASES as comma-separated or "All phases" or "None"} |
| **Skip Reviews** | {SKIP_REVIEWS} |
| **Continue Mode** | {CONTINUE_MODE} |
| **Refine Mode** | {REFINE_MODE} |
| **Strict Mode** | {STRICT_MODE} |

Step 0.4: 続行モードを処理する

CONTINUE_MODE が true の場合： Context Resolution for --continue に従って RESUME_PHASE と RESUME_STEPS を解決し、Workflow Phase 2 では、RESUME_PHASE より前のすべての実装フェーズと、そのフェーズ内の [DONE] のステップをすべてスキップします。

Step 0.5: 改善モードを処理する

REFINE_MODE が true の場合：

変更されたプロジェクトファイルを検出します：

# Check for staged and unstaged changes
STAGED=$(git diff --cached --name-only)
UNSTAGED=$(git diff --name-only)

比較モードを決定します：

if STAGED is not empty AND UNSTAGED is not empty:
    # Both staged and unstaged - use unstaged only
    CHANGED_FILES = git diff --name-only  # working dir vs staging
    COMPARISON_MODE = "unstaged_only"
elif STAGED is not empty OR UNSTAGED is not empty:
    # Only one type - compare against last commit
    CHANGED_FILES = git diff HEAD --name-only
    COMPARISON_MODE = "vs_last_commit"
else:
    # No changes
    Report: "No project changes detected. Make edits first, then run --refine."
    Exit

ステップとファイルの対応関係を作成します：
- タスクファイルの ### Parallelization Overview を読み、ステップ名、フェーズ、Sub-Task File パスを確認します
- サブタスクファイルの #### Expected Output セクションと #### Subtasks セクションを読み、ファイルパスを確認します（コンテキスト保護に対して許可される唯一の例外です。詳細は Refine Mode Behavior を参照してください）
- 対応関係を作成します：STEP_FILE_MAP = {step name → [file paths]} および STEP_PHASE_MAP = {step name → implementation phase}
変更されたファイルをステップに対応付けます：
```
AFFECTED_STEPS = []
for each changed_file:
    for step_name, file_list in STEP_FILE_MAP:
        if changed_file matches any path in file_list:
            AFFECTED_STEPS.append(step_name)
```
- 対応するステップがない場合：「変更されたファイルは、どのステップの Expected Output にも対応していません。手動で確認してください。」
改善範囲を決定します：
- REFINE_FROM_PHASE = STEP_PHASE_MAP[AFFECTED_STEPS] の中で最も早い実装フェーズ
- REFINE_FROM_PHASE 以降のすべての実装フェーズで再検証が必要です
- REFINE_FROM_PHASE より前のフェーズはそのまま維持します
変更ファイルのコンテキストを保存します：
- CHANGED_FILES = 変更されたファイルパスのリスト
- USER_CHANGES_CONTEXT = 影響を受けるファイルの git diff 出力
- 修正を担当する実装エージェントにこのコンテキストを渡します
- エージェントはユーザーの修正を上書きせず、その上に変更を積み重ねる必要があります

Workflow Phase 1: タスクを読み込んで分析する

ファイルを読み取るのはこのフェーズのみです（--refine モードでのサブタスクの #### Expected Output セクションを除きます）。

Step 1.1: タスクの詳細を読み込む

タスクファイルを一度だけ読み取ります：

Read $TASK_PATH

この読み取りの後、実行の残りの間、他のファイルを読み取ってはいけません。

ステップ 1.2: 実装プロセスを解析する

## Implementation Process セクションを 2 つの作業用構造に解析します。

フィールド	ソース	用途
ステップ名	`Step` 列（バッククォートで囲まれたサブタスクのベース名）	他のすべてのリストにおける識別子
実装フェーズ	`Phase` 列	どのレビューゲートに属するか
モデル	`Model` 列	そのディスパッチの `model`（`MODEL_OVERRIDE` の場合を除く）
エージェント	`Agent` 列	ディスパッチする `sdd:` エージェントタイプ
依存先	`Depends on` 列	順序付け
並列実行対象	`Parallel with` 列	1 つのメッセージでディスパッチするステップ
サブタスクファイル	`Sub-Task File` 列	エージェントに渡すパス

### Phase Overview から — 各 #### Phase N ブロックについて、Steps:、Reviewer model:、Checklist items: リスト、Rubrics: リストを記録します。Reviewer model: はレビューをディスパッチするために使用します。基準のリストはレビュアーの責務であり、あなたの責務ではありません — それらをいかなるプロンプトにも貼り付けないでください。

タスクファイルにはしきい値も、検証レベルも、判定者の人数もありません。それらを探さないでください。

ステップ 1.3: Todo リストを作成する

各ステップにつき 1 エントリ、および各実装フェーズのレビューにつき 1 エントリで TodoWrite を作成します:

{
  "todos": [
    {"content": "Phase 1 / Step 01-foundation [haiku]", "status": "pending", "activeForm": "Implementing 01-foundation"},
    {"content": "Phase 1 / Step 02a-service [sonnet]", "status": "pending", "activeForm": "Implementing 02a-service"},
    {"content": "Phase 1 review [reviewer: sonnet]", "status": "pending", "activeForm": "Reviewing Phase 1"},
    {"content": "Phase 2 / Step 03-integration [sonnet]", "status": "pending", "activeForm": "Implementing 03-integration"},
    {"content": "Phase 2 review [reviewer: opus]", "status": "pending", "activeForm": "Reviewing Phase 2"}
  ]
}

ワークフローフェーズ 2: 実装フェーズを実行する

実装フェーズを順番に処理します。フェーズ内では、依存関係の順序でステップを処理し、Parallel with: グループを同時にディスパッチします。フェーズのすべてのステップが完了を報告したら、フェーズレビューを 1 回実行します。

ディスパッチパターンはちょうど 1 つだけであり、それは例外なくすべての実装フェーズに適用されます。

フェーズレビューパターン

for each implementation phase P, in order:
    for each dependency-ordered group G of steps in P:
        dispatch every step of G in ONE message (parallel), each with:
            agent type   = its Agent column
            model        = MODEL_OVERRIDE if set, else its Model column
            prompt       = task file path + its sub-task file path
        collect each agent's reported artifact paths

    if SKIP_REVIEWS:
        mark P [REVIEWED-SKIPPED]; continue to the next phase

    dispatch ONE sdd:code-reviewer for P with the 4 inputs
        model = MODEL_OVERRIDE if set, else P's `Reviewer model`

    apply THRESHOLD to combined_score
        PASS      → mark P [REVIEWED]; human checkpoint if due; next phase
        FAIL      → Failure Handling (blast radius) → re-review; up to MAX_ITERATIONS

ステップのディスパッチ（ステップごとに 1 つの実装エージェント）

Task ツールを使用し、ステップごとに 1 回呼び出します（Parallel with: グループのすべてのステップは 1 つのメッセージで）:

エージェントタイプ: ステップの Agent 列に sdd: を付けたもの（例: sdd:developer、sdd:tech-writer）
モデル: 設定されていれば MODEL_OVERRIDE — そうでなければステップの Model 列 — そうでなければ sonnet
説明: 「Implement step [step-name]」
プロンプト:

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Implement step `[step-name]`.

Task File: $TASK_PATH
Sub-Task File: [the Sub-Task File path from the Parallelization Overview]

Your task:
- Read the sub-task file first — it IS your step
- Read the task file for Description, Acceptance Criteria (including the Test Strategy) and Architecture Overview
- Execute ONLY this step. Do NOT execute any other step, even one you can see in the Parallelization Overview
- Follow the sub-task file's Expected Output, Success Criteria and Subtasks exactly
- Your phase is a checkpoint, not the finish line: implement what this step delivers, and do not pull later phases' work forward
- Leave the tree building, linting and testing green

When complete, report:
1. What files were created/modified (paths)
2. Confirmation that the sub-task's success criteria are met
3. Self-critique summary
4. Any issues encountered

ステップの目標、期待される出力、成功基準、サブタスクをプロンプトに貼り付けないでください。エージェントは自身のサブタスクファイルを読みます。パスを渡すことが契約であり、内容を貼り付けることはコンテキストの肥大化とドリフトです。

各レポートから成果物のパスを収集します。成果物を読まないでください。

コードレビュアーの入力契約（必須）

すべての sdd:code-reviewer ディスパッチには、正確にこれら 4 つの入力を含め、しきい値や合否の期待に似たものを他に一切含めてはなりません（Task ツールの model パラメータはディスパッチ設定であり、プロンプト入力ではありません — MODEL_OVERRIDE を参照）:

タスクファイルパス: $TASK_PATH
フェーズ識別子: レビュー対象のフェーズを、### Phase Overview に書かれているとおりに正確に（例: Phase 2）
成果物パス: そのフェーズの実装エージェントが作成または変更したと報告したすべてのファイルパス
CLAUDE_PLUGIN_ROOT: プラグインのルートパス

ディスパッチプロンプト:

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Apply your full evaluation process (Stages 0-12) and return a single combined report.

Inputs:

1. Task file path:
   $TASK_PATH

2. Phase identifier:
   [e.g. Phase 2]

3. Artifact path(s):
   [every file path reported by this phase's implementation agents]

4. CLAUDE_PLUGIN_ROOT: ${CLAUDE_PLUGIN_ROOT}

コードレビュアーに渡してはならないもの:

スコアのしきい値、目標品質、合格ラインの値
PASS/FAIL の期待
あなた自身が書いたルーブリックやチェックリスト（権威があるのは、タスクファイルの ## Acceptance Criteria を Phase Overview で絞り込んだものだけです）
サブタスクファイルのパス — レビュアーは Phase Overview の Steps: 行と Parallelization Overview の Sub-Task File 列から自身で解決します
タスクの説明や受け入れ基準のテキスト — エージェントはタスクファイルを自身で読みます

閾値の適用（オーケストレーター層のみ）

コードレビュアーのレポートを受け取った後、オーケストレーター（このスキル）が閾値を適用します。

combined_score = reviewer.combined_score
all_issues     = reviewer.issues          # each carries the step it belongs to
blast_radius   = reviewer.blast_radius

# PASS rule (orchestrator decides):
if combined_score >= THRESHOLD:
    PASS
elif 3.0 <= combined_score < THRESHOLD and not STRICT_MODE:
    apply the Iteration Discretion Rule → accepted: PASS | declined: FAIL → fix
else:
    FAIL → fix

combined_score には、すでに仕様準拠度、コード品質、ムダの分析が反映されています（レビュアーが STAGE 9 で内部的に集計します）。オーケストレーターはサブスコアを再集計する必要はありません。ゲートの判断で重要なのは、combined_score、issues、blast_radius のみです。

失敗への対処：影響範囲を考慮する（最も重要な判断）

これは、このワークフローで行う判断の中で最も重要です。何かを実行に移す前に、十分に検討してください。

ここにルール表はありません。また、自分で作成してはいけません。原則は次のとおりです。

フェーズを修正するエージェントと、修正を再レビューするエージェントの能力は、そのフェーズを最初に構築したモデルではなく、レビュアーの指摘の影響範囲に合わせてください。

修正を1つでも実行に移す前に、次の点を明確に、書面で検討してください。

範囲 — 指摘はどのステップに及んでいますか？issues[].step と blast_radius.affected_steps を使用してください。問題がないことが明らかなステップはどれですか？
深さ — ステップ内の局所的な欠陥ですか？それともフェーズの構造そのものに問題がありますか（blast_radius.requires_phase_rework）？
結合度 — 影響を受けるステップを修正すると、影響を受けていないステップも書き直す必要がありますか？必要な場合、修正の単位はステップではなくフェーズです。
重大度 — フェーズが担う受け入れ基準を満たせなくする重大度 High／Critical の指摘ですか？それとも重要度 Low／Medium の細かな指摘ですか？
能力の限界 — 実装モデルの能力が足りなかったように見えますか？同じモデルが同じ指摘に一度失敗しているなら、同じレベルで再度割り当てても、また失敗します。上位モデルに切り替えてください。

次に、3つのことを決めてください。

修正モデル — ステップの構築に使ったモデルより上位でも下位でもかまいません。また、ステップごとに異なるモデルを選んでもかまいません。
修正範囲 — 再度実行するサブタスクのファイルを決めます。問題のないステップを再度実行してはいけません。そうすると、良い成果まで損なわれます。
再レビューモデル — 少なくともフェーズの Reviewer model を使用してください。フェーズの構造そのものに問題があって修正モデルを上位に切り替える場合は、再レビューモデルも上位に切り替えてください。欠陥を見逃したレベルでのレビューでは、確認になりません。

具体例（基準となるケース）。 3つのステップからなるフェーズをすべて haiku で構築し、レビュアーに sonnet を使用したものの、レビューに失敗したとします。同じ失敗判定でも、影響範囲だけで対応が大きく異なります。

ケース A — フェーズ全体の失敗。 レビュアーが3つすべてのステップに High の指摘を出し、requires_phase_rework: true で、フェーズ内の共有抽象化の設計にも問題があると報告しています。影響範囲 = フェーズ全体、深さ = 構造的、結合度 = 全体、能力の限界 = haiku ではこの設計を担えなかったことが明らかです。判断： フェーズ内のすべてのステップを sonnet（抽象化が本当に難しい場合は opus）で再度実行し、再レビューにはフェーズの sonnet ではなく opus を使います。壊れた構造を通してしまったのは sonnet のレビューだからです。
ケース B — 1つのステップだけの失敗。 レビュアーが単一の High の指摘を出し、affected_steps: [02b-token-service]、requires_phase_rework: false で、残る2つのステップには問題がないとします。影響範囲 = 1つのステップ、深さ = 局所的、結合度 = なし、能力の限界 = 未達。設計上の失敗ではなく、見落とされたエッジケースが原因です。判断： 02b-token-service だけを、レビュアーのそのステップに関する指摘とともに、引き続き haiku で再度実行します。残る2つのステップには手を付けず、フェーズの sonnet で再レビューします。

それ以外のすべては、この原則から導かれるものであり、あらかじめ列挙されているわけではありません。 複数のモデルを使ったフェーズ、テストだけに失敗したフェーズ、2度目の失敗に至ったフェーズ、5つのうち2つのステップが結合しているフェーズ――いずれにも決まった答えはありません。範囲 → 深さ → 結合度 → 重大度 → 能力の限界の順に検討し、考えた内容を書き留めたうえで判断してください。判断マトリクスに頼ってはいけません。状況は多様すぎますし、何より考えるべきところで考えるのをやめてしまうことになります。

最終レポートには、検討内容と判断を記録し、各修正モデルを選んだ理由がユーザーにわかるようにしてください。

再試行フィードバックの構築

再ディスパッチすると判断した各ステップについて、このプロンプトを構築します（1ステップにつき1つ、ステップが独立している場合は並列で）：

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Fix step `[step-name]` — Phase [N] review iteration [K] of [MAX_ITERATIONS]

Task File: $TASK_PATH
Sub-Task File: [that step's Sub-Task File path]

The phase this step belongs to failed its quality review. Reviewer combined_score: [X.XX] / threshold [THRESHOLD]

Issues attributed to THIS step:
[paste the reviewer.issues entries whose `step` is this step (plus any `phase-wide` entries), verbatim: source, priority, description, evidence (file:line), impact, suggestion]

Full reviewer report (for additional context, do NOT skim — use the issues list as your primary work list):
[path to reviewer's scratchpad report file under .specs/scratchpad/<hex>.md]

Your task:
- Address every High priority issue attributed to this step
- Address every Medium priority issue attributed to this step
- Do NOT introduce functionality beyond your sub-task file's Expected Output
- Do NOT modify files owned by steps that were NOT re-dispatched
- Re-run tests/lint/build to ensure no regressions

When complete, report:
1. Files changed (paths)
2. Per-issue resolution status (Fixed / Partially Fixed / Skipped with justification)
3. Any new concerns introduced by the fix

再ディスパッチされた各ステップが完了を報告した後、同じフェーズに対して同じ4つの入力で code-reviewer を再度ディスパッチします（成果物リストは増えている可能性があります — 和集合を渡してください）。PASS になるか MAX_ITERATIONS に達するまで繰り返します。

MAX_ITERATIONS に達した場合：

警告をログに記録："Phase [N] did not pass after {MAX_ITERATIONS} iterations (final combined_score: X.XX, threshold: {THRESHOLD})"
次の実装フェーズに進みます（無期限にブロックしないでください）

PASS の場合：フェーズを完了としてマークする

タスクファイルを更新します：
- ### Parallelization Overview テーブル内の各完了したステップを、そのステップ名の隣に [DONE] を付けてマークします
- フェーズ見出しを [REVIEWED] でマークします（例：#### Phase 1: Foundation [REVIEWED]）、または SKIP_REVIEWS が true の場合は [REVIEWED-SKIPPED] でマークします
todos を completed に更新します
combined_score をトラッキングに記録します

各ステップ自身の #### Subtasks と #### Success Criteria のチェックボックスは、実装エージェントが各自のサブタスクファイル内でマークします — あなたではありません。

Human-in-the-Loop チェックポイント（該当する場合）

実装フェーズが PASS した後にのみ、フェーズ識別子が HUMAN_IN_THE_LOOP_PHASES に含まれている場合（または HUMAN_IN_THE_LOOP_PHASES == "*" の場合）、Human-in-the-Loop Behavior のチェックポイントを表示します。

ユーザーがフィードバックを提供した場合：次のフェーズのために保存するか、フィードバックを添えて影響を受けるステップを再ディスパッチします
ユーザーが "n" と言った場合：ワークフローを一時停止し、現在の進捗を報告します
ユーザーが "Y" と言った場合、または続行した場合：次の実装フェーズに進みます

⚠️ チェックポイント：Definition-of-Done 検証に進む前に

DoD 検証に移る前に、ルールに従ったかを確認してください：

ステップごとに1つの実装エージェントを、タスクファイルのパスとそのサブタスクファイルのパスとともにディスパッチしましたか？
すべてのステップを、その Parallelization Overview 行が指定するモデルでディスパッチしましたか（MODEL_OVERRIDE の場合を除く）？
すべての実装フェーズの最後に、そのフェーズの Reviewer model でちょうど1つの sdd:code-reviewer を起動しましたか（SKIP_REVIEWS の場合を除く）？
個々のステップをレビューすることを避けましたか？
THRESHOLD を自分で combined_score に対して適用し、レビュアーにはしきい値を渡しませんでしたか？
すべての修正および再レビューのモデルを選ぶ前に、ブラスト半径について書面で推論しましたか？
オーケストレーターレベルの PASS ルールが満たされた後にのみ、フェーズを [REVIEWED] とマークしましたか？
成果物ファイルを自分で読むことを避けましたか？

タスクファイル（および --refine のサブタスク Expected Outputs）以外のファイルを読んだ場合、あなたは間違っています。停止して再開してください。

ワークフローフェーズ 3：Definition of Done 検証

すべての実装フェーズが完了した後、タスクがすべての Definition of Done 基準を満たしているかを検証します。

ステップ 3.1：Definition of Done 検証を起動する

Task ツールを以下で使用します：

Agent Type: sdd:developer
Model: 設定されている場合は MODEL_OVERRIDE — それ以外の場合は opus
Description: "Verify Definition of Done"
Prompt:

CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT}

Verify all Definition of Done items in the task file.

Task File: $TASK_PATH

Your task:
1. Read the task file and locate the `## Acceptance Criteria` section, then its `**Definition of Done:**` sub-block
2. Go through each checkbox item one by one
3. For each item, verify if it passes by:
   - Running appropriate tests (unit tests, E2E tests)
   - Checking build/compilation status
   - Verifying file existence and correctness
   - Checking code patterns and linting
4. You MUST mark each item in the task file that passed verification with `[X]`
5. Return a structured report:
- List ALL Definition of Done items
- Status for each:
   - ✅ PASS - if the item is complete and verified
   - ❌ FAIL - if the item fails verification, with specific reason why
   - ⚠️ BLOCKED - if the item cannot be verified due to a blocker
- Evidence for each status
- Specific issues for any failures
- Overall pass rate

This is the TASK-LEVEL check, run once, after every implementation phase is done. Unlike a phase review, nothing here is "not yet due" — every Definition of Done item must hold now.

Be thorough - check everything the task requires.

ステップ 3.2：検証結果をレビューする

Definition of Done 検証レポートを受け取ります
どの DoD 項目が PASS で、どの項目が FAIL かを把握します
検証エージェントがすべての DoD 項目が PASS と報告した場合、タスクファイルの最後にすべての DoD 項目が [X] でマークされていることを確認しなければなりません

ステップ 3.3：失敗した DoD 項目を修正する（ある場合）

Definition of Done 項目が FAIL した場合：

1. 失敗した各項目に対して実装エージェントを起動する — Model: 設定されている場合は MODEL_OVERRIDE — それ以外の場合は opus：

Fix Definition of Done item: [Item Description]

Task File: $TASK_PATH

Current Status:
[paste failure details from verification report]

Your task:
1. Fix the specific issue identified
2. Verify the fix resolves the problem
3. Ensure no regressions (all tests still pass)

Return:
- What was fixed
- Confirmation the item now passes
- Any related changes made

2. 修正後に再検証する：

検証エージェントを再度起動し（ステップ 3.1）、すべての項目が PASS になったことを確認します。

3. 必要に応じて繰り返す：

すべての Definition of Done 項目が PASS になるまで、修正 → 検証のサイクルを繰り返します。

ワークフローフェーズ 4：タスクを完了に移動する

すべての Definition of Done 項目が PASS になったら、タスクを done フォルダに移動します。

ステップ 4.1: 完了の検証

タスクファイル内ですべての完了の定義 (Definition of Done) 項目が完了としてマークされていることを確認します。

ステップ 4.2: タスクの移動

# Extract just the filename from $TASK_PATH
TASK_FILENAME=$(basename $TASK_PATH)

# Move from in-progress to done
git mv .specs/tasks/in-progress/$TASK_FILENAME .specs/tasks/done/
# Fallback if git not available: mv .specs/tasks/in-progress/$TASK_FILENAME .specs/tasks/done/

.specs/sub-tasks/<task-name>/ を移動しないでください。 それはその場に留まります。タスクファイルに記録されたパスは解決可能なままでなければなりません。

ワークフローフェーズ 5: 集約とレポート

最終レポート

すべての実装フェーズが完了し、DoD 検証に合格した後:

## Implementation Summary

### Task Status
- Task Status: `done` ✅
- All Definition of Done items: X/X PASS (100%)

### Configuration Used

| Setting | Value |
|---------|-------|
| **Model Override** | {MODEL_OVERRIDE or "None (models from task file)"} |
| **Threshold** | {THRESHOLD}/5.0 |
| **Max Iterations** | {MAX_ITERATIONS or "3"} |
| **Human Checkpoints** | {HUMAN_IN_THE_LOOP_PHASES or "None"} |
| **Skip Reviews** | {SKIP_REVIEWS} |
| **Continue Mode** | {CONTINUE_MODE} |
| **Refine Mode** | {REFINE_MODE} |
| **Strict Mode** | {STRICT_MODE} |

### Steps Completed

| Step | Phase | Model Used | Status |
|------|-------|------------|--------|
| `01-foundation` | Phase 1 | haiku | ✅ |
| `02a-service` | Phase 1 | sonnet | ✅ |
| `03-integration` | Phase 2 | sonnet | ✅ (re-dispatched at opus in iteration 1) |

### Phase Reviews

| Phase | Steps | Reviewer Model | Combined Score | Iterations | Status |
|-------|-------|----------------|----------------|------------|--------|
| Phase 1 | 2 | sonnet | 4.3/5 | 1 | ✅ |
| Phase 2 | 1 | opus | 3.6/5 | 2 | ☑️ |

**Legend:**
- ✅ PASS - `combined_score >= THRESHOLD`
- ☑️ ACCEPTED - Score in discretion band `3.0 <= combined_score < THRESHOLD` accepted per the [Iteration Discretion Rule](#iteration-discretion-rule) (outstanding nitpicks listed under Recommendations)
- ⚠️ MAX_ITER - Did not pass but MAX_ITERATIONS reached, proceeded anyway
- ⏭️ SKIPPED - Review skipped (`--skip-reviews`, continue or refine mode); the phase heading carries `[REVIEWED-SKIPPED]`, not `[REVIEWED]`

### Fix Decisions (blast-radius reasoning)

| Phase | Iteration | Findings scope | Fix model chosen | Re-review model | Reasoning |
|-------|-----------|----------------|------------------|-----------------|-----------|
| Phase 2 | 1 | 1 of 1 step, structural | opus (was sonnet) | opus (was opus) | Shared abstraction wrong; sonnet had already failed on it |

### Review Summary

- Total implementation phases: X
- Phases reviewed: Y
- Passed on first review: Z
- Accepted below target per Iteration Discretion Rule: U (outstanding nitpicks listed under Recommendations)
- Required fix iterations: W
- Total iterations across all phases: V
- Final pass rate: 100%

### Definition of Done Verification

| Item | Status | Evidence |
|------|--------|----------|
| [DoD Item 1] | ✅ PASS | [Brief evidence] |
| [DoD Item 2] | ✅ PASS | [Brief evidence] |
| ... | ... | ... |

**Issues Fixed During Verification:**
1. [Issue]: [How it was fixed]
2. [Issue]: [How it was fixed]

### Human Review Summary (if --human-in-the-loop used)

| Phase | Checkpoint | User Action | Feedback Incorporated |
|-------|------------|-------------|----------------------|
| Phase 1 | After PASS | Continued | - |
| Phase 2 | After iteration 1 | Feedback | "Improve error messages" |

### Task File Updated

- Task moved from `in-progress/` to `done/` folder
- All step rows marked `[DONE]` in the Parallelization Overview
- All phase headings marked `[REVIEWED]` in the Phase Overview — or `[REVIEWED-SKIPPED]` for phases whose review `--skip-reviews` suppressed
- All Definition of Done items marked `[X]`
- Sub-task files' subtasks marked `[X]` by their implementation agents

### Recommendations

1. [Any follow-up actions]
2. [Suggested improvements]

実行フロー図

┌──────────────────────────────────────────────────────────────┐
│                IMPLEMENT TASK WITH VERIFICATION               │
├──────────────────────────────────────────────────────────────┤
│                                                               │
│  Workflow Phase 0: Select Task                                │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Use provided name or auto-select from todo/ (if 1 task) │  │
│  │ → Move task from todo/ to in-progress/                  │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Workflow Phase 1: Load Task                                  │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Read $TASK_PATH → Parse Parallelization Overview        │  │
│  │ (steps, models, agents, sub-task paths) + Phase         │  │
│  │ Overview (phases, reviewer models) → TodoWrite          │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Workflow Phase 2: Execute Implementation Phases              │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │                                                          │  │
│  │  For each implementation phase:                          │  │
│  │                                                          │  │
│  │  ┌──────────────┐                                        │  │
│  │  │ step agent   │─┐                                      │  │
│  │  ├──────────────┤ │ (parallel where the plan says so)    │  │
│  │  │ step agent   │─┤                                      │  │
│  │  ├──────────────┤ │                                      │  │
│  │  │ step agent   │─┘                                      │  │
│  │  └──────────────┘ │                                      │  │
│  │                   ▼                                      │  │
│  │        ┌─────────────────────┐    ┌───────────┐          │  │
│  │        │ ONE code-reviewer   │───▶│ PASS?     │          │  │
│  │        │ for the whole phase │    │           │          │  │
│  │        └─────────────────────┘    └───────────┘          │  │
│  │                                     │      │             │  │
│  │                                   PASS   FAIL            │  │
│  │                                     │      │             │  │
│  │                                     ▼      ▼             │  │
│  │                            ┌──────────┐  Blast-radius    │  │
│  │                            │ Mark     │  reasoning →     │  │
│  │                            │[REVIEWED]│  fix model +     │  │
│  │                            └──────────┘  scope + re-     │  │
│  │                                          review model ↺  │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Workflow Phase 3: Definition of Done Verification            │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │                                                         │  │
│  │  ┌──────────────┐    ┌───────────────┐    ┌───────────┐ │  │
│  │  │ DoD Verifier │───▶│ All DoD       │───▶│ All PASS? │ │  │
│  │  │ Agent        │    │ items checked │    │           │ │  │
│  │  └──────────────┘    └───────────────┘    └───────────┘ │  │
│  │                                                │   │    │  │
│  │                                               Yes  No   │  │
│  │                                                │   │    │  │
│  │                                                ▼   ▼    │  │
│  │                                                Fix &    │  │
│  │                                                Retry    │  │
│  │                                                ↺        │  │
│  │                                                         │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Workflow Phase 4: Move Task to Done                          │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ mv in-progress/$TASK → done/$TASK                       │  │
│  └─────────────────────────────────────────────────────────┘  │
│                           │                                   │
│                           ▼                                   │
│  Workflow Phase 5: Aggregate & Report                         │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │ Collect all phase review results                        │  │
│  │ → Calculate aggregate metrics                           │  │
│  │ → Generate final report                                 │  │
│  │ → Present to user                                       │  │
│  └─────────────────────────────────────────────────────────┘  │
│                                                               │
└──────────────────────────────────────────────────────────────┘

使用例

基本的な使用法

# Implement a specific task
/implement add-validation.feature.md

# Auto-select task from todo/ or in-progress/ (if only 1 task)
/implement

# Continue from the last completed step
/implement add-validation.feature.md --continue

# Refine after user fixes project files (detects changes, re-verifies affected phases)
/implement add-validation.feature.md --refine

# Human review after every implementation phase
/implement add-validation.feature.md --human-in-the-loop

# Human review after specific phases only
/implement add-validation.feature.md --human-in-the-loop "Phase 1,Phase 3"

# Higher quality threshold (stricter)
/implement add-validation.feature.md --target-quality 4.5

# Lower quality threshold (faster convergence)
/implement add-validation.feature.md --target-quality 3.5

# Unlimited iterations (default is 3)
/implement add-validation.feature.md --max-iterations unlimited

# Skip all phase reviews (fast but no quality gates)
/implement add-validation.feature.md --skip-reviews

# Strict mode: never accept a phase below target - iterate until threshold or MAX_ITERATIONS
/implement add-validation.feature.md --strict

# Force ALL sub-agents (implementers + code-reviewer) onto one model, overriding the task file
/implement add-validation.feature.md --model sonnet

# Combined: continue with human review
/implement add-validation.feature.md --continue --human-in-the-loop

例 1: 機能の実装

User: /implement add-validation.feature.md

Workflow Phase 0: Task Selection...
Found task in: .specs/tasks/todo/add-validation.feature.md
Moving to in-progress: .specs/tasks/in-progress/add-validation.feature.md

Workflow Phase 1: Loading task...
Task: "Add form validation service"
Parallelization Overview: 4 steps
Phase Overview: 2 implementation phases
- Phase 1: 01-validation-types, 02-validation-service — reviewer sonnet
- Phase 2: 03a-email-validator, 03b-phone-validator — reviewer opus
Threshold: 4.0/5.0

Workflow Phase 2: Executing...

Phase 1 / step 01-validation-types [haiku]
  Prompt: task file + .specs/sub-tasks/add-validation/01-validation-types.md
  Result: ✅ src/validation/types.ts

Phase 1 / step 02-validation-service [sonnet]
  Prompt: task file + .specs/sub-tasks/add-validation/02-validation-service.md
  Result: ✅ src/validation/validation.service.ts + spec

  Launching 1 sdd:code-reviewer for Phase 1 (model: sonnet)...
  Inputs: task file path, "Phase 1", 3 artifact paths, CLAUDE_PLUGIN_ROOT
  combined_score 4.3/5.0 ≥ threshold 4.0 → PASS ✅
  Marking Phase 1 [REVIEWED]

Phase 2 / steps 03a-email-validator, 03b-phone-validator [haiku, haiku] — dispatched in parallel
  Result: ✅ 2 validators + specs

  Launching 1 sdd:code-reviewer for Phase 2 (model: opus)...
  combined_score 4.5/5.0 ≥ threshold 4.0 → PASS ✅

Workflow Phase 3: Definition of Done Verification...
  Result: 4/4 items PASS ✅

Workflow Phase 4: Moving task to done...

Workflow Phase 5: Final Report
Implementation complete.
- 4/4 steps completed, 2/2 phases reviewed
- All passed first review
- Definition of Done: 4/4 PASS
- Task location: .specs/tasks/done/add-validation.feature.md ✅

例 2: DoD 項目の失敗への対処

[All implementation phases complete and reviewed...]

Workflow Phase 3: Definition of Done Verification...
Launching DoD verification agent...
  Result: 3/4 items PASS, 1 FAIL ❌

Failing item:
- "Code follows ESLint rules": 356 errors found

Should I attempt to fix this issue? [Y/n]

User: Y

Launching sdd:developer agent...
  Result: Fixed 356 errors, 0 warnings ✅

Re-launching DoD verification agent...
  Result: 4/4 items PASS ✅

Workflow Phase 4: Moving task to done...
All DoD checkboxes marked complete ✅

以下の例 3 と例 4 は、失敗処理にある同じアンカーケースの 2 つの半分を、セッションログとしてエンドツーエンドで示したものです。これらは状況のカタログではありません。その他のあらゆる失敗は、原則から推論されるものであり、決して調べられるものではありません。

例 3: フェーズレビューの失敗 — アンカー例のケース A、セッションログとして

Phase 2 complete: steps 03a, 03b, 03c — all built by haiku.
Launching 1 sdd:code-reviewer for Phase 2 (model: sonnet)...

combined_score 2.1/5.0 — below threshold 4.0 and below the 3.0 floor → FAIL (no discretion)

Reviewer blast_radius:
  affected_steps: [03a-parser, 03b-evaluator, 03c-formatter]
  unaffected_steps: []
  requires_phase_rework: true

Blast-radius reasoning:
- Scope: all 3 steps carry High findings
- Depth: structural — the shared Rule interface the three steps agreed on is wrong
- Coupling: total — fixing one forces rewriting the other two
- Severity: 4 High findings, 2 of them break CK-3 and CK-4, which Phase 2 owns
- Ceiling: haiku produced three mutually inconsistent takes on the same interface
→ Fix model: sonnet for all three steps (was haiku)
→ Fix scope: whole phase
→ Re-review model: opus (was sonnet) — the sonnet review is what let this shape through

Iteration 1/3: re-dispatching 03a, 03b, 03c at sonnet with their per-step issues...
Re-launching sdd:code-reviewer for Phase 2 at opus...
combined_score 4.4/5.0 ≥ threshold 4.0 → PASS ✅
Marking Phase 2 [REVIEWED]

例 4: フェーズレビューの失敗 — アンカー例のケース B、セッションログとして

Phase 1 complete: steps 01a, 01b, 01c — all built by haiku.
Launching 1 sdd:code-reviewer for Phase 1 (model: sonnet)...

combined_score 3.4/5.0 — below threshold 4.0, inside discretion band → but a High finding removes discretion → FAIL

Reviewer blast_radius:
  affected_steps: [01b-token-service]
  unaffected_steps: [01a-user-model, 01c-config]
  requires_phase_rework: false

Blast-radius reasoning:
- Scope: 1 of 3 steps
- Depth: local — a missed expiry edge case, not a design failure
- Coupling: none — 01a and 01c do not touch the token path
- Severity: 1 High, breaks CK-2 which Phase 1 owns
- Ceiling: not reached — the step's design is right, one branch is missing
→ Fix model: haiku (unchanged)
→ Fix scope: 01b-token-service ONLY — 01a and 01c are not re-dispatched
→ Re-review model: sonnet (the phase's Reviewer model, unchanged)

Iteration 1/3: re-dispatching 01b-token-service at haiku...
Re-launching sdd:code-reviewer for Phase 1 at sonnet...
combined_score 4.2/5.0 ≥ threshold 4.0 → PASS ✅

例 5: 中断からの再開

User: /implement add-validation.feature.md --continue

Workflow Phase 0: Parsing flags...
Configuration:
- Continue Mode: true
- Threshold: 4.0/5.0 (default)

Scanning task file...
Parallelization Overview: 01-... [DONE], 02-... [DONE], 03-..., 04-...
Phase Overview: Phase 1 [REVIEWED], Phase 2 (not reviewed)
RESUME_PHASE = Phase 2
RESUME_STEPS = 03-..., 04-...

Resuming: dispatching 03-... and 04-... (parallel per the plan)...
[both complete]

Launching 1 sdd:code-reviewer for Phase 2 (model: opus)...
combined_score 4.3/5.0 ≥ threshold 4.0 → PASS ✅

例 6: ユーザーによる修正後のリファイン

# User manually fixed src/validation/validation.service.ts
# (Expected Output of step 02-validation-service, in Phase 1)

User: /implement add-validation.feature.md --refine

Workflow Phase 0: Parsing flags...
Configuration:
- Refine Mode: true

Detecting changed project files...
- src/validation/validation.service.ts (modified)

Mapping files to steps (reading sub-task Expected Output sections)...
- src/validation/validation.service.ts → 02-validation-service → Phase 1

Earliest affected phase: Phase 1
Preserving: nothing earlier
Re-verifying from: Phase 1 onwards

Launching 1 sdd:code-reviewer for Phase 1...
combined_score 4.3/5.0 ≥ threshold 4.0 → PASS ✅

Launching 1 sdd:code-reviewer for Phase 2...
combined_score 2.8/5.0 — High finding "typescript error in src/validation/index.ts" → FAIL
Blast radius: 1 step (04-barrel-exports), local, no coupling, ceiling not reached
→ re-dispatch 04-barrel-exports at its original model with the user's diff as context

Re-launching sdd:code-reviewer for Phase 2...
combined_score 4.5/5.0 → PASS ✅

All phases verified with user's changes incorporated ✅

例 7: ヒューマン・イン・ザ・ループのレビュー

User: /implement add-validation.feature.md --human-in-the-loop

Configuration:
- Human Checkpoints: All phases

Phase 1 / steps 01-..., 02-... dispatched...
Result: ✅ complete

Launching 1 sdd:code-reviewer for Phase 1 (model: sonnet)...
combined_score 4.4/5.0 ≥ threshold 4.0 → PASS ✅

---
## 🔍 Human Review Checkpoint - Phase 1

**Phase:** Phase 1: Validation Core
**Steps:** `01-validation-types`, `02-validation-service`
**Reviewer model:** sonnet
**Combined Score:** 4.4/5.0 (threshold: 4.0)
**Status:** ✅ PASS

**Artifacts Created/Modified:**
- src/validation/types.ts
- src/validation/validation.service.ts
- src/validation/tests/validation.service.spec.ts

**Reviewer Feedback (top issues):**
- [Low] `02-validation-service` — Error messages could be more descriptive

**Action Required:** Review the above artifacts and provide feedback or continue.

> Continue? [Y/n/feedback]: The error messages could be more descriptive
---

Incorporating feedback: re-dispatching 02-validation-service with the feedback...
[iteration continues]

例 8: 厳格な品質しきい値

User: /implement add-validation.feature.md --strict

Configuration:
- Strict Mode: true (Iteration Discretion Rule DISABLED)
- Threshold: 4.0/5.0 (default)
- Max Iterations: 3 (default)

Phase 1 / steps 01-..., 02-... dispatched...

Launching 1 sdd:code-reviewer for Phase 1 (model: sonnet)...
combined_score 3.6/5.0 — outstanding issues are 2 Low nitpicks only
Without --strict this would sit in the discretion band (3.0 <= 3.6 < 4.0) and be ☑️ ACCEPTED.
--strict disables that discretion → FAIL, iterate.

Blast radius: 1 step (02-validation-service), local → re-dispatch it with the reviewer feedback
Re-launching sdd:code-reviewer for Phase 1 (iteration 2)...
combined_score 4.2/5.0 ≥ threshold 4.0 → PASS ✅
Marking Phase 1 [REVIEWED]

エラー処理

実装の失敗

実装エージェントが失敗を報告した場合:

失敗の詳細をユーザーに提示する
解決に役立つ可能性のある確認質問をする
そのステップについて、確認内容を踏まえてエージェントを再ディスパッチする
ステップの失敗はフェーズのレビューを遅延させますが、決してスキップさせません。フェーズのすべてのステップが完了を報告したら、フェーズレビューは通常どおり正確に実行されます (ただし SKIP_REVIEWS の場合を除く)。

レビュアーが無効なレポートを返した場合

sdd:code-reviewer が、実行と評価のルールのいずれかのルールに抵触するレポートを返した場合 — 5.0 の combined_score、combined_score の欠落、PASS/FAIL の判定、またはそのフェーズが担当しない受け入れ基準に対する指摘 — それは却下し、同じ 4 つの入力を用いてエージェントを再実行してください。そのレポートを自分で修正してはいけません。

リファインモード: 変更が検出されない

--refine モードでプロジェクトに git の変更が見つからない場合:

報告する: 「前回のコミット以降、プロジェクトファイルの変更は検出されませんでした。」
提案する: 「まずプロジェクトファイルを編集してから、再度 --refine を実行してください。」
あるいは: 「すべてのステップを再実装するには、--refine を付けずに実行してください。」

リファインモード: 変更がステップに対応しない

--refine モードで変更されたファイルが見つかったものの、いずれもステップの期待される出力に対応しない場合:

報告する: 「変更されたファイルは、どのステップの期待される出力とも一致しません。」
検出された変更ファイルを一覧表示する
提案する: 「手動で確認するか、すべてのフェーズを再検証するには --refine を付けずに実行してください。」

サブタスクファイルが見つからない場合

並列化の概要にある Sub-Task File パスが存在しない場合:

.specs/sub-tasks/<task-file-basename-without-extension>/<step-name>.md を試してください — フォルダーは決して移動しないため、古いパスは通常復元可能です
それでも見つからない場合は、ユーザーに報告して停止してください。ステップの内容をでっち上げてはいけません。また、タスクファイルのみでエージェントをディスパッチしてもいけません。

チェックリスト

実装を完了する前に:

設定の処理

コンテキスト保護（重要）

タスクファイル（.specs/tasks/in-progress/ 内の $TASK_PATH）のみを読み取った — --refine モードではサブタスクの #### Expected Output セクションも対象とし、それ以外は何も読まなかった
実装の出力、参照ファイル、成果物を読み取らなかった
ステータスにはサブエージェントの報告を使用し、確認のためにファイルを読み取らなかった

委任

すべてのステップを、それぞれ独自のサブエージェントが Task ツール経由で実装し、タスクファイルのパスとサブタスクファイルのパスを指定した
（MODEL_OVERRIDE がない限り）各ステップを、Parallelization Overview の該当行に記載されたモデルとエージェントタイプでディスパッチした
（SKIP_REVIEWS の場合を除き）実装フェーズごとに sdd:code-reviewer を正確に 1 回ディスパッチし、そのフェーズの Reviewer model を使用した
個々のステップをレビューしなかった
自分自身では検証を行わなかった

進捗の追跡

エージェントから完了報告を受けた後、Parallelization Overview の各ステップの行を [DONE] にした
オーケストレーター全体の PASS 後にのみ各フェーズの見出しを [REVIEWED] にした（SKIP_REVIEWS の場合は [REVIEWED-SKIPPED]）
各ステップの後、および各フェーズレビューの後に ToDo リストを更新した

実行品質

すべてのステップを依存関係の順序に従って実行した
Parallel with: グループを順次ではなく、1 つのメッセージ内で同時に開始した
前のフェーズのレビューが終わる前に、後続フェーズのステップを開始しなかった
修正モデル、修正範囲、再レビュー用モデルを選択する前に、影響範囲の推論を明記した
影響を受けたステップのみを再ディスパッチし、問題のないステップには手を加えなかった
レビューに失敗した場合、レビュー担当者の issues（ステップごとに分類）をフィードバックとして使用し、オーケストレーター全体の PASS に達するまで反復した
フェーズレビューの結果と修正判断を含む最終レポートを生成した

ヒューマン・イン・ザ・ループ（有効な場合）

HUMAN_IN_THE_LOOP_PHASES に含まれる各実装フェーズの後にチェックポイントを表示した
ユーザーのフィードバックを後続の反復やフェーズに反映した
ユーザーが要求した場合、ワークフローを一時停止した

最終検証と完了

完了定義の検証エージェントを起動し、## Acceptance Criteria → **Definition of Done:** を読み取らせた
DoD のすべての項目を検証した（PASS/FAIL/BLOCKED のステータス）
DoD で不合格となった項目を実装エージェントで修正した
修正後に再検証を実施した
タスクを in-progress/ フォルダーから done/ フォルダーへ移動した（サブタスクフォルダーはそのまま残した）
タスクファイル内の DoD チェックボックスをすべて [X] にした
最終検証レポートをユーザーに提示した

付録 A：タスクファイルとサブタスクファイルの内容

この付録では、このスキルが使用する成果物について説明します。これは読み方のガイドであり、ワークフローフェーズ 1 で許可されている範囲を超えてファイルを読むよう指示するものではありません。

タスクファイルの構成

計画済みのタスクファイルには、次のセクションが過不足なく含まれます。

セクション	作成者	このスキルでの用途
`# Description`	`sdd:business-analyst`	直接の用途なし — サブエージェントが読みます
`## Acceptance Criteria`	`sdd:business-analyst`	`Definition of Done:` サブブロックのみ、ワークフローフェーズ 3 で使用します
`## Architecture Overview`	`sdd:software-architect`	直接の用途なし — サブエージェントが読みます
`## Implementation Process`	`sdd:tech-lead`	すべて：ディスパッチ、モデル、フェーズ、レビューゲート

## Acceptance Criteria には、次の 6 つのサブブロックがこの順序で過不足なく含まれます：**Checklist:**、**Regular Checks:**、**Rubric:**、**Rubric Score Definitions:**、**Test Strategy:**、**Definition of Done:**。最初の 5 つはレビュー担当者への入力であり、フェーズごとに対象が限定されます — 読み取ったり、転送したりすることはありません。

タスクファイルには、スコアリング設定は一切含まれません — しきい値、判定者数、ステップごとのレビュー用メタデータはありません。スコアリングはオーケストレーターの設定のみで行います。タスクファイルに上記の表に記載されていないセクションが含まれている場合、それは古い計画の残存物です。無視し、最終レポートでその旨を記載してください。

`## Implementation Process`

## Implementation Process

[sub-agent execution directive: launch one agent per step; verify at PHASE level]

### Parallelization Overview

[ASCII dependency diagram]

| Step | Phase | Model | Agent | Depends on | Parallel with | Sub-Task File |
|------|-------|-------|-------|------------|---------------|---------------|
| `01-foundation` | Phase 1 | haiku | developer | None | None | `.specs/sub-tasks/<task-name>/01-foundation.md` |
| `02a-service` | Phase 1 | sonnet | developer | `01-foundation` | `02b-docs` | `.specs/sub-tasks/<task-name>/02a-service.md` |

### Phase Overview

#### Phase 1

Steps: `01-foundation`, `02a-service`
Reviewer model: `sonnet`
Acceptance Criteria that should be fulfiled:
Checklist items:
- `CK-1` — ...
- `CK-2` — ...

Rubrics:
- `Contract Correctness`

フェーズ識別子は Phase N です（タイトルが続く場合もあります：#### Phase 1: Foundation）。レビュー担当者に渡すのは、この正確な識別子です。
Reviewer model: は haiku、sonnet、opus のいずれかです。これは、そのフェーズで 1 回だけ行うレビューのディスパッチに使用するモデルです。
Checklist items: と Rubrics: のリストは、レビュー担当者のスコアリング対象を定めます。これらはレビュー担当者への入力であり、あなたへの入力ではありません — レビュー担当者がタスクファイル自体から読み取ります。プロンプトに貼り付けないでください。

サブタスクファイル

各ステップにつき 1 つ、.specs/sub-tasks/<task-name>/<NN>-<step-slug>.md にあります。<task-name> は拡張子を除いたタスクファイル名です。フォルダーの場所は変わりません。

# Step NN: [Title]

**Task File:** `.specs/tasks/todo/<task-name>.md`
**Phase:** Phase N
**Model:** haiku | sonnet | opus
**Agent:** [agent type]
**Depends on:** [step names or None]
**Parallel with:** [step names or None]
**Note:** [or None]

**Goal:** ...

[step description]

#### Expected Output
#### Success Criteria
#### Subtasks
#### Blockers & Risks

ステップ名は、.md を除いたファイルのベース名です。これは Steps:、Depends on:、Parallel with: およびレビュー担当者による課題ごとの帰属で使用する識別子です。

スコアリング尺度

sdd:code-reviewer は、独自の ## Scoring Scale セクションで定義されている 1〜5 の整数尺度で、すべての基準を採点します。このセクションが唯一の定義であり、意図的にここでは再掲していません — 採点はレビュー担当者が行います。あなたは採点せず、combined_score と THRESHOLD を比較するだけです。どのようなプロンプトやレポートでも、この尺度や独自に作成した尺度を言い換えて記載しないでください。

あなたに関係する唯一の点： 反復判断ルールを適用する際は、スコアを直感的な「5 点満点」の感覚や adequate、excellent などの言葉で解釈せず、尺度上の位置として読み取ってください。

実行中のこれらの成果物の使用方法

ワークフローフェーズ 2 では：

各ステップのエージェントを、その Model でディスパッチし、タスクファイルのパスとサブタスクファイルのパスを渡します
実装フェーズのすべてのステップから完了報告が届くまで待ちます
そのフェーズの Reviewer model で sdd:code-reviewer を 1 つ起動します — Model：MODEL_OVERRIDE が設定されている場合はその値 — そうでない場合はそのフェーズの Reviewer model — それもない場合は opus
4 つの入力（タスクファイルのパス、フェーズ識別子、成果物のパス、CLAUDE_PLUGIN_ROOT）だけを渡します — しきい値は絶対に渡さず、サブタスクのパスも絶対に渡さないでください
レビュー担当者の統合レポートを受け取ります
このレイヤーで THRESHOLD を combined_score に適用します
FAIL の場合、影響範囲を検討し、影響を受けるステップだけの修正をディスパッチして、フェーズを再レビューします

Markdown 対応

ログインしてコメント

基本情報

作者: neolabhq
リポジトリ: neolabhq/context-engineering-kit
カテゴリ: 開発
インストール数: 1,248
GitHub スター: 1,792

問題を報告