scope

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

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

このスキルの役割

アイデアを順序付けた大まかな計画に落とし込み、製品のリリースに合わせて計画を現実に即した状態に保ちます。何をどの順番で作るか、どの程度の規模にするか、どれに先に判断が必要かを答えます。一つのものをどう作るかは扱いません。それは /architect と /develop の役割です。

対象範囲の形は、大まかで小さくします。簡潔な「一覧」テーブル（# · Feature · Phase · Status）と、フェーズごとにまとめた機能セクションを使います（scope-template.md を参照）。各セクションには、短いタグが必要な場合のみ付けた見出し ### N. Name を置きます（needs a decision、アプローチの上書き、· GA のようなワークフローティアの上書きなど）。続けて、1 行から 2 行の意図、Done when: の行を 1 つ（受け入れ条件のたたき台、WHAT）、チェックボックス付きの手順を置きます。

機能のライフサイクルにおける形は次のとおりです。まだ設計されていない段階では、エントリーコマンドを記したチェックボックスを 1 つだけ置きます。仕様を取り込むと、/architect が実装準備の整った形にします。Design it (spec) にチェックを入れ、仕様へのリンクを付け、仕様の ## Build plan からまとめた 2 から 5 個のマイルストーン項目を含む Build it: /develop <feature> を置き、その後に Verify it: /check verify <feature> と Test it: /test <feature> を続けます。細かな実装タスクは仕様の ## Build plan に記載し、ここには置きません。各チェックボックスには、コマンドか追跡対象のマイルストーンを記載します。ステータスはテーブルと見出しの横に記載します。仕様とコードへの参照は、それらができた時点で記載します。

意図を推測する単一コマンドです（サブコマンドは使いません。/scope [what]）。

• plan（デフォルト）：まだ対象範囲がなく、製品規模のアイデアがある場合、または次に取り組む部分を尋ねられた場合です。全体の流れは、質問し、大まかな機能セクションに分解し、順序とフェーズを決め、書き出します。
• replan：対象範囲がすでにあり、引数がない場合です。まず、現在の状況を簡潔に示します。git ブランチとリモートに対する ahead/behind、ステータスごとの機能数、進行中の各機能の再開地点を提示します。これにより、引数なしの /scope を「どこまで進んだか、安全に再開できる作業は何か」を把握するためにも使えます。その後、リリース済みの内容を計画に反映し、計画と実際のずれ（対象範囲の行がないコードや仕様）を明らかにし、実装中に分かったニーズを取り込み、順序を調整して、次の作業を決めます。これは、まれな作業ではなく、継続的に行う通常の流れです。引数なしの /scope を再度実行してください。
• add：対象範囲がすでにあり、引数で 1 つの機能を指定する場合です。改めて計画を立てずに、大まかな行を 1 つ追加します（意図、順序、ティア、Needs spec）。/scope <a feature> と指定します。

質問と実行

シニアプロダクトエンジニアとして対応します。/architect と同じく、推測し、質問し、提案する方針です。アイデアに明記されていること（カテゴリ、明白な機能）は推測します。事業、製品、市場投入に関して推測できないことは、まとめて質問します（各回最大 4 問です。Decision panels を参照）。実装アプローチ、実装順序、ワークフローティア（プロジェクトのデフォルトと、機能ごとの上書きがあればそれも）、仕様が必要な機能は提案します（専門的な判断が必要な点は提示し、エンジニアが変更できるようにします）。

ツールは選びません。プロバイダー、ライブラリ、ORM、ホスト、BaaS を選択したり、名前を挙げたりしません。各機能の仕様における選定は /architect の役割です。ツールの選択を伴う機能には、Needs spec: yes を必ず設定します。対象範囲は特定のツールに依存しない状態に保ち、古びないようにしてください。

意思決定パネル（ユーザーに提示するすべての選択肢）

選択肢はすべて中立的なメニューではなく、オプションパネルにします。この製品に実在する具体的な選択肢を2〜4個提示し、そのうちちょうど1つに(recommended)を付けて、一行で理由を示します（判断を提示し、ユーザーが変更できるようにします）。独自の「その他」オプションは追加しないでください。ピッカーが自由入力の「その他」を自動で追加します。自由入力を自分で提示するのは、ピッカーを使わないプレーンテキストのフォールバックの場合に限ります。能力を優先します。エージェントのピッカー（Claude CodeではAskUserQuestion）を使い、利用できない場合は同じ選択肢をプレーンテキストで提示します。複数の質問をまとめる場合も同じルールに従い、1ラウンドにつき最大4つまでにします。

