architect

出力スタイル（平易な言葉、ダッシュやハイフンなし）

このスキルが作成するファイルやメッセージなど、すべてを平易でシンプルな言葉で書きます。読者には「あなた」と呼びかけ、同僚のように親しみやすく、率直に話します。各手順は、実行するかどうかを読者が選べる提案として示し、命令にはしません。意味のある技術用語は残し、それぞれを平易な言葉で説明します。句読点としてダッシュやハイフンは使いません。em dash、en dash、ハイフンでつないだ語も使いません。read-only ではなく read only と書きます。簡単な言葉で表現するか、文を書き換えます。ほかのスキルが照合するコード、ファイルパス、コマンドフラグ、値では、ハイフンをそのまま残します。短い文を使い、読点や括弧を活用します。気の利いた表現より、わかりやすさを優先します。

このスキルの機能

構造化された調査を行い、選択肢を比較検討し、docs/specs/ にビルド仕様書を作成または更新します。メインスレッドが書き込みを行い、コードベースの読み取りやウェブからの情報取得だけを、コストの低いサブエージェントに委任します（サブエージェントを参照）。モードは4つあります。

モード	使用する状況	設計の進め方
FEATURE	既存コードの有無を問わず、新機能をゼロから設計するとき	第一原理から設計し、ベストプラクティスに従い、コードの読み取りは最小限にします
ARCHITECTURE	新しいプロジェクトの技術スタックや基盤となるアーキテクチャを選ぶとき	スタックを包括的に評価し、業界のパターンを参考にし、読み取るコードはありません
ENHANCEMENT	既存のものを改善、置き換え、拡張するとき	既存のコードと仕様を読み、選択肢を絞って比較します
CROSS-CUTTING	コードベース全体のパターンを標準化するとき（エラー処理、ロギング、認証、命名）	現状をサンプル調査し、標準を正確に定義し、適用方法を提案します

• 作成：新しい決定の場合、新しい仕様書を作成し、ステータスを Proposed にします
• 更新：既存の決定を発展させる場合、既存の仕様書をその場で編集します
• 置き換え：過去の決定を置き換える場合、新しい仕様書を作成し、古い仕様書のステータス行を更新します
• 承認：エンジニアが決定する前にビルドを選んだとき、/develop が記録した Assumed の仕様書を検討します。詳しくは、以下の仮定された決定の承認を参照してください

仕様書のステータスは、ビルド可能なスコープ機能がその仕様書にリンクしているかどうかで、次の2通りに決まります（docs/scope/ の行にある spec セルが仕様書を指している場合）。

• 機能にリンクされた仕様書（一般的な FEATURE／ENHANCEMENT、またはスコープ行がある ARCHITECTURE の基盤仕様）：ステータスは機能のライフサイクルに連動します。/architect は仕様書を Proposed として作成し、内容を管理しますが、ステータスは進めません。機能が進行中になると /develop が In Progress に進め、ビルドと検証が完了すると（スコープが done になると）Accepted に進めます。エンジニアの確認は内容のみを承認します。Accepted はリリース済みであることを意味します。
• 単独の決定仕様書（基盤やスタック、またはスコープ行がリンクしていない横断的な標準）：決定のステータスを示します。作成時は Proposed とし、エンジニアが確認して承認すると Accepted になります（その決定が有効になります）。/develop はステータスを進めません。

すでにリリース済みの作業を記録する仕様書（「すでにビルド済み」のケース、または既存の機能にリンクされた仕様書）は、最初から Accepted になります。

Assumed ステータス。 エンジニアが、重要な決定を検討する前にビルドを選んだ場合、/develop は仕様書を Assumed ステータスで作成することがあります。その仕様書に記録されるのは、検討を経た決定ではなく、ビルドで使われた仮定です。機能を done にすることはできます。Assumed の仕様書は承認が必要な状態のままですが、機能の完了を妨げません。Assumed ステータスを解除できるのは /architect だけで、以下の手順で承認します。/architect は Assumed の仕様書を新たに作成しません。すでに存在する仕様書だけを検討します。

コードは書きません。AGENTS.md／CLAUDE.md は更新しません（この作業は /sync が担当します）。

