spec-loop-plan-task

実行前の計画形式の選択とタスク計画には、このスキルを使用してください。

現在のセッションのコンテキストにすでに読み込まれている場合を除き、このファイルを最後まで読んでください。AGENTS.md がある場合は、そこに記載されたプロジェクトの指示に従ってください。

これらのルールがすでにコンテキストに含まれている場合は、要点を短くまとめて保持し、その要点が見当たらない場合、またはユーザーがルールの変更を伝えた場合にのみ読み直してください。

基本ルール

• 作業は PLAN から開始します。
• PLAN では計画用の成果物のみ変更できます。
• Spec Loop タスクとは、計画済みで、承認を経て実施され、レビュー可能な作業単位です。
• 非自明な実装作業にはタスクが必要です。
• 調査作業でタスクが必要なのは、明示的な計画、個別の追跡、またはレビュー可能な成果物が必要な場合に限ります。
• EXECUTION を開始するには、ユーザーの明示的な承認が必要です。implement、investigate、go ahead、proceed、apply などの指示は、現在のタスクが実行可能な状態にあり、指示が明確にそのタスクを指している場合に限り、承認として扱います。実行可能な状態か、指示の対象が不明確な場合は、確認してください。
• このルールを上書きできるのはユーザーのみです。

AGENTS.md がこれらのルールと矛盾する場合は、作業を停止してユーザーに確認してください。 アシスタントが停止または一時中断する場合は、その理由を説明してください。

ユーザーが計画形式、計画手順、またはセクション分けされたタスク形式を明示的に求めた場合、ユーザーが明示的に同意しない限り、簡略化しないでください。

実装作業の実行が承認されたら、spec-loop-implementation-flow/SKILL.md に従ってください。 調査作業の実行が承認されたら、承認された調査のみを行ってください。最終成果は、タスクファイルの場合は Findings に、チャットのみのタスクの場合は Scope に記録してください。必要な Test specification の確認をすべて完了し、選択した形式のルールに従って、タスクまたはサブタスクを review に提示するか、移動してください。

最初の分類

各作業項目を、次のいずれかに分類してください。

• 単独のドキュメント作業
• 軽微な実装作業
• 非自明な実装作業
• 調査作業

範囲を独立したものとする場合は、カバレッジの追加や拡張に特化したテストタスクを認めます。

次のいずれかに該当する場合、実装作業を非自明なものとして扱ってください。

• 複数ファイルにまたがり、単純な機械的編集ではない
• 編集前に調査や検討が必要
• モジュール、パッケージ、プラグインにまたがる
• 公開 API または共有 API を変更する
• 機械的な編集を超える、対象を絞ったテスト設計や検証が必要
• 実装方法として複数の妥当な選択肢がある

調査作業とは、調査、試験的な検証、プロトタイプ、カタログ作成、概念実証、または同様の証拠収集であり、その成果が製品の変更ではなく、知見またはレビュー可能な成果物となる作業を指します。調査自体に明示的な計画、個別の追跡、またはレビュー可能な成果物が必要な場合に限り、タスクを作成してください。通常の計画調査は、現在のタスクまたはチャットの状態を維持したまま PLAN 内で行ってください。調査作業で、製品、テスト、ビルド、設定、実行時環境、またはそれらに付随するドキュメントを変更してはなりません。その範囲は実装作業として計画してください。

計画形式の選択

既定ではタスクファイルを使用します。より簡易な形式は、ルールを満たし、ユーザーの許可を得た場合に限り使用できます。

最初の分類を行った後、planning-form-selection-guidance.md を読み、従ってください。

ファイルベースの複数項目作業における現行項目優先の詳細計画

計画形式の選択で task file with subtasks または multiple task files / backlog items が選ばれた場合、まず、Scope、Motivation、および妥当な大まかな内訳の作成に必要な、作業全体に関する確認のみを行ってください。その後、spec-loop-plan-work-breakdown/SKILL.md を使用して、現在のタスク、またはサブタスクを使用している場合は現在のサブタスクと、後続のタスクまたはサブタスクの概要を特定してください。詳細な確認と計画は、現在のタスク、または現在のサブタスクと必要な共有コンテキストに対してのみ行ってください。

