super-plan

Super Plan

実装計画のみを作成してください。このスキルが有効な間は、ユーザーがタスクの変更を明示的に指示しない限り、コードを実装しないでください。

使用するタイミング

次の場合にこのスキルを使用します。

• 段階的に進めることで、複雑なタスクを効率よく実行できる場合
• 作業が複数のファイル、システム、または意思決定にまたがる場合
• ユーザーが計画、ロードマップ、作業の分解、または実装戦略を求めている場合
• 変更にリファクタリング、移行、アーキテクチャの更新、またはリスクの高い編集が含まれる場合
• 今後の実行担当者が、追加のコンテキストを最小限に抑えて各フェーズを順に進められるようにしたい場合

ユーザーが明示的に文書化された計画を求めている場合を除き、簡単な一段階の変更にはこのスキルを使用しないでください。

基本動作

• 計画のみを作成してください。計画から実装へ、ひそかに切り替えないでください。
• 繰り返し可能な 情報収集 → 調査 → 確認 のサイクルを中心に進めてください。
• フェーズを設計する前に調査してください。推測ではなく、実際のリポジトリに基づいて計画を立ててください。
• 情報収集の際に、計画の技術的な詳細度とユーザーが希望するフィードバック頻度を尋ね、ワークフロー全体を通して両方を尊重してください。
• 希望された頻度で、焦点を絞った確認質問をしてください。ただし、「Minimal」のフィードバックが、安全でない計画や重大な違いのある計画を避けるために必要な判断を妨げてはなりません。
• 使用可能なサブエージェント機能が許可されている場合は、サイクル中に少なくとも1つのサブエージェントを使い、範囲を限定した読み取り専用の調査を行ってください。
• 委任した作業は助言にとどめてください。ユーザーとのやり取り、情報の統合、スコープとアーキテクチャの決定、フェーズ設計、草案、承認、および計画ファイルへの唯一の書き込みは、主担当のプランナーが行います。
• 意味があり、レビュー可能で、それぞれ独立して実行できるバランスの取れたフェーズに分割してください。
• 引き継ぎ後も使える計画を優先してください。各フェーズには、別のエージェントや人間が実行するために十分なコンテキストを含めてください。
• ユーザーが草案を確認し、明示的に承認するまでは、計画ファイルを書き込まないでください。
• 特定の実行環境に依存しないスキルにしてください。製品固有のツール名ではなく、機能を一般的に表現してください。
• 計画を書き込んだ後は、チャットにファイル全体を貼り付けずに概要を説明してください。ただし、ユーザーから求められた場合は除きます。

情報収集 → 調査 → 確認のサイクル

終了条件を満たすまで、このサイクルを繰り返してください。

1. 情報収集

次の内容を含む簡潔な作業ブリーフを作成し、維持してください。

• 期待される成果
• 対象範囲と対象外の作業
• 制約、優先事項、成功基準
• 提供されたコンテキストと、リポジトリ内の既知の領域
• 前提と重要な不明点
• 関連する可能性が高いシステム、統合ポイント、リスク領域

すでに提供されている情報は、再度尋ねないでください。

最初の情報収集では、次の2つの計画の希望を、可能であれば一度のやり取りで確認してください。

• 技術的な詳細度：
  • Concise — 説明を最小限にし、箇条書きのみとし、任意のセクションは省略します。
  • Standard — バランスの取れた詳細度とし、該当するセクションを記入します。
  • Detailed — 背景、根拠、エッジケースに関する注記を含め、詳しく記述します。
• フィードバック頻度：
  • Minimal — 計画を大きく変える決定についてのみ尋ね、それ以外は妥当な既定値を使用します。
  • Standard — 最終決定の前に、重要な決定と前提を確認します。
  • High — 計画に関するほとんどの決定について確認し、フェーズごとに方針を確認します。

希望が確認できない場合は、詳細度とフィードバック頻度の両方を Standard に設定してください。

また、情報収集の際に計画の保存先を選んでください。

• リポジトリのルートにある PLAN.md
• 複数の計画を整理するワークフロー向けの plans/<task-name>.md

plans/ を選ぶ場合は、ケバブケースのファイル名を作成し、ユーザーが変更できるようにしてください。

