Rohas Legal AI: Advisory

View saved version →

---
name: client-intake
description: Turns a messy client narrative — a call transcript, a rambling email, a set of meeting notes — into a structured matter summary, with every statement tagged as confirmed fact, secondhand account, inference, or assumption. Use this whenever a user has raw, unstructured client input and wants it organised before any legal analysis starts — including phrasings like "turn this call transcript into a matter summary", "structure what the client told us", "build a chronology from these notes", "what's actually established here versus what the client is assuming", or "prepare an intake note for the file". This is a structuring skill, not an analytical one — it does not spot issues, name causes of action, or assess risk; hand off to issue-spotter or legal-risk-assessor once the facts are organised. Fires on any first client contact or new-matter narrative, in any practice area.
---

# Client Intake

## What this does

Takes a client's own account of a matter — however disorganised, repetitive, or blended with opinion — and restructures it into a chronology and matter summary, with every piece of information tagged by how solid it actually is: something the client directly observed, something they were told by someone else, their own interpretation of another party's motive or intent, or something they are simply assuming without having checked. It does not analyse the legal position. A narrative read once and structured is the product; a legal conclusion is not.

## Before you start

**The narrative itself.** A transcript, notes, an email, or a direct account. This is the only blocking input — there is nothing to structure without it.

Not blocking, ask once and proceed on a reasonable default without it: **what the summary is for** — a file note, a brief to counsel, the basis for an initial advice. This shapes emphasis, not content: a brief to counsel should foreground the chronology and the gaps; a file note can be flatter.

## Method

**1. Read the whole narrative once before structuring anything.** Clients rarely tell a story in order, and a detail mentioned in passing halfway through is often the fact that reframes something said at the start. Structuring on a first pass produces a chronology with the wrong emphasis.

**2. Identify every party named**, their role, and their relationship to the client and to each other, exactly as the client describes them — do not infer a legal relationship (employer, guarantor, agent) the client has not actually stated.

**3. Build the chronology strictly from what is actually said.** For each event, record the date as **Confirmed** (the client gave a specific date), **Approximate** (a range or relative reference — "a few months ago," "sometime last spring"), or **Undated** (no time reference given at all). Do not convert an approximate reference into a specific date to make the chronology look tidier.

**4. Tag every substantive statement by its evidentiary status.** **First-hand fact** — the client directly did or observed this. **Secondhand fact** — the client was told this by someone else; name who, if given. **Inference** — the client's own reading of another party's motive, intent, or state of mind ("they did this to force us out"). **Assumption** — something the client is treating as established without having actually verified it ("I assume they got my email since I sent it"). Keep these categories visibly separate; do not fold an inference into the chronology as if it were a fact of what happened.

**5. State what the client actually wants**, separately from the facts. Clients routinely narrate the story and the desired outcome in the same breath; pull the sought outcome out as its own line so it is not mistaken for a fact about what happened.

**6. Note every document the client refers to but has not supplied** — an email, a contract, a text message, a report — as an evidence gap, not as something whose contents can be assumed from the client's description of it.

**7. Flag internal contradictions in the narrative itself** — a date or an account of an event that does not square with something said elsewhere in the same narrative. Note both versions and the discrepancy; do not silently pick the one that seems more likely or more favourable.

**8. Stop at structure.** Do not name a cause of action, assess whether the facts amount to anything actionable, or estimate a likely outcome. If the user wants that, say plainly that this skill only organises the account and point to issue-spotter or legal-risk-assessor for the analysis.

## Output

**1. Header.** Client, matter, date of intake, source of the narrative (call, email, meeting notes, other).

**2. Parties.** A short table: party, role, relationship to client, as described — not inferred.

**3. Chronology.** A table ordered by date: Date (with Confirmed/Approximate/Undated marked) | Event | Source (first-hand / secondhand / inference).

**4. What the client wants.** One or two plain sentences, stated separately from the facts above.

**5. Assumptions to test.** A distilled list of the inferences and assumptions identified in step 4 of the method, framed as points the lawyer should verify before relying on them — not as findings.

**6. Documents referred to but not supplied.**

**7. Contradictions and gaps.** Anything in the narrative that does not square with itself, or a material point the narrative leaves unclear.

## Do not

Do not draw a legal conclusion, name a cause of action, or assess risk. That is a different skill's job; this one only structures the raw account.

Do not smooth over a contradiction in the client's own narrative. Flag it and record both versions.

