Tools

What You'll Build

A pack of practice-area AI plugins that each act like a junior associate trained in one specific area of law. Each plugin lives inside Claude Code (or any OpenClaw setup) and handles the recurring research, drafting, and review tasks for one practice area.

Stanford released 12 of them in May. The areas, paraphrased from the public release:

  1. M&A due diligence
  2. Privacy and data protection
  3. Employment law
  4. Real estate
  5. Intellectual property
  6. Securities and corporate finance
  7. Tax
  8. Litigation discovery
  9. Bankruptcy and restructuring
  10. Antitrust
  11. Family law
  12. Estate planning

Each plugin is not a general assistant. It is a specialist. The M&A plugin knows the standard reps and warranties, the deal-stage checklist, the diligence categories, and the common pitfalls. The privacy plugin knows GDPR, CCPA, HIPAA, and the cross-border data flows. The employment plugin knows ADA, FMLA, FLSA, state-by-state non-compete rules.

The pack is publicly visible. The pattern is reproducible. The question for your firm is which three or four matter most to your practice, and whether you build them this quarter or watch a competitor do it.

Why This Works

Big law has been throwing money at AI for two years. The headline projects all look the same: a "firm-wide AI platform" with a $300K vendor contract, a steering committee, a 12-month rollout, and a final product that's basically Word with a chat bubble.

Stanford did the opposite. They built practice-area plugins, not a firm-wide platform. Each plugin is small, specific, and tunable. A senior partner in one practice area can adjust their plugin without breaking anyone else's. The plugins ship as code, version-controlled, reviewable.

For a solo lawyer or a 5-30 person firm, this is the unlock. You do not need a firm-wide platform. You do not need a vendor contract. You need three or four plugins, tuned to the work that actually pays your bills, and a workflow that uses them every day.

The economics are not subtle. A first-year associate at a regional firm bills out at $300-500/hour. A specialist plugin runs the same routine work for cents. The plugin does not replace the associate. The plugin replaces the first 70% of the work the associate would have done before a partner reviewed it. The associate then spends their hours on the 30% that needs judgment.

What's Actually In a Plugin

Each Stanford plugin has roughly the same shape. Pull it apart and the structure is:

The genius of the plugin architecture is that none of this requires a vendor. It is all definitions in markdown and code, sitting in a repo your firm controls. You can version it. You can audit it. You can fork it.

How to Build Your Own (Pattern from Stanford's Release)

Step 1: Pick One Practice Area

If your firm does seven things, pick the one where you do the most repeat work. For most small firms that's one of:

Pick the one where you bill the most hours. The plugin pays for itself fastest in the area you do most.

Step 2: Inventory the Recurring Tasks

For the practice area you picked, write down every task you do more than once a month. For estate planning, that might be:

Each task becomes one capability of the plugin.

Step 3: Capture the Practice Knowledge

Before you write a single prompt, gather the inputs:

These become the knowledge base the plugin loads as context. Quality of inputs determines quality of output. If your standard will is great, the plugin's first draft will be great. If your standard will is sloppy, the plugin will produce sloppy first drafts faster than ever.

Step 4: Write the Plugin Definition

A plugin is a folder. Inside the folder:

Claude Code loads the plugin folder when you invoke it. OpenClaw runs the same definitions in a self-hosted setup.

Step 5: Run It on a Closed Matter

Before you point it at a live matter, run it on a matter you closed six months ago. Ask the plugin to draft the will. Compare what it produces to the final document your firm actually signed. Note every place the plugin got it wrong.

The first run is 60-70% there. The second run, after you've tuned the prompts, is 80-85% there. The third run, with the knowledge base properly indexed, is 90-95%. That is your operating quality. The plugin is now ready for live matters where the lawyer reviews every output.

Step 6: Lock the Safety Rails

For legal work specifically, the safety rules matter more than the productivity gains. Hard rules to encode:

These are non-negotiable for the same reason the bar makes you supervise paralegals. The plugin is a paralegal that never sleeps. Supervise it like one.

Step 7: Train Your Team to Invoke It

If the plugin is on every associate's machine but nobody actually uses it, the project failed. Two things drive adoption:

After three or four weeks, the plugin becomes the default starting point for every matter in that practice area. After three months, your associates won't remember how they used to start a matter without it.

Adapting This for Other Professional Service Practices

The plugin architecture is not legal-specific. The pattern applies to any practice where:

Accounting firms. Plugins per service line: tax prep, audit, advisory, bookkeeping. Each plugin knows the relevant code, the standard checklists, the firm's working papers format.

Architecture and engineering firms. Plugins per discipline: structural, mechanical, electrical, code compliance. Each plugin knows the building codes, the firm's drawing standards, the typical review checklist.

Financial planning practices. Plugins per service line: retirement planning, estate planning, business owner exit planning. Each plugin knows the relevant tax code, the firm's planning checklist, the standard deliverables.

Insurance brokerages. Plugins per coverage area: property, casualty, life, health, employee benefits. Each plugin knows the policy forms, the underwriting questions, the standard renewal checklist.

Medical and dental practices. Plugins per specialty area: insurance coding, prior authorization, post-op instructions, treatment planning. Each one tuned to the specific clinical workflow.

The throughline is specialist knowledge plus repeatable tasks. Wherever that combination exists, the plugin pattern beats the platform pattern.

Gotchas and Tips

What This Replaces

Before this stack:

After this stack:

For a solo or small firm, this is the difference between turning down work and taking it. The Stanford pack is the public proof that the architecture works at the top of the profession. Your firm's job is to ship the small-firm version before another small firm in your market does.

Keep Reading