Law company using ShipifyAI

ShipifyAI was originally designed for software teams, but the same workflow maps cleanly onto any organisation that produces text artefacts in a versioned repository, has a board of work items, and announces results on a chat channel. A law firm fits the model well. Contracts, memos, opinions, and regulatory analyses are textual artefacts that benefit from version control, peer review, and a record of changes. Legal work also benefits from a focused AI assistant that has been told exactly which sources of law to consult and exactly what conventions to follow.

This article walks through the setup of ShipifyAI for a fictional mid-sized law firm. It covers how to structure the Jira board, the document repository, and the Slack channel, how to write a `CLAUDE.md` tailored for legal drafting, and which MCP servers to allow so that the AI can analyse legislation safely and reliably.

The scenario

The firm has a partner who oversees the contracts practice, three associates who draft and revise documents, and a paralegal team that handles intake and filing. The firm maintains a private repository of contract templates, a knowledge base of memos on recurring questions, and a regulatory watch document that flags changes to relevant statutes. Right now everything is done manually. The partners want to use AI to speed up first-pass drafting and regulatory analysis, while keeping a human in the review seat for everything that goes to a client.

ShipifyAI's role is to take a structured task from Jira, hand it to Claude with the firm's conventions and source restrictions, produce a draft document committed to the repository, open a pull request for human review, and post the link in Slack. Nothing leaves the firm without an associate or partner approving the merge.

Setting up the document repository

The firm uses GitHub as its document repository, with private access restricted to the legal team. The repository is structured to mirror the firm's practice. There is a `templates` directory containing master copies of standard contracts, organised by type, such as employment agreements, NDAs, master services agreements, and licensing agreements. There is a `memos` directory containing internal research memos, organised by client and matter. There is a `regulatory-watch` directory containing analyses of recent statutory changes, organised by jurisdiction and topic. There is a `clients` directory, restricted further by branch protection, containing client-specific drafts.

The ShipifyAI CLI writes its drafts as Markdown — that is the format the agent emits to the branch, because plain-text diffs make pull request review meaningful, branches stay tidy, and the AI can produce changes the same way it produces code. What the firm does with that Markdown once a lawyer has reviewed it is entirely the firm's call, and outside ShipifyAI's scope. Some matters end with a CI pipeline rendering the Markdown into PDF in the firm's house style; some with the text pasted into Word for the partner's red-pen pass; some with the draft copied straight into the client engagement system or the document management system. ShipifyAI's contribution ends with the draft on the branch.

A key difference compared with the software scenario is that pull requests in the law firm are not a gate to merging. They are a delivery channel. The AI's deliverable is the draft itself, sitting on a feature branch, with a pull request that gives the lawyer a structured place to read the diff, click through citations, and pick up the work. Most drafts are never merged into the default branch at all. The lawyer reviews the draft on the branch, copies the prepared text into the client engagement system, the email, the document management system, or the firm's PDF render, and that completes the task. The branch can then be deleted or kept for record. Nothing has to land on the default branch for the work to be considered done.

The default branch is reserved for the canonical, firm-wide artefacts: master template versions, published memos, and the consolidated regulatory watch document. Changes there happen rarely, and they happen through deliberate, partner-led merges, often as a separate housekeeping task that is not driven by the AI at all. Direct pushes to the default branch are still forbidden through branch protection, and the few merges that do happen still go through human approval. But the bulk of the AI's output never touches the default branch.

This shifts how branch protection is configured. The default branch still requires a pull request and at least one approval from a partner before merging, and required status checks still include a linter that verifies front matter integrity and a compliance check that flags forbidden terms. But the firm does not pressure lawyers to merge AI feature branches. The expected lifecycle of an AI branch is: produced by the worker, reviewed by a lawyer, the draft is taken into the client deliverable, the branch is closed. A merge is the exception, used only when the firm decides the draft itself is worth keeping in the canonical repository, for example when an AI-produced regulatory analysis is good enough to become a published memo.

