executing-plans

計画の実行

概要

計画を読み込み、批判的にレビューし、チェックポイントを設けながらバッチ単位で実行し、検証して引き継ぎます。

開始時に次のように宣言します： "I'm using the executing-plans skill to implement this plan."

可能であれば、サブエージェント主導の開発を優先してください。 タスクごとにコンテキストを新しくし、段階的にレビューする（仕様、品質、セキュリティ関連タスクではセキュリティも対象）ことで、インライン実行よりも明確に良い結果が得られます。サブエージェントが利用できない場合、タスク同士の結びつきが強すぎて分離できない場合、または計画が小さく、ディスパッチのオーバーヘッドがメリットを上回る場合は、このスキルを使用してください。

鉄則

NO EXECUTION WITHOUT A CRITICAL REVIEW OF THE PLAN FIRST

欠陥のある計画を忠実に実行しても、欠陥のある実装を効率よく作るだけです。レビューは形式的な手続きではありません。悪い計画による損失を数時間ではなく数分に抑えられる唯一の機会です。

レビューせずに実行を始めてしまいましたか？ すぐに止めてレビューしてください。タスク9よりもタスク2の時点で確認するほうが低コストです。

チェックリスト

各項目のTODOを作成してください。

1. ワークスペースを確認する — ブランチまたはワークツリーが分離されており、クリーンなベースラインであること
2. 計画を読み込み、批判的にレビューする — 着手前に懸念を伝える
3. TODOリストを作成する — タスクごとに1項目
4. バッチ単位で実行する — 2～3個のタスクを実行したらチェックポイントを設ける
5. 各チェックポイントで検証する — 実際のコマンドを実行する
6. 最終検証を行う — 全テストスイートを実行し、計画の網羅性を確認する
7. 引き継ぐ — finishing-a-development-branch

ステップ1：ワークスペースを確認する

必須のサブスキル： 作業を始める前に using-git-worktrees を使用してください。

明示的な許可がない限り、main／masterで実装を始めてはいけません。 まず確認してください。

git branch --show-current
git status --porcelain    # must be clean before starting

作業ツリーが汚れていると、レビュー時に自分の変更と既存の変更を見分けられません。

ステップ2：計画を批判的にレビューする

コードを書く前に、計画全体を読んでください。次の点を確認します。

確認項目	危険信号
プレースホルダー	「TBD」、「エラーハンドリングを追加する」、「上記についてテストを書く」、「タスク3と同様」
型の一貫性	タスク3ではclearLayers()を使い、タスク7ではclearFullLayers()を使っている
未定義の参照	どのタスクでも定義されていない型や関数をタスクで使用している
ファイルパス	存在せず、どのタスクでも作成されないパス
検証	コマンドのない手順、または期待される出力が示されていないコマンド
順序	タスク5が、タスク8で作成するものに依存している
スコープ	独立した複数のサブシステムが含まれており、別々の計画にすべきである

問題が見つかった場合： 着手前に、すべての問題をまとめて伝えてください。計画を黙って修正したり、セッション中に一つずつ発見したりしてはいけません。

Reviewed the plan. Three issues before I start:

1. Task 4 calls `validateToken()` — no task defines it. Task 2 defines
   `verifyToken()`. Same function, or a gap?
2. Task 6 modifies `src/auth/session.ts:40-58`; that file is 22 lines.
   The line range is stale.
3. Tasks 8-11 cover the notifications subsystem, independent of auth.
   Split into a second plan?

ステップ3：バッチ単位で実行する

2～3個のタスクを実行したらチェックポイントを設けます。バッチに分けることで、作業の勢いを保ちながら、9個のタスクにわたってエラーが積み重なるのを防げます。

各タスクでは、次の手順を実行します。

1. in_progressにする
2. 手順に正確に従う — 計画では粒度が意図的に定められています
3. 手順で指定された検証を実行し、出力を確認する
4. 計画の指示どおりにコミットする
5. completedにする

**「計画の手順に正確に従う」**とは、計画で指示されている場合は、まず失敗するテストを書き、実装前に実行して失敗することを確認するという意味です。「実行して失敗を確認する」手順を省略することは、計画の実行品質がいつの間にか低下する最も一般的な原因です。test-driven-developmentを参照してください。

コミットをまとめてはいけません。 タスクごとにコミットすることで、チェックポイントでレビューでき、ミスを元に戻せます。

ステップ4：チェックポイント

各バッチの後に状況を報告し、いったん停止してください。

Tasks 1-3 complete.

- Task 1: token verification — 6 tests, all passing
- Task 2: session store — 4 tests, all passing
- Task 3: middleware wiring — 3 tests, all passing