フェーズモデル

フェーズ：

• PLAN = タスクの調査、設計／仕様、テスト仕様、および調査計画。
• EXECUTION = 承認済みのタスク作業。実装作業の場合、実装変更と、それに伴う更新を指します。
• DONE = 検証および承認済み。

ルール：

• 作業はPLANで開始し、ユーザーが別途指示しない限り、各作業項目の後にPLANへ戻ります。
• PLAN中にコマンドを使用できるのは、計画成果物以外のリポジトリ内容を変更しない調査または検証に限られます。
• 動作、テスト、ビルドまたは設定、依存関係、パッケージング、ランタイムアセット、または関連ドキュメントに対する実装変更はすべてEXECUTIONに該当し、ユーザーからの明示的な指示が必要です。
• ユーザーが計画と実行の併用を許可しない限り、各フェーズは排他的です。

単独のドキュメント作業は、ユーザーまたはプロジェクトの指示に別段の定めがない限り、このフェーズモデルの対象外です。

必須の確認ゲート

タスクまたは現在のサブタスクの計画内容を作成または修正する前に、 spec-loop-clarify-task/SKILL.md にある、確認スキルで必須とされる判断スクリーニングを適用してください。 重要な未決事項の定義には、そのスキルを使用してください。

このゲートは先回りして適用し、ユーザーから確認を求められるまで待たないでください。

ファイルベースの複数項目作業では、このゲートを2回適用してください。

• 大まかな分解の前には、作業全体のスコープ、動機、計画形式の選択、およびタスクやサブタスクの境界、順序、リリース可能性、一貫性に限って適用します。
• 現在のタスクを特定した後、またはサブタスクベースの作業では現在のサブタスクを特定した後、実装可能な設計やテスト仕様を作成する前に、現在のタスク全体、または必要な共有コンテキストを含む現在のサブタスクに対して、このゲートを完全に適用します。

サブタスクでは、現在のサブタスクと必要なタスクレベルのコンテキストにのみ、このゲートを適用してください。今後のサブタスクは、現在の対象となった時点で適用します。

確認の結果、ADR作業または個別の調査作業が必要な未解決のブロッカーが見つかった場合は、ブロックされたタスク計画を続ける前に、その作業へ差し戻してください。

後の作成作業で重要な未決事項が明らかになった場合は、作業を中断し、続行する前に確認してください。

計画内容

選択した形式のタスク形式を使用してください。スコープ、最終決定事項、調査、制約、設計、レビュー時の期待事項、および検証を記載してください。これは実装タスクと調査タスクの両方に適用されます。

common-task-guidance.md にある共通タスクガイダンスを使用してください。

Test specificationを作成または修正する前に、テストに関するガイダンスとして spec-loop-write-readable-tests/SKILL.md に従ってください。

計画形式ごとの取り扱い

チャットのみ

この計画形式を使用する場合：

• chat-only-path-guidance.mdを最後まで読みます。
• common-task-guidance.mdと併せて従います。

永続的な状態をチャットだけで安全に保持できなくなった場合は、続行する前にタスクファイル計画形式へ切り替えてください。

タスクファイル

この計画形式を使用する場合：

• task-file-path-guidance.mdを最後まで読みます。
• common-task-guidance.mdと併せて使用します。
• EXECUTIONの開始前に、アクティブなタスクファイルを作成または更新します。
• プロジェクトの指示で別のディレクトリが定められていない場合、デフォルトのタスクディレクトリとしてtasks/を使用します。

task file with subtasksまたはmultiple task files / backlog itemsの場合は、上記のルールを適用してください。つまり、サブタスクを使用する場合は、現在のタスクのみ、または必要な共有コンテキストを含む現在のサブタスクのみを完全に計画します。

タスクファイル作業の実行承認を求める前に、 spec-loop-prepare-execution-approval/SKILL.md を使用してください。

ADR のルーティング

ADR のみを扱う作業では、ADR の配置場所、命名、構成、更新ルールについて spec-loop-write-adr/SKILL.md を使用してください。

タスクの計画または承認済みの調査結果から、持続的なアーキテクチャ上またはポリシー上の決定が必要だと分かった場合は、 spec-loop-write-adr/SKILL.md を通じて ADR 作業を進めてください。 ADR 作業を明確化の中に隠さないでください。