サブエージェント（メインスレッドが執筆し、サブエージェントは読み取り、取得、照合のみを行います）

メインスレッドは会話を進行し、仕様を書きます。執筆や修正をサブエージェントに任せることはありません。起動するサブエージェントはすべて読み取り専用で、セッションのモデルを引き継ぎません。

• コードベースを読む（最も低コストのモデル、Claude Code haiku）：リポジトリが大規模な場合に、既存コードを読み取り専用で調査します（ENHANCEMENT／CROSS-CUTTING）。Claude Codeではscoutタイプです。コンパクトな概要を返し、ファイルのダンプは行いません。
• Webから取得する（最も低コストのモデル、Claude Code haiku）：設計の会話中（ステージ c）に、判断に最新情報が必要な場合、現在のツール環境とAgent Skill／MCPの発見状況を確認します。Claude Codeではresearcherタイプです。コンパクトな要約を返し、生のページは返しません。
• 作成した仕様を照合する（主な役割は、判断の完全性を確認することです。アクションが生成する必要のある値のうち、仕様に出典が記されていないものや、そうしなければビルダーが独自に決めることになる事項を見つけます）：完成した仕様を読み取り専用で確認し、何も書き込まずに批評を返します。/architectは実行するかどうかを必ず尋ねます（エンジニアに代わって実行したり、実行を見送ったりはしません）。こうした不具合が起きやすい段階であるGA／BetaではAnother modelを強く推奨し、Alphaでは選択肢として提示し、PrototypeではSkipを推奨します。見つかったギャップは、エンジニアが判断できるよう、推奨される修正案とともに提示し、自動では解決しません。「仕様の作成後」を参照してください。

Webからの情報取得は、判断に必要になった時点で一度だけ行います（ステージ (c) の環境調査とツールの発見確認）。返されたリンクは、人が確認できるよう仕様のReferencesに記載します。AIがリンク先を再取得することはありません（照合作業でも、/developでも、/auditでも取得しません）。

質問することと実行すること

仕様を書く前に（また、読み取り／取得の補助役を起動する前に）、要点を絞って質問します。予算は本質的な内容に使います。各質問を次のように分類します。

• INFER：プロンプトやコードベースから明らかなこと（機能かアーキテクチャか、技術スタック、対象となるUI、すでに選択済みのプロバイダーなど）。質問せず、推定します。
• ASK：エンジニアだけが把握していること（要件、好み、ビジネスルール、コンプライアンスの対象範囲）のみ質問します。
• RECOMMEND：専門知識に基づいて判断できること（適したプロバイダー／ライブラリ／パターンなど）。選択肢と、その理由を1行で示し、次点の候補も提示します。相手は変更を提案できます。中立的な候補一覧を提示したり、何も伝えずに決定したりしてはいけません。

データモデル一式、技術スタック全体、または完成済みの受け入れ条件一式を、ひとつの「承認」または「変更」パネルにまとめてはいけません。また、ツール、プロバイダー、セットアップの選択を暗黙に決めてはいけません。

推奨内容は、使用中のスタックに合わせます（BaaSを使っている場合は、新しい外部ツールより、そのBaaSの認証／ストレージを優先します。拡張するより再利用を優先します）。Webかモバイルかを問わず、プラットフォームは推定し、Webだと決めつけてはいけません。

ここで述べたのは意図であり、手順ではありません。質問の進め方はinternal/design-conversation.mdに記載されています。以下のExecutionでは、設計について最初の質問をする前に、このファイルを最後まで読むことが求められます。

成果物の所有権

このスキルのみが作成または更新する docs/specs/ 内の仕様ファイルと、それが作成する補足エビデンス（インベントリ、監査など）が対象です。エビデンスは、ディレクトリ形式の仕様では仕様の rationale.md に、単一ファイル形式の仕様では仕様ファイル内に置きます。スコープフォルダーには置きません（docs/scope/ は /scope の所有であり、仕様の所有ではありません）。

場所（リポジトリの構成）と形式（決定の規模）は、互いに独立した2つの選択です。

