If I just want to try out the Legal Plugin without deciding yet whether to use it long-term, do I still need to customize legal.local.md first?
If you just want to get a feel for the interface and what the report format looks like, running /review-contract with the defaults is fine — it'll quickly show you what the GREEN/YELLOW/RED categorization, clause-by-clause analysis, and suggested revisions actually look like in practice. But the moment you plan to take the resulting analysis seriously — using it to actually decide whether to sign a contract, or whether to push back on a particular clause in negotiation — the gap between the default and your actual jurisdiction starts directly affecting the quality of that judgment.
The more practical split is: use the defaults to test whether the tool works at all; use a customized playbook to decide whether you can trust a given analysis. The former is product evaluation, the latter is actual reliance, and they call for different amounts of prep work.
Our company is based in Taiwan but also signs contracts with U.S. companies — how should the playbook be set up in that case?
In that situation, the more practical approach isn't choosing one standard over the other (Taiwan-only or U.S.-only) — it's designing the "acceptable range" field to cover both scenarios at once. Take the governing law clause as an example: the "standard position" can be set to the law of your primary place of business (Taiwan), while the "acceptable range" can also list governing law options commonly seen in contracts with U.S. companies (New York, Delaware, say), with a note on what to watch for where those might diverge from Taiwan's regulatory requirements (notification timelines for data protection, for instance).
That means customizing legal.local.md isn't about writing one fixed standard once — it's about first taking stock of which jurisdictions your company's actual contracts span, then writing those differences explicitly into the escalation triggers. For example: "governing law is a U.S. state and the contract touches on data protection clauses → always escalate to counsel for review." That way Claude knows which combinations need extra care, rather than assuming every contract fits the same logic.
Can the legal team customize legal.local.md on their own, or does it need help from engineering or IT?
The legal team can do it entirely on their own — no engineering or IT help needed. The file is fundamentally a structured markdown text file listing legal positions and standards, with no programming syntax involved. Anthropic's example file simply uses headings and bullet points to lay out categories like "standard position," "acceptable range," and "escalation trigger" — any legal team member familiar with contract review logic can edit it directly, at roughly the same technical difficulty as writing an internal contract review guideline document.
The real prep work is actually turning judgment criteria that previously only lived in a senior lawyer's experience — never systematically written down — into something on paper. That itself can take more time than expected, but the difficulty is in the knowledge work of taking stock of and organizing your company's negotiation standards, not any technical hurdle. Where it lives is simple too: just drop it into any folder already shared with Cowork, and the Plugin finds it automatically, with no separate deployment or configuration step needed.
If our company doesn't have time to fully customize all of legal.local.md right away, is there a reasonable middle-ground approach?
Yes — a phased customization strategy works, prioritizing the clause categories with the highest risk and the most potential for real damage. For most companies' typical contract types, the governing law clause and data protection clauses are the two highest-priority items — the former determines whether the entire analysis's comparison baseline is even valid, and the latter directly bears on regulatory compliance, where a misjudgment carries real compliance risk. These two are worth customizing first, even if other clauses (say, the finer points of IP ownership) still run on defaults for now.
Another practical move is to set the escalation trigger conditions so that "governing law or data protection clauses haven't had their comparison standard customized yet" automatically routes to attorney review. That sets up a safeguard before full customization is done, ensuring these high-risk categories never get waved through as GREEN based on the U.S. default alone. That way you lower the biggest exposure first, then fill in the remaining clause categories over time.
Among the plugins in Anthropic's open-source Knowledge Work Plugins, the Legal Plugin generated the most buzz — it reviews contracts clause by clause with a GREEN/YELLOW/RED flagging system, and the announcement was significant enough that shares in legal-tech companies like Thomson Reuters and RELX dropped over 10% the same day, with the Jefferies Group calling it the "SaaSpocalypse." But almost every tutorial covers installation and usage, and few dig into a disclaimer on the official page that's easy to skim past — this plugin defaults to U.S. jurisdiction standards, and if your company doesn't operate in the U.S., installing it and using it as-is could mean reviewing your own contracts against the wrong legal framework entirely.
The Legal Plugin's GitHub page contains a line worth reading word for word: the default playbook examples in this plugin reflect U.S. legal positions and jurisdictions (Delaware, New York, California), and if you operate under a different legal system (EU, UK, Netherlands, Australia, etc.), you must customize the playbook in `.claude/legal.local.md` to reflect your jurisdiction's specific legal requirements, standard contract terms, and compliance obligations before relying on the plugin's analysis. That's a "must," not a suggestion — this isn't a nice-to-have customization option, it's a prerequisite Anthropic itself treats as necessary.
The Legal Plugin's core mechanism is comparing a contract against the standard positions, acceptable ranges, and escalation triggers you define in `legal.local.md`. Anthropic's example file covers limitation of liability (standard position: a mutual cap at 12 months of fees), indemnification (standard position: mutual indemnification for IP infringement and data breach), IP ownership, data protection requirements (standard position: a DPA required for any personal data processing, breach notification within 72 hours), term and termination, and governing law — and every "standard position" and "acceptable range" in that example is written with U.S. commercial norms baked in as the default.
If you install the plugin and start reviewing contracts without touching the example file, Claude will compare your contract against U.S. commercial conventions — for instance, treating "breach notification within 72 hours" as the standard to check against. If the notification window your jurisdiction actually requires differs from that number, Claude might flag a clause that's fully compliant under your local law as a deviation needing revision. Conversely, it could also wave through as GREEN a clause that's clearly problematic under your jurisdiction but happens to align with U.S. convention. This isn't Claude making a bad judgment call — it's Claude faithfully applying whatever standard you configured (or failed to configure) for it. Without customization, all it has to work with is the built-in U.S. default.
The example playbook's default standard position for governing law literally reads "[Your jurisdiction]" as a placeholder, with the acceptable range listing major commercial jurisdictions like NY, DE, CA, and England & Wales. If you never touch that placeholder, Claude's logic for evaluating a governing law clause is either empty or defaults to misapplying U.S. convention — this is exactly where the absence of customization becomes most directly exposed. If a contract specifies Taiwanese law as the governing law and gets reviewed against the default playbook, Claude may not know how to evaluate that clause at all for lack of a matching standard, or it may misapply an unrelated U.S. jurisdiction's conventions to it.
The good news is that customizing `legal.local.md` requires no coding — it's a structured markdown document, and all you need to do is replace each clause's standard position, acceptable range, and escalation trigger with what actually applies in your jurisdiction and your company's actual stance. This document essentially takes the negotiation standards that used to live only in a senior lawyer's head and writes them down where Claude can reference them — in other words, this customization step is functionally the same as onboarding a new associate and teaching them your company's contract review standards, except this time the one being taught is Claude. Where it lives is simple too: save it anywhere in a folder you've already shared with Cowork, and the plugin finds it automatically.
If your company operates outside the U.S., the first thing to do after installing the Legal Plugin isn't rushing to test `/review-contract` on a contract — it's spending the time to replace every clause in `legal.local.md` with what's standard in your jurisdiction. This only needs doing once; every contract review afterward builds on that customized standard. If your company happens to be based in the U.S. and follows contract conventions close to the example defaults, this particular risk affects you less. But the moment your honest answer is "I'm not actually sure which standard positions our company follows," that's exactly the gap this customization step is meant to close — better to treat it as a step the installation process can't skip, rather than an optional extra, than to end up with a report that looks credible but was never actually checked against the right legal framework.