ADR 作業がより大きな実装変更の一部である場合は、そのタスク内で実施し、 EXECUTION 中に spec-loop-write-adr/SKILL.md を使用してください。

更新され続けるプロジェクト文書

更新され続けるプロジェクト文書は、仕様、API コントラクト、アーキテクチャ文書や運用文書、 プロジェクト用語集、現行の ADR など、プロジェクトの最新の事実を保持します。履歴文書、アーカイブ文書、一時的な文書は含まれません。

Spec Loop は、プロジェクトに更新され続けるプロジェクト文書があることを必須としていません。 存在しない場合は、このポリシーを満たすことだけを目的として文書や Living Project Documents リストを作成しないでください。

プロジェクトリスト

更新され続けるプロジェクト文書が複数あるプロジェクトでは、入口として Living Project Documents というリストを 1 つ用意してください。

• 読み込まれたプロジェクト指示ファイルに既存のリストがあればそれを使用し、なければ ルートの README.md を使用します。
• 各項目で、パス、役割、対象範囲を示し、個々の文書または文書群を特定できるようにします。
• リストを含むファイル自体は暗黙的に含まれるものとして扱います。
• リストが複数ある場合は、どれを使用するか確認します。

関連する Research の出発点としてこのリストを使用してください。現在の作業で、リストにない更新され続ける文書が指定されている、または依存している場合は、その扱いを確認してください。更新され続ける文書が複数あるのにリストがない場合は、ルートの README.md に既定のリストを作成する前に User に確認してください。

プロジェクト用語集は、更新され続けるプロジェクト文書です。リストがない場合でも、 glossary.adoc と glossary.md を検索してください。他の更新され続ける文書を含むリストから既存の用語集が漏れている場合は、その扱いを確認してください。用語集が唯一の更新され続ける文書である場合は、リストを必須とせず、それを使用し、影響がある場合は更新してください。

更新され続けるプロジェクト文書への対応だけを理由に、タスクが必要になることはありません。必要な対応は、実装と同じインクリメントに含めてください。タスクベースの作業では、確認事項を Research（チャットのみの作業では Scope）に記録し、対応を Design に列挙します。taskless の実装または単独の文書作業では、対応をまとめて実施し、各対応とその結果のファイルを最終回答に列挙するか、None affected と記載してください。タスクの内容については common-task-guidance.md を参照してください。

用語集ポリシー

glossary.adoc と glossary.md をプロジェクト用語集ファイルとして認識してください。 両方がある場合は、どちらが正規の用語集か確認してから、いずれかを更新してください。

Spec Loop の AsciiDoc 用語集には、 spec-loop-write-glossary/SKILL.md を使用してください。 その他の用語集形式については、プロジェクトの形式に従ってください。

既存のプロジェクト用語集は、個々のタスクやコードに優先する、ドメイン言語の共有情報源です。用語集がない場合は、プロジェクト用語集が作成されるまで、Research と既存のコードベースを使用してください。

プロジェクト用語集の有無によって、タスクまたはサブタスクにタスク Glossary が必要かどうかが決まるわけではありません。決まるのは、タスクの語彙とタスク用語集への追加分をどの共有情報源と照合するかだけです。

承認済みの作業によって共有ドメイン用語が変更、明確化、または実装される場合は、必要なタスク Glossary の内容を、タスクファイル内の独立したセクションまたはチャットのみの Scope に記録してください。既存のプロジェクト用語集に影響がある場合は、同じインクリメント内で更新を計画してください。プロジェクト用語集の作成、更新、または置き換えは、更新され続けるプロジェクト文書に関する作業です。User、プロジェクト指示、またはタスク計画によって承認された場合に限り、作成または置き換えを行ってください。

タスクまたはサブタスクで Scenario または Glossary が必要な場合は、 scenario-and-glossary-guidance.md を読み、指示に従ってください。タスク Glossary の内容は計画成果物です。プロジェクト用語集への対応は EXECUTION 中にのみ行います。

Related skills

Use spec-loop-setup-doc-rendering/SKILL.md for rendering setup.