Reverse-engineering Anthropic’s AI governance legal skills

When lawyers see something like Anthropic’s Claude for Legal project, an understandable reaction is:

The short answer: because a skill is not the same thing as a complete legal AI platform. And even Claude itself is not merely a model any more. The boundaries are converging. That is what makes this interesting.

Anthropic describes legal AI as an ecosystem that can include connectors to firm data, reusable skills, subagents, plugins, APIs, and enterprise controls. In Anthropic’s own explanation, connectors provide access to data, skills teach Claude how to perform repeatable legal tasks, and plugins bundle capabilities for particular practice areas.

Harvey and Legora are approaching much of the same problem from another direction: they provide legal-specific environments that package many of these capabilities into a finished product. Harvey currently combines purpose-built agents, legal research, document storage and bulk analysis through Vault, collaboration, institutional knowledge, workflow orchestration, integrations, analytics, and enterprise controls. Legora similarly combines agentic execution with workflows, drafting, review, legal research, database search, firm knowledge, permissions, and legal-specific tools.

So this is not Claude Legal versus Harvey and Legora, winner takes all. A better picture is a stack, and companies can participate at several layers at once — which, increasingly, they do.

Because having an intelligent model plus a workflow definition is not the entire product problem.

Consider what Harvey currently provides. Its platform includes agents, research, Vault, knowledge resources, Shared Spaces, workflows, contract intelligence, integrations, administrative capabilities, and enterprise security features. Harvey’s Vault can organise and analyse large document collections and connect with document-management systems while maintaining permissions and governance controls. Legora’s Workflows similarly lets lawyers orchestrate legal tasks using drafting, tabular review, legal research, database search, institutional standards, reference materials, and access controls.

That productisation matters. Imagine that a law firm wants an AI system for due diligence. The AI reasoning might be only one portion of the problem. You also need to answer:

• Where are the 15,000 documents?
• Who may access them?
• What matter do they belong to?
• Which precedents should be used?
• What research sources are licensed?
• Who can see the output?
• Can the system analyse them in bulk?
• How are citations checked?
• Where does the final work product live?
• Can lawyers collaborate on it?
• Does it work inside Word?
• Can administrators control access?
• Can the firm audit usage?
• How is the system rolled out to 3,000 lawyers?
• Who supports it when something breaks?

A SKILL.md file does not magically solve all of those problems.

This is important. It would be misleading to teach that “Claude is just the model and Harvey is the application.” That description is becoming outdated.

Anthropic now describes a legal ecosystem involving connectors, skills, plugins, subagents, APIs, enterprise controls, and workplace integrations — not merely access to a foundation model. At the same time, Harvey and Legora increasingly expose configurable agents and workflows rather than only fixed software features. Harvey now describes purpose-built agents that can execute legal work, while Legora explicitly offers both agentic Workflows and reusable Skills within its environment.

Except even that is oversimplified. Each company is moving in both directions. The more useful competitive question is becoming:

That is a much more interesting question than simply asking whose underlying model is smartest.

The repository itself provides an important clue about how Anthropic thinks about the architecture. Its repository guidance describes the project as primarily involving prompt content — skills, agents, hooks, plugin metadata, and configuration — rather than conventional application code.

The repository layout identifies individual skill entrypoints at a predictable path, alongside plugin configuration, connectors, agents, and other components:

ai-governance-legal/
  .claude-plugin/        # plugin metadata
  CLAUDE.md              # the practice profile the skills read
  references/            # knowledge the skills consult
  skills/
    <name>/SKILL.md     # one skill, one job

And AI Governance Legal is not one enormous skill. It contains separate jobs, each with its own folder and its own SKILL.md:

• cold-start-interview
• customize
• ai-inventory
• use-case-triage
• aia-generation
• vendor-ai-review
• reg-gap-analysis
• policy-monitor
• policy-starter
• matter-workspace

The use-case-triage skill handles one job: triaging a proposed AI use and determining the governance path. The aia-generation skill owns another job: conducting a more structured AI impact assessment, including intake, risk analysis, regulatory classification, policy comparison, and recommendations.

That separation is intentional. And it teaches us our first major skill-design lesson:

Let’s demystify the filename. .md simply means Markdown, a way of writing formatted documents using ordinary text:

# Big heading

## Smaller heading

- bullet
- bullet

**bold text**

You do not need special software to understand a Markdown file. It opens in VS Code, Notepad, TextEdit, GitHub, or almost any plain-text editor. There is no mysterious AI programming language hidden inside it. Anthropic itself describes simple skills as Markdown-based workflows; more advanced skills can also include executable scripts.

A simplified skill might look something like this:

---
name: use-case-triage
description: >
  Classify proposed AI use cases and identify
  governance requirements and next steps.
---

# Purpose

Determine the governance path for a proposed AI use.

# Workflow

1. Understand the proposed use.
2. Check existing policy.
3. Check prohibited uses.
4. Determine the risk tier.
5. Identify required reviews.
6. Produce a structured result.

# Output

Include:
- classification
- rationale
- required conditions
- responsible owner
- next action

# Boundaries

Do not treat the assessment as final organizational approval.

A SKILL.md file contains two different kinds of information.

If those terms sound technical, don’t worry. The easiest way to think about them is that YAML tells the system what the skill is, and Markdown tells the system how the skill works. Let’s unpack that one piece at a time.

YAML is a simple way of writing structured information in plain text. That sounds much more technical than it really is. Imagine the label on a file folder: a name, and a purpose. YAML lets us express that same kind of information in a predictable format that software can recognise:

name: ai-project-triage
description: Classify proposed AI projects and identify required governance steps.

For the simple YAML used in a skill, you do not need to learn a programming language.

Frontmatter is a small block of information placed at the very beginning of a document. Think of it as the information printed on the outside of the folder before you open it. In a skill, it might look like this:

---                          ← start of frontmatter
name: ai-project-triage
description: >
  Classify proposed organizational AI projects
  and identify required governance steps. Use
  when someone asks whether an AI use is permitted,
  prohibited, or requires additional review.
---                          ← end of frontmatter

After that comes the regular Markdown document containing the workflow.

You may also hear the information in that top section described as metadata. That is another technical-sounding word with a simple meaning: metadata is information about something.

A book contains the actual story. Information about the book is its title, author, and publication year. A photograph has an image; information about the photograph might be the date taken, the camera, the location, and the file size. Likewise, the YAML at the top of our skill contains information about the skill. The actual instructions for performing the work come later.

You may notice description: > and wonder why that little > is there. It tells YAML that the description continues onto the indented lines below. So a description broken across four lines is still one description — it is simply set out so that a human can read it more comfortably.

You do not need to memorise YAML syntax to design a skill. The important point is understanding why this information exists.

Before the AI follows a skill’s detailed instructions, the system first has to decide: is this the right skill for this request? A skill’s metadata — especially its name and description — helps determine whether the skill should be selected. Once selected, the detailed instructions in SKILL.md become available.

This is why a vague description creates problems. description: Helps with AI governance. sounds reasonable to a human, but it gives the system very little help: almost anything could qualify as “AI governance.” Compare:

description: >
  Classify proposed organizational AI uses as
  approved, conditional, prohibited, or requiring
  further review. Use when a user asks whether
  an AI system may be used, what approvals are
  necessary, or what governance process applies.

Now the system has recognisable signals:

1. A user asks: “Can we use this AI tool?” · “Does this project need approval?” · “What review does this AI system need?”
2. The description matches those words
3. Consider the AI project triage skill

Imagine an organisation with ten specialists. Someone walks through the door and says: “Marketing wants to upload customer interviews into an AI transcription service. Can we do that?”

Before anyone performs the work, somebody has to decide where the question belongs. AI inventory? No. Policy drafting? No. Impact assessment? Maybe later. Vendor AI review? Possibly later. Use-case triage? Yes. That routing decision happens before the detailed workflow begins.

Which gives us a useful distinction: the description answers “what kinds of problems belong here?”, and the skill instructions answer “now that the problem is here, how should we solve it?”

Once the skill has been selected, the Markdown body tells the AI how to perform the job.

# Purpose

Provide fast, consistent governance triage.

## Step 1 — Understand the use case

Determine:
- what the AI does
- who is affected
- what data is involved
- whether human review exists

## Step 2 — Check policy

Read `references/governance-policy.md`.

## Step 3 — Check prohibitions

