writing-plans

アクティベーションモードが明示的（`~/.config/aegis/config.toml` に `activation_mode = "explicit"` が設定されている場合、または環境内で `AEGIS_ACTIVATION_MODE=explicit` が確認できる場合）で、現在のユーザーリクエストに Aegis またはこのスキルの名前が明示的に含まれていない場合は、簡易パスに戻り、 このワークフローのチェックリスト、手順、文書要件を使わずに簡潔に回答してください。 ユーザーが Aegis またはこのスキルの名前を明示した場合は、通常どおり進めてください。

実行

→ 既存の親計画／仕様があり、小さな実行スライスですか？ → Planless Slice Lane を使用します。 → 永続的な境界（新しいオーナー、契約、スキーマ、公開 API、移行、互換性のある表面など）を伴わない、機械的または範囲が限定された変更ですか？ → 親文書なしで Planless Slice Lane を使用します。 → 新しい作業ストリームの承認済み仕様／要件、またはエスカレーションのトリガーがありますか？ → タスクの事前コンテキストがないエンジニア向けに実装計画を作成します。

永続的な計画を作成する場合は、スコープと受け入れ条件を確認し、現在のオーナー／ファイルを把握し、TDD の進め方を記録し、実行可能なタスクに分解し、検証と廃止を定義し、自己レビューして保存したうえで、実行ルートを選択してください。実際の認可または安全上の境界がユーザーへの確認を必要とする場合を除き、作業を進めてください。

タスクは、求められたユーザー成果（対象、アクション、条件、成果物）に結び付けてください。実装／テストだけでなく、ユーザーに見える接点での最終納品ステップと証拠を含めてください。未解決のニーズと依存関係を明示してください。プロジェクト全体の目標は、このリクエストの範囲外の作業を許可するものではありません。既存のスコープ／受け入れ条件の欄を再利用してください。追加の目標成果物は必要ありません。

新しいオーナー、契約、スキーマ、公開 API、アーキテクチャ境界、移行、永続化、セキュリティ／権限、配布／リリースの接点を追加する場合、または検証の境界が不明確な場合は、Planless Slice Lane からエスカレーションしてください。

計画の作成

このスキルは、承認済みの要件を、範囲が明確で実行可能な計画に変換します。計画では、何を変更するのか、なぜコードの変更が必要なのか、既存のどのオーナーとファイルを変更するのか、何との互換性を保つのか、結果をどう検証するのか、どのようなリスクが残るのか、古い経路を廃止するのか意図的に維持するのかを明らかにする必要があります。計画は手法パックのガイダンスであり、権威ある完了判定を与えるものではありません。

TDD ルートガード

タスクに分解する前に、モード（off | auto）、判断（strict | light | skipped）、権限の根拠、テスト方針、理由、検証を含む TDD Route を記録してください。

厳格な RED／GREEN ステップを含めてよいのは、ユーザー／プロジェクトから TDD を明示的に求められた場合、または TDD Route: strict の場合だけです。off では、明示的な strict の権限が優先されない限り、skipped を使用してください。計画が承認されていることやリスクラベルがあることだけでは、strict の権限にはなりません。

auto では、動作、バグ修正、共有／コア、契約、永続化、権限、移行、プロデューサー／コンシューマー、または意味のある回帰を示すシグナルがある場合は strict を選択してください。作業がごく小さく低リスクで、単一オーナーのみが対象であり、動作の変更も strict のシグナルもなく、明確で的を絞ったチェックがある場合に限り、light を選択してください。ユーザーから TDD の明示的な要求がないことは、light を選択する根拠にはなりません。auto の判断自体を記録する必要があります。

リスクが不明なままの場合は、タスクへの分解を始める前に、要件の確認、デバッグ、または計画のレビューに戻ってください。不確実性から TDD ルートを推測してはいけません。

