Plugins and Agents: Packaging a Practice's Playbook for Deployment

A plugin is how a practice's playbook gets packaged, versioned and handed to a colleague who was not in the room when you built it. It is a folder that bundles the skills, the slash commands, the playbook file, the connector configuration and a manifest that names and versions the lot. Install it and everything arrives together, at a known version. That is the difference between a clever colleague and a capability the practice owns.

A brilliant playbook on one laptop is worth almost nothing. A skill on one associate's machine has all the properties of a precedent saved to the desktop of somebody who has since gone to a competitor. Nobody else knows it exists. There is no version, so two people running it are running different reviews. This is where most practices stall, and the reason is not technical.

What packaging changes

Wrapping a skill in a plugin solves a class of problem at once:

• Discovery. A catalogue people browse, rather than folklore.
• Versioning. Two reviews are the same review because they are the same version.
• Configuration. Connectors ship with the skills that need them.
• Review. A change is a diff, and a diff can be approved.
• Withdrawal. You can pull a bad version; you cannot pull a habit.

Everything in a plugin is markdown and JSON, with no compilation step, so your risk function can read the artefact you are shipping.

The anatomy of a plugin

A real plugin from the open legal library, reduced, is five directories and one manifest:

• plugin.json carries identity and version. It is what makes the plugin installable and rollback possible.
• skills/ holds the workflows from the skills layer. Some are user-invocable; some are reference material other skills load when they detect a document type.
• agents/ holds named workers that own a sequence end to end.
• hooks/ holds shell commands run at fixed lifecycle points. Empty in most reference plugins, and the most important directory for a practice.
• .mcp.json holds the connectors from the connections layer, shipped alongside the skills that need them.

A pattern worth noticing: several legal skills are marked not user-invocable. The SaaS review, for instance, is loaded by the general contract review skill when it detects a subscription agreement. Keep the entry points few and the specialisations many. And every published legal plugin reads a configuration file holding your positions, thresholds and house format. Treat that file as the crown jewels: it is the only part of the system that is genuinely yours.

How a plugin reaches a colleague

A marketplace is one JSON file, placed in a repository your team can reach. Private repositories work exactly as public ones do, so an internal repository becomes an internal catalogue. Set this up before you have five plugins: one place with branch protection and a named reviewer, plugin.json bumped on every functional change, and each plugin owned by a named partner or GC.

The published library is organised into thirteen practice areas, by the work rather than the technology. Where to start is not the practice area with the most interesting problems. It is the one with the highest volume of near-identical work and the clearest playbook, usually commercial contract review.

The anatomy of an agent

An agent definition is a markdown file with frontmatter carrying a name, a description saying precisely when to use it, and a tools line listing what it is permitted to touch. The body reads like a good handover note to a competent new joiner. Write three things, in order:

• Scope. What it produces, named as artefacts. Two files, not "help with diligence".
• Workflow. Numbered steps naming which skill each invokes, reading as an auditable procedure.
• Guardrails. Absolutes. No external communications. Nothing docketed. Nothing filed.

The tools line is the control. A guardrail written as a sentence in the body is a request; the same guardrail expressed as an absent capability is a guarantee. Write the sentence anyway, because it tells a reviewer what you intended, then make it true in the tools line and apply the test: delete the sentence, and check whether the constraint still holds.

Every scheduled worker in the library ships with a warnings section. Four failure modes run through them: computed outputs are leads, not entries; classifications are heuristic, so read the filing and do not trust the label; triage is routing, not review, so read the whole radar and not only the flagged items; and your calibration is not law. When you build your own agent, write the warnings first. They force you to be precise about what the thing actually claims, and they are the section your risk committee reads.

Hooks: the only part that enforces

Everything else in a plugin asks the model to behave. A hook is a command the runtime executes at a fixed lifecycle point, whatever the model intended. Three events carry most of the value:

• PreToolUse fires before a tool call and is the only event that can stop it. A hook that blocks reads outside the active matter is an information barrier, not an instruction. It runs whether or not the model was persuaded.
• PostToolUse fires after, for logging or verification. It can write every access to your log. It cannot undo: by the time it fires, the document was read.
• UserPromptSubmit fires when a prompt is submitted and can inject the active matter and its restrictions, so nobody has to remember to.

This is the distinction the whole series turns on. A prompt asks the model not to do the thing, and usually works. A tools line means the model cannot do the thing at all. A hook runs your code before it happens and can refuse, with a reason. Use all three, because they fail differently. One caution: hooks run arbitrary code with the installing user's permissions, so review them like any dependency.

Govern it like software, because it is software

The moment a plugin is installed by somebody who did not write it, you have a supply chain: an artefact produced by one team, consumed by another, that changes what happens to client matter data. This is a solved problem your IT function already solved. Apply the existing machinery: version control with branch protection, a named reviewer who is not the author, a version bump on every functional change, testing against a closed matter first, and a documented rollback tried at least once.

The one thing worth adding: some changes are changes to a control. Editing a memo template is not. Editing the checks file, widening a tools line, adding a write-capable connector, or loosening matter isolation is. Those should route to whoever signs off risk changes today.

Build your first internal plugin small: one practice area, three to five skills, one read-only connector, no scheduled workers, owned by one named lawyer and run for a full cycle before anyone widens it. If that sounds boring, it is working. Agents come after you have run the same review forty times. For the whole argument, read the AI guide for legal practice.

Ready to go further? Download the five-part legal series, or send us a workflow and we will tell you plainly whether it is worth building.