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