Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →lawve-ai/ambiguity-stress-test
Adversarially stress-tests a legal text — a contract, statute, regulation, or judicial opinion — for interpretive ambiguity: it finds the seams where the people governed by it will later disagree about what it means and turns each into a concrete dispute scenario with both sides' arguments, the likely outcome, and a fix.
Passed 15 of 22 test cases with the skill, and 6 of 22 without it.
and 12 more in the full report
10 fixed5 passed either way6 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
I have attached a commercial software licensing agreement that we are preparing to sign with an enterprise customer. Please perform an adversarial ambiguity audit on this agreement to find edge cases where we and the client might interpret the language differently. For each issue, output a record containing: a short title summarizing the issue, a brief 3-to-6 sentence real-world dispute scenario detailing the event and both parties' opposing arguments, the specific clause citations, a brief statement of the textual vulnerability, a predicted court outcome under contract law principles, and recommended replacement wording that closes the gap. Finish the output with a statement describing the research basis used.
| Checked | Without skill | With skill |
|---|---|---|
| Includes the defect_family field in every output record | Missed | Passed |
| Concludes with a single-line sources note stating the instrument was read on its own terms with no research step applied | Missed | Passed |
The instructions your model reads when the skill loads.
Adversarially stress-test a legal text for the places where the people governed by it will later disagree about what it means. For each weak seam, produce a concrete dispute scenario: a realistic fact pattern, both sides' arguments, the likely outcome, and a fix. The text can be a contract, a statute, a regulation, or a judicial opinion.
The skill rests on one principle — generalize the detector, keep the resolver modular. The machinery that finds ambiguity (parse, scan, construct an edge-case scenario, frame two plausible readings) is the same for every legal text. The machinery that resolves it is not: contract ambiguity is settled by recovering the parties' bargain, statutory ambiguity by the canons of construction, regulatory ambiguity by the canons plus the enabling act, and a judicial opinion's by the doctrines of precedent. So the skill has a general core (this file) and four domain profiles (in resources/). Run the core; load the one profile that matches the document.
The product is disputes, not flags. A linter says "this term is vague." This skill instead invents the two people who would each, plausibly, win if their reading prevailed — and the money or liberty riding on the answer. A latent ambiguity is invisible to a non-specialist until someone shows them the collision it will cause.
Steps 1–4 are the engine, identical across profiles. The profile supplies the domain-specific defect families, a lexicon, the competing interpreters, the doctrines that drive the likely outcome, the redraft register, and any quality-bar adjustment.
Identify the document type and read the matching reference file before scanning:
| Document | Profile file |
|---|---|
| Contract, agreement, lease, NDA, employment offer, policy, terms of service | resources/contract.md |
| Statute, code section, ordinance, enacted bill | resources/statute.md |
| Regulation, agency rule, administrative code provision | resources/regulation.md |
| Judicial opinion, court decision, or a draft opinion | resources/opinion.md |
If the text is some other normative document (a will, a treaty, an insurance policy, a set of bylaws), run the nearest profile and state plainly which interface elements do not fit. If the input mixes types — a statute and the regulation under it, say — run each through its own profile and also look across the link.
Segment the text into addressable units and build four working lists: every defined term; every operative provision (a right, duty, or power — "shall," "may," "is entitled to"); every trigger or condition ("if," "provided that," "upon," "in the event of"); and every grant of discretion or unilateral power.
For statutes and regulations, also extract every cross-reference to another instrument — the most serious defects live in those links. For a judicial opinion, also map the structural parts — holding, supporting reasoning, dicta, disposition, and any separate opinions — because an opinion's operative rule is latent and must be reconstructed before it can be tested.
test cases passed, vs 6 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.