The GitHub Personal Access Token used by the worker follows exactly the same rules as in the software scenario. It is a fine-grained token, scoped to this single repository, with Read and write permissions on Contents and Pull requests, Read-only on Metadata, and no Administration permission. The worker can therefore push feature branches and open pull requests, but it cannot bypass branch protection on the default branch and it cannot merge anything itself.

Setting up the Jira board

The Jira project mirrors the practice areas. Each issue represents a unit of work, such as drafting a particular clause, reviewing a contract against the latest regulation, summarising a recent court decision, or producing a regulatory watch entry for a new act of parliament.

The board has four columns that match the ShipifyShipifyAIHub model. The source column, named "Ready for AI drafting", holds tasks that have been screened by the partner and are deemed safe and useful for AI to draft. The In Progress column holds tasks the AI is currently working on. The In Review column, which the firm renames "Ready for pickup", holds tasks where the AI has produced a draft on a feature branch and a pull request has been opened. From this column a lawyer takes the draft into the actual client deliverable. The Incomplete column holds tasks the AI returned because the description was insufficient or because the matter required human judgement before drafting could begin.

A task moves out of "Ready for pickup" the moment a lawyer has used the draft. Whether the underlying pull request is merged, closed without merging, or left open as a record is a separate decision that does not affect the workflow. Most often the pull request is closed without merging once the lawyer has copied the relevant text into the client deliverable.

The board has a fifth column, "Backlog", which is not visible to the AI. The intake paralegal lands every new task there. The supervising partner reviews each task, decides whether it is appropriate for AI drafting, and only then moves it to "Ready for AI drafting". This intake step is the firm's primary safety gate. Anything sensitive, anything involving live litigation, anything where confidentiality concerns are heightened, is never moved to the AI column. It stays with humans throughout.

The minimum wait time on the project is set to one full business day. This means the AI never picks a task in the same hour it was approved. An associate has a window to claim a task they are personally interested in before the AI does. This preserves apprenticeship and the training value of drafting work.

Setting up the Slack channel

The firm uses Slack for internal coordination. A dedicated channel, `#legal-ai`, is configured as the project's notification channel in ShipifyAI. The channel is restricted to lawyers and the practice manager. Notifications it receives include the announcement that a draft is ready for pickup, with a link to the pull request that holds the draft, and the announcement that the AI was unable to complete a task and the reason why. The link in the notification is the lawyer's entry point: they click through, read the diff, and take the work from there. The channel is a recap of the AI's activity, not a substitute for the firm's main coordination channel.

The Slack Bot Token is generated and configured exactly as described in the worker configuration article, with the same four scopes. The bot is invited explicitly to `#legal-ai` and to no other channel. It cannot post elsewhere by accident.

Writing a CLAUDE.md for the legal context

The `CLAUDE.md` file is where the firm's conventions are taught to the AI. It is the most important file in the repository for the quality of the drafts produced, and it is worth investing time in.

The file opens with a project overview that explains what the repository is for, what kinds of documents live in it, and who reads them. It explains the firm's domain, its jurisdictions, its principal practice areas, and the languages in which it works. The AI then knows that "the act" probably refers to a specific national statute, that "the client" implies a particular contractual relationship, and that drafts must be in the same language as the rest of the matter unless otherwise specified.

The file describes the structure of the repository, naming the templates directory, the memos directory, the regulatory watch directory, and explaining what kind of artefact lives where. It tells the AI that template changes propagate to clients only through the deliberate action of a lawyer pulling the latest template into a specific engagement, so a template edit must never silently change client documents.

The file describes the firm's house style. This includes formatting conventions, such as the use of recitals and definitions in contracts, the use of numbered headings, and the way cross-references are written. It includes terminology preferences, such as "agrees to" instead of "shall", or vice versa, depending on the firm. It includes language and tone preferences, such as plain English in client-facing memos and formal register in court submissions. It includes the firm's preferred citation format for case law and statutes.

