No-Code Workflows for Lawyers: 3 You Can Build in Claude

The Short Answer

A no-code workflow for a lawyer is a repeatable task you run the same way every time without writing software, and with Claude you can build one using three things you already have on a paid plan: a Project (persistent instructions and reference files), a saved prompt (the fixed ask), and a consistent input (the notes, transcript, or document you paste in). You do not need an automation platform, an API key, or anyone from IT. The three workflows below are built with nothing but Claude, and each one is in daily use at small firms in some form.

The reason to be precise about "no-code" is that the phrase has been colonized by automation-platform marketing, where it means wiring apps together with triggers and actions. That is a real category and some firms need it. But most of what a solo or small-firm lawyer wants from a "workflow" is consistency: the same intake summary format every time, the same client-update structure after every hearing, the same triage questions on every incoming NDA. Consistency is a prompt-and-Project problem, not an integration problem, and it is solved in an afternoon.

What "No-Code" Means Inside Claude

Four features do the work, and none involves code.

• Projects. A Project is a container with standing instructions and uploaded reference files that every conversation inside it inherits. Put your firm's summary format, your preferred tone, your jurisdiction, and a sample of your best work in the Project instructions once, and every new chat starts already knowing them. The reusable Project workflow walks through setting one up.
• Saved prompts. A prompt you have tested and keep in a text file, a snippet tool, or the Project instructions themselves. The workflow is the prompt; the Project is where it lives. Our prompt library has starting points, and the prompting guide explains the structure that makes them reliable.
• The legal plugin toolkit. Claude for Legal, Anthropic's open-source legal toolkit released in May 2026, bundles practice-area plugins and workflow agents that run through Claude's Cowork desktop agent on any paid plan. It is the pre-built version of what this post shows you how to build by hand; the setup guide covers installation. If you would rather start from a configured toolkit and customize, begin there.
• Connectors. Claude can connect to document stores, calendars, and email through MCP connectors. They are optional for everything in this post. A connector saves you the paste step; it does not change the workflow, and it adds a data-terms question you should answer before enabling it.

What is deliberately absent: automation platforms, custom GPT-style bots, scripts, and anything that needs a developer. Those exist and can be layered on later. The three workflows below run entirely inside a Claude window.

Workflow 1: Intake Notes to Client Summary

Input: your raw notes from an initial consultation, typed or dictated, in whatever shape they came out. Output: a structured intake summary in your firm's format, a list of open questions, and a draft follow-up email to the prospective client.

Project setup (once): Create a Project called Intake. In the instructions, paste your intake summary template (the headings you always use: parties, facts, timeline, claims or issues, documents mentioned, deadlines mentioned, conflicts check inputs, fee discussion), your jurisdiction, and one anonymized example of a summary you were happy with. Add a standing rule: "Where my notes are silent on a heading, write NOT DISCUSSED rather than inferring."

The prompt (every time):

Here are my raw notes from an initial consultation today. Produce:
1. An intake summary using the Project template, in the same order.
   Write NOT DISCUSSED under any heading my notes do not cover.
2. A list of the questions I should have asked and did not, grouped
   by heading.
3. A short follow-up email to the prospective client confirming
   what we discussed, listing the documents I asked them to send,
   and stating that no engagement exists until a signed agreement.
   Do not give legal advice in the email.

Notes:
[PASTE NOTES]

The NOT DISCUSSED rule is the whole reason this works. Without it, the summary quietly fills in facts you did not gather, and an intake summary that looks complete but is not is worse than a messy one. With it, the "questions I should have asked" list becomes your call-back agenda. Keep client identifiers minimal and run intake on a commercial tier, since a prospective client's information is confidential even before engagement.

Workflow 2: Hearing Notes to Client Update

Input: your notes from a hearing, status conference, or deposition day, plus the date and matter name. Output: a plain-English client update, a list of new deadlines to calendar, and a task list for you.