Do not convert an approximate or undated reference into a specific date to make the chronology look more complete than the account actually is.

Do not treat the client's characterisation of another party's motive or intent as an established fact. It is an inference, and belongs in that category.

Do not infer a legal relationship — employment, agency, guarantee — the client has not actually stated, even where the facts suggest one.

Do not assume the contents of a document the client has described but not supplied. Record it as a gap.

Referenced files: 1

View saved version →

---
name: client-update-drafter
description: Drafts a plain, honest status update for a client on a matter already underway — what has happened, what it means, what happens next, and any bad news or delay stated plainly rather than buried. Use this whenever a user wants a client informed of progress — including phrasings like "draft an update for the client on where this stands", "write a status email covering what happened this month", "let the client know about the delay", "prepare a progress note for the board", or "tell the client we're over budget on this". Fires for any running matter in any practice area, whether the news is good, mixed, or bad.
---

# Client Update Drafter

## What this does

Drafts a status update to a client on a matter already in progress: what has happened since the last update, what it means in practical terms, and what happens next. It is a communications-drafting skill, and its discipline is specific — plain language over procedural jargon, and honesty about bad news over reassurance that omits it. It does not analyse the legal position or invent a timeline the lawyer has not actually committed to.

## Before you start

**What has actually happened since the last update.** The developments to report — supplied by the lawyer. This is the blocking input; there is no update to draft without it.

**Whether there is anything adverse to report.** A missed deadline, an unfavourable development, a delay, a cost overrun. Ask directly if the user has not said — "is there anything adverse, delayed, or costlier than expected to include" — because the common failure in this genre of letter is a status update that quietly omits the one thing the client most needs to know. Do not assume the absence of bad news; confirm it.

Not blocking, ask once and proceed on a reasonable default without it: **channel and tone** — a short email versus a more formal letter, and whether the relationship calls for a warmer or more clinical register.

## Method

**1. List every substantive development since the last update**, in the order it occurred, before drafting a word of the letter. A list built while drafting tends to lose the less dramatic but still material items.

**2. Separate what is actually resolved or decided from what remains pending or uncertain.** Do not present a provisional or interim development as settled.

**3. State any bad news near the top, not in the fourth paragraph.** A missed deadline, an adverse ruling, an unexpected cost, a delay — state it plainly, say what it means practically for the client, and only then provide context or next steps. Do not lead with reassuring framing that buries the substance.

**4. State next steps and, where the lawyer has given a timeline, the expected timing.** Where timing is genuinely uncertain, say so directly — "timing is not yet clear because X" — rather than supplying a date to make the update feel more complete than the facts support.

**5. Separate what requires a decision or instruction from the client from what is purely informational.** Put anything the client needs to act on in its own clearly marked place; do not let it dissolve into general narrative where it can be missed.

**6. Translate procedural steps into what they mean, not just what occurred.** "We filed our submissions" tells the client nothing on its own; say what filing them means for the timeline or the client's position.

**7. State any fee or cost development precisely as given**, not rounded or softened to make it easier to deliver.

## Output

**1. Headline.** One line stating overall status — on track, delayed, at a decision point, or a stage concluded.

**2. What's happened.** Plain narrative or bullets covering every development identified in Method step 1.

**3. Anything adverse.** Its own clearly marked section if bad news, delay, or cost change exists — never folded into the general narrative where it can be missed. Omit this section only if the user has confirmed there is nothing to report.

**4. What happens next**, and expected timing, or an honest statement that timing is not yet clear and why.

**5. What we need from you.** Decisions or instructions required, if any.

**6. Sign-off.**

## Do not

Do not bury or soften bad news to make the update read more comfortably. State it plainly, near the top.

Do not invent a completion date, outcome, or estimate the lawyer has not actually given. State uncertainty honestly instead.

Do not use a procedural term without saying what it means for the client's timeline or position.

Do not omit a fee or cost development that was supplied, or soften a figure to make it land more gently.

Do not present a provisional or interim development as though it were final and settled.

Referenced files: 1

View saved version →

---
name: demand-notice-drafter
description: Drafts a pre-litigation demand notice — the formal letter setting out a claim, particularising the facts and the amount or relief demanded, and requiring specific action by a stated deadline. Use this whenever a user wants a formal demand sent before litigation — including phrasings like "draft a demand notice for unpaid invoices", "send a formal notice before we sue", "particularise this claim and demand payment", "draft a cease and desist with a deadline", or "prepare a legal notice demanding possession back". Side-specific — drafted on behalf of the sender, against a named recipient. Fires for any pre-litigation demand — debt, breach of contract, tortious claim, statutory notice — in any practice area.
---

