brainstorming

有効化モードが明示的（`~/.config/aegis/config.toml` に `activation_mode = "explicit"` が設定されている、または環境内で `AEGIS_ACTIVATION_MODE=explicit` が確認できる）で、現在のユーザーリクエストが Aegis またはこのスキルを名前で明示的に呼び出していない場合は、高速パスに戻ります。このワークフローのチェックリスト、 儀式的な手順、ドキュメント要件を適用せず、簡潔に回答してください。ユーザーが Aegis またはこのスキルを明示的に指定した場合は、通常どおり進めてください。

実行

→ 直接的な追及、または計画・設計へのプレッシャーテストですか？ → 以下の Grilling Mode に入ります。意図が穏やかな異議申し立てですか？ → モードを一文で確認してください。インタビュー中は通常の設計成果物の作成、ドキュメントの執筆、タスク計画、実装を開始しないでください。 → 新機能、製品の動作、UI／コンポーネント設計、アーキテクチャ／契約の変更、または複雑さが中程度以上で曖昧な作業ですか？ → まず設計します。必要な設計／仕様が承認されるまで実装しないでください。

1. プロジェクトのコンテキストを調べる → 正式なドキュメントを読み、既存のパターンを確認する
2. 確認事項を一度に1つずつ尋ねる（選択式を優先）
3. トレードオフと推奨案を含め、2～3案を提示する
4. 設計の各セクションを提示する → セクションごとにユーザーの承認を得る
5. 仕様書を作成する → 自己レビューする → ユーザーにレビューしてもらう → writing-plans に移行する → 厳格なゲート：このスキルに該当するタスクでは、設計／仕様の承認を得るまで、コードの作成、プロジェクトのひな形作成、実装スキルの呼び出しを行わないでください。

ルートの例

これらの行は、実行時の正規表現ルーターではなく、手法の動作に関する調整基準です。エージェントは根拠に基づいてルートを選択します。ルート選択についてユーザーに質問しないでください。

シナリオ	ルート
アイデアがまだ固まっていないので、まず機能設計を整理したい	通常のブレインストーミング。まずは簡潔な出力
パブリック API の契約と互換性の境界について話し合う	通常のブレインストーミング。実装前に設計セクションを提示
この案を厳しく問いただして。こちらの意見にそのまま同調しないで	Grilling Mode
ログインボタンのヌルポインターを修正する	systematic-debugging
現在の PR／diff／コードをレビューする	requesting-code-review
目標を定めた計画を立てて	目標の意図が明確なら goal-framing、そうでなければ通常のブレインストーミング
ボタンの文言を「保存」から「送信」に変えて	高速パス。設計の儀式は不要

アイデアを設計にまとめるブレインストーミング

自然な協働的対話を通じて、アイデアを具体的な設計と仕様にまとめます。

まず現在のプロジェクトのコンテキストと正式な決定権の範囲を把握し、次に質問を一度に1つずつ行ってアイデアを具体化します。作るものが明確になったら、作業を安定させるための最小限の設計成果物を提示し、必要な承認を得ます。

成功とは、提供と意味のある失敗状態を含め、ユーザーが実際に使える成果を得ることです。実際の業務上／認可上の制約と、現在の実装上の制限を分けて考えます。未対応の操作は、満たされていないニーズとして扱います。スコープを広げることなく、サポート対象のシナリオ全体での信頼性とのバランスを取ります。変更のない決定については既存の承認を有効とし、設計または認可に影響する不足点だけを確認します。

このスキルに該当する作業では、このワークフローで必要な設計／仕様を提示し、ユーザーの承認を得るまで、実装スキルを呼び出したり、コードを書いたり、プロジェクトのひな形を作成したり、実装にあたる行動を取ったりしないでください。

Grilling Mode

モードの優先順位

Grilling Mode が有効な間は、通常のブレインストーミング実行フローに優先します。ユーザーがインタビューを終了するまで、Checklist、The Process、Compact output contract、およびすべてのドキュメント作成や設計からの移行要件を一時停止します。ただし、実装禁止の厳格なゲートは維持してください。