Project setup (once): A Project called Client Updates, with instructions covering your voice (formal, warm, no jargon), a rule that every deadline must appear as "the court set" or "opposing counsel agreed" rather than as a computed date, and a template with three sections: What happened, What it means for you, What happens next. Add one sample update you have actually sent, with the client details replaced.

The prompt (every time):

These are my notes from today's [hearing / conference / deposition]
in [MATTER]. Produce:
1. A client update in the Project template. Explain any procedural
   term the first time it appears, in plain English. Do not predict
   outcomes. Do not compute dates; state deadlines exactly as my
   notes state them.
2. A table of every deadline or scheduled event mentioned, with the
   source (court order, agreement of counsel, my own commitment).
3. A task list for me, ordered by the earliest deadline each task
   serves.

Notes:
[PASTE NOTES]

Two rules carry this workflow. "Do not predict outcomes" keeps the update from drifting into reassurance you cannot back. "Do not compute dates" keeps the deadline table honest: if your notes say "expert disclosures 60 days out," the table says that, and you compute the date under the local rules, using the deadline workflow if the order is long. The update goes out under your name after you have read every line; the disclosure guide covers whether and how to tell clients AI helped draft it.

Workflow 3: NDA Triage

Input: an incoming NDA, usually from the other side's template. Output: a verdict (sign, sign with these three changes, or escalate to full review), the specific clauses driving the verdict, and redline language for the changes.

Project setup (once): A Project called NDA Triage. In the instructions, define your client's standard positions: mutual versus one-way, term of confidentiality, carve-outs you require (independently developed, publicly available, required by law with notice), no non-solicit or non-compete hidden in an NDA, governing law preference, and the list of clauses that always trigger escalation (residuals, assignment to competitors, injunctive relief without bond). Upload your client's own preferred NDA as the reference form.

The prompt (every time):

I represent the [RECEIVING / DISCLOSING / both] party. Compare the
attached NDA to the Project's standard positions and reference
form. Produce:
1. A verdict: SIGN AS IS, SIGN WITH CHANGES, or ESCALATE, with one
   sentence of reasoning.
2. A table of every deviation from our standard positions:
   Clause | Section | What it says | Our position | Severity.
3. For each High-severity deviation, proposed replacement language
   matching the NDA's defined terms, and a one-line rationale for
   opposing counsel.
4. Anything in the NDA that is not confidentiality-related
   (non-solicit, non-compete, exclusivity, IP assignment), flagged
   separately regardless of severity.

[UPLOAD NDA]

This is the workflow that most obviously replaces a "platform." A triage rule set that lives in Project instructions is editable in seconds when the client's positions change, produces a consistent verdict, and costs nothing beyond the plan you already pay for. The longer version, with a triage rubric for other routine contracts, is the NDA and contract triage workflow. The fourth item in the prompt, the not-confidentiality-related flag, catches the non-compete smuggled into an NDA more reliably than a tired reader does at 6 p.m.

Making a Workflow Stick

Three habits separate a workflow you use from a prompt you tried once.

• One Project per workflow, not one Project per matter. The Project holds the method; the matter goes in the conversation. When the method improves, you edit one place.
• Put the negative rules in the Project, not the prompt. "Write NOT DISCUSSED," "do not compute dates," "do not predict outcomes" belong in standing instructions so you cannot forget them on a busy day. The over-prompting post explains why a few sharp rules beat a page of instructions.
• Test on an old file before a live one. Run the intake workflow on a consultation from last year where you know what the summary should say. If the output diverges, fix the Project instructions, not the prompt.

When You Actually Need More Than Claude

Honesty about the boundary: a Claude-only workflow requires a person to start it. If the task is "every time a document lands in this folder, do X without anyone noticing," that is a trigger, and triggers are what automation platforms and connectors provide. The same applies to workflows that must write into a practice-management system, or that run across dozens of matters at once. For a solo or small firm, that need usually arrives after the Claude-only version has run for months and proven the method. Build the manual version first; it is the specification for anything you automate later, and most firms find the manual version is enough.