to-spec

このスキルは、現在の会話コンテキストとコードベースの理解を使って仕様書を作成します。ユーザーにインタビューしてはいけません。すでに把握している情報だけをまとめてください。

Issue tracker と triage label の語彙は、すでに提供されているはずです。提供されていない場合は、ユーザーに /setup-matt-pocock-skills を実行してもらってください。

手順

1. まだリポジトリを調査していない場合は、まず調査してコードベースの現在の状態を把握します。仕様書では常にプロジェクトのドメイン用語集の語彙を使用し、関連する ADR に従ってください。

2. この機能をどの seams でテストするかを下書きします。新たに seams を追加するより、既存の seams を優先してください。可能な限り高いレベルの seam を使用します。seams を新たに追加する必要がある場合は、可能な限り高いレベルで提案してください。

seams は少ないほどよく、理想的には 1 つです。これらの seams が想定どおりか、ユーザーに確認してください。

3. 以下のテンプレートを使って仕様書を作成し、プロジェクトの issue tracker に公開します。ready-for-agent triage label を適用してください。追加の triage は不要です。

問題の説明

ユーザーが直面している問題を、ユーザーの視点から説明します。

解決策

問題の解決策を、ユーザーの視点から説明します。

ユーザーストーリー

番号付きのユーザーストーリーを詳細に列挙します。各ユーザーストーリーは、次の形式に従ってください。

1. As an , I want a , so that

1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending

このユーザーストーリーの一覧では、機能のあらゆる側面を十分に網羅してください。

実装上の決定事項

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

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

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

例外：プロトタイプで作成したスニペットが、ある決定事項を散文よりも正確に表現している場合（ステートマシン、reducer、スキーマ、型の形状など）、該当する決定事項にインラインで含め、そのスニペットがプロトタイプ由来であることを簡潔に説明できます。決定事項が密に表現された部分だけを残し、動作するデモ全体は含めないでください。

テスト上の決定事項

すでに行われたテスト上の決定事項を列挙します。以下を含めてください。

• 優れたテストの説明（実装の詳細ではなく、外部動作のみをテストすること）
• テスト対象となるモジュール
• 既存の類似テストなど、コードベース内の参考例

対象外

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

補足事項

機能に関するその他のメモを記載します。