executing-plans

計画の実行

概要

計画を読み込み、批判的にレビューし、タスクを複数のバッチに分けて実行し、バッチ間でレビューを受けるために報告します。

基本原則： アーキテクトによるレビューのチェックポイントを設けて、バッチ単位で実行します。

開始時に宣言： 「計画実行スキルを使用して、この計画を実装します。」

プロセス

ステップ 1：計画の読み込みとレビュー

1. 計画ファイルを最後まで読みます
2. 批判的にレビューします。手戻りのコストが膨らむ前に問題を見つける段階です。次の点を確認します。
   • 曖昧、または矛盾しているように見える手順
   • 不足している依存関係やセットアップ
   • 実際のコードベースでは成り立たない前提
   • 疑問のある技術的な選択
3. 懸念事項がある場合：作業を進める前にパートナーに伝えます。今の段階で認識を合わせておけば、誤った方向で何時間も作業する事態を防げます
4. 計画に問題がなければ、TODO トラッカーを作成し、ステップ 2 に進みます

ステップ 2：バッチの実行

デフォルト：1 バッチにつき最初の 3 タスク

チェックポイント方式（3 タスクを実行し、フィードバックを受けてから続行）なら、パートナーが進捗を把握でき、誤った土台の上に作業を積み重ねるのを防げます。

バッチ内の各タスクについて：

1. トラッカーでステータスを in_progress にします
2. 計画の手順を正確に実行します。手順は小さく、検証可能な単位になるよう作成されています
3. 完了としてマークする前に、指定された検証を実行します。早い段階でミスを見つけられます
4. 検証に失敗した場合：停止して報告し、指示を待ちます
5. 検証に合格した場合：完了としてマークし、次のタスクに進みます

作業の範囲を絞りましょう。3 タスクを丁寧に実行してフィードバックを受ける方が、10 タスクを何も確認せずに実行し、途中で方向を誤っていたと気づくよりも効率的です。

ステップ 3：報告

バッチが完了したら、次の内容を明確に報告します。

• 実装した内容（変更点、新規ファイル、変更したコード）
• 検証結果（テスト結果、エラーメッセージがあればその内容）
• 想定外の発見や、計画からの軽微な逸脱の概要
• 最後に「フィードバックをお待ちしています。」と記載します

報告のために一時停止することは重要です。追加作業に取りかかる前に、パートナーが軌道修正できる機会になります。

ステップ 4：続行

パートナーから返答があります。次のような対応が考えられます。

• 承認して続行を依頼する（次のバッチを実行）
• 問題を指摘して変更を依頼する（ステップ 1 またはステップ 2 に戻る）
• 新しい情報に基づいて計画を変更する（ステップ 1 に戻る）

指示に従います。このサイクル（実行 → 報告 → フィードバック → 続行）によって、計画から逸脱するのを防げます。

すべてのバッチを完了し、パートナーの承認を得たら、ステップ 5（開発の完了）に進みます。

ステップ 5：開発の完了

すべてのタスクを完了して検証したら、ブランチを仕上げます。すべてのテストが成功することを確認し、作業ツリーがクリーンであることを確認したうえで、ユーザーに次の選択肢を提示します。main にマージする、PR を作成する、または追加レビューのためブランチを保持する、のいずれかです。

• 最後にテストスイート全体を実行します
• 未追跡または未コミットの変更が残っていないことを確認します
• ユーザーに、今すぐマージするか、PR を作成するか、手動レビューに回すかを尋ねます

停止して支援を求めるタイミング

次の場合は、確認のために実行を一時停止します。

• バッチの途中でブロッカーに直面した場合（依存関係の不足、テストの失敗、指示が不明確など）。何も確認せずに続行すると、労力が無駄になります
• 計画に重大な抜けがあり、開始できない場合。計画にないことは実行できません
• 指示を理解できない場合。推測するより尋ねる方が効率的です
• 検証が繰り返し失敗する場合。計画の前提に問題がある可能性を示しています