If a prohibited use applies, stop and explain why.

## Step 4 — Classify

Choose:
- Approved
- Conditional
- Prohibited
- Insufficient information

## Step 5 — Produce the output

Use the required output template.

Now the file is behaving almost like a small program. Not computer code exactly — but it has an input, a procedure, conditions, branches, and an output.

The use-case-triage skill handles the kind of hallway question that organisations constantly receive: “Can we just use AI for this?” Instead of answering that question informally every time, the skill turns it into a repeatable governance workflow. Conceptually, the process looks something like this:

1. A request arrives
2. Understand the use case
3. Consult organisational context
4. Check the use-case registry
5. Check the red lines
6. Determine a classification
   • approved
   • conditional
   • not approved
7. Identify requirements
8. Route the next action

The skill does not try to own every possible step after triage. If deeper review is necessary, another workflow can take over. That is excellent skill design, and it gives us another principle:

Because then you get the mega skill: AI governance and privacy and contract review and impact assessments and vendor review and regulatory research and policy drafting and litigation and employment and IP and research, all in one file.

At first this seems convenient — “let’s create one legal skill that knows everything!” But several problems appear at once. The instruction file becomes enormous. The AI has more irrelevant instructions competing for attention. Routing becomes fuzzy. Testing becomes difficult. Updates become risky. Responsibility between workflows becomes unclear.

Instead, a small router hands off to a triage skill, an assessment skill, a vendor skill, and a policy skill — each with a recognisable job. That modularity is one of the strongest lessons from this case.

A common beginner instinct is: “I have a 70-page AI policy. I’ll paste the entire thing into SKILL.md.” Don’t.

The skill should contain the instructions necessary to run the workflow. Large bodies of information that are needed only in particular situations can live in supporting resources:

ai-project-triage/
│
├── SKILL.md
│
├── references/
│   ├── governance-policy.md
│   ├── prohibited-uses.md
│   └── escalation-rules.md
│
├── scripts/
│   └── validate-output.py
│
└── assets/
    └── assessment-template.docx

The SKILL.md might simply say: before classifying a use case, read references/prohibited-uses.md; if the case requires escalation, consult references/escalation-rules.md.

This progressive structure is intentional: metadata helps determine whether the skill applies, SKILL.md provides the essential workflow, and supporting resources can be consulted when they become relevant.

Don’t make SKILL.md carry all four jobs.

Anthropic’s AI Governance Legal design also separates organisational configuration from the generic workflow. This is particularly clear in the aia-generation skill — again, AIA means AI impact assessment.

Anthropic describes this skill as conducting a structured AI impact assessment, including risk analysis, regulatory classification, policy comparison, and recommendations. It also draws on an organisation’s configured “house style” rather than assuming every organisation conducts an assessment identically.

This is a reusable pattern worth stealing. The skill contains the method. The organisation supplies the configuration. The current matter supplies the facts.

Anthropic includes a cold-start-interview capability for a reason. Before all of the other workflows can consistently reflect an organisation, something has to establish the organisation’s working context: its risk posture, policies, jurisdictions, escalation contacts, approved and prohibited uses, assessment format, vendor positions, and sign-off process.

Anthropic’s quick-start materials describe these setup interviews as creating a practice profile that other skills can then read:

1. Setup interview
2. An organisational profile is written down
3. Every other skill reads it
   • triage
   • impact assessment
   • vendor review

That is much better than teaching every individual skill the organisation’s entire history. And it reveals another powerful design pattern:

Which gives us: trigger → skill → resources → output.

Here is a simplified example you could use as a starting point.

---
name: ai-project-triage
description: >
  Classify proposed organizational AI projects
  and identify required governance steps. Use
  when a user asks whether an AI use is permitted,
  what approvals are required, or whether an
  additional privacy, security, legal, or impact
  review is necessary.
---

# Objective

Determine the appropriate governance path for
a proposed AI use.

# Required context

Before classification, determine:

- What will the AI do?
- Who is affected?
- What data will it process?
- What happens because of its output?
- Is there human review?
- Which vendor or model is involved?

# Workflow

1. Understand the use case.
2. Read `references/governance-policy.md`.
3. Check prohibited uses first.
4. Check previously approved use cases.
5. Determine governance tier.
6. Identify required reviews.
7. Produce the required output.

