writing-plans

計画の作成

重大な制約 — 何よりも先にお読みください

このスキルの実行中は、いかなる場合も EnterPlanMode または ExitPlanMode を呼び出してはいけません。 このスキルは通常モードで動作し、AskUserQuestion を通じて独自の完了フローを管理します。EnterPlanMode を呼び出すと、Write/Edit が制限される計画モードにセッションが固定されます。ExitPlanMode を呼び出すと、ワークフローが中断され、ユーザーの実行方法の選択がスキップされます。どちらかを呼び出したくなったら、いったん停止し、このスキルの指示に従ってください。

概要

コードベースの知識がまったくなく、好みも疑わしいエンジニアを想定して、包括的な実装計画を作成します。各タスクで変更するファイル、コード、確認が必要なテストやドキュメント、テスト方法など、必要な情報をすべて記載します。計画全体を、取り組みやすい小さなタスクに分割します。DRY。YAGNI。TDD。こまめにコミットします。

対象者は優秀な開発者ですが、こちらのツールセットや問題領域についてはほとんど知らないものとします。また、適切なテスト設計についてもあまり知らないものとします。

最初に宣言します： 「writing-plans スキルを使用して、実装計画を作成します。」

コンテキスト： 分離されたワークツリーで作業する場合、実行時に superpowers-extended-cc:using-git-worktrees スキルを使用して作成しておく必要があります。

計画の保存先： docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md

• （計画の保存場所に関するユーザーの希望があれば、こちらを優先します）

スコープの確認

仕様が複数の独立したサブシステムを対象としている場合は、ブレインストーミングの段階でサブプロジェクトの仕様に分割しておく必要があります。そうなっていない場合は、サブシステムごとに個別の計画へ分割するよう提案します。各計画は、それぞれ単独で動作し、テスト可能なソフトウェアを作成できるものでなければなりません。

ファイル構成

タスクを定義する前に、作成または変更するファイルと、それぞれの役割を整理します。ここで分解の方針を確定します。

• 境界が明確で、インターフェースが十分に定義された単位を設計します。各ファイルの責任は、ひとつに明確化します。
• 一度に把握できるコードについては、より的確に推論できます。また、対象を絞ったファイルほど編集の信頼性も高まります。多くの役割を担う大きなファイルよりも、小さく、目的が明確なファイルを優先します。
• 一緒に変更するファイルは、同じ場所にまとめます。技術レイヤーではなく、責任に基づいて分割します。
• 既存のコードベースでは、確立されたパターンに従います。コードベースで大きなファイルが使われている場合、独断で再構成してはいけません。ただし、変更対象のファイルが扱いにくいほど大きくなっている場合は、計画に分割を含めてもかまいません。

この構成をもとに、タスクを分解します。各タスクでは、単独で意味をなす、一貫した変更を行います。

必須の最初のステップ：タスク追跡を初期化する

コードの調査や計画の作成を始める前に、必ず次のことを行ってください：

1. TaskList を呼び出し、ブレインストーミングで作成された既存のタスクがあるか確認します
2. タスクがある場合：計画の作成中に、実装の詳細を追加します
3. タスクがない場合：計画の各タスクを作成する際に、TaskCreate でタスクを作成します

TaskList を呼び出すまで、調査に進んではいけません。 これには、バックグラウンド調査や並行調査を行うサブエージェントの起動も含まれます。TaskList は高速かつ同期的なので、最初に呼び出してから調査エージェントを並行して起動してください。

TaskList

タスクの粒度

各タスクは、テスト可能でコミット可能な成果を生み出す、一貫した作業単位です。

粒度の詳しい指針については、skills/shared/task-format-reference.md を参照してください。

重要な原則：TDD のサイクルは、タスクとは別ではなく、タスクの中で行います。タスクは「テストを含めて X を実装する」という単位です。red-green-refactor の手順はタスク内の実行詳細であり、タスクの境界ではありません。

スコープの確認：

