use-case-specification

ユースケース仕様

複数ターンの会話を通じてユースケースの詳細を収集し、ユースケース仕様書を作成します。

原則

1. 一度に一つ。 各応答では、決定を一つ進めるか、情報を一つ収集します。
2. 進める前に確認する。 このスキルを完了とする前に、ユーザーが仕様を承認するまで待ちます。
3. 質問攻めにせず、推測する。 会話ですでにわかっていることを活用します。本当に推測できない場合に限り、質問してください。
4. ベースモデルの選択について質問しないでください。 モデルの選択は、モデル選択スキルでのみ扱います。

ワークフロー

ステップ 0：既存の仕様書を確認する

情報収集を始める前に、プロジェクト内に *_use_case_spec.md ファイルがすでに存在するか確認します。存在する場合は、ユーザーに提示し、再利用、変更、新規作成のいずれを希望するか尋ねます。

フェーズ 1：情報収集（1～3 ターン）

これまでの会話ですでにわかっていることを確認してから、不足している情報を特定します。次の 3 点が必要です。

• 何を解決するために、ユーザーはモデルのカスタマイズを行うのか
• 誰がファインチューニング済みモデルを、どのような状況で使用するのか
• テストセットでカスタムモデルの性能をベースモデルと比較する際、どのような成功基準で評価するのか。成功基準は、LLM による評価で測定できるもの（例：回答の正確性、トーンへの準拠）である必要があります。レイテンシやスループットなどは該当しません。

ガイドライン：

• ユーザーがすでに話した内容から、できる限り多く推測します
• ユーザーが例を挙げている場合は、再度質問するのではなく、不足情報の補完に活用します
• フェーズ 2 に必要な情報を推測できない場合に限り、確認の質問をします
• すべて明確な場合は、「必要な情報は十分に把握できました。ユースケース仕様を作成します。」と伝えて、フェーズ 2 に進みます。

⏸ 確認の質問をした後は、ユーザーの返答を待ちます。

フェーズ 2：ユースケース仕様書の作成

1. 利用可能な場合は、ディレクトリ管理スキルで定義されたプロジェクトのディレクトリ構成に従い、生成したすべての成果物を保存します。
2. ユーザーから収集した情報をまとめ、以下の項目のみを含む [relevant_title]_use_case_spec.md という Markdown ドキュメントを作成します。

Use case description
  - Concise problem statement + what the custom model will do
  - Field name: “Business Problem”
  - Type: String

Key stakeholders
  - Who uses the model and in what context
  - Field name: “Primary Users”
  - Type: String, comma separated if there are multiple 

Success criteria
  - A list of 3 criteria (a short name and a description) with which the user measure the success of the custom model. 
  - Field name: “Success Tenets”
  - Type: list of name-description pairs

1. ユースケース仕様を、次のような人が読みやすい形式で提示します。

ユースケース仕様を作成し、[relevant_title]_use_case_spec.md に保存しました。

ユースケース仕様は、AWS Responsible AI Lens が推奨する設計原則です。

[人が読みやすい形式で記述したユースケース]

これは意図と一致していますか？

⏸ ユーザーの承認を待ちます。

use_case_specification の編集プロトコル

• ユーザーが use_case_spec.md に記載された情報の変更を依頼した場合は、それに応じてファイルを編集し、再度確認を求めます。
• ユーザーは必要に応じて use_case_spec.md を直接編集できます。ユーザーからファイルを直接更新したと伝えられた場合は、最新の内容を読み込み、コンテキストに反映します。