明示された権限を伴う strict の判断だけが、失敗するテスト、RED、GREEN、REFACTOR の手順を規定できます。それ以外の場合は、最小限の変更に加え、診断のための再現、または変更後の回帰確認を計画してください。auto の判断が欠けている場合は、実装タスクに進む前にルートの選択に戻ってください。

エントリーと成果物の選択

開始時に明示します： 計画作成ルートでは、このスキルが実装計画を作成していることを伝えます。Planless Slice Lane では、代わりにそのレーンを伝え、計画を作成しているとは述べません。

実行コンテキスト： デフォルトでは現在のブランチ／ワークスペースを再利用します。独立した履歴が必要な場合はブランチを使用します。並行チェックアウトが必要な場合、無関係な未コミット変更が妨げになる場合、またはユーザー／リポジトリから明示的な権限が与えられている場合は、ワークツリーを使用します。

入力： 承認済み要件、Spec Brief、またはDesign Spec。

デフォルトの計画パス： docs/aegis/plans/YYYY-MM-DD-<feature-name>.md。計画はwork/に置きません。ユーザーおよびリポジトリからの指示がデフォルトに優先します。

例外：既存の親計画／仕様が現在の小規模な実行スライスをすでに管理している場合、または変更が機械的もしくは範囲の限定されたもので、親ドキュメントを必要としない場合は、Planless Slice Laneを使用します。新しい計画は保存しません。簡潔なSlice Cardを出力します：

Slice Card:
- Goal:
- Parent plan/spec:
- Files:
- Boundary:
- Verification:
- Stop:

親ドキュメントがない場合のParent plan/spec:は、none — direct bounded requestです。

Aegis プロジェクトワークスペース

ワークスペースの作成は遅延方式で行い、プロジェクトの指示に従います。Aegis Method Pack リポジトリは、稼働中のdocs/aegis/ワークスペースを作成または出荷してはなりません。永続的な計画のために別のプロジェクトのワークスペースを初期化または更新する必要がある場合は、expanded-planning-guidance.mdのワークスペースに関するセクションを確認してください。<aegis-workspace-helper>およびINDEX.mdのコマンドの詳細はそこに記載されていますが、計画を作成するかどうかの判断は含まれません。

デフォルトの計画形式

簡潔な出力要件：これらの項目は、カードを積み重ねるのではなく、自然な計画の内容として表現します：Aegis Visibility、承認済みのスコープと計画の根拠、必須のベースライン参照、ファイル／担当者、互換性の境界、Change Necessity、TDD の進め方、タスク、検証、リスク、廃止。以下の発動条件に該当しない限り、条件付きの構成は出力しません。

Aegis Visibilityは通常、担当者、契約、廃止、互換性、または検証に関するどの課題によって永続的な計画が有用になるのかを説明する1文です。構造化されたトレースは、監査、デバッグ、リリース、長期タスクのレビュー、または明示的な要望がある場合に限ります。

タスクに着手する前に、Requirement Ready Checkを実施します：承認済みの情報源、スコープ、シナリオ、受け入れの証拠を特定します。判断を左右する項目が不足している場合は、実装タスクを作成せず、要件／仕様の担当者に最小限の不足事項を返します。

重要なソースコード編集または新しいソースコードのパスを追加する前に、必ずChange Necessityを実施します。これはプロンプトではなく、振る舞いを基準に判断します。変更なし／ドキュメント／設定だけでは不十分な理由を自然に説明し、コード変更の最小境界を明示します。小さなヘルパー、ガード、分岐、フォールバック、アダプター、担当者も例外ではありません。no-change、docs/config-only、またはneeds-clarificationという結果になった場合は、コード計画を縮小するか、停止します。