1. 独立して検証できますか？（できない場合 → 小さすぎます）
2. 複数の関心事にまたがっていますか？（またがる場合 → 大きすぎます）
3. 独立したコミットにしますか？（しない場合 → 隣接するタスクと統合します）

計画ドキュメントのヘッダー

すべての計画は、必ず次のヘッダーから始めてください：

# [Feature Name] Implementation Plan

> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers-extended-cc:subagent-driven-development (recommended) or superpowers-extended-cc:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.

**Goal:** [One sentence describing what this builds]

**Architecture:** [2-3 sentences about approach]

**Tech Stack:** [Key technologies/libraries]

**Spec:** [path to the spec/design doc this plan implements — the plan
argues from the spec, so the spec travels with it; executors read both]

## Global Constraints

[Binding requirements every task must respect — exact values, formats, cross-component relationships ("same layout as X", "matches Y"). Execution controllers hand these to every reviewer. "none" if none.]

**User decisions (already made):** [One line per decision the user made during brainstorming/planning, quotable. "none" if none.]

---

保留中の決定事項

計画でユーザーへの質問（DECIDE リスト、AskUserQuestion の手順）が予定されている場合、各質問は次の条件を満たす必要があります。

• ヘッダーの決定事項があるにもかかわらず、なぜ未解決なのかを説明します。記録された決定事項で回答できる場合は、その記録に基づいて回答し、再度質問しません。
• 回答に必要な事実を選択肢の説明に記載します。成果物の名前と役割／状態を明記し（例：「古い GitHub ミラー、最終プッシュは 2026-03-25 — ローカルツールの開発環境とは別」）、各選択肢で変更されないものも示します。
• 記録された決定事項に反する推奨はしません。それは計画の不備です（No Placeholders と同じ重大度です）。

タスクの構成

### Task N: [Component Name]

**Goal:** [One sentence — what this task produces]

**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`

**Acceptance Criteria:**
- [ ] [Concrete, testable criterion]
- [ ] [Another criterion]

**Verify:** `exact test command` → expected output

**Steps:**

- [ ] **Step 1: Write the failing test**

```python
def test_specific_behavior():
    result = function(input)
    assert result == expected
```

- [ ] **Step 2: Run test to verify it fails**

Run: `pytest tests/path/test.py::test_name -v`
Expected: FAIL with "function not defined"

- [ ] **Step 3: Write minimal implementation**

```python
def function(input):
    return expected