グリルモードに入る条件

• 明示的な依頼： ユーザーがアイデア、計画、設計について厳しく問いただすよう求める、または明示的にプレッシャーテストを依頼した場合です。明示的な表現には、grill me、grill this plan、审问我、盘问我、拷问我 などがあります。このモードにすぐ入ります。
• 間接的な依頼： ユーザーが草案のアイデア、計画、設計について前提に異議を唱える、欠点を探す、レッドチームを行う、または「别顺着我」と求めた場合です。質問は Grill or normal brainstorming? だけにします。確認を得てからこのモードに入ります。
• グリルではない場合： 単なる表現や文字列への言及、PR、差分、現行コードのレビューは該当しません。表現が文字どおり何を意味するかは通常どおり説明し、実装レビューは requesting-code-review に振り分けます。

開始カード

ユーザーがこのモードに入った後、ユーザーの言語でこれを一度だけ出力し、その後インタビューを始めます。

◆ Grilling Session
Target: <idea / plan / design>
Question path: value -> boundaries -> failure modes -> acceptance
Pace: deep (default) | fast (user-requested)

進め方

• じっくり進める場合： 決定に影響する、または前の回答に依存する質問を、各ターンでちょうど1つだけ尋ねます。回答を待つ前に、推奨する回答と最も関連性の高いトレードオフを示します。
• 手早く進める場合： ユーザーが手早く、またはまとめてインタビューするよう明示的に求めた場合に限ります（例：fast、batch、快问、一次问几个）。独立した決定事項を最大3つまで尋ねます。各質問について推奨案とトレードオフを示してから、ユーザーの回答を待ちます。依存関係のある追加質問では、じっくり進める方式に戻ります。

1. 質問する前に、コードベースと現行の権威あるドキュメントを調べ、事実を確認します。ローカルで確認できる事実をユーザーに尋ねてはいけません。
2. 決定権はユーザーにあります。推奨案、暫定的な回答、認識合わせの確認を最終承認として扱ってはいけません。
3. 一度だけ提示する開始カードを除き、各ターンでは観察事項、推奨案、および選択した進め方に沿った質問のみを提示します。インタビュー中に、設計の一連の手順をすべて示したり、ドキュメントを作成したり、計画を立てたり、実装したりしてはいけません。
4. ユーザーが中止、保留、または質問は十分だと伝えたら終了します。構造化された Challenge Result で再確認します。この要約によって完了の権限が与えられるわけではありません。

Challenge Result
- Survived assumptions
- Rejected assumptions
- New evidence needed
- Design changes required
- Residual risks
- Return state: interview | design | approaches | writing-plans

5. インタビュー後に進めるようユーザーが求めた場合は、通常のブレインストーミングにおける設計ゲートに戻ります。計画または実装に進むには、設計／仕様について引き続き必要な承認を得る必要があります。

別ルートへの振り分け／ドキュメント必要性ゲート

複雑さの低い作業にこのワークフローを無理に適用してはいけません。文言の小さな修正、単一の担当者が所有するバグ修正、単純な設定／状態に関する質問、ローカルユーティリティの変更、機械的な複数ファイル変更は、新しいドキュメントを作らずに、意図を簡潔に確認し、ベースラインを確認してから、TDD／デバッグと検証を進められます。仕様、計画、ADR、またはベースライン資料を書く前に、ドキュメント必要性ゲートを実行します。

1. 既存の仕様／計画／ADR／ベースラインで、この変更範囲はすでに扱われていますか？ -> 該当する場合は、所有者となるドキュメントをその場で更新します。兄弟ドキュメントを新たに作成してはいけません。
2. 変更範囲は、永続的／不可逆的（スキーマ、公開 API、所有者、依存関係の方向、移行、互換パスの廃止）、セッション間／担当者間の引き継ぎ、承認が必要、または権威ある情報源が必要なものですか？ -> はい：その変更範囲に必要な最小限の資料を書きます（Documentation を参照）。 -> いいえ：ドキュメントは書かず、簡潔な草案をセッション内にとどめます。
3. 編集時と終了時に再確認します。不確実性または影響が大きくなった場合は、安定化に必要な最小限の仕様へと段階を引き上げます。

