📋use-case-specification
- プラグイン
- sagemaker-ai
- ソース
- GitHub で見る ↗
説明
AWSの責任あるAIレンズが推奨する、モデルカスタマイズのためのビジネス上の問題、ステークホルダー、および測定可能な成功基準を定義した再利用可能なユースケース仕様ファイルを作成します。 次のような場合に使用: モデルカスタマイズ計画における最初のデフォルトステップとして使用します。ユーザーが明示的に拒否した場合、またはすでに再利用可能なユースケース仕様が存在する場合にのみスキップしてください。 問題ステートメント、主要ユーザー、およびLLM-as-a-Judgeの成功基準を取得します。
原文を表示
Creates a reusable use case specification file that defines the business problem, stakeholders, and measurable success criteria for model customization, as recommended by the AWS Responsible AI Lens. Use as the default first step in any model customization plan. Skip only if the user explicitly declines or already has a use case specification to reuse. Captures problem statement, primary users, and LLM-as-a-Judge success tenets.
ユースケース
- ✓モデルカスタマイズ計画の初期段階で利用する
- ✓ビジネス上の問題を定義する必要があるとき
- ✓ステークホルダーと成功基準を明確にするとき
- ✓再利用可能なユースケース仕様を作成する
本文(日本語訳)
ユースケース仕様
マルチターンの会話を通じてユースケースの詳細を収集し、ユースケース仕様書を作成します。
原則
- 一度に一つのことを。 各応答では、意思決定の一つを進めるか、情報を一つ収集するかのどちらかに限定します。
- 進める前に確認する。 ユーザーが仕様を承認するまで待ってから、このスキルの完了とみなします。
- 推測する、尋問しない。 会話の中ですでに分かっていることを活用します。どうしても推測できない場合のみ質問します。
- ベースモデルの選択については質問しない。 モデルの選択は、model-selection スキルが専任で担当します。
ワークフロー
ステップ 0: 既存の仕様書の確認
ディスカバリーを開始する前に、プロジェクト内に *_use_case_spec.md ファイルがすでに存在するか確認します。
存在する場合は、ユーザーにその内容を提示し、再利用するか、修正するか、新規作成するかを確認します。
フェーズ 1: ディスカバリー(1〜3 ターン)
これまでの会話ですでに分かっていることを確認し、まだ不明な点を特定します。 以下の三点が必要です:
- What(何を) — ユーザーがモデルカスタマイズによって解決しようとしている問題は何か
- Who(誰が) — ファインチューニング済みモデルを誰がどのような状況で使用するか
- Which(何で測るか) — テストセットにおいてカスタムモデルとベースモデルのパフォーマンスを比較・評価するために使用できる成功基準。成功基準は LLM-as-a-Judge で測定可能なもの(例: 応答精度、トーンの遵守)に限り、レイテンシやスループットなどは対象外とします。
ガイドライン:
- ユーザーがすでに述べた内容からできる限り推測します
- ユーザーが例を示した場合は、それを情報の補完に活用し、改めて質問しません
- フェーズ 2 に必要な情報が推測できない場合のみ、補足の質問をします
- すべてが明確な場合は、「明確な状況が把握できました。ユースケース仕様書をまとめます。」と伝え、フェーズ 2 へ進みます。
⏸ 補足の質問をした後は、ユーザーの回答を待ちます。
フェーズ 2: ユースケース仕様書の作成
- 生成されたすべての成果物は、directory-management スキルで定義されたプロジェクトのディレクトリ構造(利用可能な場合)に保存します。
- ユーザーから収集した情報を統合し、
[relevant_title]_use_case_spec.mdという名前の Markdown ドキュメントを作成します。 このドキュメントには以下のフィールドのみを含めます:
ユースケースの説明
- 簡潔な問題の説明 + カスタムモデルが行うこと
- フィールド名: "Business Problem"
- 型: String
主要なステークホルダー
- モデルを使用する人物とその状況
- フィールド名: "Primary Users"
- 型: String(複数の場合はカンマ区切り)
成功基準
- カスタムモデルの成功を測定するための基準を 3 つリストアップする(短い名称と説明)
- フィールド名: "Success Tenets"
- 型: 名称と説明のペアのリスト
- ユースケース仕様を、以下の形式で人間が読みやすい形式で提示します:
ユースケース仕様書をまとめ、[relevant_title]_use_case_spec.md に保存しました。
ユースケース仕様書は、AWS Responsible AI Lens が推奨するデザイン原則です。
[人間が読みやすい形式のユースケース]
この内容はご意図に沿っていますか?
⏸ ユーザーの承認を待ちます。
use_case_specification 編集プロトコル
- ユーザーが
use_case_spec.mdに含まれる情報に関する変更を要求した場合は、それに応じてファイルを編集し、再度確認を求めます。 - ユーザーが直接
use_case_spec.mdを編集することもできます。ユーザーがファイルを直接更新したと述べた場合は、ファイルを読み込んで最新の内容をコンテキストに反映します。
原文(English)を表示
Use Case Specification
Multi-turn conversation to gather use case details and produce a use case specification document.
Principles
- One thing at a time. Each response advances exactly one decision or collects one piece of information.
- Confirm before proceeding. Wait for the user to approve the spec before considering this skill complete.
- Infer, don't interrogate. Use what's already known from the conversation. Only ask when you truly can't infer.
- Do NOT ask about base model selection. Model selection is handled exclusively by the model-selection skill.
Workflow
Step 0: Check for Existing Spec
Before starting discovery, check if a *_use_case_spec.md file already exists in the project. If it does, present it to the user and ask whether they want to reuse it, modify it, or start fresh.
Phase 1: Discovery (1–3 turns)
Review what is already known from the conversation so far, then identify what is still missing. You need these three things:
- What is the problem the user is trying to solve with model customization
- Who will use the finetuned model and in what context
- Which success criteria can be used to evaluate how well the custom model performs compared to the base model on a test set. Success criteria must be measurable by an LLM-as-a-Judge (e.g., response accuracy, tone adherence) — not things like latency or throughput.
Guidelines:
- Infer as much as possible from what the user has already said
- If the user gave examples, use them to fill gaps rather than asking again
- Only ask clarifying questions when you cannot infer the information needed for Phase 2
- If everything is already clear, say "You've given me a clear picture. I'll put together a use case specification now." and move to Phase 2.
⏸ Wait for user after each clarifying question.
Phase 2: Producing a Use Case Specification Document
- Save all generated artifacts under the project directory structure defined by the directory-management skill, if available.
- Synthesize the information you collected from the user into a Markdown document called [relevant_title]_use_case_spec.md containing the following fields (and only these fields):
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
- Present the use case specification in a human-readable format as follows:
I have put together a use case specification and saved it in [relevant_title]_use_case_spec.md.
A use case specification is a design principle recommended by the AWS Responsible AI Lens.
[use case in human-readable format]
Does this match your intent?
⏸ Wait for user approval.
use_case_specification Edit Protocol
- If the user requests changes pertaining to any information covered by use_case_spec.md, you must edit it accordingly and ask for confirmation again.
- The user can edit use_case_spec.md directly if they want to. If the user says they've updated the file directly, read it to get the latest in your context.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。