executing-plans

計画の実行

概要

このスキルは、承認済みの計画書を、規律あるバッチ単位の実行を通じて動作するコードへと変換します。各ステップは TDD で実装し、次へ進む前に検証し、チェックポイントでレビューします。計画から本番コードへ、一貫した品質ゲートを保ちながら移行するための構造的な枠組みを提供します。

開始時に次のように伝えます：「計画実行スキルを使用して、承認済みの計画を [plan path] に基づいて実装します。」

トリガー条件

• 承認済みの計画書があり、実装の準備ができている
• /execute コマンドが計画への参照とともに呼び出された
• 部分的に完了した計画の実行を再開する
• 計画承認後、計画スキルから移行する

---

フェーズ 1：計画を読む

目標： コードを書く前に、計画を十分に理解します。

1. 計画書を最初から最後まで読む
2. すべての実装ステップを特定して数える
3. ステップ間の依存関係を整理する（先に実施する必要があるものを確認する）
4. 曖昧な点や未解決の質問を記録する
5. 作業を進める前に、ユーザーに理解した内容を確認する

計画の理解度チェックリスト

確認項目	質問
目標の明確さ	計画の目標を一文で説明できますか？
ステップ数	実装ステップはいくつありますか？
依存関係	どのステップがどのステップに依存していますか？
曖昧な点	不明確なステップや仕様が不足しているステップはありますか？
検証	すべてのステップに検証方法がありますか？

停止 — 次の条件を満たすまでフェーズ 2 に進まないでください：

• 計画の目標を一文で説明できる
• すべての実装ステップを列挙できる
• 依存関係を整理できている
• 曖昧な点を記録し、ユーザーと確認して解決している
• ユーザーから進行の許可を得ている

---

フェーズ 2：タスクのバッチを作成する

目標： 計画を、小規模で実行可能なタスクのバッチに分割します。

バッチサイズの判断表

タスクの複雑さ	バッチサイズ	例
シンプル（設定、ボイラープレート）	最大 5 タスク	環境変数、インポート、型定義
標準（機能、ロジック）	3 タスク	エンドポイント、サービス、コンポーネント
複雑（統合、セキュリティ）	2 タスク	OAuth フロー、決済処理
重大（データ移行、認証）	1 タスク	データベースのマイグレーション、認証情報の取り扱い

タスク要件（STIC）

基準	説明
Specific（具体的）	実装する内容が明確に定義されている
Testable（テスト可能）	自動テストで検証できる
Independent（独立）	可能な範囲で、バッチ内の他のタスクとの結合が最小限である
Compact（簡潔）	集中して取り組めるセッション（2～5 分）で完了できる

タスクテンプレート

Task: [concise description]
Plan Step: [reference to plan section]
Files to Create/Modify: [list of exact file paths]
Acceptance Criteria:
  - [specific, testable criterion 1]
  - [specific, testable criterion 2]
Dependencies: [other tasks that must be done first, or "none"]
Verification: [exact command to run]

停止 — 次の条件を満たすまでフェーズ 3 に進まないでください：

• 現在のバッチのタスクを作成している
• 各タスクに明確な受け入れ基準がある
• 依存関係が満たされている（前のタスクが完了している）
• 依存関係の順にタスクを並べている（独立したタスクを先にする）

---

フェーズ 3：タスクを実行する

目標： TDD を用いて、タスクを一つずつ実行します。

タスクごとのワークフロー

1. ANNOUNCE which task you are starting
2. IMPLEMENT using test-driven-development skill:
   a. Write failing test (RED)
   b. Write minimal code to pass (GREEN)
   c. Refactor (REFACTOR)
   d. Repeat RED-GREEN-REFACTOR for each behavior
3. VERIFY using verification-before-completion skill:
   a. Run full test suite (not just new tests)
   b. Run lint, type-check, build as applicable
   c. Confirm all checks pass
4. MARK task as complete
5. PROCEED to next task

実行ルール

ルール	理由
タスクは一度に一つ	タスク 1 の検証が完了するまで、タスク 2 を開始しない
TDD を厳守する	失敗するテストなしに本番コードを書かない
計画から逸脱しない	計画の変更が必要な場合は停止し、ユーザーと相談する
検証を省略しない	完了とする前に、すべてのタスクで検証に合格する必要がある
進捗を報告する	各タスクの開始時と完了時に伝える

タスク結果の判断表

結果	対応	次のステップ
検証に合格	完了としてマーク	次のタスク
テスト失敗、明らかな修正方法あり	修正して再検証	同じタスク
テスト失敗、原因が不明	systematic-debugging を呼び出す	修正後、同じタスク
計画のステップが曖昧	作業を停止してユーザーに尋ねる	明確な指示を待つ
計画のステップが実行不可能	妨げとなる要因を報告	指示を待つ
想定外の依存関係が判明	報告して順序を変更	バッチを調整

