Rohas Legal AI: Verify

View saved version →

---
name: adversarial-reviewer
description: Attacks a finished draft the way opposing counsel, a skeptical judge, or a regulator would — hunting for exploitable ambiguity, gaps, internal inconsistency, and unsupported assertions, and writing out the strongest counter-argument to the document's own conclusions. Use this as a final stress test before a document goes out — including phrasings like "attack this draft before we send it", "what would opposing counsel do with this", "poke holes in this opinion", "find the weakest point in this pleading", or "red-team this before we file it". It finds problems; it does not fix them — hand off to the relevant drafting or redline skill for that. Fires on any finished draft in any practice area — contracts, pleadings, opinions, notices.
---

# Adversarial Reviewer

## What this does

Reads a finished draft and attacks it, deliberately adopting the perspective of whoever is positioned against it — opposing counsel, a skeptical judge, a regulator — rather than reviewing it neutrally. It hunts for exploitable ambiguity, gaps a well-prepared opponent would notice, internal inconsistency, and assertions the document makes without support, and writes out the strongest counter-argument to the document's own main conclusions. It does not fix what it finds; that is a different skill's job.

## Before you start

**The draft itself.** The finished document to attack. Blocking — there is nothing to stress-test without it.

**Who the adversarial perspective belongs to.** The actual counterparty's counsel, a skeptical judge or tribunal, a regulator, an auditor. This is blocking — an attack has to come from someone specific, since what counts as a weakness shifts depending on who is looking for one. Ask if it is not obvious from the document.

## Method

**1. Read the whole draft once before attacking anything.** Understand the document's overall structure and logic first; an attack constructed clause by clause on a first pass misses how weaknesses in different places compound each other.

**2. Restate the adversarial perspective explicitly before starting** — who is attacking, and what they want. A generic attack is a weak attack; a specific one, from a specific adversary with a specific interest, finds real problems.

**3. Hunt for exploitable ambiguity.** Any clause, sentence, or term capable of more than one reading — and for each, take the reading that is worst for the document's own side, not the intended one. State the exploit specifically: what the adversary would argue this actually means.

**4. Hunt for gaps and omissions.** What a well-prepared opponent would notice is simply not addressed — a scenario left uncovered, a right not reserved, a term used but never defined. Omissions are often more damaging than anything stated badly, because there is nothing on the page to argue against them with.

**5. Hunt for internal inconsistency.** Anything that contradicts something else in the same document. An opponent will use one part of the document against another; find those pairs before they do.

**6. Test every factual or legal assertion for whether it is actually supported within the document**, and flag anything merely asserted. An opponent will demand support for anything stated without it.

**7. Write out the strongest counter-argument to each of the document's main conclusions, in the adversary's own voice** — not "this could be attacked" but the actual argument, as the adversary would make it.

**8. Rank the vulnerabilities found and identify the single weakest point in the document.** A list of many weaknesses without a ranking tells the user everything is equally urgent, which is rarely true and wastes limited time fixing the wrong thing first.

**9. Stop at the attack.** Do not draft a fix, a redline, or an amended clause — flag the vulnerability and point to the skill built for repairing it.

## Output

**1. Header.** Document type, the adversarial perspective adopted, date.

**2. Attack summary.** The two or three most damaging lines of attack, in one paragraph, before any detail.

**3. Vulnerabilities.** A table: Location | Vulnerability | How it would be attacked | Severity.

**4. Gaps and omissions.** What is simply missing that the adopted adversary would notice.

**5. Strongest counter-arguments.** The adversary's best version of the case against the document's main conclusions, written out in full, not summarised.

**6. Single biggest weakness.** One clear sentence naming the most exploitable point in the whole document.

**7. Recommended next step.** Which skill or process should fix what was found — this skill does not draft the fix itself.

## Do not

Do not soften the attack to spare the drafter. The entire value of this skill is genuine adversarial rigor; a gentle version of it is worthless.

Do not fix the problems found. Flag them and hand off to a drafting or redline skill.

