to-spec

このスキルでは、現在の会話のコンテキストとコードベースに関する理解をもとに、仕様書を作成します。ユーザーに質問してはいけません。すでに把握している内容をまとめてください。

課題トラッカーとトリアージラベルの用語集は、すでに提供されているはずです。提供されていない場合は、まず set-up-project スキルを実行してください。

プロセス

1. まだ確認していない場合は、リポジトリを調査してコードベースの現在の状態を把握します。仕様書では、プロジェクトのドメイン用語集を一貫して使用し、変更対象の領域に関する ADR を遵守してください。

2. この機能をテストする接点を検討します。新しい接点より、既存の接点を優先してください。可能な限り高いレイヤーの接点を使用します。新しい接点が必要な場合は、可能な限り高いレイヤーで提案してください。コードベース全体にわたる接点はできるだけ少なくします。理想は 1 つです。

これらの接点が期待に合っているか、ユーザーに確認してください。

3. 以下のテンプレートを使って仕様書を作成し、プロジェクトの課題トラッカーに登録します。トリアージラベル ready-for-agent を付けてください。それ以上のトリアージは不要です。タイトルは docs/agents/issue-tracker.md > 「Title prefixes」に記載された形式にしてください。

ローカルファイルのトラッカーでは、仕様書を .efforts/<effort>/spec.md に保存します。ここで <effort> は effort の名前です（effort がない場合は、機能を表す短いスラッグを使用します）。チケットはその隣の .efforts/<effort>/issues/ に保存します。

問題の説明

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

解決策

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

ユーザーストーリー

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

1. <アクター>として、<メリット>を得るために、<機能>を使いたい

1. モバイルバンキングの顧客として、支出についてより適切な判断を下すために、自分の口座残高を確認したい

このユーザーストーリーの一覧は非常に詳細なものとし、機能のあらゆる側面を網羅してください。

実装の決定事項

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

• 作成または変更するモジュール
• 変更するモジュールのインターフェース
• 開発者による技術的な明確化
• アーキテクチャ上の決定
• スキーマの変更
• API コントラクト
• 具体的なインタラクション

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

例外：プロトタイプで作成したスニペットが、文章よりも正確に決定事項を表現できる場合（ステートマシン、リデューサー、スキーマ、型の形状など）は、該当する決定事項にスニペットを記載し、それがプロトタイプに由来することを簡潔に明記します。動作するデモではなく、決定事項を明確に示す部分だけを抜き出してください。

テストの決定事項

テストに関する決定事項を列挙します。以下を含めてください。

• 優れたテストの条件（実装の詳細ではなく、外部から観察できる振る舞いのみをテストすること）
• テスト対象となるモジュール
• テストの先例（コードベース内の類似テストなど）

対象外

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

補足事項

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