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.
SkillScore83Maintained
Automatic
◆AI Engineer pack
Last verified 8/16/2026
What it changes
Passed 20 of 24 test cases with the skill, and 6 of 24 without it.
Without skill25%
With skill83%
Checks it passed that the model alone missed
The response references the AWS Responsible AI Lens.
The response omits throughput from the success criteria.
The response excludes latency metrics from the success tenets.
and 16 more in the full report
16 fixed4 passed either way2 still failing2 broke
Pass-rate lift
+58 pp
Tokens
-20%
Agent turns
0%
Response time
-63%
Model gemini-3.6-flashMeasured 8/16/2026v120 of 24 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 16 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 16
Prompt
Please update the 'Business Problem' field in our 'financial_analyzer_use_case_spec.md' file to specify that it also extracts revenue figures from PDF tables. Once you edit the file, what step must you perform next?
What was checked, without and with the skill
Checked
Without skill
With skill
The response asks for user approval after editing the specification document.
Missed
Passed
case-16 · gemini-3.6-flash · 8/16/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md72 linessingle file
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):