Do not invent a fact the document is silent on in order to attack it. Work from the ambiguity, gaps, and inconsistency actually present, or clearly label a hypothetical as a hypothetical.

Do not produce a balanced or neutral review here. That is a different skill's job; this one specifically wears the adversary's hat throughout.

Do not limit the search to what the user has already flagged as a concern. The point is to find what they have not thought of.

Referenced files: 1

View saved version →

---
name: assumption-flagger
description: Surfaces every assumption a draft depends on — factual, legal, definitional, about another party's future conduct, or about scope — whether the document states them or not, so they can be verified or challenged before anyone relies on it. Use this as an independent audit pass on any document — including phrasings like "what is this opinion actually assuming", "surface every assumption in this risk assessment", "what would have to be true for this conclusion to hold", "audit this draft for unstated premises", or "check what this document is taking for granted". Works on documents from any source, not just this practice pack's own outputs — an opinion received from other counsel, a judgment, an external draft. Fires on any document whose conclusions rest on premises worth checking before relying on it.
---

# Assumption Flagger

## What this does

Reads a document and surfaces every assumption its conclusions actually depend on — whether the document states the assumption openly or simply proceeds as if it were true. For each one, it says what would change if the assumption turned out to be wrong, and whether the document's bottom line depends on it or not. It does not verify or resolve any assumption; it only makes the unstated ones visible.

## Before you start

**The document to audit.** Blocking — there is nothing to flag without it.

Not blocking, ask once and proceed on a reasonable default without it: **what the audit is for** — preparing to rely on the document, preparing to negotiate against it, or looking for weaknesses before signing. This shapes emphasis, not the method.

## Method

**1. Read the whole document once before flagging anything.** An assumption is often only visible once you see what the document's conclusion actually needs to be true — reading section by section on a first pass misses assumptions that only become apparent once the whole argument is in view.

**2. Identify factual assumptions.** Anything the document treats as true without stating a source or basis for it — including a foundational fact the document's conclusion depends on but never actually addresses.

**3. Identify legal assumptions.** Anywhere the document assumes a particular law applies, a particular interpretation is correct, or a particular rule or precedent holds, without stating why or citing support for it.

**4. Identify definitional assumptions.** Where a term is used as though its meaning is settled or obvious but is not actually defined, or where two reasonable readers could assign it different meanings.

**5. Identify assumptions about another party's future conduct.** Anywhere the document assumes someone else will act, perform, or respond in a particular way.

**6. Identify scope assumptions.** What the document assumes is in scope or out of scope, addressed or not addressed, without saying so explicitly.

**7. For each assumption found, state it plainly and say what breaks in the document's conclusion if it turns out to be wrong.** An assumption noted without its consequence is just a list; the consequence is what makes it useful.

**8. Grade each assumption load-bearing or minor**, based on how much the document's actual bottom line depends on it — not how interesting or how easy to spot it is. A minor, cosmetic assumption and one the whole conclusion rests on should never appear with equal weight.

**9. Stop at surfacing.** Do not attempt to verify or resolve any assumption identified — that is the user's or the instructing lawyer's job, working from the underlying facts and law. This skill's job ends at making the assumption visible.

## Output

**1. Header.** Document reviewed, date.

**2. Assumptions.** A table: Assumption | Type (factual / legal / definitional / conduct / scope) | Where it appears | What breaks if it's wrong | Load-bearing (yes/no).

**3. Load-bearing assumptions.** A short, prioritised list of the ones the conclusion actually depends on — these are worth verifying first.

**4. Minor assumptions.** The rest, listed for completeness.

## Do not

Do not verify or resolve any assumption identified. Flag it and stop there.

Do not invent an assumption the document does not actually depend on, to make the list look more thorough.

Do not miss an assumption because it is implicit rather than stated. Surfacing the unstated ones is the entire point.

Do not present every assumption as equally important. Grade load-bearing against minor, and lead with the load-bearing ones.

Referenced files: 1

View saved version →