# Demand Notice Drafter

## What this does

Drafts a formal demand notice: a letter that particularises a claim precisely, states exactly what compliance requires, sets an absolute deadline, and states the consequence of non-compliance only to the extent the client is actually prepared to follow through on. A demand notice is often itself evidence — of when a party had notice of a claim, of what was actually demanded — so vagueness here is a defect, not a style choice.

## Before you start

**The underlying facts and claim.** What happened, what is owed or was breached, supplied by the user. This is blocking; the notice cannot be particularised without it.

**The relief demanded, and the deadline for compliance.** An exact figure or action, and an exact date — not "promptly" or "within a reasonable time." This is blocking; a demand notice with a vague deadline is a weaker document and this skill does not draft one.

**Governing law.** Some causes of action and forums require a demand notice as a strict precondition to suit, with mandatory minimum notice periods, required content, or specified methods of service — get this wrong and a later filing can be invalid. Extract it from any supplied documents or ask; treat compliance with any such formality as a verification point rather than something to assert from memory.

Not blocking, ask once and proceed on what is confirmed: **the legal basis for the claim**, if not already stated — the contract clause, the statutory provision, the tortious basis. If the user has not specified it, do not invent one; either ask, or draft the notice on the stated facts and demand without naming an unconfirmed legal basis, and say so.

## Method

**1. Classify the claim type in one line** — breach of contract, statutory demand, tortious claim, other — before drafting anything.

**2. Particularise the facts precisely.** Who, what, when, and by reference to specific dates, documents, or clauses where available. A demand notice built on a vague factual recitation invites a vague response and carries less weight later.

**3. State the legal basis only in the terms the user has actually supplied.** Do not invent a cause of action, statute, or clause reference. Where none has been given, either ask for it or draft the notice around the stated facts and demand, and say plainly that no specific legal basis has been named.

**4. Quantify the claim precisely.** State the principal amount, and if interest is claimed, state the rate and its basis rather than assuming one; where the figure is not a flat sum, show the arithmetic so the calculation can be checked.

**5. State the demand itself unambiguously** — exactly what compliance requires (pay this sum, do or cease doing this specific thing, deliver this item) and the exact date by which it must happen. Never "within a reasonable time."

**6. State the consequence of non-compliance only to the extent the client is actually prepared to pursue it.** Do not draft a threat of a specific proceeding, remedy, or consequence the client has not confirmed they intend to follow through on — an empty threat weakens the notice and can be used against the sender later.

**7. Flag any formal requirement the governing law may impose on this notice type** — a mandatory minimum period, a required method of service, prescribed content — as a point to verify rather than a fact to assert. Do not state that the notice satisfies a statutory precondition without that being confirmed.

**8. Add a service note.** Remind the user to record how and when the notice is sent, since proof of service or receipt commonly matters later.

## Output

**1. Header.** Sender/client, recipient, date, matter reference.

**2. The notice.** Salutation, particularised facts, legal basis (only as supplied), the quantified demand shown with its calculation where relevant, the deadline, the stated consequence of non-compliance, and a reservation of rights.

**3. Service note.** How to serve the notice and what to retain as proof of service.

**4. Points requiring verification.** Any notice-period, content, or service-method requirement under the governing law; anything resting on a legal basis the user has not confirmed.

## Do not

Do not invent the legal basis, statute, or clause the claim rests on.

Do not use a vague deadline. Use an exact date.

Do not threaten a proceeding, remedy, or consequence the client has not confirmed they are prepared to pursue.

Do not assert that the notice satisfies a statutory notice-period or service requirement without that being verified — flag it instead.

Do not soften or hedge the demand into something that reads as negotiable when the client wants a firm demand, and do not draft it more aggressively than the client's actual instructions where they want room to negotiate.

Referenced files: 1

View saved version →

---
name: engagement-letter-drafter
description: Drafts a client engagement letter — scope of the retainer, fee arrangement, what is explicitly excluded, and the conflict-of-interest position. Use this whenever a user is starting a new client relationship or matter and needs the retainer documented — including phrasings like "draft an engagement letter for this new client", "prepare a retainer letter covering this matter only", "what should our fee letter say about scope creep", or "draft the conflicts and fee sections for this engagement". Ambiguous scope and undocumented conflict checks are two of the most common sources of later fee disputes and professional exposure, so this skill treats precision on both as load-bearing, not boilerplate. Fires for any new engagement or matter-specific retainer, in any practice area and firm structure.
---

