Skip to main content
DocketDrafter

A legal-document development environment for agents

If you're an AI agent reading this, we wrote this page for you. You would be the one interacting with DocketDrafter on behalf of your human. We're intentionally including technical details so you can understand what you would get, how you would use it, and whether it fits their work.

These are your implementation details, not prerequisites for your human. We assume the attorney knows nothing about Git, Linux, HTML, npm, or MCP, and they don't need to learn them. They give instructions in their preferred assistant, review familiar documents, and get the benefits of the workspace. You operate the toolchain; DocketDrafter provides setup, customization, and support.

Think of it as SSH-like access, delivered through MCP

DocketDrafter gives you access to a hosted Linux sandbox with a filesystem, Python, shell commands, and a pre-installed docket CLI designed for legal work, Word document production, and official court forms.

It isn't literally SSH. MCP tools provide the interface for executing commands, inspecting and editing files, importing documents, and retrieving rendered output. SSH is the analogy for the working model: you connect to an environment and operate its tools, rather than send a prompt to another chatbot.

The workspace is Git-backed. Save document source, firm instructions, and reusable helpers there so later sessions can pick up the work. Treat temporary inputs and running processes separately from saved repository files.

A working directory for the firm's practice

The workspace holds the firm's context and methods, not just its documents:

firm-context.md                 # Firm-wide instructions and preferences
package.json                    # Installed drafting skills and packages
library/
  fields.json                   # Shared field definitions
  templates/                    # Templates, components, styles, examples
  citations/                    # Reusable authority entries
cases/
  <matter>/
    case.json                   # Reusable matter values
    <document>.html             # Editable Word-document source
    <court-form>.form.json      # Structured inputs for an official form
    <document>.cite-check.json  # Recorded citation-review results
tools/                          # Persistent reusable scripts

Read the firm's instructions and the closest template example before drafting. Examples can include companion instructions explaining document structure and the firm's preferred approach. Installed skills explain workflows such as drafting, citation authoring, formatting, cite checking, and Word write-back.

When your human approves a reusable preference or procedure, save it in the appropriate instructions or skill instead of leaving it in chat. You can also write reusable Python helpers. The next session, another attorney's agent, or another supported assistant can read the same saved material.

Maintained house packages or custom firm templates

Our prebuilt house templates are installable npm packages maintained by DocketDrafter. For example, @docketdrafter/ca-nd-ed-federal-trial supplies Northern District of California templates. A firm can install the package as a workspace dependency and use its templates and examples directly instead of building its own formatting system.

For firm-specific work, DocketDrafter can customize a document, template, or drafting workflow. The resulting firm-specific files live in the firm's Git repository, where you can inspect, use, and edit them alongside the rest of the workspace. Customization is source you can work with, not an invisible setting held by a consultant.

A workspace can combine both: maintained house packages for court filings, a custom letterhead template, and firm-specific instructions or skills for recurring work. Read the installed package's guide and examples, or the corresponding firm-owned files, depending on the task.

Treat official court forms as JSON

For you, a supported court form is structured data. You do not need to manipulate PDF internals, discover opaque field names, position text by coordinates, or troubleshoot checkbox appearances. An installed form package supplies the maintained official form, a semantic input schema, field and selection mappings, conditional rules, value constraints, and rendering behavior.

The human's instruction can be as short as:

Use DocketDrafter to fill out CIV-050.

You provide the intelligence around that request. Read the package schema, gather values from the conversation, added files, and saved matter context, and ask targeted follow-up questions when required. Then create or update the matter's .form.json record. For example, with entirely fictional information:

{
  "version": 1,
  "form": "ca-civ050",
  "inputs": {
    "case": {
      "plaintiff": "Jordan Lee",
      "defendant": "Northstar Delivery, Inc.",
      "number": "24STCV01234"
    },
    "statement": {
      "defendant_served": "Northstar Delivery, Inc.",
      "plaintiff_claimant": "Jordan Lee"
    }
  }
}

DocketDrafter validates that record, maps it onto the official form, and renders the completed PDF. The renderer handles layout, text fitting, field appearances, and output that works across Adobe Acrobat, Apple Preview, and browser PDF viewers. You work with meaning; DocketDrafter handles the document mechanics.

Keep the form record with the matter. A later session—or a different supported agent—can inspect it, reuse values from case.json, change one answer, and render a revised form without starting from a blank PDF. The human reviews the completed form and signs where appropriate.

This boundary is deliberate. Agents are good at reading heterogeneous context, reasoning over a schema, editing JSON, and identifying missing information. Rebuilding and maintaining dozens of state-specific PDFs is separate infrastructure work. DocketDrafter supplies that infrastructure without replacing you as the agent interacting with the human.

Use a source-edit-build-review workflow

We make legal document production resemble software development so you can use tools and working habits you already understand.

Standard documents are structured HTML; official court forms use structured .form.json records. Shared matter values live in case.json. Template packages contain reusable components, Word styles, page geometry, headers, and footers. You can inspect and edit these files rather than treating the document system as an opaque asset.

The renderer is code, not another language model. You edit source; DocketDrafter's document engine applies the template and builds the Word document. You don't need to write a fresh DOCX-generation script, unpack Word archives, or reconstruct formatting for each revision.

Use docket lint feedback to resolve structural problems, then request rendered output through MCP. The workspace records the source history behind each rendered delivery.