これが重要な理由： 早めに停止すれば、無駄な作業を防ぎ、パートナーから適切な指示を受けられます。誤った土台の上に作業を進めるより、一時停止して確認する方が効率的です。

前のステップに戻るタイミング

レビューに戻る（ステップ 1）場合：

• フィードバックに基づいてパートナーが計画を更新した場合。以前のレビューはもう有効ではありません
• 根本的なアプローチを見直す必要がある場合。新しい情報によって戦略が変わります

ブロッカーを無理に突破すると、技術的負債が生じます。 後から間違いを修正するより、一時停止して再検討する方が効率的です。

覚えておくこと

• まず計画を批判的に確認します
• 計画の手順に正確に従います
• 検証を省略しません
• 計画で指定されている場合は、スキルを参照します
• バッチの合間は、報告して返答を待ちます
• 行き詰まったら推測せず、作業を止めます
• ユーザーの明示的な同意なしに、main/master ブランチで実装を始めてはいけません

よくある落とし穴

エージェントが確認を省略し、すぐに実行を始めてしまう

問題： ステップ 1（計画の読み込みと確認）を行わず、ステップ 2（バッチの実行）に飛びついてしまいます。これでは、無駄な作業が発生する前に計画の不備を見つける機会を逃します。

原因： 読むより実行するほうが生産的に感じられ、「とにかく始めよう」という衝動が強いためです。

防止策： 計画を読み、疑問点を書き出し、最初のタスクを in_progress にする前に疑問を提示します。やり直しを防ぐうえで、確認のステップは最も効果が高いタイミングです。

バッチサイズが大きすぎて混乱する

問題： 1 つのバッチで 10 件以上のタスクを実行しようとすると、完了したこと、ブロックされていること、検証に失敗した箇所を追跡しにくくなります。チェックポイントのメリットも失われます。

原因： 急いで進めたい気持ちや、「デフォルト：最初の 3 件」を最低数だと誤解していることが原因です。

防止策： 計画に別途指示がない限り、1 バッチ 3 件にします。報告してフィードバックを受けた後であれば、バッチを大きくすべきか判断できます。バッチを小さくすれば、報告が明確になり、フィードバックのサイクルも速くなります。

検証の失敗を無視する

問題： 検証に失敗している（テストが通らない、出力が期待と一致しない）のに、タスクを完了扱いにして先へ進んでしまいます。この問題は積み重なり、後続のタスクにも影響します。

原因： 「完了」として先へ進みたい誘惑があるためです。検証が任意の仕上げのように感じられることがあります。

防止策： 検証に失敗したタスクは未完了です。バッチを止め、失敗を報告して、指示を待ちます。計画に不備があるか、手順を誤解している可能性があります。パートナーに状況を知らせる必要があります。

実行中に計画が古くなる

問題： 実行の途中で、パートナーが計画の更新が必要だと気づきます（範囲の変更、技術選定の誤り、新たな障害の発見など）。それでも、古い計画に従って実行を続けてしまいます。

原因： 目の前のタスクに集中していて、計画が更新されたことに気づかないためです。

防止策： 各バッチの報告後は、パートナーの返答を注意深く読みます。計画の変更に言及している場合は、途中まで進んでいてもステップ 1（確認）に戻ります。勢いよりも、最新の状況を把握することが大切です。

連携

関連するワークフロースキル：

• writing-plans — このスキルが実行する計画を作成します。このスキルは、構成の整った計画があることを前提としています。計画を作成する必要がある場合は、まずこのスキルを参照してください。
• brainstorming — writing-plans に引き継ぐ設計を作成します。ワークフロー全体を実行するには、brainstorming → writing-plans → executing-plans の順に進めます。

Git worktree のヒント： 計画を実行する前に、作業を main から隔離するため、独立した git worktree での実行を検討してください。

git worktree add ../feature-work -b feature/my-feature

これにより、main での事故を防ぎ、問題のある実験をきれいに破棄できます。