ルートの優先順位

1. まず別ルートに振り分けるケースをこのワークフローから外します（systematic-debugging、requesting-code-review、目標の意図が明確な場合の goal-framing、即時対応の小規模タスク）。
2. Grilling Mode には、明示的な異議申し立ての意図が必要です。通常の議論、評価、理解の明確化はグリルに該当しません。
3. それ以外の場合は通常のブレインストーミングの流れで進め、根拠に基づいて掘り下げます。契約、所有者、永続化、移行、セキュリティ、利用者数、影響範囲を確認します。最初の依頼が大がかりに聞こえるというだけでなく、根拠が見つかってから段階を引き上げます。
4. ファイル数だけでは設計上の判断材料になりません。機械的な複数ファイル変更でも即時対応の対象になり得ます。また、1ファイルだけの契約変更でも全面的な設計が必要になる場合があります。

役割と権限に関する契約

エージェントが決める事項

以下はユーザーに尋ねず、直接決定します。

• リポジトリの調査戦略と証拠収集の順序
• 承認済みの担当範囲内でのファイルと関数の構成
• テストコマンドと、状況に応じた検証方法
• ポリシーで既に許可されている場合の、インライン実行とサブエージェント実行の選択
• 製品の動作、契約、権限、永続的な境界を変更しない、元に戻せる実装構成

ユーザーが決める事項

ユーザーに尋ねるのは、以下に限ります。

• 製品の動作や好み
• 元に戻せない、破壊的、外部公開、本番環境、または機微な影響
• ユーザーにしか決められない、製品や契約に関する明示的な確約
• リポジトリ、ツール、権限に関するドキュメントから得られない、必要な情報

ユーザーへの質問はすべて、次の基準を満たす必要があります。

ユーザーが別の回答を選んだ場合、どの設計上の境界、動作、担当者、 受け入れ基準、またはリスク判断が変わりますか？

何も変わらない場合は、質問しないでください。質問がこの基準を満たす場合は、 推奨する選択肢とその理由を添え、ユーザーが調査するのではなく、 提示された選択肢から決定できるようにします。この分類は、 どの決定をユーザーが行うかを明確にするものであり、このワークフローで 定められている承認ポイントをなくすものではありません。

チェックリスト

以下の各項目について、必ずタスクを作成し、順番に完了してください。

1. プロジェクトの背景を調査する — ファイル、ドキュメント、最近のコミット、権限に関するドキュメントを確認し、アクティブなモデリングを読み込まずに、関連するアクティブな CONTEXT.md の内容を受動的に把握する
2. 進め方と範囲を選ぶ — 実際の設計か、診断かを判断し、それに応じたワークフローに進むか、まず分解する
3. 確認の質問をする — 一度に一つずつ尋ね、目的、制約、成功基準を把握する
4. 作業用の成果物を作成する — TaskIntentDraft、BaselineReadSetHint、BaselineUsageDraft、ImpactStatementDraft
5. 新たな表面を追加する場合は存在確認を行う — アプローチによって新しい担当者、スキル、成果物、アダプター、フォールバック、ワークフローステップ、またはベンチマーク指標が追加される場合のみ
6. 2～3個のアプローチを提案する — トレードオフと推奨案を示す
7. 設計を提示する — 複雑さに応じたセクションで提示し、必要な場合はユーザーの承認を得る
8. 仕様の成果物を作成する — Doc Necessity Gateを通過し、既存の担当範囲の仕様書や計画書で対象がカバーされていない場合に限る。既存の文書でカバーされている場合は、別の文書を新規作成せず、その文書を更新する
9. 仕様を自己レビューする — プレースホルダー、矛盾、曖昧さ、範囲、境界を確認する
10. ユーザーが仕様書をレビューする — 先に進む前に、ユーザーにレビューを依頼する
11. 実装に移行する — writing-plansスキルを呼び出す（終端状態）