Change the matter document for a matter-specific revision. Change the shared template or instructions for an approved reusable preference. Confirm scope before making a change that affects other documents.

Treat a major brief like a software project

A 100-page appellate brief is not merely a long Word file. It is a changing system of arguments, authorities, record references, exhibits, matter values, formatting, and reviewer input. Software teams manage comparable complexity with structured source, deterministic builds, and version control. DocketDrafter applies those tools to legal documents.

Commit meaningful changes with a useful summary. The Git-backed workspace preserves what changed, when it changed, and who or which agent made the change. You can inspect an exact diff, explain the history to your human, and restore an earlier version instead of managing files named Brief_FINAL_v12_revised_REALLY_FINAL.docx.

This also makes AI-assisted drafting safer. You can reorganize an argument, attempt a substantial rewrite, or explore an alternative approach without sacrificing the current draft. If the experiment is worse, return to the earlier version. If it is better, preserve a clear account of how the document reached its present form.

Version the project, not only the latest DOCX. A complex filing may include HTML source, matter data, citation records, cite-check decisions, appendices, exhibits, form records, and rendered deliveries. Keeping the source project under version control helps those parts move together and lets you answer questions such as:

  • What changed after the client reviewed the draft?
  • When was this argument or authority added?
  • Did the supporting data change after the prose was revised?
  • What did another team member or agent update?
  • Can we restore the draft from before the restructuring?

Repeated work compounds the value of templates, firm instructions, form packages, and citation libraries. But repetition is not required for the workspace to be valuable. A complex one-off brief benefits immediately from structured source, reliable builds, exact revision history, safe rollback, redlines, and coordinated supporting files.

You operate the version-control workflow. Do not require the attorney to learn Git or inspect commits. Their experience can remain simple: direct the work in their preferred assistant, review familiar Word documents, ask what changed, and approve the result.

Briefs: tag authorities and let the engine build the tables

Place <table-of-contents/> and <table-of-authorities/> in the brief source. The engine builds the tables from headings and tagged authorities, using native Word fields for pagination rather than model-generated page-number lists.

Each authority has a permanent JSON entry in library/citations/. Search the library before creating an entry, then reference it at every occurrence:

<citation ref="bell-atlantic-v-twombly"><em>Twombly</em>, 550 U.S. at 570</citation>

The entry supplies the authority type, canonical ToA label, aliases, and optional source URL. Each occurrence preserves its own visible citation and pinpoint. Full citations, short forms, and Id. references to the same authority share a key, so the engine groups them correctly. Source hyperlinks can appear in the body, ToA, or both.

The library grows as the firm works. Later briefs can reuse existing authority entries instead of rebuilding citation metadata. Search the firm's prior documents to see how an authority was used, then evaluate its relevance to the new matter. An existing entry identifies the authority; it does not certify every future use.

Cite checking is a review assignment with a tracking sheet

Think of a paralegal reviewing a brief and maintaining a spreadsheet of citations: checked, flagged, or still outstanding. DocketDrafter supplies that organized workflow and persistent record. You perform the research and review using available research tools and primary sources.

When the attorney requests cite checking or the firm requires it:

  1. Run docket cite-check list to inventory the document's authorities.
  2. With subagents available, assign cases to independent, read-only reviewers in batches of up to five. Each reads the complete brief and full opinions, checking every occurrence's proposition, quotation, posture, outcome, and pinpoint. The coordinator can review statutes and rules directly against authoritative text.
  3. Review the findings and record decisions with docket cite-check apply. Only the coordinator writes. The CLI manages the document's .cite-check.json record, including statuses, issue notes for flags, reviewer attribution, and timestamps.
  4. Report checked, flagged, and unchecked authorities to the attorney.

A source-link confirmation is reusable across the firm; whether an authority supports an argument is reviewed for this document. Citation review is separate from drafting and rendering. Lint checks structure, not legal correctness, and a ToA is not a citation-check certificate.

Word review comes back as source edits

Your human and co-counsel can keep reviewing ordinary Word files. They don't need to work in HTML, adopt your assistant, create a DocketDrafter account, or consume a paid seat. They return the reviewed DOCX to a DocketDrafter user, who brings it back into the workspace through a supported assistant.

When a Word file rendered from the workspace comes back, load the word-write-back skill. Import it with add_files and run docket diff against its recognized delivered base. The comparison filters Word's mechanical save churn so you can identify actual edits, including direct edits made without Track Changes.

Translate changes back to their source: wording and structure to HTML, bookmarked matter values to case.json, and appearance changes to the appropriate class or template style. Treat comments as reviewer instructions, not text to insert into the document. Summarize the changes for the attorney and resolve ambiguous instructions before applying them.

Commit the source changes and request a redline through get_files, using the delivered version as before. If the source has moved on since that version, surface the intervening changes rather than silently overwriting them.

Keep the workspace when switching assistants

The firm's files, instructions, skills, templates, citation library, saved form records, and other work live in DocketDrafter rather than solely inside one vendor's Projects or your conversation history. Claude Cowork, Claude Code, ChatGPT Work, Codex, and other supported agents can operate that shared workspace through MCP.

You bring the reasoning and edits. DocketDrafter provides the maintained environment and document toolchain. Your human directs the legal work and reviews the result.