The file also lists what the AI must never do. It must never draft an opinion that purports to be legal advice without explicit human review. It must never invent case citations, never hallucinate statutory references, and never claim regulatory facts that are not supported by a citation to one of the allowed MCP sources. It must never include client-identifying information in templates or in regulatory analyses. It must never bypass the review gate by trying to push directly to the default branch.

The file ends with a checks section, parallel to the software version. Before considering a task complete the AI must run the firm's lint script, which validates document front matter and checks for forbidden terms. It must verify every legal citation by querying the appropriate MCP server. It must produce a summary of the change in the pull request body, written for the reviewing lawyer. It must include a confidence note where the source of law is contested or recent.

Allowed MCP servers for legal analysis

This is where the law firm scenario diverges most clearly from the software scenario. The AI in a legal context needs structured access to authoritative legal sources, and it must not be allowed to fabricate them. MCP servers are the right tool because they expose a typed interface that the AI can call by name, and the firm controls which servers are connected and what they expose.

The firm enables a small, curated set of MCP servers on the worker machine, configured in `~/.claude/mcp.json`. The list is intentionally narrow.

• A statutes MCP server, connected to the official electronic gazette of the firm's primary jurisdiction. The server exposes a search interface that returns the consolidated text of an act by name and a date, plus a fetch interface that returns the full text of a specific provision by reference. The server should be backed by an official source such as the national legislature's open data feed, not a third-party paraphrase. The AI is instructed to cite by official reference and to include the consolidation date.
• A case law MCP server, connected to a vetted database of court decisions. The server exposes search by court, by date range, by parties, and by keyword, and fetch by case identifier. The firm's research librarian curates the list of databases the server can talk to. The AI is instructed to verify every citation and never to write a quote it has not retrieved.
• A regulatory tracker MCP server, connected to the firm's internal regulatory watch service. The server exposes a feed of recent statutory changes with effective dates and short summaries. The AI uses it to detect when a contract template references an act that has been amended.
• A firm knowledge MCP server, scoped to the firm's own memos directory. The server exposes search across past internal memos so that the AI can find prior firm positions on a recurring question and cite them in new drafts.
• A filesystem MCP server, scoped to the working directory of the repository. This is the same MCP recommended in the software scenario.

The firm explicitly does not connect MCP servers that the AI could use to bypass the security model. There is no MCP server connected to the firm's email, calendar, document management system, billing system, or client portal. There is no MCP server connected to Jira directly, since all task transitions go through the ShipifyAI backend just as in the software scenario. There is no MCP server that can fetch arbitrary URLs from the open internet, because that would let the AI cite a blog post as if it were authoritative law.

The MCP configuration file lists the chosen servers under `mcpServers`, naming each one and specifying the command that runs it. Each server runs as a child process of Claude Code on the worker machine, with its own credentials managed inside the server itself, and only the typed interface is exposed to the AI. The credentials of the statutes server, the case law server, and the regulatory tracker live in environment variables on the worker, separate from any other secret. The firm rotates these credentials on the same schedule as the GitHub PAT.

Skills for legal drafting

The firm ships its own skill pack inside `.claude/skills`, parallel to the software scenario but tailored for legal work.

A `cite-law` skill describes when and how to cite a statutory provision, a case, or an internal memo, and explicitly forbids citing anything that has not been retrieved through one of the allowed MCP servers. The skill names the firm's preferred citation format, gives examples of correct citations, and lists the MCP server that is the source of truth for each kind of citation.

A `draft-clause` skill describes the standard structure of a clause in the firm's house style, including how to write definitions, how to handle defined terms in plural and possessive, how to phrase representations and warranties, and how to handle limitations of liability. The skill instructs the AI to look up the firm's preferred wording in the templates directory before drafting from scratch.

