to-spec

このスキルは、現在の会話のコンテキストとコードベースへの理解をもとに、仕様書を作成します。すでに把握している情報をまとめることを基本とします。このスキルを実行する時点で、たいていは決定が済んでいるため、インタビューをやり直すようなことはしないでください。

本当に必要な場合は質問してかまいません。 質問が必要なのは、会話、コードベース、GLOSSARY.md、ADRから解消できず、そのままではユーザーが決めていないことを勝手に決めることになるような不足がある場合です。その場合は、次のようにしてください。

• 仕様書を書く前に、質問をまとめて一度に行ってください。一つずつ質問しないでください。
• 仕様書の内容を実際に左右する質問だけに絞ってください。
• 各質問には最善の推測も添え、ユーザーがそれを確認するだけで回答できるようにしてください。
• 境界（ステップ 3）は、そのような質問の一つです。最善の推測として提案する境界を質問のまとめに含めてください。それ以外に該当する質問がなければ、境界についてだけ簡潔に尋ねてください。
• その後、仕様書を作成してください。推測して明記できることについて、回答待ちで作業を止めないでください。

該当する不足がなければ、境界については常に、まとめて確認するか、境界だけの質問を一つ行ってから、質問せずに仕様書を作成してください。

プロセス

1. 公開先を決定します。 必ず次のいずれかに決まるため、質問は不要です。公開先を選択肢として提示せず、黙って決定してステップ 4 に引き継いでください。

   1. 今回の実行で GitHub、GitLab、ローカルの Markdown、または別のトラッカーへの公開をユーザーが明示的に求めた場合は、その指定先を使用します。
   2. それ以外の場合で、docs/agents/issue-tracker.md が存在し（/setup-skills によって作成されており）、トラッカーが指定されている場合は、そのトラッカーを使用します。
   3. それ以外の場合は、ローカルの Markdown（.scratch/<feature-slug>/SPEC.md）を使用します。git remote を調べないでください。公開先の選択肢を提示しないでください。

   GitHub または GitLab の場合は、docs/agents/issue-tracker.md があれば、そこに記載された規約とトリアージラベルの対応に従ってください。なければ、以下の <destination-conventions> に従います。これらの規約とトリアージラベルの語彙を設定するには、/setup-skills を実行してください。

2. まだ調べていない場合は、コードベースの現状を把握するためにリポジトリを調べます。仕様書全体でプロジェクトのドメイン用語集の語彙を使用し、対象領域に関わるADRを遵守してください。

3. 機能をテストする境界を検討します。既存の境界を優先し、可能な限り上位の境界を使用してください。新しい境界が必要な場合は、可能な限り上位の境界を提案してください。コードベースをまたぐ境界は、できるだけ少なくします。理想は一つです。

   境界について個別に確認しないでください。前述のとおり、境界はユーザーへの質問をまとめる際に含め、合意した境界を仕様書の「Testing Decisions」に記載してください。

4. 以下のテンプレートを使って仕様書を作成し、ステップ 1 で決定した公開先に公開します。トリアージラベル ready-for-agent を適用してください。追加のトリアージは不要です。ローカルの Markdown の場合、「ラベルの適用」とは、ファイル上部付近に Status: ready-for-agent と記載することを意味します。

• GitHub：gh issue create --title "..." --body "..." を使用します。複数行の本文にはヒアドキュメントを使用してください。トリアージラベルは --label で指定します。
• GitLab：glab issue create --title "..." --description "..." を使用します。複数行の説明にはヒアドキュメントを使用してください。トリアージラベルは --label で指定します。
• ローカルの Markdown：.scratch/<feature-slug>/SPEC.md に書き込み、必要に応じてディレクトリを作成します。ラベルの代わりに、トリアージ状態をファイル上部付近の Status: 行に記録します。

問題の説明

ユーザーの視点から見た、ユーザーが直面している問題。

解決策

ユーザーの視点から見た、問題の解決策。

## ユーザーストーリー

長く、番号付きのユーザーストーリーのリストです。各ユーザーストーリーは、次の形式にしてください。

1. として、できるように、したいです

1. モバイルバンキングの利用者として、支出についてより適切な判断ができるように、自分の口座の残高を確認したいです

このユーザーストーリーのリストは非常に詳細にし、機能のあらゆる側面を網羅する必要があります。

実装の決定事項

決定した実装上の事項のリストです。以下を含めることができます。

• 作成または変更するモジュール
• 変更するモジュールのインターフェース
• 開発者による技術的な補足
• アーキテクチャ上の決定事項
• スキーマの変更
• API コントラクト
• 具体的な相互作用

具体的なファイルパスやコードスニペットは含めないでください。すぐに古くなる可能性があります。

例外：プロトタイプで作成されたスニペットが、文章よりも正確に決定事項を表現している場合（状態マシン、リデューサー、スキーマ、型の構造など）は、関連する決定事項にインラインで含め、プロトタイプから得られたことを簡潔に記してください。動作するデモではなく、決定事項をよく表す重要な部分に絞ってください。

テストの決定事項

決定したテスト上の事項のリストです。以下を含めてください。

• 優れたテストの条件の説明（実装の詳細ではなく、外部から見える振る舞いのみをテストすること）
• 合意した接合点（各項目を箇条書きにすることで、/to-tickets と /tdd が利用できるようにします）
• テスト対象のモジュール
• テストの先行事例（コードベース内の類似した種類のテスト）

対象外

この仕様の対象外となる事項の説明です。

補足

この機能に関するその他の補足事項です。