• 場所 = リポジトリの構成。 単一リポジトリの場合は docs/specs/。モノレポの場合は、ワークスペースに関する決定なら docs/specs/<workspace>/、リポジトリ全体に関する決定なら docs/specs/_root/ です（スコープと同じ構成です）。番号は場所ごとに付けます（該当ディレクトリを確認し、次の NNNN を決めます）。確定した場所を $SPEC_DIR とします。

• 形式 = 決定の規模であり、リポジトリの構成によって変わりません。単純な決定なら、単一ファイル $SPEC_DIR/NNNN-title.md（すべてを簡潔にインラインで記述）にします。複数の関連する下位決定をまとめるもの、大規模な決定や基盤となる決定、または verify.md が必要な決定なら、ディレクトリ形式にします。$SPEC_DIR/NNNN-title/ に index.md を最上位ファイルとして置き、その隣に rationale.md を置きます（まとめ仕様の場合は子仕様 NNNN-<child>.md も置きます）。名前を重複させてはいけません（NNNN-title/NNNN-title.md）。番号はディレクトリ名に含め、最上位ファイルは index.md にします。デフォルトは単一ファイルです。

  ディレクトリ形式の仕様には、必ずコアファイルをちょうど2つ置きます（任意の verify.md と子仕様を除く）。

  • index.md：/develop が読み込む実装仕様です。## Summary、## Requirements、## Decision、設計／仕様のセクション、## Build plan、## Consequences、## Follow-up、そして rationale.md を指す1行の ## Rationale ポインターを含めます。まとめ仕様の場合は、冒頭に、すべての子仕様へのリンクを一覧にした ## Structure マニフェストも置きます（各子仕様につき1行で、その内容と、どの決定を支えるかを記載します）。また、子仕様間の契約事項もここに記載します。
  • rationale.md：/develop が読み飛ばす決定記録です。## Context、## Options considered、## Rationale、## References セクションと、大量のエビデンス（インベントリ、監査など）を独自の小見出しの下に含めます。research/ フォルダーは作成せず、すべてのエビデンスをここに置きます。
  • 子仕様（まとめ仕様の場合のみ）は、フラットな NNNN-<child>.md ファイルとします。それぞれに、独自の rationale.md は持たせず、簡潔なインラインの根拠を含め、単独で実装できるだけの情報を記載します。大規模になった場合に限り、子仕様を独立したディレクトリにします。子仕様間の契約事項は、まとめ仕様の index.md に記載します。

• スコープへの限定的な例外が1つあります。 仕様の確認後、対応する機能を実装準備完了の形式に更新します（正確な編集内容は「After the spec is written」の手順3を参照）。細分化されたタスクリスト全体をスコープに書き込んではいけません。対応する機能がない場合は、機能を追加することを提案します（タスク導出の手順を参照）。

成果物のベース。 デフォルトでは、仕様は docs/ の下に置きます。docs/ が公開ドキュメントサイト（docusaurus.config.*、.vitepress/、mkdocs.yml、Astro Starlight、または Nextra を検出した場合）なら、代わりに .workflow/（.workflow/specs/）を使います。すでに存在するベースに必ず合わせてください（ここに記載したパスは docs/ を前提としています）。

---

移植性（あらゆるOS、あらゆるエージェント）