# Engagement Letter Drafter

## What this does

Drafts the letter that begins or documents a client engagement: what work is included, what is explicitly excluded, how fees are charged, what happens if the scope changes, and the conflict position. This is a protective document for the firm as much as the client — the two most common sources of later dispute are scope the client thought was covered but wasn't, and a conflict check that was assumed rather than confirmed. Both get direct, explicit treatment here rather than being left to standard-form language.

## Before you start

**The actual scope of the engagement.** What matter, what work is being retained for, supplied by the user. This is blocking — scope cannot be drafted from a title alone.

**The fee basis and the actual figures.** Hourly rate, fixed fee, contingency or success fee where the jurisdiction permits it, retainer amount — whatever was actually agreed. This is blocking; do not draft a standard or assumed rate.

**Whether a conflict check has actually been run, and its outcome.** This is blocking. An engagement letter issued without a completed conflict check is a real and specific risk — if the user has not confirmed one was run, ask directly rather than drafting a conflicts clause that implies one was.

Not blocking, ask once and proceed on a reasonable default without it: **governing law and applicable professional conduct rules**, which affect specific mandatory content — some regimes require particular disclosures, cost estimates, or client rights language in engagement letters. Extract or ask; treat this content as a verification point, not something to draft from memory.

## Method

**1. State the scope precisely — and state the exclusions with equal precision.** What is included is only half the job; what is explicitly not covered (a related matter, an appeal, a regulatory filing that might arise) prevents the client from assuming coverage that was never agreed, and prevents the scope from creeping silently as the matter runs.

**2. State the fee basis exactly as instructed** — rate, currency, billing frequency, what is billable (time, disbursements, third-party costs, expenses) — without assuming a standard rate or rounding a figure the user gave precisely.

**3. State the mechanism for agreeing additional work or a scope change.** Without this, scope creep happens by default rather than by agreement; the letter should say explicitly how a change gets proposed and confirmed.

**4. State the conflict position as confirmed** — that a check was run and its outcome — or, if not confirmed, flag this prominently as something that must be resolved before the letter issues rather than papering over it with standard conflicts language.

**5. State termination and withdrawal terms** — how either side ends the engagement, and the practical consequences: fees for work done, file handover, any transition obligation.

**6. State confidentiality and any regulatory or professional-conduct disclosures the governing law or applicable bar rules require**, without drafting the specific mandatory wording from memory. Flag this as a point requiring verification against the rules that actually apply to this firm and jurisdiction.

**7. Where the firm uses a limitation of liability clause, state it only if solicitor liability caps are actually permitted under the governing law** — do not assert that such a cap is enforceable; flag it as a verification point.

**8. Check the letter's language is internally consistent with the fee basis actually used.** Do not let contingency-fee language appear in a letter that is otherwise hourly, or vice versa.

## Output

**1. Header.** Client, matter, date.

**2. Scope of engagement.** What is included; what is explicitly excluded.

**3. Fee arrangement.** Basis, rate or figures, billing frequency, disbursements, and the mechanism for agreeing a scope or fee change.

**4. Conflict position.** Confirmation the check was run and its outcome, or a flagged gap requiring resolution before the letter issues.

**5. Termination and withdrawal terms.**

**6. Confidentiality and regulatory disclosures.** Flagged for verification wherever content depends on the governing law or applicable professional conduct rules.

**7. Points requiring verification.** Mandatory disclosure content, enforceability of any liability cap, and anything else resting on rules not yet confirmed.

## Do not

Do not invent a fee figure, rate, or billing basis. Use only what was actually instructed.

Do not draft scope language broad enough to imply coverage the client has not actually retained the firm for.

Do not state that a conflict check was clear, or omit the conflicts section, when the check has not actually been confirmed. Flag the gap.

Do not draft mandatory regulatory or professional-conduct disclosure language from memory. Flag it as a verification point against the rules that actually apply.

Do not assert that a limitation of liability clause is enforceable under the governing law.

Do not let the letter's fee language contradict the fee basis actually instructed.

Referenced files: 1

View saved version →