成果物の所有権

docs/scope/は機能スコープであり、このスキルが所有します。/architectはdocs/specs/を所有します。他のスキルはdocs/scope/をスキャンして、該当する機能の行を見つけます。ドキュメントは継続的に更新します。plan、replan、addはすべて既存ファイルを編集します（内容を整合させて追記し、新しい日付付きファイルは作成しません）。それ以外には何も書き込みません。仕様書、コード、AGENTS.mdは作成しません。docs/scope/にはスコープファイルのみを置きます。インベントリ、分析、調査ドキュメントは、仕様書と同じ場所にあるrationale.mdに置きます（/architectが所有）。

ファイル構成：

• 小規模な製品：docs/scope/scope.mdの単一ファイル（一覧表＋フェーズ別セクション＋凡例）。
• 大規模な製品：エピックごとに分割します。docs/scope/index.md（エピック全体をまとめた一覧表＋エピックごとの1行のステータス概要。各概要からエピックファイルにリンク）と、各エピックにつき1ファイル（領域名を使用。例：docs/scope/auth.md）。
• 必要に応じて昇格します。最初は単一ファイルから始めます。scope.mdがスキャンしやすい範囲を超えたら（明確に異なる領域にまたがる機能がおよそ12個を超えた場合）、index.mdに名前を変更し（表＋エピックごとの概要を残します）、各領域のセクションをそれぞれの<epic>.mdに移します。早すぎる分割は避けてください。名前は意味のあるもの（scope.md／index.md／<epic>.md）にし、番号は付けません。
• すべてのファイルは大まかな内容に絞り、小さく保ちます。エピックファイルが長くなった場合は、機能をより細かくし、意図を明確にします。実装タスクを大量に列挙しないでください。

ステータスのライフサイクル（/scopeが初期ステータスを設定し、パイプラインが進行させます）：

• 新機能はplannedから始めます。ブラウンフィールドの場合は、すでに存在する機能も登録します。完了済みならexisting、一部実装済みならin-progressとします。/scopeが書き込むステータスはこの2つだけです。
• /developはパイプラインで実装した機能を進めます（planned → in-progress → done）。/syncは差分と照合して整合させます。仮定に基づく決定のもとで実装された機能（エンジニアが決定前に実装することを選んだ際に、/developが記録したAssumed状態の仕様書が該当する場合）は、/architectが決定を正式に承認するまで、assumed decision (spec NNNN)という注記を保持します。この注記はdoneを妨げません。これは、正式な承認まで表面化しておく決定上の負債です。
• doneはexistingと同じではありません。doneは、このパイプラインで実装して検証したことを意味します。existingは、ワークフロー開始前から存在していたことを意味します。/developと/syncはexistingの行を変更しません。
• replanでは、スコープから外れた機能をdroppedにできますが、行は削除しません。droppedは履歴として保持され、アクティブな件数と作業から除外されます。/developと/syncはこれをスキップします。

ワークフローのティア（機能ごとに厳密さを調整する設定。Prototype · Alpha · Beta · GA）：各機能にどの程度のプロセスを適用するかを決めます。プロジェクト全体のデフォルトを1つ設定します（推奨。planのStep 5bで一度設定し、スコープのヘッダーにある**Workflow:**行に記録します）。また、機能ごとに上書きできます（見出しの横にタグを付けます。例：· GA。デフォルトと異なる機能に限ります。タグがなければデフォルトを継承します）。ティアによって決まる内容：