A `regulatory-analysis` skill describes how to produce a regulatory watch entry. The skill instructs the AI to retrieve the current consolidated text of the relevant act through the statutes MCP server, retrieve the most recent amendments through the regulatory tracker, retrieve any case law interpreting the changed provisions through the case law MCP, and produce a memo with the firm's standard structure: summary at the top, list of changes with effective dates, practical impact section, action items section. The skill enforces a definition of done that includes verified citations, a stated consolidation date, and a paragraph in plain language that any partner can paste directly into a client email.

A `compare-template` skill describes how to compare an existing contract template against a recent statutory change, identify clauses that may need updating, and propose specific edits. The skill instructs the AI to mark every proposed edit as a suggestion, never to silently rewrite a template, and to include a justification with statutory citation for each suggested change.

A `self-review-legal` skill mirrors the software self-review skill but adapted for legal artefacts. It instructs the AI to re-read the draft as a sceptical reviewer, to check that every legal claim is backed by a citation, to verify that no client confidential information has slipped into a template or memo, and to check that the draft language is consistent with the matter's language and the firm's tone for that document type.

Iterating with the AI through review comments

The lawyer is not limited to taking the first draft as-is. The same PR review follow-up loop that the software workflow uses is available in the law firm scenario, and it is the natural way to push corrections back to the AI without rewriting the draft by hand.

Every pull request opened by the worker has a title that starts with `[AI GENERATED]`. As long as that prefix is in the title, the AI will keep watching the pull request and will respond to review comments on it. A lawyer who wants the AI to revise something writes a review comment on the relevant line or block of text, exactly as a senior associate would write feedback for a junior. The comment can ask for a different formulation, a softer or harsher tone, a missing recital, an additional citation, a clause to be split into two, or any other concrete change. The comment is the instruction.

Six hours after the comment is posted, the worker treats the thread as actionable, posts a thumbs-up reaction as an acknowledgement that work has started, and asks Claude to address the comment in the context of the current branch. If Claude makes the change it commits the edit to the same feature branch with a message starting `[AI GENERATED] address review comment`, pushes the branch, and replies on the thread with `done [AI GENERATED]`. If Claude judges the comment incorrect or out of scope, it replies with `[AI GENERATED] declining` and a one-sentence reason, and leaves the text unchanged. The lawyer sees the response in the same thread on GitHub and decides whether to push back, accept the decline, or take over manually.

Several practical patterns are worth noting. The six-hour minimum delay exists deliberately so that quick clarifications between lawyers do not trigger AI responses. If a lawyer leaves multiple comments at once, the AI handles each thread independently in its next iteration cycle. A thread becomes inactive once the bot has replied with `done`, so a follow-up comment after `done` is needed to re-open the conversation; the worker treats the new human comment as the new actionable state and waits another six hours. A thread that the lawyer resolves manually is skipped by the AI entirely, which is the right tool when the lawyer has handled the comment themselves and does not want the AI to act on it.

This loop is what makes the "draft on a branch, take it from there" model practical. The lawyer does not need to perfect every draft by hand. They can hand back specific corrections, get a revised version a few hours later, and only then decide whether to use the draft as a deliverable, merge it into the canonical repository, or discard the branch.

If at any point the lawyer wants to take the pull request out of the AI's view, they remove the `[AI GENERATED]` prefix from the title. The control article describes this and the other take-over paths in detail.

Security and confidentiality

The four pillars of ShipifyAI's security model apply to the law firm scenario as they do to the software scenario, with a few legal-specific reinforcements.

The worker runs on a dedicated, isolated machine with no client confidential data outside the active matter. The firm runs separate workers for engagements that have heightened confidentiality obligations, so that an opinion drafted for one client never sees the documents of another. The worker machine has no email client, no document management system credentials, and no access to the firm's billing or time-keeping systems. The AI sees only the repository it is working on and the MCP servers explicitly listed in the configuration.