停止 — 次のタスクに進む前に、以下を完了してください。

• 現在のタスクの受け入れ基準を満たしている
• すべてのテストに合格している（新規および既存）
• 完了前の検証を実行している
• タスクを完了としてマークしている

---

フェーズ 4：バッチのチェックポイント

目標： バッチ内のすべてのタスクを完了した後、チェックポイントで全体をレビューします。

チェックポイントの手順

1. テストスイート全体を実行します — 現在のバッチのテストだけでなく、すべてのテストを対象にします
2. すべての検証コマンドを実行します — lint、型チェック、ビルド、フォーマット
3. 実装内容をレビューします — 完了したタスクと結果を要約します
4. 計画に対する進捗を評価します — どこまで進んでいますか？
5. 実行中に発生した問題やリスクを特定します
6. ユーザーに報告し、指示を仰ぎます

チェックポイント報告テンプレート

BATCH CHECKPOINT
================
Batch: [N] of [estimated total]
Tasks Completed: [list]

Verification Results:
  Tests:      [X passed, Y failed, Z skipped]
  Build:      [pass/fail]
  Lint:       [pass/fail, N warnings]
  Type-check: [pass/fail]

Progress: [N of M plan steps complete] ([percentage]%)

Issues Encountered:
  - [issue 1 and how it was resolved]

Risks or Concerns:
  - [risk 1]

Next Batch Preview:
  - [task 1]
  - [task 2]
  - [task 3]

Awaiting direction: Continue with next batch / Adjust plan / Other?

停止 — 次のバッチに進む前に、以下を完了してください。

• テストスイート全体に合格している
• すべての検証コマンドに合格している
• チェックポイント報告をユーザーに提示している
• ユーザーが続行を承認している

---

フェーズ 5：続行、調整、または完了

目標： 各チェックポイントの後、ユーザーの指示に従って対応します。

指示の判断表

ユーザーの指示	対応	次のフェーズ
「続行」	次のバッチのタスクを作成	フェーズ 2
「計画を調整」	変更について話し合い、計画書を更新	フェーズ 2（更新された計画で）
「ここで停止」	進捗を要約し、残りの作業を記載	完了
「[ステップ] まで先に進む」	依存関係が満たされていることを確認してから進む	フェーズ 2（新しいステップから）
「戻って [タスク] をやり直す」	必要に応じて元に戻し、修正して再実行	フェーズ 3

ユーザーの明示的な承認なしに、次のバッチに進んではいけません。

---

重大な妨げへの対応

タスクの完了を妨げる問題に遭遇した場合、その場しのぎの回避策を講じてはいけません。作業を停止し、エスカレーションしてください。

妨げの分類

種類	例	対応
仕様が曖昧	計画のステップに複数の解釈がある	解釈を提示し、ユーザーに尋ねる
依存関係の欠如	必要な API またはライブラリが利用できない	代替案とともに報告する
矛盾	ステップが計画の別の部分と矛盾している	両方を特定し、ユーザーに尋ねる
セキュリティ上の懸念	計画されたアプローチに脆弱性がある	リスクを報告し、より安全な代替案を提案する
実現可能性	記載された方法ではステップを実装できない	理由を説明し、代替案を提案する

妨げの報告形式

CRITICAL BLOCKER
================
Task: [which task is blocked]
Blocker: [clear description of the problem]
Impact: [what cannot proceed until this is resolved]
Options:
  A. [option with tradeoffs]
  B. [option with tradeoffs]
  C. [skip this step and continue]

Awaiting direction before proceeding.

ユーザーの意図を推測してはいけません。承認なしに回避策を実装してはいけません。妨げとなっているタスクを黙って飛ばしてはいけません。明確なトレードオフとともに選択肢を提示してください。可能であれば、妨げのないタスクは続行してください（ただし、スキップしたタスクを明記してください）。

---

サブエージェントへの割り当て

大規模な計画では、個々のタスクをサブエージェントに割り当てて並行実行できます。

サブエージェントへの割り当てを提案する場合

条件	基準
計画内の独立したタスク	依存関係が少ないタスクが 10 件以上
タスク仕様の品質	各タスクに明確な受け入れ基準がある
速度要件	ユーザーが緊急性を示している
タスク間の依存関係	結合度が低い

条件を満たす場合は、残りの作業について subagent-driven-development スキルへの切り替えを提案してください。

---

アンチパターン／よくある間違い