終端状態は、writing-plansを呼び出すことです。 ほかの実装スキルは呼び出さないでください。

プロセス

アイデアの把握：

• まず現在のプロジェクトの状態（ファイル、ドキュメント、最近のコミット）を確認する
• 詳細な質問をする前に、関連する権限に関するドキュメントを読む
• 質問、選択肢、シナリオ、仕様書では、既存の正式な用語を使う。 用語が明確になった場合、または用語間に矛盾がある場合は、 establishing-project-contextを構成する。解決内容を仕様書だけに残さない。
• 依頼が承認済みの計画に関する診断、根本原因の調査、またはフォローアップである場合は、適切なワークフローに進む
• 依頼が複数の独立したサブシステムにまたがる場合は、まずその点を指摘して分解する
• 確認の質問は一度に一つずつ行い、選択式を優先する
• 調査中は、事実、仮定、不明点を区別する

作業用成果物： 次の4つのドラフトを維持します。TaskIntentDraft（成果、目標、成功を示す証拠、中止条件、対象外事項、範囲、リスク）、 BaselineReadSetHint（候補となるドキュメント、権限に関する不足事項）、 BaselineUsageDraft（必須の参照情報、任意で提供されたコンテキスト参照情報、計画前に確認済みの参照情報、引用済みの参照情報、不足している参照情報、助言的な判断）、 ImpactStatementDraft（影響を受けるレイヤー、担当者、不変条件、互換性、対象外事項）。範囲が変わった場合は、内容を更新します。 コンパクトな出力形式： Aegis Visibility、TaskIntentDraft、BaselineReadSetHint、 BaselineUsageDraft、Requirement Ready Check、ImpactStatementDraft、 Existence Check、Product Risk Lens、Architecture Integrity Lens、 Prior-Art & Reuse Lens、Baseline Role Alignment、Plan-Time Complexity Check、Options、Decision Needed。完全な設計構造へ展開する前に、このコンパクトな形式を使用します。

このワークフローにおける Aegis Visibility では、設計／仕様の明確化が実装より先に必要な理由と、その抑制によって軽減される逸脱、過剰構築、担当の誤り、受け入れ基準の欠落のリスクを示します。自然でタスクに即した内容にし、定型的なスキルトレースにしないでください。

設計の方向性が特定のベースライン文書または最新の権威ある参照情報に依存する場合は、コンパクトな BaselineUsageDraft を使用します。

BaselineUsageDraft:
- Required baseline refs:
- Delivered context refs:
- Acknowledged before plan refs:
- Cited in design refs:
- Missing refs:
- Decision: continue | needs-baseline-readback | needs-verification | pause-for-user | blocked

Delivered context refs は、ホストが投影する任意の記録情報にすぎません。ホストがコンテキストのペイロードを注入したことや、モデルが内部でそれを利用したことを証明する権威ある根拠ではありません。この成果物は、設計の推奨または承認の前に、ベースライン／コンテキストへの注意が逸れるリスクを可視化するためのものです。

要件がすでに確認済みで完全でない場合、設計を推奨する前に、コンパクトな Requirement Ready Check を使用します。

Requirement Ready Check:
- Requirement source refs:
- Goals and scope refs:
- User / scenario refs:
- Requirement item refs:
- Acceptance / verification criteria refs:
- Open blocker questions:
- Decision: ready | needs-source | needs-goal-alignment | needs-scenario | needs-acceptance-criteria | needs-clarification | needs-user-decision | blocked

プロジェクトの権威ある情報源によって確認されるまでは、タスクの意図、会話、ソース文書、エージェントによる推論を、要件の候補となる情報源として扱います。判断が ready でない場合は、設計を提案／仕様の明確化の段階にとどめ、ギャップを実装タスクに変換しないでください。

