Passed 18 of 23 test cases with the skill, and 5 of 23 without it.
Without skill22%
With skill78%
Checks it passed that the model alone missed
The output references SQL safety checklists.
The output references the LLM trust boundary checklist.
The Source column includes line numbers for file paths.
and 19 more in the full report
14 fixed4 passed either way4 still failing1 broke
Pass-rate lift
+57 pp
Tokens
+50%
Agent turns
0%
Response time
+0%
Model gemini-3.6-flashMeasured 10/10/2026v518 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 14 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 14
Prompt
The term 'Order' means an unfulfilled shopping cart in `checkout/cart.py`, but in `warehouse/fulfillment.go` it means an approved physical shipment request. Merge these into a single global unified definition for our team and output a single term definition.
What was checked, without and with the skill
Checked
Without skill
With skill
The output maintains distinct definitions for each bounded context.
Missed
Passed
The output defines boundary translation logic between contexts.
Missed
Passed
case-06 · gemini-3.6-flash · 10/10/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md79 lines3 filesincludes scripts
Domain
Two independent uses: vocabulary work makes a term, name or
rule boundary precise enough for acceptance examples, code and conversation; a
standards lookup finds the language, data-format, risk or
test-design standard for a change. Neither needs the other. Plan
owns unified discovery and resumption; Domain resolves only the needed
vocabulary or rule boundary and returns it to the existing intent.
Vocabulary work
Cite the existing owner. Find the vocabulary owner in the caller's
instructions, domain docs or contracts and read only the relevant terms. A
lookup is read-only. With no owner, label each definition as observed in
code or proposed.
Keep one meaning per bounded context, the area where a term has one
agreed meaning and an owner for its rules. When a word crosses contexts,
name each meaning and the translation at the boundary instead of imposing
one global definition.
Report code that disagrees with intent. Identify the actor, state,
operation and observable result the term denotes, then compare the intended
meaning with callers, types and tests. A mismatch is a finding to resolve:
renaming code does not add missing behavior, and redefining the term to
match the code hides the defect.
Price renames of shared names. Exported names, serialized fields, stored
values and API payloads need compatibility work (migration, versioning,
client updates), not a cosmetic replacement. Keep naming changes within
authorized scope.
Distinguish with an example. Separate competing meanings with a concrete
case; express a branching boundary as Given/When/Then and reuse it in
implementation and validation. Use the settled term in scenario names,
operations, types and documentation. Ask only when an unresolved
distinction would change behavior or ownership; a lookup needs no interview.
Update the owner; add no glossary by default. When refinement is
authorized, update the existing owner with the meaning, context and example,
keeping useful aliases as explicit translations. Without an owner, return
the proposal in the caller's intent or conversation rather than creating a
new glossary file.
Return vocabulary work in this shape, then stop once the next change can be