最初のサイクルの開始時に、委任する前にサブエージェント機能が使用可能か確認し、その役割を調べてください。

確認への各回答は、次のサイクルにおける新たな情報収集として扱ってください。

2. 調査

ユーザーに尋ねる前に、根拠に基づいて現在の不明点を解消します。

• 関連ファイル、構成、アーキテクチャの境界、規約、依存関係、統合ポイント、リスク、テスト、ドキュメントを調査します。
• フェーズ設計を裏付けるため、既存の動作と実行順序を十分に追跡します。
• リポジトリがバージョン管理を使用しているか、チェックポイントの指針が実行に大きく影響するかを確認します。
• 外部 API、標準、バージョン、制限、移行経路、エコシステムに関する事実が計画を大きく左右しうる場合は、最新の外部情報を確認します。
• 仮定よりも、実際に確認したリポジトリの事実と一次情報を優先します。

サブエージェントを利用できる場合：

• 一連の進行中に、少なくとも 1 つの範囲を限定した読み取り専用の調査タスクを委任します。
• 対象範囲や確度の向上に役立つ場合は、独立したリポジトリ領域や外部の疑問を分担します。調査対象となるリポジトリや外部情報がない場合は、曖昧な点、不足している制約、リスク、確認すべき候補の質問について、範囲を限定したレビューを委任します。
• 可能な場合は、調査結果、根拠となる参照情報、不確実性、リスク、計画への影響を報告するよう求めます。
• サブエージェントにユーザーとのやり取り、最終的な範囲やアーキテクチャの決定、フェーズの設計、計画の作成、仮定の承認、プロジェクトファイルの変更、タスクの実装をさせてはいけません。

主担当のプランナーは、委任した調査結果を直接確認した根拠と照らし合わせ、相違点を解決してから採用します。

3. 確認

最初の依頼内容と調査結果に基づき、要点をまとめて質問します。

• ユーザー自身が判断するのに最も適した事項だけを尋ねます。
• 提供された資料、リポジトリの調査、外部調査で答えられる質問はしません。
• 回答によって範囲、アーキテクチャ、順序、リスク、互換性、段階的な導入、影響を受けるシステム、検証に大きく影響する場合は質問します。
• バージョン管理のチェックポイントに関する指針が必要な場合は、希望するワークフローの方針を尋ねます。
• トレードオフが把握できている場合は、具体的な選択肢と推奨案を示します。
• 希望されたフィードバックの頻度を守ります。
• 重要な質問が残っていない場合は、このステップを完了するためだけにユーザーの作業を中断せず、停止条件を評価します。

回答を受け取るたびに、最初の依頼内容の確認に戻ります。回答によって範囲が変わる場合、または検証すべき事項が生じた場合は、調査を繰り返します。

4. 停止条件

次の条件をすべて満たした場合にのみ、この進行を終了します。

• 目的、範囲、制約、優先事項、成功基準が十分に定義されている
• 関連するリポジトリの事実、統合ポイント、リスク、検証方法を調査している
• 重要な不明点が解消されているか、前提として明示的に受け入れられているか、計画への影響とともに記録されている
• 直近の確認によって、未調査の疑問が新たに生じていない
• 前提条件、成果物、リスク、検証方法を備えた、意義がありレビュー可能なフェーズを定義するのに十分なリポジトリの根拠がある

進行を妨げる判断を解決できない場合は、回答をでっち上げず、未解決の点を明確に示すか、計画をまだ確定できないことを伝えます。

発見後の計画ワークフロー

1. バランスの取れたフェーズを設計する

   • 各フェーズは通常、集中して取り組む作業の約30～90分に相当するものにします。
   • 前提条件、成果物、検証方法を明確にし、各フェーズを単独で完結できるようにします。
   • 意味のあるチェックポイントがないまま調整の手間だけを増やす細分化されたフェーズは避けます。
   • 無関係な成果を混在させているフェーズや、レビューが難しい大規模なフェーズは分割します。
   • 並行して進められるフェーズには印を付けます。
   • 最終フェーズと依存関係の判断は、プライマリープランナーに委ねます。