Existence Check： 新しい担当者、スキル、成果物、ホストアダプター、フォールバック、互換性経路、ワークフローのステップ、ベンチマーク指標を追加するアプローチを推奨する前に、それが本当に必要か確認します。参照資料として docs/current/AEGIS_MINIMALITY_REFERENCE.md を使用します。既存の担当者や成果物を再利用する通常の機能設計に、この確認を無理に適用しないでください。

Existence Check:
- Proposed new surface:
- Existing owner / reuse candidate:
- Why existing surface is insufficient:
- Creation proof:
- Entropy / retirement impact:
- Decision: reuse-existing | add-with-proof | defer | reject | needs-first-principles-review

判断が reuse-existing の場合は、新しい仕組みではなく再利用する方法を推奨します。判断が add-with-proof の場合は、根拠、検証シグナル、該当する廃止条件を設計／仕様に含めます。

Product Risk Lens： 製品、機能、UI、ワークフロー、アーキテクチャに関する選択肢が曖昧な場合は、ペルソナになりきるのではなく、簡潔なレビュー観点を追加します。

Product Risk Lens:
- Value:
- Non-goals:
- Trade-offs:
- Decision needed:

これはレビュー観点であり、ペルソナとしての出力ではありません。ベースラインの根拠、承認済みの要件、最新の権威ある文書に優先するものではなく、実装前に製品リスクと判断点を可視化するためのものです。

Plan-Time Complexity Check： 中規模／大規模の作業で実装の方向性を選択する前に、関連する可能性の高い担当ファイルと現在の構造を確認します。これは設計上の負荷を確認するための助言であり、ゲートでも完了の権威でもありません。小規模でリスクの低い編集には無理に適用しないでください。

共通の成果物クラス、負荷シグナルの解釈、予算超過時の対応については、using-aegis/references/complexity-governance.md を使用します。

Complexity Budget:
- Artifact class:
- Target files / artifacts:
- Current pressure:
- Projected post-change pressure:
- Budget result: within-budget | at-risk | over-budget
- Planned governance:

Plan-Time Complexity Check:
- Better file boundary:
- Recommendation: edit-in-place | extract helper | add owner file | split task | defer refactor

アプローチの検討： トレードオフと推奨案を添えて、2～3つのアプローチを提案します。スコープの境界を明確にし、対象に含めるもの、先送りするもの、別の担当に属するものを示します。

アプローチを選択する前に、新しい仕組みの提案がある場合は Existence Check を使用します。存在確認の後も、候補となる方向性に新しい担当者、重複する担当者、フォールバック、アダプター、互換性のみを目的とする受け渡し手段、削除を先に行うかどうかの検討、未検証の前提、「長期的に安定している」という主張が残る場合は、first-principles-review とその Decision Hygiene Review にエスカレーションします。どちらの確認も、あらゆる設計に必須の儀式にしてはいけません。判断対象が整理されたら、このワークフローに戻ります。

主要な判断が内部での廃止、互換性の維持、永続状態の確認のいずれかである場合は、anti-entropy-governance を組み合わせます。これは削除対象を分類し、delete-first | compat-exception | confirmation-first を選択し、破壊的な操作の権限を設計スキルの外部に維持します。 主なリスクが広範な戦略ではなく、アーキテクチャの一貫性、つまり正規の所有者が不明確であること、責務が重複していること、呼び出し側でフォールバックしていること、古い経路に実際のロジックが残っていること、または上位レベルの所有者／契約／信頼できる情報源を簡素化できる可能性があることにある場合は、より範囲を絞った Architecture Integrity Lens を使用してください。このレンズでは、アプローチを推奨する前に、不変条件、正規の所有者／契約、責務の重複、上位レベルでの簡素化、廃止／反証条件、判定に答える必要があります。

Prior-Art & Reuse Lens： 候補となるアプローチに、新しい仕組み、プロトコル、アーティファクトの形式、または重要なやり取りのパターンが導入される場合は、独自に考案する前に、実証済みの外部事例を確認してください。このレンズは動作をきっかけに適用します。プロジェクトにとって方向性が新しい場合、内部での再利用を確認した後も妥当なアプローチが複数残る場合、または対象領域について現在のリポジトリに証拠がない場合は、先例を調査してください。すでに広く知られたフレームワークのパターンに当てはまる定型作業では、調査のための手続きを行わないでください。また、ウェブ検索ツールが利用できなくても、アプローチの選定を停滞させないでください。