• 設計時：ティアが高いほど、Needs spec: yesとなる可能性が高くなり、仕様書のクロスモデル意思決定クリティックが実行されます（GA／Betaでは自動実行）。Prototype／Alphaの機能では、多くの場合Needs spec: noです。
• /developの後（検証の後続工程）：Prototype＝なし（/developのビルド時セルフチェックに依存します）。Alpha＝/check verify。Beta＝/check verify＋/test。GA＝新しいモデルによる/check review＋/documentを追加します。
• doneを完了させる条件（最後に必要なステージで機能を完了とします）：Prototype → /develop（実装＋セルフチェック）、Alpha → /check verify、Beta／GA → /test。Assumed状態の仕様書はdoneを妨げません。すべてのティアで、承認（/architect）が必要な状態としてフラグが保持されます。 /scope は、機能の組み合わせのリスクと規模からプロジェクトのデフォルトを推奨します（ステップ 5b）。これは /architect と /develop が参照するものと同じ情報です。/develop は有効なティア（機能のオーバーライド、なければプロジェクトのデフォルト、どちらもなければ推定値）を参照し、推奨する次のステップの規模を調整します。そのため、Prototype プロジェクトに検証を指示したり、Alpha プロジェクトに完全なレビューの連鎖を指示したりすることはありません。

成果物のベースパス：デフォルトは docs/ です。docs/ が公開ドキュメントサイト（docusaurus.config.*、.vitepress/、mkdocs.yml、Astro Starlight、または Nextra を検出）になっている場合は、.workflow/（.workflow/scope/…）を使用してください。既存のベースパスがある場合は、常にそちらに従ってください（ここに記載のパスは docs/ を前提としています）。

同時実行：セッションやチームメイト間で共有されます。書き込みの直前に再度読み込んでください。編集は必要最小限に留めます（行は順に追加し、変更されたセルを調整し、ファイル全体を書き換えないでください）。予期しない状態を上書きせず、問題として報告してください。追加時は次に空いている番号を使い、追加する人同士で番号が重複しないようにしてください。

参照ファイル

• scope-template.md：書式のルール、「概要」テーブル、機能ごとのセクション（見出し + 意図 + 完了条件 + チェックボックス付きタスク + 参照行）、既存コードベースへの適用およびエピック分割の形式、## /scope complete レポートブロックが記載されています。スコープとレポートを書く際に読み込んでください。

移植性（すべての OS、すべてのエージェント）

macOS、Linux、Windows 上のすべての Agent Skills クライアントが対象です。検出用のスニペットは POSIX を参照しています。エージェントのクロスプラットフォーム対応ファイルツールを使用してください。計画はインラインで実行します。以下の 2 つのサブエージェント（ステップ 1 の既存コードベースのコードスキャン、ステップ 6b の情報源調査）は任意であり、機能を優先して利用し、利用できない場合はインラインで実行します。対話型の選択メニューは使いません。各パネルについて、同じ選択肢をプレーンテキストで尋ねてください。

実行

ステップ 0：意図を推定し、アイデアを確認する

サブコマンドはありません。まず、docs/scope/（成果物のベースパスが .workflow/ の場合は .workflow/scope/）にスコープがあるか確認し、次のように推定します。

• スコープがあり、引数がない（または「reconcile / what's next」として再実行している）→ 再計画の動作（modes/replan.md）。
• スコープがあり、引数が単一の機能を示している → 追加の動作（modes/add.md）。
• まだスコープがなく、プロダクト規模のアイデアがある、または次のスライスを計画している（既存コードベースの場合を含む）→ 以下の計画の動作。

曖昧な場合（新しいスライスか単一の機能か）：スコープから最も可能性の高い解釈を推定し、レポートで選んだ動作を伝えてください。本当に判断できない場合は、確認の質問を 1 行で尋ねてください。

計画の動作でアイデアが与えられていない場合（引数がなく、拡張するスコープもない）：他のことをする前に停止し、次のように尋ねてください。

「何を作ろうとしていますか？計画したいプロダクト、またはそのスライスについて説明してください（何をするもので、誰を対象としているかを 1〜2 文で）。」

回答を待ち、その内容をプロダクトのアイデアとして使用してください。

ステップ 1：推定した動作を読み込む

ステップ 0 で動作を推定した後、モードファイルを 1 つだけ読み込み、その指示に従ってください。

• 計画の動作（新しいスコープ、プロダクト規模のアイデア、または次のスライスの計画）には modes/plan.md。
• 再計画の動作（スコープがあり、引数がない）には modes/replan.md。
• 追加の動作（スコープがあり、引数が 1 つの機能を示している）には modes/add.md。

推定した動作が変わらない限り、他のモードファイルは読まないでください。上記の共通ルールはすべて引き続き適用されます。また、書き込みやレポートの形式を参照する場合は、引き続き scope-template.md を参照してください。