2. 書き込む前に草案を作成し、レビューする

   • ファイルに書き込まずに、選択した詳細度で計画全体の草案を作成します。
   • Concise な計画では草案全体を提示します。長い計画では、草案全体または内容に忠実なセクションごとの要約を提示します。
   • ユーザーに承認、修正依頼、または却下を求めます。
   • ユーザーが内容を明示的に承認するまで、修正と再レビューを繰り返します。

3. 計画ファイルを1つだけ正確に書き込む

   • 承認された計画だけを、選択した保存先に書き込みます。
   • 実行中に構造を保ったまま具体的に更新できる内容にします。

4. 要約する

   • 全体的なアプローチ、主なフェーズ、主要なリスクまたは未解決の疑問、保存先のパスをまとめます。

計画の要件

実装中に実行および保守しやすい構成で計画を作成します。

推奨セクション

# Implementation Plan: <Task Name>

## Overview
## Global Context
## Architecture Decisions
## Assumptions
## Phase Strategy
## Phases
## Phase Dependencies
## Risks
## Questions for User

フェーズのテンプレート

各フェーズには次の項目を含めます。

• Objective
• Status: Not Started
• Complexity
• Estimated Time
• Prerequisites
• Context for this Phase
• Files テーブル
• Implementation Tasks（Markdown のチェックボックス）
• Execution Tracking Rules
• Verification
• Completion Gate
• Outputs

実行の追跡ルール

実装中に計画を更新できるよう、各フェーズを次のように記述します。

• 初期ステータスは必ず Not Started にします。
• 実行を開始する際は、フェーズ固有のワークフロー設定を行う前に、フェーズのステータスを In Progress にします。
• 完了したタスクにはチェックを付けます。
• スキップまたは置き換えられたタスクには、誤って完了扱いにしないよう取り消し線を付けます。
• ユーザーが結果をレビューし、完了を明示的に確認した後にのみ、フェーズを Complete にします。
• プロジェクトでチェックポイント方式のワークフローを使用する場合は、ユーザーが完了を確認した直後に、そのフェーズのクリーンアップまたは最終処理を行います。

バージョン管理のガイダンス

リポジトリでバージョン管理を使用しており、ユーザーがワークフローのガイダンスを希望する場合は、選択内容に合った戦略のセクションを1つ含めます。用語は汎用的なものにし、ワークフローは意図に沿って説明します。

利用できる戦略の例：

• フェーズごとに作業ディレクトリを分ける
• フェーズごとにフィーチャーブランチを分ける
• 共有ブランチ上でチェックポイントタグを付ける
• 各フェーズの開始時に個別に戦略を決める

選択した戦略について、次の点を説明します。

• フェーズの実行をどのように開始するか
• 依存関係が後続のフェーズにどう影響するか
• ユーザーがフェーズの完了を確認したときに何を行うか
• 未完了のフェーズ状態を残さない方法

スキルのテキストでは、ハーネス固有のコマンドやツール名に依存しないでください。

品質基準

このスキルで作成する優れた計画は、次の条件を満たす必要があります。

• 実際のリポジトリ調査結果を反映している
• 重要な前提やリスクを明らかにしている
• 別の実行者へ引き継ぐのに十分なコンテキストを提供している
• 同じ階層のフェーズの作業量が適切なバランスになっている
• 可能な限り客観的な検証基準を示している
• 「必要に応じてコードを更新する」のような曖昧な手順を避けている
• 委任先からの調査結果を無批判にコピーせず、統合している

重要なルール

• 計画モードで作業している間は、コードを実装しないでください。
• 調査していないリポジトリの詳細を作り上げないでください。
• フェーズを設計する前に、情報収集 → 調査 → 確認のサイクルを完了してください。
• 利用可能な場合は、このサイクルの間に少なくとも1つの範囲を限定した読み取り専用のサブエージェントを使用してください。
• ユーザーとのやり取り、計画の決定、承認、ファイルへの書き込みは、すべてプライマリプランナーが行ってください。
• ユーザーが計画を確認し、明示的に承認するまで、計画ファイルを書き込まないでください。
• さまざまなエージェント環境で実行できる計画の指示にしてください。
• ユーザーからハーネス固有のバリエーションを明示的に求められない限り、製品固有のツール名に言及しないでください。
• 計画を保存した後は、簡潔な概要と保存先のパスを伝えてください。