Prior-Art & Reuse Lens:
- Searched precedents: <bounded sources; index-first summary; cite anchor per claim>
- Adopt verbatim: <proven pattern + source>
- Adapt with reason: <tailored part -> project constraint / non-negotiable it maps to>
- Reject with reason: <project fact that makes the pattern inapplicable>
- Degraded: <no web/search tooling -> external basis unknown; internal-only evidence stated>

検索結果は証拠の候補であり、プロンプトに含める素材ではありません。生のページを貼り付けるのではなく、インデックスを起点に要約し、根拠となる箇所を引用してください。引用可能な根拠がない「業界標準」という主張は unknown のままにしてください。採用／却下の判断はすべて、好みではなく、名前を挙げたプロジェクトの制約または事実に結び付けてください。このレンズはアプローチの推奨にのみ反映されます。参考情報として扱い、完了を承認する権限は与えません。

ベースラインにおける役割の整合： 「何を構築すべきか」と「どこに置くべきか」の両方が問題になり得る場合は、要件の正しさとアーキテクチャの正しさを分けて扱ってください。

Baseline Role Alignment:
- Product / Requirement Baseline:
- Architecture / Runtime Boundary Baseline:
- Result: aligned | Design Defect | Implementation Drift | missing-authority | needs-clarification
- scope: requirements | architecture | both
- Next action:

該当する要件、設計、またはベースラインが間違っている場合は、Design Defect を使用してください。正しい変更されていないベースラインから作業が逸脱している場合は、Implementation Drift を使用してください。Architecture Defect と Architecture Drift は、それぞれアーキテクチャに関する Design Defect と Implementation Drift の互換エイリアスです。これはレビュー用のレンズであり、実行時のゲートでも、完了を承認する権限でもありません。

設計の提示： 複雑さに応じてセクションの規模を調整してください。重要な対象、つまりアーキテクチャ、コンポーネント、データフロー、エラー処理、テスト、互換性の境界だけを扱ってください。動作、契約、アーキテクチャ、またはユーザー向けのフローを決定する場合は、実装の前に設計の承認を得てください。

ADR のシグナル： 設計／仕様が永続的なアーキテクチャ要素（所有者、公開契約、アーティファクトの形式、依存関係の方向、信頼できる情報源、ホストとの互換性、実行時に利用可能となる境界、フォールバック、アダプター、廃止スケジュール）に関わる場合は、ADR のシグナル、参照元、実際の代替案、後で完了するために必要なベースライン同期の確認事項を記録してください。実行されていない案を、承認済みのアーキテクチャ記録として作成しないでください。

分離を意識した設計： 各ユニットの目的は明確に一つとし、インターフェースを明確に定義して、単独でテストできるようにしてください。内部の実装を読まなくても理解できますか。内部の実装を変更しても、利用側を壊さずに済みますか。

既存のコードベース： 既存のパターンに従ってください。現在の目標に役立つ場合に限り、対象を絞った改善を加えてください。設計が契約、互換性、フォールバック、または重複した所有者に関わる場合は、その点を明確に指摘してください。

条件付きの詳細ガイダンス

ユーザー向けのインターフェースやインタラクションを設計する場合は、ui-ux-governance を組み込み、範囲を限定したエクスペリエンスのルールを既存の受け入れ基準に反映します。このスキルは、設計承認と引き継ぎの責任を保持します。

条件付きの設計プローブ、シナリオプロファイル、ワークスペース／仕様ドキュメントの詳細については、以下の明示的な見出しに対応します。

expanded-design-guidance.md のうち、証拠に合致するセクションだけを読みます。