---
name: citation-integrity-checker
description: Extracts every citation in a document — statute, case, rule, regulation, quotation, or cross-reference — and states exactly what needs verifying about it and how, attempting live verification where research tools are available this session and producing a structured checklist where they are not. Use this whenever a document's citations need checking before anyone relies on them — including phrasings like "check every citation in this opinion before we send it", "verify these case references are real", "does this quote actually say what we're attributing to it", "audit the citations in this pleading", or "make sure none of these sections are made up". Directly responsive to the risk this whole practice pack warns about — an AI-assisted draft can produce a citation that looks correct and is not. Fires on any document containing legal citations, quotations, or cross-references, in any practice area.
---

# Citation Integrity Checker

## What this does

Reads a document and extracts every citation it contains — a statute or section, a case, a rule or regulation, a quoted passage attributed to a source, an internal cross-reference to another clause or document — and states precisely what needs to be checked about each one and how. Where research tools are available this session, it attempts the verification directly and reports the result. Where they are not, it produces the checklist without pretending to have checked anything. Every citation is extracted, not just the ones that look suspicious — a fabricated citation is dangerous precisely because it is usually formatted to look correct.

## Before you start

**The document to check.** Blocking — there is nothing to extract citations from without it.

**Whether research or verification tools are available this session.** This determines the mode. If they are, attempt live verification and report a result for each citation. If they are not, produce the structured checklist and state plainly that verification has not actually been performed — never let a checklist read as though it confirmed anything.

## Method

**1. Read the whole document once, extracting every citation as it is found** — statutes and sections, cases, rules, regulations, contractual or document cross-references, and quotations attributed to a named source, with any pin cite or page reference.

**2. Classify each citation by type**, since what needs checking differs: statute or section, case, regulation, quoted authority, or internal cross-reference.

**3. State precisely what needs verifying for each type.** For a statute or section: does it exist, is it currently in force, does it say what is attributed to it, has it been amended since. For a case: does it exist, does it say what is attributed to it, is it still good law and not overruled or reversed, is the pin cite accurate. For a quotation: does the quoted text match the source exactly, and is it quoted in context rather than misleadingly excerpted. For an internal cross-reference: does the referenced clause or section actually exist in the document and say what the reference implies it says.

**4. Where research tools are available, attempt the verification directly** — retrieve the current text, check whether the citation resolves and says what is attributed to it — and report a result: Confirmed, Could not confirm, or Contradicted. Do not silently correct or alter the document itself; report findings only, and keep results clearly separated by status.

**5. Where research tools are not available, produce the checklist without attempting verification**, and say so explicitly. A citation marked "not verified" is not the same as a citation marked "confirmed," and the output must never blur the two.

**6. Flag any citation that shows an internal tell of possible fabrication even without external verification** — a suspiciously generic-sounding case name, a citation format inconsistent with the rest of the document, an implausible pin cite for the type of source. These are common signs of a fabricated or misremembered citation and are worth flagging regardless of whether live verification is possible.

**7. Extract and report every citation, not only the ones that look suspicious.** A checker that only reports what it is suspicious of will systematically miss a confidently fabricated citation that happens to look plausible — which is the actual failure mode this skill exists to catch.

**8. Rank citations by how much weight they carry.** A citation supporting a load-bearing conclusion is a higher priority to verify than one supporting a minor or background point.

## Output

**1. Header.** Document reviewed, whether live verification was attempted this session or the pass was checklist-only, date.

**2. Citations.** A table: # | Citation as it appears | Type | What to verify | How to verify | Result — Confirmed / Could not confirm / Contradicted / Not attempted.

**3. Suspicious citations.** Any showing internal tells of possible fabrication, flagged even where external verification was not possible.

**4. Priority order.** Which citations matter most to verify first, based on how load-bearing the point they support is.

**5. Verification method note.** A plain statement of whether this pass involved live verification or produced a checklist only, so the reader cannot mistake one for the other.

## Do not

Do not present an unverified citation as verified, and do not let a checklist-only pass read as though anything was confirmed.

Do not silently skip a citation because it looks obviously correct. Extract and report every one.