アンチパターン	失敗する理由	正しいアプローチ
計画全体を一度に実装する	チェックポイントも品質ゲートもありません	チェックポイントを設けたバッチ単位の実行
「簡単だから」と TDD を省略する	バグが蓄積し、リグレッションが発生します	例外なく、すべてのタスクで TDD を実施します
ブロッカーに気づかれないよう対処する	ユーザーが把握できず、誤った前提が組み込まれます	作業を止め、ブロッカーをエスカレーションします
バッチ後の承認を得ずに進める	方針が変更されている可能性があります	必ずチェックポイントを設け、返答を待ちます
計画から逸脱する	無許可の変更やスコープクリープにつながります	変更を実装する前に相談します
新しいテストだけを実行する	リグレッションを検出できません	チェックポイントでテストスイート全体を実行します
検証せずにタスクを完了扱いにする	進捗が実態と異なり、バグが蓄積します	検証は必須です
5 件を超えるタスクをバッチにまとめる	レビューが難しく、バッチごとのリスクが高すぎます	バッチは小さく保ちます
チェックポイントの報告を省略する	ユーザーが進捗を把握できなくなります	必ずチェックポイントの内容をすべて提示します
バッチの区切りでコミットしない	差分が巨大になり、元に戻すのが困難になります	各バッチの後にコミットします

---

自己正当化を防ぐガード

検証手順を省略してはいけません。ユーザーの承認を得ずにチェックポイントを越えて進めてはいけません。話し合いなしに承認済みの計画から逸脱してはいけません。

次のように考えていることに気づいたら：

• 「次に何をするか分かっているから、チェックポイントは省略しよう……」— いいえ。報告して返答を待ちます。
• 「この検証は重複している……」— それでも実行します。新しい根拠だけを使用します。
• 「計画はだいたい合っているから、進めながら調整しよう……」— まず調整について話し合います。

---

サブエージェントへの委任の機会

タスクのパターン	委任先	タイミング
共有状態のない独立した計画のステップ	Agent ツールを介した並列サブエージェント	依存関係の分析で、ステップ間にブロッカーがないと分かった場合
完了したステップのコードレビュー	code-reviewer エージェント	主要な計画ステップを完了した後
完了した機能のテスト実行	バックグラウンドの Bash タスク	作業の進行中でもテストを独立して実行できる場合

委任する際は、dispatching-parallel-agents スキルのプロトコルに従います。

---

統合ポイント

スキル	関係	タイミング
planning	上流 — 承認済みの計画書を提供します	計画がこのスキルへの入力になります
test-driven-development	タスクごと — すべてのコードタスクで TDD サイクルを実施します	フェーズ 3 の実行
verification-before-completion	タスクごと — 検証ゲートを設けます	タスクを完了扱いにする前
systematic-debugging	失敗時 — 予期しない失敗を調査します	タスクでエラーが発生した場合
code-review	チェックポイント — コードの品質をレビューします	フェーズ 4 のバッチレビュー
subagent-driven-development	代替 — 並列実行の経路です	独立したタスクが多数ある場合
resilient-execution	失敗時 — 別の方法を試して再実行します	タスクのアプローチが失敗した場合
task-management	補完 — タスクの追跡を提供します	併用できます

---

具体例

例：計画からバッチを作成する

計画：「JWT を使ったユーザー認証を追加する」

Batch 1 (3 tasks):
  Task 1: Write failing test for JWT token generation
    Files: tests/auth/jwt.test.ts
    Verification: npm test -- --grep "JWT generation" → FAIL (expected)

  Task 2: Implement JWT token generation
    Files: src/auth/jwt.ts
    Verification: npm test -- --grep "JWT generation" → PASS

  Task 3: Write failing test for auth middleware
    Files: tests/middleware/auth.test.ts
    Verification: npm test -- --grep "auth middleware" → FAIL (expected)

[CHECKPOINT after batch 1]

Batch 2 (3 tasks):
  Task 4: Implement auth middleware
  Task 5: Write failing test for login endpoint
  Task 6: Implement login endpoint

[CHECKPOINT after batch 2]

---

完了条件

次の条件を満たしたとき、計画の実行は完了です：

1. 計画のすべてのステップがタスクとして実装されている
2. すべてのタスクで検証に合格している
3. テストスイート全体が合格している
4. 最終チェックポイントの報告がユーザーに提示されている
5. ユーザーが計画の完了を確認している

---

スキルの種類

RIGID — このプロセスに厳密に従ってください。バッチ、チェックポイント、検証ゲートはすべて必須です。検証なしに完了したタスクはありません。ユーザーの承認なしに進むバッチもありません。