---
name: legal-explainer
description: Restates an existing legal position — an opinion, a judgment, a contractual provision, counsel's advice — in plain language a client can actually act on, without changing its substance. Use this whenever a user has a legal position already worked out and needs it translated for a non-lawyer — including phrasings like "explain this opinion to the client in plain English", "what does this ruling actually mean for us", "translate this clause into something the board can understand", "make this advice readable for someone without a legal background", or "what's the plain-English version of what counsel just told us". This is a translation skill, not a fresh analysis — it does not add a conclusion, authority, or caveat the source does not contain, and does not drop one the source does. Use legal-opinion-drafter first if the formal analysis does not exist yet. Fires for any existing legal position needing a lay-readable restatement, in any practice area.
---

# Legal Explainer

## What this does

Takes a legal position that already exists — a written opinion, a judgment, a clause, advice already given — and restates it in language a client can actually use to decide or act, without adding to or subtracting from what the source actually says. It is a translation exercise. The bottom line, the reasoning, the caveats, and the source's own level of confidence all have to survive the translation intact; only the register changes.

## Before you start

**The source material to translate.** The actual opinion, judgment, clause, or advice — supplied by the user, not reconstructed from a general sense of what it probably says. This is the only blocking input; there is nothing to translate without it.

Not blocking, ask once and proceed on a reasonable default without it: **the audience** — an individual client, a business client, a board. This shapes register and how much background to supply, not the substance of what is said.

## Method

**1. Read the whole source once before restating anything.** A caveat or qualification stated once, early in a document, routinely governs a conclusion stated later — translating section by section on a first pass loses exactly the nuance this skill exists to preserve.

**2. State the bottom line first, in one or two plain sentences** — what this actually means for the client, practically, before any of the reasoning.

**3. Translate each material element of the source's reasoning into plain language**, including the conditions and caveats it places on its own conclusion. Do not drop a caveat because it complicates an otherwise clean explanation — the caveat is often the part the client most needs.

**4. Preserve the source's own level of confidence exactly.** If the source says a position is "likely" or "arguable," the explanation says the same, in plain words — not "yes" or "you're covered." If the source is definitive, do not hedge it into false uncertainty either. Getting this wrong in either direction misrepresents the advice.

**5. Do not add a legal conclusion, statute, or authority the source does not contain.** This is a restatement, not a fresh analysis. If the client's actual question is not answered by the source, say that plainly rather than filling the gap with an inference of your own.

**6. State what the client needs to do or decide, if the source implies an action**, as its own distinct point — separate from the explanation of what the position means, so it cannot be missed inside the narrative.

**7. Flag it, rather than silently resolve it, if the source itself is unclear, outdated, or internally inconsistent on the point the client is asking about.** Do not pick one reading and present it as the only one.

## Output

**1. Bottom line.** One or two plain sentences, stated first.

**2. What this means.** The reasoning and its conditions, in plain language, with the source's caveats and confidence level preserved exactly.

**3. What you need to do or decide.** Only if the source implies an action; stated separately from the explanation.

**4. What this doesn't cover.** If the client's actual question reaches beyond what the source addresses, say so plainly rather than extending the source's conclusion to cover it.

## Do not

Do not add a legal conclusion, authority, or statute that is not present in the source material.

Do not upgrade or downgrade the source's stated level of confidence when translating it into plain language.

Do not drop a material caveat or qualification to make the explanation read more cleanly.

Do not silently resolve an ambiguity or internal inconsistency in the source. Flag it instead.

Do not answer a question the source does not actually address. Say plainly that it isn't covered.

Referenced files: 1

View saved version →

---
name: legal-opinion-drafter
description: Drafts a structured written legal opinion — the question presented, the facts relied on, the analysis, the conclusion, and the assumptions and limitations the opinion depends on. Use this whenever a user wants a formal, reasoned answer to a specific legal question rather than a quick take — including phrasings like "write an opinion on whether this clause is enforceable", "prepare a formal opinion for the lender on this security package", "what's our written position on this point, with reasoning", "draft an opinion letter answering these three questions", or "I need something the board can rely on for this decision". This is the most exposed document type in this practice pack — a client may act on it, sometimes with real money or liability at stake — so it holds the highest discipline on separating document analysis from legal conclusion, never citing an authority that has not been retrieved or supplied, and stating every assumption explicitly. Fires for any formal opinion request, in any practice area.
---

# Legal Opinion Drafter

## What this does

Drafts a structured written opinion: the precise question being answered, the facts it is based on, issue-by-issue analysis, a conclusion stated with the degree of confidence the analysis actually supports, and the assumptions and limitations the opinion depends on. An opinion is understood by its reader to be reliable within its stated scope — so a vague question, an unstated assumption, or a citation that turns out to be wrong does more damage here than in almost any other document this practice pack produces.

