Install
$ agentstack add skill-rohasnagpal-legal-ai-skills-legal-opinion-drafter ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
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.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: rohasnagpal
- Source: rohasnagpal/legal-ai-skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.