```

- [ ] **Step 4: Run test to verify it passes**

Run: `pytest tests/path/test.py::test_name -v`
Expected: PASS

- [ ] **Step 5: Commit**

```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```

プレースホルダー禁止

各手順には、エンジニアが必要とする具体的な内容をすべて含めてください。以下は計画の不備です。決して記載しないでください。

• 「TBD」、「TODO」、「後で実装する」、「詳細を記入する」
• 「適切なエラー処理を追加する」／「検証を追加する」／「エッジケースに対処する」
• 実際のテストコードを示さずに「上記のテストを書く」
• 「タスク N と同様」（タスクの順番どおりに読むとは限りません。コードを再掲してください）
• 方法を示さずに実行内容だけを説明する手順（コードを伴う手順にはコードブロックが必要です）
• いずれのタスクでも定義されていない型、関数、メソッドへの参照

セルフレビュー

計画全体を書き終えたら、視点を新たにして仕様を確認し、計画と照らし合わせます。これは自分で実行するチェックリストであり、サブエージェントへの依頼ではありません。

1. 仕様の網羅性： 仕様の各セクション／要件に目を通します。それを実装するタスクを挙げられますか？不足している点があれば列挙します。

2. プレースホルダーの確認： 上記の「プレースホルダー禁止」セクションにあるパターンなど、問題のある記述が計画にないか検索します。見つかったら修正します。

3. 型の一貫性： 後続のタスクで使用している型、メソッドシグネチャ、プロパティ名が、先行タスクで定義したものと一致しているか確認します。タスク 3 では clearLayers()、タスク 7 では clearFullLayers() と呼ぶような関数名の不一致はバグです。

問題が見つかった場合は、その場で修正します。再確認する必要はありません。修正して先に進みます。対応するタスクがない仕様要件が見つかった場合は、そのタスクを追加します。

ゲート適用に関する注意（ユーザーゲートのタスクにタグが付いており、フックがまだ登録されていない場合のみ）

計画に userGate: true のタスクが含まれている場合、ユーザーがすでにオプトインしているかを確認します（Claude Code がマージする、ユーザーが編集可能な 3 つの設定ファイル、つまりプロジェクトの settings.local.json と settings.json、およびユーザーの ~/.claude/settings.json を検索します。存在しないファイルは何も表示せずスキップされます）。

cat .claude/settings.local.json .claude/settings.json ~/.claude/settings.json 2>/dev/null | grep -q "post-task-complete-revalidate.sh"

パイプラインが 0 で終了した場合（いずれかのファイルに正式なユーザーゲートフックが登録済みの場合）→ 注意書きを一切表示しません。ユーザーはすでに有効化しています。

それ以外の場合は、Execution Handoff の前に次の短い注意書きを表示します（{N} とタスク番号を置き換えます）。

注意：{N} 件のタスクにユーザーゲート（タスク #X、#Y、…）のタグを付けました。計画はこのまま最後まで実行できます。終了時に自動で適用する場合は、JSON スニペットを README.md で確認し、.claude/settings.json（または settings.local.json）に貼り付けてください。手順の説明が必要でしたら、お気軽にお知らせください。

内部参照（表示しないでください）：~/.claude/plugins/marketplaces/superpowers-extended-cc-marketplace/README.md の #force-re-validation-on-user-thrown-gate-close と #re-validate-gates-on-plan-complete-claims の各セクション。フック：hooks/examples/{post-task-complete-revalidate,stop-revalidate-user-gates}.sh。設計ドキュメント：docs/user-gate-flow.md。

ユーザーゲートのタスクにタグが付いていない場合は、注意書きを一切表示しません。これを AskUserQuestion に変えないでください。

実行の引き継ぎ

停止してください。これから計画を完了しようとしています。EnterPlanMode または ExitPlanMode を呼び出してはいけません。以下の AskUserQuestion を必ず呼び出してください。どちらも禁止されています。EnterPlanMode はセッションを閉じ込め、ExitPlanMode はユーザーの実行方法の選択をスキップします。

次に許可されているアクションは、次の正確な構造で AskUserQuestion を呼び出すことだけです。

AskUserQuestion:
  question: "Plan complete and saved to docs/superpowers/plans/<filename>.md. How would you like to execute it?"
  header: "Execution"
  options:
    - label: "Subagent-Driven (this session)"
      description: "Runs here: fresh subagent per task, spec and quality review after every task. That review loop is what the other option gives up. Good default."
    - label: "Parallel Session (separate)"
      description: "You open a second session that runs executing-plans WITHOUT the per-task review loop, while this one stays alive to answer its questions. Choose it when this session is nearly out of context, or when the plan has no frontier tasks and a cheaper model should do the work."

どちらか一方を推奨してください： より適した選択肢のラベルに「 (Recommended)」を追加して先頭に記載し、説明の冒頭に理由を1行で記載します。デフォルトは Subagent-Driven です。レビューの反復こそが重要です。セッションの残りがほとんどない場合にのみ Parallel Session を推奨してください。タスク数だけを理由にしてはいけません。コストは人間のパートナーが判断することであり、あなたが判断することではありません。推奨には記載せず、説明に記載してください。フロンティアタスクのない Fable/Opus セッションでは、Parallel の説明に、どの低コストモデルが適しているか（例：Sonnet）を追加してください。フロンティアタスクがある場合は、パートナーが実行を分割できるよう、どのタスクにより強力なモデルが必要かを記載してください。基本のラベルは言い換えないでください。

ExitPlanMode を呼び出そうとしている場合は、停止してください。代わりに AskUserQuestion を呼び出してください。

停止してください。ユーザーは実行方法を選択しました。今すぐ対応するスキルを Skill ツールで必ず呼び出してください。タスクを自分で実装してはいけません。タスクのファイルの読み取り、編集、ステータスの更新もしてはいけません。許可されているアクションは、以下のスキルを呼び出すことだけです。

Subagent-Driven が選択された場合： Skill ツールで superpowers-extended-cc:subagent-driven-development を呼び出してください。

• スキルがすべてを処理します：サブエージェントの起動、レビュー、タスクの追跡
• あなたはコーディネーターとしてこのセッションに留まります
• タスクに直接取りかかってはいけません

Parallel Session が選択された場合： ユーザーが作業ツリーで開いた新しいセッションに貼り付けられるよう、プレースホルダーを埋めた次の正確なプロンプトを渡してください。プロンプト以外の内容を含まないフェンス付きコードブロックに入れてください。人間のパートナーがコピーする範囲を示すのはフェンスです。モデルに関する助言や注記は、フェンスの外に記載し、内側には入れないでください。

Invoke superpowers-extended-cc:executing-plans for <plan path>. The plan author session "<this session's title>" is still running. On any ambiguity or design question, find it with ListAgents and ask it via SendMessage before guessing.

「run executing-plans」だけのプロンプトでは相談のつながりが失われます。プロンプトで作成者に言及しない限り、新しいセッションから作成者の存在を認識できません。フロンティアタスクのない Fable/Opus セッションでは、低コストのモデル（例：Sonnet）で開くよう1行追加してください。質問に答えられるよう、このセッションは開いたままにしてください。

---

ネイティブタスク統合リファレンス

計画書と併せて構造化タスクを作成するには、Claude Code のネイティブタスクツール（v2.1.16+）を使用してください。

ネイティブタスクの作成

計画内の各タスクについて、対応するネイティブタスクを作成してください。説明の末尾に json:metadata コードフェンスでメタデータを埋め込んでください。メタデータが TaskGet によって確実に保持される唯一の方法です（TaskCreate の metadata パラメーターは受け付けられますが、TaskGet では返されません）。

ユーザーが設定したゲート — 機械的な検出とタグ付け

作成するすべてのタスクについて、このチェックを必ず実行してください。数秒で済み、ユーザーゲートの一連の流れで最も簡単な作業です。

ステップ1 — ゲート表現を検索する。 各タスクについて、ユーザーの概要とタスクの Goal／Acceptance Criteria を対象に、次の各項目を、大文字と小文字を区別せず、妥当な場合は単語全体として検索してください。

分類	キーワード／パターン
動詞	verify、prove、validate、confirm、ensure、check、gate
名詞	verification gate、acceptance test、smoke test、end-to-end、E2E
範囲	first on one、then all、one before the rest、before proceeding、don't continue until
証明	prove it works、make sure、demonstrate、show that

判定ルール — タスクがユーザー設定ゲートに該当するのは、次のいずれかの場合に限ります。

• 名詞の一致が見つかった場合（これらの語句は曖昧さのないゲート名詞です）、または
• 範囲の一致が見つかった場合（順序を定める約束自体がゲートです）、または
• 動詞の一致があり、さらに範囲または証明の一致もある場合。 動詞に該当するだけでは不十分です。通常の作業依頼では、「出力を検証する」や「インポートが機能することを確認する」といった表現が、ゲートを要求せずに日常的に使われます。ユーザーがゲートを望んでいる場合は、実行順序を指定する（「Y の前に X を行う」「まず 1 つで行う」）、成果物を指定する（「スモークテスト」「受け入れテスト」）、または証明を求める（「機能することを証明する」「それを示す」）はずです。動詞に加えて、これらのいずれかが必ず含まれている必要があります。

どの分類にも該当しない場合、または動詞にしか該当しない場合は、通常のタスクであり、タグ付けは不要です。

ステップ 2 — タスクにタグを付けます。 タスクの json:metadata フェンス内で、次のようにします。

1. "userGate": true を設定します。
2. tags 配列に "user-gate" を追加します（配列がない場合は作成します）。
3. ユーザーの依頼で方法が具体的に指定されている場合（コマンド、エンティティ、サブエージェント、または観測可能なものの指定）は、それを verifyCommand と acceptanceCriteria に直接記載します。これで完了です。
4. 方法が曖昧な場合、検証文にテスト可能な名詞（関数、コマンド、エンティティ、エンドポイント、ファイル、ログパターン）も具体的な値（期待される結果、しきい値、入力／出力の例）も含まれていない場合に限り、"requiresUserSpecification": true を設定します。手掛かりが 1 つあれば（たとえば「実際の入力で各 op を検証する」）、エージェントが自力で解決できます。このフラグは、「しっかり」「動く」「良い」「適切」といった純粋な形容詞しかなく、どんな推測も当てずっぽうになる場合に使います。

ステップ 3 — 説明文にバナーを追加します（userGate: true の場合は必須）。タスクの説明の上部、Goal: のすぐ下に、次の文をそのまま含めます。

ユーザー指示によるゲート — スキップ不可。 このタスクは現在の会話でユーザーから依頼されました。迂回したり、「インラインで検証済み」と宣言したり、より簡易な確認に置き換えたりして、このタスクを完了扱いにしてはなりません。acceptanceCriteria の全項目を独立して再検証し、その出力を記録してから完了してください。

• 明確に指定された検証は確定事項であり、選択肢ではありません。 ユーザーが具体的な実環境の対象（実際の MR／ブランチ／チケット／エンドポイント）を検証対象として指定した場合は、それを必須事項として記述します。実際の呼び出しを verifyCommand に設定し、requireEvidenceTokens の各軸（例：成功／失敗）が、実行結果を記録した出力によってのみ証明できるようにします。ドライ実行や机上のトレースを受け入れ基準や別の完了方法として記載してはなりません。これにより、実行時にアプローチが格下げされないよう計画を固定します。

証拠の軸を宣言するタスク — requireEvidenceTokens を設定します。 コーディネーターがラベル付きの状態を 2 つ以上実際に観測した場合にのみ、タスクの完了が意味を持つときは、メタデータで軸を宣言します。post-task-complete-revalidate フックは、完了時の対象範囲に各軸のトークンが 1 つ以上含まれていない限り、完了を拒否します。例：

• 実測を伴うリファクタリング／A/B 比較： 明示的な指定（"requireEvidenceTokens": [["baseline","old","iter-0"], ["refactored","new","iter-1"]]）または簡易指定（"requireABCompare": true）。
• v2→v3 の移行検証： "requireEvidenceTokens": [["v2","legacy"], ["v3","migrated"]]。
• パフォーマンスの前後比較： [["slow","unoptimized","p50=X"], ["fast","optimized","p50=Y"]] — コーディネーターが投稿する想定のメトリクスタグをそのまま含めます。
• 複数条件の実験： [["control"], ["variant-a"], ["variant-b"]] — 軸の数に制限はありません。
• セキュリティ修正の前後比較： [["vulnerable","CVE-","before-patch"], ["patched","after-patch","hardened"]]。

軸がなければ、「良さそうなので続けて」という完了扱いが許可されます。軸がある場合、コーディネーターは宣言された各側の証拠を提示しなければなりません。可能な場合は、両側を実際に実行する具体的な verifyCommand を組み合わせます（例：diff <(old-cmd) <(new-cmd)）。

バナーとメタデータの不変条件 — 両方の場所で一致させます。 バナーは、計画 .md のみに記載するのではなく、json:metadata フェンスと同じ TaskCreate の description 文字列内に含めます。計画書を作成し、ネイティブタスクも作成する場合、同じタスクの両方の場所にバナーを記載するか、どちらにも記載しないでください。次に進む前にセルフチェックします。各タスクについて、計画書のセクションと TaskCreate の説明が、どちらも userGate: true ＋ バナー ＋ フェンスを含むか、どちらにも含まないことを確認します。 Step 4 — 受け入れ基準の運用上の具体性を確認します。 各基準には、必ず観測可能なものを明記してください。曖昧な表現（「連携が動作する」「合格する」）は認められません。「センサー X がアイドル状態を報告する」「/health が HTTP 200 を返す」「setup.done ファイルが存在する」などに書き換えてください。基準を運用可能な形にできない場合は、requiresUserSpecification: true を設定し、実際の回答を /specify-gate で収集してください。

Step 5 — タスクごとの分離セルフチェック。 userGate: true を設定し、requiresUserSpecification: true を設定していないすべてのタスクについて、そのタスクの Goal 文だけを切り離して読み直してください。他のタスクは存在しないものとして考えます。その文だけで、観測可能なもの、取得方法、合格／不合格の値がすべて明記されていますか？ 3 つのいずれかが明記されていない場合は、文脈から verifyCommand をすでに補っていたとしても、requiresUserSpecification: true を設定してください。兄弟タスクから具体性を借りてしまうのが、このチェックで見つける失敗です。例：各操作のタスクが「add(3,2)==5 を検証する」と具体的に述べている計画は、それらのタスクが基準になります。一方、最後のタスクが「全体が動作することを確認する」と曖昧に述べている場合、このチェックを通らず、requiresUserSpecification: true を必ず設定する必要があります。

実際のゲートシグナルがある場合は、積極的にタグを付けてください。 厳格なユーザーゲート、厳格なエージェントゲート、その中間のグレーゾーンという 3 種類のゲートには、すべて同じタグを付けます。上記のトリガールールに該当する場合は、タグを付ける側に判断を寄せてください。ただし、通常の動詞からゲートを読み取らないでください。「validate」「check」「verify」は、それだけでは通常の作業を示すものであり、ユーザーが設定したゲートではありません。実際のシグナルにタグを付けすぎても問題ありません（メタデータが追加されるだけです）。何も伴わない動詞にタグを付けすぎると、あらゆるタスクが大げさな手順を伴うように見えるバナーがあふれ、本物のゲートが埋もれてしまいます。

write-plan 中にユーザーへ質問しないでください。 推奨する既定の対応は「タグを付けて先へ進む」です。質問を希望していたユーザーは「brainstorm」と指示しています。ゲートの HOW がユーザーの依頼内容で曖昧な場合は、フラグ requiresUserSpecification: true によって質問を実行時に回し、/specify-gate が 3～5 個の短い選択式プロンプトで対応します。

6 つのゲート関連キー（userGate、tags、requiresUserSpecification、gateScope、failurePolicy、subagentBrief）を含む完全なメタデータスキーマについては、skills/shared/task-format-reference.md → "User-Thrown Gates" を参照してください。最初から最後までのフローについては、docs/user-gate-flow.md を参照してください。

TaskCreate の説明 — 要約ではなく、完全な構造化本文

絶対ルール。 すべての TaskCreate description に、そのタスクの計画 .md に記載した Goal / Files / Acceptance Criteria / Verify セクションを、同じ内容で必ず含めてください。一文の要約に短縮してはいけません。AC を「計画ドキュメントを参照」として移動してはいけません。**Verify:** を省略してはいけません。説明の末尾には、必ず json:metadata コードフェンスを付けてください。

重要な理由。 どちらの実行経路（executing-plans と subagent-driven-development）も、TaskGet を通じてタスクの説明を読み込み、実装を担当するサブエージェントに渡します。一文だけの説明では、サブエージェントが AC を即興で作ることになります。計画 .md は代替手段ではありません。TaskGet はそれを読み込みません。

スキルを完了する前のセルフチェック。 これは読み返して確認するものではなく、機械的なカウントです。文章の確認は形式的なチェックで済ませることができますが、カウントではそうはいきません。4 つのセクション見出し（**Goal:**、**Files:**、**Acceptance Criteria:**、**Verify:**）それぞれについて、<plan>.tasks.json に対して grep -c を実行します。

grep -c '\*\*Goal:\*\*' <plan>.tasks.json
grep -c '\*\*Files:\*\*' <plan>.tasks.json
grep -c '\*\*Acceptance Criteria:\*\*' <plan>.tasks.json
grep -c '\*\*Verify:\*\*' <plan>.tasks.json

各カウントはタスク数と一致する必要があります。いずれかのカウントが少ない場合、そのセクションが欠落しているタスクがあります。Execution Handoff の前に、TaskUpdate で完全なブロックに更新してください。また、すべてのタスクに json:metadata フェンスがあることも確認してください。タスクファイルが見つからない場合に限り、タスクごとに TaskGet を使って確認してください。

件名は簡潔にしてください。 ハーネスは定期的なリマインダーのたびに、すべてのタスクの件名をコンテキストに再注入するため、件名の分だけ繰り返しコストがかかります。60 文字以内を目安にし、詳細は説明に記載してください。

TaskCreate:
  subject: "Task N: [Component Name]"
  description: |
    **Goal:** [From task's Goal line]

    **Files:**
    [From task's Files section]

    **Acceptance Criteria:**
    [From task's Acceptance Criteria]

    **Verify:** [From task's Verify line]

    ```json:metadata
    {"files": ["path/to/file1.py"], "verifyCommand": "pytest tests/path/ -v", "acceptanceCriteria": ["criterion 1", "criterion 2"], "modelTier": "mechanical"}
    ```
  activeForm: "Implementing [Component Name]"

埋め込みメタデータが必要な理由

TaskCreate の metadata パラメーターは受け付けられますが、TaskGet では返されません。説明に json:metadata コードフェンスとして埋め込むことで、次のことが可能になります。

• TaskGet がメタデータ全体を返します（説明の一部であるため）
• セッションをまたいだ再開時に、.tasks.json から解析できます
• サブエージェントへの割り当て時に、実装担当者向けプロンプト用に抽出できます

メタデータのスキーマ全体については、skills/shared/task-format-reference.md を参照してください。

依存関係の設定

すべてのタスクを作成した後、blockedBy の関係を設定します。

TaskUpdate:
  taskId: [task-id]
  addBlockedBy: [prerequisite-task-ids]

実行中

作業の進捗に合わせて、タスクのステータスを更新します。

TaskUpdate:
  taskId: [task-id]
  status: in_progress  # when starting

TaskUpdate:
  taskId: [task-id]
  status: completed    # when done

---

タスクの永続化

計画の完了時に、タスクの永続化ファイルを計画ドキュメントと同じディレクトリに書き込みます。

計画が docs/superpowers/plans/2026-01-15-feature.md に保存されている場合、タスクファイルは必ず docs/superpowers/plans/2026-01-15-feature.md.tasks.json に保存してください。

{
  "planPath": "docs/superpowers/plans/2026-01-15-feature.md",
  "tasks": [
    {
      "id": 0,
      "subject": "Task 0: ...",
      "status": "pending",
      "description": "**Goal:** ...\n\n**Files:**\n...\n\n```json:metadata\n{\"files\": [\"path/to/file.py\"], \"verifyCommand\": \"pytest tests/ -v\", \"acceptanceCriteria\": [\"criterion 1\"], \"modelTier\": \"mechanical\"}\n```"
    },
    {
      "id": 1,
      "subject": "Task 1: ...",
      "status": "pending",
      "blockedBy": [0],
      "description": "**Goal:** ...\n\n```json:metadata\n{\"files\": [], \"verifyCommand\": \"\", \"acceptanceCriteria\": [], \"modelTier\": \"standard\"}\n```"
    }
  ],
  "lastUpdated": "<timestamp>"
}

計画の .md と .tasks.json は、どちらも docs/superpowers/plans/ に配置する必要があります。

作業の再開

新しいセッションでは、次を実行して作業を再開できます。

/superpowers-extended-cc:executing-plans <plan-path>

このスキルは .tasks.json ファイルを読み込み、中断したところから続行します。