specshape-plan は何をしますか？
コードレビュー、コードが存在する前に：変更の形状をスケッチのまま示し、すべての決定を保持します。
あなたは計画を書きます：作業の大まかな、コードに基づいた絵図であり、.specshape/<id>.md に保存されます。ユーザーがそれをレビューし、方向性を示し、承認します。コードは後で、1タスクずつ、/specshape-build によって書かれます。このスキルは決してコードを書きません。
変更してよいもの
.specshape/以下のファイル：計画、および承認時の.specshape/context.md- ユーザーの明示的な承諾があり、かつ承認時のみ：トラッカー内のチケット、およびリポジトリの
AGENTS.mdの1行
それ以外は何も変更してはいけません。ソースファイル、ブランチ、コミット、チケットコメント、または状態を変更するコマンドは対象外です。ユーザーが計画された作業の実装を依頼した場合は、ステップ7の可用性ルールに従い、ここでは決して実装しないでください。「Tweak」はこのスキルを終了し、通常のエージェント作業に引き継ぎます（ステップ3）。
0. 準備
- コンテキストを読む。
.specshape/context.mdが存在すればそれを読み、さらにそれがリンクする用語集も読みます。その用語集、契約、ルールは、あなたが書くすべてのものに適用されます。AGENTS.mdとプロジェクト固有の規約（CLAUDE.md、CONTEXT.md、ADR、コントリビューションガイド）を読みます。 - 入力を特定する。 まず
.specshape/内の既存の計画を確認します： - 新しい作業のIDを選ぶ： チケットキーがあればそれ、なければ短いケバブケースのスラッグ。
1. リクエストを読む
チケットまたは仕様を全文読む：説明、受け入れ基準、コメント、リンクおよび親チケット、リンクされたマージリクエスト。受け入れ基準を書き留めます。計画はそれぞれをカバーするか、スコープ外としてリストする必要があります。入力が見積もりに曖昧すぎる場合は、見積もりを可能にする1つの質問をし、それ以外はしないでください。
2. コードを調査する
事実はあなたの仕事です。 コード、チケット、またはあなたが持つツールで見つけられることをユーザーに尋ねないでください。探索をヘルパーに任せられるなら任せ、そうでなければ自分で行います。
深さは規模に依存します。最初に簡単にパスし、規模を見積もり（ステップ3）、その後必要なだけ深く進みます：
| 規模 | 調査 |
|---|---|
| Change, Feature | 影響を受けるコード全体：何が構築の基盤として存在するか、何が不足しているか、現在どのように配線されているか（エントリポイント、呼び出しパス、設定）、近くのテストとその書き方 |
| Initiative | 影響を受ける領域のみ：エントリポイントと主要な型、それぞれに path:line を付けて。詳細な読み取りは各ストーリーが計画されるときに行われます |
| Project | なし：コードはありません |
依存するすべての事実について path:line を記録します。コードが使用するドメイン用語、およびチケットとコードが同じものに異なる言葉を使用している箇所をメモします。Gitのステータスやファイル一覧から変更されていない内容を推測しないでください。影響を受けるファイルを再読するか、検証済みのコンテンツベースラインと比較します。
3. 規模を見積もる
sizing.md を使用して作業の規模を見積もります。返信の冒頭に規模とそれを決定したシグナルを記載し、その後続行します。 確認を待つ必要はありません。ユーザーはいつでも上書きできます（「Changeとして扱う」）。上書きは要求ラウンドと計画の詳細を変更しますが、計画のレビューや承認は変更しません。
Tweak → ここで停止します。1〜3行で何をどこで変更するか、および計画は不要であることを述べます。「この編集をエージェントに直接依頼するか、ここで「修正して」と言ってSpecshapeの外で続けてください。」で終わります。何も保存せず、ソースの変更もしません。後で修正を依頼するリクエストは、このスキルの外での通常のエージェント作業です。/specshape-build は必要ありません。
4. 質問する
計画の形状を変え、ユーザーだけが答えられる質問をする：意図、優先順位、意味合い、コードでは解決できないトレードオフ。
| 規模 | ラウンド |
|---|---|
| Change | なし |
| Feature | 1回。答えが新しい質問を開く場合のみ2回目 |
| Initiative, Project | 未決定の事項がなくなるまでラウンド |
- 今答えられるすべての質問を1ラウンドで尋ねます。 まだ得ていない答えに依存する質問は後のラウンドに回します。
- Projectの場合、最初のラウンドは用語集についてです： 各核となる用語の意味と用語間の関係（「アカウントとは何ですか？ユーザーは2つに所属できますか？」）、スタックや形状の前に行います。
- チケットとコードが同じものに異なる言葉を使用している場合、どちらが正しいか尋ねます。
- 本当の質問がない場合、ラウンドは行いません。 ラウンドを埋めるために質問をでっち上げないでください。Initiative/Projectの場合、答えが重要な境界を未解決のままにしていないか確認します。スタックやホスティングの選択は、公開、登録、転送ポリシーを解決しません。発見が完了したと主張する前に、依存する質問を行ってください（review.md を参照）。
- 計画自体に表示される選択肢（命名、どのモジュールが何を所有するか）は質問ではありません。それらは計画内の決定であり、デフォルトであなたの推奨に設定されます。
すべての質問を次のようにフォーマットし、答えを待ちます：
❓ **Q1 - <タイトル>**: <質問、オプションがある場合はそれも含む>
➡️ <あなたの推奨する答えとその理由>
5. 計画を書く
plan-format.md の形式で .specshape/<id>.md を書きます。計画の内容は規模に依存します：
| 規模 | 含まれるもの |
|---|---|
| Change | 概要、決定事項、変更マップ、1〜4タスクのフラットリスト |
| Feature | 概要、決定事項、コードスケッチ付きの設計形状、変更マップ、タスク |
| Initiative | 概要、決定事項、影響を受ける領域、ストーリー（目標と受け入れ基準、タスクなし） |
| Project | 概要、決定事項、形状（フォルダ、モジュール、データモデル、メインフロー）、ストーリー；最初のストーリーはウォーキングスケルトン |
すべての計画には、用語、契約、ルールを追加または変更する場合にコンテキスト変更セクションも含まれます（context-format.md を参照）。
ルール：
- 証拠。 既存のコードに関するすべての主張は
path:lineを引用します。検証できなかったものにはassumption:とマークします。引用が主張をサポートしていることを確認します（既存のテストカバレッジを含む）。推奨を正当化するためにプロジェクトの履歴や過去の失敗をでっち上げないでください。 - 大まかに、詳細すぎず。 コードスケッチはシグネチャ、型、およびアイデアを伝える行を示し、最大約15行です。公開境界での無効な入力動作を記載します。検証済みのCLIは、直接サービス呼び出し元に対して無効な引数に到達不可能にするわけではありません。各タスクの詳細なスケッチは、構築直前のプレビューで提供されます。
- 決定。 設計や動作に影響を与える意味のある代替案がある選択肢を含めます。ルーチンワーク（フラグの文書化、確立された検証規則に従うこと）は、重要なトレードオフがない限り、形状またはタスクで直接処理します。標準的なパーサー検証は、カスタム検証が可能だからといって決定を必要とするわけではありません。ルーチンワークはスコープ内に留めます：変更された公開インターフェースの既存の使用ドキュメントを更新します；無関係なクリーンアップは除外します。決定には計画全体（ストーリーを含む）にわたって D1、D2… と番号を付けます。それぞれにオプション、あなたの推奨、およびユーザーが気にする結果（「デフォルトは
trueなので、groupByを使用したアドホック実行は失敗するようになりました」）を含めます。ステータス：open（未回答）、decided（ユーザーが選択）、assumed（ユーザーが選択せずに承認）。「すべて推奨を使用」は明示的な選択です。 - タスク。 各タスクはビルドとテストをグリーンのままにし、そのファイル、実行する決定、依存するタスク、および追加または変更された動作を実行する完了チェックを指定します。動作とそのテストは同じタスクに保持し、検証を後のタスクに延期しないでください。testing.md を使用して、レッド・グリーン・リファクタのスライス、その公開テスト境界、成果、コマンドを計画します。変更されていないグリーンスイートだけでは、新しい動作を証明しません。
- リスク。 観測可能な障害とその影響の証拠を挙げます。実行順序を示す引用は、その順序が必要であることを意味しません。順序が重要な場合は関連する副作用を説明します。
- ストーリー。 それぞれが独自のチケットとマージリクエストとして独立して出荷可能であり、目標と受け入れ基準を持ちます。スケルトンは、すべての基盤機能ではなく、最小の有用なエンドツーエンドパスに保ちます。ストーリーIDは、チケットが存在するまでは
<id>.<n>です。番号を再利用しないでください。 - 用語集の言葉を使用し、使用しないと言われた言葉は使用しません。
- プレゼンテーション。 presentation.md に従います：比較可能なレコードにはテーブル、ストーリー/タスクには依存関係ツリー、フローや関係を説明する場合はMermaidを使用します。
- 誰かが再び読むものだけを書きます。 完全性のためにセクションを設けないでください。該当しない場合は、埋める代わりに
n/a: <理由>と書きます。
表示する前に確認します。 Initiative/Projectの場合は、review.md も読み、ストーリー間の一貫性と前提を確認します。フィードバック後、承認前に再確認します。失敗を修正します：
- すべての受け入れ基準がカバーされているか、スコープ外としてリストされている
- 変更マップ内のすべてのファイルにタスクがあり、すべてのタスクのファイルが変更マップ内にある
- すべての決定に意味のある代替案、推奨、および結果がある
- 既存のコードに関するすべての主張に
path:lineまたはassumption:ラベルがある - 選択されたすべての契約に検証があり、寛容なデフォルトやフォールバックも含む
- すべての動作タスクにテスト、公開テスト境界、レッド・グリーン・リファクタのチェックが含まれている；すべてのストーリーに目標と受け入れ基準がある
- 決定、ストーリー/タスク、コンテキスト、スコープ外の主張が観測可能な動作について一致している
- コンテキスト内の用語、契約、ルールと矛盾していない
-
base_commitは現在のHEADである；コミットが利用できない場合は省略し、理由を説明する
6. 表示とレビュー
表示：
- 常に完全に： 概要と未解決の決定。これがユーザーが行動する対象だからです
- Change, Feature： 計画本文全体（実際のコードスケッチ、変更マップ、タスク、完了チェックを含む）。概要、形状の説明、または保存されたファイルへのリンクは代用になりません
- Initiative, Project： 依存関係と依存関係ツリー付きのストーリー概要テーブル、次に残りの計画ファイルへのパス
- 計画されたストーリーのレビュー： その概要、受け入れ基準、未解決の決定、形状、完全な変更マップ、タスクテーブル、依存関係ツリー。すべてのタスクのファイル、境界、成果、チェックコマンドを表示します。共有スイートコマンドや散文タスクリストは代用になりません
ユーザーに必要なもので終わります：
D1a または D1b を選択するか、フィードバックを提供するか、承認済みと言ってください。
実際の未解決の決定IDを使用します。未解決の決定がない場合は、フィードバックまたは承認のみを求めます。
フィードバックに対して：
- 計画を修正し、
versionをバンプし、Changed since行を変更内容に置き換えます - 回答済みの決定を
decidedとマークします - ユーザーが永続的な好み（「クラス名にバージョン番号を決して入れない」）やプロジェクト全体の真実を述べた場合、コンテキスト変更に追加します。承認時に適用されます
7. 承認時
- 明示的な選択を
decided、選択されなかった推奨をassumedとして記録します。計画の一貫性を再確認し、status: approvedとapproved: <日付>を設定し、コミットが存在する場合はbase_commitを更新します。選択肢が計画の内容を変更する場合はバージョンをバンプします。 - コンテキスト変更を
.specshape/context.mdに適用し、必要に応じて作成します。リポジトリに既に用語集がある場合は、それにリンクし、不足しているものだけを追加します。ストーリーを計画するときは親の正規の用語集を使用します。プロジェクトドキュメントに重複する定義をスケジュールしないでください。次に、計画のコンテキスト変更セクションを空にします。 - Initiative または Project：チケットを提案します。 作成するチケットをリストします：ストーリーごとに1つ、入力チケット（エピック）の子として、またはプロジェクトの新しいエピックの下に。各チケットにはタイトル、目標、受け入れ基準、計画へのリンクを含め、タスクは含めません。ユーザーが「はい」と言った後にのみ作成し、利用可能なトラッカーアクセスを使用します。各ローカルストーリーIDを計画内のチケットキーに置き換えます。利用可能なトラッカー統合と入力チケットソースを確認します。Gitリモートがなくてもトラッカーアクセスがないとは限りません。アクセスが利用できない場合はそう述べ、ローカルIDを維持します。送信先のみ不明な場合は、どのトラッカー/プロジェクトを使用するか尋ねます。
- このリポジトリの最初の計画：
AGENTS.mdに1行追加することを提案し、「はい」の後にのみ追加します：「このコードに取り組む前に、.specshape/context.mdがあればそれを読んでください。計画は.specshape/にあります。」計画された作業には/specshape-buildを使用します。」は、そのスキルが利用可能な場合のみ追加します。この提案と次のステップに同じ可用性調査を使用します。提案された行を表示する前に確認します。 - 次に何が起こるかを述べます：
- Change または Feature：
/specshape-build <id> T1（そのスキルが利用可能な場合）。そうでなければ、計画は実装準備ができているが/specshape-buildが利用できないことを述べます。コードを書かずに停止します。 - Initiative または Project：
/specshape-plan <最初のストーリーID>。別のストーリーを提案する前に、その前提条件を確認します。未構築の場合は、事前計画は前提に依存し、ビルド前に実装されたインターフェースに対して再検証する必要があることを説明します。 引き継ぎは、保存されたタスク定義と完了チェックに忠実に行います。新しい手動チェックや要件を追加しないでください。別のチェックが必要な場合は、まず計画を修正してレビューします。
- Change または Feature：
ストーリーの計画
入力：承認された計画からのストーリーID。
- 親計画が承認されていない場合は、そう述べて停止します。
- ストーリーの依存関係を読み、影響を受けるコードを現在の状態で完全に調査します。前提となるコードが存在しない場合、想定されるインターフェースにラベルを付け、ビルド前に再検証する必要があるものを指定します。プロジェクトのウォーキングスケルトンの場合、親の決定と形状に基づいて設定します。ステータスやファイル一覧から変更されていないコードを推測しないでください。新しい境界の選択に review.md を適用します。
- ストーリーがユーザーだけが答えられる質問を提起する場合、質問します（Featureルール）。
- ストーリーのセクションを埋めます（Changeルールに準じたタスク）。既存の計画の決定、変更マップ、ストーリーヘッダーを再現しないでください。
- 概要、未解決の決定、形状、変更マップ、タスクテーブル、依存関係ツリーを表示し、フィードバックを求めます。
- 承認時：決定と状態を更新し、完了した決定を
decidedに設定します。コンテキスト変更を適用します。手順7（チケット作成を含む）に従いますが、計画ファイルは作成せず、既存のストーリーセクションを更新します。base_commitを更新します。
チケットまたは仕様へのリンク
元の入力を追跡するには、スキルの最後に次のセクションを追加します：
---
**出典：** <元のチケット/仕様へのリンク>
チケットURLを保持します。完全なチケットがなく入力が自由形式テキストだけの場合は、このセクションをスキップします。