変更が共有／コアの振る舞い、またはモジュール間の振る舞いに影響する場合、あるいは公開 API、スキーマ、契約、互換性、永続化、キャッシュ、エクスポート／読み戻し、フォールバック、アダプター、重複／レガシーの担当者、廃止経路、またはプロデューサーとコンシューマーの両方に影響する場合は、タスクに着手する前にRipple Signal Triageを実施します。該当するシグナルがなければ、何も出力しません。該当する場合は、正規の担当者と影響を受ける下流コンシューマーを特定し、真実のソース／契約／フォールバック／廃止に関するリスクを明示して、拡張した検証内容を該当タスクに含めます。必須となる担当者／公開契約／真実のソースの変更、2つの担当者の併存、またはフォールバック、アダプター、互換性分岐の追加が必要な場合は、設計に戻るか、実装前に明示的な合意を得る必要があります。

タスクを分解する前に、簡潔なPlan Pressure Testを実施します：担当者／契約／廃止との適合性、上位アーキテクチャの方針、検証範囲、タスクの実行可能性を確認します。その結果に応じて、続行、計画の修正、または設計への差し戻しを行います。このテストは承認権限を持ちません。

条件付き詳細ガイダンス

インターフェース／操作性に関する作業では、ui-ux-governance を組み合わせ、承認された体験基準と対応するチェック項目を、影響を受けるタスクに引き継ぎます。表示状態や復旧方法を変える API の変更を含めます。バックエンドのみの作業は対象範囲を限定してください。

expanded-planning-guidance.md のうち、トリガーに一致するセクションのみを読みます。

• 具体的なベースラインの確認に構造が必要な場合、または要件の準備状況が不十分／議論中の場合は、## Baseline And Requirement Detail。
• 新しいサーフェスや新しいオーナーについて、タスク分解前に Existence Check、AEGIS_MINIMALITY_REFERENCE、Architecture Integrity Lens、または first-principles-review の詳細が必要な場合は、## New-Surface And Architecture Detail。
• ファイルサイズ、複数オーナー、既存箇所への追加、アダプター、フォールバック、共有コアに関する重大な懸念がある場合は、## Complexity Detail。
• 長期実行、引き継ぎが多い、サブエージェント主導、またはアーキテクチャ／契約／互換性／廃止に関するリスクの高い引き継ぎでは、## Execution Readiness Detail。
• 保存にワークスペースの初期化または INDEX.md の更新が必要な場合に限り、## Workspace Save Detail。
• ルートの根拠に構造化された引き継ぎが必要な場合に限り、## Execution Route Detail。
• 独立したリスクの高いレビュー、または引き継ぎの多いレビューの場合に限り、## Expanded Plan Review。

直接のトリガーは、ベースラインの準備状況、新しいサーフェスまたは新しいオーナー、複雑性の懸念、ワークスペースへの保存、実行の引き継ぎを対象とします。この参照資料は詳細のみを提供します。このメインファイルが、ルーティング、Plan と Planless の選択、タスクのブロック、実行の引き継ぎを管理します。

新しいサーフェスでは、タスクに着手する前に Existence Check と docs/current/AEGIS_MINIMALITY_REFERENCE.md を使用します。既存のオーナーで十分な場合は、そのオーナーを再利用します。オーナー、契約、責任の重複、上位レベルでの簡素化、フォールバック、廃止にリスクが残る場合は、タスク分解の前に Architecture Integrity Lens と first-principles-review を使用します。

保守対象のソースでは、ファイルの構成、オーナーとの適合性、既存箇所への追加に伴うリスク、より適切な境界を確認します。懸念を示す兆候がなければ、コンパクトな編集箇所の判断で十分です。懸念がある場合は、拡張版の Plan-Time Complexity Check と Complexity Budget を読み込みます。予算超過の結果が出た場合は、タスクの境界を変更するか、ガバナンス作業を追加するか、後続対応のために停止する必要があります。

通常の中規模／大規模な引き継ぎでは、Intent Lock、Scope Fence、Baseline Lock、テスト、ドリフト時の停止を自然な形で明示します。上記の監査可能な引き継ぎトリガーに該当する場合に限り、拡張版の Execution Readiness View を読み込みます。どちらの形式も、GateDecision、PolicySnapshot、承認ゲート、完了権限ではありません。