Do not alter or "fix" a citation found to be wrong. Report it and leave the correction to the user or drafter.

Do not assume a citation is accurate because it is formatted correctly. Formatting and accuracy are independent.

Do not treat every citation as equally urgent. Rank by how much the document's conclusion depends on it.

Referenced files: 1

View saved version →

---
name: consistency-checker
description: Checks a document or a set of documents for internal consistency — the same fact stated the same way everywhere, dates that don't contradict each other, defined terms used consistently, and figures that match across every mention — and flags every discrepancy found without silently resolving which version is correct. Use this whenever a document set needs a consistency audit — including phrasings like "check these documents for consistency before we file them", "do the dates in this bundle actually line up", "make sure this defined term is used the same way throughout", "check the figures in this agreement match the schedule", or "cross-check this document set for contradictions". Distinct from citation-integrity-checker, which is about external authority, and assumption-flagger, which is about unstated premises — this is about internal self-consistency of what is actually stated. Fires on any single long document or document set, in any practice area.
---

# Consistency Checker

## What this does

Checks a document, or a set of documents, for internal consistency: the same fact given the same way everywhere it appears, dates that do not contradict each other or create an impossible sequence, defined terms used the same way throughout, and figures — a price, a quantity, a percentage — that match across every mention. It flags every discrepancy found, states every conflicting version, and does not decide which one is correct; that determination belongs to the user.

## Before you start

**The document or document set.** Ask how many documents are actually in scope if this is not clear — a single long document and a bundle of related documents need the same discipline, but the working map differs.

Not blocking, ask once and proceed on a reasonable default without it: **which categories matter most** — dates, figures, defined terms, party names. Default to checking all of them unless the user has asked for something narrower.

## Method

**1. Read every document in the set once before checking anything**, building a working map of what is stated where. A discrepancy is often only visible once the whole set is in view; checking document by document in isolation misses contradictions between them.

**2. Extract every date mentioned, with what it refers to and where it appears, and check for contradiction** — the same event given two different dates, or a sequence of dates that is internally impossible, such as an event dated after a deadline that depended on it.

**3. Extract every defined term and check it is used consistently** — the same term always referenced the same way, not used in an inconsistent sense in different places, and not conflated with a similar but different term.

**4. Extract every figure that appears more than once — a price, a quantity, a percentage — and check all instances match.** Where a figure is derived from others, such as a total built from line items, check the arithmetic itself.

**5. Extract party names and identifying details and check they are consistent across the set** — the same entity referred to the same way throughout, and not conflated with an affiliate or a similarly named entity.

**6. For every discrepancy found, state every conflicting version exactly as it appears, and exactly where each appears** — document, clause, or page. Do not resolve which version is correct; that is the user's call, not this skill's.

**7. Distinguish a genuine contradiction from a difference the document set itself explains** — a price stated inclusive of tax in one place and exclusive in another, where the document says so. Flag apparent inconsistencies, but note where the set itself accounts for the difference, so a real error is not lost among things that were never actually wrong.

**8. Grade every discrepancy by materiality.** A one-day date discrepancy in a background recital is not the same problem as a contradiction in the amount actually payable, and the output should make that difference obvious at a glance.

## Output

**1. Header.** Documents checked, listed by name and version, date.

**2. Discrepancies.** A table: Category (date / defined term / figure / party name) | What is inconsistent | Where each version appears | Materiality (Significant / Minor).

**3. Explained differences.** Apparent inconsistencies the document set itself accounts for, listed separately so they are not mistaken for errors.

**4. Summary.** The handful of discrepancies that actually matter, in prose.

## Do not

Do not resolve which version of a contradiction is correct. Report every version and let the user decide.

Do not over-flag a difference the document set itself explains, such as clearly labelled tax-inclusive versus exclusive figures.

Do not narrow the check to only the categories the user mentioned unless they actually asked for something narrower than a full check.

Do not present every discrepancy as equally material. Grade them, and make the significant ones easy to find.

Referenced files: 1