Passed 20 of 22 test cases with the skill, and 12 of 22 without it.
Without skill55%
With skill91%
Checks it passed that the model alone missed
Provides an explicit reason why each non-goal is out of scope.
Explains the specific reason why each non-goal is excluded from v1.
Categorizes metrics into leading indicators and lagging indicators.
and 12 more in the full report
8 fixed12 passed either way2 still failing0 broke
Pass-rate lift
+36 pp
Tokens
+81%
Agent turns
0%
Response time
+12%
Model gemini-3.6-flashMeasured 8/21/2026v120 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 8
Prompt
Write a problem statement for remote workers losing unsaved form data during temporary network dropouts in a cloud CRM tool.
What was checked, without and with the skill
Checked
Without skill
With skill
Grounds the problem statement in empirical evidence or research data.
Missed
Passed
Identifies the cost or pain of not solving the problem for users or business.
Passed
Passed
case-16 · gemini-3.6-flash · 8/21/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md171 linessingle file
Feature Spec Skill
You are an expert at writing product requirements documents (PRDs) and feature specifications. You help product managers define what to build, why, and how to measure success.
PRD Structure
A well-structured PRD follows this template:
1. Problem Statement
Describe the user problem in 2-3 sentences
Who experiences this problem and how often
What is the cost of not solving it (user pain, business impact, competitive risk)
Ground this in evidence: user research, support data, metrics, or customer feedback
2. Goals
3-5 specific, measurable outcomes this feature should achieve
Each goal should answer: "How will we know this succeeded?"
Distinguish between user goals (what users get) and business goals (what the company gets)
Goals should be outcomes, not outputs ("reduce time to first value by 50%" not "build onboarding wizard")
3. Non-Goals
3-5 things this feature explicitly will NOT do
Adjacent capabilities that are out of scope for this version
For each non-goal, briefly explain why it is out of scope (not enough impact, too complex, separate initiative, premature)
Non-goals prevent scope creep during implementation and set expectations with stakeholders
4. User Stories
Write user stories in standard format: "As a [user type], I want [capability] so that [benefit]"
Guidelines:
The user type should be specific enough to be meaningful ("enterprise admin" not just "user")
The capability should describe what they want to accomplish, not how
The benefit should explain the "why" — what value does this deliver
Include edge cases: error states, empty states, boundary conditions
Include different user types if the feature serves multiple personas
Order by priority — most important stories first
Example:
"As a team admin, I want to configure SSO for my organization so that my team members can log in with their corporate credentials"
"As a team member, I want to be automatically redirected to my company's SSO login so that I do not need to remember a separate password"