このスキルは、現在の会話コンテキストとコードベースの理解を基に仕様書を生成します。ユーザーにインタビューせず、すでに分かっている知識を統合してください。
イシュートラッカーとトリアージラベルの語彙は、事前に提供されている必要があります。提供されていない場合は、ユーザーに /setup-matt-pocock-skills を実行するよう伝えてください。
プロセス
-
まだ行っていない場合は、コードベースの現在の状態を理解するためにリポジトリを探索します。仕様書全体でプロジェクトのドメイン用語集の語彙を使用し、対象領域に関連するADR（Architecture Decision Records）を尊重します。
-
機能をテストするためのシーム（テスト境界）をスケッチします。既存のシームを優先し、新しいシームは必要最小限にします。最も高い（抽象度の高い）シームを使用してください。新しいシームが必要な場合は、可能な限り高い位置に提案します。コードベース全体のシーム数は少ないほど良く、理想は1つです。
これらのシームがユーザーの期待と一致しているかを確認します。
- 以下のテンプレートを使用して仕様書を書き、プロジェクトのイシュートラッカーに公開します。
ready-for-agentトリアージラベルを適用してください。追加のトリアージは不要です。
問題文
ユーザーが直面している問題を、ユーザーの視点から記述します。
解決策
問題に対する解決策を、ユーザーの視点から記述します。
ユーザーストーリー
ユーザーストーリーの長い番号付きリスト。各ユーザーストーリーは以下の形式とします:
- <アクター>として、<機能>が欲しい。なぜなら<利益>だからだ。
<ユーザーストーリーの例>
- モバイルバンクの顧客として、口座の残高を確認したい。なぜなら、支出に関するより良い情報に基づいた意思決定ができるからだ。 </ユーザーストーリーの例>
このユーザーストーリーのリストは非常に網羅的で、機能のすべての側面をカバーしている必要があります。
実装上の決定
行われた実装上の決定のリスト。以下を含めることができます:
- 構築・修正されるモジュール
- 修正されるそれらのモジュールのインターフェース
- 開発者からの技術的な明確化
- アーキテクチャ上の決定
- スキーマの変更
- APIコントラクト
- 特定のインタラクション
具体的なファイルパスやコードスニペットは含めないでください。すぐに古くなる可能性があります。
例外: プロトタイプが、散文よりも正確に決定を表現できるスニペット（ステートマシン、リデューサー、スキーマ、型の形状など）を生成した場合は、関連する決定内にインラインで埋め込み、プロトタイプから来たことを簡単にメモしてください。動作するデモではなく、重要な部分だけにトリミングしてください。
テスト上の決定
行われたテスト上の決定のリスト。以下を含めてください:
- 良いテストとは何か（実装の詳細ではなく、外部の振る舞いのみをテストする）の説明
- どのモジュールがテストされるか
- テストの先行事例（コードベース内の類似のテストタイプ）
スコープ外
この仕様のスコープ外となる事項の説明。
その他のメモ
機能に関するその他のメモ。