The AI does not modify Jira directly. The supervising partner's intake decisions are the firm's primary safety gate, and the worker only ever sees tasks that the partner has approved into the source column. Comments on Jira issues, marking a task as Incomplete, and transitioning to "Ready for pickup" all go through the ShipifyAI backend, which gives the firm a single audit trail of every state change.

The AI cannot push to the default branch. The AI's working artefact is always a feature branch with a pull request, and the lawyer takes the draft from there into the client deliverable without merging in most cases. When the firm does decide to merge a draft into the canonical repository, branch protection ensures the merge passes through human approval, exactly as in the software scenario.

The AI is not given the structural ability to push to the default branch. The PAT scope refuses it, the deny list in the Claude settings refuses it, the CLI's branching logic does not produce such pushes, and even if all of those failed, the branch protection rule on the GitHub side would reject the operation. The defence is layered.

In addition to the standard four pillars, the firm enables an egress firewall on the worker machine that allows outbound traffic only to the GitHub API, the ShipifyAI backend, the Anthropic API, the Slack API, and the specific endpoints of the allowed MCP servers. The AI cannot reach the open internet from the worker, so it cannot exfiltrate text and it cannot fetch arbitrary URLs that pretend to be law. The firm also enables read-only mounts for everything outside the project working directory and rotates the worker container daily, so that any state accumulated during a session is gone the next morning.

A typical task end-to-end

Consider how a single task flows through this setup. A new act amends a section of the country's labour code, and the firm's regulatory librarian creates a Jira issue titled "Update employment template to reflect the amendment to article 29 of the labour code, effective next quarter". The supervising partner reviews the issue, judges it appropriate for AI drafting, adds a brief description with the official act reference, and moves it from Backlog to "Ready for AI drafting". The minimum wait time of one business day ticks down.

The next morning the worker picks up the task. Claude reads `CLAUDE.md`, loads the relevant skills, retrieves the consolidated text of the amended labour code provision through the statutes MCP server, retrieves the explanatory memorandum through the regulatory tracker, and locates the firm's existing employment template in the repository. It compares the template against the new provision, identifies two clauses that conflict with the amendment and three that need supplementary wording, and produces a feature branch with the proposed edits. Each edit is annotated with a comment explaining the change and citing the act and section number.

The AI then runs the firm's lint script, runs the cite-law skill to verify every citation, runs the self-review-legal skill to check for confidential information, and opens a pull request titled "[AI GENERATED] Update employment template to reflect labour code amendment article 29". The pull request body explains the change in plain language, lists every citation, and notes the effective date of the amendment. The Slack bot posts the link to `#legal-ai` and the Jira task moves to "Ready for pickup".

A senior associate opens the pull request, reads the diff alongside the cited statutory text, accepts two of the proposed wording changes, decides one needs a rewording, and judges two as not warranted. The associate then takes the relevant text directly from the feature branch into the client engagement, blending the AI's draft with their own edits. The pull request itself is closed without merging once the work has been incorporated. If the associate had wanted to ask the AI for a rewording first, they would have left a review comment on the thread; six hours later the worker would have addressed the actionable thread, made the change, replied `done [AI GENERATED]`, and pushed the updated text to the same branch for the associate to pick up.

The Jira task moves to the firm's Done column the moment the lawyer has used the draft, regardless of whether the underlying pull request was merged or simply closed. The Slack channel announces the pickup. Nothing on the default branch needed to change for the task to be considered done.

At every step a human controls the gate. The intake partner decides what the AI works on. The reviewing associate decides what part of the draft is good enough to use, what needs a rewording, and what gets discarded. The AI does the bulk of the mechanical drafting and citation verification, which is exactly the kind of work that benefits from automation, while the legal judgement remains entirely with the lawyers.

Where to go next

The worker configuration article explains how to obtain and install each integration token in detail. The Claude configuration article explains how to write `CLAUDE.md`, how to author skills, and how to configure the allowList. The control article explains how a lawyer takes a draft or a task back from the AI at any point. The security article explains the four pillars in depth, including the rationale behind each layer of defence.