to-spec

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

課題トラッカーとトリアージラベルの用語が提供されているはずです。提供されていない場合は、/setup-matt-pocock-skills を実行するようユーザーに伝えてください。

プロセス

1. まだ確認していない場合は、リポジトリを調べてコードベースの現状を把握してください。仕様全体でプロジェクトのドメイン用語集を使用し、対象領域の ADR に従ってください。

2. この機能をテストする接点を洗い出してください。新たに作る接点より、既存の接点を優先してください。可能な限り高いレベルの接点を使ってください。新しい接点が必要な場合は、可能な限り高いレベルで提案してください。コードベース全体にわたる接点は、少ないほど望ましく、理想は 1 つです。

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

3. 以下のテンプレートを使って仕様を作成し、プロジェクトの課題トラッカーに公開してください。ready-for-agent トリアージラベルを付けてください。追加のトリアージは不要です。

この仕様が既存の親課題を具体化するもの（たとえば、会話がエピックから始まった場合や、ユーザーがその参照情報を渡した場合）は、課題トラッカーのドキュメントに記載された方法に従い、公開した仕様を親課題のネイティブなサブ課題としてリンクしてください。これにより、単に本文で言及するのではなく、親課題のサブ課題一覧に表示されます。

問題の概要

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

解決策

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

ユーザーストーリー

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

1. <ユーザーの役割>として、<メリット>を得るために、<機能>を使いたい

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

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

実装上の決定事項

決定済みの実装方針を列挙します。以下を含めることができます。

• 作成または変更するモジュール
• 変更するモジュールのインターフェース
• 開発者からの技術的な補足
• アーキテクチャ上の決定
• スキーマの変更
• API コントラクト
• 具体的な連携方法

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

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

テスト上の決定事項

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

• 優れたテストの条件（実装の詳細ではなく、外部から見える振る舞いだけをテストする）
• テスト対象のモジュール
• テストの先行事例（コードベース内にある類似のテストなど）

対象外

この仕様の対象外となる内容を説明します。

補足

この機能に関する補足事項を記載します。