計画で、古い内部パスの削除、実績のある外部互換性境界の維持、または永続状態の確認のための停止を選ぶ必要がある場合は、anti-entropy-governance を組み合わせます。これは破壊的な実行を許可するものではありません。

承認済みの ADR シグナルの保持、ソース参照、代替案、互換性、ベースライン同期に関する質問は完了まで保持します。未実行の計画から、承認済みアーキテクチャの記憶を作成してはいけません。

Planless Slice Lane

次のいずれかの開始条件に該当する場合は、計画の作成または保存の前に Planless Slice Lane を使用します。

• 親仕様または親計画がすでに作業ストリームを定義しており、現在の依頼が、その親に含まれる範囲の限定されたタスクを実行または調整するものである。
• 変更が機械的または範囲の限定されたものであり、親ドキュメントを必要としない（# Execute の親なし分岐）。

かつ、次の両方に該当する場合：

• 新しいオーナー、契約、スキーマ、パブリック API、アーキテクチャ境界、マイグレーション、永続化、セキュリティ／権限、配布／リリースのサーフェス、または不明瞭な検証境界がない。
• スライスを Slice Card で記述できる。

このレーンは、実行の記録を永続的な計画成果物にせずに、長期タスクの継続性を保ちます。親スコープまたは受け入れ条件との不一致がある場合は、マイクロプランを作成せず、親計画／仕様に戻ります。

計画とタスクの品質

タスクを作成する前にファイルを把握します。既存の所有関係と命名規則に従います。重要な計画では、CONTEXT-MAP.md または CONTEXT.md にある関連用語を受動的に使用します。実際の意味上の矛盾がある場合は、establishing-project-context に振り分けます。

永続的な計画はすべて、Goal、Architecture、Tech Stack、Baseline/Authority Refs、Compatibility Boundary、TDD Route、Verification から始めます。その後、正確なファイル、目的、必要最小限の変更、互換性への影響、タスクを実証するコマンドや結果を含む、小規模で順序付けられたタスクを定義します。シグネチャ、契約、または変換がほかの方法では曖昧なままになる場合に限り、コード抜粋を含めます。実装を計画内に重複して記載しないでください。

バグ修正、リファクタリング、契約変更、またはガバナンスの整理では、該当するタスク内で Repair Track と Retirement Track を明示します。古い所有者やフォールバックを維持する場合は、その理由と廃止のトリガーが必要です。

承認済みスコープの網羅性、プレースホルダー、所有者と型の一貫性、最小限の変更範囲、互換性、正確な検証、条件付きトリガーの処理、廃止について、1 回セルフレビューします。不備はその場で修正します。タスクは実行単位であり、Git 履歴の単位ではありません。コーディネーターは TaskStartSnapshot を取得し、タスク全体のレビューと最新の検証が完了した後にのみ、その範囲に限定したコミットを 1 つ作成します。

実行の引き継ぎ

実行ルートの決定はエージェントが担います。所有範囲が限定された真に独立したタスクで、連携するメリットがある場合に限り subagent-driven を選び、それ以外は inline を選びます。サブエージェントを利用できない場合は、インライン実行に切り替えます。ワークスペースがダーティであることだけを理由に、どちらかのルートを選ばないでください。

未解決の承認、プライバシー、有料リソース、外部アクション、取り消し不能なアクション、スコープ、受け入れ条件、またはワークスペースの所有権に関する境界についてのみ、ユーザーに確認します。それ以外の場合は、直ちに進めます。決定、根拠、フォールバック、および User confirmation required: no | yes — <boundary> を簡潔に示します。完全な Execution Route スキーマが役立つ場合に限り、参照を読み込みます。

subagent-driven の場合は、aegis:subagent-driven-development を使用します。inline の場合は、aegis:executing-plans を使用します。