• 既存の証拠が不十分で、範囲を限定したプローブによって設計の方向性を変えられる場合に限り、## Design Probe を読みます。
• 作業が名前付きシナリオクラスのいずれかに分類され、プロファイル固有の状態やリスクの網羅が有用な場合に限り、## Software Scenario Profiles を読みます。
• Doc Necessity Gate によって仕様書またはワークスペース成果物が選ばれた場合に限り、## Documentation And Workspace Bootstrap を読みます。
• Design Spec を作成する場合に限り、## Spec Self-Review を読みます。
• 名前付きのベースラインテンプレートのセクションは、そのファイルを新規作成する場合に限り読みます。

ルート選択、最初のターンでの確認、別ルートへの移行ケース、または Grilling Mode のインタビュー中には、このリファレンスを読み込まないでください。このリファレンスは詳細を提供しますが、ルーティング、設計承認、引き継ぎの責任は引き続きこのメインスキルが担います。

設計の準備完了と設計完了

次の条件を満たしたとき、アプローチの選定準備が整います。

• 望ましい成果と主要なシナリオが明らかになっている。
• 範囲と対象外事項が明示されている。
• 現在の動作と目標との差分が、根拠に基づいている。
• 主要な不変条件と、正規の所有者となりそうなものが特定されている。
• 少なくとも1つの観測可能な受け入れ基準がある。
• アプローチの分類を変えうる未解決の不明点がない。

不明点をすべて解消する必要はありません。収束の妨げとなるのは、判断を変えうる不明点だけです。

以下の該当する条件をすべて満たすと、設計を引き継げます。

• 選択したアプローチと正規の所有者が明示されている。
• 固定された動作／契約と、実装側が選べる事項が分けられている。
• 代替案を実質的に比較したか、証拠に基づいて除外している。
• 重要な前提が、証拠によって裏付けられているか、明示的に承認されている。
• 該当する場合、障害／復旧と利用者への影響が網羅されている。
• 受け入れ基準が観測可能で、検証に使用できる。
• 新たな所有者、フォールバック、アダプター、互換性、永続化について、作成を裏付ける証拠と、廃止／ロールバックの扱いがある。
• ユーザーが所有するすべての判断について、ユーザーから実際に承認を得ている。

Design Complete は手法の準備が整った状態を示すものであり、完了を承認する権限ではありません。これらの条件を満たした場合に限り、writing-plans に進んでください。判断を変えうる未解決の不明点を計画に持ち込まないでください。

設計の後

承認後は、必要に応じて検証済みの仕様成果物を作成します。Doc Necessity Gate によってワークスペースまたは仕様ドキュメントが選ばれた場合は、expanded-design-guidance.md の該当セクションを読みます。それ以外の場合は、承認済みの設計をセッション内に保持します。ワークスペースのサポートを選択した場合、そのヘルパーは対象プロジェクトの外部に置き、<aegis-workspace-helper> として呼び出します。

Aegis Project Workspace： ワークスペースの作成と仕様の保存は、引き続き Doc Necessity Gate とプロジェクトの権限に従います。

Design Spec を作成する場合は、計画に進む前に自己レビューを完了し、ユーザーから明示的なレビューを受けてください。要望された変更を適用し、再度レビューします。中規模タスクの受け入れ条件を定めるだけの小規模な Spec Brief では、プロジェクトの権限によって正式なゲートが求められない限り、簡潔なレビューで構いません。

実装：

• writing-plans スキルを呼び出して、詳細な実装計画を作成します。
• 他のスキルは呼び出さないでください。次のステップは writing-plans です。

主要な原則

• 一度に1つの質問 — 複数の質問を一度に提示して、相手を圧倒しないでください。
• 選択式を優先 — 可能な場合、自由回答よりも回答しやすい形式です。
• YAGNI を徹底する — すべての設計から不要な機能を取り除きます。
• 代替案を検討する — 決定する前に、常に2～3つのアプローチを提示します。
• 段階的に検証する — 設計を提示し、先に進む前に承認を得ます。
• 柔軟に対応する — 筋が通らない点があれば、立ち戻って確認します。