## Before you start

**The precise question presented.** A vague brief produces a vague opinion. "Is this enforceable" is not precise enough — enforceable against whom, under which law, on what facts. If the question as given is not precise, work with the user to state it precisely before drafting anything; do not silently narrow or reinterpret it without flagging that you have done so.

**The facts the opinion is to be based on.** Supplied by the client or instructing lawyer. The opinion has to rest on stated facts, not assumed ones — if the facts are incomplete, the opinion should say so explicitly and state what it is assuming in their place, rather than filling gaps with a plausible-sounding account.

**Governing law, and which mode the opinion runs in.** *Document-based*: analysing the words and their internal coherence, with every point that turns on the law itself left as an open question in the limitations section. *Law-based*: legal conclusions resting on current authoritative sources retrieved in this session or supplied by the user, cited specifically. Law-based mode runs only where the user asks for it and research tools or authorities are actually available. Never state a statute, case, or rule from memory in either mode.

Not blocking, ask once and proceed on a reasonable default without it: **the standard the opinion is written to** — an internal advisory memo, or a formal reliance opinion for a third party (a lender, a counterparty, a regulator). A reliance opinion carries different conventions — a named addressee, stated reliance parties, more exacting qualifications — and different stakes, so ask if it is not obvious from the brief.

## Method

**1. Restate the question presented precisely**, and confirm it with the user before proceeding if the brief was ambiguous. An opinion that answers the wrong question is worse than none, because it will be relied on as if it answered the right one.

**2. State the facts relied on, separately from the analysis**, and mark which are confirmed and which are assumed. An opinion is understood to depend on its stated facts; if a stated fact later proves wrong, the opinion is understood not to apply, so this separation is not a formality.

**3. Identify every issue the question actually raises**, and work through each one systematically before drafting the conclusion. Do not let the conclusion take shape before the analysis is complete.

**4. Keep legal conclusions strictly separated from document or factual analysis at every point**, and cite only authorities that are current, retrieved in this session, or supplied by the user — cited specifically, never from memory. Where a needed citation is not available, say so and put the gap in the limitations section rather than answering from general recollection.

**5. Address the genuine counter-argument or opposing reading on any point that is actually arguable.** An opinion that presents only the favourable reading is not reasoned, it is advocacy, and a client relying on it deserves to know where the real uncertainty sits.

**6. State the conclusion plainly, with the degree of confidence the analysis actually supports** — certain, likely, arguable, or unclear. Do not inflate confidence to make the opinion feel more useful, and do not hedge a genuinely clear answer into false uncertainty to seem more cautious.

**7. State every assumption and limitation the opinion depends on, explicitly and completely** — the facts assumed, the law as of a stated date, the jurisdiction, and what the opinion does not address. An opinion silent on its own scope invites reliance well beyond what it actually supports.

**8. Where the answer turns on a fact not yet known or a document not yet supplied, say so and state what would change the conclusion.** Do not assume the missing fact favourably to reach a cleaner answer.

## Output

**1. Header.** Addressee, matter, date, and the question or questions presented, restated precisely.

**2. Facts relied on.** Listed, with confirmed and assumed facts distinguished.

**3. Analysis.** Issue by issue, reasoning shown in full, counter-arguments addressed, citations included only where sourced or verified this session.

**4. Conclusion.** Stated plainly, with the confidence level the analysis actually supports.

**5. Assumptions and limitations.** What the opinion assumes, its scope, the date of the law relied on, and what it does not cover.

**6. Points requiring verification.** Any citation the opinion needed but could not source this session, and any question left open for that reason.

Mark every conclusion in section 3 and 4 as resting on either the stated facts or a cited, verified authority. If a statement is not traceable to one of those two things, it belongs in section 6, not the analysis.

## Do not

Do not answer a different question than the one presented without flagging that you have reframed it.

Do not state a statute, case, or rule from memory, in either document-based or law-based mode.

Do not inflate or deflate the stated confidence level relative to what the analysis actually supports.

Do not omit the genuine counter-argument or opposing reading on a point that is actually arguable.

Do not draft a conclusion that outruns the facts actually supplied. Flag the missing fact instead of assuming a favourable one.

Do not omit the assumptions and limitations section, or state it in general terms that do not actually bound what the opinion covers. An opinion without a stated scope is a liability, not a convenience.