Full suite: 47 passed, 0 failed.
Deviation: Task 2 specified a Map; used a WeakMap so sessions are
garbage-collected with their request objects. Behavior is identical.

Continue with tasks 4-6?

チェックポイントでは、確信ではなく証拠を報告してください。「問題なく動作するはずです」ではなく、実際のコマンド出力を示します。verifying-before-completionを参照してください。

必要に応じて、各チェックポイントでレビュアーを割り当ててもかまいません。requesting-code-reviewを参照してください。バッチでセキュリティ関連のコードに触れた場合は、security-reviewerを割り当て、CriticalまたはHighの指摘をブロッカーとして扱ってください。

ステップ 5：逸脱への対処

計画は現実と向き合います。次に起きたことを分類してください。

状況	対応
ステップのコードにタイプミスや明らかな軽微な誤りがある	修正し、チェックポイントで報告します
ステップのアプローチは機能するが、より良い方法がある	計画に従います。代替案を記録します。独断で改善しないでください。
ステップが記載どおりには実行できない	中止します。理由を報告し、代替案を提案します。返答を待ちます。
コードベースについてのステップの前提が間違っている	中止します。計画を更新する必要があります。回避策で進めないでください。
タスクが不要だと判明した	中止して確認します。黙ってスキップしないでください
無関係なバグを発見した	記録します。修正しないでください。実行中のスコープクリープは、計画の意味を損ないます。

決して黙って逸脱しないでください。 どんなに小さくても、すべての逸脱を次のチェックポイントで報告します。

中止して確認するとき

次の場合は、ただちに中止してください。

• ブロッカーが発生した場合 — 依存関係の不足、環境の問題、ベースラインの失敗
• 指示が本当に不明確な場合
• 同じ検証に 2 回続けて失敗した場合
• コードベースについての計画の前提が間違っていると判明した場合
• ステップの実装に、計画で想定していないコードの再構成が必要な場合

推測せずに確認してください。 タスク 3 での誤った推測は、その後のすべてのタスクを損ないます。

検証が繰り返し失敗する場合： 中止して systematic-debugging を使用してください。修正を次々と試さないでください。3 回修正に失敗したなら、問題は考えている場所にはありません。

ステップ 6：最終検証

引き継ぐ前に、必須サブスキル： verifying-before-completion を使用してください。

• 計画のすべてのタスクにチェックが付いている
• このメッセージ内でテストスイート全体を実行し、出力を確認して、失敗が 0 件である
• リンターとビルドが問題なく実行される
• 計画の目標を読み直し、実装がそれを達成しているか確認する
• すべての逸脱をユーザーに報告している
• git status がクリーンで、すべての変更をコミットしている

計画の網羅性チェック： 計画の要件を順に確認し、それぞれを実装しているコードを示してください。テストスイートの合格が証明するのはテストの合格であり、計画の達成ではありません。

ステップ 7：引き継ぎ

必須サブスキル： finishing-a-development-branch を使用して、テストを検証し、マージ／PR／維持／破棄の選択肢を提示して、クリーンアップしてください。

よくある間違い

レビュー前に実行する。 計画の欠陥まで忠実に実装してしまいます。

「失敗を確認する」を省略する。 計画ではテストを実行して失敗を確認するよう指示しています。これを省略すると、そのテストが実際に何かを検証しているのか分かりません。

黙って逸脱する。 実装が計画からずれても、レビューまで誰も気づきません。

コミットを最後にまとめて行う。 元に戻せるチェックポイントがなく、レビューできない差分になります。

ブロッカーを無理に突破する。 そもそも間違っていたステップに対して、3 回も修正を重ねてしまいます。

「ついでに」変更する。 実行中に無関係なリファクタリングを行うと、差分をレビューできなくなり、逸脱が見えなくなります。

記憶を頼りに完了を宣言する。 「以前すべてのテストに合格した」は検証ではありません。今すぐ実行してください。

統合

必須のワークフロースキル：

• using-git-worktrees — 必須：開始前に分離されたワークスペースを用意します
• writing-plans — このスキルが実行する計画を作成します
• test-driven-development — テストファーストのステップを正しく実行する方法です
• verifying-before-completion — 必須：完了を宣言する前に使用します
• finishing-a-development-branch — 必須：すべてのタスクの後に開発を完了します

問題が起きた場合：

• systematic-debugging — 検証が繰り返し失敗する場合
• receiving-code-review — チェックポイントのレビューのフィードバックに対応する場合

代替案：

• subagent-driven-development — サブエージェントが利用可能な場合に推奨