# Stop conditions

If essential information is missing:
- gather only the missing information.

If a prohibited-use rule applies:
- stop the ordinary workflow;
- identify the controlling policy;
- explain the escalation path.

# Output

## Use case

[one-sentence summary]

## Classification

[Approved / Conditional / Prohibited /
Insufficient Information]

## Basis

[short explanation]

## Required actions

| Action | Owner |
|---|---|

## Next step

[recommended workflow]

# Boundaries

Do not represent the classification as final
organizational approval when human sign-off is
required.

The interesting part isn’t the prose. It’s the architecture: trigger, context, procedure, branching, stop condition, output contract, boundary. Those are the building blocks.

We did not put these into the skill: the complete EU AI Act, the entire company AI policy, 600 approved vendors, 50 historical impact assessments, the security architecture, all of privacy law, or every output example.

Those things might still be useful. But they belong in the appropriate place — reference files, connected data systems, research tools, databases, other skills, or external applications. Which leads to one of the most useful rules in skill design:

Now we can answer the original question more precisely. A sophisticated SKILL.md can encode something valuable: institutional legal procedure. That is significant. It means firms can increasingly express portions of their expertise as reusable AI workflows.

But legal AI platforms are selling considerably more than a prompt or a Markdown file. They are packaging combinations of:

• models
• legal workflows
• legal data
• institutional knowledge
• document infrastructure
• matter context
• research
• collaboration
• integrations
• permissions
• governance
• administration
• user experience
• deployment
• support

Harvey’s current offering demonstrates this kind of bundled approach, combining agents, research, document infrastructure, knowledge resources, collaboration, workflows, integrations, and enterprise controls. Legora similarly combines agents and workflows with research, drafting, review, database search, institutional materials, permissions, and other legal tools. Meanwhile, Anthropic is moving upward from the foundation-model layer through skills, plugins, connectors, subagents, workplace integrations, APIs, and enterprise infrastructure.

So there is real competitive overlap. But:

There is another possible outcome. Skills could increasingly become a kind of workflow layer through which organisations express how they want AI-assisted work performed. Imagine a firm develops its own our-nda-playbook, our-due-diligence-method, our-ai-governance-triage, our-privacy-review, and our-client-alert-style.

The strategically important asset may increasingly become the firm’s encoded way of working rather than simply the prompt box through which it accesses a model. Then the platform question becomes: where can our institutional workflows run best? That might ultimately involve Claude, ChatGPT, Harvey, Legora, an internal application, or some combination.

In fact, Legora now also uses the term Skills for reusable instructions that encode a firm’s processes and standards inside its own agent environment. That convergence makes the underlying idea even more important. The terminology and file formats may differ; the architectural question remains:

Anthropic’s AI Governance Legal project is useful as a teaching example precisely because the interesting part is not the legal prose. The interesting part is the decomposition.

That is the transition from “write a good prompt about AI governance” to “design a reusable AI system for doing AI-governance work.” And that is what skill design really is.

When studying any skill — including the ones on this site — ask these questions.

1. Trigger

What kinds of requests should activate it?

2. Job

What single recognisable job does it own?

3. Inputs

What information must exist before work begins?

4. References

What knowledge should be consulted rather than baked into the skill?

5. Workflow

What happens first, second, and third?

6. Branches

Where can the workflow take different paths?

7. Stop conditions

When should automatic processing stop?

8. Output contract

What exactly should a successful result contain?

9. Boundary

What is the skill specifically not authorised to do?

10. Handoff

Which skill or human takes over next?

11. Configuration

Which parts should change from organisation to organisation?

12. Platform dependencies

What requires tools, data, integrations, or infrastructure beyond the skill itself?

That last question is especially important. It prevents us from confusing a great skill with a complete product — and that distinction explains a great deal about the emerging legal AI market.

If the technical vocabulary starts to blur together, come back to this:

1. YAML — what is this?
2. Description — when should I use it?
3. The SKILL.md body — how do I do the job?
4. References — what information do I need?
5. Scripts — what should code do reliably?
6. Assets — what materials do I use in the output?
7. Platform — where does all of this operate at scale?

That is the core idea behind skill design.