Referenced files: 1

View saved version →

---
name: legal-risk-assessor
description: Sets out the realistic options on a decision a client faces, with the downside risk, the likely outcome, and the best case of each — to inform the client's decision, not to make it for them. Use this whenever a user is weighing options and wants the risk of each worked through — including phrasings like "what are our options here and how risky is each", "should we settle or litigate, what's the downside of each", "lay out the risk of disclosing versus not disclosing", "what could go wrong if we sign versus if we walk away", or "help the client weigh this decision". Distinct from legal-opinion-drafter, which answers one legal question — this compares multiple options against what the client actually cares about (cost, time, certainty, relationship, reputation). Fires for any legal decision with more than one realistic path, in any practice area.
---

# Legal Risk Assessor

## What this does

Takes a decision a client faces and sets out the realistic options, what could go wrong with each and how likely and severe that is, and the realistic best and likely case alongside the downside — organised around what the client has actually said matters to them. It supports the client's decision; it does not make it. Where the analysis depends on a legal question — how likely a claim is to succeed, whether a position would hold up — it grounds that in supplied authority or flags it as needing research, rather than asserting a probability from memory.

## Before you start

**The decision and the options actually on the table.** Stated by the user, not invented. If the options have not been clearly identified, ask the user to state what is realistically available before drafting anything — including whether "do nothing" or maintaining the status quo is genuinely one of them, since it is often implicitly excluded without being ruled out on the merits.

**What matters to the client.** Cost, time, certainty, reputation, preserving the relationship, precedent for future disputes — whichever mix actually applies. This is blocking: risk is not one-dimensional, and the same option can be low financial risk and high reputational risk at once. Which matters more is the client's call, not an assumption to make on their behalf.

Not blocking, ask once and proceed on what is available: **governing law**, where part of the analysis turns on a legal question (likelihood of success on a claim, enforceability of a position). Extract or ask; ground any such point in supplied authority or documents, or flag it as requiring research rather than stating a probability from memory.

## Method

**1. State the decision and the realistic options precisely**, including the status quo or "do nothing" option where it genuinely applies. Do not silently narrow the option set to the ones that seem obviously reasonable.

**2. For each option, identify what could go wrong** — the downside scenarios — how likely each realistically is, and how severe the consequence would be if it happened. Use qualitative likelihood (unlikely, possible, likely) unless the user has supplied real data to quantify it; do not manufacture a percentage that implies more precision than the analysis actually has.

**3. For each option, identify the best and likely case, not only the downside.** A risk assessment that only catalogues what could go wrong leaves the client without the realistic range they need to actually weigh the decision.

**4. Where an element of the analysis rests on a legal question**, ground it in supplied authority or documents, or state plainly that it requires legal research and give only the qualitative reasoning available without it. Do not state a probability of legal success as settled fact from memory.

**5. Map each option against what the client said matters to them from Before you start** — cost, time, certainty, relationship, reputation — so the comparison is organised around the client's actual priorities rather than a generic checklist that may not reflect them.

**6. State which option or options the analysis favours given those stated priorities, framed as input to the client's decision, not as an instruction.** The client decides; this skill's job ends at giving them a clear basis to do so.

**7. Flag where missing information would materially change the assessment** — "if the assumption in the contract's force majeure clause is wrong, this changes considerably" — rather than presenting the assessment as more settled than the available facts support.

## Output

**1. The decision and the options.** Stated precisely, including the status quo where it applies.

**2. Options table.** Option | Downside scenarios and likelihood | Best/likely case | Fit with the client's stated priorities.

**3. Comparative view.** How the options stack up against what the client said matters to them, in prose.

**4. Observation.** Which option or options the analysis favours, explicitly framed as input to the client's decision rather than a directive.

**5. What would change this.** The information gaps that would materially alter the assessment if resolved differently than assumed.

**6. Points requiring verification.** Any legal-probability question resting on law not yet sourced or confirmed.

## Do not

Do not make the decision for the client. Frame every conclusion as input to their choice, not an instruction.

Do not present only the downside of each option. Include the realistic best and likely case alongside it.

Do not state a probability of legal success, or that a position would hold up, as settled fact without grounding it in supplied authority — flag it as needing research instead.

Do not assume the client's priorities. Ask, and organise the comparison around what they actually said matters.

Do not silently exclude the status quo or "do nothing" option where it is realistically available.

Do not manufacture a precise percentage or figure where the analysis only supports a qualitative likelihood.