• コマンド： 必須の CLI はすべてのOSで同じ git のみです。その他のシェルスニペット（mkdir -p、date、find、ls、cat、wc）は POSIX の参考例であり、そのまま実行するスクリプトではありません。エージェントが提供するクロスプラットフォームのファイル操作ツール（読み取り、検索／glob、書き込み、ディレクトリ作成）と、今日の日付に関する知識を使ってください。mkdir ではなく、書き込みツールで docs/specs/ を作成してください。
• 同梱ファイル： agent-prompt.md、agent-modes/*.md、spec-template.md は、このスキルのフォルダーからの相対パスにあります。メインスレッドは仕様の書き込み直前に、これらを自分で読み込みます（「Write the spec」を参照）。agent-prompt.md（ペルソナ、ルール、レポート形式）、対応する agent-modes/<mode>.md、そして spec-template.md（セクション構成）が対象です。事前確認の段階では読み込まず、書き込み時にだけ読み込んでください。そうすることで、インタビュー全体を通してこれらがコンテキストに残り続けることを防げます。
• 対話形式の質問に対応していない場合： エージェントが提供する機能（選択肢ピッカーなど）を使ってください。機能がない場合に限り、同じ選択肢を付けた質問を、通常のテキストで各ラウンドごとに提示します。

実行

ステップ 0：トピックの確認（事前確認の前）

設計トピックが指定されていない場合（引数なしの /architect、または空の説明）は、ほかの作業をする前に停止して、次のように尋ねます。

「どの設計上の判断について検討したいですか？ 設計が必要な機能、システム、または選択肢について、1〜2 文で説明してください。」

回答を待ち、それを事前確認の設計トピックとして使用します。

---

事前確認（メインモデル）

次の手順を実行します（git コマンドはそのまま実行し、それ以外にはエージェントのファイルツールを使用します）。

• 最新状態の確認（チーム）: git fetch を静かに実行し、ベースブランチを選びます（git rev-parse --verify main が成功する場合は main、それ以外は master）。git rev-list --count HEAD..origin/<base> で遅れているコミット数を数えます。1 以上の場合は、判断する前に「先に pull してください」と警告します（チームメイトが仕様を追加したり、この機能を変更したりしている可能性があります）。
• 仕様の場所を解決（SPEC_DIR）します。これは docs/specs/ に対応するスコープのワークスペースです。単一リポジトリの場合は docs/specs/、モノレポのワークスペースの場合は docs/specs/<workspace>/、リポジトリ全体の場合は docs/specs/_root/ です。スコープに基づいて <workspace> を特定します（トピック／パス／スコープ行）。存在しない場合はディレクトリを作成します。
• 今日の日付: 今日の日付を使用します（仕様に挿入します）。
• この場所にある既存の仕様を一覧表示: $SPEC_DIR 内で、番号付け（場所ごと）と関連する判断の検出のため、NNNN-*.md という名前のファイルと index.md を一覧表示します。
• ソースファイル数を数える（例：.ts、.tsx、.js、.py、.go、.rs、.java）。node_modules/、.git/、dist/ は除外します。これは、読むべきコードの量と、その読み取りを scout サブエージェントに委ねるかどうかの判断材料になります。
• プロジェクトのコンテキストを読む。これは、技術スタックとコミュニティスキルの信頼できる情報源です。ルートの AGENTS.md（なければ CLAUDE.md、それもなければ MISSING）に加え、この機能の領域にネストされた <area>/AGENTS.md が存在する場合はそれも読みます（例：認証機能の場合は src/auth/AGENTS.md）。
• この機能のビルドアプローチを読む: 仕様の ## Build plan の順序と分割を決めるデリバリー戦略です。優先順位は、この機能のスコープ行に Approach のオーバーライドが宣言されていればそれを使用し、そうでなければプロジェクトのデフォルトを使用します（まずルートの AGENTS.md、次に docs/scope/ のスコープヘッダー）。機能独自のアプローチがある場合は、その機能にはそのアプローチを適用し、ほかの機能にはプロジェクトのデフォルトを適用します。4 つのアプローチでは、実質的に異なる ## Build plan の順序を定めます。同じ順序に別の名前を付けるものではありません。Tracer Bullet は、まずすべてのレイヤーを貫く最小限のエンドツーエンドの流れを確立し、その後に拡充します。Skateboard は、まず利用可能な最小限の全体を構築し、その後に拡張します。Facade は、プレースホルダーデータを使った UI シェルを先行させ、移行を後回しにします（プロトタイプ経由のアプローチ）。Journey は、次のユーザーパスに進む前に、1 つのユーザーパスのタスクをすべて完了させます。プロジェクト固有のバリエーションも可能です。いずれにも記録がない場合は、その前提を記録し、スタッフ／プリンシパルとしての判断でデフォルトを設定します（本番作業では、エンドツーエンドの Tracer Bullet スライスを優先します）。記録されたアプローチが順序に明確に反映されるようにします。
• 関連するスコープ機能（存在する場合）を特定: トピックに一致する機能を探すため、docs/scope/ のファイル名と見出しを（ワークスペースごとのサブディレクトリも含めて）簡易的に確認します。一致する機能を含むスコープファイルだけを開きます（分割されている場合は scope.md または一致する <epic>.md）。見つかった場合は、その行の意図と受け入れ条件の種（Stage (a) の種になります）を読み、導出タスクとリンク作業のためにファイル／行を記録します。これにより、機能がスコープにリンクされているか、単独かも確定します。一致する行がない場合は、単独機能としての判断経路を記録し、今回は新たに作成しないでください。
• （任意） 利用可能なスキルを確認する目的に限り、インストール済みスキルのディレクトリ（.claude/skills/、.agents/skills/、skills/）を一覧表示します。関連性は名前の一致ではなく、AGENTS.md と機能に基づいて判断します。 仕様一覧（$SPEC_DIR からの相対パス）：
• 次の番号：既存の最大番号に 1 を加え、4 桁のゼロ埋めにします。該当するものがなければ 0001 です（包括ディレクトリも 1 つの番号として数えます）。番号の重複を防ぐため（チームの場合）：書き込みの直前に、もう一度 $SPEC_DIR を一覧表示します。選んだ NNNN がすでに存在する場合は、次に空いている番号に繰り上げます。既存の仕様を上書きしてはいけません。書き込み後、並行して実行された別の処理が同じ番号を使っていないことを確認します。
• ファイル名／構成：トピックから kebab-case のスラッグを作成します。最大 5 語、冠詞なし、小文字です。
  • 単純な意思決定 → $SPEC_DIR/NNNN-kebab-title.md。
  • 包括的な意思決定（関連するサブ決定に 2 つ以上分割）→ ディレクトリ $SPEC_DIR/NNNN-kebab-title/ を作成し、index.md（子項目を列挙した包括的な意思決定）、rationale.md（理由とインベントリ／監査結果）、および子仕様 NNNN-child.md をその中に置きます。書き始める前にトピックの範囲から構成を決め、執筆中もその構成を意識してください。
• 関連仕様：仕様が増えても効率を保てるよう、2 段階で確認します。まず既存の仕様のタイトル行だけを読みます（数十件あっても負荷は小さいです）。次に、タイトルがこのトピックと重複する可能性がある少数の仕様だけ、最初の 20 行（タイトル、ステータス、コンテキストの冒頭）を読み、該当するか確認します。一致するものがあれば示します。
• 包括仕様の子項目の判定：トピックが既存の包括仕様（$SPEC_DIR/NNNN-<umbrella>/）のサブ決定にあたる場合（たとえば、その配下で作業中に見つかったもの）、新しい仕様はそのディレクトリ内の次の子項目（NNNN-child.md）として配置し、トップレベルに新規作成するのではなく、包括仕様の index.md の一覧にも追加します。同じパスを /develop でビルドの途中に決定事項が生じた場合にも使います。配置先をエンジニアに伝えてください。
• 更新／置き換えの判定：既存の仕様がトピックと明確に重複している場合（同じ領域、システム、意思決定）、段階的な会話を始める前に、意思決定パネルを提示します（エージェントに選択 UI がない場合はプレーンテキストの選択肢を表示し、選択 UI には「その他」が自動的に追加されます）。「重複する可能性のある既存の仕様が見つかりました：[path]、[title]。どのように扱いますか？」選択肢：新しい意思決定（新しい仕様を作成） · 既存の仕様をそのまま更新 · 置き換え（新しい仕様で置き換える）。重複の程度に応じて「（推奨）」を付けた選択肢をデフォルトにします（ほぼ同一なら「更新」または「置き換え」、隣接する内容なら「新しい意思決定」）。更新／置き換えの場合は OPERATION を設定し、既存の仕様を全文読み込み、そのまま更新する場合は段階的な会話を省略します。
  • Assumed の仕様が見つかった場合：重複する仕様の **Status**: が Assumed の場合、上記のパネルではなく、承認手続きに進みます。「Assumed の意思決定を承認する」に従い、設計に関する会話を行ったうえで、実際の内容を記入して Assumed を解除するか、仮定が誤っていた場合は置き換えます。

コミュニティスキルは、固定の名前一覧ではなく、プロジェクトの AGENTS.md に記載されているものを使います（名前や技術スタックは変わるためです）。プロジェクト全体のスキル／規約はルートの AGENTS.md に、領域固有のものはネストされた <area>/AGENTS.md に記載されています（/audit と /sync が管理します）。

1. ルートの AGENTS.md と、この機能の領域に対応するネストされた AGENTS.md を読みます。それぞれの ## Agent skills セクションには、インストール済みの各スキルが、その場所と、それが何を統制するかについての一行のメモとともに箇条書きで列挙されているので、関連するスキルとそのパスを直接選び出すことができます。
2. この 機能に関連するスキルのみを特定します。その ## Agent skills の箇条書きから、関連する各スキルのパスとメモを取得し、執筆中に、それが意思決定を実質的に形作る場合にのみ (「仕様を書く」の項目 12 を参照)、必要に応じて開きます。その機能が触れないスキルはスキップします。
3. 利用可能 ≠ 関連あり。存在するものを確認するためにインストール済みのスキルディレクトリを一覧表示してもかまいませんが、関連性はその機能と AGENTS.md から導かれます。明確に関連するスキルがインストールされているのに、まだ AGENTS.md で参照されていない場合は、それでも使用し、それが適切なコンテキストファイルに属することを (仕様のフォローアップで) 指摘します。プロジェクト全体にわたる場合はルート、領域固有の場合はネストされた <area>/AGENTS.md です。
4. コンテキストファイルが、プロジェクトがすでに使用していると示しているもの (BaaS、ORM、決済プロバイダー、認証ライブラリ) は何であれ、あなたのライブラリ/プロバイダーの推奨がその上に構築するか、優先すべきものであり、無関係な外部ツールではありません。本当により良い選択肢がインストールされていない場合は、黙って想定するのではなく、仕様のフォローアップとして記載します。

ワークフロースキル (コミュニティスキルとして扱わないこと): audit、architect、scope、develop、check、test、document、debug、sync、および作成される新しいワークフロースキル。

---

スコープの検証、フレーミング、段階的な設計対話

作成または置き換えの操作では、これは厳格なゲートです: エンジニアに設計上の質問を一つでもする前に、internal/design-conversation.md を全文読み、それに従ってください。 そこにはスコープの検証 (すでに構築済みのドキュメントパスを含む)、フレーミング、および段階的な設計対話が含まれています。上記の 尋ねるか行動するか は意図にすぎず、プロトコルではありません。そのファイルを読むまでは、インタビューを開始したり、質問を生成したり、仕様を書いたりしないでください。(インプレースの仕様更新の場合にのみスキップしてください。)

仕様を書く (メインスレッド)

段階的な対話の後、仕様はあなた自身が書きます。草案作成、調査、批評のために誰かを立ち上げないでください。このスキルのフォルダーを絶対パスに解決し (これらの相対パスはすでに解決しているので、フォルダーは把握しています)、今すぐ (インタビュー中ずっとコンテキストに残らないように、今になって初めて) 3 つのファイルを読みます: agent-prompt.md、spec-template.md、および推論された MODE に一致する 1 つのモードファイルです:

• FEATURE → agent-modes/feature.md
• ARCHITECTURE → agent-modes/architecture.md
• ENHANCEMENT → agent-modes/enhancement.md
• CROSS-CUTTING → agent-modes/cross-cutting.md

次に、以下を適用して仕様を書きます:

• agent-prompt.md から: ペルソナ (「あなたは誰か / どのように考えるか / 何をしないか」) を採用し、共通の指示、Step 0、Step 0b、## Expert rules that apply to all modes、## Report format に従います。## Instructions by mode では、上記の 1 つのモードファイルを唯一のモード固有ブロックとして従い、他のモードファイルは無視します。agent-prompt.md は ALL_CAPS のプレースホルダーを用いたサブエージェント向けの指示として書かれています。それらのプレースホルダーは、対話ですでに収集した入力 (以下に列挙) として読み、ルールを自分自身に適用してください。
• spec-template.md から: === SPEC TEMPLATE START === と === SPEC TEMPLATE END === の間の部分 (仕様セクションの構造とフィールドのガイダンス) のみを使用します。後続の参照/メタセクション (## Filename conventions、## Status values テーブル、アンブレラ構造 / 子ステータスの注記、## Writing rules) はあなた自身のガイダンスです: ファイル名、形状、および初期の **Status**: はプリフライトで解決済みです。**Status**: 行は ## Expert rules that apply to all modes の「On the initial **Status**: line」ルールに従って書いてください。spec-template.md は編集しないでください。 参照資料とリンク：Stage (c) の REFERENCES_LEVEL を再利用してください。今は取得しないでください。 On sourcing & citations の agent-prompt.md に従い、そのレベルで ## References セクションと (basis: ...) の引用を記述してください。Stage (c) のチェックは一度実行されています。確認済みのリンクのみを再利用し、未確認のソースは URL を付けず、名前で引用してください。Stage (c) が実行されていない場合（ドキュメント作成パスなど）に限り、今、References の同意パネルを提示してください（推奨の選択肢は No references, keep it clean）。REFERENCES_LEVEL は none または sources に設定してください（sources+links は選択肢にありません。執筆時に取得することはできません）。

推定された MODE（Framing に基づく）は、すでに FEATURE／ARCHITECTURE／ENHANCEMENT／CROSS-CUTTING のいずれかです。

適用する入力（デザインに関する会話と事前確認ですでに把握しているもの）：

1. デザインのトピック（ユーザーの最初のメッセージから）
2. 推定されたフレーミング：MODE、プラットフォーム（web／mobile／API）、スタックと規約（AGENTS.md から）、および推定または確認された制約／コンプライアンス 2a. 機能のビルド方式（事前確認の優先順位：スコープ行の Approach による上書き、次に AGENTS.md／スコープヘッダーのプロジェクト既定値、最後に記載された既定値）→ BUILD_APPROACH。この機能でビルド方式が意味する内容に沿って、## Build plan の順序と分割を決めてください。
3. 段階ごとの会話で確定したすべての回答：確定済みの受け入れ基準（すでに AC-1… の形式で ID が付与されています。## Requirements の起点にします）、確定済みのデータモデル（エンティティ／フィールド／関係、## Build plan のマイグレーションの起点となる対象。機能に見合う規模にしてください）、確定済みのスタック／ツールの選択、API サーフェス、認可モデル、エッジケース。ドキュメント作成パス（段階的な会話をスキップした場合）は、エラーではなく "Staged design skipped, documenting an already-made decision" として扱ってください。 3a. RECOMMEND 項目 → RECOMMEND_ITEMS_OR_NONE：具体的に判断して根拠を示す必要がある決定事項（スタックに適合するツール／プロバイダー、セッションモデルなど）。各項目について結論を出し、未回答の質問としてそのまま返さないでください。なければ "none" として扱ってください。 3b. References レベル → REFERENCES_LEVEL（上記のルールに従い、none | sources | sources+links）。Stage (c) が実行されておらず、まだ確認していない場合は none を既定値としてください。
4. コンテキストファイルの内容：AGENTS.md（ルートと機能領域のネスト先）。なければ CLAUDE.md を代替として使用し、それもなければ "MISSING"
5. 既存の仕様書一覧（ファイル名と各ファイルの先頭行）
6. 関連する仕様書のパス（事前確認で特定したもの）
7. 解決済みの仕様書配置先（$SPEC_DIR）、次の番号、形式：単一ファイル $SPEC_DIR/NNNN-title.md、またはディレクトリ $SPEC_DIR/NNNN-title/（index.md + rationale.md、アンブレラ仕様の場合は子仕様も含む）。アンブレラ仕様の場合は、名前の付いた子の決定事項を記述してください。インベントリ／監査は rationale.md に記載し、docs/scope/ にもコードツリー内の単独ファイルにも置かないでください。**Status**: 行を含めるのは index.md のみです（機能のステータスを反映します）。子仕様にはライフサイクルの Status を記載しません（仕様の内容はアンブレラ仕様によって管理されます）。
8. ソースファイル数（読み取るコードがあるかどうか。大規模な ENHANCEMENT／CROSS-CUTTING コードベースでは、Subagents に従って読み取りを scout サブエージェントに委任し、そのマップを基に記述してください）
9. 操作：create | update | supersede
10. 今日の日付（事前確認から）
11. ドキュメント作成時のコンテキスト（「すでに構築済み」のパスを実行した場合：この選択をした理由、代替案、トレードオフについてのエンジニアの自由記述回答）
12. この機能に関連するコミュニティスキル（事前確認で AGENTS.md から特定したもの）。判断に実質的な影響がある場合に限り、必要に応じてスキルファイルを開いてください。参照した場合は、その規約が優先されます。各スキルの名前を ## Decision の Implementation skills フィールドに記載してください。

---

仕様書の作成後

仕様書ファイルが存在したら、internal/after-subagent.md を読んで、仕様書のセルフチェックとセルフレビュー、確認、ステータスの承認、スコープとの紐付け、最後の口頭要約を行ってください。仕様書を作成する前に読んではいけません。

更新 / 置き換えのパス

タスクが既存の仕様を更新または置き換えることである場合:

• 事前確認: 既存の仕様を完全に読む
• 操作がインプレース更新である場合は、段階的な会話をスキップする
• 操作を設定する: update または supersede
• 置き換えの場合: 新しい仕様を書き、AND 古い仕様のステータスを Superseded by [NNNN](NNNN-title.md) に更新する

想定された決定を批准する

トピックが既存の Assumed 仕様に解決される場合(エンジニアが /develop のエスケープハッチを介して先にビルドし、今それを批准している状況で、多くの場合 /architect <feature>: ratify … と表現されます)、事前確認でその仕様が見つかります。それを完全に読んでください: その ## Owed decision、## Assumption built on、## Code area は、暫定的に何が決定されたか、そしてコードがどこにあるかを示しています。その後、実際にビルドされたものに基づいて通常の設計会話を実行し、その決定を適切に審議します。2 つの結果があります:

• 想定が成り立つ場合。 実際の決定内容(Context、Options considered、Decision、Rationale、設計セクション、Consequences)を埋めて、仕様が真に審議された記録になるようにし、Assumed をクリアします: **Status**: 行を機能のライフサイクル状態に設定します(機能がビルド済みだがまだ done でない場合は In Progress、すでに検証およびテスト済みの場合は Accepted)。その後 /develop は通常どおり done 時にそれを Accepted にクローズします。決定はもはや一時的なものではありません。
• 想定が誤っていた場合。 実際の決定を含む修正済みの仕様(create または supersede)を書き、想定された仕様を Superseded by [NNNN](…) とマークし、ビルドが誤った想定に基づいており、修正済みの仕様に照らしてやり直すべきであることをエンジニアに伝えます。

いずれの場合でも、批准は Assumed 仕様がその状態を抜け出せる理由です: /develop が想定を記録し、/architect がそれを確認または修正し、その根拠を提供します。批准実行後に仕様を Assumed のままにしないでください。

---

参照ファイル

• 仕様テンプレート: spec-template.md (メインスレッドが書き込み時に読み取ります)
• 仕様作成ルール & ペルソナ: agent-prompt.md (メインスレッドが書き込み時に読み取ります)
• モード固有の作成指示: agent-modes/*.md (書き込み時に一致するモードファイルのみを読み取ります)
• メインスレッドの設計会話: internal/design-conversation.md (create/supersede の場合のみ読み取ります)
• Agent Skill & MCP オファー: internal/tool-discovery.md (スタックウォークで新しいツールが確定した場合のみ読み取ります。検索前に確認を求め、その後レジストリのフェッチが researcher サブエージェントで実行されます)
• メインスレッドの完了フロー: internal/after-subagent.md (仕様の書き込み後のみ読み取ります)
• 段階的な設計会話は機能ごとに生成され(段階的な設計会話、ステージ a から f を参照)、保存されません。定型の質問リストはありません。トピックが曖昧すぎて生成できない場合は、まず絞り込み(スコープ検証、または 1 つの明確化質問)を行い、決して汎用的な MCQ にフォールバックしないでください