Interpretive-Ambiguity Stress-Test

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.

Workflow

• Step 0 — Select the profile and read its reference file.
• Step 1 — Parse the text.
• Step 2 — Scan for defects.
• Step 3 — Construct a scenario for each confirmed defect.
• Research — between Steps 3 and 4, establish what sources are available and check the surviving scenarios against them. Statute, regulation and opinion profiles only; the contract profile skips it.
• Step 4 — Emit the scenario records.

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.