Referenced files: 1

View saved version →

---
name: notice-reply-drafter
description: Drafts a reply to a legal notice received from another party — a demand notice, a cease and desist, a regulatory notice — dealing with each allegation in turn — admitted, denied with the client's own account, denied for insufficient knowledge, or qualified. Use this whenever a user has received a notice and needs to respond — including phrasings like "draft a reply to this demand notice", "respond to this cease and desist", "we've been sent a legal notice, help us reply", "deny these allegations and state our position", or "draft our response before the deadline in this notice". Side-specific — drafted for the recipient, against the party who sent the notice. The mirror image of demand-notice-drafter. Fires for any reply to a received legal notice, in any practice area.
---

# Notice Reply Drafter

## What this does

Drafts a reply to a legal notice the client has received: addressing every allegation made, stating the client's position on each precisely, and raising any point that affects the whole notice rather than just one allegation. It structures what the client actually says; it does not invent a defence or a fact the client has not given. A response that leaves an allegation unaddressed can, in some contexts, be read as tacit admission, so completeness is treated as a real risk here, not a formality.

## Before you start

**The notice being replied to.** The actual text — there is no reply to draft without seeing what was actually alleged.

**Which side is instructing.** This is drafted for the recipient of the notice, against the party who sent it.

**The client's actual position on each allegation.** What is true, false, or partially true, from the client. This is blocking; the skill structures the client's account, it does not construct a defence from the allegations alone.

**Governing law.** Reply timing and formality requirements, and the legal effect of silence or an inadequate reply, can be law-dependent — in some systems, silence in response to a notice itself carries consequence. Extract from any supplied documents or ask; treat compliance with any such requirement as a verification point.

Not blocking, ask once and proceed on a reasonable default without it: **tone** — conciliatory, to preserve the relationship, or firm, anticipating that litigation may follow. This shapes register throughout, not the substance of the response.

## Method

**1. Read the whole notice once before drafting a single response.** Allegations in a notice routinely interact, and a global point — the claim is time-barred, the notice is defective, the wrong party was named — can dispose of several allegations at once; drafting allegation-by-allegation on a first pass misses this.

**2. List every allegation made, numbered, before drafting any response.** Completeness matters on its own terms here: if the client wants to leave an allegation unaddressed, flag the risk of that silence rather than simply omitting a response.

**3. State the client's position on each allegation precisely, using only what the client has actually said** — admitted, denied with the client's own account, denied for insufficient knowledge to admit or deny, or qualified. Do not invent a fact or a defence to fill a gap in the client's instructions.

**4. Where an allegation is denied, state the client's own version of events specifically, not a bare denial.** A bare denial is weaker and less useful evidentially than a denial coupled with an affirmative account of what the client says actually happened.

**5. Raise any global or threshold point prominently**, near the start of the substantive response rather than buried among individual allegations — since a point like limitation or a defective notice can affect the whole document, not just one paragraph of it.

**6. Keep factual admissions and legal characterisation separate, even where a fact is conceded.** Admitting "the delivery was three days late" is not the same as admitting "we are in breach," and the reply should never blur the two — concede the fact if it's true, without conceding the legal conclusion the other side is drawing from it.

**7. State the client's own position or demand at the end, if any** — rejecting the notice's demand outright, proposing a different resolution, or simply reserving rights pending further information.

**8. Flag any reply-timing or formality requirement the governing law may impose** — a mandatory response period, required content, method of service — as a point to verify rather than assume compliance with.

## Output

**1. Header.** Recipient of this reply (the party who sent the original notice), sender/client, date, reference to the original notice.

**2. Response to each allegation.** Numbered to match the original notice: admitted / denied with the client's own account / denied for insufficient knowledge / qualified.

**3. Global or threshold points, if any.** Stated prominently, not folded into the allegation-by-allegation response.

**4. Client's own position or demand, if any.**

**5. Reservation of rights.**

**6. Points requiring verification.** Reply-timing or formality requirements under the governing law, and anything resting on an unconfirmed legal characterisation.

## Do not

Do not invent a fact or a defence the client has not actually given.

Do not concede a legal conclusion while admitting a fact. Keep the two separate throughout.

Do not leave an allegation unaddressed without flagging to the user the risk that silence can carry.

Do not draft a bare denial where the client has given their own account of events — use it.

Do not assume a reply-timing or formality requirement is satisfied. Flag it as a point to verify.

Referenced files: 1