出力スタイル（平易な言葉、ダッシュやハイフンは使用しない）
このスキルが生成するすべてのもの（ファイル、メッセージ）は、平易でシンプルな言葉で記述してください。読者には「あなた」として語りかけ、同僚のように温かく直接的で、すべてのステップは実行してもスキップしてもよい推奨事項として提示し、決して命令しないでください。実際の意味を持つ技術用語は保持し、それぞれを平易な言葉で説明してください。句読点としてダッシュやハイフンを決して使用しないでください。emダッシュ、enダッシュ、ハイフンでつないだ複合語も禁止です。read only のように書き、read-only とは書かないでください。単純な言葉で言い換えるか、文を書き換えてください。コード、ファイルパス、コマンドフラグ、他のスキルが照合する値はハイフンを保持します。短い文、カンマ、または括弧を使用してください。明確さは賢さに優先します。
このスキルの機能
構造化された発見プロセスを実行し、選択肢を評価し、docs/specs/ にビルド仕様を作成または更新します。メインスレッドが作成を担当し、コードベースの読み取りやWebからの情報取得のみを安価なサブエージェントにオフロードします（サブエージェントを参照）。4つのモードがあります。
| モード | 使用タイミング | 設計動作 |
|---|---|---|
FEATURE | 既存のコードがあるかどうかに関わらず、新しい機能を一から設計する場合 | 第一原理による設計、ベストプラクティス、最小限のコード読み取り |
ARCHITECTURE | 新しいプロジェクトの技術スタックまたは基盤アーキテクチャを選択する場合 | 包括的なスタック評価、業界パターン、コードの読み取りは不要 |
ENHANCEMENT | 既存のものを改善、置き換え、または拡張する場合 | 既存のコードと仕様を読み取り、焦点を絞ったオプション比較 |
CROSS-CUTTING | コードベース全体にわたるパターン（エラーハンドリング、ログ記録、認証、命名）を標準化する場合 | 現在の状態をサンプリングし、標準を正確に定義し、適用を推奨 |
- 作成: 新しい決定 → ステータスが
Proposedの新しい仕様 - 更新: 既存の決定を発展させる → 既存の仕様をその場で編集
- 差し替え: 過去の決定を置き換える → 新しい仕様 + 古い仕様のステータス行を更新
- 追認:
/developがエンジニアが決定前に構築することを選択した際に記録したAssumedステータスの仕様を審議する → 以下の 想定された決定を追認する を参照
仕様のステータスは、ビルド可能なスコープ機能が仕様をリンクしているかどうか（docs/scope/ の行で spec セルがその仕様を指しているかどうか）によって、2つの方法のいずれかで動作します。
- 機能リンク付き仕様（典型的な FEATURE/ENHANCEMENT、またはスコープ行を持つ ARCHITECTURE 基盤）: ステータスは機能のライフサイクルを反映します。/architect は
Proposedとして作成し、その内容を所有しますが、ステータスを進めることはありません。/develop は機能が進行中になったときにIn Progressに進め、その後、構築および検証されたときにAcceptedに進めます（スコープがdone）。エンジニアの確認は内容のみを追認します。Acceptedは出荷済みを意味します。 - スタンドアロン決定仕様（基盤/スタックまたは横断的標準、リンクするスコープ行なし）: 決定ステータス。作成時は
Proposed、エンジニアが確認時に追認するとAcceptedになります（決定は発効します）。/develop はこれを進めません。
既に出荷済みの作業（「既に構築済み」のパス、または既に existing のリンク機能）を文書化する仕様は、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（これらのバグが存在する階層）では強く「別のモデル」を推奨し、Alphaでは選択肢を提供し、Prototypeでは「スキップ」を推奨します。見つかったギャップは、自動解決せずに、推奨される修正とともにエンジニアに提示され、エンジニアが決定します。仕様作成後 を参照してください。
Web からの情報取得は、決定に必要な場合に1回行われます（ステージ (c) のランドスケープおよびツールディスカバリチェック）。返されたリンクは、人間が追跡できるように仕様の参考文献に含まれます。AI が再度取得することはありません（クロスチェック、/develop、または /audit でも）。
質問 vs 行動
仕様を作成する前（および読み取り/取得ヘルパーを起動する前）に、的を絞った質問をしてください。予算を実質的な内容に費やしてください。すべての質問を分類します。
- INFER: プロンプトやコードベースから明らかなこと（機能かアーキテクチャか、スタック、UIの範囲、すでに選択されたプロバイダー）。導き出し、決して尋ねないでください。
- ASK: エンジニアだけが知っていること（要件、好み、ビジネスルール、コンプライアンス範囲）。
- RECOMMEND: 専門知識で決まること（どのプロバイダー/ライブラリ/パターンが適切か）。選択肢、1行の理由、次点を述べてください。エンジニアは上書きできます。中立的なメニューや暗黙の決定は絶対に避けてください。
完全なデータモデル、フルスタック、または既成の受け入れ基準セットを1つの承認または変更パネルにまとめたり、ツール、プロバイダー、セットアップの選択を黙って決めたりしないでください。
推奨事項は使用中のスタックに合わせてください（BaaS を使用している場合、新しい外部ツールよりもその認証/ストレージを優先。再利用が乱立に勝ります）。Web でもモバイルでも、プラットフォームを推測し、Web を想定しないでください。
これは意図であり、手順ではありません。質問の実行方法は internal/design-conversation.md にあり、以下の実行により、設計の質問を1つもする前に全文を読むことになります。
アーティファクトの所有権
docs/specs/ 内の仕様ファイル。このスキルによってのみ作成または更新されます。さらに、付随する証拠（インベントリ、監査）も含み、これらは仕様の rationale.md（ディレクトリ仕様の場合）またはインライン（単一ファイル仕様の場合）に配置され、スコープフォルダーには決して配置されません（docs/scope/ は /scope が所有し、仕様は所有しません）。
2つの独立した選択肢: ロケーション（リポジトリの形状）と形状（決定の規模）。
-
ロケーション = リポジトリの形状。 単一リポジトリ →
docs/specs/。モノレポ → ワークスペースの決定の場合はdocs/specs/<workspace>/、リポジトリ全体の場合はdocs/specs/_root/（スコープを反映）。番号付けはロケーションごとに行います（そのディレクトリをスキャンして次のNNNNを見つけます）。解決されたロケーションを$SPEC_DIRと呼びます。 -
形状 = 決定の規模。これはリポジトリの形状に関係なく同じです。単純な決定: 1つのファイル
$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が読み取るビルド仕様:## 概要、## 要件、## 決定、設計/仕様セクション、## ビルド計画、## 結果、## フォローアップ、および1行の## 根拠ポインタ（rationale.mdへ）。傘型の場合は、先頭に## 構造マニフェストがあり、すべての子仕様をリストおよびリンクし（各行: その内容とサポートする決定）、クロスチャイルド契約を保持します。rationale.md:/developがスキップする決定記録:## コンテキスト、## 検討したオプション、## 根拠、## 参考文献セクション、およびかさばる証拠（インベントリ、監査）は独自の小見出しの下に配置されます。research/フォルダーはありません。すべての証拠はここにあります。- 子仕様（傘型のみ）はフラットな
NNNN-<child>.mdファイルで、それぞれ単独でビルド可能な十分な完全性を持ち、簡潔なインラインの根拠を含みます（独自のrationale.mdは持ちません）。子仕様が大きくなった場合にのみ、独自のディレクトリに昇格させます。クロスチャイルド契約は傘型のindex.mdにあります。
-
スコープへの1つの狭い例外: 仕様が確認された後、一致する機能をビルド可能な形状に更新します（正確な編集は 仕様作成後、ステップ3を参照）。アトミックタスクリストをスコープにダンプしないでください。一致する機能がない場合: 登録を提案します（タスク導出手順を参照）。
アーティファクトベース。 デフォルトでは仕様は docs/ の下にあります。docs/ が公開ドキュメントサイト（docusaurus.config.*、.vitepress/、mkdocs.yml、Astro Starlight、または Nextra が検出された場合）である場合は、代わりに .workflow/ を使用します（.workflow/specs/）。既に存在するベースがどちらであっても、常にそれに従います（ここでのパスは docs/ を想定しています）。
移植性（任意のOS、任意のエージェント）
- コマンド:
gitは唯一必要なCLIで、すべてのOSで同じです。その他のシェルスニペット（mkdir -p、date、find、ls、cat、wc）はPOSIXリファレンスであり、リテラルスクリプトではありません。エージェントのクロスプラットフォームファイルツール（読み取り、検索/glob、書き込み、ディレクトリ作成）および今日の日付に関する知識を使用してください。mkdirではなく書き込みツールでdocs/specs/を作成してください。 - バンドルファイル:
agent-prompt.md、agent-modes/*.md、およびspec-template.mdは、このスキルのフォルダーからの相対パスにあります。メインスレッドは、仕様を書き込む直前にこれらを自分自身で読み取ります（仕様の書き込み を参照）: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>で後方にあるコミット数をカウントします。>0の場合、決定前に「最初に 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（存在する場合。例: auth機能の場合はsrc/auth/AGENTS.md）。 - この機能のビルドアプローチを読み取る: 仕様の
## ビルド計画の順序付けと分割を管理する配信戦略。優先順位: 宣言されている場合はこの機能のスコープ行アプローチオーバーライド、そうでなければプロジェクトのデフォルト（最初にルートAGENTS.md、次にdocs/scope/のスコープヘッダー）。独自のアプローチを持つ機能は、そのアプローチによって構築されます。他の機能はプロジェクトのデフォルトを使用します。4つは、実質的に異なる## ビルド計画の順序付けを意味し、同じ順序にラベルを付け直したものではありません: Tracer Bullet は、まずすべてのレイヤーを通る薄いエンドツーエンドのスレッドを立ち上げ、次に厚くします。Skateboard は、最初に使用可能な最小の全体を構築し、次に拡大します。Facade は、プレースホルダーデータでUIシェルを先行させ、移行を先送りします（プロトタイプパス）。Journey は、1つのユーザーパスのタスクを次のパスに進む前に完全に完了します。プロジェクト固有のバリアントも可能です。どちらも記録されていない場合は、仮定をメモし、スタッフ/プリンシパルの判断でデフォルトを設定します（本番作業にはエンドツーエンドの Tracer Bullet スライスを優先します）。記録されたアプローチが順序付けを目に見えて形成するようにします。 - リンクされたスコープ機能を特定する（ある場合）:
docs/scope/のファイル名/見出し（ワークスペースサブディレクトリを含む）を簡易スキャンして、このトピックに一致する機能を見つけます。見つかった場合は、その単一のスコープファイル（scope.md、または分割されている場合は一致する<epic>.md）のみを開きます。見つかった場合は、その行の意図と受け入れ基準のシード（ステージ (a) のシード）を読み取り、タスクの導出とリンクの手順のためにファイル/行を記憶します。これにより、機能リンク付きとスタンドアロンのステータスも確定します。行が一致しない場合は …
[truncated for translation]