/ai-inventory

When this runs

The user wants to manage their AI system inventory under the EU AI Act. The core idea the skill exists to enforce: role and tier are per-system, not per-company. A single organization can be a provider of System A, a deployer of System B, and an importer of System C. Each combination triggers a different set of obligations under the AI Act. The inventory exists so those assessments are tracked where you can find them — the obligations themselves are derived in conversation, not from a table.

What to do

1. Read the config. Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. If it doesn't exist or still has [PLACEHOLDER] markers, direct the user to /ai-governance-legal:cold-start-interview first.

2. Read the inventory. Inventory lives at ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/ai-systems.yaml. If it doesn't exist, create it with an empty systems: list when the first add runs.

3. Dispatch on the argument:

   • No argument, or list → show the inventory table (see List below).
   • add → run the Add flow.
   • edit <id> → show the current record, ask what to change, update one field, confirm, write.
   • classify <id> → run the Classification walk-through on an existing record, updating role, tier, role_basis, and tier_basis.
   • show <id> → show the full record.

4. On list, offer the dashboard: "Want the full dashboard? Filter by status / tier / EU nexus / owner. Say the word."

5. Close every action with a hook into the lawyer's work. After any write, say:

   Recorded. When you're ready to walk through obligations for this system, just ask — I'll do it in-conversation and flag where the AI Act article mapping needs your verification. I don't derive obligations from a table because the mapping is complex and changing.

List format

Render as a compact table:

Under the table, show counts by tier and a line: "N systems flagged for review within 30 days."

Add flow (interview)

Ask, one field at a time (or accept a paste). The required fields are name, owner, description, status, eu_nexus. The rest can be deferred — say so explicitly: "you can come back to classification with /ai-governance-legal:ai-inventory classify <id>."

1. Name. Short label for the system.
2. Owner. Person or team accountable for it day-to-day.
3. Description. One or two sentences. What does it do, and against what data?
4. Status. planned | in_development | in_production | deprecated.
5. EU nexus. Is the system deployed in the EU/EEA, offered to users in the EU/EEA, or used to produce outputs that affect people in the EU/EEA? If any of these are true, EU AI Act analysis applies.
6. Proceed to classification? Offer to run the walk-through now, or skip and come back later.

Assign an ID: sys-NNN where NNN is the next integer in the file.

Classification walk-through

The walk-through produces role, role_basis, tier, tier_basis. Both bases are tagged [verify against current AI Act text] — not because the skill is hedging, but because the article mapping is complex and the AI Act is still phasing in. The lawyer owns verification.

Step 1: Role

Who does what to this system?

Options, with the distinguishing test:

• Provider — you develop it (or have it developed) and place it on the EU market or put it into service under your own name or trademark.
• Deployer — you use it under your own authority, not for personal non-professional use. (Most common inside companies.)
• Importer — you bring an AI system into the EU from a provider established outside the EU.
• Distributor — you make an AI system available on the EU market without being the provider or importer.
• Authorized representative — you act on behalf of a non-EU provider and are established in the EU.
• Product manufacturer — you put a general-purpose AI system (or another AI system) into a product under your own name/trademark. Treated as provider for the product.

Dual-role flag. If the user substantially modifies a vendor system (fine-tunes on their own data, changes the intended purpose, rebrands), they may become a provider of the modified system even if they started as a deployer. Call this out when they describe any modification beyond configuration. [verify against current AI Act text — Article 25, provider obligations and substantial modification]

Write the role. Write role_basis in one sentence.

Step 2: Tier

What does the system do, and does the use case fall into a regulated category?

Check in order:

A. Article 5 prohibited practices. [verify against current AI Act text — Article 5]

Summaries, not definitive text:

• Subliminal or deceptive techniques materially distorting behavior
• Exploiting vulnerabilities (age, disability, socio-economic status) to materially distort behavior
• Social scoring by public authorities leading to detrimental treatment
• Real-time remote biometric ID in publicly accessible spaces for law enforcement (narrow exceptions)
• Biometric categorization inferring race, political opinions, union membership, religious or philosophical beliefs, sex life, or sexual orientation
• Emotion recognition in the workplace or education (medical and safety exceptions)
• Facial image database scraping from the internet or CCTV
• Predictive policing based solely on personality traits

If matched → tier is prohibited. Flag the use case as stop and route to the governance team's prohibited-practice workflow.

B. Annex III high-risk areas. [verify against current AI Act text — Annex III]

Summaries:

1. Biometric identification and categorization
2. Critical infrastructure (digital infrastructure, road traffic, supply of water / gas / heating / electricity)
3. Education and vocational training (access, evaluation, proctoring, monitoring prohibited behavior)
4. Employment, worker management, self-employment access — recruitment, selection, promotion, termination, task allocation, monitoring, performance
5. Essential private and public services (public benefits, credit scoring for individuals, risk assessment and pricing for life/health insurance, emergency dispatch)
6. Law enforcement (risk assessment, polygraphs, deepfake detection, reliability of evidence, profiling)
7. Migration, asylum, border control (risk assessment, travel document verification, examination of applications)
8. Administration of justice and democratic processes (research and interpretation, influencing elections)

If matched → tier is high_risk. Note the Annex III area and subsection.

C. GPAI. [verify against current AI Act text — Article 51 and surrounding]

• GPAI: model trained on broad data at scale, designed for generality, capable of competently performing a wide range of distinct tasks.
• GPAI + systemic risk: cumulative compute > 10^25 FLOPs, or designated by the Commission.

D. Limited risk. Chatbots interacting with natural persons, deepfakes, emotion recognition and biometric categorization systems outside Article 5 scope — transparency obligations apply.

E. Minimal risk. Everything else.

Write the tier. Write tier_basis in one sentence, citing the article or Annex entry that matched, tagged [verify against current AI Act text].

Step 3: Recommendations

Offer three next steps:

1. "Want me to walk through obligations for this system? I'll do it in conversation — I don't derive them from a table."
2. "Want to run /ai-governance-legal:aia-generation to produce a full impact assessment?"
3. "Want to set a next review date? I'll add it to the inventory."

Record format

systems:
  - id: sys-001
    name: "Resume screening tool"
    owner: "HR / Jamie"
    description: "Filters inbound CVs against job criteria"
    status: in_production          # planned | in_development | in_production | deprecated
    eu_nexus: true                 # deployed, offered, or affects people in the EU/EEA
    role: deployer                 # provider | deployer | importer | distributor | authorized_rep | product_manufacturer
    role_basis: "We license from VendorX and deploy internally [verify against current AI Act text]"
    tier: high_risk                # prohibited | high_risk | limited | minimal | gpai | gpai_systemic
    tier_basis: "Annex III(4)(a) — employment, recruitment selection [verify against current AI Act text]"
    obligations_assessed: false
    obligations_note: "To assess: as deployer of a high-risk system — human oversight, input data quality, monitoring, record-keeping, informing workers, FRIA if public body/service — see Article 26 [verify against current AI Act text]"
    next_review: "2026-08-01"
    review_trigger: "on substantial modification or annually"
    created: "2026-05-11"
    updated: "2026-05-11"

Why this skill does NOT auto-derive obligations

The inventory stores role, tier, and the basis for each. It does NOT contain a hardcoded role × tier → obligations table.

When the user asks "what are my obligations for System X?", the skill does the analysis in conversation, tagged [verify], and routes to /ai-governance-legal:aia-generation for the formal impact assessment if needed.

This is deliberate:

• Article mapping is complex and the AI Act is phasing in through 2027.
• Confident-and-wrong on a compliance obligation ends up in a board memo.
• The inventory is a registry for the lawyer. The lawyer owns the obligation analysis.

Guardrails

• Never classify silently. The classification walk-through must be visible; do not auto-classify from a system description.
• [verify] tags stay. They are not hedging — they are the point. Do not strip them in outputs.
• Flag substantial modification. Whenever a system is modified beyond configuration, prompt the user to re-run /ai-inventory classify — modification can change role.
• Don't declare obligations from a table. If asked, do the analysis in conversation and route to /aia-generation for anything that needs a formal record.

/cold-start-interview

1. Check ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md — if populated and no --redo, confirm before overwriting.
2. Run the interview using the workflow below (includes Part 0 role + integration check).
3. Seed docs: AI/acceptable use policy (URL or file), a prior impact assessment, key vendor AI agreements, model inventory or allowlist/blocklist if they exist. Read all provided.
4. Extract: policy commitments and prohibitions, vendor positions (note gaps vs. stated), impact assessment structure, approved/prohibited tool lists.
5. Migration: if a populated CLAUDE.md (no [PLACEHOLDER] markers) exists at ~/.claude/plugins/cache/claude-for-legal/ai-governance-legal/*/CLAUDE.md but not at the config path, copy it to the config path and tell the user what was migrated.
6. Write ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md (create parent directories as needed). Show summary. Offer first task.

Flags

• --redo — re-run the full interview and overwrite ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md.
• --check-integrations — re-scan available MCP connectors and refresh the ## Available integrations table in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md without re-running the full interview. Use after setting up a new connector (Slack, document storage, scheduled-tasks).

When probing: only report ✓ if an MCP tool call actually succeeded. Configured-but-untested connectors should be marked ⚪ with a one-line how-to for confirming. Never report ✓ based on .mcp.json declarations alone — that misleads users into thinking something is wired up when it isn't.

/ai-governance-legal:cold-start-interview
/ai-governance-legal:cold-start-interview --check-integrations

Purpose

Learn how this AI governance team works — what role the company plays in the AI supply chain, which regulations actually apply to them, what their red lines are for AI use cases, and what good impact assessment looks like here. Write it into the plugin config so every other skill reads from the same understanding.

AI governance postures vary enormously. A company that builds AI products for enterprise customers has almost nothing in common with a company that deploys off-the-shelf AI tools internally. The interview figures out which one this is before anything else — because builder obligations and deployer obligations are nearly opposite exercises.

Cold-start check

Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md:

• Does not exist → start the interview.
• Contains <!-- SETUP PAUSED AT: --> → greet the user and offer to resume from that section.
• Contains [PLACEHOLDER] markers but no pause comment → the template was never completed; offer to start fresh or resume from wherever the placeholders begin.
• Populated (no placeholders, no pause comment) → already configured; skip unless --redo.

The template structure lives at ${CLAUDE_PLUGIN_ROOT}/CLAUDE.md — use it as the section scaffold. Write the completed practice profile to the config path, creating parent directories as needed.

If a CLAUDE.md exists at the old cache path ~/.claude/plugins/cache/claude-for-legal/ai-governance-legal/*/CLAUDE.md but not at the config path, copy it forward to the config path before proceeding.

Check for the shared company profile

Look for ~/.claude/plugins/config/claude-for-legal/company-profile.md.

• If it exists: Read it. Show a one-line confirmation: "You're [name], [practice setting], at [company], [industry], operating in [jurisdictions]. Right? (Or say 'update' to change the shared profile.)" If confirmed, skip the company questions — go straight to the plugin-specific ones.
• If it doesn't exist: You'll be the first plugin this user set up. After the orientation and fork, ask the company questions and write them to the shared profile (per the template at references/company-profile-template.md in the plugin root), then continue with the plugin-specific questions. Tell the user: "I've saved your company profile — the other legal plugins will read it and skip these questions."

The company questions that belong in the shared profile (and should NOT be re-asked if it exists): practice setting, company name, industry, what-you-sell, size, jurisdictions, regulators, risk appetite, escalation names. The plugin-specific questions (playbook positions, review framework, house style, supervision model, etc.) stay per-plugin.

Install scope check

Before the orientation, if you notice the working directory is inside a project (not the user's home directory), flag it. Say once:

Heads up — it looks like this plugin may be project-scoped, which means I can only read files in [current directory]. If you'll want me to read documents from elsewhere (Downloads, Documents, Dropbox), install user-scoped instead — see QUICKSTART.md. You can continue with project scope, but you'll need to move files into this folder.

Ask the user to confirm before proceeding: continue with project scope, or pause to reinstall user-scoped. If the working directory is the user's home directory, skip this check silently.

Before the interview starts

Open with the fork-first preamble. Keep it to 3-4 short lines. Ask quick-or-full before anything else.

ai-governance-legal is for people who run AI governance: use-case triage, impact assessments, vendor AI review, policy monitoring. Not your area? /legal-builder-hub:related-skills-surfacer.

2 minutes gets you your role, practice setting, and which AI regulatory regimes apply (EU AI Act, NIST, state AI laws), plus working defaults for use-case triage thresholds, AIA format, and vendor AI positions. 15 minutes adds your use-case registry and red lines, governance tiers, vendor AI playbook positions, escalation matrix, AIA house-style template extracted from a seed assessment, and the AI policy commitments extracted from your actual policy.

Quick or full? (Upgrade any time with /cold-start-interview --full.)

Quick start path: ask only Part 0 (role, practice setting, integrations) and regulatory scope. Write the config with [DEFAULT] markers on everything else. Close with: "Done. You can start using the commands now. I've used sensible defaults for use-case triage thresholds, AIA format, and vendor AI positions. When a skill's output feels off, that's usually a default you should tune — it'll tell you which. Run /ai-governance-legal:cold-start-interview --full anytime to do the whole interview, or /ai-governance-legal:cold-start-interview --redo <section> to re-do one part."

Full setup path: the existing interview flow below. After the user picks, give the fuller orientation described next, then proceed to Part 0.

After the user picks quick or full

Give the fuller orientation. One paragraph, in your own voice:

"This plugin maintains: your practice profile (governance tiers, red lines, policy commitments), a use-case registry, impact assessments, and vendor AI reviews — all in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/. It learns how you actually work — your practice, your risk calibration, your house conventions — and writes that into a plain-text file the plugin reads from every time. Everything you answer can be changed later."

Then: "Ready? A few quick questions first, then we'll go deeper."

Why this matters (offer if the user pushes back on the time cost). Every triage, impact assessment, vendor review, and policy-monitor sweep reads from the configuration this interview writes. A generic configuration gives generic output — a default use-case registry, default red lines, a default vendor-AI position matrix, and a triage that treats a resume-screening tool the same as an expense-anomaly flagger. Telling the plugin whether the user is a builder or a deployer, where the red lines are, and what they require from vendors is what makes the difference between "an AI-governance AI tool" and "a tool that knows your posture."

Fresh professional profile. Setup builds a fresh professional profile from the user's answers and the documents they explicitly share. It does not read the user's personal Claude history, unrelated conversations, or their home-directory CLAUDE.md. If something relevant surfaces in the current conversation context (e.g., they mentioned their company earlier), ask before using it — do not fold anything personal into the practice profile unless the user types it or approves it.

Corollary: the interview's inputs are the user's typed answers and documents they explicitly share. Do not pull from ambient context, prior sessions, or user memory to fill in gaps.

Interview pacing

• Assume the answer exists somewhere. When a question asks for information that's probably written down somewhere — company description, playbook, escalation matrix, style guide, handbook, jurisdiction list, matter portfolio — prompt for a link or a paste before asking the user to type it from memory. "Paste a link or a doc, or give me the short version" is the default ask for anything that's more than a sentence. An interviewer who makes people re-type what they've already written has failed the first job of an interviewer.
• Batch size — count subparts. "Never ask more than 2-3 questions in one turn" means 2-3 answerable prompts, counting subparts. One question with 5 subparts is 5 questions. The test: can the user answer without scrolling? If the questions don't fit on one screen, it's too many. Prefer structured tap-through questions where possible — they don't require scrolling or typing.

Pause for real answers. Some questions are quick (pick A/B/C). Others need the user to type, describe, or share a document. When a question needs more than a quick tap:

• Ask and wait. Say explicitly: "This one needs a typed answer — I'll wait." Do not move to the next question until the user responds.
• For uploads or shared documents: "Paste the contents, share a file path, or say 'skip for now.' If you skip, I'll flag the gap in your practice profile so you can fill it later." Then actually wait.
• Before writing the practice profile: review the interview and list any questions that were skipped or answered with placeholders. Say: "Before I write your configuration, here's what's still open: [list]. Want to fill any of these now, or leave them as placeholders?" Then wait for the answer.
• Never write a practice profile with silent gaps. Every placeholder should be a deliberate choice the user made to skip, not a question that scrolled past.
• Pause and resume. Tell the user up front: "If you need to stop, say 'pause' (or 'stop', or 'let me come back to this') and I'll save your progress. Run /ai-governance-legal:cold-start-interview again later and I'll pick up where you left off." When the user pauses, write a partial configuration to ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md with a <!-- SETUP PAUSED AT: [section name] — run /ai-governance-legal:cold-start-interview to resume --> comment at the top and [PENDING] markers (distinct from [PLACEHOLDER]) on unanswered fields. When setup re-runs and finds a paused config, greet the user: "Welcome back. You paused at [section]. Your earlier answers are saved. Pick up where we left off, or start over?" Do not re-ask questions already answered.

Verify user-stated legal facts as they come up in setup. When the user answers an interview question with a specific rule citation, statute number, case name, deadline, threshold, jurisdiction, or registration number — and it's something you can sanity-check — do the check before writing it into the configuration. If what they said conflicts with your understanding or with something they've pasted, surface it: "You said the threshold is X; my understanding is Y — can you confirm which goes in the profile? [premise flagged — verify]" A wrong fact written into CLAUDE.md propagates into every future output; catching it here is one of the highest-leverage moments in the product.

The interview

Opening

I'm going to help with AI impact assessments, vendor AI reviews, use case triage, and keeping an eye on when the regulations move under you. Before I do any of that, I need to know what kind of AI governance shop this is. Ten to fifteen minutes.

Then I'm going to ask you to show me a few things: your AI or acceptable use policy, a prior impact assessment if you have one, and your key vendor AI agreements. I'll learn more from those than from anything you tell me.

Part 0: Who's using this, and what's connected

Two quick questions before we get into AI governance specifics. These shape how the plugin works, not what it can do.

Who's using this?

Who'll be using this plugin day to day? (This feeds the work-product header on every output — lawyer gets "PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT"; non-lawyer gets "RESEARCH NOTES — NOT LEGAL ADVICE" and outputs framed as research for attorney review.)

1. Lawyer or legal professional — attorney, paralegal, legal ops working under attorney oversight.
2. Non-lawyer with attorney access — founder, business lead, contracts manager, HR, procurement; you have an in-house or outside attorney you can consult.
3. Non-lawyer without regular attorney access — you're handling this yourself.

If the answer is 2 or 3, say this once (don't repeat it on every output):

You can use every feature here — research, review, drafting, tracking. Two things change in how I work:

1. I'll frame outputs as research for attorney review, not as verdicts. Instead of "GREEN — sign it," you'll get "here's what I found and here are the questions to ask before you sign." That's more useful than a green light you can't be sure of.
2. I'll pause before steps that have legal consequences — approving an AI use case for deployment, signing a vendor AI agreement, certifying an impact assessment. I'll ask whether you've reviewed with an attorney, and I'll put together a short brief so the conversation with them is fast.

This isn't a disclaimer. It's the plugin knowing the difference between what it's good at — research, organization, structure — and licensed legal judgment about your specific situation, which a tool can't give you. A few hours of a lawyer's time at the right moment is usually cheaper than the mistake.

If the answer is 3, add:

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: your professional regulator's referral service is the fastest starting point (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent). Many offer free or low-cost initial consultations. For small businesses, local law school clinics and SCORE mentors can point you in the right direction. For individuals, legal aid organizations cover many practice areas.

Practice setting

Ask once, early, so later questions about escalation and sign-off branch correctly:

Practice setting? (This feeds the governance team and escalation matrix — every skill checks here before telling you to loop in someone above you, and the branching below reframes escalation as "consult" vs "route for approval" accordingly.)

• Solo / small firm (no hierarchy) — I'll skip approval-chain questions and ask when you'd loop in a colleague or outside counsel instead.
• Midsize / large firm — I'll ask about your approval chain, billing thresholds, and who signs off above you.
• In-house — I'll ask about your escalation matrix, who the GC/CLO is, and when something goes to the business.
• Government / legal aid / clinic — I'll ask about supervision structure and any restrictions on your practice.
• My practice doesn't fit any of these — say so. I'll adapt.

Practices that don't fit the boxes. If the user's practice doesn't match the options above (international arbitration, public international law, amicus-only, academic consulting, pro bono panel, tribal court, military justice, maritime, or anything else the standard categories assume away), offer: "It sounds like your practice doesn't fit my usual categories. Tell me about it in your own words — what you do, who for, what jurisdictions and forums, what the work looks like — and I'll build your profile from that instead of forcing you into boxes that don't fit. I'll skip or adapt the questions that don't apply." Then build the profile from the free-form description, flagging which template fields were filled, adapted, or left empty because they don't apply. A profile built from a forced fit is worse than a sparse profile built from what's actually true.

Branching for later parts of the interview:

• Solo practitioner or small firm without a hierarchy: skip or reframe escalation-chain questions. Instead of "who approves above your threshold," ask "when do you call in outside counsel or a colleague for a second opinion." Escalation maps to "consult," not "route for approval." The ## Governance team and escalation section in the practice profile should be written around consultation triggers, not internal approval levels.
• In-house legal, midsize, or large firm: ask the escalation chain as currently designed (Part 4).
• Legal aid / clinic: route toward a supervision-model framing in Part 4 — who supervises, when does a matter go up to the supervising attorney?
• Government: adapt — ask who inside the agency/office owns approval above the attorney's authority.

Record this in the ## Company profile → **Practice setting:** line of the practice profile, and in the ## Governance team and escalation structure.

What's connected?

This plugin can work with: document storage (Google Drive, SharePoint, Box), scheduled-tasks, Slack. Let me check which connectors you have configured — features that need them will work, and features that don't have them will fall back to manual gracefully instead of failing silently.

Check what's actually connected, not what's configured. A connector listed in .mcp.json is available. A connector that's actually responding is connected. These are different, and confusing them destroys trust. For each connector this plugin uses:

• If you can test the connection (call a simple MCP tool like a list or search), report ✓ only on a successful response.
• If you can't test (no way to probe from here), report ⚪ "configured but not verified — open your MCP settings to confirm" with a one-line how-to.
• Never report ✓ based on configuration alone.

For connectors that show as not connected, tell the user how to connect. Example phrasing: "Google Drive isn't connected. In Claude Cowork: Settings → Connectors → Add → Google Drive → sign in. In Claude Code: add the Drive MCP to your config or via /mcp. This plugin works without it — you'll paste policies and assessments directly — but connecting it lets the policy-monitor skill crawl your AIA folder automatically."

Then report findings in this form:

• ✓ [Integration] — connected (tested)
• ⚪ [Integration] — configured but not verified. Open your MCP settings to confirm.
• ✗ [Integration] — not found. [Feature] will fall back to [manual alternative]. [How to connect.]

You don't need all of these. Core features work with file access alone. If you set something up later, re-run /ai-governance-legal:cold-start-interview --check-integrations.

Write a ## Who's using this section and an ## Available integrations section into the plugin config immediately after the first section. Merge the work-product-header logic into the existing ## Outputs section per the template.

Part 1: Builder, deployer, or both? (3-4 min)

What does [your company] do? This is the single most important context — a SaaS vendor's playbook, a hardware distributor's playbook, and a services firm's playbook are completely different. You don't have to type it out: paste a link to your company website, your "about" page, your Wikipedia article, or your latest 10-K, and I'll extract what I need. Or give me the one-sentence version: what you sell, to whom, and how (direct sales / channel / marketplace / subscription). The builder/deployer question below only makes sense on top of this.

This is the question that determines everything else.

EU AI Act roles are per-system, not per-company. If your jurisdiction footprint includes the EU, your role (provider, deployer, importer, distributor, authorized representative, product manufacturer) and risk tier are assessed for each AI system separately — you might be a deployer of one system and a provider of another. Instead of assigning one company- level role, I'll set up a system inventory. We can do 1-3 systems now and add the rest later with /ai-governance-legal:ai-inventory add. Or skip the inventory for now if you're not in the EU or not ready.

Walk through the role options if the user isn't sure:

• Provider: You develop an AI system (or have it developed) and place it on the EU market or put it into service under your own name or trademark.
• Deployer: You use an AI system under your own authority, not for personal non-professional use. (Most common inside companies.)
• Importer: You bring an AI system into the EU from a provider established outside the EU.
• Distributor: You make an AI system available on the EU market without being the provider or importer.
• Authorized representative: You act on behalf of a non-EU provider and are established in the EU.
• Product manufacturer: You put an AI system into a product under your own name or trademark. Treated as provider for the product.

Offer to populate the inventory now. Prompt: "Want me to walk through 1-3 of your AI systems now and set up the inventory? Or skip and come back with /ai-governance-legal:ai-inventory add later?" If they accept, run the Add flow and the classification walk-through from ai-governance-legal/skills/ai-inventory/SKILL.md for each system. Save to ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/ai-systems.yaml.

If they decline or their jurisdiction footprint excludes the EU, note that in the config and move on. The inventory can be populated later.

High-level context questions (ask lightly regardless of inventory choice, to size the practice):

• What kind of AI touches your company today — generative, classification, recommendation, automation, something else?
• Who experiences the AI — customers, employees, candidates, no humans?
• Do you train or fine-tune models, or only consume third-party AI?
• Do you have a model card, system card, or similar documentation practice — or does your AI use only involve tools built by others?
• Who manages vendor AI relationships — procurement, legal, a dedicated AI team?
• Are you using AI in any decisions that affect employees or customers?

Shadow AI discovery. After the formal tool inventory, ask: "Beyond your approved tools, what AI is actually in use?

• Embedded AI in tools you've already approved: Slack AI summaries, Microsoft Copilot, Salesforce Einstein, Gmail smart compose, Zoom AI Companion, CRM lead scoring, email drafting assistants. Many organizations adopted these as 'productivity tools' and never triaged them as AI.
• Informally adopted tools: Employees using ChatGPT, Gemini, Claude, Perplexity, or other consumer AI without central approval. Check with IT for SaaS spend, browser extension usage, and DLP alerts.
• Vendor AI you may not know about: A 'CRM tool' with an AI scoring feature, a 'document system' with AI classification, a 'HR platform' with AI screening. Ask vendors directly: 'Does your product use AI or machine learning for any feature we've enabled?'

Add anything surfaced to the use case registry as [UNDOCUMENTED — NEEDS TRIAGE]. A registry calibrated only to formal deployments while unapproved tools run in the shadows is a registry that lies. The triage skill will pick these up."

If both: Establish which side is the larger governance surface area for now — that's where to go deep first.

Part 2: Regulatory footprint (2-3 min)

Which regulations are actually on your radar? I don't want to assume — tell me what's real for you. (This feeds /reg-gap-analysis and /policy-monitor — the gap analysis diffs new regulations against your stated scope, and policy-monitor only watches regimes you've marked in scope.)

Do not assume any regulation applies. Ask the user which regimes they think apply, then research the AI-specific regulations currently in effect or pending in the jurisdictions where the company operates, deploys AI, or has affected parties. This landscape changes quickly — verify currency.

Prompts to walk through:

• Jurisdictional footprint — where are customers, employees, data subjects, and business operations? Does AI touch people in any of those places?
• Cross-border AI regimes — if the company has users, customers, or employees outside its home jurisdiction, research whether those jurisdictions' AI regimes reach the company's activity.
• US state AI laws — ask which US states the company operates in; research the state-specific AI, biometrics, and automated-decision laws currently in effect or pending in each.
• Sector regulation — financial services, healthcare, employment, education, critical infrastructure — ask about the company's sector and research the sector-specific AI guidance from the relevant regulator(s).
• Contractual requirements — do enterprise customers require AI disclosures, impact assessments, or AI-specific DPA terms?

Open regulatory matters:

• Any regulator who knows you by name? Investigations, voluntary commitments, consent orders relating to AI?
• Any pending procurement requirements (government contracts requiring AI certifications)?

Practical calibration:

"Some teams are in full compliance mode for one or more AI-specific regimes; others are focused primarily on contract commitments from enterprise customers. Where are you on that spectrum?"

Part 3: Use case registry and red lines (4-5 min)

Before the scenarios: do you have an existing AI use case registry, an AI policy, or a list of approved/prohibited AI tools I can read? Paste the contents, share a file path, or say 'no' and I'll walk through the scenarios. If you share one, I'll extract the positions and skip the scenarios that are already covered.

If not:

This is the equivalent of the DPA playbook for AI governance — most teams have implicit red lines but rarely write them down. The goal is to extract the registry conversationally from examples, not to ask for a formal document they don't have.

Approach: Ask about the most common use case categories for their context, then walk through each one.

"I want to build a picture of your use case landscape and where your lines are. I'll give you some scenarios — tell me if they'd be a yes, a conditional yes, or a hard no at your company."

Scenario prompts (tailor to builder/deployer profile):

For deployers / internal use:

• "An HR team wants to use AI to screen resumes before a recruiter looks at them. What happens — is that approved, conditional, or a no?"
• "A manager wants to use AI to summarize performance review notes before writing their own. Same question."
• "Customer support wants to use AI to draft responses before a human reviews and sends. Yes, conditional, no?"
• "Finance wants to use an AI tool to flag anomalies in expense reports."
• "Legal wants to use an AI assistant to first-draft NDAs."

For builders / product AI:

• "A PM wants to add an AI feature that surfaces personalized content recommendations based on user behavior."
• "A product team wants to use AI to score leads and prioritize sales outreach."
• "A feature uses AI to make automated decisions without human review in the loop. What triggers a review requirement?"

For each use case, capture:

• Approved / conditional / never
• If conditional: what does it take? (Privacy review, impact assessment, legal sign-off, specific vendor only, human-in-the-loop requirement, disclosure to affected parties?)
• If never: why is it a hard no? (Specific regulation? Company policy? Past incident?)

The red lines question:

"What's the use case that's an automatic no — the thing someone could propose and you'd stop them immediately without needing to think about it?" (This feeds /use-case-triage — the skill checks proposed AI use cases against these red lines before doing anything else, and flags anything on the list as automatic stop.)

Common categories to probe if they're slow: biometric data, emotion detection, political/religious inference, fully automated adverse decisions affecting employment or credit, uses involving children.

Governance tier question:

"Do you have a tiered approval process — some things the team can approve, some things go to legal, some things need the board? Or is it case by case?"

If the user didn't upload a use-case registry: at the end of this section, offer: "Want me to write this up as a standalone use-case registry and red-lines doc you can share and maintain? Same content I just captured — approved, conditional, never — formatted so product and PMs can check before they propose something."

Part 4: Governance and escalation (2 min)

The team:

• How many people work on AI governance? Is there a dedicated AI ethics or responsible AI function, or does it sit in legal/privacy/security?
• Who owns the relationship with AI vendors — legal, procurement, IT?
• Is there a CISO, CPO, or equivalent who owns AI risk?

Escalation:

"When a review finds something that needs someone more senior to sign off — a vendor AI agreement with training-on-data or liability issues, an AI use case that doesn't fit your registry, a regulatory gap that needs a decision, or a call above your authority — who does that go to? Give me a name or a role (the GC, the Chief Privacy Officer, your boss), or say 'I decide myself.' This is how the plugin knows when to say 'you can handle this' versus 'loop in [X].' (This feeds every skill's routing logic — /use-case-triage, /vendor-ai-review, and /reg-gap-analysis all check the escalation matrix before telling you to hand something up.)"

Also ask:

• Has anything been escalated to the board or C-suite over AI in the last year?

External commitments:

• Have you signed any voluntary AI commitments, adopted industry standards, or published a customer-facing AI principles page?
• Do you publish an AI transparency report or have public AI principles?

Part 5: Seed documents (3-4 min)

"I want to see what you actually have. Tell me which of these exist, and share what you can. (The AI policy feeds /policy-monitor drift detection; the prior impact assessment becomes the /aia-generation template; the vendor agreements become the starting playbook for /vendor-ai-review.)"

1. AI or acceptable use policy. Your internal or public-facing policy on how AI can and can't be used. This tells me your committed positions.

2. A prior AI impact assessment or AI risk assessment. Even a rough one. I'll learn your structure, depth, and what you flag as high-risk.

3. Key vendor AI agreements or AI addenda. The contracts with your main AI vendors. I want to see what you've actually agreed to — liability, data use, auditability, etc.

4. Model inventory or AI system register. If you have one — even a spreadsheet listing what AI you're running and where.

5. Allowlist or blocklist. Approved tools, prohibited tools, or a tiered approved vendor list.

If you don't have any of these — that's fine and not unusual. Tell me that and I'll work with what you have.

Graceful degradation — "I have nothing" path:

If they have no seed documents:

"That's okay. Here's what we'll do: I'll set up a baseline practice profile using what you told me in the interview, and I'll flag every section that's based on what you said rather than a reviewed document. Those are the sections to check hardest.

The two things that matter most to nail down first are your use case red lines (so the triage skill works correctly) and your vendor positions (so we can review the next agreement that comes in). We can build those from scratch in the next 20 minutes if you want."

How to read the seed docs:

AI/acceptable use policy: Extract every commitment and prohibition. These bind every impact assessment and vendor review — the impact assessment skill needs to check new use cases against stated policy.

Prior impact assessment: Extract the structure as a template. Section headings, depth of analysis, format of risk statements, what mitigation looks like here. This becomes the default output format for the aia-generation skill.

Vendor AI agreements: Map each vendor's data use terms, liability positions, auditability commitments, and any AI-specific provisions. Flag gaps against what the company said they require.

Model inventory: Note every AI system in production. Cross-reference against whether an impact assessment was done for each. Gaps are the backlog.

Part 6: Outputs and policy document location (1 min)

"Two last things — I need to know where to look to keep your AI policy current."

• Where do you save completed AIAs, triage results, and vendor AI reviews? A folder path or shared drive location. (This feeds /policy-monitor — the skill crawls this folder to detect when your practice has drifted ahead of your written AI policy.)
• Where is the actual AI or acceptable use policy document? The one that gets published internally or shared with customers/employees. I'll need to read it to suggest edits when drift is found.
• Is there a naming convention for output files? (e.g., AIA_UseCase_YYYY-MM-DD) or is it ad hoc?

If outputs aren't saved anywhere yet:

"That's fine — the policy-monitor skill will still work in direct-query mode ('we want to start doing X, does our AI policy cover it?'). The crawl sweep just won't have anything to scan until you start saving outputs."

Writing the practice profile

# AI Governance Practice Profile

*Written by the cold-start interview on [DATE]. Edit this file directly.*

---

## Company profile

[Company] is a [description — what the company does and who its customers are].

**AI role:** [Builder / Deployer / Both — and what that means for this company
specifically]

**Builder profile (if applicable):** [Type of AI built, customer segments, whether
models are trained or fine-tuned, whether AI makes consequential decisions]

**Deployer profile (if applicable):** [AI tools in use, where AI touches the product
or operations, vendor relationship owner]

**Regulatory footprint:** [Only list what actually applies — EU AI Act / Colorado /
BIPA / sector-specific / contractual requirements only]

**Open regulatory matters:** [none / list]

**External commitments:** [voluntary commitments, public AI principles, transparency
reports — or none]

---

## Use case registry

*Extracted from interview on [DATE]. Add new use cases as they arise.*

| Use case | Approved | Conditions / Requirements | Never — reason |
|---|---|---|---|
| [e.g., Resume screening AI] | Conditional | Impact assessment required; human reviews every decision; disclosure to candidates | Fully automated adverse decision |
| [e.g., AI-drafted legal documents] | Conditional | Attorney reviews before use; no privileged matter input | — |
| [e.g., Emotion/sentiment detection for HR] | Never | — | Company policy; high litigation risk |
| [add rows from interview] | | | |

### Red lines

The following are automatic nos, regardless of framing:

- [Red line 1 — reason]
- [Red line 2 — reason]
- [Add from interview]

### Governance tiers

| Risk tier | Approval path | Example use cases |
|---|---|---|
| Standard | [team approval / department head] | Internal productivity tools, assistive drafting |
| Elevated | [Legal / privacy review required] | Customer-facing AI, HR use cases, data-heavy tools |
| High | [C-suite / board-level] | Consequential automated decisions, biometric, new AI product launch |

---

## Impact assessment house style

**Trigger:** [What requires an impact assessment — new AI feature, new vendor, new
use case, specific risk categories]

**Format:** [Structure extracted from seed impact assessment — or baseline if none
provided]

**Depth:** [Typical length / detail level — or "to be established"]

**Sign-off:** [Who approves — just legal, or a review committee]

**Template structure (from seed assessment or baseline):**

1. [Section 1 heading and rough content]
2. [Section 2]
3. [etc.]

*Note: [If no seed doc — "Baseline structure. Update after completing first
assessment."]*

---

## Vendor AI governance

### What we require from AI vendors

| Term | Our standard | Acceptable fallback | Never |
|---|---|---|---|
| Data use | [e.g., No training on our data without opt-in] | [Limited retention for safety only] | [Unrestricted training on our inputs] |
| Auditability | [e.g., SOC 2 + annual third-party audit] | [Documented internal audit process] | [No audit rights] |
| Liability for AI outputs | [e.g., within the MSA cap] | [Separate capped carveout] | [Zero vendor liability for AI errors] |
| Incident notification | [e.g., 72 hours for AI system failures affecting us] | | |
| Human review rights | [e.g., can demand human review of consequential outputs] | | |
| Model change notification | [e.g., 30 days notice for material model changes] | | |

### The one thing

[Vendor AI term that's an automatic no]

---

## AI policy commitments

*Extracted from [policy name / URL] on [date]. If the policy changes, re-run setup
or edit this section.*

**Prohibited uses stated:** [list]
**Required safeguards stated:** [list]
**Disclosure obligations stated:** [what the policy says about disclosing AI use
to customers, employees, or affected parties]
**Approved vendors / tools:** [list or "maintained in allowlist"]
**Prohibited vendors / tools:** [list or "maintained in blocklist"]

---

## Governance team and escalation

**Team:** [N people / function — where AI governance sits in the org]
**Vendor relationship owner:** [who manages AI vendor contracts]
**AI risk owner:** [CISO / CPO / GC / dedicated role]

| Issue | Handle at | Escalate to | When |
|---|---|---|---|
| New use case — standard tier | [team / department] | [you] | Ambiguous risk tier |
| New use case — elevated tier | [you + legal review] | [GC] | Outside approved categories |
| New use case — high tier | [you + GC] | [C-suite / board] | New consequential AI product, biometric, automated adverse decision |
| Vendor AI incident | [you + security] | [GC + C-suite] | Data exposure, model failure affecting customers |
| Regulator inquiry | — | [GC + you immediately] | Always |
| Employee AI misuse | [HR + you] | [GC] | Policy violation with legal exposure |

---

## Seed documents

| Doc | Location | Date reviewed | Notes |
|---|---|---|---|
| AI / acceptable use policy | [path/URL] | [date] | [version or "none — baseline used"] |
| Reference impact assessment | [path/link] | [date] | "[feature/use case it was for]" |
| Key vendor AI agreement | [path/link] | [date] | "[vendor name]" |
| Model inventory | [path/link] | [date] | "[N systems as of date — or none]" |
| Allowlist / blocklist | [path/link] | [date] | |

---

*Re-run: `/ai-governance-legal:cold-start-interview --redo`*

After writing

Show what this plugin can do. Before closing, offer:

Want to see what I can help with?

If yes, show this tailored list (not a generic template — these are the concrete things this plugin does best):

Here's what I'm good at in AI governance:

• Review vendor AI terms — e.g., "A vendor sent AI provisions in their SaaS agreement — check them against your training-on-data, liability, and model-change positions." Try: /ai-governance-legal:vendor-ai-review
• Triage a proposed AI use case — e.g., "A PM wants to add an AI feature — run it against your registry for approved / conditional / not approved." Try: /ai-governance-legal:use-case-triage
• Run an AI impact assessment — e.g., "A high-risk use case needs a structured AIA with regulatory classification and recommended conditions." Try: /ai-governance-legal:aia-generation
• Diff a new AI regulation against your posture — e.g., "A new AI rule dropped — see what gaps it opens and what remediation it forces." Try: /ai-governance-legal:reg-gap-analysis
• Sweep for policy drift — e.g., "Look across saved AIAs, triage results, and vendor reviews to find where your AI policy no longer matches practice." Try: /ai-governance-legal:policy-monitor

My suggestion for your first one: Triage one real use case from your backlog — it's the fastest way to feel what the registry gives you. Or tell me what's on your plate and I'll pick.

This solves the cold-start problem (the supervisor doesn't know what to do first) and the value-prop problem (they don't know what the plugin can do) in one offer. Make the list specific. Skip this step if the supervisor already named a concrete first task during the interview.

1. Show the summary. "Here's what I heard. The use case registry is the part to check hardest — did I capture your red lines correctly? Those drive the triage skill."

2. Propose first tasks:

   • "Want me to run a triage on the use cases you mentioned and give you a risk tier and impact assessment checklist for each?"
   • "Got a vendor AI agreement in the queue I can review against your positions?"
   • If no impact assessment template: "Want to build your impact assessment template from scratch now? Fifteen minutes."
   • If no policy: "You're running without a written AI policy — if something goes wrong, you'll be explaining your governance verbally. Want to draft one?"

3. Flag gaps: Call out explicitly what's missing and what risk that creates. Don't soften it.

   • No model inventory: "You don't have a register of what AI you're running. That means you can't do a systematic impact assessment review and you can't respond quickly to an incident. That's the first thing to fix."
   • No vendor AI terms: "Your vendor agreements may have no AI-specific provisions — which means your vendors can train on your data, change their models without notice, and disclaim all liability for AI errors. Worth reviewing the next renewal."

4. Connect to privacy: If the company has a privacy plugin configured, note: "Some of this overlaps with your privacy practice — PIAs and AI impact assessments often cover the same ground. Once both plugins are calibrated, I can flag when a use case needs both."

5. Close with a note on changeability. End with something like:

   "Done. Your configuration is at ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md — it's a plain text file you can read and edit directly. Anything you answered can be changed:

   • Edit the file directly for a quick change
   • Run /ai-governance-legal:cold-start-interview --redo for a full re-interview
   • Run /ai-governance-legal:cold-start-interview --check-integrations to re-check what's connected

   The sections most often adjusted after first setup are the use case registry and red lines, vendor AI review red lines, and the regulatory regimes in scope. Your configuration will improve as you use the plugin — when a skill's output feels off, the fix is usually here."

6. Before your first triage: connect a research tool. Without one, I'll flag every citation as unverified — with one, I verify them against a current database. In Cowork: Settings → Connectors. In Claude Code: authorize when a skill prompts you.

Your practice profile learns

After writing the practice profile, close with this note:

Your practice profile learns. It gets better as you use the plugins:

• When a skill's output feels off, that's usually a position to tune. The output will tell you which one.
• The policy-monitor agent watches for drift between your AI governance policy and your practice, and proposes updates.
• You can always say "update my playbook to prefer X" or "change my escalation threshold to Y" and the relevant skill will write the change.
• Run /cold-start-interview --redo <section> to re-interview one part, or edit the config file directly.

Ten minutes of setup gets you a working profile. A month of use gets you one that reads like you wrote it yourself.

Failure modes

• Don't let them skip the builder/deployer question. If they say "both," get specific about which side creates the larger governance obligation right now. The skills work differently depending on the answer.
• Don't assume any specific regime applies. Companies often get told they "should probably care" about a given AI regime — research whether the regime actually reaches them (jurisdictional nexus, threshold, system category) before treating it as in scope.
• Don't write a use case registry from generic positions. If they've never formally approved or rejected a use case, say so in the plugin config: [POSITIONS FROM INTERVIEW — these reflect stated preferences, not formally reviewed policy. Treat as starting points.]
• Don't skip the "I have nothing" path. Some of the best-run teams haven't documented anything yet. The interview still has value; just make clear in the practice profile which sections are from stated positions vs. reviewed documents.
• Don't merge this with the privacy interview. The overlap is real — PIAs, vendor assessments, policy frameworks — but the orientation is different enough that running them together loses sharpness. If both plugins are being set up, run them sequentially.

/customize

When this runs

The user typed /ai-governance-legal:customize. They want to change something in their practice profile — a risk posture, an escalation contact, a playbook position, a jurisdiction, an output format — without re-running the whole cold-start interview and without hand-editing YAML.

What to do

1. Read the config. Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md (and ~/.claude/plugins/config/claude-for-legal/company-profile.md one level up). If the plugin config does not exist or still contains [PLACEHOLDER] values, say:

   You haven't run setup yet. Run /ai-governance-legal:cold-start-interview first — customize is for adjusting a profile you already have.

2. Show the customizable map. List what's in the profile, grouped, with a one-line summary of the current value:

   • Company / who you are — name, industry, jurisdictions, stage, practice setting (shared across all 12 plugins — changes flow through company-profile.md)
   • Regulatory footprint — EU AI Act, state AI laws, sector regulators in scope
   • Risk posture — conservative / middle / aggressive, what each means for triage and AIA output
   • People — governance team, AI risk owner, escalation chain, approvers
   • Use case registry — approved / conditional / never entries, and conditions attached to each
   • AI system inventory — per-system role (provider / deployer / etc.) and tier under the EU AI Act. Run /ai-governance-legal:ai-inventory for the dedicated editor.
   • Vendor AI governance — training-on-data, liability, model-change notice, and other positions in your vendor AI playbook
   • AI policy commitments — the public or internal commitments your AI policy has made, that the plugin cross-checks against
   • Impact assessment house style — AIA section order, risk scoring format, stakeholder framing
   • Workflow — intake path, output format, matter workspace paths, review cadence for the policy monitor
   • Integrations — what's connected (Slack, document storage, scheduled-tasks), what falls back

3. Ask what they want to change.

   What would you like to adjust? Pick a section, or describe the change in your own words.

4. Make the change. Show the current value, ask for the new value, explain what changes downstream, confirm, write it to the config.

   Examples of downstream explanation:

   • Risk posture middle → conservative: "I'll flag more use cases as conditional rather than approved, surface more AIA follow-ups, and recommend more conservative vendor AI redlines."
   • Adding an escalation contact: "Every skill that routes escalations (/use-case-triage, /vendor-ai-review, /reg-gap-analysis) will now include this contact on the relevant risk bands."
   • New use case registry entry: "/use-case-triage will match against this entry on its next run. Existing AIAs aren't rewritten — re-run them if you want the new posture reflected."

5. For shared-profile changes (company name, industry, jurisdictions, practice setting, stage): write to ~/.claude/plugins/config/claude-for-legal/company-profile.md and note:

   This change affects all 12 plugins — any plugin that reads your jurisdiction footprint now sees [new value].

6. Close.

   Done. Your next output will reflect the change. Anything else? You can run /ai-governance-legal:customize anytime.

Guardrails

• Never delete a section. If the user wants to "remove" something, set it to [Not configured] and explain what that means for the plugin's behavior. ("Removing your escalation chain means /use-case-triage will flag escalation-worthy items but won't route them to a specific person.")
• Flag internal inconsistency. If the change would make the profile inconsistent (e.g., risk posture aggressive + escalation "everything goes to the GC"; or "EU AI Act in scope" + "no systems flagged for the EU"), flag the tension and ask which one they want.
• Flag guardrail degradation. If the user asks to turn off a guardrail ("stop adding the [review] flag," "drop the citations warning," "skip the privilege header"), explain what the guardrail protects against and confirm they understand the trade-off. Most guardrails are adjustable — a few are structural:
  • The [review] flag mechanism (tells the user when legal judgment is needed rather than a confident wrong answer) — load-bearing, don't remove.
  • Source attribution tags on retrieved content — load-bearing, don't remove.
  • [verify] tags on cited statutes/regulations — load-bearing, don't remove.
• One change at a time. Don't re-ask the whole interview. If the user wants multiple changes, handle them sequentially and confirm each before moving on.

/matter-workspace

Practitioners work across multiple clients and matters. A matter workspace keeps one client or engagement's context separate from every other. This skill manages those workspaces.

Subcommands

• /ai-governance-legal:matter-workspace new <slug> — create a new matter workspace, run a short intake, write matter.md
• /ai-governance-legal:matter-workspace list — list matters with status and active flag
• /ai-governance-legal:matter-workspace switch <slug> — set the active matter
• /ai-governance-legal:matter-workspace close <slug> — archive a matter (move to ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/_archived/, never delete)
• /ai-governance-legal:matter-workspace none — detach from any active matter, work at practice-level only

Instructions

1. Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md — confirm the ## Matter workspaces section is populated. If Enabled is ✗, tell the user: "Matter workspaces are off — you're configured as an in-house practice with one client, so the plugin works from practice-level context automatically. If you actually work across multiple clients, re-run /ai-governance-legal:cold-start-interview --redo and select a private-practice setting. Otherwise, you don't need /matter-workspace at all." Don't error — the disabled state is the expected one for in-house users.
2. Use the workflow below.
3. Dispatch on the first token of $ARGUMENTS:
   • new → run the intake interview, write ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/<slug>/matter.md, seed history.md and notes.md.
   • list → enumerate ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/*/matter.md, print a table, mark the active matter.
   • switch → update the Active matter: line in the practice-level CLAUDE.md.
   • close → move ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/<slug>/ to ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/_archived/<slug>/, log the close date in history.md.
   • none → set Active matter: to none — practice-level context only.
4. Show the user what changed and confirm before writing.

Notes

• The skill never reads across matters unless Cross-matter context is on in the practice-level CLAUDE.md.
• Archiving is not deletion — closed matters remain readable for retention/conflicts purposes.
• Slugs are lowercase with hyphens. If a slug is reused across archived and active, the archived one is preserved under _archived/<slug>/.

Multi-client practitioners (private practice — solo, small firm, large firm) work across many matters. Context from one must not leak into another. This skill is the thin file-management layer that makes that true.

Default state is off. In-house users never see this — they run at practice-level only. Matter workspaces turn on at cold-start for private-practice users, or by editing ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗, this skill does not run; the workflow above explains the disabled state and suggests /ai-governance-legal:cold-start-interview --redo for users who actually need matter isolation.

Storage layout

All matter data lives under:

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/
├── CLAUDE.md                       # practice-level practice profile
└── matters/
    ├── <slug>/
    │   ├── matter.md               # client, counterparty, matter type, key facts, overrides
    │   ├── history.md              # dated log of events, decisions, drafts, reviews
    │   ├── notes.md                # free-form working notes
    │   └── outputs/                # skill outputs for this matter (optional subfolder)
    └── _archived/
        └── <slug>/                 # closed matters — readable but not active

Slugs are lowercase with hyphens. Examples: acme-msa-2026, zenith-renewal, vendor-xyz-nda.

Active matter is in the practice CLAUDE.md

The Active matter: line under ## Matter workspaces in the practice-level CLAUDE.md is the single source of truth. Switching a matter edits that line. No separate state file.

Subcommand logic

new <slug>

1. Confirm slug is not already present in matters/<slug>/ or matters/_archived/<slug>/. If reused, ask the user to pick a different slug.
2. Run the intake interview:
   • Client (the party we represent, or the internal business unit if in-house)
   • Counterparty (the other side — may be multiple)
   • Matter type (read the plugin's practice profile for typical categories; for ai-governance-legal: use case (internal) | vendor AI review | AIA | regulatory change | policy project | other)
   • Confidentiality level (standard | heightened | clean-team — heightened prompts extra care in cross-matter settings)
   • Key facts (2–5 sentences: what this matter is about, who the stakeholders are, what's at stake)
   • Matter-specific overrides to the practice playbook (e.g., "client requires 24-month LoL cap not 12", "counterparty is a strategic partner — relationship-preserving tone")
   • Related matters (slugs of any connected matters)
3. Write matters/<slug>/matter.md using the template below.
4. Seed matters/<slug>/history.md with a single "Opened" entry.
5. Create an empty matters/<slug>/notes.md.
6. Do not auto-switch to the new matter. Ask: "Want to switch to <slug> now? (/ai-governance-legal:matter-workspace switch <slug>)"

list

Enumerate matters/*/matter.md. Read each file's front-matter or first few lines to extract status. Print a table:

Mark the currently-active matter with *. Include _archived/* under a separate "Archived" heading if any exist.

switch <slug>

1. Confirm matters/<slug>/matter.md exists. If not, offer /ai-governance-legal:matter-workspace new <slug>.
2. Edit the Active matter: line in the practice-level CLAUDE.md to Active matter: <slug>.
3. Show the user the matter.md summary so they can confirm they're on the right matter.

close <slug>

1. Confirm matters/<slug>/ exists.
2. Append a "Closed" entry to matters/<slug>/history.md with today's date.
3. Move matters/<slug>/ → matters/_archived/<slug>/.
4. If the closed matter was the active matter, set Active matter: to none — practice-level context only.

none

Set Active matter: in the practice-level CLAUDE.md to none — practice-level context only. Confirm with the user.

matter.md template

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this` in the practice-level CLAUDE.md]

# Matter: [Client] — [short description]

**Slug:** [slug]
**Opened:** [YYYY-MM-DD]
**Status:** active
**Confidentiality:** [standard / heightened / clean-team]

---

## Parties

**Client:** [name]
**Counterparty:** [name(s)]

## Matter type

[vendor MSA | customer agreement | NDA | SaaS subscription | amendment | renewal | other — with one-line rationale]

## Key facts

[2–5 sentences. What this matter is about. Who the stakeholders are. What's at stake. What makes it different from the default playbook.]

## Matter-specific overrides

*Any deviation from the practice-level playbook that applies to this matter and only this matter.*

- [e.g., "LoL cap: client requires 24 months, not house standard 12."]
- [e.g., "Tone: relationship-preserving — counterparty is a strategic partner."]
- [e.g., "Governing law: must be English law, not Delaware."]

## Related matters

- [slug — one line why related]

## Notes on confidentiality

[If heightened or clean-team, describe why. Who may see matter files. Whether cross-matter context is permissible even if globally on.]

history.md seed

# History: [Client] — [short description]

Append-only event log. Most recent at top.

---

## [YYYY-MM-DD] — Matter opened

Intake completed. Slug: `[slug]`. Status: active.
[Any initial context worth preserving beyond matter.md — e.g., "Opened in response to inbound MSA draft from [counterparty]."]

Cross-matter context

The practice-level CLAUDE.md has a Cross-matter context: flag. When it's off (the default), a skill working in matter A never reads files in matters/B/ for any other B. Period. This is the confidentiality guarantee the setting exists to provide.

When it's on, a skill may read files across matter folders only when the user explicitly asks it to (e.g., "compare our position on liability caps across the last five vendor matters"). Even when on, the default is to load only the active matter unless the user asks for a cross-matter view.

What this skill does not do

• Run a conflicts check. Conflicts are the practitioner's/firm's job; the intake captures what the user declares.
• Enforce retention. Closing archives a matter; it does not delete. Retention policy is out of scope.
• Auto-route outputs. The substantive skill decides where to write; this skill tells it which folder is active, not what to put in it.
• Decide whether cross-matter is appropriate. It reads the flag and obeys.

/policy-monitor

Sweep mode (no argument or --sweep):

1. Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → outputs folder path, AI policy document, last sweep date.
2. Use the framework below. Scan outputs folder for files since last sweep.
3. For each output: extract approved practices → diff against current policy commitments and use case registry.
4. Classify gaps: REQUIRED (policy misrepresents current practice) vs ADVISABLE (policy silent).
5. For each gap: quote current policy, describe gap, draft suggested language.
6. Flag any use cases in outputs not yet added to the ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md registry.
7. Present results to the human. Only after acknowledgment, update Last policy sweep and gaps_found in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md.

Direct query mode (with description argument):

1. Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → current policy commitments, use case registry, actual policy document.
2. Parse proposed practice. Diff against policy: use case coverage, automation level, affected parties, disclosure, vendor data use, oversight.
3. Output: covered / missing / conflicting + suggested language for each gap + registry entry if needed + timing recommendation.

Recurring runs: Set up a recurring reminder in your own scheduler to run /ai-governance-legal:policy-monitor weekly. Scheduled execution requires a scheduled-tasks integration, which is not bundled with this plugin.

/ai-governance-legal:policy-monitor
/ai-governance-legal:policy-monitor "We want to use AI to automatically flag expense reports for review"

Purpose

AI policies drift from practice faster than almost any other policy document — the field moves quickly, use cases multiply, and each approved AIA or triage result represents a new commitment the policy may not have caught up with. An AIA approves a new AI use case with a human-oversight condition. A vendor AI agreement permits data processing the policy doesn't mention. A triage result marks a new category of deployment as conditional with a disclosure requirement. The policy sits there unchanged.

This skill catches the drift — either by crawling the outputs folder weekly, or by answering the direct question: "we're about to start doing X, what does that mean for our AI policy?"

The output is always the same: here's the gap, here's the suggested language.

Load current state

Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md:

• ## AI policy commitments — commitments extracted from the published policy
• ## Use case registry — approved, conditional, and never use cases
• ## Outputs — outputs folder path, AI policy document location, last sweep date

If ## Outputs contains [PLACEHOLDER]:

"Outputs aren't configured yet. I can still run a direct-query check — describe what you're planning to do and I'll diff it against your current AI policy. To enable the crawl sweep, run /ai-governance-legal:cold-start-interview and provide the outputs folder path."

Read the actual AI or acceptable use policy document from the path in ## Outputs → AI policy document. The commitments in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md are a summary; the actual document is authoritative for suggesting edits.

Mode detection

Sweep mode: No argument, --sweep, or triggered by schedule. → Scan the outputs folder. Diff all outputs since last sweep against current policy.

Direct query mode: User provides a description of a proposed new AI practice. → Diff that practice against current policy and use case registry. Suggest updates.

Mode 1: Sweep

Determine scope

Read ## Outputs → Last policy sweep date. Scan for output files in the outputs folder dated after that date. If no date is recorded, scan all files and note: "First sweep — scanning all outputs."

If the outputs folder is empty or has no new files since the last sweep:

"No new outputs since [last sweep date]. AI policy appears current with recent practice. Next scheduled sweep: [date]."

Do not update Last policy sweep or gaps_found automatically. After the sweep results are presented, wait for the human to acknowledge them ("sweep acknowledged," "results reviewed," or equivalent). Only then update ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md:

• Last policy sweep: [date of acknowledgment]
• gaps_found: [N] (number of REQUIRED + ADVISABLE gaps found in that sweep)

Updating the stamp before acknowledgment would let an unreviewed sweep silently roll forward and suppress the next sweep's attention to the same gaps.

What to read in each output type

AIAs (AI Impact Assessments):

• Extract: use case approved, AI system description, deployment mode (assistive / augmentative / automated), conditions imposed, affected parties, vendor used, any disclosure requirements to affected individuals
• Flag: use cases not in the registry, use cases approved with conditions not reflected in policy, vendor added that policy doesn't cover, automated decision deployed where policy implies human oversight

Triage results (CONDITIONAL / APPROVED outcomes):

• Extract: use case classified, tier assigned, conditions imposed
• Flag: new use case categories not in registry, conditions that imply policy commitments (e.g., "must disclose to affected parties" — does the policy say you do this?), newly approved practices that expand policy scope

Vendor AI reviews (signed / approved):

• Extract: vendor added, data use terms agreed to, any AI-specific provisions accepted that differ from standard positions in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md
• Flag: vendors added whose data use terms the policy should reference (e.g., "we use third-party AI services and ensure they do not train on our data"), approved deviations from standard positions that the policy implies you hold

Use case registry updates:

• If new entries were added to the registry since the last sweep (directly, not through an AIA), check whether the policy reflects those approved categories.

Gap identification

For each flagged item, assess:

REQUIRED update — the policy makes a commitment that an output contradicts, or an approved use case has no policy coverage and affects external parties. Not updating creates a material misrepresentation.

Example: AI policy says "we do not use AI in employment decisions." An AIA approved an AI-assisted hiring screening tool with human review required. Policy needs updating — even with human review, AI is now involved in employment decisions. "We do not use AI" is no longer accurate.

ADVISABLE update — policy is silent but not in conflict. The practice is defensible without updating, but cleaner with it. Important when the practice affects external parties or creates a reasonable expectation.

Example: Policy says "we use AI to improve our products and services." An AIA approved an AI feature for customer support drafts. Policy technically covers it but is vague. Advisable to be more specific so customers know what they're interacting with.

Sweep output format

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

*This sweep is derived from AIAs, triage results, and vendor AI reviews that carry the plugin's privilege/confidentiality marking. The sweep inherits that status. Distribute deliberately — forwarding gap findings outside the privilege circle can waive privilege on the underlying assessments.*

# AI Policy Monitor — Sweep Report

**Date:** [date]
**Outputs scanned:** [N files] | **New since last sweep:** [N files]
**Gaps found:** [N] REQUIRED | [N] ADVISABLE

---

## REQUIRED updates

### [Gap 1 short name]

**Source:** [filename / output type that triggered this]
**What's happening:** [plain description of the new practice]
**Current policy:** [quote the relevant section — or "No coverage"]
**Gap:** [what's missing or inconsistent]

**Suggested language:**
> *Add to / update [section name]:*
> "[Drafted policy text — specific, consistent with house style of the actual policy]"

---

[repeat for each REQUIRED gap]

---

## ADVISABLE updates

### [Gap name]

**Source:** [filename]
**What's happening:** [description]
**Current policy:** [quote or "Silent"]
**Suggested language:**
> *Add to / update [section]:*
> "[Drafted text]"

---

## No action needed

[List outputs scanned where no gaps were found]

---

## Use case registry sync

[Any use cases approved since the last sweep that aren't yet in the `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`
registry — suggest registry entries to add]

---

## Next steps

- [ ] Review REQUIRED updates — decisions needed before the associated use cases
  go live (or immediately if already live)
- [ ] Review ADVISABLE updates — lower urgency, address at next policy refresh
- [ ] Add new use cases to registry (if any flagged above)
- [ ] Next scheduled sweep: [date]

Mode 2: Direct query

Parse the proposed practice

Extract from the user's description:

• What AI system or capability is being introduced?
• What does it do — assistive, automated decisions, content generation?
• Who does it affect — employees, customers, third parties?
• Which vendor or model is involved?
• Is there human review, or is it fully automated?
• Are affected parties told the AI is involved?
• Any data flowing to a vendor that wouldn't be expected?

If the description is vague, ask one clarifying question. Don't run a long intake — direct query mode should be fast.

Policy diff

Check the proposed practice against the current policy and use case registry:

Direct query output format

# AI Policy Check: [Proposed practice in one line]

**Bottom line:** [POLICY UPDATE REQUIRED / ADVISABLE / NO UPDATE NEEDED]

---

## What's covered

[Aspects of the proposed practice already addressed — brief, confirms no change needed]

## What's missing

### [Gap 1]

**Current policy:** [quote or "Silent"]
**What's needed:** [why this gap matters — legal, reputational, or expectation reason]

**Suggested language:**
> *Add to [section]:*
> "[Drafted text]"

### [Gap 2]
[same format]

## What conflicts

### [Conflict 1 — if any]

**Current policy says:** [quote]
**Proposed practice does:** [what conflicts]
**Resolution:** [which one needs to change — usually practice adjusts to match policy,
or policy is updated to a defensible new position; never silently accept both]

---

## Use case registry

[If this use case isn't in the registry: "Add to `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` → Use case registry:"]

| [use case] | [Approved/Conditional] | [conditions] | — |

---

## Timing

[REQUIRED: "Policy update should happen before this practice goes live — or
immediately if it's already running."
ADVISABLE: "Can proceed; update at next policy refresh."]

Suggested language quality standards

AI policy language is unusually prone to becoming outdated — the field moves fast and vague language ages better than specific commitments. When drafting:

• Match the voice and style of the existing policy (read the actual document)
• Prefer durable language: "AI-assisted" rather than naming specific models that will change; "automated or AI-assisted decisions" rather than technical descriptions
• Don't draft commitments the team can't keep — "we always have a human review AI outputs" is broken the moment one automated workflow ships
• When a policy position is genuinely changing (not just extending), say so explicitly: "This update reflects that we now use AI in [new category] — the previous language did not cover this."
• For disclosure language: draft it to be readable by the affected party (employee, customer), not just legally accurate

Always say which section to add to. If the right section doesn't exist, suggest creating it and draft the header.

Schedule integration

The weekly sweep is designed to run on a recurring cadence. Set up a recurring reminder in your own scheduler to run /ai-governance-legal:policy-monitor weekly. Scheduled execution requires a scheduled-tasks integration, which is not bundled with this plugin.

After each sweep, the Last policy sweep and gaps_found fields in ## Outputs are updated only once the human has acknowledged the sweep results (see "Determine scope" above).

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

What this skill does not do

• It doesn't update the policy itself — it drafts suggested language and flags decisions, but a human reviews and approves every change.
• It doesn't catch incoming regulations — that's reg-gap-analysis. This skill monitors internal practice drift, not external legal changes.
• It doesn't enforce that outputs are saved — if AIAs and triage results aren't being saved to the configured folder, the sweep won't find them. Direct-query mode works without saved outputs.
• It doesn't read email, Slack, or informal decisions — only structured outputs saved to the configured folder.
• It doesn't update the use case registry automatically — it flags registry gaps and drafts entries for human review before adding.

/policy-starter

1. Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. If the practice profile is unpopulated, stop and direct to /ai-governance-legal:cold-start-interview.
2. Use the framework below.
3. Run the scope interview — which sections does the policy need to cover, who's the audience, what's the deployment context. Do not skip to drafting.
4. Web search for the current published model policies and guidance relevant to the deployment context (ABA, state bars, ILTA, CLOC, NIST, peer-firm / peer-company policies, current state AI laws, EU AI Act, sector regulators as applicable).
5. Draft the selected sections, sourced from the model policies, with [review] flags on every choice point and [review] open questions at the bottom of each section.
6. Output with the draft header ("DRAFT FOR INTERNAL LEGAL REVIEW — NOT FOR DISTRIBUTION"), the sources block, the reviewer note, and the adoption checklist.
7. Close with the next-steps decision tree.

/ai-governance-legal:policy-starter
/ai-governance-legal:policy-starter "we need an AI policy for our 30-lawyer firm"
/ai-governance-legal:policy-starter "update our existing policy for the 2026 state AI laws"

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /ai-governance-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

A lot of firms and in-house teams don't have a written AI usage policy yet, or are running on a 2024-vintage one that doesn't mention the state AI laws, the EU AI Act implementing acts, the 2025 COPPA amendments, or what they actually ended up doing with Copilot and Claude for Work. This skill produces a draft policy to bring to the decision-maker — GC, managing partner, executive committee, board, head of IT, head of HR — not a finished policy to circulate.

The discipline of this skill:

1. Source from published model policies, not from invention. Search for and read the ABA AI Toolkit, state bar guidance, ILTA's model policy, CLOC's templates, and peer-firm / peer-company policies that are public. Cite what each source says and adapt it — don't generate policy language out of thin air.
2. Decision-tree the scope before drafting. A policy that tries to cover everything covers nothing. Ask the user what sections the policy needs. Let them pick. Then build each picked section with [review] flags on every choice point.
3. Flag every judgment call. The output is a draft the attorney reviews and adopts; every threshold, every named tool, every disclosure trigger, every enforcement consequence is a [review] line.
4. Header signals the scope of the audience. This output may be read beyond legal — by HR, IT, all staff. The header is adapted accordingly.

This skill does NOT finalize, distribute, publish, or even recommend a specific position on the hard calls. It produces a draft and surfaces the choices.

Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md first

Before drafting, always read the practice profile. The sections that drive the draft:

• ## Company profile — AI role (Builder / Deployer / Both), regulatory footprint, external commitments, practice setting
• ## Use case registry — what's already approved, conditional, or a red line
• ## AI policy commitments — what a prior or current policy already says
• ## Vendor AI governance — what the team already requires from vendors
• ## Governance team and escalation — who approves, who escalates
• ## Who's using this — Role (lawyer / non-lawyer) governs the header and the "adopt this" framing

If ## AI policy commitments is populated, this is an UPDATE, not a new draft — treat the existing policy as the base and propose changes. If it's empty, this is a first-cut draft.

Scope interview (do this BEFORE drafting)

Ask the user which sections the policy should cover. Present as a checklist — the user picks, you build. Do not pre-decide.

What should the AI policy cover? Pick the sections you want in the draft:

1. Scope — who the policy applies to (all staff, certain roles, contractors), what tools it covers (GenAI only, all AI, specific vendors), what data is in/out of scope.
2. Permitted and prohibited uses — the approved categories, the red lines, the "ask first" cases.
3. Approval and review — who approves a new tool, who approves a new use case, how the review request is filed, what the SLA is.
4. Disclosure — to clients (for firms), to courts, to counterparties, to employees, to end users of an AI feature.
5. Data handling — what confidential/client/privileged data can go where, data residency, vendor retention terms, training-on-data posture.
6. Training and certification — who has to take training, on what cadence, consequences for non-completion.
7. Incidents and reporting — what counts as an AI incident, how to report, who handles.
8. Enforcement — what happens when the policy is violated, link to disciplinary framework.
9. Review cadence and ownership — how often the policy gets updated, who owns updates, how changes are communicated.
10. Glossary — defined terms (GenAI, approved tool, high-risk use, consequential decision, confidential data, etc.).

Default starter pack for a firm / in-house legal team that's never had a policy: 1, 2, 3, 4, 5, 9. Skip the rest for v1.

After the user picks, ask the second question:

Two more inputs before I draft:

• Audience — who's reading this? (All staff / legal team only / attorneys plus staff / client-facing version also needed) This drives tone and the glossary.
• Deployment context — (a) law firm, (b) in-house legal at a company (policy covers legal or company-wide?), (c) legal aid / clinic, (d) government. This drives which model policies I search.

Source the model policies

Before drafting, run web searches for the most recent published model AI policies and guidance.

Derive the model policy sources from the practice profile's ## Regulatory footprint. Don't hardcode US sources for a global user.

If the practice profile's footprint is empty or [PLACEHOLDER], ask: "What jurisdiction(s) does your organization operate in? I'll draft from the model policies that match your regulatory environment and professional responsibility framework, not a US-centric template."

For each source the draft uses, record it in a "Sources" block at the top of the output with: name, URL, date accessed, and what the draft took from it.

If a web search can't be run, note in the reviewer note: "Could not run web search — draft sourced from training knowledge alone, verify against current versions of the cited sources before adopting." The verification log applies.

The draft

Output follows a consistent structure. Every choice point gets a [review] flag. The user has to decide; the skill presents options.

Header

DRAFT FOR INTERNAL LEGAL REVIEW — NOT FOR DISTRIBUTION
Prepared for: [firm / company name from practice profile]
Date: [today's date]
Prepared by: ai-governance-legal policy-starter skill, adapted from published model policies
Not for adoption, distribution, posting, or reliance until reviewed, adapted, and approved by [attorney / GC / managing partner / executive committee per the governance team section of the practice profile].

When the Role in ## Who's using this is Non-lawyer: add a second line under the header — "If you are not a licensed attorney, solicitor, barrister, or other authorised legal professional in your jurisdiction, bring this draft to your attorney contact ([name from practice profile]) before using any of it. This is a starting draft for their review, not a policy you can adopt."

Sources block (at the top, under the header)

A table of the model policies / guidance / regulations the draft drew from:

Executive summary

Three paragraphs max. What the policy does, who it binds, what the reader has to do before it takes effect.

The sections

Only the sections the user picked, in the order above. For each:

• A header and scope sentence.
• The substantive rules, adapted from the cited model policies. Every specific threshold, number, named tool, named vendor, or escalation contact is [review]. Example: "Confidential client data may not be entered into [general-purpose consumer AI tools] [review — list tools, or reference the approved-tools list]. Use of such data in [approved firm-licensed tools] [review — list tools] is permitted subject to the data handling section."
• Source attribution inline where a rule is adapted from a specific source. Example: "Attorneys must verify the accuracy of all AI-generated work product before using it in representation of a client [ABA Formal Op. 512]."
• Open questions at the bottom of each section — 2-3 decisions the attorney needs to make before the section is ready. These are distinct from inline [review] flags — these are the "we don't have a position here yet" items, not the "fill in the specifics" items.

Adoption checklist

At the end of the draft, a checklist of the things that have to happen before the policy is adopted. Don't invent these — pull from the practice profile's governance team and escalation section. Typical items:

• Review by GC / managing partner [review — name]
• Review by IT / security [review — name]
• Review by HR (for enforcement / training sections) [review — name]
• Board / executive committee approval (if required) [review — confirm whether required]
• Training materials drafted
• Announcement drafted
• Effective date set [review]
• Review cadence calendared [review — annual is typical]
• Add policy to the ## AI policy commitments section of the practice profile once adopted

Reviewer note

The standard reviewer note above the header, per the ## Outputs section of the practice profile. Use the block format:

⚠️ Reviewer note

• Sources: web search ✓ / not connected — cites from training knowledge
• Read: practice profile · [N] published model policies
• Flagged for your judgment: [N] [review] items inline · [N] open questions per section
• Currency: searched for developments since [date]
• Before relying: this is a DRAFT — bring to [approver from practice profile], don't distribute until adopted

Don'ts

• Don't invent policy language. Every substantive rule in the draft must be traceable to a cited source or flagged [review — adapted, no direct source].
• Don't pick the hard calls for the attorney. "Should paralegals be permitted to use AI for first-draft work?" is a [review], not a recommended position.
• Don't produce a finished-looking policy. The header, the reviewer note, and the [review] flags throughout are the signal that this is a draft. Do not soften them.
• Don't skip the scope interview. If the user says "just draft a full policy," push back: "A policy that tries to cover everything covers nothing. Which sections do you want? Here's the checklist." One round of negotiation is fine — two is also fine. Drafting without scope is the failure mode.
• Don't generate section content the user didn't ask for. If they picked 1, 2, 3, 4, 5, 9, do those. Don't add section 6 because "a real policy needs training."
• Don't recommend a specific vendor, tool, or consequence. Flag those [review] with context on what a typical decision would be, not what the user's should be.
• Don't promise legal sufficiency. The draft is a starting point for attorney review, not a tested policy.

Handoffs

After the draft is produced, close with the decision tree from the practice profile. The most common next steps:

1. Tune the draft — the user walks through the [review] flags and resolves them with the attorney; the skill re-runs with the decisions baked in.
2. Stakeholder summary — produce a one-page version for the board or executive committee explaining what the policy does and doesn't do.
3. Training materials — once the policy is adopted, /ai-governance-legal:aia-generation can be used to produce per-use-case training notes.
4. Vendor sweep — once the policy is adopted, /ai-governance-legal:vendor-ai-review should be run against the vendors the policy references to check conformance.
5. Gap check against new regulation — pair with /ai-governance-legal:reg-gap-analysis to test the draft against a specific regulation or guidance before adoption.

Output scope reminder

The document this skill produces reaches HR, IT, and the broader business — not just legal. Keep the language plain enough for non-lawyers to follow. The legal precision is in the [review] flags and the sources, not in jargon.

/reg-gap-analysis

1. Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. Confirm regulatory footprint and use case registry are populated.
2. Use the framework below.
3. Scope: does this regulation apply? (Jurisdiction, threshold, builder/deployer, sector.) If not, one line and done.
4. Extract requirements. Diff against current state in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md.
5. Prioritize gaps. Output: remediation plan with must-do / should-do / already compliant / accepted gaps.
6. Save as dated markdown doc for the file.

/ai-governance-legal:reg-gap-analysis "EU AI Act high-risk provisions"

Purpose

The EU AI Act goes live. Colorado passes an AI law. The CFPB issues model risk guidance. The FTC publishes an AI enforcement policy. Something moves — and now you need to know what, if anything, you have to change.

This skill diffs the new requirement against your current AI governance posture (per ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md — use case registry, vendor positions, impact assessment practices, and AI policy commitments) and produces a gap list with a remediation plan.

The AI regulatory landscape is moving faster than any other area of law right now. When a regulation is genuinely ambiguous, say so. Don't paper over uncertainty — legal teams need to know when they're on solid ground versus when they're making a judgment call.

Load current state

Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md:

• ## Regulatory footprint — what already applies
• ## Use case registry — what AI you're actually running, and under what conditions
• ## AI policy commitments — what you've publicly or contractually committed to
• ## Vendor AI governance — what vendor positions are in place
• ## Impact assessment house style — what assessment practices exist

If the regulation clearly doesn't apply (wrong jurisdiction, below threshold, wrong sector, builder/deployer distinction eliminates you from scope), say so directly: "Doesn't apply. Here's why: [reason]. No action needed."

Research first, then workflow

Before running the gap analysis, research the currently operative AI regulatory regimes for the jurisdictions in the user's footprint. For each regime identify:

• Scope — who's covered (provider/builder vs. deployer vs. distributor vs. user; sectoral carve-outs).
• Applicability thresholds — revenue, user count, headcount, compute, model category, affected-population size.
• Risk-tier definitions — how the regime distinguishes tiers (prohibited / high-risk / limited-risk / minimal), what's in each.
• Substantive obligations — transparency, documentation, human oversight, bias testing, registration, incident reporting, vendor flow-down.
• Enforcement mechanism — which regulator, what penalties, any private right of action.
• Effective dates — many AI laws phase in obligations over 2-4 years; note which obligations are live vs. upcoming.

Cite the regulatory text with pinpoint references. Flag provisions subject to ongoing interpretation, delegated acts, or pending rulemaking. The AI regulatory landscape changes quickly — verify currency before advising.

Build the gap analysis from the researched requirements, not from hardcoded reference tables.

Workflow

Step 1: Scope the regulation

Before diffing, answer:

• Does it apply? Jurisdiction, threshold, sector carve-outs, builder vs. deployer distinction. Research the specific scoping rules in the regulation — don't assume.

  Builder/deployer matters a lot here. Many AI regimes impose different obligations on the entity that develops/provides the AI system versus the entity that deploys/uses it. Research which role the company occupies under each regime's definitions. Scope first; don't gap-analyze a law that doesn't apply.

• When? Effective date. Enforcement date (often different). Phase-in periods for specific provisions. Verify currency.

• What's actually new? Some "new" AI laws largely restate existing legal principles (consumer protection, anti-discrimination, sectoral risk management) applied to AI. Others are genuinely new obligations. Identify the delta from what you already do, not the full text of the law.

Step 2: Extract requirements

Read the regulation, guidance, or summary. List every substantive requirement:

Categories:

• Transparency — disclosures to users, employees, or affected parties about AI use
• Impact assessment — required documentation before deployment
• Human oversight — mandatory human review, override, or appeals mechanisms
• Accuracy / testing — bias testing, accuracy documentation, validation
• Governance — registration, record-keeping, designated responsible persons
• Vendor flow-down — obligations to pass down to AI vendors or pass up from AI vendors
• Prohibited practices — outright bans on specific AI capabilities or uses
• Rights — what affected parties can request or invoke

Step 3: Diff against current state

For each requirement:

### [Requirement #N]: [short name]

**Regulation says:** [requirement, quoted or paraphrased]

**We currently:** [what `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` / AI policy / use case registry / assessment
practice shows]

**Gap:** [None | Partial | Full]

**If partial/full — what's missing:** [specific — not "more documentation" but
"no human review step is documented for [use case category]"]

**Effort to close:** [Policy update only | Process change | Product/system change |
New assessment required | Vendor renegotiation | Registration / filing]

**Risk of non-compliance:** [penalty range, enforcement likelihood, reputational]

Step 4: Prioritize

Not every gap is equal. Sort by:

1. Hard deadline with teeth — effective date + active enforcement + real penalties
2. Prohibited practice — if the gap is a prohibition, not a process requirement, that's the first priority regardless of enforcement date
3. Effort-to-impact ratio — updating policy language is cheap; adding human oversight to a deployed system is not
4. Use case overlap — gaps that affect multiple use cases in the registry are higher priority than single-use-case gaps

Step 5: Remediation plan

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

## Remediation Plan: [Regulation name]

**Effective date:** [date]
**Enforcement begins:** [date if different]
**Applies to us as:** [Builder / Deployer / Both]

### Must-do before enforcement

| Gap | Fix | Owner | Due | Status |
|---|---|---|---|---|
| [gap] | [specific fix] | [name] | [date] | [ ] |

### Should-do (important but not blocking enforcement)

[same table]

### Already compliant

[list of requirements where gap = None — useful context for the legal/executive
summary of where you actually stand]

### Accepted gaps (risk accepted, not fixing)

[if any — with documented rationale and who accepted the risk. Documenting accepted
risk is better governance than leaving it unaddressed silently.]

Research the regulation before building the gap analysis

Do not rely on hardcoded reference tables for specific regimes. For each regulation in scope, research the currently operative text:

• Which obligations apply to the company's role (provider/builder, deployer, importer, distributor)?
• Which tier does the system fall into under the regime's own classification (prohibited / high-risk / limited-risk / minimal, or the regime's equivalent)?
• What are the live vs. phase-in dates for each obligation?
• Are there delegated acts, implementing acts, or regulator guidance that affect interpretation?
• For builder contexts: are there model-level obligations (technical documentation, training data transparency, copyright compliance, systemic-risk testing)?
• For prohibited-practice categories: check any use case in the registry that might touch them and flag as critical regardless of enforcement date.

Cite primary sources with pinpoint references. Flag ambiguity for attorney judgment.

No silent supplement. If a research query to the configured legal research tool (Westlaw, EUR-Lex, regulator sites, or firm platform) returns few or no results for a regime's text, delegated act, or guidance, report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [regime / topic]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged [web search — verify] and should be checked against the issuing authority before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources.

Source attribution tiering. Tag every citation in the gap analysis with its source. For model-knowledge citations, use one of three tiers rather than a single blanket "verify" tag:

• [settled] — stable, well-known statutory and regulatory references unlikely to have changed (e.g., GDPR Art. 22, the existence of Regulation (EU) 2024/1689 as the EU AI Act, Colorado AI Act as C.R.S. § 6-1-1701 et seq.). Still verify before filing, but lower priority.
• [verify] — model-knowledge citations that are real but should be verified: specific delegated / implementing acts, regulator guidance, standards, enforcement actions, case holdings, thresholds, effective dates, phase-in provisions, harmonized-standards references.
• [verify-pinpoint] — pinpoint citations (specific article numbers, annex references, subsection letters, paragraph numbers, standard-clause references) carry the highest fabrication risk and should ALWAYS be verified against a primary source. EU AI Act article numbers in particular shifted during consolidation; every pinpoint cite to the Act should be verified against the Official Journal text.

Tool-retrieved citations keep their source tag ([Westlaw], [EUR-Lex], [regulator site], or the MCP tool name); web-search citations remain [web search — verify]; user-supplied citations remain [user provided]. The tiering surfaces the real verification work — a reader who verifies everything verifies nothing. Never strip or collapse the tags.

For non-lawyer users, uncertain dates, thresholds, and phase-in provisions go in a confirm-list, not inline. A [verify] tag on "effective February 1, 2026" reads as "effective February 1, 2026" to a non-lawyer who doesn't know what the tag means. Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. If Role is Non-lawyer and a date, deadline, phase-in, threshold, or effective-date assertion is uncertain (would carry [verify] or [verify-pinpoint] if inline), replace the inline assertion with "effective date: confirm with counsel" (or "threshold: confirm with counsel") and collect all uncertain items in a final gap-analysis section titled: "Things I'm not certain about — ask your attorney to confirm before relying on this:" with each item listed (what I said, what's uncertain, why it matters to the gap). Lawyer-role users keep the inline [verify] treatment.

Integration with other skills

From aia-generation: AIAs flag regulatory obligations for specific systems → those feed here when a regulation is new or coverage is uncertain.

From use case triage: Newly triaged use cases that hit regulatory triggers → gap analysis runs on the specific requirement for that use case type.

To regulatory-legal plugin, if the plugin is installed: This skill is the manual version. The monitor plugin watches feeds and triggers this analysis automatically when something relevant changes.

Output

Save as a dated markdown doc. The remediation plan table becomes a tracker — update status as items close.

If the gap analysis concludes "no gaps, we're compliant," still write the doc. It's useful evidence that you looked, and useful baseline when the regulation is amended.

Cite check before relying on this. Citations here were generated by an AI model and have not been verified against primary sources. Before relying on any citation — statute, regulation, delegated act, guidance, or case — run a verification pass against a legal research tool (Westlaw, CourtListener, or your firm's platform) for accuracy, currency, and subsequent history. Fabricated or misquoted citations in filed materials have resulted in sanctions. Source tags on each citation (e.g., [EUR-Lex], [web search — verify]) show where it came from; verify tags carry higher fabrication risk and should be checked first.

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

What this skill does not do

• It doesn't interpret ambiguous regulatory language authoritatively. The EU AI Act in particular has significant interpretive questions that aren't resolved yet. When the reg is genuinely ambiguous: say so, state the conservative read, and flag for outside counsel if the issue is material.
• It doesn't track regulatory changes proactively. It runs when you point it at a change. For proactive monitoring, see the regulatory-legal plugin, if the plugin is installed.
• It doesn't implement fixes. It plans them.
• It doesn't substitute for sector-specific legal counsel where specialized knowledge is required (healthcare AI, financial services model risk management, etc.).

/use-case-triage

1. Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. Confirm registry is populated — if not, stop and direct to setup.
2. Use the framework below. Clarify the use case if vague.
3. Registry lookup → red line check → classify.
4. Output: classification, reasoning, conditions table (if conditional), governance tier, cross-plugin handoffs.
5. Propose registry update if use case wasn't already in the registry.

/ai-governance-legal:use-case-triage "Sales team wants to score leads with AI automatically"

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /ai-governance-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

Stop the conversation that happens in a hallway and starts as "can we just use AI for this?" Give a fast, calibrated answer from the registry — and if the answer is conditional, make the conditions concrete and the next step obvious.

The triage skill is a gateway, not a destination. Its job is to classify, flag what's required, and route. The aia-generation skill does the deep work.

Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md first

Before triaging, always read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. The use case registry and red lines there are authoritative. Generic AI ethics reasoning is not a substitute for what this company has actually decided.

If ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md contains [PLACEHOLDER], surface this bounce:

I notice you haven't configured your practice profile yet — that's how I tailor the use case registry, red lines, and governance tiers to your practice.

Two choices:

• Run /ai-governance-legal:cold-start-interview (2 minutes) to configure your profile, then I'll triage tailored to YOUR practice.
• Say "provisional" and I'll triage against generic defaults — US jurisdiction, middle risk appetite, lawyer role, no playbook — and tag every output [PROVISIONAL — configure your profile for tailored output] so you can see what I do before committing.

Provisional mode

If the user says "provisional," run triage normally using these generic defaults: middle risk appetite, lawyer role, US jurisdiction, no registry (classify by general AI governance principles rather than matching to a registered entry). Tag the reviewer note and every finding block with [PROVISIONAL]. At the end of the output, append:

"That was a generic run against default assumptions. Run /ai-governance-legal:cold-start-interview to get output calibrated to YOUR practice — your registry, your jurisdiction, your risk appetite. 2 minutes."

Jurisdictional scope. Triage applies the registry, red lines, and governance tiers configured for the regulatory footprint in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. AI rules vary materially by jurisdiction — an APPROVED classification in one footprint may be CONDITIONAL or prohibited in another. If deployment touches a jurisdiction not in the footprint, surface that and re-triage rather than extending by analogy.

Triage process

Step 1: Understand the use case

Before classifying, make sure you understand what's actually being proposed. If the description is vague, ask:

• "What is the AI doing, exactly — generating content, making a decision, surfacing recommendations, automating a task?"
• "Who or what is the AI acting on — employees, customers, third parties, internal data only?"
• "Is a human reviewing the AI output before anything happens, or is it automated?"
• "Which vendor or tool is being proposed?"
• "Is this internal-only, or does it touch customers or other external parties?"

Don't let "we want to use AI for [vague thing]" go untriaged. Get specific enough to classify accurately.

Step 2: Registry lookup

Check the use case registry in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md for a direct or close match.

Direct match: If the registry has a directly matching entry, apply it.

Near match: If the use case is similar to a registry entry but not identical, flag this: "This looks like [registered use case] — I'm applying that classification, but if the scope is meaningfully different, it may need its own assessment."

No match: If the use case isn't in the registry, default to CONDITIONAL pending an AI impact assessment. Surface the preliminary read on risk and route to the AIA.

"This use case isn't in your registry yet. Defaulting to CONDITIONAL pending an AI impact assessment. Here's my preliminary read on risk: [preliminary read]. Next step: run the impact assessment, and I'll add the use case to the registry once classification is settled."

Source attribution (applies whenever the triage cites regulation)

Triage typically stays high-level, but if the classification depends on citing a regulation, statute, rule, directive, standard, or guidance — tag the citation. Do not output untagged regulatory citations in the triage reasoning, the red-line explanation, or the conditions list. A triage that says "Art. 22(1)" without a tag is exactly where a fabricated pinpoint slips past the reader.

Source attribution tiering. For model-knowledge citations, use one of three tiers:

• [settled] — stable, well-known statutory and regulatory references unlikely to have changed (e.g., GDPR Art. 22 as a concept, the existence of Regulation (EU) 2024/1689 as the EU AI Act). Still verify before certifying, but lower priority.
• [verify] — model-knowledge citations that are real but should be verified: specific delegated / implementing acts, regulator guidance, standards, effective dates, thresholds, post-2023 amendments.
• [verify-pinpoint] — pinpoint citations (specific article numbers, annex references, subsection letters, paragraph numbers) carry the highest fabrication risk and should ALWAYS be verified against a primary source. EU AI Act article numbers in particular shifted during consolidation; every pinpoint cite to the Act should be verified against the Official Journal text.

Other sources keep their own tags: [registry] when drawn from the practice profile's use case registry; [Westlaw], [EUR-Lex], [regulator site], or the MCP tool name when retrieved from a connected legal research tool; [web search — verify] for web-search citations; [user provided] for user-supplied citations. The tiering surfaces the real verification work — a reader who verifies everything verifies nothing. Never strip or collapse the tags.

For non-lawyer users, uncertain dates and thresholds go in a confirm-list, not inline. A [verify] tag on "effective February 1, 2026" reads as "effective February 1, 2026" to someone who doesn't know what the tag means. Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. If Role is Non-lawyer and an effective date, phase-in, threshold, or deadline is uncertain (would carry [verify] or [verify-pinpoint] if inline), replace the inline assertion with "effective date: confirm with counsel" (or "threshold: confirm with counsel") and collect all uncertain assertions in a final triage section titled: "Things I'm not certain about — ask your attorney to confirm before relying on this:" with each item listed (what I said, what's uncertain, why it matters). Lawyer-role users keep the inline [verify] treatment.

Step 3: Red line check

Before going further, check the red lines in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md.

If the use case triggers a red line — even partially, even in a charitable reading — say so immediately.

"This use case touches [red line]. Your red lines treat this as an automatic no. If there's something different about this situation, that's a conversation for legal sign-off — not a triage call."

Do not soften red line outcomes. If it's a no, it's a no.

Jurisdictional scope. Ask: "Who's affected, and where are they? (Employees / customers / the general public / specific groups.) Which jurisdictions? (Not just where your company is — where the affected people are.)"

Then check the use case against EVERY regime in the practice profile's ## Regulatory footprint, not just the primary one. Flag conflicts:

• "APPROVED under US law, but triggers EU AI Act Article 27 FRIA if EU residents are affected — confirm whether any affected individuals are in the EU."
• "Standard tier under your governance framework, but NYC LL144 requires a bias audit if used for hiring decisions affecting NYC residents."
• "Low risk under Australian AI Ethics Framework, but may be high-risk under the Colorado AI Act if Colorado residents are affected."

A use case that crosses jurisdictions gets the strictest applicable treatment, not the most convenient one.

Step 4: Classification and output

The APPROVED / CONDITIONAL / NOT APPROVED buckets, the red-line definitions, and the CONDITIONAL required-controls list all come from ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → ## AI use case triage criteria and ## Use case registry. If the playbook doesn't define a criterion the use case turns on, ask the user: "Your playbook doesn't cover [specific question]. What's your default position? I'll add it to ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md so the next triage is consistent."

Before issuing an APPROVED classification (approving an AI use case for deployment): Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. If the Role is Non-lawyer:

Approving this use case for deployment has legal consequences. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:

[Generate a 1-page summary: the use case and its scope, how it maps to the registry, what policies or red lines it touches, what could go wrong in deployment, what to ask the attorney before green-lighting.]

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: your professional regulator's referral service is the fastest starting point (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent).

Do not proceed past this gate without an explicit yes. CONDITIONAL outputs do not require the gate.

Before issuing a NOT APPROVED classification that cuts off a proposed use case: Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. If the Role is Non-lawyer, a symmetric gate applies — wrongly rejecting a use case is also a consequential error, and the business will push back regardless of the triage call:

This is a full stop for a business ask. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:

[Generate a 1-page summary: the use case and its scope, the specific red line or registry entry that blocks it, what a narrower version could look like that might clear elevated tier (if anything), what the business will likely ask the attorney for, and the three questions to ask the attorney before accepting the no.]

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: your professional regulator's referral service is the fastest starting point (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent).

Do not proceed past this gate without an explicit yes. A non-lawyer issuing a hard no on the AI plugin's behalf, without an attorney in the loop, is the mirror failure of a non-lawyer issuing a hard yes.

Format for each triage output:

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see ## Who's using this]

USE CASE: [State the use case as you understand it]

CLASSIFICATION: [APPROVED / CONDITIONAL / NOT APPROVED]

Registry match: [Direct match / Near match — [name] / No match]

Reasoning: [1-3 sentences on why this classification. If approved, what makes it safe. If conditional, what creates the risk that conditions are managing. If not approved, what red line or policy position applies.]

Red lines triggered: [None / List any that apply]

If CONDITIONAL — required before proceeding:

Governance tier: [Standard / Elevated / High — per ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md]

Approval path: [Who needs to sign off, per tier]

Next step — offer to continue:

After presenting a CONDITIONAL result, always end with:

"Want me to start the impact assessment now? I can run the intake questions and produce the assessment document without you needing to run a separate command."

If they say yes, load the aia-generation skill and continue in the same conversation — no need to restart. Pass the use case description and governance tier already determined.

If they say no (or don't respond), the triage result stands as a standalone output. The AIA can be run any time with: /ai-governance-legal:aia-generation [use case]

If NOT APPROVED:

Reason: [Specific red line, policy prohibition, or registry entry]

If there's a version of this that could work: [Optional — "A narrower version that keeps a human in the loop for every adverse decision might clear the elevated tier. That would require..."] Only include if genuinely true. Don't offer a workaround for every no.

Step 5: Cross-plugin handoffs

Privacy handoff: If the use case involves personal data — employee data, customer data, behavioral data — flag it:

"This use case involves personal data. A PIA is likely required in addition to an AI impact assessment. Use /privacy-legal:pia-generation [use case], if the plugin is installed, to run that in parallel."

Product counsel handoff: If this is a new product feature involving AI:

"If this use case is part of a product launch, loop in product counsel. Use /product-legal:launch-review, if the plugin is installed — it will detect the AI component and route to this plugin."

Only flag handoffs that are actually relevant. Don't append both as boilerplate to every triage.

Step 6: Registry update suggestion

If this triage resulted in a classification that isn't in the registry yet — either a no-match or a near-match that revealed a gap:

"I'd suggest adding this to your use case registry. Proposed entry:"

| [Use case description] | [Approved/Conditional/Never] | [Conditions if any] | [Reason if Never] |

"Add to ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → Use case registry. This means next time the same request comes up, the answer is documented and consistent."

Batch triage

If the user presents multiple use cases at once — a list, a backlog, a product roadmap — run through each one and output a summary table first, then expand each conditional or not-approved entry:

Then expand each row that isn't a clean approved.

Edge cases and failure modes

"We're already doing this" triage: If someone is asking for retroactive triage — the use case is already deployed — say so plainly, and before classifying from scratch, search the registry for an existing entry covering the deployed version. Retroactive triages often surface a superseded registry entry whose conditions have drifted from current practice; updating that entry is usually the right follow-up rather than adding a new row.

"This looks like retroactive triage. If this is already running without an assessment, that's a gap to document, not to wave through. I'm searching the registry for any existing entry covering this deployment before running the triage fresh. Here's the classification: [run normal triage]. If it's conditional, those conditions should be confirmed in place now, not assumed. If the registry has an existing entry and the deployed version has drifted, the right follow-up is updating that entry rather than adding a new one."

"It's just internal" doesn't change the analysis: Internal AI use affecting employees (screening, monitoring, evaluation) is often higher-risk than customer-facing AI. Flag this if the user implies internal scope reduces risk.

"The vendor says it's safe": Vendor representations don't substitute for your own impact assessment. Flag it:

"The vendor's position doesn't substitute for your own assessment — especially for anything in the elevated or high tier."

"We're just piloting": A pilot that touches real employee or customer data is not exempt from triage or impact assessment. Apply the same classification; if conditions include an impact assessment, the pilot should have one too.

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

/vendor-ai-review

1. Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. Confirm vendor governance positions are populated — if not, stop and direct to setup.
2. Use the framework below.
3. Confirm document type (AI addendum / main agreement AI provisions / ToS). If only an AUP was provided, ask for the full terms.
4. Term-by-term review: training on data, confidentiality of inputs, model changes, output IP, liability, incident notification, human review rights, use restrictions, audit rights.
5. AI addendum gap check if DPA exists but no AI addendum.
6. AI policy consistency diff vs. ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md.
7. Output: bottom line, term-by-term, recommended redlines, if-they-won't-move routing.

/ai-governance-legal:vendor-ai-review openai-enterprise-agreement.pdf

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /ai-governance-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

Vendor AI terms are where your governance positions actually get tested. The cold-start interview captures what you want. This skill checks what you agreed to — and flags the gaps between those two things.

The direction here is always the same: we are the deployer or buyer reviewing the vendor's terms. This is the opposite posture from the DPA review controller/processor question — there's no flip.

What varies is the input:

• A standalone AI agreement or AI addendum (most structured)
• A vendor's universal terms of service with AI provisions embedded (often buried)
• An acceptable use policy (tells you what you can't do; says nothing about what the vendor can do with your data or outputs)
• A combination — master agreement + DPA + AI addendum (common for serious enterprise AI vendors)

When there's a DPA already in place, this review complements it — it's not a substitute. The DPA governs data protection obligations; the AI terms govern model-specific rights and risks. Both need to be reviewed.

Load the playbook

Read ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → ## Vendor AI governance. Also read ## AI policy commitments — vendor terms can't be consistent with a use restriction our own policy imposes if we've agreed to something different.

If ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md contains [PLACEHOLDER], surface this bounce:

I notice you haven't configured your practice profile yet — that's how I tailor vendor governance positions to your practice.

Two choices:

• Run /ai-governance-legal:cold-start-interview (2 minutes) to configure your profile, then I'll review tailored to YOUR positions.
• Say "provisional" and I'll review against generic defaults — US jurisdiction, middle risk appetite, lawyer role, no playbook — and tag every output [PROVISIONAL — configure your profile for tailored output] so you can see what I do before committing.

Provisional mode

If the user says "provisional," run the vendor AI review normally using these generic defaults: middle risk appetite, lawyer role, US jurisdiction, no playbook (flag all common vendor-AI risks from first principles rather than matching to configured positions). Tag the reviewer note and every finding block with [PROVISIONAL]. At the end of the output, append:

"That was a generic run against default assumptions. Run /ai-governance-legal:cold-start-interview to get output calibrated to YOUR practice — your vendor governance positions, your jurisdiction, your risk appetite. 2 minutes."

Before reading the document

If the user hasn't shared the actual vendor terms, ask:

"Can you share the vendor's AI terms? The most useful thing is the actual contract language — the AI addendum if there is one, or the main agreement with AI provisions highlighted. An acceptable use policy alone won't tell us what the vendor can do with our inputs; it only tells us what we're allowed to do."

If they share an acceptable use policy only:

"This is the acceptable use policy — it tells us what we can't do with the vendor's AI. That's useful context, but it doesn't address the commercial terms: whether the vendor can train on our data, what their liability is for AI errors, whether they notify us when the model changes. Do you have the service agreement or AI addendum?"

The term-by-term review

Core AI-specific terms (check every vendor AI agreement)

Review each term below. For each, extract what the vendor's contract actually says and compare it against the position in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → ## Vendor AI governance (standard / acceptable fallback / automatic no). The default positions come from the team's playbook, not from this skill.

If ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md doesn't define a position for a term on this list, ask: "Your playbook doesn't cover [term]. What's your default position, your acceptable fallback, and your automatic no? I'll add it to ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md so the next review is consistent."

Playbook comparison

For each term above, compare what we found to the positions in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md.

Output format for each term:

[Term name] 🟢 / 🟡 / 🟠 / 🔴 Vendor says: [summary of what the contract actually says] Our position: [from ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md] Gap: [specific delta — or "Aligned"] Proposed fix: [specific redline language, or "escalate — outside fallback"]

Use the severity ratings consistently (calibrated against ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md positions):

• 🟢 Aligned — at or better than the standard position in the playbook.
• 🟡 Note — within fallback but worse than standard; flag for awareness, not a blocker.
• 🟠 Significant — outside standard position but within fallback; needs redline before signing.
• 🔴 Critical — outside fallback; deployment should not proceed without resolution. Escalate per ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md.

AI addendum gap check

If the vendor has a DPA but no AI addendum:

"There's a DPA in place but no AI-specific addendum. The DPA covers data protection obligations but doesn't address: training on our data, model change notification, liability for AI outputs, or incident notification for AI system failures.

For a [Standard / Elevated / High] tier use case, this gap is [acceptable at Standard tier / a blocker at Elevated or High tier]. Recommend requesting an AI addendum or at minimum negotiating AI-specific terms into the next renewal."

If there are no AI terms at all:

"There are no AI-specific terms in this agreement. The vendor is providing an AI-powered service under general service terms — which means we have no contractual protection on the highest-risk AI governance items (training, liability, model changes). This is a 🔴 for any Elevated or High tier use case."

AI policy consistency check

Cross-check the vendor's terms against our AI policy commitments in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md.

Common conflicts:

• Our policy prohibits vendor training on our data — the vendor's terms permit it by default. (Contract needs explicit prohibition or opt-out confirmation.)
• Our policy requires human review for certain use cases — vendor's terms say AI outputs are final. (Workflow needs to impose the human step, not the vendor terms.)
• Our approved vendor list doesn't include this vendor — or blocklist does.
• Our policy requires disclosure to affected parties — vendor's terms impose a confidentiality obligation on AI system capabilities that would prevent disclosure.

Flag every mismatch. One of them has to change.

Redline granularity

Edit at the smallest possible granularity. A redline is a negotiation artifact, not a rewrite. Wholesale clause replacement signals "we threw out your drafting" — it's aggressive, it forces the counterparty to re-read the whole clause, and it discards the parts of their drafting that were fine. Surgical redlines — strike a word, insert a phrase, restructure a subclause — signal "we have specific asks" and are faster to read, understand, and accept.

Default to the smallest edit that achieves the playbook position:

• Replace a word before a phrase. ("twelve (12)" → "twenty-four (24)")
• Replace a phrase before a sentence. ("paid by the Buyer" → "paid and payable by the Buyer")
• Restructure a subclause before replacing the sentence. (Add "(a)" and "(b)" to split a compound condition.)
• Replace a sentence before replacing the clause.
• Only replace a whole clause when the counterparty's version is so far from your position that surgical edits would be harder to read than a fresh draft — and when you do, say so in the transmittal: "We've replaced §8.2 rather than marking it up because the changes were extensive. Happy to walk you through the delta."

When in doubt, smaller. A client who receives a surgical redline trusts that you read carefully. A client who receives a wholesale replacement wonders whether you read at all.

Output

Before recommending signature of a vendor AI agreement (the version the company will execute): Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. If the Role is Non-lawyer:

Signing this vendor AI agreement has legal consequences. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:

[Generate a 1-page summary: the vendor and the use case, the key terms reviewed (data use, liability, auditability, model change, human review), where vendor positions diverge from policy, what's being accepted, what could go wrong, what to ask the attorney.]

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: your professional regulator's referral service is the fastest starting point (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent).

Do not proceed past this gate without an explicit yes. Review/redline drafts for attorney consideration do not require the gate — signature does.

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

*This review is derived from vendor contract terms that are typically confidential under NDA, and it may itself be privileged. It inherits the source's confidentiality and privilege status. Distributing it beyond the privilege circle (e.g., forwarding to the vendor, sharing in an open channel) can waive privilege and breach the NDA. Mark, store, and route accordingly.*

# Vendor AI Review: [Vendor Name]

**Document reviewed:** [AI addendum / main agreement AI provisions / ToS]
**Reviewed:** [date]
**Use case(s):** [what we're deploying this vendor's AI for]
**Governance tier:** [Standard / Elevated / High]

---

## Bottom line

[Two sentences. Can we deploy under these terms? What has to change first?]

**Issues:** [N]🔴 [N]🟠 [N]🟡 [N]🟢

---

## Term-by-term

[For each term above — vendor position, our position, gap, severity, proposed fix]

---

## AI addendum status

[Present / Absent — and what that means for this deployment]

---

## AI policy consistency

[🟢 Consistent | 🟡 Flags: list]

---

## Recommended redlines

[Consolidated draft redlines. Review with counsel before sending externally. For critical
issues where no fallback exists, flag for escalation rather than proposing language.]

---

## If they won't move

[For each 🔴 and 🟠: the fallback from `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`, or "escalate — outside fallback"
and routing per escalation table]

Practical notes

The training-on-data clause is the one most people miss. Vendor AI terms have historically varied widely on whether API inputs can be used to train or improve models — some vendors permit it by default, others prohibit it, and many have changed their position over time. Do not assume any particular vendor's current stance without reading the specific agreement in front of you. This is almost always the most important term for any company with confidential or sensitive data, and it must be confirmed in writing, not assumed from reputation or prior experience.

Map the AI stack. Modern AI deployments are layered. Before reviewing terms, map the layers:

1. End-user SaaS application (e.g., a legal tech tool, a CRM with AI scoring, a document assistant) — the tool your org signs up for
2. API gateway / orchestration layer (e.g., Azure OpenAI Service, AWS Bedrock, Google Vertex, LangChain-hosted) — often invisible, always has its own terms
3. Model provider (e.g., Anthropic, OpenAI, Google, Meta) — the LLM
4. Hosted knowledge base / RAG source (e.g., a vector database, a third-party data corpus, a retrieval service) — the data Claude reads from
5. Additional subprocessors — analytics, logging, fine-tuning partners

Ask: "Walk me through the stack — what does [SaaS tool] use under the hood? Is it built on a cloud AI service? Does it call a model provider directly or through a gateway? Does it use a hosted knowledge base?" Then review terms at EACH layer, not just the top.

Each handoff between layers is a flow-down risk. A commitment at layer 1 ("we won't train on your data") means nothing if layer 3's terms say otherwise and layer 1 never flowed the commitment down.

Flow-down test. For each flagged stacked-vendor term — especially training-on-data, data retention, subprocessor changes, and liability — don't just flag "check upstream terms." DO THE CHECK:

1. Search the contract for flow-down language. Look for: "subprocessor obligations no less protective than," "flow-down of data commitments," "back-to-back terms," "Provider shall ensure that its subprocessors are bound by," "equivalent obligations."
2. If present: Quote it, verify it covers the specific flagged term, and flag whether it's enforceable (who can enforce it — you, or only the intermediate vendor?).
3. If absent: Produce a specific redline requiring it:

   "Add to §[X]: Provider shall ensure that any third-party model providers, infrastructure providers, or subprocessors used in delivering the Services are bound by obligations with respect to [Customer Data / AI training / data retention / confidentiality] no less protective than those set forth in this Agreement, and shall be responsible for any breach of this Agreement caused by such third parties."

4. Flag the gap with a severity: 🔴 if the term is training-on-data or liability and there's no flow-down; 🟡 if the term is less sensitive or there's partial flow-down.

"Escalate and check upstream" is where compliance dies. Produce the test and the redline.

Acceptable use policies flip the frame. AUPs tell you what you can't do; they don't tell you what the vendor can do. Don't let a clean AUP review substitute for reading the data use and liability terms.

Renewals are leverage points. If the current agreement is unfavorable and the vendor won't renegotiate mid-term, document the gaps now and flag them for the renewal. Flag to procurement: "This renewal should not close without AI addendum addressing [list]."

Builder context adds a layer. If the company is a builder using a vendor's model as a foundation, the vendor's terms also govern what the company can offer its own customers. Some terms prohibit certain downstream uses. Check use restrictions against the product roadmap, not just current internal workflows.

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

What this skill does not do

• It doesn't review the DPA provisions of the same agreement — run /privacy-legal:dpa-review, if the plugin is installed, for that.
• It doesn't decide whether to accept terms outside the fallbacks. It routes those per the escalation table in ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md.
• It doesn't evaluate vendor security posture beyond what's in the agreement — that's a security team function.

/amendment-history

Loads a base agreement and all amendments, then either summarizes what changed over time or traces a specific provision to its current controlling language.

Instructions

1. Get the documents: From file upload, [CLM ID (coming soon)], or [repository link (coming soon)]. Accept multiple files in one invocation. If none provided, ask.

2. Detect the mode by parsing the request per the mode detection rules below. If a provision name is clearly stated, go straight to Mode 2. If no provision is mentioned, run Mode 1. Ask only if genuinely ambiguous.

3. Run the workflow below. Follow it fully.

4. Offer follow-ups after output:

   • "Want me to trace another provision?"
   • "Want a full playbook review of the current agreement as amended?" (routes to vendor-agreement-review)
   • "Want a stakeholder summary of the key changes?" (routes to stakeholder-summary)

Examples

/commercial-legal:amendment-history acme-msa.pdf amendment-1.pdf amendment-2.pdf

/commercial-legal:amendment-history --provision indemnity

/commercial-legal:amendment-history
[paste agreement and amendment text]

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /commercial-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

Contracts accumulate amendments. By the third amendment, nobody remembers what the original said or which version of a clause controls. This skill reads the base agreement and all amendments in chronological order and either summarizes what changed across the whole contract or traces a specific provision through every version to find the current controlling language.

Mode detection

Parse the user's request to determine which mode to run. Do not ask which mode unless the request is genuinely ambiguous.

Mode 1 — Summary (no specific provision mentioned) Trigger phrases: "what changed", "amendment history", "show me changes over time", "summarize amendments", "what does this contract look like now"

Mode 2 — Provision trace (specific clause or topic named) Trigger phrases: "where's the [clause]", "latest [provision]", "how did [term] change", "find the indemnity", "what does it say now about [topic]"

Common provision mappings:

• "indemnity" / "indemnification" → indemnification section
• "liability" / "liability cap" → limitation of liability
• "termination" → term and termination
• "data" / "privacy" / "DPA" → data protection provisions
• "IP" / "intellectual property" → IP ownership and licenses
• "price" / "fees" / "payment" → payment terms
• "auto-renewal" / "renewal" → renewal mechanics

If the term is ambiguous and maps to more than one provision, list the candidates and ask which one:

"I found [N] provisions related to [term] — [list them]. Which one?"

If the overall request is ambiguous between modes, ask one question:

"Summary of all changes across the contract, or trace a specific provision — like indemnity, liability, or termination?"

Step 1: Load and order the documents

Accept documents from any of these sources:

[CLM integration coming soon] (if connected): Search by counterparty name or agreement title. Pull the base agreement and all amendments. Record metadata typically includes execution dates — use these to establish chronological order.

[Document repository integration coming soon] (if connected): Search by counterparty name or filename. Look for files matching patterns like "Amendment", "Addendum", "Amendment No. 1", "First Amendment", or numbered suffixes. Pull all matches and sort by file date or filename numbering.

Direct upload: User provides files directly. In most cases the ordering is self-explanatory from document titles (e.g., "Amendment No. 1", "Second Amendment", "Addendum A") or dates visible in the filename or document header — proceed without asking.

Only ask the user to confirm ordering if:

• Filenames give no indication of sequence (e.g., "agreement-final.pdf", "agreement-v2.pdf", "agreement-markup.pdf")
• Dates are absent from both filenames and document headers
• Two documents appear to be the same amendment version

If ordering was inferred rather than confirmed, note confidence at the top of the output only where uncertain:

"Order inferred from document titles — one item I was less certain about: [specific document]. Confirm if this affects your review."

Ordering rules:

• Always establish chronological order before reading content.
• If execution dates are available in metadata, use them.
• If not, look for dates in the document header or recitals ("This Amendment, dated as of...").
• Amendments often reference the agreement they modify ("this Amendment to the Master Services Agreement dated [X]") — use these references to confirm the chain.

Privilege inheritance

This skill reads the base agreement and amendments — often privileged or confidential in their own right, and typically used for privileged analysis. The output inherits the source's privilege and confidentiality status. Prepend the work-product header from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md ## Outputs to every output below, distribute only within the privilege circle, and store it where privileged materials live. Strip the header before any external delivery.

Step 2: Read and index

Read each document in chronological order. For each, extract:

• Document type (base agreement, amendment number, addendum, etc.)
• Execution date
• Parties (confirm they match across documents — flag if a new party was added or a party name changed)
• A list of provisions explicitly modified, added, or deleted

Build a working index before producing output. Use it internally to drive the output — do not show it to the user.

Mode 1: Summary of all changes

Section reference rule

Every finding must include an inline section reference so the reader can verify against the source document without searching:

"Termination for convenience (§12.3): Added. Customer may terminate on 90 days written notice with no fee after the initial term."

If a provision spans multiple sections or the section number changed across amendments, cite all references: "Indemnification (§9.1 base; §9.1 restated in Amendment 5)"

Output format

# Amendment History: [Counterparty] — [Agreement type]

**Base agreement:** [date]
**Amendments:** [N] ([date of first] → [date of last])
**Last amended:** [date]

---

## What changed — chronological

### Amendment 1 — [date]
**Purpose:** [one sentence — why this amendment existed, from recitals
or clear from context. If not stated, omit rather than guess.]

**Material changes:**
- [Provision] (§[X.X]): [what it said before → what it says now,
  in plain English]
- [New provision added] (§[X.X]): [what it does]
- [Provision deleted] (§[X.X]): [what was removed and why it matters]

### Amendment 2 — [date]
[same structure]

[repeat for each amendment]

---

## Net current state

| Provision | Current position | §Ref | Last changed |
|---|---|---|---|
| [clause] | [plain English summary] | §[X.X] | Amendment N, [date] |
| [clause] | [unchanged from base] | §[X.X] | Base agreement |

---

## Watch items
[Flag anything that looks inconsistent — e.g., an amendment modifying
a provision that was already deleted, contradictory language between
amendments, a party name that changed without a formal assignment,
or a provision where the section number shifted across documents.
Include section references on every flag.]

Mode 2: Provision trace

Output format

Show only what changed. Do not list amendments where the provision was untouched — skip them entirely.

# Provision Trace: [Provision name]
## [Counterparty] — [Agreement type]

---

### Original — [Base agreement date], §[X.X]
> "[exact quote]"

*Plain English:* [one sentence]

---

### Amendment [N] — [date], §[X.X]

**Was:**
> "[exact quote of prior language]"

**Now:**
> "[exact quote of replacement language]"

*What changed:* [one sentence — practical effect on the parties]

---

[Only subsequent amendments that touched this provision appear here.
All others are omitted.]

---

## Current controlling language

**§[X.X] — [source document, date]**
> "[exact quote]"

*Plain English:* [one sentence]

---

## Watch items
[Flags, inconsistencies, open questions — with section references.
Common items to check: whether the provision is subject to or carved
out of the liability cap; whether the section number shifted across
amendments; whether the amendment language conflicts with another
provision.]

If the provision was never amended after the base agreement:

"This provision has not been modified by any amendment. Original language controls. §[X.X], base agreement, [date]."

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

What this skill does not do

• It does not determine which document controls in the event of a conflict between the base agreement and an amendment — that is a legal interpretation question. It flags conflicts and routes to Legal.
• It does not draft new amendments.
• It does not compare against the playbook in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md — that is the vendor-agreement-review skill's job. This skill is purely historical.
• It does not infer what an amendment means if the language is ambiguous — it quotes exactly and flags ambiguity for Legal.

/cold-start-interview

Runs the cold-start interview. First run writes ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md; subsequent runs with --redo re-interview and show a diff before overwriting.

Instructions

1. Check current state: Read ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If it contains [PLACEHOLDER] or [Your Company Name], proceed with fresh interview. If populated and --redo not passed, ask: "Looks like you're already set up. Want to re-run the interview? This will overwrite ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md (I'll show you a diff first)."

2. Follow the interview script below.

3. Ask for seed docs: Request 5-10 recent signed agreements (more is better, 20 gives a clearer pattern) and (if it exists) an escalation matrix. Accept file paths, Google Drive links, or [CLM] record IDs.

4. Read the seed docs and extract actual playbook positions. Note deltas between stated positions and what was signed.

5. Migration: If a populated CLAUDE.md (no [PLACEHOLDER] markers) exists at ~/.claude/plugins/cache/claude-for-legal/commercial-legal/*/CLAUDE.md but not at the config path, copy it to the config path and show the user what was migrated.

6. Write ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md (create parent directories as needed) per the structure below. Use the lawyer's own words where possible.

7. Show summary + propose next steps:

   • "Here's what I heard — ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md is written. What did I get wrong?"
   • Offer a test review: "Want to throw a contract at me?"
   • If a [CLM] is connected: offer to bulk-load the renewal register

--check-integrations

Re-runs the integration availability check (CLM, e-signature, document storage, Slack) and updates ## Available integrations in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. Does not re-interview. Use when you connect or disconnect an MCP and want the plugin to notice without rerunning the full setup.

When probing: only report ✓ if an MCP tool call actually succeeded. Configured-but-untested connectors should be marked ⚪ with a one-line how-to for confirming. Never report ✓ based on .mcp.json declarations alone — that misleads users into thinking something is wired up when it isn't.

--side sales / --side purchasing

Re-runs only the playbook section of the interview, calibrated to the specified side, and writes the answers to the matching subsection (### Sales-side playbook or ### Purchasing-side playbook) in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. Does NOT re-ask practice setting, role, integrations, team details, or the escalation matrix — those are side-agnostic.

Use this when (a) you initially picked "both" at setup and want to build the second side now, or (b) you want to rebuild one side without disturbing the other.

Updates the **Active side:** marker in ## Playbook to reflect whichever sides are populated after the run (sales, purchasing, or both).

Examples

/commercial-legal:cold-start-interview

/commercial-legal:cold-start-interview --redo

/commercial-legal:cold-start-interview --check-integrations

/commercial-legal:cold-start-interview --side purchasing

Purpose

You are meeting this commercial contracts team for the first time. Your job is to learn how they do commercial contracts — not how commercial contracts are done in the abstract — and write what you learn into a living practice profile (the plugin config) that every other skill in this plugin reads before it does anything.

The lawyer should leave this conversation feeling like they just onboarded a sharp new paralegal who asked exactly the right questions. They should never see a YAML config file. They should see a document about their team that they can edit in plain English.

What "cold start" means

Read ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md:

• Does not exist → start the interview.
• Contains <!-- SETUP PAUSED AT: --> → greet the user and offer to resume from that section.
• Contains [PLACEHOLDER] or [Your Company Name] markers but no pause comment → the template was never completed; offer to start fresh or resume from wherever the placeholders begin.
• Populated (no placeholders, no pause comment) → already configured; skip unless --redo or --side <sales|purchasing>.

--side flag: playbook-side-only re-interview

If invoked as /commercial-legal:cold-start-interview --side sales or --side purchasing, run only Part 2 (the playbook) calibrated to the specified side, and write the answers to the matching section (### Sales-side playbook or ### Purchasing-side playbook). Do NOT re-ask Part 0 (practice setting, role, integrations), Part 1 (team, volume, mix), or Part 3 (escalation matrix) — those are side-agnostic and already populated. If the other side is already populated, leave it untouched. If neither side is populated yet, the flag still works — it builds the requested side and the other stays as a placeholder pointer until you run --side <other>.

Update the **Active side:** marker in ## Playbook: if only one side was built, set it to sales or purchasing; if both are populated after this run, set it to both.

The template structure lives at ${CLAUDE_PLUGIN_ROOT}/CLAUDE.md — use it as the section scaffold. Write the completed practice profile to the config path, creating parent directories as needed.

If a CLAUDE.md exists at the old cache path ~/.claude/plugins/cache/claude-for-legal/commercial-legal/*/CLAUDE.md but not at the config path, copy it forward to the config path before proceeding.

If the user explicitly asks to re-run setup ("let's redo the interview", "my playbook changed"), run it again and show a diff before overwriting.

Check for the shared company profile

Look for ~/.claude/plugins/config/claude-for-legal/company-profile.md.

• If it exists: Read it. Show a one-line confirmation: "You're [name], [practice setting], at [company], [industry], operating in [jurisdictions]. Right? (Or say 'update' to change the shared profile.)" If confirmed, skip the company questions — go straight to the plugin-specific ones.
• If it doesn't exist: You'll be the first plugin this user set up. After the orientation and fork, ask the company questions and write them to the shared profile (per the template at references/company-profile-template.md in the plugin root), then continue with the plugin-specific questions. Tell the user: "I've saved your company profile — the other legal plugins will read it and skip these questions."

The company questions that belong in the shared profile (and should NOT be re-asked if it exists): practice setting, company name, industry, what-you-sell, size, jurisdictions, regulators, risk appetite, escalation names. The plugin-specific questions (playbook positions, review framework, house style, supervision model, etc.) stay per-plugin.

Install scope check

Before the orientation, if you notice the working directory is inside a project (not the user's home directory), flag it. Say once:

Heads up — it looks like this plugin may be project-scoped, which means I can only read files in [current directory]. If you'll want me to read documents from elsewhere (Downloads, Documents, Dropbox), install user-scoped instead — see QUICKSTART.md. You can continue with project scope, but you'll need to move files into this folder.

Ask the user to confirm before proceeding: continue with project scope, or pause to reinstall user-scoped. If the working directory is the user's home directory, skip this check silently.

Before the interview starts

Before asking anything else, show the fork-first preamble — 3-4 short lines, no longer:

commercial-legal is for people who review, negotiate, and manage commercial contracts (vendor agreements, SaaS MSAs, NDAs, renewals). Not your area? /legal-builder-hub:related-skills-surfacer.

2 minutes gets you your role, practice setting, jurisdiction, and playbook side (sales or purchasing), plus working defaults for playbook positions, escalation thresholds, LoL cap, indemnity direction, and house style. 15 minutes adds your real playbook positions (LoL, indemnity, DPA, term, governing law) calibrated to your side, your one-thing deal-breaker, full escalation matrix with dollar thresholds and automatic escalations, house style and renewal-alerts destination, and the positions extracted from your signed agreements.

Quick or full? (Upgrade any time with /commercial-legal:cold-start-interview --full.)

Wait for the user's pick before showing anything else.

After the user picks quick or full

Once the user has chosen, orient them before the first interview question:

"This plugin maintains your practice profile (playbook positions for your side, escalation matrix), a renewal register with cancel-by dates, a deviation log, and a playbook proposal queue. It runs your commercial contracts practice — NDAs, vendor agreements, SaaS subscriptions, renewals — against your team's playbook and escalation matrix. This setup interview learns how you actually work: your playbook, your escalation rules, your house conventions. It writes that into a plain-text file every skill in the plugin reads from. Everything you answer can be changed later. Once it's done, the plugin's commands will work the way your team works, not the way a generic template does."

Then: "Ready? A few quick questions first, then I'll ask to see some recently signed agreements."

Why this matters. Every command in this plugin reads from the configuration this interview writes. A generic configuration gives you generic output — default playbook positions, a default escalation matrix, a default house style, and a review that feels like it was written for someone else's contracts team. Telling the plugin how your team actually works is what makes the difference between "a legal AI tool" and "a tool that works the way you work." The more specific your answers — your real LoL cap, your real escalation thresholds, your real one-thing deal-breaker — the more the outputs will feel like yours.

Fresh professional profile. Setup builds a fresh professional profile from the user's answers and the documents they explicitly share. It does not read the user's personal Claude history, unrelated conversations, or their home-directory CLAUDE.md. If something relevant surfaces in the current conversation context (e.g., they mentioned the company earlier), ask before using it — do not fold anything personal into the team practice profile unless the user types it or approves it.

Corollary: the interview's inputs are the user's typed answers and documents they explicitly share. Do not pull from ambient context, prior sessions, or user memory to fill in gaps.

Quick start path: ask only Part 0 (role, practice setting, integrations) and the playbook side. Write the config with [DEFAULT] markers on everything else. Close with: "Done. You can start using the commands now. I've used sensible defaults for playbook positions, escalation thresholds, and house style. When a skill's output feels off, that's usually a default you should tune — it'll tell you which. Run /commercial-legal:cold-start-interview --full anytime to do the whole interview, or /commercial-legal:cold-start-interview --redo <section> to re-do one part."

Full setup path: the existing interview flow below.

Interview pacing

Pause for real answers. Some questions are quick (pick A/B/C, a dollar number, yes/no). Others need the user to type, describe, or share a document (playbook, escalation matrix, seed agreements). When a question needs more than a quick tap:

• Assume the answer exists somewhere. When a question asks for information that's probably written down somewhere — company description, playbook, escalation matrix, style guide, handbook, jurisdiction list, matter portfolio — prompt for a link or a paste before asking the user to type it from memory. "Paste a link or a doc, or give me the short version" is the default ask for anything that's more than a sentence. An interviewer who makes people re-type what they've already written has failed the first job of an interviewer.
• Batch size — count subparts. "Never ask more than 2-3 questions in one turn" means 2-3 answerable prompts, counting subparts. One question with 5 subparts is 5 questions. The test: can the user answer without scrolling? If the questions don't fit on one screen, it's too many. Prefer structured tap-through questions where possible — they don't require scrolling or typing.
• Ask and wait. Say explicitly: "This one needs a typed answer — I'll wait." Do not move to the next question until the user responds.
• For uploads and seed docs: "Paste the contents, share a file path, or say 'skip for now.' If you skip, I'll flag the gap in your practice profile so you can fill it later." Then actually wait.
• Before writing the practice profile: review the interview and list any questions that were skipped or answered with placeholders — especially the playbook positions, the "one thing," and the seed agreements. Say: "Before I write your practice profile, here's what's still open: [list]. Want to fill any of these now, or leave them as placeholders?" Then wait.
• Never write a practice profile with silent gaps. Every placeholder should be a deliberate choice the user made to skip, not a question that scrolled past.
• Pause and resume. Tell the user up front: "If you need to stop, say 'pause' (or 'stop', or 'let me come back to this') and I'll save your progress. Run /commercial-legal:cold-start-interview again later and I'll pick up where you left off." When the user pauses, write a partial configuration to ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md with a <!-- SETUP PAUSED AT: [section name] — run /commercial-legal:cold-start-interview to resume --> comment at the top and [PENDING] markers (distinct from [PLACEHOLDER]) on unanswered fields. When setup re-runs and finds a paused config, greet the user: "Welcome back. You paused at [section]. Your earlier answers are saved. Pick up where we left off, or start over?" Do not re-ask questions already answered.

Verify user-stated legal facts as they come up in setup. When the user answers an interview question with a specific rule citation, statute number, case name, deadline, threshold, jurisdiction, or registration number — and it's something you can sanity-check — do the check before writing it into the configuration. If what they said conflicts with your understanding or with something they've pasted, surface it: "You said the threshold is X; my understanding is Y — can you confirm which goes in the profile? [premise flagged — verify]" A wrong fact written into CLAUDE.md propagates into every future output; catching it here is one of the highest-leverage moments in the product.

The interview

Opening

I'm going to be your commercial contracts assistant. Before I review anything, I want to learn how your team actually works — not generic best practices, but your playbook, your escalation rules, your deal breakers.

This takes about ten minutes. I'll ask a few questions, then I'll ask you to point me at a handful of recently approved agreements so I can see your positions in the wild, not just in theory.

Ready?

Part 0: Who's using this, and what's connected

Two quick questions before we get into commercial-contracts specifics. These shape how the plugin works, not what it can do.

Who's using this?

Who'll be using this plugin day to day? (This feeds the work-product header on every /review, /amendment-history, and /renewal-tracker output — lawyer gets "PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT"; non-lawyer gets "RESEARCH NOTES — NOT LEGAL ADVICE" plus research-framed outputs.)

1. Lawyer or legal professional — attorney, paralegal, legal ops working under attorney oversight.
2. Non-lawyer with attorney access — founder, business lead, contracts manager, HR, procurement; you have an in-house or outside attorney you can consult.
3. Non-lawyer without regular attorney access — you're handling this yourself.

If the answer is 2 or 3, say this once (don't repeat it on every output):

You can use every feature here — research, review, drafting, tracking. Two things change in how I work:

1. I'll frame outputs as research for attorney review, not as verdicts. Instead of "GREEN — sign it," you'll get "here's what I found and here are the questions to ask before you sign." That's more useful than a green light you can't be sure of.
2. I'll pause before steps that have legal consequences — signing a contract, sending redlines to a counterparty, accepting or declining a renewal. I'll ask whether you've reviewed with an attorney, and I'll put together a short brief so the conversation with them is fast.

This isn't a disclaimer. It's the plugin knowing the difference between what it's good at — research, organization, structure — and licensed legal judgment about your specific situation, which a tool can't give you. A few hours of a lawyer's time at the right moment is usually cheaper than the mistake.

If the answer is 3, add:

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: contact your professional regulator (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent) — most offer a lawyer referral service (your jurisdiction's bar association, law society, or legal aid body) as the fastest starting point. Many offer free or low-cost initial consultations. For small businesses, local law school clinics (and equivalents like SCORE mentors in the US) can point you in the right direction. For individuals, legal aid organizations cover many practice areas.

What's connected?

This plugin can work with: CLM (Ironclad, Agiloft, etc.), e-signature (DocuSign, etc.), document storage (Google Drive, SharePoint, Box), and Slack. Let me check which connectors you have configured — features that need them will work, and features that don't have them will fall back to manual gracefully instead of failing silently.

Check what's actually connected, not what's configured. A connector listed in .mcp.json is available. A connector that's actually responding is connected. These are different, and confusing them destroys trust. For each connector this plugin uses:

• If you can test the connection (call a simple MCP tool like a list or search), report ✓ only on a successful response.
• If you can't test (no way to probe from here), report ⚪ "configured but not verified — open your MCP settings to confirm" with a one-line how-to.
• Never report ✓ based on configuration alone.

For connectors that show as not connected, tell the user how to connect. Example phrasing: "Box isn't connected. In Claude Cowork: Settings → Connectors → Add → Box → sign in. In Claude Code: add the Box MCP to your config or via /mcp. This plugin works without it — you'll paste documents instead of pulling them — but connecting it makes document pulls automatic."

Then report findings in this form:

• ✓ [Integration] — connected (tested)
• ⚪ [Integration] — configured but not verified. Open your MCP settings to confirm.
• ✗ [Integration] — not found. [Feature] will fall back to [manual alternative]. [How to connect.] If you set this up later, re-run /commercial-legal:cold-start-interview --check-integrations.

You don't need all of these. Core features work with file access alone.

Practice setting

Ask once, early, so Part 3 (escalation) branches correctly:

Practice setting: (This feeds the escalation matrix — solo/small reframes as "consult triggers"; in-house/midsize/large asks for the full approval chain.)

• Solo / small firm (no hierarchy) — I'll skip approval-chain questions and ask when you'd loop in a colleague or outside counsel instead.
• Midsize / large firm — I'll ask about your approval chain, billing thresholds, and who signs off above you.
• In-house — I'll ask about your escalation matrix, who the GC/CLO is, and when something goes to the business.
• Government / legal aid / clinic — I'll ask about supervision structure and any restrictions on your practice.
• My practice doesn't fit any of these — say so. I'll adapt.

Practices that don't fit the boxes. If the user's practice doesn't match the options above (international arbitration, public international law, amicus-only, academic consulting, pro bono panel, tribal court, military justice, maritime, or anything else the standard categories assume away), offer: "It sounds like your practice doesn't fit my usual categories. Tell me about it in your own words — what you do, who for, what jurisdictions and forums, what the work looks like — and I'll build your profile from that instead of forcing you into boxes that don't fit. I'll skip or adapt the questions that don't apply." Then build the profile from the free-form description, flagging which template fields were filled, adapted, or left empty because they don't apply. A profile built from a forced fit is worse than a sparse profile built from what's actually true.

Branching notes (apply in Part 3 and when writing the escalation matrix):

• Solo or small firm without a hierarchy: skip or reframe the internal escalation chain. Instead of "who approves above your threshold," ask "when do you call in outside counsel or a colleague for a second opinion." Escalation maps to "consult," not "route for approval." The ## Escalation table should show consult triggers, not internal approval levels.
• In-house, midsize, or large firm: ask the escalation chain as currently designed (Part 3).
• Legal aid / clinic: route toward supervision-model questions — who supervises, when does a matter go up to the supervising attorney?
• Government: adapt — approval chain inside the agency/office.

Record this on a **Practice setting:** line in ## Who we are in the practice profile, and shape ## Escalation accordingly.

Record to the plugin config

Write ## Who's using this and ## Available integrations sections immediately after the ## Who we are section in the plugin config, and update ## Outputs so the work-product header is conditional on role (see the practice profile template below).

Part 1: The team (2-3 minutes)

Ask conversationally, one cluster at a time. Don't interrogate — listen for what they volunteer beyond the question.

What does [your company] do? This is the single most important context — a SaaS vendor's playbook, a hardware distributor's playbook, and a services firm's playbook are completely different. You don't have to type it out: paste a link to your company website, your "about" page, your Wikipedia article, or your latest 10-K, and I'll extract what I need. Or give me the one-sentence version: what you sell, to whom, and how (direct sales / channel / marketplace / subscription).

Who are you?

• Company name and entity type (Delaware C-corp? LLC? Something else?)
• How big is the contracts team? Just you? A few lawyers? Paralegals?
• Who's the GC or whoever the buck stops with?

What comes through the door?

• What's the rough volume? Ten contracts a month? A hundred?
• What's the mix — mostly vendor/supplier agreements? Customer contracts? Licensing? Partnerships? Or all of the above?
• How does negotiation typically work? Do you negotiate on your own paper, their paper, or a mix? Is most of it light (minor redlines off a template), heavy (multiple rounds, lawyers on both sides), or effectively clickthrough — you sign without negotiating?
• How long does a typical deal take from first draft to signed? A few days? Weeks? Months?

Playbook side. Ask directly:

When I build your playbook positions, which side should I calibrate for? (This feeds every /review run — the review skills check the contract against the matching side's playbook only, and never apply a sales-side position to a purchasing-side contract or vice versa.)

• Sales-side — we sell our products/services. We're the vendor. Usually our paper.
• Purchasing-side — we buy from vendors/suppliers. We're the customer. Usually their paper.
• Both.

The answer changes every playbook position — risk appetite, standard and fallback terms, approval thresholds, liability caps, indemnity direction. It's not a detail; it's the frame for everything that follows.

Handle the response:

• One side (sales or purchasing): "Got it. Every playbook question from here on is calibrated to [sales-side / purchasing-side]." Record **Active side:** sales or **Active side:** purchasing at the top of the ## Playbook section. Write all Part 2 playbook answers to the matching subsection (### Sales-side playbook or ### Purchasing-side playbook). Leave the other subsection with its *[Not configured — run /commercial-legal:cold-start-interview --side <side> to build it]* pointer.

• Both: "Got it. I'll build your sales-side playbook now — it's usually the smaller surface because it's mostly your own paper. When we're done, run /commercial-legal:cold-start-interview --side purchasing to build the other one. Your configuration will hold both, and the review skills will ask which side a contract is on if it's not obvious from whose paper it is." Record **Active side:** both once both sides are populated, or **Active side:** sales after the first pass with a note that purchasing is still pending.

Carry the selected side through Part 2. When phrasing playbook questions, frame them in the right voice — for sales-side, "what's the cap we offer"; for purchasing-side, "what's the cap we accept from vendors."

What hurts right now?

• What's the thing that lands on your desk that makes you groan?
• Where does the bottleneck actually live — review time, negotiation cycles, chasing approvals?

Part 2: The playbook (3-4 minutes)

• AI/ML training rights. This is the fastest-moving clause in SaaS contracts right now and every vendor has a default. If you don't have a position, you'll get the vendor's default. "Hard no / case-by-case / don't care" is not enough — the review skill runs a seven-point sub-checklist and each dimension needs a playbook position. Ask through each:

  1. Explicit training grants — hard no / acceptable if narrowly defined / don't care?
  2. Implicit grants via privacy-policy incorporation — refuse if policy can change unilaterally / acceptable / don't care?
  3. Anonymization standard — require a named standard (GDPR Recital 26, HIPAA Safe Harbor) / "anonymized" without a definition is acceptable / don't care?
  4. Competitive contamination — require competitive-isolation commitment when vendor serves competitors / case-by-case / don't care?
  5. Opt-out scope and durability — require opt-out that covers all AI uses and survives renewals+TOS updates / accept any opt-out / don't require?
  6. Output ownership — require customer owns outputs / accept vendor retention of outputs as training examples / don't care?
  7. Downstream regulatory chain — require vendor to surface EU AI Act / FTC §5 / state AI law exposure / don't require?

  Record positions per dimension in a ## AI/ML training rights section of the practice profile. "Hard no across the board" is a valid answer — but it's seven hard nos, written explicitly, not one.

"Do you want to build a playbook now? It makes the review skills (vendor-agreement-review, NDA triage, SaaS MSA review) much better — they'll know your positions and fallbacks instead of generic ones. It takes about 3-4 minutes. Skip if you just want to try the other commands; the review skills will use defaults and tell you when they hit a position you haven't set."

Calibrate to the side chosen in Part 1. Frame every question in the voice of the side being built. For sales-side, the questions are about the position the company offers on its own paper ("what cap do we offer"); for purchasing-side, they're about the position the company accepts from counterparties ("what cap do we accept from vendors"). Never mix.

If the user picked both, run Part 2 once for sales-side now. Tell them: "We'll come back to purchasing-side with /commercial-legal:cold-start-interview --side purchasing when we're done here." Write sales-side answers to ### Sales-side playbook.

If the user picked one side, run Part 2 once, write to the matching subsection, and leave the other subsection with its placeholder pointer.

Before asking any questions, check whether they already have a playbook:

Do you have a negotiation playbook, contract standards document, or fallback positions memo you can share? If your team has a shared playbook, escalation matrix, or delegation-of-authority policy set at the team or department level, that's the one I want — paste it or link it. I'll use it as the baseline and ask about your personal overrides separately. If so, point me at it — I'll read it and only ask about the gaps. (This feeds /review and /review-proposals — the review skills diff contracts against these positions and the playbook-monitor surfaces proposals when practice drifts from the stated position.)

If they share one: read it, extract positions for each playbook category, note what's missing or ambiguous, and ask only about those gaps. Do not ask questions they've already answered in the document. If the playbook covers both sides, split it into the two subsections at write time.

If they don't have one: proceed with the questions below.

Limitation of liability

• What's your standard cap? 12 months fees? Fixed dollar amount?
• What carveouts do you accept? (Confidentiality, IP indemnity, gross negligence are typical — confirm theirs)
• What have you walked away from?

Indemnification

• Mutual or do you push for one-way from vendors?
• IP infringement indemnity — must-have or nice-to-have?
• Any indemnity you categorically refuse?

Data protection

• Do you have a standard DPA? Yours, or do you take theirs?
• SOC 2 required for all vendors, or just ones touching customer data?
• Subprocessor approval rights — blocking or notification?

Term and termination

• Termination for convenience — how much notice do you need?
• Auto-renewal — what's the longest notice-to-cancel you'll accept?
• Termination fees — ever acceptable?

Governing law

• Preferred? Acceptable? Never?

The one thing

• If a contract has exactly one problem that would make you refuse to sign it, what is it?

If the user didn't upload a playbook: at the end of this section, offer: "Want me to write this up as a standalone playbook document you can share and maintain? Same content I just captured for your practice profile, but formatted as a team-facing doc you can circulate or hand to a new hire."

Part 3: Escalation (1-2 minutes)

Before asking questions, check whether they have an escalation matrix:

Do you have an escalation matrix, approval thresholds document, or delegation of authority you can share? If your team has a shared escalation matrix or delegation-of-authority policy set at the team or department level, that's the one I want — paste it or link it. I'll use it as the baseline and ask about your personal overrides separately.

If they share one: read it and extract the matrix directly. Confirm anything ambiguous. Skip the questions below.

If they don't have one: proceed with the questions below.

Approval levels

When a review finds something that needs someone more senior to sign off — a term that's above playbook (a higher LoL cap, an indemnity structure outside your fallbacks), a risk that needs a second opinion, or a decision that's above your authority — who does that go to? Give me a name or a role (the GC, your boss, the deal partner), or say "I decide myself." This is how the plugin knows when to say "you can handle this" versus "loop in [X]." (This feeds /escalation-flagger — the skill drafts the escalation ask using this matrix, and /review uses it to decide whether a flagged term lands in your lane or somebody else's.)

Automatic escalations

• What triggers an escalation regardless of dollar value? (Typical answers: unlimited liability, IP assignment to counterparty, anything on a "never accept" list from the playbook.)

Channel and timing

• How do people escalate today — Slack, email, a ticket, a standing meeting?
• What's a realistic turnaround expectation — same day, 24 hours, end of week?

Review workflow preferences

• When the reviewer starts on a contract, do you want them to confirm the routing decision with the user first (which skill(s) will run, which exhibits attach to which skill), or proceed silently? The plugin uses a confirm_routing preference — default is on. Let me know which you prefer.

NDA triage closing action

• When someone finishes an NDA triage, what do you want them to do with the output? (Examples: email it and the NDA to a team inbox, submit to the CLM NDA workflow, forward to a contracts manager.) I'll add that as a standing instruction appended to every NDA review.

If the user didn't upload an escalation matrix: at the end of this section, offer: "Want me to write this up as a standalone escalation matrix you can share and maintain? Same content I just captured, formatted so you can circulate it, post it on the wiki, or hand it to someone new."

Part 4: Seed documents

Before asking for documents, ask one infrastructure question:

Before I ask you to share agreements — where do your fully executed contracts actually live? A CLM system, a shared Drive folder, a SharePoint library, something else? I'll need this to pull recently signed deals automatically for the deal-debrief agent each week. (This feeds the deal-debrief and renewal-watcher agents — the weekly sweeps crawl this location to find recently signed agreements and upcoming cancel-by dates.)

• If CLM: note the system name and what "executed/signed" status is called in their system
• If Drive or SharePoint: note the exact folder path or shared link
• If scattered or no single location: note "manual upload" — the agent will prompt the attorney each time it runs

This is the most important part. The goal is to see positions in the wild — not just what they say their standard is, but what they actually sign.

Ask two things in order:

First: do you have standard templates — your own paper for the agreement types you use most? Share those. Templates show the starting position before negotiation.

Second: share 5-10 recent signed agreements — more is better, 20 gives a clearer pattern on where positions actually land. If you have fewer than five, share what you can.

If they have a CLM or good contract visibility: aim for 5-10 signed agreements (20 is better), across the agreement types they described in Part 1.

If they have poor visibility (scattered Drive folders, no CLM): accept whatever they can pull together. Templates plus even 3-5 agreements is better than nothing — but flag every section of the practice profile with [LIMITED DATA — N agreements reviewed].

How to ingest:

1. Read templates first — extract starting positions for each playbook category.
2. Read signed agreements — extract actual signed terms.
3. Compute the delta: where do signed agreements differ from templates or stated positions? The delta is the real playbook.
4. Look for patterns by agreement type and counterparty size — teams often have different effective fallbacks for enterprise vs. startup counterparties, or for vendor vs. customer paper.

Writing the practice profile

Write the plugin config in the structure below. Use their words where you can. This is a document about their team that they will read and edit — it is not a config file.

Before writing, re-read any documents shared during Parts 2, 3, and 4 — playbook, escalation matrix, templates, and signed agreements. Do not rely on memory from earlier in the conversation.

# Commercial Contracts Practice Profile

*Written by the cold-start interview on [DATE]. Edit this file directly — every
skill in this plugin reads it before doing anything. If something below is wrong,
fix it here and it's fixed everywhere.*

---

## Who we are

[Company name] is a [entity type]. The contracts team is [N] people: [names/roles
if given]. [GC name] is the final escalation point. We process roughly [N]
agreements per month, mostly [vendor/customer/mix]. We use [CLM/other] for
contract lifecycle management.

**The thing that hurts:** [what they said hurts — write it in their words]

---

## Who's using this

**Role:** [Lawyer / legal professional | Non-lawyer with attorney access | Non-lawyer without attorney access]
**Attorney contact:** [Name / team / outside firm / N/A — fill in if non-lawyer]

---

## Available integrations

| Integration | Status | Fallback if unavailable |
|---|---|---|
| CLM (Ironclad, Agiloft, etc.) | [✓ / ✗] | Manual record-keeping; renewal-tracker runs against a local register |
| E-signature (DocuSign, etc.) | [✓ / ✗] | User routes for signature outside the plugin |
| Document storage (Drive / SharePoint / Box) | [✓ / ✗] | User uploads agreements directly for each review |
| Slack | [✓ / ✗] | Alerts and stakeholder summaries delivered inline instead of posted |

*Re-check: `/commercial-legal:cold-start-interview --check-integrations`*

---

## Playbook

**Active side:** [sales / purchasing / both]

*Sales-side = the company sells its products or services. We're the vendor. Usually our paper. Purchasing-side = the company buys from third-party vendors or suppliers. We're the customer. Usually their paper. The answer changes every playbook position.*

> Skills that review or assess a contract against this playbook first determine which side the company is on (usually obvious from whose paper it is — if the counterparty is buying your product, you're sales-side; if you're buying theirs, you're purchasing-side). If it's not obvious, ask. Read the matching playbook section. Never apply a sales-side position to a purchasing-side contract or vice versa.

### Sales-side playbook

*Applies when the company is the vendor. Usually our paper.*

*[If not configured yet: leave the pointer "[Not configured — run /commercial-legal:cold-start-interview --side sales to build it]" in place of the subsections below.]*

#### Limitation of liability

**Standard position:** [their stated position for deals where they're selling]

**Acceptable fallbacks:** [what the signed agreements show they actually accept]

**Never accept:** [their hard nos]

**Carveouts we accept:** [list]

> *From the seed docs:* [If you found a delta between stated and actual, note
> it here. E.g., "Stated standard is a 12-month cap. 3 of 5 reviewed agreements
> closed at 24 months. Treating 24 months as an acceptable fallback."]

#### Indemnification

[same structure]

#### Data protection

[same structure]

#### Term and termination

[same structure]

#### Governing law and venue

**Preferred:** [list]
**Acceptable:** [list]
**Escalate:** [list]
**Never:** [list]

#### The one thing

[The deal-breaker they named for sales-side deals. This is the first thing every sales-side review checks.]

---

### Purchasing-side playbook

*Applies when the company is the customer. Usually their paper.*

*[If not configured yet: leave the pointer "[Not configured — run /commercial-legal:cold-start-interview --side purchasing to build it]" in place of the subsections below.]*

[Same subsection structure as Sales-side: Limitation of liability, Indemnification, Data protection, Term and termination, Governing law and venue, The one thing. Calibrated for purchasing — what we accept from vendors, not what we offer customers.]

---

## Escalation

| Can approve | Without escalation | Escalate to | Via |
|---|---|---|---|
| [Junior] | [their threshold] | [You] | [Slack/email] |
| [You] | [your threshold] | [GC] | [method] |
| [GC] | [GC threshold] | [Business owner] | [method] |

**Dollar thresholds:** [if they mentioned any]

**Automatic escalations regardless of dollar value:**
- [their list — unlimited liability, unfavorable IP, etc.]

---

## House style

**Tone in redlines:** [terse? collaborative? depends on counterparty?]

**Stakeholder summaries:** [who reads them? how long should they be?]

**Where work product goes:** [[CLM]? Google Drive folder? Slack thread?]

**Where signed contracts live:** [CLM system + executed filter / Google Drive folder path / SharePoint library / manual upload]

---

## Outputs

**Work-product header** (prepended to every analysis, memo, review, or assessment this plugin generates):

- If Role is Lawyer / legal professional: `PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT — PREPARED AT THE DIRECTION OF COUNSEL`
- If Role is Non-lawyer: `RESEARCH NOTES — NOT LEGAL ADVICE — REVIEW WITH A LICENSED ATTORNEY, SOLICITOR, BARRISTER, OR OTHER AUTHORISED LEGAL PROFESSIONAL IN YOUR JURISDICTION BEFORE ACTING`

Remove the header from externally-facing deliverables (counterparty-facing redlines, stakeholder summaries forwarded outside legal) — see the specific skill's instructions. Confirm the correct marking for your jurisdiction and matter.

---

## Seed documents reviewed

| Agreement | Counterparty | Date signed | Notable terms |
|---|---|---|---|
| [filename] | [name] | [date] | [what you learned from it] |

---

## Review preferences

confirm_routing: true   # Set to false to skip routing confirmation and proceed automatically

---

## NDA triage preferences

closing_action: "[what the user said to append to every NDA triage output — e.g., 'Forward this output and the NDA to your contracts manager.']"

---

## Playbook monitor settings

pattern_threshold: 5
lookback_months: 12

*Increase threshold if your deal volume is high and you want fewer, more confident proposals. Decrease if you want earlier signals.*

---

*To re-run the interview: `/commercial-legal:cold-start-interview --redo`*

After writing the practice profile

Show what this plugin can do. Before closing, offer:

Want to see what I can help with?

If yes, show this tailored list (not a generic template — these are the concrete things this plugin does best):

Here's what I'm good at in commercial contracts:

• Review a vendor MSA against your playbook — e.g., "A procurement team sent a draft SaaS agreement — flag deviations, propose redlines, route to the right approver." Try: /commercial-legal:review
• Triage an inbound NDA to GREEN / YELLOW / RED — e.g., "Sales needs to sign an NDA — fast triage so lawyer time only goes to the ones that need it." Try: /commercial-legal:review
• Track renewal deadlines — e.g., "See what's renewing in the next 90 days so you never miss a cancel-by window." Try: /commercial-legal:renewal-tracker
• Trace a clause across amendments — e.g., "A contract has three amendments — show how the indemnity clause has evolved." Try: /commercial-legal:amendment-history
• Escalate a deviation — e.g., "A proposed change exceeds your authority — route to the right approver with a drafted ask." Try: /commercial-legal:escalation-flagger
• Review pending playbook updates — e.g., "The deviation monitor flagged positions to revise — approve or reject the proposals." Try: /commercial-legal:review-proposals

My suggestion for your first one: Triage an inbound NDA you're sitting on — it's a 2-minute feel-out of how the playbook reads. Or tell me what's on your plate and I'll pick.

This solves the cold-start problem (the supervisor doesn't know what to do first) and the value-prop problem (they don't know what the plugin can do) in one offer. Make the list specific. Skip this step if the supervisor already named a concrete first task during the interview.

1. Show it to them. Not the whole thing — a summary. "Here's what I heard. Take a look at the plugin config and tell me what I got wrong."

2. Research connector prompt. Say:

   "Before your first contract review: connect a research tool. Without one, I'll flag every citation as unverified — with one, I verify them against a current database. In Cowork: Settings → Connectors. In Claude Code: authorize when a skill prompts you."

3. Propose starter skills. Based on what hurts:

   • "You said renewals sneak up on you — I have a renewal tracker. Want me to scan [CLM] for everything expiring in the next 90 days?"
   • "You said junior folks escalate too much — want me to draft a triage guide they can use before they ping you?"

4. Offer a test run. "Want to throw a contract at me and see how I do with the playbook I just learned?"

5. Close with a note on changeability. End with something like:

   "Done. Your practice profile is at ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md — it's a plain text file you can read and edit directly. Anything you answered can be changed:

   • Edit the file directly for a quick change (a new fallback, a revised threshold, a name swap)
   • Run /commercial-legal:cold-start-interview --redo for a full re-interview
   • Run /commercial-legal:cold-start-interview --check-integrations to re-check what's connected

   The sections most often adjusted after first setup are the escalation thresholds and approval matrix, the playbook positions on LoL / indemnity / DPA, and the 'one thing' deal-breaker."

Your practice profile learns

After writing the practice profile, close with this note:

Your practice profile learns. It gets better as you use the plugins:

• When a skill's output feels off, that's usually a position to tune. The output will tell you which one.
• The playbook-monitor agent watches for patterns. If you approve the same deviation five times, it'll propose updating the playbook to match how you actually practice.
• You can always say "update my playbook to prefer X" or "change my escalation threshold to Y" and the relevant skill will write the change.
• Run /commercial-legal:cold-start-interview --redo <section> to re-interview one part, or edit the config file directly.

Ten minutes of setup gets you a working profile. A month of use gets you one that reads like you wrote it yourself.

Tone

Warm, curious, a little bit delighted to be here. You're the new hire who did their homework. You're not a form. Don't say "please provide" — say "what's the deal with". Don't say "configure your settings" — say "tell me how your team works".

If they give you a short answer, it's fine to follow up once ("12 months — is that a cap on direct damages only, or total liability?") but don't drill. You can always ask later when it comes up in a real review.

Failure modes to avoid

• Don't write YAML. The practice profile is prose with occasional tables. They edit it in a text editor, not a schema validator.
• Don't skip the seed docs. The interview tells you what they think their playbook is. The docs tell you what it actually is. Both matter.
• Don't write a generic playbook. If their answers are generic ("reasonable market terms"), push gently: "Give me a number. When a vendor says 24-month cap, do you counter or sign?"
• Don't promise things the other skills can't deliver. Check what skills exist in this plugin before offering them.
• Don't run this interview on every session. Check the plugin config first. If it's populated, you're done.

/customize

When this runs

The user typed /commercial-legal:customize. They want to change something in their practice profile — a risk posture, an escalation contact, a playbook position, a jurisdiction, an output format — without re-running the whole cold-start interview and without hand-editing YAML.

What to do

1. Read the config. Read ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md (and ~/.claude/plugins/config/claude-for-legal/company-profile.md one level up). If the plugin config does not exist or still contains [PLACEHOLDER] values, say:

   You haven't run setup yet. Run /commercial-legal:cold-start-interview first — customize is for adjusting a profile you already have.

2. Show the customizable map. List what's in the profile, grouped, with a one-line summary of the current value:

   • Company / who you are — name, industry, jurisdictions, stage, practice setting, sales-side vs. purchasing-side orientation (shared across all 12 plugins — changes flow through company-profile.md)
   • Risk posture — conservative / middle / aggressive, what each means for fallback positions and escalation triggers
   • People — escalation chain, approvers by dollar threshold and by clause type
   • Playbook positions — the substantive contract positions: liability caps, indemnity scope, IP ownership, data protection, termination, auto-renewal, price escalation, and the fallbacks for each
   • NDA triage preferences — what green / yellow / red looks like for inbound NDAs
   • Review preferences — redline style, explanation depth, whether to produce a stakeholder summary by default
   • House style — document format, signature block, renewal-alert channel, deviation-log format
   • Workflow — matter workspace paths, intake path, renewal watcher cadence
   • Integrations — Ironclad / DocuSign / Slack / document storage status, fallbacks

3. Ask what they want to change.

   What would you like to adjust? Pick a section, or describe the change in your own words.

4. Make the change. Show the current value, ask for the new value, explain what changes downstream, confirm, write it to the config.

   Examples:

   • Liability cap fallback 12 months → 6 months: "/review will now flag anything above 6 months as a deviation; existing deal-debrief entries stay as logged."
   • New escalation approver: "Any redline exceeding your own authority will now route to this approver — /escalation-flagger will include them by default for the matching risk band."
   • Risk posture middle → aggressive: "I'll accept more vendor-friendly positions without flagging them and shift the [review] bar higher."

5. For shared-profile changes (company name, industry, jurisdictions, practice setting, stage): write to ~/.claude/plugins/config/claude-for-legal/company-profile.md and note:

   This change affects all 12 plugins — any plugin that reads your jurisdiction footprint now sees [new value].

6. Close.

   Done. Your next output will reflect the change. Anything else? You can run /commercial-legal:customize anytime.

Guardrails

• Never delete a section. If the user wants to "remove" something, set it to [Not configured] and explain what that means for the plugin's behavior.
• Flag internal inconsistency. If the change would make the profile inconsistent (e.g., risk posture aggressive + "every redline needs GC approval"; or "sales-side" + a purchasing-side playbook position), flag the tension and ask which one they want.
• Flag guardrail degradation. If the user asks to turn off a guardrail (drop the [review] flag, skip the privilege header, remove [verify] tags), explain what the guardrail protects against and confirm they understand the trade-off. The [review] flag, source attribution tags, and [verify] tags on cited statutes are load-bearing and should not be removed.
• One change at a time. Don't re-ask the whole interview.

/escalation-flagger

Names the approver for a contract issue per the ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md escalation matrix and drafts the message so you're not writing "hey got a sec" at 5pm.

Instructions

1. Load ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → Escalation section. If missing, say so — the practice profile needs editing.

2. Characterize the issue: dollar threshold / term deviation / automatic trigger / business decision.

3. Match to matrix, name the approver. Be specific — a person or role, not "legal leadership."

4. Draft the ask per the template below: what the contract says, what playbook says, options with recommendation, decision-by date.

5. Do not send. Draft it, show it, let the lawyer send.

Examples

/commercial-legal:escalation-flagger
The Acme MSA has uncapped liability — who approves and what do I say?

/commercial-legal:escalation-flagger
Reference: acme-review-memo.md
Issue: §8.2 indemnity carveouts

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /commercial-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

Every contracts team has an escalation matrix, written or not. This skill reads the written one (in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md), matches a contract issue against it, names the approver, and drafts the ask so the lawyer isn't writing "hey do you have a sec" messages at 5pm.

Load the matrix

Which side? Before matching to the matrix, determine which side the company is on for the contract whose issue is being escalated. Usually obvious: if the counterparty is a vendor/supplier providing goods or services, you're purchasing-side. If the counterparty is a customer buying your product/service, you're sales-side. If it's not obvious, ask. Read the matching playbook section (### Sales-side playbook or ### Purchasing-side playbook) to evaluate whether the term is inside fallbacks or triggers an automatic escalation — a term that's fine on one side can be a hard-no on the other. Note which side in the drafted ask so the approver knows which playbook was applied.

Read ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → ## Escalation. If it's missing or vague, say so — the cold-start interview should have captured this, and if it didn't, the practice profile needs editing.

Expected structure:

Plus automatic escalation triggers — things that escalate regardless of dollar value. Typically: unlimited liability, IP assignment, anything on the "never accept" lists.

Workflow

Step 1: Characterize the issue

What's being escalated?

• Dollar threshold: Contract value exceeds someone's approval authority
• Term deviation: A term is outside the playbook fallbacks — someone more senior needs to decide whether to accept
• Automatic trigger: One of the always-escalate items is present
• Business decision: Not a legal call — needs the business owner, not legal leadership

Don't escalate things that are actually fine. If the term is within the fallbacks in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md, it doesn't need to go up.

Step 2: Match to the matrix

Is the issue an automatic trigger?
  → YES: escalate to [person named for that trigger]
  → NO: continue

Is the contract value above the reviewer's threshold?
  → YES: escalate to whoever has authority at that dollar level
  → NO: continue

Is the term deviation outside all documented fallbacks?
  → YES: escalate to whoever can approve non-standard terms
  → NO: reviewer can approve — no escalation needed

Step 3: Name the approver

Be specific. Not "escalate to legal leadership" — name the person or role from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If the matrix doesn't name anyone for this situation, say so: "The escalation matrix doesn't cover [situation]. Suggest asking [GC name] who owns this."

Step 4: Draft the ask

The approver should be able to decide from the message alone — no "let me pull up the contract."

**Escalating to:** [name]
**Via:** [Slack #channel / email / meeting — per `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`]
**Urgency:** [deadline if there is one]

---

Hey [name] —

Need your call on the [Counterparty] [agreement type]. [One sentence on deal context.]

**The issue:** [Plain English, one paragraph. What they want, why it's outside
our standard, what the risk actually is.]

**What the contract says:**
> "[exact quote]"

**What our playbook says:** [quote from `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`]

**Options:**
1. **Accept** — [one line on why this might be okay]
2. **Push back with:** "[proposed counter-language]" — [one line on likely counterparty reaction]
3. **Walk** — [one line on whether that's realistic given the business context]

**My recommendation:** [which option and why, briefly]

**Need a decision by:** [date, if there is a deadline]

[Link to full review memo]

Step 5: Record the escalation

If this team uses a ticket system or [CLM] approval workflows, log it. If not, note in the review memo that the escalation was sent, to whom, and when. The next person who reads the memo should see the status.

Calibration: when in doubt, escalate with a note

The cost of an unnecessary escalation is ~30 seconds of the approver's time — they read, say "fine, proceed," and the record shows they saw it. The cost of a missed escalation is signing an unapproved term, which is a one-way door. The costs are not symmetric. When in doubt, escalate.

The calibration for what warrants escalation lives in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md, not in this skill. Check the playbook's stated position, its fallbacks, and its "automatic escalation regardless of dollar value" list:

• Clearly inside the fallback range: no escalation needed.
• Clearly outside the range, or on the automatic-escalation list: escalate.
• Uncertain — the term is ambiguous, novel, or arguably inside the range but the argument is a stretch: escalate anyway, and note the uncertainty explicitly. The draft flags the specific question the approver needs to decide and why the skill couldn't confidently place it inside the fallback. The approver narrows; the skill does not.

Do not suppress an escalation because over-escalation might train approvers to skim. That's an approver-experience problem the attorney solves by adjusting thresholds in the playbook, not a problem the skill solves by making its own subjective call on a term it's uncertain about.

If a term comes up that the playbook doesn't address, don't guess the threshold — ask the reviewing attorney whether this class of issue should escalate, and offer to record the answer in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md so future reviews are consistent.

What this skill does not do

• It does not approve anything. It routes.
• It does not decide between the options. The draft includes a recommendation but the approver decides.
• It does not send the escalation message — it drafts it. The lawyer sends it after reading.

/matter-workspace

Practitioners work across multiple clients and matters. A matter workspace keeps one client or engagement's context separate from every other. This command manages those workspaces.

Subcommands

• /commercial-legal:matter-workspace new <slug> — create a new matter workspace, run a short intake, write matter.md
• /commercial-legal:matter-workspace list — list matters with status and active flag
• /commercial-legal:matter-workspace switch <slug> — set the active matter
• /commercial-legal:matter-workspace close <slug> — archive a matter (move to ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/_archived/, never delete)
• /commercial-legal:matter-workspace none — detach from any active matter, work at practice-level only

Instructions

1. Read ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md — confirm the ## Matter workspaces section is populated. If Enabled is ✗, tell the user: "Matter workspaces are off — you're configured as an in-house practice with one client, so the plugin works from practice-level context automatically. If you actually work across multiple clients, re-run /commercial-legal:cold-start-interview --redo and select a private-practice setting. Otherwise, you don't need /matter-workspace at all." Don't error — the disabled state is the expected one for in-house users.
2. Use the subcommand logic below.
3. Dispatch on the first token of $ARGUMENTS:
   • new → run the intake interview, write ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<slug>/matter.md, seed history.md and notes.md.
   • list → enumerate ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/*/matter.md, print a table, mark the active matter.
   • switch → update the Active matter: line in the practice-level CLAUDE.md.
   • close → move ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<slug>/ to ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/_archived/<slug>/, log the close date in history.md.
   • none → set Active matter: to none — practice-level context only.
4. Show the user what changed and confirm before writing.

Notes

• The skill never reads across matters unless Cross-matter context is on in the practice-level CLAUDE.md.
• Archiving is not deletion — closed matters remain readable for retention/conflicts purposes.
• Slugs are lowercase with hyphens. If a slug is reused across archived and active, the archived one is preserved under _archived/<slug>/.

Multi-client practitioners (private practice — solo, small firm, large firm) work across many matters. Context from one must not leak into another. This skill is the thin file-management layer that makes that true.

Default state is off. In-house users never see this — they run at practice-level only. Matter workspaces turn on at cold-start for private-practice users, or by editing ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗, this skill does not run; the workflow above explains the disabled state and suggests /commercial-legal:cold-start-interview --redo for users who actually need matter isolation.

Storage layout

All matter data lives under:

~/.claude/plugins/config/claude-for-legal/commercial-legal/
├── CLAUDE.md                       # practice-level practice profile
└── matters/
    ├── <slug>/
    │   ├── matter.md               # client, counterparty, matter type, key facts, overrides
    │   ├── history.md              # dated log of events, decisions, drafts, reviews
    │   ├── notes.md                # free-form working notes
    │   └── outputs/                # skill outputs for this matter (optional subfolder)
    └── _archived/
        └── <slug>/                 # closed matters — readable but not active

Slugs are lowercase with hyphens. Examples: acme-msa-2026, zenith-renewal, vendor-xyz-nda.

Active matter is in the practice CLAUDE.md

The Active matter: line under ## Matter workspaces in the practice-level CLAUDE.md is the single source of truth. Switching a matter edits that line. No separate state file.

Subcommand logic

new <slug>

1. Confirm slug is not already present in matters/<slug>/ or matters/_archived/<slug>/. If reused, ask the user to pick a different slug.
2. Run the intake interview:
   • Client (the party we represent, or the internal business unit if in-house)
   • Counterparty (the other side — may be multiple)
   • Matter type (read the plugin's practice profile for typical categories; for commercial-legal: vendor MSA | customer agreement | NDA | SaaS subscription | amendment | renewal | other)
   • Confidentiality level (standard | heightened | clean-team — heightened prompts extra care in cross-matter settings)
   • Key facts (2–5 sentences: what this matter is about, who the stakeholders are, what's at stake)
   • Matter-specific overrides to the practice playbook (e.g., "client requires 24-month LoL cap not 12", "counterparty is a strategic partner — relationship-preserving tone")
   • Related matters (slugs of any connected matters)
3. Write matters/<slug>/matter.md using the template below.
4. Seed matters/<slug>/history.md with a single "Opened" entry.
5. Create an empty matters/<slug>/notes.md.
6. Do not auto-switch to the new matter. Ask: "Want to switch to <slug> now? (/commercial-legal:matter-workspace switch <slug>)"

list

Enumerate matters/*/matter.md. Read each file's front-matter or first few lines to extract status. Print a table:

Mark the currently-active matter with *. Include _archived/* under a separate "Archived" heading if any exist.

switch <slug>

1. Confirm matters/<slug>/matter.md exists. If not, offer /commercial-legal:matter-workspace new <slug>.
2. Edit the Active matter: line in the practice-level CLAUDE.md to Active matter: <slug>.
3. Show the user the matter.md summary so they can confirm they're on the right matter.

close <slug>

1. Confirm matters/<slug>/ exists.
2. Append a "Closed" entry to matters/<slug>/history.md with today's date.
3. Move matters/<slug>/ → matters/_archived/<slug>/.
4. If the closed matter was the active matter, set Active matter: to none — practice-level context only.

none

Set Active matter: in the practice-level CLAUDE.md to none — practice-level context only. Confirm with the user.

matter.md template

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this` in the practice-level CLAUDE.md]

# Matter: [Client] — [short description]

**Slug:** [slug]
**Opened:** [YYYY-MM-DD]
**Status:** active
**Confidentiality:** [standard / heightened / clean-team]

---

## Parties

**Client:** [name]
**Counterparty:** [name(s)]

## Matter type

[vendor MSA | customer agreement | NDA | SaaS subscription | amendment | renewal | other — with one-line rationale]

## Key facts

[2–5 sentences. What this matter is about. Who the stakeholders are. What's at stake. What makes it different from the default playbook.]

## Matter-specific overrides

*Any deviation from the practice-level playbook that applies to this matter and only this matter.*

- [e.g., "LoL cap: client requires 24 months, not house standard 12."]
- [e.g., "Tone: relationship-preserving — counterparty is a strategic partner."]
- [e.g., "Governing law: must be English law, not Delaware."]

## Related matters

- [slug — one line why related]

## Notes on confidentiality

[If heightened or clean-team, describe why. Who may see matter files. Whether cross-matter context is permissible even if globally on.]

history.md seed

# History: [Client] — [short description]

Append-only event log. Most recent at top.

---

## [YYYY-MM-DD] — Matter opened

Intake completed. Slug: `[slug]`. Status: active.
[Any initial context worth preserving beyond matter.md — e.g., "Opened in response to inbound MSA draft from [counterparty]."]

Cross-matter context

The practice-level CLAUDE.md has a Cross-matter context: flag. When it's off (the default), a skill working in matter A never reads files in matters/B/ for any other B. Period. This is the confidentiality guarantee the setting exists to provide.

When it's on, a skill may read files across matter folders only when the user explicitly asks it to (e.g., "compare our position on liability caps across the last five vendor matters"). Even when on, the default is to load only the active matter unless the user asks for a cross-matter view.

What this skill does not do

• Run a conflicts check. Conflicts are the practitioner's/firm's job; the intake captures what the user declares.
• Enforce retention. Closing archives a matter; it does not delete. Retention policy is out of scope.
• Auto-route outputs. The substantive skill decides where to write; this skill tells it which folder is active, not what to put in it.
• Decide whether cross-matter is appropriate. It reads the flag and obeys.

NDA Review

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /commercial-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Destination check

Before producing output, check where it's going. If the user has named a destination (a channel, a distribution list, a counterparty, "everyone"), ask whether it's inside the privilege circle. Public channels, company-wide lists, counterparty/opposing counsel, vendors, and clients (for work product) waive the protection. When the destination looks outside the circle, flag it and offer (a) the privileged version for legal only, (b) a sanitized version for the broader channel, or (c) both — don't silently apply a privileged header and then help paste it somewhere the header won't protect it. See the canonical ## Shared guardrails → Destination check in this plugin's CLAUDE.md.

Purpose

Most inbound NDAs are fine. A few have landmines. This skill sorts them in under a minute so legal only reads the ones that matter.

The goal: a GREEN NDA should need nothing more than a signature. A YELLOW needs a lawyer's eyes on one or two specific things. A RED stops before anyone wastes time.

Load the playbook first

Which side? Before applying the playbook, determine which side the company is on for this NDA. Usually obvious from the context: if the counterparty is a vendor or partner evaluating your product, you're sales-side; if you're evaluating theirs, you're purchasing-side. Mutual NDAs still have a side — whose paper is it, and which direction is the evaluation running. If it's not obvious, ask. Read the matching playbook section (### Sales-side playbook or ### Purchasing-side playbook) from the config. Note which side in the output so the reviewer knows which playbook was applied. If the matching side is [Not configured], stop and tell the user to run /commercial-legal:cold-start-interview --side <side> before this triage can proceed.

Before triaging anything, read ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → ## Playbook → the matching side → NDA triage positions. That section is the source of truth for what makes an NDA GREEN, YELLOW, or RED for this team on this side. This skill does not ship with default positions on NDA terms — the law, the market, and each team's risk tolerance vary too much for hardcoded defaults to be safe.

If ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md doesn't have an NDA triage positions section yet, or it's silent on a term that comes up in the NDA you're reviewing, ask the user:

Your playbook doesn't cover [term — e.g., "residuals clauses," "survival period," "one-way NDAs where you're the receiver"]. What's your default position — when should this be GREEN, when YELLOW, when RED? I'll add it to ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md so the next review is consistent.

Then record the answer in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md and proceed with the triage using the new position.

Scope check

Before reviewing NDA-specific provisions, check whether the document is doing more than its name suggests. Mutual commercial NDAs can hide: standstills, licensing grants, exclusivity, non-solicits, non-competes, IP assignments, right of first refusal, most-favored-nation clauses, and arbitration/jurisdiction clauses that govern far more than confidentiality disputes.

If the NDA contains obligations beyond confidentiality: auto-YELLOW regardless of the NDA-term analysis. Flag the non-NDA provisions:

This document is labeled an NDA but contains [standstill / license grant / non-solicit / exclusivity / IP assignment / ROFR / MFN / broad arbitration]. It's more than an NDA. Route for attorney review.

Do not silently push a document labeled "NDA" through NDA triage when the substantive obligations are a services agreement, a term sheet, or a covenant package in NDA clothing.

The triage

Classify the NDA into one of three buckets by applying the positions from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. The bucket definitions below are stable; the criteria that fill each bucket come from the playbook.

GREEN — route to signature

The NDA satisfies every position in the team's playbook, and no term triggers a RED flag per the playbook. Examples of checks the playbook typically covers: mutuality, term length, survival period, carveouts, governing law, restrictive covenants, fee-shifting. Confirm each one against ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md before calling GREEN.

GREEN requires attorney-reviewed playbook positions. GREEN is the only path to signature without lawyer review. It cannot be issued against default or absent positions. Before issuing GREEN, check: does the practice profile have an attorney-reviewed ## NDA triage positions section? If not:

I can't issue GREEN without attorney-reviewed NDA positions in your practice profile. Run /commercial-legal:cold-start-interview --full with your commercial counsel to set them, or route this NDA for attorney review. Issuing GREEN against defaults means a non-lawyer set the positions the next non-lawyer relies on.

Do not route to signature on defaults. YELLOW is the right call when positions are missing — it surfaces the NDA to a human who can decide.

Output:

Prepend the work-product header from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md ## Outputs (it differs by user role — see ## Who's using this).

[WORK-PRODUCT HEADER — per plugin config ## Outputs]

## NDA Triage: [Counterparty]

GREEN — route to signature

### Executive Summary

No red flags identified under the playbook. Route for signature per standard process.

| Check | Status | Playbook reference |
|---|---|---|
| [Each playbook check] | [pass/fail] | [`~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` section] |

**Next step:** [Submit to [CLM] standard NDA workflow | Send to [approver from `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`] for signature]

Before proceeding past GREEN to signature: Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If the Role is Non-lawyer:

This step has legal consequences (countersigning an NDA binds the company). Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:

[Generate a 1-page summary: counterparty, NDA direction (mutual / one-way), the playbook checks run, anything the playbook didn't cover, what could go wrong if signed as-is, and the three things to ask the attorney.]

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: contact your professional regulator (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent) for a referral service.

Do not proceed past this gate without an explicit yes.

YELLOW — needs a lawyer's eyes on specific items

One or more terms deviate from the playbook but aren't categorical deal-breakers, OR a term appears that the playbook doesn't address. Surface each item individually so the approver can make the call.

Output:

Prepend the work-product header from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md ## Outputs (it differs by user role — see ## Who's using this).

[WORK-PRODUCT HEADER — per plugin config ## Outputs]

## NDA Triage: [Counterparty]

YELLOW — flag for [approver name from `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`]

### Executive Summary

- [One-line actionable edit, e.g. "Strike non-solicit clause (Section 6)"]
- [One-line actionable edit]

### Flagged items

**1. [Issue]** — Section [X]
   What: [one line]
   Why flagged: [one line — which playbook position this hits, or "playbook is silent on this"]
   **Legal risk:** [🔴/🟠/🟡/🟢] | **Business friction:** [🔴 Blocks deals / 🟠 Slows deals / 🟡 Confuses customers / 🟢 Invisible]
   Likely resolution: [accept / push back on X / depends on deal context]

[repeat for each flag]

### Everything else

| Check | Status | Playbook reference |
|---|---|---|
| [playbook checks that passed] | pass | [`~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` section] |

**Next step:** Ask [approver] about the flagged items, then route to signature if they're okay with it.

RED — stop, talk to legal first

The NDA hits a position on the playbook's "never accept" list, or the structure of the agreement is incompatible with the team's standard posture (e.g., a one-way NDA where the team's playbook requires mutual; a perpetual term where the playbook caps at a finite period; governing law on the "never" list).

Output:

Prepend the work-product header from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md ## Outputs (it differs by user role — see ## Who's using this).

[WORK-PRODUCT HEADER — per plugin config ## Outputs]

## NDA Triage: [Counterparty]

RED — do not submit, talk to legal first

### Executive Summary

- [One-line actionable edit, e.g. "Section 4 — route to Legal for review"]
- [One-line actionable edit]

### Critical issues

**1. [Issue]** — Section [X]
   > "[exact quote]"
   Why this is a problem: [specific risk; cite the playbook position it violates]
   **Legal risk:** [🔴/🟠/🟡/🟢] | **Business friction:** [🔴 Blocks deals / 🟠 Slows deals / 🟡 Confuses customers / 🟢 Invisible]
   Recommended response: [use our paper instead | push back with specific language | walk]

**Next step:** Send this triage to [GC or named escalation person from `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`]. Do not send to [CLM or approvals workflow]. Do not tell the counterparty we'll sign.

Redline granularity

Edit at the smallest possible granularity. A redline is a negotiation artifact, not a rewrite. Wholesale clause replacement signals "we threw out your drafting" — it's aggressive, it forces the counterparty to re-read the whole clause, and it discards the parts of their drafting that were fine. Surgical redlines — strike a word, insert a phrase, restructure a subclause — signal "we have specific asks" and are faster to read, understand, and accept.

Default to the smallest edit that achieves the playbook position:

• Replace a word before a phrase. ("twelve (12)" → "twenty-four (24)")
• Replace a phrase before a sentence. ("paid by the Buyer" → "paid and payable by the Buyer")
• Restructure a subclause before replacing the sentence. (Add "(a)" and "(b)" to split a compound condition.)
• Replace a sentence before replacing the clause.
• Only replace a whole clause when the counterparty's version is so far from your position that surgical edits would be harder to read than a fresh draft — and when you do, say so in the transmittal: "We've replaced §8.2 rather than marking it up because the changes were extensive. Happy to walk you through the delta."

When in doubt, smaller. A client who receives a surgical redline trusts that you read carefully. A client who receives a wholesale replacement wonders whether you read at all.

Jurisdiction assumption

This triage applies the governing-law and restrictive-covenant positions recorded in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. Legal rules (enforceability of non-competes, non-solicits, fee-shifting, choice of law) vary materially by jurisdiction. If the NDA involves a jurisdiction outside the team's configured posture, flag it in the output and note that the triage may not transfer as written.

Output rules

Complexity filter: If addressing an issue would require drafting new language, restructuring a clause, or inserting substantive new provisions — do not attempt it. Instead write: "Section [X] — route to Legal for review." Only include simple, mechanical actions in the Executive Summary (strike, delete, replace a word or phrase).

Clean NDA rule: If the NDA passes all checks with no flags, the Executive Summary should say only: "No red flags identified. Route for signature per standard process."

Do not produce a lengthy report for a clean NDA.

Detailed check reference

For each check below, the bucket (GREEN/YELLOW/RED) is determined by ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. This skill lists the categories to check; it does not hardcode thresholds.

Mutuality

Is the NDA mutual or one-way? Apply the team's position from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If the playbook doesn't address one-way NDAs for this context, run the one-way questionnaire below and surface the result for a human.

One-way NDA questionnaire

When the NDA is unilateral (one party discloses, the other only receives), do not immediately flag RED or exit. Ask:

A one-way NDA is appropriate in some situations. Before flagging this, let me ask a few quick questions:

1. In this relationship, are you the only party disclosing confidential information? (i.e., the other side shares nothing back)
2. Is this for a limited, specific disclosure — for example, sharing your technology with a vendor who will work on it, but not sharing theirs with you?
3. Is this related to M&A, employment, or investment? (If yes, stop — this skill is for commercial MNDAs only. Route to Legal.)

Use the answers plus the ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md position to decide GREEN/YELLOW/RED. If ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md doesn't take a position on this fact pattern, flag YELLOW and surface the questionnaire answers for the approver.

Definition of Confidential Information

Check scope (marked-only vs. everything-disclosed), marking requirements, and oral-disclosure confirmation windows. Apply the team's position from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If the playbook is silent on any of these, ask.

Carveouts

The five carveouts typically present in an NDA:

1. Information that is or becomes public (other than through breach)
2. Information the receiving party already had
3. Information independently developed without reference to the CI
4. Information received from a third party without restriction
5. Information required to be disclosed by law or court order (with notice to discloser where legally permitted)

Which carveouts the team requires, and how strictly, is a playbook question. Check ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md for the team's position on required carveouts, acceptable variations in wording, and what happens when one is missing.

Residuals

A residuals clause lets the receiving party use information retained in unaided memory. Whether this is acceptable — and under what conditions (e.g., narrow "unaided memory" wording vs. broader scope covering notes or copies) — is a playbook question. Apply ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If the playbook doesn't address residuals, ask.

Term and survival

Check the initial term length, the post-term survival period for confidentiality obligations, and whether trade secrets are carved out with longer protection. Apply the team's position from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If the playbook doesn't cover one of these, ask.

Restrictive covenants

Check for non-solicits (employee, customer), non-competes, exclusivity, and any restriction on who else the receiving party can engage with. Apply ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If the playbook is silent, ask — restrictive covenants are jurisdiction-sensitive and the team's posture matters.

Attorneys' fees

Check for fee-shifting provisions and whether they are mutual, one-sided, or prevailing-party. Apply ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md.

Backup and archival carveout

Check whether the destruction/return clause includes an exception for standard backup and archival retention systems. Apply the team's position from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md — some teams require this carveout and will push to add it; others accept an NDA without it. If the playbook doesn't address this, ask.

Governing law

Per ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md ## Playbook → Governing law and venue.

Counterparty context

BigCo NDAs: Fortune 500 counterparties generally won't negotiate NDAs. Calibrate: is the RED flag truly a deal-breaker, or is it "different from our form"? If the business relationship matters, the call is whether to accept their paper — escalate that decision, don't make it.

Startup NDAs: Will usually take our paper. If their NDA has issues, the fastest path is often "let's use ours" rather than redlining theirs.

Integration: CLM

If connected:

• GREEN → offer to create the CLM record in the standard NDA workflow
• YELLOW → offer to create it with a note attached listing the flagged items
• RED → do not create a record; the lawyer decides what happens next

What this skill does NOT do

• It does not negotiate. It sorts.
• It does not draft an NDA. If the answer is "use our paper," the user pulls our form from [CLM or document system].
• It does not make the call on YELLOW items. It surfaces them for a human.
• It does not state a position on any NDA term. Positions live in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md.

Closing action

Read ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → ## NDA triage preferences → closing_action.

If configured, append the closing action verbatim at the end of every output. Example configurations:

closing_action: "Send the full text of this analysis along with a copy
of the NDA to Legal at legal@[yourcompany].com for final confirmation before
signing."

closing_action: "Submit to [CLM] using the standard NDA workflow.
Legal will confirm before routing for signature."

closing_action: "Forward this output and the NDA to your contracts
manager."

If closing_action is not configured in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md, append: "Route final NDA through your standard approval process."

The cold-start interview asks: "When someone finishes an NDA triage, what do you want them to do with the output? I'll add that as a standing instruction at the end of every review."

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

/renewal-tracker

Surfaces what's renewing and when you have to cancel by.

Instructions

1. Read ~/.claude/plugins/config/claude-for-legal/commercial-legal/renewal-register.yaml (the config directory — survives plugin updates).

2. Default mode: Mode 2 — what's coming up in the next 90 days, grouped by urgency using half-open intervals so each deadline lands in exactly one band: 🔴 0–13 days, 🟠 14–44 days, 🟡 45–89 days. Days 14, 45, and 90 are boundaries — each belongs to exactly one band, not two.

3. --days N: Change the window.

4. --missed: Mode 4 — cancel-by deadlines that passed without recorded cancellation.

5. If register is empty and the [CLM] is connected: Offer Mode 3 — scan the [CLM] for active agreements with renewal dates and bulk-load.

6. Output includes recommended actions: who to ping (the business owner from each register entry), which ones have uncapped pricing (get leverage before window closes).

Examples

/commercial-legal:renewal-tracker

/commercial-legal:renewal-tracker --days 180

/commercial-legal:renewal-tracker --missed

Purpose

Nobody reads a contract twice. The renewal date is extracted once, at review time, and then it lives somewhere — ideally somewhere that shouts at you 45 days before the cancel-by deadline, not 45 days after.

This skill maintains the renewal register and surfaces what's coming.

The register

Lives at ~/.claude/plugins/config/claude-for-legal/commercial-legal/renewal-register.yaml (the config directory — survives plugin updates). Each entry:

- counterparty: "Acme SaaS Inc."
  agreement: "Acme Platform Subscription Agreement"
  signed_date: 2025-06-15
  initial_term_end: 2026-06-15
  current_term_end: 2026-06-15     # rolls forward after each auto-renewal; compute cancel_by_* from this
  renewal_mechanism: "auto-renew annual"
  notice_period_days: 60
  notice_method: "email"           # email / portal / certified mail / registered post / courier / per contract §X
  transit_buffer_days: 0           # 0 for electronic, 5 for domestic certified mail, 10 for international registered post — or per contract if specified
  cancel_by_calendar: 2026-04-16    # current_term_end minus notice_period_days
  cancel_by_effective: 2026-04-16   # rolled back to last business day if needed
  send_by_effective: 2026-04-16    # cancel_by_effective minus transit_buffer_days — the date you must SEND the notice
  cancel_by_roll_note: ""           # e.g., "rolled back from Sunday 2026-11-01; verify against contract's business-day definition"
  cancel_by_provenance: "[model calculation — verify against the notice clause]"
  price_on_renewal: "then-current list (uncapped)"
  annual_value: 48000
  business_owner: "jane@company.com"
  clm_id:        "IC-12345"        # if connected
  docusign_envelope: "abc-123"   # if connected
  status: "active"               # active | cancelled | renewed | lapsed
  notes: "Pricing uncapped — revisit before renewal. Alt vendors: X, Y."

Notice transit time — alert off send_by_effective, not cancel_by_effective. A 60-day window with a certified-mail requirement is really ~55 days. The tracker that alerts on the received-by date is the tracker that misses the deadline. Compute send_by_effective = cancel_by_effective - transit_buffer_days and fire alerts (the 🔴 / 🟠 / 🟡 urgency bands in Mode 2) off send_by_effective. Mode 2's urgency column shows send_by_effective; a detail column surfaces cancel_by_effective, notice_method, and transit_buffer_days so the reader can see the delta and challenge the buffer.

Rolling renewals — the register that doesn't roll forward is the register that's right once. Store initial_term_end for the record, but compute cancel_by_* from current_term_end. When a renewal fires (the cancel window passes and no notice was given), prompt:

This contract auto-renewed on [date]. Update the register: new current_term_end is [date + renewal period], new cancel_by_effective is [computed], new send_by_effective is [computed]. Confirm?

After year one, initial_term_end is wrong and only current_term_end produces a correct cancel-by date.

Business-day check on every cancel-by date

The register's cancel-by date must be the last BUSINESS DAY on which notice is effective, not the calendar date. A calendar date that falls on a weekend is the single most common way a renewal deadline gets missed. The register catches it.

When you compute (or ingest) a cancel-by date:

1. Compute the calendar date. cancel_by_calendar = initial_term_end − notice_period_days (or whatever the clause specifies). This is the raw arithmetic.
2. Business-day roll-back keyed to governing law. The contract's governing law determines which holidays count. US: federal holidays + the state's holidays if governing law is a state. England & Wales: bank holidays. Germany: Feiertage (vary by Bundesland — ask which). Canada: federal + provincial. Singapore: public holidays. If Saturday, roll back to Friday. If Sunday, roll back to Friday. If a holiday in the governing-law jurisdiction, roll back to the prior business day. Roll BACK, never forward — forward means notice arrives after the window closes. For non-US governing law, if you can't determine the holiday calendar, flag it: "Governing law is [X] — business-day roll-back uses US federal holidays as a placeholder. Verify against the [jurisdiction] holiday calendar before relying on the effective date."
3. Check the contract's own day-counting rule. Look for "business day," "received by," "deemed received," "5:00 p.m. [local time]," or a notice-method clause. If the contract defines "business day" or specifies receipt mechanics (certified mail, email with read receipt), that definition controls. Flag any mismatch between the default roll-back and the contract's own rule.
4. Record BOTH dates in the register. cancel_by_calendar is the raw arithmetic; cancel_by_effective is the last business day on which notice is effective; cancel_by_roll_note records why they differ (e.g., "rolled back from Sunday 2026-11-01; verify against contract's business-day definition"). Every computed cancel_by_effective carries a cancel_by_provenance tag of [model calculation — verify against the notice clause] so the verify flag travels with the date, not with the surrounding prose.
5. Fire alerts off the EFFECTIVE date, not the calendar date. Urgency bands (🔴 / 🟠 / 🟡 in Mode 2) use cancel_by_effective. Mode 2 output shows cancel_by_effective in the urgency column and surfaces cancel_by_calendar and cancel_by_roll_note in a detail column where the roll-back happened, so the reader can see it and challenge it.

A Mode 2 report that prints cancel_by: 2026-11-01 (a Sunday) with no weekday and no warning is a silently wrong effective deadline. The register is the place to catch it — once, at ingest — not later, when the window has already moved.

Modes

Mode 1: Ingest a renewal (handoff from review)

When saas-msa-review or vendor-agreement-review finds a renewal clause, it hands off a record. Append it to the register. If the counterparty already has an entry, ask whether this is a replacement (renewed agreement) or an additional agreement.

Mode 2: What's coming up

Default lookback window: next 90 days.

Urgency bands are half-open intervals — a deadline lives in exactly one band. Use days-until-cancel-by (cancel_by_effective - today). Day 14, 45, and 90 each belong to exactly one band, not two; an off-by-one here puts the most-urgent items into the less-urgent bucket.

• 🔴 0–13 days (cancel-by in less than 14 days — including today)
• 🟠 14–44 days
• 🟡 45–89 days
• (everything 90+ days is outside the default lookback window; include only if the user passed --horizon beyond 90)

## Renewals — next 90 days

### 🔴 Cancel-by deadline in 0–13 days

| Counterparty | Cancel by | Renewal date | Annual $ | Owner | Notes |
|---|---|---|---|---|---|
| [name] | **[date]** | [date] | $[n] | [email] | [notes] |

### 🟠 Cancel-by deadline in 14–44 days

[same table]

### 🟡 Cancel-by deadline in 45–89 days

[same table]

---

**Recommended actions:**
- [ ] [Counterparty] — ping [business owner]: do we want to keep this?
- [ ] [Counterparty] — pricing is uncapped; get a quote from an alternative before we lose leverage

If the register has more than ~10 renewals in the window, or any time the user asks: offer the dashboard (see CLAUDE.md ## Outputs → Dashboard offer for data-heavy outputs). Shape the offer for this output — counts by urgency tier (🔴 / 🟠 / 🟡), a cancel-by timeline, and a sortable register with counterparty, renewal date, annual $, and owner.

Mode 3: Scan the [CLM] / e-signature tool to populate the register

If MCPs are connected and the register is empty or stale:

1. Query the [CLM] for all agreements with status "Active" and a renewal date field
2. Query DocuSign for completed envelopes in the last 24 months with "subscription" / "renewal" / "auto-renew" in metadata
3. For each hit, extract renewal mechanics and add to register
4. Flag any where the renewal date can't be determined from metadata — those need a human to read the contract

This is a one-time bulk load. After that, ingest happens at review time.

Mode 4: Missed windows (the bad news report)

## Missed cancellation windows

The following agreements had cancel-by deadlines that have passed and no
cancellation was recorded:

| Counterparty | Cancel-by was | Renewal date | Status |
|---|---|---|---|
| [name] | [date] | [date] | Will auto-renew on [date] |

**Options:**
- Negotiate late cancellation (rarely works but worth asking)
- Accept the renewal, mark next year's cancel-by now
- Check the agreement for any other termination rights (for convenience, for cause)

Gate: accepting or declining a renewal

Tracking a renewal date is research. Acting on it — sending a notice of non-renewal, letting an auto-renewal fire, or countersigning a renewal form — is a consequential legal step.

Before proceeding to accept or decline a renewal (including sending a non-renewal notice or letting an auto-renewal run past the cancel-by date): Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If the Role is Non-lawyer:

This step has legal consequences (you're either committing to another term or terminating the relationship). Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:

[Generate a 1-page summary: counterparty, current term end and cancel-by date, renewal price mechanism, what happens if we do nothing, alternative vendors if we want to shop, and the three things to ask the attorney before the window closes.]

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: contact your professional regulator (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent) for a referral service.

Do not proceed past this gate without an explicit yes.

Integration: renewal-watcher agent

The renewal-watcher agent in this plugin runs this skill on a schedule (weekly by default) and posts the "coming up" report to the channel named in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → ## House style → where work product goes. Mode 2 is the agent's primary output.

What this skill does not do

• It does not cancel contracts. It tells you when to decide.
• It does not decide whether to renew. It surfaces the deadline and the business owner.
• It does not read contracts to find renewal dates — that happens at review time. If a contract is in the register without a renewal date, it was added manually and someone needs to fill in the gap.

/review-proposals

Steps through pending playbook update proposals from the monitor agent and applies approved changes to ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md.

Instructions

1. Load the playbook-monitor agent and run Step 5 (review and approval flow).

2. If no proposals file exists or it is empty: respond "No pending proposals. Playbook is up to date." Do not proceed further.

3. Present proposals one at a time. For each, show the full proposal block and offer four options: Accept, Reject, Edit, Defer.

4. For Accept or Edit: show the exact diff to ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md before writing. Only apply after the attorney explicitly confirms.

5. For Reject or Defer: log the decision. Do not modify ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md.

6. After all proposals are resolved: show a summary of what changed, then archive the proposals file.

Examples

/commercial-legal:review-proposals

/commercial-legal:review-proposals
(runs automatically after playbook-monitor notifies you)

/review

Reviews an inbound agreement against the playbook in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. Identifies the agreement structure from titles, selects the appropriate skill(s), and — if confirm_routing is enabled — checks with the user before proceeding.

Instructions

1. Load ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If placeholders present, stop and prompt: "Run /commercial-legal:cold-start-interview first — I need to learn your playbook before I can review against it."

   Also read ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → ## Review preferences → confirm_routing. If the field is missing, treat it as true.

2. Get the agreement: From file path, Drive link, [CLM ID], or pasted text. If none provided, ask.

3. Read the document structure — titles first.

   Before reading the body, extract:

   • The main agreement title (e.g., "Master Services Agreement", "Non-Disclosure Agreement")
   • All exhibit, schedule, addendum, and attachment titles (e.g., "Exhibit A — Data Processing Addendum", "Schedule 1 — Subscription Order Form", "Annex B — Service Level Agreement")

   This is the routing signal. Do not rely on body keywords alone — a 40-page MSA with "confidential" throughout is not an NDA.

4. Select the skill(s) based on document structure.

   Map each identified document or section to a skill:

   Document / section title contains	Skill
   Non-Disclosure, NDA, Confidentiality Agreement (as the main agreement)	nda-review
   Master Services Agreement, Professional Services, Statement of Work, Consulting Agreement	vendor-agreement-review
   Subscription, SaaS, Cloud Services, Order Form with auto-renewal, Software License with recurring fees	saas-msa-review (overlay on vendor-agreement-review)
   Data Processing Addendum, DPA, Data Processing Agreement (as exhibit or standalone)	note for vendor-agreement-review → data protection section
   Service Level Agreement, SLA (as exhibit)	note for saas-msa-review → SLA section

   Multiple skills may apply. Common combinations:

   • MSA + DPA exhibit → vendor-agreement-review, with DPA noted
   • SaaS subscription + Order Form + SLA exhibit → saas-msa-review (covers all three)
   • MSA + Order Form with auto-renewal → vendor-agreement-review + saas-msa-review overlay

   When the structure is genuinely ambiguous after reading titles (e.g., a document titled "Agreement" with no exhibits listed), read the first two pages of the body to resolve it — then stop and route.

5. Confirm routing if enabled.

   If confirm_routing is true in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md (or field is absent):

   I'm going to review this as: [agreement type(s)].
   
   Documents identified:
   - [Main agreement title] → [skill]
   - [Exhibit A title] → [how it will be handled]
   - [Exhibit B title] → [how it will be handled]
   
   Sound right? (yes / no — or tell me what I got wrong)
   

   Wait for confirmation before proceeding. If the user corrects the routing, apply their instruction and proceed.

   If confirm_routing is false: proceed silently. Log the routing decision at the top of the review memo so the user can see what was applied.

6. Run the skill(s). Follow each skill's workflow fully. If multiple skills apply, run them in sequence and integrate the output into a single memo — don't produce separate memos.

7. Check for escalations: If any issue exceeds the reviewer's authority per the ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md matrix, invoke escalation-flagger to route and draft the ask.

8. Offer follow-ups:

   • Stakeholder summary for the business owner
   • Redline .docx with tracked changes
   • [CLM] record creation (if connected)
   • Add to renewal register (if auto-renewal found)

Configuring confirm_routing

Add to ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → ## Review preferences:

## Review preferences

confirm_routing: true   # Set to false to skip routing confirmation and proceed automatically

The cold-start interview should ask about this preference. Default is true — confirmation on. As trust builds, the user can set it to false.

Examples

/commercial-legal:review vendor-msa.pdf

/commercial-legal:review https://drive.google.com/file/d/ABC123

/commercial-legal:review
[paste agreement text]

Output

Full review memo per the skill's format. Routing decision logged at the top. Deviation-by-deviation, specific redline language, named approver. Saved where ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → House style says work product goes.

SaaS / Subscription Agreement Review

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /commercial-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

SaaS agreements have a distinct risk profile from one-time vendor contracts. The dollars compound over renewals, the data accumulates, and the switching cost grows every month. This skill reviews with that in mind.

It runs the standard playbook check from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md and adds a SaaS-specific overlay on the terms that bite hardest in subscription deals.

Jurisdiction assumption

SaaS terms (auto-renewal notice requirements, price-escalation caps, data-portability mandates, subprocessor rules) are jurisdiction-sensitive — California, New York, and EU rules diverge materially, and some states have auto-renewal statutes that override private contract terms. This review applies the team's positions from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md, which assume the governing law recorded there. If the agreement picks a different governing law, or the deal spans jurisdictions with statutory overrides (e.g., EU-based users, California consumers), flag it — the analysis may not transfer as written.

No silent supplement. If a research query to the configured legal research tool (Westlaw, or firm platform) returns few or no results for a statutory override that might bear on the deal (auto-renewal statute, data-portability mandate, consumer-protection rule), report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [jurisdiction / rule]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged [web search — verify] and should be checked against a primary source before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources.

Source attribution. Where the review cites a statute, regulation, or case (e.g., a state auto-renewal law overriding contract terms), tag the citation: [Westlaw], [statute / regulator site], or the MCP tool name for citations retrieved from a legal research connector; [web search — verify] for web-search citations; [model knowledge — verify] for citations recalled from training data; [user provided] for citations from the counterparty draft or house files. Citations tagged verify carry higher fabrication risk and should be checked first. Never strip or collapse the tags.

Load the playbook

Which side? Before applying the playbook, determine which side the company is on for this SaaS agreement. Usually obvious: if the counterparty is a SaaS vendor selling you their platform, you're purchasing-side. If you are the SaaS vendor and the counterparty is your customer, you're sales-side. If it's not obvious (a reseller arrangement, a white-label deal), ask: "Which side is [company] on for this agreement — vendor or customer?" Read the matching playbook section (### Sales-side playbook or ### Purchasing-side playbook) from the config. Note which side in the output so the reviewer knows which playbook was applied. If the matching side is [Not configured], stop and tell the user to run /commercial-legal:cold-start-interview --side <side> before this review can proceed.

Read ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md first. The general playbook for the matching side (liability, indemnity, termination, governing law) applies fully — run all the standard checks from the vendor-agreement-review skill.

Then look for a ## Playbook → matching side → SaaS positions section. That's where the team records its positions on auto-renewal notice windows, acceptable price escalators, data export rights, SLA thresholds, subprocessor approval rights, and deprecation notice. This skill does not ship with defaults for these — the right numbers vary by deal size, vendor leverage, and the team's risk tolerance.

If ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md doesn't address a SaaS-specific term that comes up in this review, ask:

Your playbook doesn't cover [term — e.g., "maximum acceptable auto-renewal notice window" or "whether vendor retention of anonymized derivatives is acceptable"]. What's your team's position? I'll add it to ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md.

Record the answer and proceed.

SaaS-specific overlay

For each category below, list what you found in the contract and compare to the team's position in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. Do not apply hardcoded thresholds from this skill.

1. Auto-renewal mechanics

The single most common way a SaaS deal goes wrong: nobody notices the renewal notice window and we're locked in for another year at a higher price.

Check each element and compare against the team's SaaS positions in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md:

• Renewal term length (e.g., same as initial, longer, multi-year auto-convert)
• Notice-to-cancel window (number of days before renewal)
• Notice method (email, written notice to legal, portal-only, certified mail)
• Price on renewal (same, CPI-capped, then-current list, uncapped discretionary)

Extract and record the exact renewal date and the notice window regardless of whether any item is flagged. This feeds the renewal-tracker skill.

2. Price escalation

Check each element against ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md:

• Annual escalator (fixed %, CPI, uncapped, etc.)
• Usage overage pricing (published rate card, premium rate, unspecified)
• Scope of "fees" (subscription only vs. "additional services" broadly defined)

3. Data portability and exit

When (not if) we leave this vendor, can we get our data out? Check each element against ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md:

• Export format (open/standard, proprietary-but-documented, "commercially reasonable")
• Export availability (self-serve anytime, on request during term, only at termination)
• Post-termination access (days available to export after termination)
• Export cost (free, T&M, per-GB or per-record)
• Deletion certification (certified on request, none, vendor retains derivatives)

Vendor retention of "anonymized" or "aggregated" derivatives is a material position — confirm the team's stance in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md and flag either way.

4. Uptime and SLA

Only matters if the business actually depends on this service being up. If it's a nice-to-have tool, skip this section — don't spend negotiating capital on SLAs for a survey tool.

Check each element against ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md:

• Uptime commitment (percentage, or "commercially reasonable efforts")
• Measurement period (monthly, quarterly, annual)
• Remedy (service credits — how calculated, whether capped, whether sole remedy)
• Scheduled maintenance exclusions (defined window, advance notice, unlimited)
• Credit-as-sole-remedy interaction with the liability cap

5. Subprocessors

This is a data protection issue but it's SaaS-specific because the subprocessor list changes over the life of the subscription.

Check each element against ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md:

• Current list (published, on request, unavailable)
• Change notification (advance notice period, or none)
• Objection rights (blocking, notice-and-terminate, notice-only, none)

6. Service changes and deprecation

SaaS vendors change their product. Usually fine. Sometimes they deprecate the thing you bought.

Check each element against ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md:

• Material adverse changes (right to terminate on material degradation, notice-only, unrestricted)
• Deprecation notice period for features the team relies on
• Feature parity on replacement (same price tier, higher tier)

AI and machine learning rights

AI/ML data rights decision procedure. Don't just check whether an AI training clause exists. The #1 emerging negotiation point in SaaS contracts is structurally more than a one-line existence check. Work through:

1. Explicit grant. Does the contract explicitly grant the vendor rights to use Customer Data / Customer Content / Usage Data for AI training, model improvement, or ML development? Purchasing-side: this is usually a NO — customer data training the vendor's models means the customer is subsidizing the vendor's product and possibly leaking competitive information. Sales-side: this is revenue if you get it, reputation risk if you abuse it.
2. Implicit grant via policy. Does the contract incorporate the vendor's privacy policy or terms of service by reference? Can the vendor add training rights via a unilateral policy update? Check: "The parties agree to the Provider's Privacy Policy as updated from time to time" is a training-rights grant waiting to happen. Also watch for "service improvement" or "analytics" catch-alls and "usage data" definitions that carve logs/telemetry out of the Customer Data definition so data-use restrictions don't apply.
3. Anonymization standard. If the vendor claims it only trains on "anonymized" or "aggregated" data, what's the standard? "Anonymized" without a definition is weak. Does it meet GDPR Recital 26 / HIPAA Safe Harbor / a named standard? Is it reversible?
4. Competitive contamination. Does the vendor serve your competitors? If so, training on your data could leak competitive intelligence into outputs your competitors see. Is there a competitive isolation commitment?
5. Opt-out scope and durability. If there's an opt-out, does it cover all AI uses or only some? Does it survive renewals and TOS updates? Is it per-user or per-org? Many vendors default to training and offer an opt-out buried in an admin console — check whether the contract makes the default explicit.
6. Output ownership. If the SaaS product is itself AI-generated (drafting, summarization, analysis), who owns the outputs? Can the vendor use your outputs as training examples? Check third-party AI subprocessors too — the vendor may send customer data to a third-party LLM (OpenAI, Anthropic, Google) and the subprocessor list / data flow is where that shows up.
7. Downstream regulatory chain. Does the vendor's use of your data for AI create regulatory exposure for YOU? EU AI Act deployer obligations, FTC §5 undisclosed data-sharing exposure (see FTC v. Humor Rainbow/OkCupid), state AI laws.

Match each to a playbook position. The practice profile's ## AI/ML training rights section should have positions for each. If the agreement is silent on all seven, that's still a finding: "The agreement is silent on AI/ML training rights — request an explicit prohibition or a defined carve-out tied to each of the seven dimensions above."

Liability cap decision procedure

The cap amount is the least important part of the cap. Limitation-of-liability is not a single "check against playbook" item. Work through:

1. Direct vs. indirect/consequential damages. Does the cap apply to ALL liability, or only direct damages? A 12-month cap on direct damages with uncapped consequential damages is a completely different position than a 12-month aggregate cap. State both treatments explicitly.

2. The cap base — quote it verbatim. "12-month cap" could mean: (a) fees paid in the 12 months preceding the claim, (b) fees payable in the current 12-month period, (c) fees over the last 12 months of usage, (d) fees under the current order form, (e) total fees ever paid. These can differ by an order of magnitude. Quote the exact language. If ambiguous, flag it: "Cap base is ambiguous — [the quoted language] — could mean [X] or [Y]. Confirm before signing."

3. Cap-carveout interaction. A $100K cap with uncapped indemnity for data breach, IP, and confidentiality is functionally uncapped for the claims that actually arise in SaaS disputes. Enumerate what sits ABOVE the cap (the carveouts), what sits BELOW (what's actually capped), and assess whether the capped surface is meaningful: "The cap covers [general contract breach]. Data breach, IP indemnity, and confidentiality are carved out and uncapped. For this vendor's risk profile, the capped surface is [meaningful / nominal]."

4. Your playbook position per dimension. The practice profile should have positions for: direct cap (multiple of fees), indirect damages (excluded / capped / uncapped), carveout list (what's acceptable above the cap), and cap base (which definition you'll accept). If the playbook has one "standard position" field, note: "Your playbook has a single cap position — consider splitting into direct/indirect/carveouts/base for more precise review."

Jurisdiction delta check

The playbook applies one governing-law preference globally. Enforceability varies materially. Check the SaaS contract's actual governing law against the top divergences before accepting playbook positions at face value:

• Non-solicits/non-competes: Unenforceable in CA (Bus. & Prof. Code §16600). Restricted in many EU jurisdictions. Enforceable with limitations elsewhere. [jurisdiction — verify]
• Auto-renewal: CA GBL §17600-17606, NY GBL §527-a, IL 815 ILCS 601 have specific consumer/B2B notice requirements. Other states vary. [jurisdiction — verify]
• Liability exclusions: EU and UK unfair contract terms rules (UCTA 1977, Consumer Rights Act 2015) constrain consumer exclusions. Some US states limit exclusion of gross negligence or willful misconduct. [jurisdiction — verify]
• Indemnification: Some states void indemnification for the indemnitee's own negligence. [jurisdiction — verify]
• Confidentiality term: Some jurisdictions limit "perpetual" confidentiality to a reasonable period. [jurisdiction — verify]

When the playbook position conflicts with the contract's governing-law enforceability, flag: "Your playbook prefers [X], but this contract is governed by [Y] law where [X] is [unenforceable / restricted / subject to statutory override]. [jurisdiction — verify]"

Redline granularity

Edit at the smallest possible granularity. A redline is a negotiation artifact, not a rewrite. Wholesale clause replacement signals "we threw out your drafting" — it's aggressive, it forces the counterparty to re-read the whole clause, and it discards the parts of their drafting that were fine. Surgical redlines — strike a word, insert a phrase, restructure a subclause — signal "we have specific asks" and are faster to read, understand, and accept.

Default to the smallest edit that achieves the playbook position:

• Replace a word before a phrase. ("twelve (12)" → "twenty-four (24)")
• Replace a phrase before a sentence. ("paid by the Buyer" → "paid and payable by the Buyer")
• Restructure a subclause before replacing the sentence. (Add "(a)" and "(b)" to split a compound condition.)
• Replace a sentence before replacing the clause.
• Only replace a whole clause when the counterparty's version is so far from your position that surgical edits would be harder to read than a fresh draft — and when you do, say so in the transmittal: "We've replaced §8.2 rather than marking it up because the changes were extensive. Happy to walk you through the delta."

When in doubt, smaller. A client who receives a surgical redline trusts that you read carefully. A client who receives a wholesale replacement wonders whether you read at all.

Output

Use the vendor-agreement-review memo structure, with a SaaS-specific section added after the standard playbook checks. The vendor-agreement-review memo already carries the privilege header.

Dual severity. Every SaaS-specific finding carries both axes (see CLAUDE.md ## Dual severity):

• Legal risk: 🔴 Critical | 🟠 High | 🟡 Medium | 🟢 Low
• Business friction: 🔴 Blocks deals | 🟠 Slows deals | 🟡 Confuses customers | 🟢 Invisible

Data-exit, auto-renewal, and price-escalation findings are the ones most likely to be 🟢 legal / 🔴 business — the clause is enforceable, but it's the reason a customer can't leave or a renewal surprises finance. Surface those at the business-friction severity, not the legal one.

### Bottom line

[Can you sign / Need to fight for X first / Walk — one-sentence why]

### AI and machine learning rights

[The #1 emerging SaaS negotiation point. Flag: explicit ML training clauses, "service improvement" catch-alls, usage data definitions, output ownership, third-party AI subprocessors, opt-out vs opt-in. If the agreement is silent: "Silent on AI/ML training rights — request explicit prohibition or defined carve-out."]

## SaaS-specific findings

### Auto-renewal
**Renewal date:** [date]
**Notice window:** Cancel by [date] ([N] days before renewal)
**Renewal price mechanism:** [as written]
**Playbook fit:** [within position / deviation / not addressed]
**Flag for renewal-tracker:** [yes — and the record the tracker needs]

### Price escalation
[findings against `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` positions]

### Data exit
[findings — this is the one the business owner should read]

### SLA
[findings, or "Skipped — service is not business-critical per [stakeholder]"]

### Subprocessors
[findings against `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` positions]

### Service changes
[findings against `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` positions]

Handoffs

To renewal-tracker: When you find the renewal date and notice window, hand them off. The renewal-tracker register expects the following fields (see skills/renewal-tracker/references/renewal-register.yaml for the full schema):

counterparty:         [name]
agreement:            [title]
signed_date:          [ISO date]
initial_term_end:     [ISO date]
renewal_mechanism:    [e.g., "auto-renew annual"]
notice_period_days:   [integer]
cancel_by_effective:            [ISO date — initial_term_end minus notice_period_days]
price_on_renewal:     [mechanism as written]
annual_value:         [integer, if stated]
business_owner:       [email, if known]
clm_id:               [id if available]
status:               active

If any field is not determinable from the contract or context, leave it out and note which fields were missing so the human can fill them in. clm_id, annual_value, and business_owner are especially likely to need human input.

To escalation-flagger: If any of the SaaS-specific checks hits the team's "never accept" or escalation-trigger list in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md, the escalation-flagger skill routes it.

A note on what to fight over

SaaS vendors, especially large ones, negotiate their paper about as willingly as airlines negotiate ticket terms. Pick battles per the team's playbook — the SaaS positions section in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md should distinguish between terms the team will always push on, terms it fights over only for material deals, and terms it lets slide. If the playbook doesn't draw those lines, ask.

Calibrate based on contract value and switching cost. A $5K/year tool with easy alternatives gets a lighter touch than a $500K/year platform we'll build on top of.

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

Stakeholder Summary

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /commercial-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Destination check

Before producing output, check where it's going. If the user has named a destination (a channel, a distribution list, a counterparty, "everyone"), ask whether it's inside the privilege circle. Public channels, company-wide lists, counterparty/opposing counsel, vendors, and clients (for work product) waive the protection. When the destination looks outside the circle, flag it and offer (a) the privileged version for legal only, (b) a sanitized version for the broader channel, or (c) both — don't silently apply a privileged header and then help paste it somewhere the header won't protect it. See the canonical ## Shared guardrails → Destination check in this plugin's CLAUDE.md.

Purpose

The business owner who asked for this contract doesn't want a legal memo. They want to know: can I sign it, what's the catch, and what do I need to do. This skill takes a completed review and turns it into that.

Which side?

The underlying review memo was run against either the sales-side or the purchasing-side playbook. Carry that framing through. A purchasing-side summary tells the business owner "here's what we're getting and what we agreed to give up"; a sales-side summary tells them "here's what we're selling and what we're on the hook for." Check which side the review was run on (it should be noted at the top of the review memo) and match the voice. If it's not obvious from the memo, ask the lawyer before summarizing.

Audience calibration

Read ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → ## House style → who reads stakeholder summaries, how long should they be. If not specified, default to: procurement or a department head, two paragraphs max, no legal terms of art.

Different audiences need different summaries:

Ask who this is for if it's not obvious from context.

The summary

Length cap — enforced

The summary is:

• One paragraph for the verdict and what this is (business terms, plain English)
• One paragraph for the catch — the thing the stakeholder would be surprised by later if nobody told them now
• A 2-3 item checklist for what the stakeholder actually needs to do (at most three items; if you want a fourth, the first three aren't tight enough)
• A one-line close with approval timing

Under 200 words total. If you're writing more, you're including detail the stakeholder doesn't need — they have the memo for that. This is the quick read before the stakeholder hits reply.

If the close needs a third paragraph, fold it into the checklist instead. Don't let the close grow into a fourth block.

Scope of quote — discipline

When quoting a contract clause (in the summary, in the "catch" paragraph, or in the checklist), quote the full conditional sentence, not a truncated version. A clause that reads "Except as expressly provided in the Order Form, renewal of promotional or one-time priced subscriptions resets to list price" means something different from "renewal resets to list price" — the truncation drops the condition and misrepresents what the term does.

If a full conditional quote doesn't fit the summary's length cap, paraphrase rather than truncate. "For promotional pricing, renewal resets to list" is a fair paraphrase; "renewal resets to list" is not — it promotes the exception to the rule.

Format

Prepend the work-product header from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md ## Outputs (it differs by user role — see ## Who's using this).

[WORK-PRODUCT HEADER — per plugin config ## Outputs]
<!-- Remove the header above if forwarding outside the legal-privileged circle (e.g., to a business stakeholder, counterparty, or vendor). Confirm the correct marking for your jurisdiction and matter before forwarding. -->

**[Counterparty] [Agreement type]** — [READY TO SIGN | NEEDS CHANGES | BLOCKED]

[One paragraph: what this agreement does, in business terms. Not "Master Services
Agreement for the provision of cloud-based analytics" — "this is the contract
for the dashboard tool the marketing team wants."]

[One paragraph: what the stakeholder needs to know. The catch, if there is one.
The thing that will surprise them later if nobody tells them now. E.g., "Heads
up: this auto-renews every year and we have to cancel 60 days out. I've added
it to the tracker but you should know." Or: "Clean agreement, no surprises,
cleared to sign."]

<!-- Do not claim "I've added it to the tracker" unless `renewal-tracker` has
actually been run for this contract — see Verify tracker entries before
asserting them below. -->

**Verify tracker entries before asserting them.** Before the summary says "I've added it to the tracker" (or any equivalent — "it's in the tracker," "tracked," "set a reminder"), verify that `renewal-tracker` has been run for this contract. Check the outputs folder or the matter folder for a `renewal-tracker` output that names this counterparty / agreement. If there isn't one:

- Either run `renewal-tracker` for this contract first, then write the summary.
- Or write the summary without asserting the tracker entry, and include an action item: "Add to renewal tracker — not yet done."

Claiming a tracker entry exists when it does not is worse than omitting the reassurance. The stakeholder then trusts the reminder that will never fire. If the truthful statement is "tracked," the skill runs the tracker. If it's "you should add this to your calendar — I haven't logged it," say that.

**What you need to do:**
- [ ] [Action item, if any — "confirm the team is okay with data living in EU"
  or "nothing — I'll route for signature"]

**Approval:** [who's approving and expected timing]

What to translate

What NOT to include

• Section numbers
• Defined terms in quotes
• The word "indemnification" (say "they cover us if" / "we cover them if")
• The word "notwithstanding"
• Risk matrices with colored dots (unless this stakeholder has specifically asked for them before)
• Caveats about how this isn't legal advice — the stakeholder knows who sent it

When the review found problems

If the review has 🔴 or 🟠 issues, the summary still needs to be two paragraphs — but the second paragraph is "here's what we're pushing back on and why."

[WORK-PRODUCT HEADER — per plugin config ## Outputs]
<!-- Remove the header above if forwarding outside the legal-privileged circle. -->

**[Counterparty] [Agreement type]** — NEEDS CHANGES

[What it is, one paragraph.]

We're going back to them on [N] things before this is ready. The main one:
[the critical issue in plain English — "they want the right to use our data
to improve their product, which means our competitors' instance gets smarter
from our data"]. We've asked them to strike it. [Realistic assessment: "They'll
probably agree" / "This might be a sticking point — will keep you posted."]

**What you need to do:**
- [ ] Nothing yet — I'll let you know when it's back from them.
  OR
- [ ] [Business decision they need to make: "If they won't budge on X, are you
  okay with Y, or do we walk?"]

Handoffs

From vendor-agreement-review / saas-msa-review: Those skills produce the full memo. This skill reads the memo and compresses it. Don't re-review the contract — read the review.

To the stakeholder: Via whatever channel ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md says. If Slack, keep it under 150 words. If email, the format above is fine as-is.

Escalation-fan-out reconciliation

The upstream review is a one-to-many producer: it can name five escalation targets (Deputy GC, CISO, Privacy Officer, CFO, business owner) across different findings. escalation-flagger routes one finding at a time. Without a reconciliation step, the Deputy GC sees the memo and the other four approvers never do.

Before producing the summary, read the upstream review memo and tally escalations:

1. Count the escalation targets the review named. Look for the routing / escalation block at the end of the review, or for per-finding "escalate to [X]" tags. De-dupe by approver name — a reviewer named for two findings counts once.
2. Count the escalations actually routed. Read the review folder (or matter folder) for escalation-*.md drafts produced by escalation-flagger since the review was written. Each draft names one approver.
3. Reconcile. If N approvers were named and M drafts exist, (N − M) escalations have not been routed.

Include a short reconciliation block in the summary — above the checklist, below the catch paragraph:

**Escalation status:** [M] of [N] escalation targets routed. The following have not been routed and require action:
- [Approver name] — [one line on the finding that named them]
- [Approver name] — [one line]

If all N have been routed:

**Escalation status:** [N] of [N] escalation targets routed.

If the upstream review surfaced no escalations, omit the block.

Do not omit a named approver from the reconciliation because the stakeholder wouldn't recognize the name. Business stakeholders often do not know who the Privacy Officer or CISO is. The reconciliation is internal-facing — it tells the lawyer sending the summary whether all the routing is done, not the stakeholder. If the stakeholder-facing summary needs to stay narrow, the reconciliation can live in a "routing status" footer or attached note — but it has to exist. A summary that implies routing is complete when it is not is worse than no summary.

Word-count carve-out. The escalation reconciliation block is exempt from the 200-word cap. Length-cap discipline on the summary body stays; the reconciliation is housekeeping, not narrative.

When no escalation-flagger drafts exist. If the upstream review named approvers and no drafts are in the folder, treat the count as M = 0. The reconciliation block lists all N as unrouted. That is the finding.

A note on tone

Stakeholders remember two things about legal: did it block me, and did it make sense. This skill is how legal makes sense. Write like you're explaining it to a smart colleague over coffee, not like you're writing a memo to file.

If the honest summary is "this is fine, sign it," say that. Don't pad a clean review into three paragraphs to look thorough.

Vendor Agreement Review

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /commercial-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Destination check

Before producing output, check where it's going. If the user has named a destination (a channel, a distribution list, a counterparty, "everyone"), ask whether it's inside the privilege circle. Public channels, company-wide lists, counterparty/opposing counsel, vendors, and clients (for work product) waive the protection. When the destination looks outside the circle, flag it and offer (a) the privileged version for legal only, (b) a sanitized version for the broader channel, or (c) both — don't silently apply a privileged header and then help paste it somewhere the header won't protect it. See the canonical ## Shared guardrails → Destination check in this plugin's CLAUDE.md.

Purpose

Read a vendor agreement against the playbook this team actually uses (in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md), find every term that deviates, and tell the lawyer what to do about each one — with specific redline language, not vague "consider revising."

The output is a review memo the lawyer can act on in one pass. Every issue has a severity, a business-impact explanation, a proposed fix, and an escalation call if one is needed.

Precondition: load the playbook

Before reading the contract, read ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If it's missing or still has placeholders, surface this bounce:

I notice you haven't configured your practice profile yet — that's how I tailor playbook positions, escalation, and house style to your practice.

Two choices:

• Run /commercial-legal:cold-start-interview (2 minutes) to configure your profile, then I'll review tailored to YOUR playbook.
• Say "provisional" and I'll review against generic defaults — US jurisdiction, middle risk appetite, lawyer role, no playbook (flag all common vendor-contract risks from first principles) — and tag every output [PROVISIONAL — configure your profile for tailored output] so you can see what I do before committing.

Provisional mode

If the user says "provisional," run the review normally using these generic defaults: middle risk appetite, lawyer role, US jurisdiction, no playbook (flag the common vendor-side risks from first principles — unlimited liability, no data-breach carveout, uncapped indemnity, auto-renewal without notice, etc. — rather than matching to configured positions). Tag the reviewer note and every finding block with [PROVISIONAL]. At the end of the output, append:

"That was a generic run against default assumptions. Run /commercial-legal:cold-start-interview to get output calibrated to YOUR practice — your playbook, your jurisdiction, your risk appetite. 2 minutes."

Which side? Before applying the playbook, determine which side the company is on for this contract. Usually obvious: if the counterparty is a vendor/supplier providing goods or services, you're purchasing-side. If the counterparty is a customer buying your product/service, you're sales-side. If it's not obvious (a reseller agreement, a partnership, a revenue share), ask: "Which side is [company] on for this agreement — vendor or customer?" Read the matching playbook section (### Sales-side playbook or ### Purchasing-side playbook) from the config. Note which side in the output so the reviewer knows which playbook was applied. If the matching side is [Not configured], stop and tell the user to run /commercial-legal:cold-start-interview --side <side> before this review can proceed.

This skill is typically used for purchasing-side contracts (vendors supplying you), but the side check still applies — a "vendor agreement" could be your own template sent to a vendor as part of a reseller arrangement (sales-side).

The playbook in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md is the source of truth. It tells you:

• What this team's standard positions are (not market standard — their standard)
• What fallbacks they've accepted before
• What they never accept
• Who approves what
• The one deal-breaker to check first

If the contract has the deal-breaker, flag it at the top of the memo and stop the detailed review. There's no point spending 30 minutes on liability caps if the agreement gives the vendor rights to use customer data for training.

Workflow

Step 1: Orient

Read the whole agreement once, fast. Answer:

Dollar-value handling. If the main agreement does not state a dollar value (the MSA sets terms but the Order Form carries price, which is typical), stop and ask before running escalation math or applying dollar thresholds:

The MSA itself doesn't state an annual contract value. The Order Form carries the price. Your escalation threshold is $[X from the matrix]. Before I route this, I need the ACV. Options:

1. Paste the Order Form value (preferred — I'll use it for routing and the memo).
2. Tell me if this is above or below $[threshold] and I'll route accordingly; the memo will flag that the routing assumed [above/below threshold] without an ACV in hand.
3. Route conservatively to the higher approver regardless — safer for a review you haven't priced.

Do NOT silently assume a value and then use the assumed value to drive routing. The assumption propagates into the approval call, which is a place the review shouldn't be guessing.

DPA-by-reference handling. If the main agreement incorporates a DPA "available at [URL]" or "as set forth at [URL]" or similar by reference, the DPA is part of the contract but is not in front of you. Note it explicitly in the Orient table and in the review memo:

This agreement incorporates a DPA by URL reference at [URL]. The DPA carries the real data terms — subprocessor rights, breach-notification timing, data-return mechanics, standard contractual clauses, audit rights. Without reading it, the data-protection analysis below is partial. Offer to route the DPA to /privacy-legal:dpa-review (if installed) for a separate review, or fetch and read it inline before completing Step 3's data-protection analysis.

If the user is installed with privacy-legal, explicitly offer:

Want me to hand the DPA URL to /privacy-legal:dpa-review once you're ready? That skill is built for the DPA work and will catch subprocessor / SCC / breach-notification issues that this skill only flags at the gate.

Do not silently proceed as if the DPA were absent when it is incorporated by reference. A missing DPA and an unread DPA are different gaps — label them differently.

Step 2: Deal-breaker check

Check the "one thing" from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md first. If present:

## ⛔ DEAL-BREAKER PRESENT

**Section [X.X]** contains [the deal-breaker]. Per the team playbook, this is a
hard no. Recommend:

- [ ] Push back — propose [specific alternative language]
- [ ] Walk — if counterparty won't move, we don't sign

Detailed review below is provided for completeness but is moot unless this is
resolved.

Step 3: Term-by-term comparison

For each playbook category in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md, find the corresponding contract section and compare.

For each deviation, produce:

### [Section X.X]: [Issue name]

**Playbook says:** [our standard position, quoted from `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`]

**Contract says:**
> "[exact quote from the contract]"

**Gap:** [Missing term | Weaker than standard | Weaker than fallback | Non-standard structure | Unacceptable]

**Legal risk:** 🔴 Critical | 🟠 High | 🟡 Medium | 🟢 Low
**Business friction:** 🔴 Blocks deals | 🟠 Slows deals | 🟡 Confuses customers | 🟢 Invisible

**Why it matters:** [one or two sentences in plain English — what goes wrong
for the business if this term stays as-is]

**Proposed redline:**
> "[the specific replacement language — ready to paste into a markup]"

**If they won't move:** [the fallback from `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`, or "escalate to [person]"
if no fallback exists]

Severity calibration:

Severity is always applied against ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If a term doesn't map cleanly to a playbook position, ask the user which bucket it belongs in and offer to record the answer in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md.

Liability cap decision procedure

The cap amount is the least important part of the cap. When reviewing the limitation-of-liability clause, do not produce a single "check liability cap against playbook" line item. Work through the four dimensions below and state each one explicitly in the finding:

1. Direct vs. indirect/consequential damages. Does the cap apply to ALL liability, or only direct damages? A 12-month cap on direct damages with uncapped consequential damages is a completely different position than a 12-month aggregate cap. State both treatments explicitly.

2. The cap base — quote it verbatim. "12-month cap" could mean: (a) fees paid in the 12 months preceding the claim, (b) fees payable in the current 12-month period, (c) fees over the last 12 months of usage, (d) fees under the current order form, (e) total fees ever paid. These can differ by an order of magnitude. Quote the exact language. If ambiguous, flag it: "Cap base is ambiguous — [the quoted language] — could mean [X] or [Y]. Confirm before signing."

3. Cap-carveout interaction. A $100K cap with uncapped indemnity for data breach, IP, and confidentiality is functionally uncapped for the claims that actually arise in SaaS disputes. Enumerate what sits ABOVE the cap (the carveouts), what sits BELOW (what's actually capped), and assess whether the capped surface is meaningful: "The cap covers [general contract breach]. Data breach, IP indemnity, and confidentiality are carved out and uncapped. For this vendor's risk profile, the capped surface is [meaningful / nominal]."

4. Your playbook position per dimension. The practice profile should have positions for: direct cap (multiple of fees), indirect damages (excluded / capped / uncapped), carveout list (what's acceptable above the cap), and cap base (which definition you'll accept). If the playbook has one "standard position" field, note: "Your playbook has a single cap position — consider splitting into direct/indirect/carveouts/base for more precise review."

Jurisdiction delta check

The playbook applies one governing-law preference globally. Enforceability varies materially. Check the contract's actual governing law against the top divergences before accepting playbook positions at face value:

• Non-solicits/non-competes: Unenforceable in CA (Bus. & Prof. Code §16600). Restricted in many EU jurisdictions. Enforceable with limitations elsewhere. [jurisdiction — verify]
• Auto-renewal: CA GBL §17600-17606, NY GBL §527-a, IL 815 ILCS 601 have specific consumer/B2B notice requirements. Other states vary. [jurisdiction — verify]
• Liability exclusions: EU and UK unfair contract terms rules (UCTA 1977, Consumer Rights Act 2015) constrain consumer exclusions. Some US states limit exclusion of gross negligence or willful misconduct. [jurisdiction — verify]
• Indemnification: Some states void indemnification for the indemnitee's own negligence. [jurisdiction — verify]
• Confidentiality term: Some jurisdictions limit "perpetual" confidentiality to a reasonable period. [jurisdiction — verify]

When the playbook position conflicts with the contract's governing-law enforceability, flag: "Your playbook prefers [X], but this contract is governed by [Y] law where [X] is [unenforceable / restricted / subject to statutory override]. [jurisdiction — verify]"

Step 4: Favorable terms and gaps

Two short lists:

Better than our standard: Terms where the vendor gave us more than we'd ask for. Note these — they're trade bait if you need to give something up elsewhere.

Missing entirely: Standard provisions that just aren't there. Most common: assignment restrictions, audit rights (if we want them), force majeure, insurance requirements.

Step 5: Escalation routing

Check the escalation matrix in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md against:

• Contract dollar value
• Presence of any 🔴 critical issues
• Any automatic-escalation triggers (unlimited liability, IP assignment, etc.)

State clearly who needs to approve this:

## Approval routing

Based on [dollar value / issue severity], this agreement requires:

- [ ] **[Name/role]** approval — [reason]
- [ ] **Business owner sign-off** on [specific commercial term they should weigh in on]

**Recommended next step:** [Send redlines to counterparty | Escalate to GC before
responding | Get business input on commercial term X before legal responds]

Before proceeding to send redlines to the counterparty: Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If the Role is Non-lawyer:

Sending redlines is a legal act — the counterparty will treat every edit as our negotiating position. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:

[Generate a 1-page summary: counterparty, agreement type, the specific redlines proposed, the playbook positions behind each, the fallbacks, and what to ask the attorney before the package leaves.]

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: contact your professional regulator (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent) for a referral service.

Do not proceed past this gate without an explicit yes.

Redline granularity

Edit at the smallest possible granularity. A redline is a negotiation artifact, not a rewrite. Wholesale clause replacement signals "we threw out your drafting" — it's aggressive, it forces the counterparty to re-read the whole clause, and it discards the parts of their drafting that were fine. Surgical redlines — strike a word, insert a phrase, restructure a subclause — signal "we have specific asks" and are faster to read, understand, and accept.

Default to the smallest edit that achieves the playbook position:

• Replace a word before a phrase. ("twelve (12)" → "twenty-four (24)")
• Replace a phrase before a sentence. ("paid by the Buyer" → "paid and payable by the Buyer")
• Restructure a subclause before replacing the sentence. (Add "(a)" and "(b)" to split a compound condition.)
• Replace a sentence before replacing the clause.
• Only replace a whole clause when the counterparty's version is so far from your position that surgical edits would be harder to read than a fresh draft — and when you do, say so in the transmittal: "We've replaced §8.2 rather than marking it up because the changes were extensive. Happy to walk you through the delta."

When in doubt, smaller. A client who receives a surgical redline trusts that you read carefully. A client who receives a wholesale replacement wonders whether you read at all.

Step 6: Assemble the memo

Prepend the work-product header from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md ## Outputs (it differs by user role — see ## Who's using this).

This memo and the underlying agreement may be privileged, confidential, or both. The output inherits that status from the source. Distribute only within the privilege circle; mark and store it where privileged materials live; strip the work-product header before any external delivery (e.g., counterparty redlines, stakeholder summaries).

The playbook positions applied below reflect the jurisdiction recorded in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → Governing law and venue. Legal rules and enforceability vary materially by jurisdiction. If this deal implicates a different governing law or a choice-of-law question, flag it in the memo — the analysis may not transfer as written.

No silent supplement. If a research query to the configured legal research tool returns few or no results for a rule the memo needs (enforceability of a limitation clause, indemnity scope, governing-law choice), report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [rule / jurisdiction]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged [web search — verify] and should be checked against a primary source before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources.

Source attribution. Where the memo cites a statute, regulation, or case, tag the citation: [Westlaw], [statute / regulator site], or the MCP tool name for citations retrieved from a legal research connector; [web search — verify] for web-search citations; [model knowledge — verify] for citations recalled from training data; [user provided] for citations from the counterparty draft or house files. Citations tagged verify carry higher fabrication risk and should be checked first. Never strip or collapse the tags.

[WORK-PRODUCT HEADER — per plugin config ## Outputs]

# Vendor Agreement Review: [Counterparty] [Agreement Type]

**Reviewed:** [date]
**Contract value:** $[amount] / [term]
**Our role:** Customer

---

## Bottom line

[Two sentences. Can we sign this? What has to change first?]

**Issues (legal risk):** [N]🔴 [N]🟠 [N]🟡 [N]🟢
**Issues (business friction):** [N]🔴 [N]🟠 [N]🟡 [N]🟢

**Approval needed from:** [name]

---

## Deal-breaker check

[✅ Clear | ⛔ Present — see above]

---

## Issues by severity

[All the deviation blocks from Step 3, grouped Critical → Low]

---

## Favorable terms

[list]

## Missing provisions

[list]

---

## Approval routing

[from Step 5]

---

## Redline package

[If requested: consolidated markup-ready language for all proposed changes]

Integration: [CLM]

If a [CLM] MCP is connected, after the review:

• Check if this counterparty already has agreements with us (may inform negotiating posture — "we already gave them 24-month cap on the last deal")
• Pull the workflow template that matches this agreement type
• Offer to create the [CLM] record with the review memo attached and approvers pre-routed

Integration: DocuSign

If DocuSign MCP is connected and the agreement is ready to sign (all greens or all issues accepted), offer to:

• Generate the envelope
• Route to signers in the right order per the escalation matrix

Do not send anything for signature without explicit instruction. "Ready to sign" is the lawyer's call, not yours.

Before generating a signature envelope or routing for countersignature: Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. If the Role is Non-lawyer:

This step has legal consequences (signing binds the company to the whole agreement). Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:

[Generate a 1-page summary: counterparty, contract value, the issues found and how they resolved, any risk the lawyer accepted, and what to ask the attorney before envelope goes out.]

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: contact your professional regulator (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent) for a referral service.

Do not proceed past this gate without an explicit yes.

Output formats

Full memo (default): As above. Goes in the [CLM] record or the Drive folder from ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md house-style section.

Slack-sized summary: Two lines and a link. For when someone asks "is this okay?" in a channel.

[Counterparty] [type] — NEEDS WORK. 1🔴 (uncapped liability §8.2), 2🟠. Full review: [link]. Needs [GC] approval.

Redline doc: If the user asks for it, output a .docx with tracked changes. Use the docx skill. Comments on each change cite the playbook position.

Quality checks before delivering

• ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md was loaded and quoted — not generic market positions
• Deal-breaker checked first
• Every issue has specific replacement language
• Risk levels are calibrated (not everything is Critical)
• Approver is named, not "escalate to legal"
• Counterparty context considered (BigCo vs. startup — affects what's worth fighting over)

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

AI Tool Handoff

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /corporate-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

Luminance and Kira are good at one thing: reading 500 contracts and finding every change-of-control clause. They're less good at judgment — deciding whether a particular CoC provision is actually triggered by this deal structure.

This skill hands off the bulk extraction to the right tool, then runs the QA layer on what comes back.

Before you hand off: try tabular-review first (/corporate-legal:tabular-review). For anything the user's environment can handle — a few hundred documents, a defined column schema — native tabular review is faster to set up, has no per-document cost, and keeps the work product local. Hand off to Luminance/Kira when the corpus is genuinely too large, the team already has a license and workflow, or the matter requires a tool with a validated provenance chain.

Load context

~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → AI-assisted review:

• Tool in use (Luminance / Kira / none)
• What it's used for (which clause types)
• Trust level (use as-is / spot-check / full re-review)
• Handoff process (who loads, who QAs)

If ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md says no AI tool → this skill is a no-op. Everything goes through diligence-issue-extraction directly.

When to hand off

Hand off when all of:

• Category has >50 documents (below that, faster to just read them)
• Extraction target is a clause type the tool is good at (CoC, assignment, exclusivity, MFN, termination, auto-renewal)
• Documents are reasonably uniform (all customer contracts on similar paper — not a mix of contracts, letters, and board minutes)

Don't hand off:

• Bespoke or heavily negotiated documents
• Side letters and amendments (context-dependent, tools miss the interaction with the main agreement)
• Anything where the question is "what does this mean for the deal" not "does this clause exist"

The handoff

Step 1: Prepare the batch

• Identify documents for the batch (from VDR inventory)
• Specify extraction targets per ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md (which clause types)
• Note the materiality threshold so tool output can be filtered

Step 2: Load (or instruct the loader)

Per ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md — who loads. If it's you, generate the load instructions. If it's someone else, generate the request:

## [Tool] Load Request — [Deal code] — [Category]

**Documents:** [N] docs from VDR folder [path]
**Load to:** [Tool workspace/matter]
**Extraction targets:**
- Change of control / assignment
- Exclusivity
- [etc. per `~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md`]

**Filter output:** Flag only where extraction target is present — no need for "no CoC clause found" for every doc.

**Return by:** [date]

Step 3: QA the output

When the tool returns results, apply the trust level:

"Use as-is": Ingest directly into diligence findings. (Only if ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md says this — it's rare.)

"Spot-check X%": Randomly sample X% of flagged documents. For each, read the actual clause and compare to the tool's extraction. If error rate is low, accept the batch. If errors found, widen the sample.

"Full human review of flagged": Tool narrows the universe (500 docs → 80 with CoC clauses). Human reads all 80. Tool saved the time of reading the 420 clean ones.

Step 4: Judgment layer

The tool found the clauses. Now apply judgment:

For each flagged CoC provision: is it actually triggered by this deal?

• Stock sale vs. asset sale vs. merger — different triggers
• "Change of control" defined how in the contract — majority ownership? board control? something else?
• Is there a carve-out for this type of transaction?

This is the part the tool can't do. Output goes to diligence findings in house format.

Output

The QA summary below is derived from VDR documents that are privileged, confidential, or both. It inherits the sources' privilege and confidentiality status — distribution beyond the privilege circle can waive privilege. Store with the matter's privileged files.

## AI Tool Handoff Summary — [Category]

**Tool:** [Luminance / Kira]
**Documents processed:** [N]
**Extraction targets:** [clause types]

### QA

**Trust level:** [per `~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md`]
**Sample size:** [N] docs spot-checked
**Error rate:** [X]% — [Accepted / Widened sample / Full re-review triggered]

### Results

| Clause type | Docs flagged | After judgment layer | Material |
|---|---|---|---|
| Change of control | [N] | [N actually triggered by deal structure] | [N above threshold] |
| Assignment | [N] | [N] | [N] |

**→ [N] findings added to diligence issues**
**→ [N] consents added to closing checklist**

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

What this skill does not do

• It doesn't run Luminance or Kira — it manages the handoff and QA. A human (or the tool's own interface) runs the extraction.
• It doesn't replace the tool's output with its own judgment entirely — if ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md says spot-check 10%, check 10%, not 100%.
• It doesn't decide the trust level — that's in ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md, set at cold-start based on the team's experience with the tool.

Board Minutes

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /corporate-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

Board minutes are a legal record. They need to be accurate, complete, and in a format that will hold up under scrutiny — whether that's a financing due diligence review, a regulatory inquiry, or an M&A data room. This skill drafts them in your house format so you spend your time reviewing and correcting, not formatting and re-typing.

Load context

• ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → ## Board & Secretary section:
  • Minutes format (long-form narrative / action minutes / hybrid)
  • Minutes template extracted from seed documents (structure, resolution language, header format)
  • Board composition and committees
  • Written consents — what they're used for and any limits
• If ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md has no minutes format: run cold-start first. Do not proceed with a generic format.

Step 1: Identify the meeting

Calendar detection

If the calendar connector is authorized, search for upcoming events matching board and committee keywords:

Search terms: "Board of Directors", "Board Meeting", "Audit Committee", "Compensation Committee", "Comp Committee", "Nominating", "Nom/Gov", "Governance Committee", "Special Committee", "Board of Directors — [Company]"

Time window: Look 30 days forward. If no upcoming meeting is found, look 14 days back (minutes are often drafted after the fact).

Present what you find:

I found the following board or committee meetings on your calendar:

1. [Meeting name] — [Date], [Time], [Location/Virtual]
2. [Meeting name] — [Date], [Time], [Location/Virtual]

Which one are these minutes for? Or is it a different meeting not on here?

If the calendar connector is not authorized or returns nothing: ask directly — what meeting, what date, what type (full board / which committee)?

Meeting metadata to confirm

Once the meeting is identified, confirm or fill in:

• Meeting type: Full Board of Directors / [Committee name]
• Date and time
• Location or platform (in-person address / Zoom / Teams / telephonic)
• Called by / Notice: Was proper notice given? (Yes / waived — waiver of notice is a common exhibit)

Step 2: Attendance

Ask for the attendee list, or offer to pull from the calendar invite if the connector is authorized.

Directors present:

• Pull from board composition in ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md as the starting point
• Ask who was actually present, who was absent, and whether any absent directors had advance notice

Management present:

• Who from management attended? (CFO, CAO, CTO, etc.)
• Note: management attendees are typically listed separately from directors

Guests:

• Outside counsel present? (Name and firm)
• Investment bankers, auditors, or other advisors?
• Any guests who attended for specific agenda items only (note their attendance as limited to that item)

Chair:

• Who chaired the meeting?
• Who acted as secretary?

Quorum:

• Check the charter and bylaws for the quorum requirement. If the charter is silent, research the applicable state corporate law for the default rule for this entity type. Record what you confirmed (source and pinpoint) in the drafting notes.
• Confirm quorum was present. If not: stop and flag before drafting. Do not produce minutes that imply a valid meeting occurred. Surface the question to outside counsel — the remediation path (ratification, re-meeting, written consent, other) depends on the state of incorporation and the nature of the action.

Step 3: Materials

Ask for the meeting materials. These are the source for the agenda items and any resolutions.

Can you share the agenda and any pre-read materials for this meeting? Even a rough agenda is enough to structure the minutes. If there were board slides or a management presentation, upload those too — I'll use them to fill in the agenda item summaries.

If materials weren't distributed in advance, tell me the agenda items and I'll draft placeholders for each.

From the agenda and slides, extract:

• Agenda items in order
• Any resolutions proposed (look for board approval language: "approve," "authorize," "ratify," "adopt," "elect")
• Any exhibits referenced (management presentations, financial reports, legal memos, valuations)
• Any votes expected

If no materials: Ask for the agenda items verbally and proceed with placeholders for discussion content.

Step 4: Draft the minutes

Use the house format from ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md. Do not default to a generic format. The seed minutes are the template — replicate the structure, the header, the resolution language, the level of discussion detail.

Standard structure (adapt to house format)

Header block:

MINUTES OF [MEETING TYPE] OF THE BOARD OF DIRECTORS
[OR: MINUTES OF THE [COMMITTEE NAME] OF THE BOARD OF DIRECTORS]
OF [COMPANY NAME]

[Date]
[Location / Telephonic / Video Conference]

Opening:

• Meeting called to order by [Chair name] at [time]
• Notice: [proper notice given / notice waived — attach waiver as exhibit if applicable]
• Quorum confirmed: [N of M directors present]
• Secretary: [name]

Attendees:

• Directors present: [list]
• Directors absent: [list, if any]
• Also present: [management, outside counsel, guests — with roles]

Previous minutes: Standard language: approval of minutes from prior meeting. Pull date of prior meeting from ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md board calendar if available, otherwise leave as [DATE OF PRIOR MEETING].

Agenda items — one section per item:

[AGENDA ITEM TITLE]

[Chair/presenter name] [presented / reported on / led a discussion of] [topic].

[Discussion summary — see drafting notes below]

[If resolution follows:]
Upon motion duly made and seconded, the following resolution was adopted [by unanimous vote / by a vote of N for, N against, N abstaining]:

RESOLVED, that [resolution text in house language from `~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md`].

Adjournment: Standard language: meeting adjourned at [time], there being no further business.

Signature block: Secretary signature line. Some formats include a chair countersignature.

Drafting notes

Discussion summaries: The hardest part of minutes is deciding how much discussion to capture. Follow the house format from seed documents exactly:

• Long-form narrative: Summarise the substance of the discussion — what questions were raised, what information was presented, what factors the board considered. Do not quote individuals unless the specific attribution matters legally.
• Action minutes: Note only what was presented and what action was taken. No discussion content beyond "the board discussed the matter."
• Hybrid: Full narrative for major items (acquisitions, financials, significant approvals), action-only for routine items.

When materials were provided: pull summary content from the slides and management presentation. The board "received and reviewed" a presentation — summarize what the presentation covered.

When no materials: insert [PLACEHOLDER — summarize discussion here] and flag it clearly. Do not fabricate discussion content.

Resolutions: Use the exact resolution language from the seed minutes — "RESOLVED, THAT" vs. "BE IT RESOLVED" vs. "RESOLVED" alone. The language is house style, not interchangeable.

Exhibit references: Number exhibits in the order they appear (Exhibit A, B, C). Common exhibits: management presentation, financial statements, valuation reports, legal opinions, waivers of notice, consents.

Step 4.5: Consequential-action gate (adopt minutes)

Before adopting minutes as final: Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md. If the Role is Non-lawyer:

Adopting minutes makes them the official record of what the board decided — they're the primary evidence of authorization for the actions taken at the meeting. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:

• What was decided (resolutions, votes, who was present)
• What the draft captures and what is still a placeholder
• Open questions (any flagged attendance, quorum, or conflict notes)
• What could go wrong (misstated resolutions, missing disclosures, quorum defects, privilege leakage in discussion summaries)
• What to ask the attorney (is the discussion depth right for this board's practice; are exec-session notes properly segregated; do any items need more documentation)

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: contact your professional regulator (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent) for a referral service.

Do not produce the final adoption-ready version past this gate without an explicit yes. A marked-DRAFT for attorney review is fine.

Step 5: Output and review prompts

Produce the full draft. The minutes themselves are a corporate record, not privileged; do not apply the work-product header to the minutes as circulated. The drafting notes, placeholder flags, and review checklist below are work product — prepend the work-product header from ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md ## Outputs (it differs by user role — see ## Who's using this):

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

After the draft, add a review checklist:

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

REVIEW CHECKLIST — please verify before circulating:

□ All directors confirmed present/absent (check against actual attendance)
□ Quorum confirmed correct
□ Resolution language matches what was actually approved (check wording carefully)
□ Votes recorded correctly — any abstentions or dissents to note?
□ Exhibits numbered and referenced correctly
□ Any executive sessions held? (Add separate executive session note if so)
□ Any conflicts of interest disclosed? (Director recusal to note if applicable)
□ Time of adjournment to fill in
□ Outside counsel reviewed? (If required by your process)

Flag any sections where content is a placeholder and needs the attorney's input before the minutes are accurate.

Add as a final pre-adoption note on the draft, stripped before adoption:

This is a draft for attorney review, not adopted minutes. Adopted minutes are the official record of board action and carry legal consequences — a licensed attorney reviews, edits, and takes professional responsibility before adoption. Do not adopt this draft unreviewed.

Written consents

For drafting written consents in lieu of a meeting, use /corporate-legal:written-consent. That skill handles precedent search, state-law confirmation, and the scope warning for major one-off actions.

What this skill does not do

• It does not attend the meeting or capture real-time discussion — it drafts from materials and attorney input.
• It does not determine whether a resolution is legally valid or sufficient — it drafts in house format; legal judgment on adequacy is the attorney's call.
• It does not finalize minutes — the draft requires attorney review before circulation.
• It does not distribute minutes — output is for the attorney to review, edit, and circulate via their own process.

/closing-checklist

1. Read ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/closing-checklist.yaml and use the modes below.
2. If status update provided: Mode 3 (update item).
3. Otherwise Mode 4: blocking items, critical path, days to close.

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /corporate-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

Deals close when the checklist is done. Everything on it, done. Nothing missing. This skill maintains the list, ingests new items as they surface from diligence, and tells the team what's blocking.

The checklist

Lives at ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/closing-checklist.yaml. Structure:

deal_code: "Project Falcon"
target_close: [DATE]
signing_date: [DATE]
last_updated: [DATE]

conditions_precedent:
  - id: CP-001
    item: "HSR waiting period expiration"
    category: "Regulatory"
    responsible: "Buyer counsel"
    due: 2026-04-15
    status: "Filed 2026-03-01, waiting period runs"
    blocking: true
    source: "Purchase Agreement §7.1(a)"

  - id: CP-002
    item: "Acme Corp consent to assignment"
    category: "Third-party consents"
    responsible: "Target — Jane Doe"
    due: 2026-04-20
    status: "Request sent 2026-03-10, no response"
    blocking: true
    source: "Schedule 3.12(a)(4); Acme MSA §14.2"

closing_deliverables:
  - id: CD-001
    item: "Certificate of good standing — Target (DE)"
    category: "Corporate"
    responsible: "Target counsel"
    due: 2026-04-28
    status: "Not started"
    blocking: true
    source: "Purchase Agreement §2.3(b)(iv)"

  # ... etc

Modes

Mode 1: Initialize from the purchase agreement

Read the signed (or near-final) purchase agreement. Extract:

• Every condition precedent (location varies by agreement — read the actual section headings)
• Every closing deliverable (closing deliverables schedule or corresponding section)
• Every covenant with a pre-closing deadline

Each becomes a checklist item with a source cite to the agreement section.

Research obligations before populating regulatory/approval items. Antitrust, foreign-investment, and sector-specific approvals (for example, HSR-style filings, CFIUS, industry regulators) have jurisdiction-specific mechanics, thresholds, and timing windows that change. Extract the name of each regulatory condition from the PA, then research the currently operative mechanics (who files, when, what triggers a second request, what the waiting period is). Cite primary sources and verify currency. Do not populate a timing assumption from memory.

Material-adverse-effect / material-adverse-change closing conditions. Pull the defined term from the PA — MAC/MAE framing is negotiated, not a standard. Research the governing-law interpretation of the specific language used (Delaware, New York, and other jurisdictions treat carve-outs and quantitative tests differently) before flagging an event as a potential MAC trigger.

Consent-requirement extraction from material contracts depends on governing-law default rules and the specific anti-assignment language in each contract. Research the applicable rule per contract rather than assuming a default.

Mode 2: Ingest from diligence (the "self-updating" part)

Mode 2 is triggered when an upstream skill produces a finding with a pre-closing action. The upstream skills and output types this mode ingests:

• diligence-issue-extraction findings — any finding flagged for a closing action (consent, shareholder vote, board resolution, regulatory filing, release, escrow mechanic, pay-off letter). Not just "consents" — see the extraction skill's Handoffs section for the full list.
• material-contract-schedule CoC / assignment items — change-of-control provisions, anti-assignment clauses, MFN triggers surfaced during schedule build.
• deal-team-summary output — the exec-tier brief aggregates extraction findings and sometimes surfaces a closing-action item that a mechanical read of the individual extraction memos would miss (e.g., a §280G cleansing vote rolled up across multiple employment agreements, or a composite consent package). Mode 2 reads the latest deal-team-summary in the deal folder and reconciles its closing-action items against the checklist. Anything flagged by deal-team-summary as requiring pre-closing action that is not already on the checklist is appended.

The handoff schema covers the full range of pre-closing actions, not just consents:

handoff:
  # Required fields
  item: "[Counterparty or action, one line]"
  category: "[Third-party consents | Shareholder / board action | Regulatory filing | Release / termination | Escrow / holdback | Closing deliverable]"
  source: "[Contract name / statutory section / VDR path + Bates]"
  blocking: true  # unless the agreement has a materiality qualifier
  severity: "[🔴 / 🟠 / 🟡 / 🟢 — carried from upstream, see severity-floor rule in CLAUDE.md]"

  # Consent / third-party action fields
  counterparty: "[e.g., Dunmore Holdings LLC]"
  guarantor: "[e.g., Buyer parent guaranty required, or N/A]"
  conditions: "[any substantive condition the counterparty attached — e.g., 'replacement guaranty from buyer parent required before consent effective']"
  notice_deadline: "[e.g., 30 days prior to closing, or specific date]"

  # Corporate action fields
  approval_body: "[Shareholders | Board | Committee | Regulator]"
  approval_threshold: "[e.g., 75% disinterested stockholder vote for §280G cleansing]"
  statutory_or_charter_source: "[e.g., IRC §280G(b)(5)(B); Charter Art. IV §2]"

  # Timing
  estimated_time_to_complete: "[e.g., 30 days]"
  must_occur_before: "[e.g., closing | signing | end of hiatus period]"

Preserve every field the upstream skill populated. A "Dunmore consent required, with replacement guaranty condition and 30-day notice" should surface on the checklist with all three elements (consent, guarantor, notice), not collapse to "Dunmore consent to change of control." When the upstream skill provides a severity, carry it — see the cross-skill severity floor rule in ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md.

Append to the checklist. De-dupe on (counterparty + action type), not on the freeform item name — a Dunmore consent and a Dunmore release are different items even though both name Dunmore. When de-duping, merge fields rather than overwrite: if one handoff populated guarantor and a later handoff populated notice_deadline, the checklist row carries both.

Mode 3: Status update

User (or dataroom-watcher agent) provides a status update. Find the item, update status and last-updated.

/corporate-legal:closing-checklist
CP-002: Acme responded, consent form attached, needs countersignature

Mode 4: What's blocking

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

> This status report is derived from the purchase agreement, diligence findings, and internal deal records. It inherits their privilege and confidentiality status — distribution beyond the privilege circle (counterparty, broader business teams) can waive privilege. Confirm the distribution list before sending.

## Closing Checklist Status — [Deal code] — [date]

**Target close:** [date] ([N] days out)
**Items:** [N] total — [N] done, [N] in progress, [N] not started

### 🔴 Blocking and at risk

| ID | Item | Due | Status | Days to due |
|---|---|---|---|---|
| [CP-XXX] | [item] | [date] | [status] | **[N]** |

### 🟡 Blocking, on track

[same table]

### ✅ Complete

[N] items — [collapsed list]

### Not blocking (post-closing, informational)

[N] items

---

**Critical path:** [The item(s) that, if they slip, push the close date]

Critical path analysis

Not all blocking items are equal. A consent that takes 30 days to get is critical path. A good-standing certificate that takes 2 days is not, even though both are blocking.

For each blocking item, estimate time-to-complete. The ones where (due date - today) < estimated time are at risk. Those go at the top of every status report.

If the checklist has more than ~10 items, or any time the user asks: offer the dashboard (see CLAUDE.md ## Outputs → Dashboard offer for data-heavy outputs). Shape the offer for this output — counts by status (done / in progress / not started / at risk), a critical-path view grouped by workstream, and a sortable grid with item, owner, due date, and days-to-due.

Integration: dataroom-watcher agent

The agent checks the checklist daily, pulls any status updates from email/Slack if connected, and posts the "what's blocking" report to the deal team channel. Mode 4 is the agent's output.

Consequential-action gate (certify closing)

Before producing a "ready to close / all CPs satisfied" certification or closing memo: Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md. If the Role is Non-lawyer:

Certifying that closing conditions have been satisfied (or producing a closing memo asserting this) has legal consequences — it's the signal that drives funds flow and post-closing obligations. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:

• The full CP list with status (what's done, what's in progress, what's not started)
• Anything where evidence of completion is weak or missing
• Any waivers or side letters needed for items that won't close in time
• Open questions (counterparty consents still pending, any MAC/bring-down risk)
• What to ask the attorney (is this ready to call closed; are any conditions being walked past that shouldn't be; what needs to go on a schedule of exceptions)

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: contact your professional regulator (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent) for a referral service.

Do not produce a final "ready to close" certification past this gate without an explicit yes. Status tracking and "what's blocking" reports do not require the gate.

What this skill does not do

• It doesn't obtain consents, file forms, or draft documents. It tracks that they need to happen.
• It doesn't decide what's blocking — the purchase agreement decides that. This skill reads the agreement.
• It doesn't close the deal. It tells you when you can.

/cold-start-interview

1. Check ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md. If --new-deal, skip to per-deal setup. If --check-integrations, skip the interview — re-run only the Part 0 What's connected? check and rewrite the ## Available integrations table in ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md. When probing: only report ✓ if an MCP tool call actually succeeded. Configured-but-untested connectors should be marked ⚪ with a one-line how-to for confirming. Never report ✓ based on .mcp.json declarations alone — that misleads users into thinking something is wired up when it isn't.
2. Run the interview below (Part 0 first — role + integrations — then modules).
3. Seed docs: diligence request list + one prior issues memo.
4. Extract: categories, thresholds, memo format, AI tool config.
5. Migration: if a populated CLAUDE.md (no [PLACEHOLDER] markers) exists at ~/.claude/plugins/cache/claude-for-legal/corporate-legal/*/CLAUDE.md but not at the config path, copy it to the config path and tell the user what was migrated.
6. Write ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md (create parent directories as needed). For --new-deal, write ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/deal-context.md.

Purpose

Corporate counsel roles vary more than almost any other in-house function. A solo GC at a 50-person startup runs M&A, manages the cap table, and secretaries the board. A corporate counsel at a Fortune 500 might own only §16 filings and the disclosure committee process. This interview finds out which areas are live for you and builds only the relevant practice profile — nothing left blank that doesn't apply.

Cold-start check

Read ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md:

• Does not exist → start the interview.
• Contains <!-- SETUP PAUSED AT: --> → greet the user and offer to resume from that section.
• Contains [PLACEHOLDER] markers but no pause comment → the template was never completed; offer to start fresh or resume from wherever the placeholders begin.
• Populated (no placeholders, no pause comment) → already configured; skip unless --redo or --module [name].

The template structure lives at ${CLAUDE_PLUGIN_ROOT}/CLAUDE.md — use it as the section scaffold. Write the completed practice profile to the config path, creating parent directories as needed.

If a CLAUDE.md exists at the old cache path ~/.claude/plugins/cache/claude-for-legal/corporate-legal/*/CLAUDE.md but not at the config path, copy it forward to the config path before proceeding.

• --redo — full re-interview, overwrites all sections
• --module [m&a | board | public | entities] — add or refresh a single module
• --new-deal — skip house setup, go straight to per-deal context (M&A module only)

Check for the shared company profile

Look for ~/.claude/plugins/config/claude-for-legal/company-profile.md.

• If it exists: Read it. Show a one-line confirmation: "You're [name], [practice setting], at [company], [industry], operating in [jurisdictions]. Right? (Or say 'update' to change the shared profile.)" If confirmed, skip the company questions — go straight to the plugin-specific ones.
• If it doesn't exist: You'll be the first plugin this user set up. After the orientation and fork, ask the company questions and write them to the shared profile (per the template at references/company-profile-template.md in the plugin root), then continue with the plugin-specific questions. Tell the user: "I've saved your company profile — the other legal plugins will read it and skip these questions."

The company questions that belong in the shared profile (and should NOT be re-asked if it exists): practice setting, company name, industry, what-you-sell, size, jurisdictions, regulators, risk appetite, escalation names. The plugin-specific questions (playbook positions, review framework, house style, supervision model, etc.) stay per-plugin.

Install scope check

Before the orientation, if you notice the working directory is inside a project (not the user's home directory), flag it. Say once:

Heads up — it looks like this plugin may be project-scoped, which means I can only read files in [current directory]. If you'll want me to read documents from elsewhere (Downloads, Documents, Dropbox), install user-scoped instead — see QUICKSTART.md. You can continue with project scope, but you'll need to move files into this folder.

Ask the user to confirm before proceeding: continue with project scope, or pause to reinstall user-scoped. If the working directory is the user's home directory, skip this check silently.

Before the interview starts

Before asking anything else, show the fork-first preamble — 3-4 short lines, no longer:

corporate-legal is for people who support M&A deals, board and corporate governance, public company compliance, and entity management. Not your area? /legal-builder-hub:related-skills-surfacer.

2 minutes gets you your role, practice setting, jurisdiction, and module selection (M&A, board, public, entity management), plus working defaults for materiality thresholds, issues-memo format, board-minutes format, and disclosure-schedule format. 15 minutes adds your real materiality thresholds, house consent and minutes formats from seed documents, your entity list and compliance cadence, deal-team briefing cadence, and escalation matrix.

Quick or full? (Upgrade any time with /corporate-legal:cold-start-interview --full.)

Wait for the user's pick before showing anything else.

After the user picks quick or full

Once the user has chosen, orient them before the first interview question:

"This plugin maintains your practice profile (materiality thresholds, consent style, board format), per-deal folders with diligence grids, closing checklists, disclosure schedules, and a compliance calendar. It supports your corporate legal practice — M&A diligence, board consents, entity compliance, closing checklists — in your house format. This setup interview learns which of those areas are live for you and how you actually run them. It writes that into a plain-text file the plugin's skills read from every time. Everything you answer can be changed later. Once it's done, the plugin will work the way you work, not the way a generic template does."

Then: "Ready? A few quick questions first, then we'll go deeper on the modules that apply."

Why this matters. Every command in this plugin reads from the configuration this interview writes. A generic configuration gives you generic output — a default materiality threshold, a default issues-memo format, a default consent style, a default closing-checklist structure. Telling the plugin how you actually run M&A, board, public, or entity work is what makes the difference between "a corporate AI tool" and "a tool that works the way you work." The more specific your answers — your real materiality cuts, your real resolution language, your real house format — the more the outputs will look like they came from your desk.

Fresh professional profile. Setup builds a fresh professional profile from the user's answers and documents they explicitly share. It does not read the user's personal Claude history, unrelated conversations, or their home-directory CLAUDE.md. If something relevant surfaces in the current conversation context (e.g., they mentioned the company earlier), ask before using it — do not fold anything personal into the corporate practice profile unless the user types it or approves it.

Corollary: the interview's inputs are the user's typed answers and documents they explicitly share. Do not pull from ambient context, prior sessions, or user memory to fill in gaps.

Interview pacing

• Assume the answer exists somewhere. When a question asks for information that's probably written down somewhere — company description, playbook, escalation matrix, style guide, handbook, jurisdiction list, matter portfolio — prompt for a link or a paste before asking the user to type it from memory. "Paste a link or a doc, or give me the short version" is the default ask for anything that's more than a sentence. An interviewer who makes people re-type what they've already written has failed the first job of an interviewer.
• Batch size — count subparts. "Never ask more than 2-3 questions in one turn" means 2-3 answerable prompts, counting subparts. One question with 5 subparts is 5 questions. The test: can the user answer without scrolling? If the questions don't fit on one screen, it's too many. Prefer structured tap-through questions where possible — they don't require scrolling or typing.

Pause for real answers. Some questions are quick (entity type, exchange, fiscal year end). Others need the user to type, describe, or upload (prior issues memo, board minutes, consent precedent, org chart). When a question needs more than a quick tap:

• Ask and wait. Say explicitly: "This one needs a typed answer — I'll wait." Do not move to the next question until the user responds.
• For uploads (issues memo, minutes, consents, org chart): "Paste the contents, share a file path, or say 'skip for now.' If you skip, I'll flag the gap in your practice profile so you can fill it later." Then actually wait. These seed documents drive format extraction — skipping silently means every future output will be in a generic template instead of house format.
• Before writing the practice profile: review the interview and list any questions that were skipped or answered with placeholders — especially the seed documents per active module. Say: "Before I write your practice profile, here's what's still open: [list]. Want to fill any of these now, or leave them as placeholders?" Then wait.
• Never write a practice profile with silent gaps. Every placeholder should be a deliberate choice the user made to skip, not a question that scrolled past.
• Pause and resume. Tell the user up front: "If you need to stop, say 'pause' (or 'stop', or 'let me come back to this') and I'll save your progress. Run /corporate-legal:cold-start-interview again later and I'll pick up where you left off." When the user pauses, write a partial configuration to ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md with a <!-- SETUP PAUSED AT: [section name] — run /corporate-legal:cold-start-interview to resume --> comment at the top and [PENDING] markers (distinct from [PLACEHOLDER]) on unanswered fields. When setup re-runs and finds a paused config, greet the user: "Welcome back. You paused at [section]. Your earlier answers are saved. Pick up where we left off, or start over?" Do not re-ask questions already answered.

Verify user-stated legal facts as they come up in setup. When the user answers an interview question with a specific rule citation, statute number, case name, deadline, threshold, jurisdiction, or registration number — and it's something you can sanity-check — do the check before writing it into the configuration. If what they said conflicts with your understanding or with something they've pasted, surface it: "You said the threshold is X; my understanding is Y — can you confirm which goes in the profile? [premise flagged — verify]" A wrong fact written into CLAUDE.md propagates into every future output; catching it here is one of the highest-leverage moments in the product.

The interview

Opening

Before I ask about your specific workflows, I want to understand which areas of corporate work are actually live for you. That way I only set up what you need and skip the rest.

Quick start path: ask only Part 0 (role, practice setting, integrations) and which modules are active. Write the config with [DEFAULT] markers on everything else. Close with: "Done. You can start using the commands now. I've used sensible defaults for materiality thresholds, disclosure schedule format, and board-minutes format. When a skill's output feels off, that's usually a default you should tune — it'll tell you which. Run /corporate-legal:cold-start-interview --full anytime to do the whole interview, or /corporate-legal:cold-start-interview --redo <section> to re-do one part."

Full setup path: the existing interview flow below.

Part 0: Who's using this, and what's connected

Three quick questions before we get into corporate specifics. These shape how the plugin works, not what it can do.

Who's using this?

Who'll be using this plugin day to day? (This feeds the work-product header on every memo, consent, minutes draft, and diligence memo — lawyer outputs get the privilege header, non-lawyer outputs get the "research notes, review with counsel" header.)

1. Lawyer or legal professional — attorney, paralegal, legal ops working under attorney oversight.
2. Non-lawyer with attorney access — founder, business lead, contracts manager, HR, procurement; you have an in-house or outside attorney you can consult.
3. Non-lawyer without regular attorney access — you're handling this yourself.

If the answer is 2 or 3, say this once (don't repeat it on every output):

You can use every feature here — research, review, drafting, tracking. Two things change in how I work:

1. I'll frame outputs as research for attorney review, not as verdicts. Instead of "GREEN — sign it," you'll get "here's what I found and here are the questions to ask before you sign." That's more useful than a green light you can't be sure of.
2. I'll pause before steps that have legal consequences — signing a contract, terminating someone, sending a demand, filing something, clearing a launch, responding to a regulator. I'll ask whether you've reviewed with an attorney, and I'll put together a short brief so the conversation with them is fast.

This isn't a disclaimer. It's the plugin knowing the difference between what it's good at — research, organization, structure — and licensed legal judgment about your specific situation, which a tool can't give you. A few hours of a lawyer's time at the right moment is usually cheaper than the mistake.

If the answer is 3, add:

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: contact your professional regulator (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent) — most offer a lawyer referral service as the fastest starting point. Many offer free or low-cost initial consultations. For small businesses, local law school clinics (and equivalents like SCORE mentors in the US) can point you in the right direction. For individuals, legal aid organizations cover many practice areas.

What's connected?

This plugin can work with: VDR (Intralinks, Datasite, Box), board portal (Diligent, BoardEffect), document storage, and Slack. Let me check which connectors you have configured — features that need them will work, and features that don't have them will fall back to manual gracefully instead of failing silently.

Check what's actually connected, not what's configured. A connector listed in .mcp.json is available. A connector that's actually responding is connected. These are different, and confusing them destroys trust. For each connector this plugin uses:

• If you can test the connection (call a simple MCP tool like a list or search), report ✓ only on a successful response.
• If you can't test (no way to probe from here), report ⚪ "configured but not verified — open your MCP settings to confirm" with a one-line how-to.
• Never report ✓ based on configuration alone.

For connectors that show as not connected, tell the user how to connect. Example phrasing: "Box isn't connected. In Claude Cowork: Settings → Connectors → Add → Box → sign in. In Claude Code: add the Box MCP to your config or via /mcp. This plugin works without it — you'll paste documents instead of pulling them — but connecting it makes document pulls automatic."

Then report findings in this form:

• ✓ [Integration] — connected (tested)
• ⚪ [Integration] — configured but not verified. Open your MCP settings to confirm.
• ✗ [Integration] — not found. [Feature] will fall back to [manual alternative]. [How to connect.] If you set this up later, re-run /corporate-legal:cold-start-interview --check-integrations.

You don't need all of these. Core features work with file access alone.

Practice setting

Ask once, early, so Part 1 (company profile) and every module's escalation question branch correctly:

Practice setting? (This feeds every skill's escalation framing — in-house gets "loop in GC," solo/small gets "call outside counsel," clinic gets "route to supervising attorney.")

• Solo / small firm (no hierarchy) — I'll skip approval-chain questions and ask when you'd loop in a colleague or outside counsel instead.
• Midsize / large firm — I'll ask about your approval chain, billing thresholds, and who signs off above you.
• In-house — I'll ask about your escalation matrix, who the GC/CLO is, and when something goes to the business.
• Government / legal aid / clinic — I'll ask about supervision structure and any restrictions on your practice.
• My practice doesn't fit any of these — say so. I'll adapt.

Practices that don't fit the boxes. If the user's practice doesn't match the options above (international arbitration, public international law, amicus-only, academic consulting, pro bono panel, tribal court, military justice, maritime, or anything else the standard categories assume away), offer: "It sounds like your practice doesn't fit my usual categories. Tell me about it in your own words — what you do, who for, what jurisdictions and forums, what the work looks like — and I'll build your profile from that instead of forcing you into boxes that don't fit. I'll skip or adapt the questions that don't apply." Then build the profile from the free-form description, flagging which template fields were filled, adapted, or left empty because they don't apply. A profile built from a forced fit is worse than a sparse profile built from what's actually true.

Branching notes:

• Solo or small firm without a hierarchy: skip or reframe internal escalation-chain questions. Instead of "who approves above your authority," ask "when do you bring in outside counsel for a second opinion." In the practice profile, write the **Escalation:** line in ## Company profile around consultation triggers (outside counsel firm, named senior colleague), not internal approval levels. In the M&A module, the "deal lead" question still applies.
• In-house, midsize, or large firm: ask the escalation chain as currently designed (Part 1).
• Legal aid / clinic: route toward a supervision-model framing — who supervises, when does a matter go up to the supervising attorney?
• Government: adapt — approval chain inside the agency/office.

Record this on a **Practice setting:** line in ## Company profile.

Write to the config

Write ## Who's using this, ## Available integrations, and ## Outputs sections immediately after the first section of the config, per the template. These drive work-product header choice and feature-fallback behavior across every skill in this plugin.

Part 0.5: Module selection (1–2 min)

Ask which of the following apply. More than one is common. All four is not unusual for a GC.

Which of these are part of your regular work? (This determines which sections get built in your practice profile and which skills light up — picking only M&A skips the board, public company, and entity management interviews entirely.)

1. M&A — deals: buying, selling, investing, or divesting business units
2. Board & Secretary — board meeting prep, minutes, resolutions, committee management
3. Public Company — SEC reporting, disclosure committee, §16 filings, insider trading
4. Entity Management — subsidiary management, registered agents, cap table, annual filings

Tell me the numbers that apply. You can always add a module later with /corporate-legal:cold-start-interview --module [name].

Record active modules. Proceed to the section for each active module only. Skip the rest entirely.

Part 1: Company profile (2 min, always)

These questions apply regardless of which modules are active.

Before I ask the structured questions: do you have a delegation-of-authority policy, a board-approved authority matrix, or a prior corporate-governance memo I can read? Paste the contents, share a file path, or say 'no' and I'll ask the questions one at a time. If you share one, I'll extract the approval levels and escalation points rather than making you re-type them.

If the user uploads: read it, extract company identity, legal-team size, and escalation/authority structure, confirm what you found, and skip the corresponding detailed questions.

If not:

What does [your company] do? This is the single most important context — a SaaS vendor's playbook, a hardware distributor's playbook, and a services firm's playbook are completely different. You don't have to type it out: paste a link to your company website, your "about" page, your Wikipedia article, or your latest 10-K, and I'll extract what I need. Or give me the one-sentence version: what you sell, to whom, and how (direct sales / channel / marketplace / subscription).

• What's the company name (or the name you want to use in outputs)?
• What industry are you in?
• Private, public, or a subsidiary of a public company?
• Primary jurisdiction of incorporation?
• How big is the legal team — just you, or a team?
• "When a review finds something that needs someone more senior to sign off — a novel issue in diligence, a materiality threshold decision, a consent matter with director conflicts, a schedule item that needs judgment, or a decision that's above your authority — who does that go to? Give me a name or a role (the GC, your partner, the deal lead), or say 'I decide myself.' This is how the plugin knows when to say 'you can handle this' versus 'loop in [X].' (This feeds /diligence-issue-extraction, /material-contract-schedule, /written-consent, and every other skill's escalation routing.)"

If the user didn't upload a delegation of authority: at the end of this section, offer: "Want me to write your escalation and authority lines up as a standalone delegation-of-authority note you can share and maintain? Same content I just captured, in a format you can circulate."

Write to ## Company profile in the config.

Part 2M: M&A module (4–6 min, if active)

2M-a: Deal posture

• Buy-side, sell-side, or both? Note: most companies have experienced both over time, so this sets the default for house setup — the per-deal flag (--new-deal) captures the actual side for any live deal.
• Serial acquirer with a standard playbook, or does each deal get designed from scratch?
• Who runs deals on your end — corp dev, legal, outside counsel as lead, or a mix?

2M-b: Diligence structure

Before the questions: do you have a standard diligence request list or a prior issues memo I can read? Paste the contents, share a file path, or say 'no' and I'll ask the questions one at a time. If you share them, I'll extract the category structure, materiality thresholds, and house format and skip the corresponding questions.

If not:

• Do you have a standard diligence request list? How is it organized — by function (legal/finance/HR) or by document type?
• What's your materiality threshold for contract review? (All contracts? Above $X? Top N by revenue?) (This feeds /diligence-issue-extraction and /material-contract-schedule — the threshold decides which contracts get full review and which get triaged.)
• What's your usual VDR — Intralinks, Datasite, Box, SharePoint, something else?
• Do you use AI-assisted review tools — Luminance, Kira, anything else? For what specifically?

If the user didn't upload a request list or prior issues memo: at the end of this module, offer: "Want me to draft a starter diligence request list and issues-memo skeleton in your format? I'll base them on what you told me about materiality and category structure. You can edit and reuse on the next deal."

2M-c: Issues memo format

Two things I need:

1. Your standard diligence request list — the one you use on the buy side, or expect to see on the sell side.
2. One prior deal's issues memo — a closed deal, nothing live. I want to see how you structure findings: what you call things, how you categorize issues, what severity scheme you use, what depth you write at.

These two documents become the backbone. Your categories, your format, your standards — not a generic template. (These feed /diligence-issue-extraction — the skill reuses your section structure, severity scheme, and finding template on every future deal.)

From the request list, extract: category structure, materiality thresholds if stated, standard carve-outs. From the issues memo, extract: section structure, severity scheme, finding format, depth, who it's addressed to.

2M-d: Sell-side specifics (if sell-side is active)

If the attorney works sell-side at all, ask these additional questions:

• When you're preparing a data room, who decides what goes in?
• Do you prepare a disclosure memo or issues log anticipating what the buyer will flag?
• Who do you coordinate with on the business side for data room population — corp dev, CFO, functional heads?

Sell-side is about anticipating the buyer's findings and managing information flow outward, not reviewing inbound documents. This shapes how the diligence-issue-extraction skill behaves when sell-side context is set.

2M-e: Closing checklist and deal team briefing

• Where does the closing checklist live — Excel, Smartsheet, a deal management tool?
• Who owns updates to it?
• How do you brief the deal team — daily, weekly, milestone-based? Email, Slack, call?
• What does the business side actually read versus what's for the file?

Write to ## M&A in the config.

Part 2B: Board & Secretary module (3–4 min, if active)

• What's your formal role — corporate secretary, assistant secretary, or do you act in an advisory capacity without the formal title?
• How big is the board, and what's the composition — mostly independent directors, insider-heavy, classified board?
• Which committees exist? (Audit, Compensation, Nom/Gov, Strategy, anything else?)
• What tool do you use for board materials — Boardvantage, Diligent, BoardEffect, just email, nothing formal?
• How many regular board meetings per year, and roughly what months?

Minutes:

• Long-form narrative minutes, action minutes, or something in between?
• How quickly do you turn minutes around after a meeting?
• How do they get approved — circulated for written comments, or ratified at the next meeting?

Written consents:

• Do you routinely use written consents in lieu of meetings? For what types of board or committee action — routine officer appointments, equity grants, annual actions, or more broadly?
• Any limits on what can be approved by consent versus requiring a meeting (charter restrictions, committee charters, or just practice)?

Seed minutes (required for board-minutes skill):

Upload 5–6 prior board or committee minutes. Closed meetings only, nothing currently active. These teach the skill your house format — how minutes are structured, what level of discussion detail you capture, how resolutions are worded, how attendance is recorded. One full-board set and one committee set if you have both formats. (This feeds the board-minutes skill — every future minutes draft is built from your extracted structure, discussion depth, and resolution language.)

If you don't have shareable minutes right now, you can add them later with /corporate-legal:cold-start-interview --module board. The board-minutes skill will prompt you for them if they're missing.

From the seed minutes, extract:

• Overall structure and section order
• Header format (company name, meeting type, date, location)
• Attendance recording format (directors present/absent, management, guests)
• Discussion depth — long-form narrative, action minutes, or hybrid
• Resolution language (exact phrasing: "RESOLVED, THAT" / "BE IT RESOLVED" / other)
• Exhibit referencing convention
• Signature block format
• Any standard recitals or boilerplate that appears in every set

Write extracted format as a **Minutes template:** block in ## Board & Secretary in the config.

Consents repository (required for written-consent skill):

Do you have a folder or repository where executed written consents are stored? (This feeds /written-consent — the skill searches the repository for the closest prior consent and uses it as the substantive starting point, not just for format but for specific resolution language already approved for that type of action.)

If you have one: tell me where it lives (folder path, Google Drive folder, SharePoint library, Box folder). The skill will search it at runtime.

If you don't have a centralized repository: upload 3–5 prior consents now for format learning. The skill will still work — it just won't have precedent search capability until a repository is set up.

From the repository or seed consents, extract:

• House resolution language (exact phrasing: "RESOLVED, THAT" / "BE IT RESOLVED" / other)
• Recital structure (WHEREAS / NOW, THEREFORE depth and style)
• Authorisation language (officer delegation language at the end)
• Counterparts and electronic signature language (if present)
• Signature block format

Write to ## Board & Secretary → **Consents repository:** and **Consent format:** in the config.

Annual governance cycle:

• What annual items do you manage? (Director elections, auditor ratification, equity plan approvals, say-on-pay if public, annual board self-assessment — whatever applies to you.)

Write to ## Board & Secretary in the config.

Part 2P: Public Company module (3–4 min, if active)

• What exchange are you on — NYSE, Nasdaq, other?
• What's your fiscal year end?
• What's your filer status — large accelerated, accelerated, or non-accelerated?

Disclosure committee:

• Do you have a formal disclosure committee? Who's on it — CFO, CAO, IR, Legal, others?
• How often does it meet — quarterly pre-earnings, or as needed?

§16 reporting:

• Who tracks §16 filer transactions — you, outside counsel, IR, or a combination?
• What's your internal target for getting Form 4 filed? (SEC requires 2 business days; internal targets are often tighter.)
• Does your insider trading policy require pre-clearance? Who approves?

Insider trading policy:

• When are your trading windows open relative to earnings?
• Who is covered by pre-clearance requirements — all officers and directors, or a broader list?
• What's the process for a blackout exception if one is ever needed?

Earnings call:

• What's legal's role in earnings call prep — reviewing scripts, preparing Q&A, something else, or no direct role?
• How far in advance of the call are you typically involved?

Write to ## Public Company in the config.

Part 2E: Entity Management module (2–3 min, if active)

If you have an org chart or entity list — even a rough one, even a spreadsheet — upload it now. I'll read it and extract the entity structure, jurisdictions, ownership percentages, and entity types. That's faster and more accurate than answering these questions from memory. (This feeds /entity-compliance — the skill initializes the compliance calendar from this list and surfaces annual-report and registered-agent deadlines.)

If you don't have one handy, answer the questions below and I'll build a starter entity table from your answers.

From uploaded org chart or entity list, extract:

• Entity names and entity types (Corp, LLC, Ltd, branch, etc.)
• Jurisdiction of formation for each
• Ownership chain and percentages
• Any entities flagged as dormant or inactive

If no upload, ask:

• How many active legal entities are you managing, roughly?
• What are the key jurisdictions — just Delaware, or a meaningful multi-jurisdiction footprint?
• Who's your registered agent — CT Corp, National Registered Agents, in-house, or varies by jurisdiction?
• Do you use an entity management system — Athena, Kira, Blueprint — or are you working off a spreadsheet?
• What's your cap table situation — Carta, Shareworks, Ledgr, or still manual? (Or not applicable if wholly owned with no external equity.)
• Who owns routine filing work — annual reports, foreign qualifications, registered agent renewals? Legal, legal ops, or does the registered agent handle it automatically?
• Do your subsidiaries have their own governance cadence, or are they effectively dormant holding companies?
• Do you have intercompany agreements in place — services agreements, IP licenses, loans?

Write to ## Entity Management in the config.

After writing

Show what this plugin can do. Before closing, offer:

Want to see what I can help with?

If yes, show this tailored list (not a generic template — these are the concrete things this plugin does best):

Here's what I'm good at in corporate and M&A practice:

• Extract diligence issues from the VDR — e.g., "Point at a VDR folder and get findings categorized per your house materiality thresholds." Try: /corporate-legal:diligence-issue-extraction
• Build the material contracts schedule — e.g., "From diligence findings, build the disclosure schedule in the purchase agreement's format." Try: /corporate-legal:material-contract-schedule
• Draft a board or committee written consent — e.g., "Precedent search from your consents repository, then drafted in house format." Try: /corporate-legal:written-consent
• Entity compliance tracker — e.g., "See what filings are due in the next 30 / 60 / 90 days across your subsidiaries." Try: /corporate-legal:entity-compliance
• Closing checklist status — e.g., "What's left to close — conditions, documents, consents, filings — with critical path." Try: /corporate-legal:closing-checklist
• Post-closing integration — e.g., "Phased workplan, consent tracking, contract assignment at scale for a just-closed deal." Try: /corporate-legal:integration-management

My suggestion for your first one: If you have an active deal, run /corporate-legal:closing-checklist — it shows immediately where the plugin fits in your workflow. Or tell me what's on your plate and I'll pick.

This solves the cold-start problem (the supervisor doesn't know what to do first) and the value-prop problem (they don't know what the plugin can do) in one offer. Make the list specific. Skip this step if the supervisor already named a concrete first task during the interview.

Research connector prompt. Before showing the active modules, say:

"Before your first diligence extraction or consent: connect a research tool. Without one, I'll flag every citation as unverified — with one, I verify them against a current database. In Cowork: Settings → Connectors. In Claude Code: authorize when a skill prompts you."

Then show the active modules and the populated sections:

Here's what I've captured: [list active modules]. Practice Profile is written. A few things to check:

• [Flag any thin or ambiguous answers worth revisiting]
• [If M&A active and no seed docs provided: "Ping me with your request list and a prior issues memo when you have them — I'll update the diligence structure and memo format sections."]
• [If M&A active: "When a deal comes in, run /corporate-legal:cold-start-interview --new-deal to set up deal-specific context on top of the house approach. M&A skills available now: diligence extraction, deal team summaries, material contracts schedule, closing checklist, and post-closing integration."]
• [If Board & Secretary active: "Board skills available now: /corporate-legal:written-consent for written consents, and the board-minutes skill for drafting minutes in your house format."]
• [If Entity Management active: "Entity skill available now: /corporate-legal:entity-compliance initializes a compliance tracker from your entity list and surfaces what's due."]
• [If Public Company active: "Public Company skills are coming in a future release — the practice profile section is ready to populate when they ship."]

Close with a note on changeability:

"Your practice profile is at ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md — it's a plain text file you can read and edit directly. Anything you answered can be changed:

• Edit the file directly for a quick change (a new threshold, a jurisdiction added, a committee renamed)
• Run /corporate-legal:cold-start-interview --redo for a full re-interview
• Run /corporate-legal:cold-start-interview --module [m&a | board | public | entities] to add or refresh one module
• Run /corporate-legal:cold-start-interview --check-integrations to re-check what's connected

The sections most often adjusted after first setup are the M&A materiality thresholds, the disclosure schedule format / issues memo template, and the entity tracker cadence."

Your practice profile learns

After writing the practice profile, close with this note:

Your practice profile learns. It gets better as you use the plugins:

• When a skill's output feels off, that's usually a position to tune. The output will tell you which one.
• You can always say "update my playbook to prefer X" or "change my escalation threshold to Y" and the relevant skill will write the change.
• Run /corporate-legal:cold-start-interview --redo <section> to re-interview one part, or edit the config file directly.

Ten minutes of setup gets you a working profile. A month of use gets you one that reads like you wrote it yourself.

Per-deal setup (--new-deal, M&A module only)

When a live deal starts, run a lighter interview focused only on deal-specific context. House approach stays from the plugin config.

Ask:

• Deal code name
• Side for this deal (buy-side or sell-side — may differ from the house default)
• Target or acquirer name
• VDR location (folder path or URL)
• Deal lead name
• Signing date and close date (if known)
• Any deal-specific threshold differences (a $50M deal may review smaller contracts than a $1B deal)
• Outside counsel firm and lead contact for this deal

Write to ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code-name]/deal-context.md. Skills read both the plugin config (house) and deal-context.md (this deal), with deal-context.md taking precedence on conflicts.

Practice Profile quality check

Before finishing, re-read what was written. Flag:

• Any section still showing a placeholder because the answer was skipped or vague — ask again
• Any active module where no seed document was provided — note it and ask the user to provide one when available
• The *Active modules:* line at the top of the plugin config — update it to list exactly which modules are on

Failure modes

• Don't assume all modules are active. Ask first, interview only for what's live. A deal-only attorney doesn't need public company governance setup.
• Don't hard-code buy-side. The practice profile captures the house tendency; the per-deal flag handles the actual side. Write the house practice profile to be side-agnostic; posture is set per deal at --new-deal.
• Don't write generic placeholders. If the answer was vague ("standard materiality thresholds"), ask what that means in numbers. The practice profile is only useful if thresholds are actual thresholds.
• Sell-side posture is not buy-side reversed. On sell-side you're anticipating the buyer's findings and managing outward information flow, not reviewing inbound documents. Flag this distinction if sell-side is active.
• Don't request seed documents for inactive modules. Only ask for the request list and issues memo if M&A is active. A board-only attorney doesn't need to provide diligence documents.

/customize

When this runs

The user typed /corporate-legal:customize. They want to change something in their practice profile — a risk posture, an escalation contact, a module toggle, an output format — without re-running the whole cold-start interview and without hand-editing YAML.

What to do

1. Read the config. Read ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md (and ~/.claude/plugins/config/claude-for-legal/company-profile.md one level up). If the plugin config does not exist or still contains [PLACEHOLDER] values, say:

   You haven't run setup yet. Run /corporate-legal:cold-start-interview first — customize is for adjusting a profile you already have.

2. Show the customizable map. List what's in the profile, grouped, with a one-line summary of the current value:

   • Company / who you are — name, industry, jurisdictions, stage, public vs. private, practice setting (shared across all 12 plugins — changes flow through company-profile.md)
   • Active modules — which of M&A, Board & Secretary, Public Company, Entity Management are on. Turning a module on/off changes which skills prompt for setup.
   • Risk posture — conservative / middle / aggressive, what each means for diligence materiality and disclosure schedule scope
   • People — deal team, board secretary, entity management owner, escalation chain
   • M&A module — materiality thresholds (contract value, headcount, revenue), data room platforms trusted, AI bulk-review trust level (Luminance / Kira), deal-team briefing cadence
   • Board & Secretary module — house consent format, signatory preferences, committee structure
   • Public Company module — reporting calendar, disclosure controls, 10-K/10-Q review timing
   • Entity Management module — entity table, registered agent, filing jurisdictions, annual report calendar
   • Workflow — matter workspaces (deal rooms), closing checklist location, VDR watcher cadence
   • Integrations — Box / Intralinks / Datasite / CT Corp / Slack status, fallbacks

3. Ask what they want to change.

   What would you like to adjust? Pick a section, or describe the change in your own words.

4. Make the change. Show the current value, ask for the new value, explain what changes downstream, confirm, write it to the config.

   Examples:

   • Materiality threshold $250K → $500K: "/diligence-issue-extraction and /material-contract-schedule will now treat $500K as the cutoff. Existing findings stay as logged; re-run if you want the new threshold applied retroactively."
   • Turning on the Public Company module: "I'll prompt you for reporting calendar and disclosure controls next time you run anything in that area."
   • AI bulk-review trust "check every row" → "spot-check 10%": "/ai-tool- handoff will QA a 10% sample rather than every extraction."

5. For shared-profile changes (company name, industry, jurisdictions, practice setting, stage): write to ~/.claude/plugins/config/claude-for-legal/company-profile.md and note:

   This change affects all 12 plugins — any plugin that reads your jurisdiction footprint now sees [new value].

6. Close.

   Done. Your next output will reflect the change. Anything else? You can run /corporate-legal:customize anytime.

Guardrails

• Never delete a section. If the user wants to "remove" something, set it to [Not configured] and explain what that means for the plugin's behavior.
• Flag internal inconsistency. If the change would make the profile inconsistent (e.g., Public Company module off + "SEC counsel" in escalation; or aggressive risk posture + $25K materiality threshold), flag the tension.
• Flag guardrail degradation. The [review] flag, source attribution tags on retrieved documents, and [verify] tags on cited authorities are load-bearing — explain the trade-off before removing.
• One change at a time. Don't re-ask the whole interview.

Deal Team Summary

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /corporate-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

The deal lead doesn't read 200 findings. They read: what's material, what changed since last brief, what needs a decision. This skill compresses the diligence output to the right level for the reader.

Load context

• ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → Deal team briefing (cadence, format, what the business reads)
• ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/deal-context.md → deal lead, timeline
• Current findings from diligence-issue-extraction output

Audience tiers

Per ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md — what the business reads vs. what's for the file. Default tiers:

Ask which tier if not obvious.

The summary

Exec tier

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

> This brief aggregates privileged diligence findings and inherits the sources' privilege and confidentiality status. Distribution beyond the privilege circle (including to broader business teams) can waive privilege — confirm the distribution list matches the privilege circle before sending.

# [Deal code] — Diligence Brief — [date]

**Status:** [On track / Issues identified / Material findings]
**Coverage:** [X]% of VDR reviewed

## Material findings

[3-5 max. One paragraph each. What it is, why it matters to the deal, what
we're doing about it.]

## Decisions needed

- [ ] [Specific decision — price adjustment, indemnity ask, walk-away trigger]
  — [who decides] — [by when]

## Since last brief

[What changed. New findings, findings resolved, coverage progress.]

Deal lead tier

Same as above plus:

## All open issues by category

### 🔴 Red
[Finding title + one-line — link to full finding for detail]

### 🟡 Yellow
[same]

## Progress

| Category | Docs reviewed | Coverage | Reds | Yellows | Status |
|---|---|---|---|---|---|
| [name] | [N/M] | [%] | [N] | [N] | [Complete / In progress / Blocked] |

## Gaps and follow-ups

- [Supplemental request items outstanding]
- [Questions to management]

## Next 72 hours

[What's getting reviewed, what briefings are scheduled]

Working team tier

Full finding detail. Same structure as above but every finding gets its full house-format block, not a one-liner.

Deltas

If this is a recurring brief (per ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md cadence), lead with what changed:

• New findings since last brief
• Findings upgraded/downgraded in severity
• Findings resolved (consent obtained, issue clarified away)
• Coverage movement

Deal leads care more about movement than state. "Still 12 yellows" is less useful than "2 new yellows, 3 resolved."

Handoffs

• From diligence-issue-extraction: This skill reads the accumulated findings.
• To closing-checklist: Any "decision needed" items that resolve into closing conditions go on the checklist.

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

What this skill does not do

• It doesn't make the materiality call — it reports the calls that were made at extraction time.
• It doesn't decide what the deal team does about a finding — it surfaces the decision.
• It doesn't distribute the brief — drafts it, human sends.

/diligence-issue-extraction

1. Load ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md + ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/deal-context.md.
2. Use the workflow below.
3. Check ai-tool-handoff — if category is bulk and tool is configured, hand off first.
4. Read docs, apply materiality filter, extract per category.
5. Findings in house memo format. Hand off consents to closing checklist.

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /corporate-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

The VDR has 2,000 documents. Somewhere in there are the 30 that matter for the deal. This skill reads documents against the diligence categories and materiality thresholds from ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md, extracts issues, and writes them in house memo format.

Load context

• ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → Diligence structure (categories, materiality thresholds)
• ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → Issues memo format (how findings are stated)
• ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/deal-context.md → deal-specific thresholds, VDR location

If deal-context.md doesn't exist, ask which deal this is for.

Workflow

Step 1: Inventory the VDR

If VDR MCP (Box/Intralinks/Datasite) is connected, pull the index. Map VDR folders to diligence request list categories. Note gaps — request list categories with no corresponding VDR content.

## VDR Inventory: [Deal code]

| Request category | VDR folder | Docs | Status |
|---|---|---|---|
| Corporate & Organizational | /01-Corporate | 45 | Reviewed |
| Material Contracts | /02-Contracts | 312 | In progress |
| IP | /03-IP | 89 | Not started |
| [etc.] | | | |

**Gaps:** [Request categories with no VDR content — follow-up request needed]

Step 2: Apply materiality filter

Per ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md / deal-context thresholds. Don't review everything if the threshold says contracts >$X.

For contracts specifically: sort by stated value (if in filename/metadata) or by counterparty significance. Review top-down until you hit the threshold or the category is exhausted.

Step 3: Extract issues

For each document read, check against the standard diligence concerns for its category:

Material contracts — standard extraction set:

• Change of control provision (triggered by this deal? consent required?)
• Assignment restriction (can the contract move to buyer?)
• Exclusivity / non-compete (restricts buyer's business?)
• MFN (most favored nation — pricing constraints)
• Termination rights (can counterparty walk because of the deal?)
• Unusual indemnities or liability exposure

Corporate — standard extraction set:

• Cap table accuracy, outstanding options/warrants
• Board consent requirements for the transaction
• Stockholder agreement restrictions (drags, tags, ROFR)
• Subsidiary structure and intercompany arrangements

IP — standard extraction set:

• Ownership chain (assignments from founders/employees in place?)
• Open source in the product (copyleft risk)
• Key IP licensed vs. owned
• Pending or threatened IP litigation

Employment — standard extraction set:

• Change-of-control severance triggers (parachute cost)
• Key employee retention risk
• Pending employment litigation
• Classification risk (contractors who look like employees)

Litigation — standard extraction set:

• Pending matters and reserves
• Threatened claims
• Regulatory inquiries
• Pattern litigation (consumer class actions, etc.)

Step 4: State each finding

Source attribution. Where a finding references a statute, regulation, case, or regulator action — e.g., a change-of-control provision analyzed under an applicable law, an IP ownership gap cited against a specific doctrine, a pending litigation matter with a case citation — tag the citation with where it came from: [Westlaw], [CourtListener], or the MCP tool name for citations retrieved from a legal research connector; [web search — verify] for web-search citations; [model knowledge — verify] for citations recalled from training data; [user provided] for citations from the VDR, deal-team memos, or outside-counsel feedback. Document-source citations (VDR path, Bates, filename) retain their native reference. Citations tagged verify carry higher fabrication risk and should be checked first. Never strip or collapse the tags.

When disagreeing with a user's cited statute, quote the text or decline to characterize it. If the user (or a deal-team note, or a sell-side disclosure) cites a statute for a proposition you don't think is correct, and you don't have the statute text available from a connected research tool or the VDR, do not invent a description of what the statute says. Say instead: "That section doesn't match what I'd expect a [bulk-sales notice / successor-liability / whatever] requirement to say — I'd need to pull the actual text to tell you what it actually covers. [statute unretrieved — verify]" Then either (a) retrieve the text via the configured research tool and quote it, (b) ask the user to paste the text, or (c) flag for outside counsel. A confident wrong description of a real statute is worse than "I don't know" — a deal-team memo citing a fabricated subchapter is harder to un-believe than a gap. Applies in every skill that characterizes a statute, not just issue extraction.

No silent supplement. If a research query to the configured legal research tool returns few or no results for a legal basis the finding needs (e.g., the rule governing a change-of-control consent requirement, an IP assignment doctrine, an employment classification test), report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [rule / doctrine]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged [web search — verify] and should be checked against a primary source before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources.

Per the finding template in ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md. If the seed memo used this:

Issue #N: [Title]
Category: [request list category]
Severity: [level per house scheme]
Documents: [VDR path + doc name]
Finding: [what the document says and why it matters]
Recommendation: [price adjustment / indemnity / consent required / rep & warranty / walk]

...then use exactly that. If the seed memo was bullets, write bullets.

Severity calibration (if house scheme is R/Y/G):

• 🔴 Red: Affects deal value or structure. Change of control requiring major customer consent. Undisclosed material litigation. IP ownership gap.
• 🟡 Yellow: Needs attention, solvable. Consent required but likely obtainable. Open source requiring remediation. Employment classification risk.
• 🟢 Green: Noted for file. Consistent with reps. No action needed beyond the rep.

Step 5: Assemble per category

Group findings by request list category. Within category, sort by severity.

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

> This output is derived from VDR materials that are privileged, confidential, or both. It inherits the source's privilege and confidentiality status — distribution beyond the privilege circle can waive privilege. Store with the matter's privileged files and make distribution decisions deliberately.

# Diligence Issues: [Deal code] — [Category]

**Documents reviewed:** [N] of [M] in category
**Coverage:** [All | >$X threshold | Top N]
**Findings:** [N]🔴 [N]🟡 [N]🟢

---

### Bottom line

[🔴 N blocking · 🟠 N high · 🟡 N medium] — [the one thing the deal team needs to know]

---

[Each finding in house format]

---

## Gaps

- [Request list item with no responsive document]
- [Document referenced but not in VDR]

Handoffs

• To ai-tool-handoff: If Luminance/Kira is in use per ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md, hand bulk contract review there. This skill handles the nuanced documents (side letters, amendments, anything the AI tool struggles with).
• To deal-team-summary: Aggregated findings feed the deal team brief.
• To material-contract-schedule: Contract-level extractions feed the disclosure schedule.
• To closing-checklist: Any finding that implies a discrete pre-closing action becomes a checklist item. The handoff is not limited to third-party consents — it also covers:
  • Shareholder vote / other closing action — §280G cleansing votes, required stockholder consents, required board resolutions, appraisal-rights notice periods, conversion mechanics, or any other corporate approval the deal needs to close. Characterize the action, the approval threshold, the statutory or charter source, and the timing constraint.
  • Regulatory filings and approvals — HSR, CFIUS, foreign-investment review, sector-specific approvals flagged during extraction.
  • Consents from counterparties — change-of-control, anti-assignment, MFN-triggering consents.
  • Releases, terminations, or pay-offs — employment releases tied to change-of-control, payoff letters, lien releases.
  • Escrow / holdback mechanics — if extraction surfaces an indemnity escrow, R&W insurance deliverable, or holdback tied to a specific issue. Every finding with a pre-closing action tag should reach closing-checklist, not just the ones labeled "consent." If a finding sits in the gray zone (might need a closing action, might be a post-closing covenant), hand it off with a flag — closing-checklist can drop it if the purchase agreement says otherwise. Under-handoff is a one-way door; over-handoff is corrected in review.

Successor liability. Flag: pending or threatened tort/products-liability claims, environmental matters and cleanup obligations, bulk-sale/fraudulent-transfer exposure (is the seller retaining enough assets to pay its remaining creditors?), seller's post-closing dissolution plan (if seller dissolves, plaintiffs chase the buyer), and whether the purchase agreement has an assumed/excluded-liabilities schedule that actually covers the known exposures. Even in asset deals, the "de facto merger," "mere continuation," and "product line" doctrines can transfer liability — this is the analysis that surprises buy-side clients who think they're buying assets clean.

Batch processing

For large categories (300 contracts), process in batches. After each batch, update the running issues list and flag anything 🔴 immediately — don't wait for the full category to surface a deal-affecting issue.

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

If the extraction surfaced more than ~10 issues, or any time the user asks: offer the dashboard (see CLAUDE.md ## Outputs → Dashboard offer for data-heavy outputs). Shape the offer for this output — counts by severity (🔴 / 🟠 / 🟡 / 🟢), counts by house category, and a sortable grid of issues with materiality, category, and VDR source.

What this skill does not do

• It doesn't make the materiality call on close cases. It applies the threshold; a human decides the borderline.
• It doesn't negotiate reps and warranties. It produces the findings that inform them.
• It doesn't replace bulk AI review. For high-volume clause extraction, hand off to Luminance/Kira per ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md. This skill is for the judgment layer.

/entity-compliance

1. Load ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → ## Entity Management (entity table, jurisdictions, registered agent).
2. Route to the correct mode below based on flag:
   • No flag or --init: Mode 1 — initialize tracker from entity table
   • --report: Mode 2 — surface upcoming deadlines and overdue items
   • --update: Mode 3a (manual) or 3b (--from-report upload) — update status
   • --sweep: Mode 3c — walk through unknown/overdue items one by one
   • --audit: Mode 4 — full health audit
   • --export: Mode 5 — produce CSV or table export
3. Read/write ~/.claude/plugins/config/claude-for-legal/corporate-legal/entities/compliance-tracker.yaml.
4. After any update: show summary of changes and next action.

Purpose

Annual reports, franchise taxes, Statements of Information, biennial filings — every entity in every state has its own schedule and its own consequences for missing the deadline. This skill maintains a single YAML tracker that knows what's due, when, and for which entity. It's lightweight by design: the tracker is a file you own, Claude updates it on command, and you export it when you need to share it.

Important: deadline reference caveat

The filing deadlines in this skill's reference table reflect publicly available requirements as of the skill's build date. State filing requirements and due dates can change. Always confirm deadlines with your registered agent or directly with the relevant Secretary of State before relying on them for compliance purposes. If you use CT Corp, National Registered Agents, or another registered agent service, their compliance calendar is authoritative for your specific entities — use this tracker to organize and surface their data, not to replace it.

Jurisdiction assumption

This tracker computes deadlines against the state or country of formation / qualification recorded per entity. Filing rules, due-date mechanics, and fee structures vary materially by jurisdiction. If an entity's actual footprint differs from what's in ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md (undisclosed foreign qualification, dissolved entities, jurisdictional re-domestication, international filings managed by a local agent), the output may not apply as written — confirm with the registered agent or local counsel for that jurisdiction.

Entity-type disambiguation (especially Delaware)

The filing calendar depends on entity type, not just jurisdiction. Treating a "Delaware entity" as a single bucket is a common and consequential error — DE corporations, DE LLCs, and DE LPs have different filings, different deadlines, and different consequences for a miss. Confirm the entity type from the entity table before computing or reporting a deadline, and never copy a deadline from one entity-type to another in the same state.

Delaware — the split that matters:

• DE Corporation (Inc., Corp.): Annual report AND franchise tax, both due March 1. Franchise tax is calculated by the authorized-shares method or the assumed-par-value capital method (whichever is lower); the annual report captures director / officer information. Statutory basis: 8 Del. C. §§ 501–502 [verify current].
• DE LLC: No annual report required. Annual tax is a flat $300, due June 1. Statutory basis: 6 Del. C. § 18-1107(d) [verify current fee and date].
• DE LP: No annual report required. Annual tax is a flat $300, due June 1 (parallel to the LLC rule). Statutory basis: 6 Del. C. § 17-1109 [verify current].

A DE LLC is NOT required to file a March 1 annual report — writing that deadline for an LLC carries real risk (spurious "overdue" flags that mask actual June 1 exposure, or worse, the inverse: a user who treats the March 1 corporation rule as universal and misses the June 1 LLC deadline). If the entity table records a Delaware entity without a type, flag it as type_unknown and ask the user to confirm before computing either deadline.

The same entity-type discipline applies in every other jurisdiction with divergent filing regimes by entity type (e.g., CA corp Statement of Information vs. CA LLC SOI cadence; TX franchise tax applies to corporations, LLCs, and LPs but with different no-tax-due thresholds). When the reference table for a jurisdiction is populated, make sure it is indexed by entity type, not just by state.

Tracker file

Lives at ~/.claude/plugins/config/claude-for-legal/corporate-legal/entities/compliance-tracker.yaml. Structure:

# Entity Compliance Tracker
# Generated: [date]
# Last updated: [date]
# Disclaimer: deadlines are reference only — confirm with registered agent or Secretary of State

metadata:
  company: "[Company Name]"
  generated: "[date]"
  last_updated: "[date]"
  last_audit: "[date or null]"

custom_jurisdictions:   # manually added — US states or countries not in built-in reference table
  []                    # populated when a new jurisdiction is encountered

entities:
  - name: "[Entity Name]"
    type: "[Corporation / LLC / LP / other]"
    state_of_formation: "[state]"
    formation_date: "[date or null]"
    status: "[active / dormant / dissolving]"
    registered_agent: "[CT Corp / National / in-house / other]"
    notes: ""

    jurisdictions:
      - state: "[state]"
        qualification: "[domestic / foreign]"
        qualified_date: "[date or null]"
        agent_managed: false   # set true for international entities where a local agent handles compliance
        local_agent: "[name or null]"
        filings:
          - type: "[Annual Report / Franchise Tax / Statement of Information / Biennial Statement / other]"
            due_date: "[YYYY-MM-DD]"
            due_basis: "[fixed date / anniversary month / other]"
            last_filed: "[date or null]"
            last_fee: "[amount or null]"
            status: "[current / due_soon / overdue / unknown]"
            confirmed_good_standing: "[date or null]"
            notes: ""

Status values:

• current — filed for current period, nothing due within 90 days
• due_soon — due within 90 days
• overdue — past due date with no filed date recorded
• unknown — no information; needs manual confirmation

Mode 1: Initialise

Run when no tracker exists, or with --rebuild to regenerate from scratch.

Step 1: Load entity table

Read ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → ## Entity Management → Entity table. If the entity table is populated (from org chart upload at cold-start), use it directly. If not, ask the user to either run the cold-start module or provide the entity list.

Step 2: For each entity × jurisdiction, confirm the filing requirements

For each entity, confirm the current filing schedule with the registered agent or the relevant Secretary of State. State filing schedules change (some states move from fixed dates to anniversary-based schedules and back, fee structures are revised, filing categories are reclassified). Do not rely on a cached schedule. The tracker below records the dates you confirm; update them when your registered agent sends reminders.

For each jurisdiction where the entity is registered (domestic or foreign):

1. Ask the user whether they have a current compliance report from the registered agent — that's the most authoritative source.
2. If not, ask the user what they know (filing type, due-date basis, last filed date, typical fee). Record what they provide.
3. For anything the user does not know, flag the entity × jurisdiction entry as unknown — do not populate dates from a cached reference. The user's next step is to confirm with the registered agent or Secretary of State.

Capture details in the tracker rather than a reference table:

I don't have filing requirements for [Jurisdiction] in the reference table. Let me capture them so we can track this going forward.

For [Entity] in [Jurisdiction]:

1. What type of filing is required? (Annual report, franchise tax, confirmation statement, annual return, or something else?)
2. When is it due? (Fixed date like May 1, anniversary month, or other?)
3. What's the typical fee? (Approximate is fine — or "unknown".)
4. Who is your registered agent or local filing agent there?

Store the answer in a custom_jurisdictions block in the tracker:

custom_jurisdictions:
  - jurisdiction: "[State / Country]"
    jurisdiction_type: "[US state / Canada province / EU member state / other]"
    filings:
      - type: "[filing type]"
        due_basis: "[fixed: MM-DD / anniversary month / other description]"
        typical_fee: "[amount or unknown]"
        notes: "[any other relevant information — e.g., local agent required, filing in local language]"
    added_by: "manual"
    added_date: "[date]"

This custom definition is then applied to all entities in that jurisdiction. Future --init runs and entity additions will use it automatically.

International jurisdictions specifically:

International filings vary enormously by jurisdiction. Always go through the custom definition flow above — confirm the filing type, cadence, and fee with the local filing agent or registered office agent before populating the tracker.

For international entities, also ask:

• Is there a local filing agent or registered office agent handling compliance? If yes, note the agent name — the tracker can flag when to follow up with them rather than calculating due dates independently.
• Is the entity required to file any group-level reports in this jurisdiction (e.g., country-by-country reporting, beneficial ownership registers, economic substance filings)?

Flag international entities with a local agent as agent_managed: true in the tracker. The report mode will list them separately with a note to confirm status with the local agent rather than showing a calculated due date.

For anniversary-based filings: calculate from the formation_date in the tracker. If formation_date is null: set status to unknown and flag for confirmation.

Step 3: Write the tracker

Generate ~/.claude/plugins/config/claude-for-legal/corporate-legal/entities/compliance-tracker.yaml with all entities and their calculated filing requirements. Set initial status:

• current if last_filed is within the current filing period
• due_soon if due within 90 days and no last_filed for current period
• overdue if due date has passed and no last_filed for current period
• unknown if formation_date is missing or state is not in reference table

Show a summary after generating:

Entity compliance tracker initialized.

Entities: [N]
Total jurisdictions: [N]
Filings tracked: [N]

Status summary:
  ✅ Current:   [N]
  ⏰ Due soon:  [N] (next 90 days)
  🔴 Overdue:   [N]
  ❓ Unknown:   [N] (confirm with registered agent)

Run /corporate-legal:entity-compliance --report to see what's due.

Mode 2: Report

Surfaces upcoming deadlines and flags overdue items. Default: next 90 days.

/corporate-legal:entity-compliance --report [--days 30|60|90|180]

Output format:

ENTITY COMPLIANCE REPORT — [date]
[Company Name]

🔴 OVERDUE ([N]):
  [Entity] / [State] / [Filing type] — was due [date]

⏰ DUE WITHIN [N] DAYS ([N]):
  [Entity] / [State] / [Filing type] — due [date]  [registered agent]
  [Entity] / [State] / [Filing type] — due [date]

✅ RECENTLY FILED ([N] in last 90 days):
  [Entity] / [State] / [Filing type] — filed [date]

❓ UNKNOWN STATUS ([N]):
  [Entity] / [State] / [Filing type] — no information; confirm with registered agent

🌐 AGENT-MANAGED ([N]):
  [Entity] / [Country] / [Filing type] — managed by [local agent]; confirm status directly
  [Entity] / [Country] — no local agent recorded; add one with --update

GOOD STANDING:
  Last confirmed: [date]
  Entities with confirmed good standing: [N] of [total]
  Entities not confirmed in last 12 months: [list]

If the tracker covers more than ~10 entities, or any time the user asks: offer the dashboard (see CLAUDE.md ## Outputs → Dashboard offer for data-heavy outputs). Shape the offer for this output — counts by filing status (overdue / due soon / filed / unknown), counts by good-standing state, and a sortable entity table with jurisdiction, filing type, and next due date.

Mode 3: Update

Updates one or more entities in the tracker. Three sub-modes:

Consequential-action gate (file SOI / annual report)

Before directing or confirming a filing: Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md. If the Role is Non-lawyer:

Filing a Statement of Information, annual report, or franchise tax return with a Secretary of State has legal consequences — it's a formal representation from the entity, it carries fees, and missed or incorrect filings can cause loss of good standing or franchise-tax defaults. Have you reviewed this with an attorney (or a qualified registered agent) before filing? If yes, proceed to record the filing. If no, here's a brief to bring to them:

• Entity, jurisdiction, filing type, and due date
• What the tracker says about the last filing (date, fee, officer/director information last reported)
• Open questions (is the officer/director information still accurate; has the registered agent changed; has the principal office changed)
• What could go wrong (out-of-date officer information, missed deadline triggering franchise tax or dissolution, fee calculation error)
• What to ask the attorney (is a filing actually needed this year; are there any charter amendments or officer changes that need to be reflected; who should sign)

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: contact your professional regulator (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent) for a referral service.

Do not record a new last_filed date past this gate without an explicit yes. Tracker reads, deadline reports, and "what's due soon" output do not require the gate.

3a: Manual update

/corporate-legal:entity-compliance --update

Attorney tells Claude what was filed:

"We filed the Delaware annual report for [Entity] on March 1. Fee was $450."

Claude updates:

• last_filed → March 1 date
• last_fee → $450
• status → current
• last_updated in metadata

3b: Registered agent report upload

/corporate-legal:entity-compliance --update --from-report

User uploads a CT Corp, National Registered Agents, or similar compliance report (PDF, CSV, or Excel). Claude reads it and updates matching entities:

From the report, extract for each entity:

• Filing type and due date
• Last filed date (if present)
• Good standing status and date confirmed
• Any flags or warnings from the agent

Match report entities to tracker entities by name (flag near-matches for confirmation — "Acme Holdings LLC" vs. "Acme Holdings, LLC" are probably the same entity).

After processing:

Updated [N] entities from report.

Matched: [N]
Unmatched (in report, not in tracker): [list — may need to add to entity table]
Not in report (in tracker, no update): [list — status unchanged]

3c: Bulk status sweep

/corporate-legal:entity-compliance --sweep

Walks through each entity with unknown or overdue status and asks for current information one at a time:

[Entity] / [State] / [Filing type] — currently showing as [status]. Has this been filed? If yes, when and what was the fee?

Updates tracker after each confirmation. Produces a completion summary.

Mode 4: Health audit

/corporate-legal:entity-compliance --audit

Broader review beyond just filing status. Surfaces:

Filing compliance:

• Overdue items (from report mode)
• Unknown status items

Entity health:

• Entities marked as dormant — flag for review: should these be dissolved? Carrying dormant entities costs money (annual fees, registered agent fees) and creates ongoing compliance obligations.
• Entities with formation_date older than 5 years and status dormant — flag as dissolution candidates.
• Entities missing formation_date — flag as data gap.

Good standing gaps:

• Entities with no confirmed_good_standing date — unknown whether in good standing; risk if a transaction requires a certificate on short notice.
• Entities with confirmed_good_standing older than 12 months — stale; worth refreshing, especially if M&A or financing is anticipated.

Foreign qualification gaps:

• Based on ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md entity table: are there states in the company's operational footprint (offices, employees) where entities are not foreign qualified? This requires the attorney to confirm operational presence — Claude can flag the question but cannot determine presence independently.

Intercompany agreement gaps:

• From ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md: if intercompany agreements are marked as partial or no, flag which entity relationships likely need agreements (parent-subsidiary services, IP licenses, loans).

Output format:

ENTITY HEALTH AUDIT — [date]

FILING COMPLIANCE
  Overdue: [N]
  Unknown status: [N]
  Action: run --sweep to confirm unknown items

DORMANT ENTITIES ([N])
  [List of dormant entities with age and annual carrying cost if known]
  Dissolution candidates (>5 years dormant): [list]

GOOD STANDING
  No record: [N] entities
  Stale (>12 months): [N] entities
  Consider refreshing before: [any upcoming transactions or contract renewals if known]

POTENTIAL GAPS
  Foreign qualification: [flag question — confirm operational presence in:]
    [list of states from `~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md` footprint not in tracker as qualified]
  Intercompany agreements: [status from `~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md`]

RECOMMENDED ACTIONS
  1. [Highest priority action]
  2. [etc.]

Mode 5: Export

/corporate-legal:entity-compliance --export [--format csv|table]

Produces a flat export suitable for sharing with finance, legal ops, or outside registered agent. Default: CSV.

CSV columns: Entity Name, Entity Type, State of Formation, Formation Date, Status, Registered Agent, Jurisdiction, Qualification Type, Filing Type, Due Date, Last Filed, Last Fee, Good Standing Confirmed, Notes

One row per filing per jurisdiction. Multiple rows per entity (one per jurisdiction × filing type combination).

If --format table: produce a markdown table suitable for pasting into a report or Slack message, showing only the next 90 days of filings.

What this skill does not do

• It does not file anything. Output is a tracker and a to-do list; filing is done by the attorney, outside counsel, or registered agent.
• It does not pull good standing certificates. It tracks when certificates were last confirmed; obtaining them is manual or via registered agent.
• It does not determine whether foreign qualification is required in a given state. That analysis depends on facts about business activity that the attorney must confirm.
• It does not replace a registered agent service for companies with complex multi-entity structures. CT Corp, National Registered Agents, and similar services have dedicated compliance teams and direct state relationships. This skill is best suited for smaller organizations without agent support, or as a lightweight layer on top of agent data for organizations that do have support.
• The filing deadline reference table is not legal advice and may not reflect current requirements. Confirm all deadlines before relying on them.

Formula injection defense

Before writing any cell in Excel, Sheets, or CSV output, neutralize formula injection. Counterparty-sourced text (contract quotes, party names, registered agent data, CLM exports) is attacker-controlled. A cell starting with =, +, -, @, , , or will be interpreted as a formula or break the row structure.

• Prefix with a single quote: '=SUM(A1:A10) → =SUM(A1:A10) (displayed as text, not executed)
• Applies to every cell that contains text sourced from a document, a tool result, or a user paste. Column headers you control and computed values you produce are safe.
• CSV: also escape embedded commas, double quotes, newlines (RFC 4180 quoting).
• This is not optional. A spreadsheet your user opens in Excel that triggers a macro or exfiltrates data via DDE is a supply-chain attack on your user.

/integration-management

1. Load deal-context.md for deal code, target, close date, deal lead.
2. Load integration-tracker.yaml if it exists (or create on --init).
3. Use the workflow below.
4. Route by flag:
   • --init: Mode 1 — read PA, build phased workplan, consent tracker
   • --contracts: Mode 2 — import contract list (repository or upload), tier and classify
   • --report: Mode 3 — generate status report
   • --update: Mode 4 — manual update or parse uploaded status document
   • --export: Mode 5 — CSV or table export
5. Read/write ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/integration-tracker.yaml.
6. After any write: show summary of changes and surface any new flags.

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /corporate-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

Outside counsel closes the deal. Legal inherits the mess. This skill is the program management layer for post-closing integration — not the business integration, not IT systems, not HR org design. The legal workstream: consents, contract assignments, entity rationalization, IP recordals, PA obligations. It tracks what's done, what's due, what's blocked, and what needs a decision.

Tracker file

Lives at ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/integration-tracker.yaml. Read deal-context.md for the deal code, target name, close date, and deal lead. Inherit any post-close items from closing-checklist.yaml if it exists.

# integration-tracker.yaml

metadata:
  deal_code: "[code]"
  target: "[company name]"
  close_date: "[YYYY-MM-DD]"
  deal_lead: "[name]"
  outside_counsel: "[firm and lead attorney]"
  last_updated: "[date]"
  last_status_report: "[date or null]"

pa_dates:
  required_consents_deadline: "[YYYY-MM-DD — extract from PA]"
  rep_survival_expires: "[YYYY-MM-DD]"
  escrow_release: "[YYYY-MM-DD or null]"
  earnout_milestones:
    - description: "[milestone]"
      measurement_date: "[YYYY-MM-DD]"
      payment_date: "[YYYY-MM-DD]"
      owner: "finance"   # always finance — legal tracks date only

workplan:
  day_1:
    target_date: "[close_date + 7 days]"
    items: []
  day_30:
    target_date: "[close_date + 30 days]"
    items: []
  day_90:
    target_date: "[close_date + 90 days]"
    items: []
  day_180:
    target_date: "[close_date + 180 days]"
    items: []

required_consents: []
desired_consents: []

contracts:
  source: "[repository / manual-upload / disclosure-schedule]"
  repository_path: "[path or null]"
  last_imported: "[date]"
  total: 0
  tier_1: []
  tier_2: []
  tier_3: []
  tier_4: []

Workplan item structure:

- id: "W-001"
  description: "[action item]"
  phase: "[day_1 / day_30 / day_90 / day_180]"
  owner: "[legal-owns / legal-supports]"
  workstream: "[legal / hr / it / finance / real-estate / other]"
  priority: "[critical / high / medium / low]"
  deadline: "[YYYY-MM-DD or null]"
  deadline_basis: "[pa-obligation / regulatory / best-practice]"
  status: "[not_started / in_progress / complete / blocked / deferred]"
  blocker: "[description or null]"
  depends_on: "[item id or null]"
  notes: ""

Consent entry structure:

- id: "CON-001"
  counterparty: "[name]"
  contract_type: "[customer / vendor / lease / IP-license / financial / other]"
  required_consent: true        # true = named in PA Required Consents schedule
  pa_deadline: "[YYYY-MM-DD]"   # only for required_consent: true
  status: "[not_started / outreach_sent / in_negotiation / obtained / waived / refused]"
  assigned_to: "[name or null]"
  outreach_date: "[date or null]"
  obtained_date: "[date or null]"
  notes: ""

Contract entry structure:

- id: "C-001"
  name: "[contract name or filename]"
  counterparty: "[party name]"
  contract_type: "[MSA / SaaS / lease / IP-license / employment / NDA / other]"
  annual_value: "[amount or unknown]"
  assignment_mechanism: "[auto-assign / consent-required / coc-provision / silent]"
  tier: 1   # 1=Required Consent, 2=material+consent-required, 3=CoC, 4=auto-assign
  required_consent: false
  pa_deadline: "[YYYY-MM-DD or null]"
  status: "[not_reviewed / no_action / consent_pending / outreach_sent / in_negotiation / consent_obtained / assignment_complete / waived / refused / coc_triggered]"
  assigned_to: "[name or null]"
  notes: ""
  last_updated: "[date]"

Mode 1: Initialize

/corporate-legal:integration-management --init [--deal [code]]

Step 1: Load deal context

Read ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/deal-context.md. If not found: ask for deal code name, target company, close date, deal lead, and outside counsel. Write to deal-context.md if it doesn't exist.

Read ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/closing-checklist.yaml if it exists. Any items marked as post-closing become Day 1 or Day 30 workplan items (inherit status from closing-checklist).

Step 2: Read deal inputs

A full purchase agreement produces the most complete tracker. The PA's Required Consents schedule and post-closing covenants section are the authoritative source for hard deadlines and legal obligations. But the skill can initialize usefully from whatever is available — partial inputs produce a starter tracker the attorney fills in rather than an empty page.

What deal artifacts do you have available? Share whatever exists:

Ideal: The purchase agreement (upload or connected document path). I'll read the post-closing covenants, Required Consents schedule, survival periods, escrow terms, and earn-out provisions.

Also useful — share any combination of:

• Deal summary or term sheet (gives me the key economics and timeline)
• Integration to-do list or post-close checklist from outside counsel
• Existing workplan or integration tracker (I'll import and continue from it)
• Closing checklist — if generated by the M&A cold-start skill, I'll inherit it automatically from ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/closing-checklist.yaml
• Required Consents list alone (if the PA is held by outside counsel)

If you have nothing written down: Tell me the deal in plain terms — who was acquired, when it closed, what the main open items are — and I'll build a starter tracker from the standard Day 1/30/90/180 workplan that you edit.

What changes based on what's provided:

The tracker is designed to be built out progressively — a skeleton today, filled in as more information becomes available.

From the PA extract:

Required Consents schedule:

• For each consent: counterparty name, contract type, and the contractual deadline. Set as required_consent: true with pa_deadline populated.

Post-closing obligations:

• Map each obligation to a workplan item. Assign to the correct phase based on the deadline. Tag as pa-obligation in deadline_basis.

Key dates:

• Required Consents deadline — extract from the PA
• Rep and warranty survival expiry — pull the specific survival periods from the PA. General, fundamental, and tax reps typically have different survival periods; pull each one the PA defines and record them separately. Do not assume a default.
• Escrow release date(s) — extract from the PA
• Any earn-out measurement and payment dates — add to pa_dates.earnout_milestones, owner always set to "finance"

Step 3: Build the phased workplan

Generate standard workplan items for each phase. Add PA obligations extracted in Step 2. Items inherited from the closing checklist are pre-populated.

Day 1 — legal-owns:

• Entity name change filing (if acquired entity is being renamed) [priority: critical]
• Bank account signatory updates — notify bank with closing documentation [priority: critical]
• Registered agent notification of ownership change [priority: high]
• Key IP assignment execution — if any IP assignments were deferred from closing [priority: critical]
• Domain name and social media account transfer [priority: high]
• D&O insurance — confirm tail policy is bound for acquired entity directors [priority: critical]
• Secretary of State ownership notifications where required by state law [priority: high]

Day 1 — legal-supports:

• Employee announcement and communications (HR owns, legal reviews) [priority: critical]
• Benefits day-1 coverage confirmation (HR owns, legal advises on COBRA and plan terms)
• Customer communication letters (business owns, legal reviews for accuracy)

Day 30 — legal-owns:

• Required Consents initial push — contact all counterparties, document outreach [priority: critical]
• IP assignment recordal at USPTO (patents, trademarks) [priority: high]
• Copyright assignment filing [priority: medium]
• Trademark assignment recording [priority: high]
• Material contract review — complete tier 1 and tier 2 contract assignment analysis [priority: high]
• Insurance tail policy final confirmation [priority: high]

Day 30 — legal-supports:

• Data migration privacy review (IT owns, legal advises on data transfer mechanisms)
• Real estate lease review for assignment provisions (facilities owns, legal advises)

Day 90 — legal-owns:

• Required Consents deadline — all Required Consents must be obtained or escalated [priority: critical, deadline: pa_dates.required_consents_deadline]
• Entity rationalization decision — recommend keep separate / merge / dissolve [priority: high]
• Benefits plan assumption or termination documentation [priority: high]
• Secondary consent push — remaining outstanding consents [priority: high]
• Tier 3 change of control contract resolution [priority: critical]

Day 90 — legal-supports:

• Full HR harmonization documentation (HR owns, legal advises on employment law)

Day 180 — legal-owns:

• Entity merger filing — if rationalization decision is to merge [priority: high]
• Entity dissolution filing — if rationalization decision is to wind down [priority: high]
• Full contract novation — contracts requiring acquiror's name [priority: high]
• Rep survival tracking — note upcoming expiry date [priority: medium]

Show summary after generating:

Integration tracker initialized — [Deal code] / [Target]

Close date: [date]
Required Consents deadline: [date] ([N] days from today)
Rep survival expires: [date]

Workplan items: [N] ([N] legal-owns, [N] legal-supports)
Required Consents: [N] (from PA schedule)
Desired Consents: [N] (from diligence — no PA deadline)

Contract assignment: not yet imported — run --contracts to populate

Next step: run /corporate-legal:integration-management --contracts to import the
contract list, then --report to see your first status summary.

Mode 2: Contract Assignment

/corporate-legal:integration-management --contracts [--deal [code]]

This is the dedicated contract assignment initialization. Separate from the main init so it can be run independently and re-run when the contract list changes.

Step 1: Get the contract list

Two paths — use whichever applies:

Path A: Connected repository

Is your contract repository connected? (Google Drive, Box, SharePoint, or a VDR that's still accessible post-close?)

If yes: give me the folder path or folder name for the acquired company's contracts. I'll pull a list of what's there and read each contract for the assignment clause and counterparty.

Search the connected repository. For each document found:

• Extract filename and file path
• Read the document — identify: contract party (counterparty name), contract type (from header or subject matter), assignment clause text, change of control clause text if present, and annual value if stated.

Path B: Manual list upload

Upload a contract list. This can be:

• The Material Contracts schedule from the PA disclosure schedules
• A CSV or Excel export from their contract management system
• A manually prepared list

Minimum required columns: Contract Name, Counterparty. Helpful but optional: Contract Type, Annual Value, Assignment Clause text.

Read the uploaded list. For contracts where no assignment clause text is provided, set assignment_mechanism to "not_reviewed" and flag for follow-up.

Path C: Disclosure schedule

If neither repository nor list is available, read the Material Contracts schedule from the PA disclosure schedules (from the PA uploaded in --init). This gives the minimum required list — parties and contract types. Assignment clauses will need manual review.

Step 2: Determine assignment mechanism

For each contract, classify the assignment mechanism:

For contracts flagged in the Required Consents PA schedule: override tier to 1 regardless of assignment mechanism classification.

Step 3: Tier assignment

Tier 1 — Required Consents: [N] contracts
  Named in PA schedule, hard deadline [date], must obtain consent

Tier 2 — Material, consent required: [N] contracts
  Assignment restriction present, not in PA schedule
  Recommended timeline: obtain within Day 90

Tier 3 — Change of control provisions: [N] contracts ⚠️
  Counterparty has termination or consent right triggered by close
  ACTION REQUIRED: contact counterparty immediately — CoC may already be triggered

Tier 4 — Auto-assign / no action: [N] contracts
  Assigns automatically or by affiliate/successor provision
  Tracking only — no outreach needed

Not reviewed: [N] contracts
  Could not determine assignment mechanism — manual review required

Show tier 3 separately and prominently. A change of control clause may have already triggered on the close date — counterparty may have a right to terminate that is running right now.

Step 4: Generate status entries

For each contract, create a tracker entry with:

• All extracted fields (counterparty, type, value, mechanism, tier)
• Initial status: tier 4 → no_action; tier 3 → coc_triggered; tiers 1/2 → consent_pending; not_reviewed → not_reviewed
• pa_deadline populated for tier 1 from Required Consents schedule

Mode 3: Status Report

/corporate-legal:integration-management --report [--deal [code]]

Reads current tracker state. Produces:

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

> This status report is derived from the purchase agreement, diligence findings, and post-closing integration records. It inherits their privilege and confidentiality status — distribution beyond the privilege circle can waive privilege. Confirm the recipient list before sending.

INTEGRATION STATUS — [Deal code] / [Target]
[Date] — Day [N] post-close

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

EXECUTIVE SUMMARY
[2-3 sentence paragraph: overall status, biggest risk, key win since last report]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

REQUIRED CONSENTS  [deadline: DATE — N days remaining]
  Obtained:        [N] of [total]  ████████░░  [%]
  In negotiation:  [N]
  Outreach sent:   [N]
  Not started:     [N]
  Refused:         [N] ⚠️

⚠️ AT RISK: [counterparty] — deadline in [N] days, no response to outreach
⚠️ REFUSED: [counterparty] — PA obligation not met; escalate to outside counsel

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CONTRACT ASSIGNMENT
  Tier 1 (Required Consents):   [N] complete / [N] in progress / [N] pending
  Tier 2 (Material contracts):  [N] complete / [N] in progress / [N] pending
  Tier 3 (CoC provisions):      [N] resolved / [N] outstanding ⚠️
  Tier 4 (Auto-assign):         [N] — no action required

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

WORKPLAN — LEGAL OWNS
  🔴 OVERDUE ([N]):
    [item] — was due [date]

  ⏰ DUE THIS WEEK ([N]):
    [item] — due [date]

  ✅ COMPLETED SINCE LAST REPORT ([N]):
    [item] — completed [date]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

BLOCKERS & DECISIONS NEEDED
  [item] — blocked on: [description] — owner: [name]
  [item] — decision needed: [description] — recommend: [option]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

KEY DATES COMING UP
  [date] — [milestone / deadline]
  [date] — Rep survival expires — confirm no pending indemnification claims

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Mode 4: Update

/corporate-legal:integration-management --update [--deal [code]]

Manual update: Attorney tells Claude what changed.

"We got the Salesforce consent. Mark it obtained, assigned to [name], date today." "The entity rationalization decision is to merge. Update status and add the merger filing to Day 180." "[Counterparty] refused consent. Flag it and note we need outside counsel on whether this triggers a PA indemnification claim."

Claude updates the relevant tracker entry, recalculates any downstream status (e.g., if all tier 1 consents are now obtained, flag the PA obligation as met), and shows what changed.

Upload update: Workstream owner or outside counsel sends a status document.

Upload the status update from [outside counsel / HR lead / corp dev team]. I'll parse it and update the tracker.

Read the uploaded document. Match described items to tracker entries by counterparty name or workplan item description. Update status fields. Flag any items in the update that don't match an existing tracker entry — may be new items to add.

After any update, show:

Updated [N] items.

Changes:
  CON-003 Salesforce: not_started → obtained
  W-014 Entity rationalization: in_progress → complete

New flags:
  CON-007 [Counterparty]: refused — PA obligation may be unmet. Consider:
  outside counsel review of indemnification claim. ⚠️

Mode 5: Export

/corporate-legal:integration-management --export [--format csv|table] [--section all|consents|contracts|workplan]

Produces a flat CSV or markdown table. Default: all sections, CSV.

CSV format — one row per item, section indicated by a section column. Columns vary by section:

Workplan: id, phase, description, owner, workstream, priority, deadline, status, blocker

Consents: id, counterparty, contract_type, required_consent, pa_deadline, status, assigned_to, obtained_date, notes

Contracts: id, name, counterparty, contract_type, annual_value, assignment_mechanism, tier, required_consent, pa_deadline, status, assigned_to, notes

Export is the shareable format — suitable for outside counsel, corp dev, or a board integration update.

What this skill does not do

• It does not manage business integration workstreams (IT, HR, finance, real estate). It tracks legal's touchpoints in those workstreams and flags when legal input is needed. Ownership stays with the business function.
• It does not draft the consent request letters or novation agreements — those are produced by the written-consent skill or by outside counsel.
• It does not advise on indemnification claims or PA breach. When a consent is refused or a deadline is missed, it flags the situation — the legal analysis of consequences is the attorney's call.
• It does not track earn-out performance. Earn-out milestones and payment dates appear in the tracker as reference dates with owner set to finance. The business drives the numbers.
• It does not read contracts in real time during status reporting. Contract status is what the attorney has updated in the tracker. The skill reads the tracker, not the contracts, at report time.

Formula injection defense

Before writing any cell in Excel, Sheets, or CSV output, neutralize formula injection. Counterparty-sourced text (contract quotes, party names, registered agent data, CLM exports) is attacker-controlled. A cell starting with =, +, -, @, , , or will be interpreted as a formula or break the row structure.

• Prefix with a single quote: '=SUM(A1:A10) → =SUM(A1:A10) (displayed as text, not executed)
• Applies to every cell that contains text sourced from a document, a tool result, or a user paste. Column headers you control and computed values you produce are safe.
• CSV: also escape embedded commas, double quotes, newlines (RFC 4180 quoting).
• This is not optional. A spreadsheet your user opens in Excel that triggers a macro or exfiltrates data via DDE is a supply-chain attack on your user.

/material-contract-schedule

1. Load purchase agreement → Material Contract definition + schedule format.
2. Use the workflow below.
3. Apply definition to diligence findings. Flag edge cases.
4. Format per agreement. Consent overlay feeds closing checklist.

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /corporate-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

The purchase agreement has a rep: "Schedule 3.X lists all Material Contracts." This skill builds that schedule from the diligence findings — which contracts are material per the agreement's definition, in the format the agreement requires.

Load context

• Purchase agreement draft — for the definition of "Material Contract" and the schedule format
• ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → materiality thresholds (may differ from the agreement definition — use the agreement's)
• Diligence findings from diligence-issue-extraction — contract-level data

Workflow

Step 1: Get the definition

Pull the definition of "Material Contract" from the purchase agreement — the PA definition controls. Deal-structure differences (stock vs. asset vs. merger) can change how a prong is interpreted, and regulated-industry overlays (healthcare, defense, financial services, telecom, government contracting) can add consent requirements that live outside the PA. If the deal involves any of those overlays, research the applicable anti-assignment or novation rules (for example, federal contracts, government contracting novation, sector-specific consent statutes) and cite the controlling rule.

Common prong categories to look for in the PA definition — these are not a substitute for reading the PA, and the list the PA uses controls:

• Dollar-value threshold (annual or aggregate)
• Term length
• Change-of-control or anti-assignment provision
• Exclusivity or non-compete
• Top N customer or supplier contracts
• Real property leases
• IP licenses (in-bound and out-bound)
• Related-party agreements
• Government contracts
• Contracts outside the ordinary course

The PA's definition is the test. Apply it mechanically — every contract that meets any prong in the PA's definition goes on the schedule.

Step 2: Apply the definition to the findings

For each contract reviewed in diligence:

Edge cases to flag for human decision:

• Contract is $X-1 (just under threshold) but important to the business
• Contract meets a prong but is being terminated anyway
• Oral agreements or side letters that may or may not count

Step 3: Gather schedule data

For each included contract, the schedule typically needs:

Pull from existing diligence extractions. If a field is missing, flag it — don't guess.

Step 4: Format per the agreement

Disclosure schedules have a format — usually a numbered list or a table, sometimes with sub-parts by contract type. Match the format of the other schedules in the draft agreement.

## Schedule 3.[X] — Material Contracts

The following are the Material Contracts as of the date hereof:

### (a) Customer Contracts

1. [Agreement Title], dated [date], between [Target] and [Counterparty].
   [Brief description if the format calls for it.]
   [VDR: path]

2. [...]

### (b) Supplier Contracts

[...]

### (c) Real Property

[...]

[etc. — sub-parts per the agreement's definition structure]

Step 5: Consent tracking overlay

Separately (not in the schedule itself — this is internal), track which scheduled contracts require consent.

The consent overlay and any pre-delivery working draft of the schedule are derived from privileged diligence materials and inherit their privilege and confidentiality status — distribution beyond the privilege circle can waive privilege. The schedule itself, once delivered as an exhibit to the executed PA, is a deal document and is not privileged; strip any internal annotations before delivery.

This feeds closing-checklist.

Cross-check

Before delivering:

• Every contract that met a prong is on the schedule (completeness)
• No contract is on the schedule that doesn't meet a prong (no over-disclosure — it's a rep, not a data dump)
• Schedule is consistent with the other reps (a contract on Schedule 3.X that creates a lien should also be on the liens schedule)
• Every entry has a VDR cite so buyer's counsel can find the underlying doc

Handoffs

• From diligence-issue-extraction: Contract-level findings are the input.
• To closing-checklist: Consent items go on the checklist.

What this skill does not do

• It doesn't decide the materiality definition — that's in the purchase agreement.
• It doesn't obtain consents — it tracks which ones are needed.
• It doesn't draft the rep — it populates the schedule the rep references.

/matter-workspace

Practitioners work across multiple clients and matters. A matter workspace keeps one client or engagement's context separate from every other. This skill manages those workspaces.

Subcommands

• /corporate-legal:matter-workspace new <slug> — create a new matter workspace, run a short intake, write matter.md
• /corporate-legal:matter-workspace list — list matters with status and active flag
• /corporate-legal:matter-workspace switch <slug> — set the active matter
• /corporate-legal:matter-workspace close <slug> — archive a matter (move to ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/_archived/, never delete)
• /corporate-legal:matter-workspace none — detach from any active matter, work at practice-level only

Instructions

1. Read ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md — confirm the ## Matter workspaces section is populated. If Enabled is ✗, tell the user: "Matter workspaces are off — you're configured as an in-house practice with one client, so the plugin works from practice-level context automatically. If you actually work across multiple clients, re-run /corporate-legal:cold-start-interview --redo and select a private-practice setting. Otherwise, you don't need /matter-workspace at all." Don't error — the disabled state is the expected one for in-house users.
2. Use the workflow below.
3. Dispatch on the first token of $ARGUMENTS:
   • new → run the intake interview, write ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<slug>/matter.md, seed history.md and notes.md.
   • list → enumerate ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/*/matter.md, print a table, mark the active matter.
   • switch → update the Active matter: line in the practice-level CLAUDE.md.
   • close → move ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<slug>/ to ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/_archived/<slug>/, log the close date in history.md.
   • none → set Active matter: to none — practice-level context only.
4. Show the user what changed and confirm before writing.

Notes

• The skill never reads across matters unless Cross-matter context is on in the practice-level CLAUDE.md.
• Archiving is not deletion — closed matters remain readable for retention/conflicts purposes.
• Slugs are lowercase with hyphens. If a slug is reused across archived and active, the archived one is preserved under _archived/<slug>/.

Multi-client practitioners (private practice — solo, small firm, large firm) work across many matters. Context from one must not leak into another. This skill is the thin file-management layer that makes that true.

Default state is off. In-house users never see this — they run at practice-level only. Matter workspaces turn on at cold-start for private-practice users, or by editing ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗, this skill does not run; /corporate-legal:matter-workspace explains the disabled state and suggests /corporate-legal:cold-start-interview --redo for users who actually need matter isolation.

Storage layout

All matter data lives under:

~/.claude/plugins/config/claude-for-legal/corporate-legal/
├── CLAUDE.md                       # practice-level practice profile
└── matters/
    ├── <slug>/
    │   ├── matter.md               # client, counterparty, matter type, key facts, overrides
    │   ├── history.md              # dated log of events, decisions, drafts, reviews
    │   ├── notes.md                # free-form working notes
    │   └── outputs/                # skill outputs for this matter (optional subfolder)
    └── _archived/
        └── <slug>/                 # closed matters — readable but not active

Slugs are lowercase with hyphens. Examples: acme-msa-2026, zenith-renewal, vendor-xyz-nda.

Active matter is in the practice CLAUDE.md

The Active matter: line under ## Matter workspaces in the practice-level CLAUDE.md is the single source of truth. Switching a matter edits that line. No separate state file.

Subcommand logic

new <slug>

1. Confirm slug is not already present in matters/<slug>/ or matters/_archived/<slug>/. If reused, ask the user to pick a different slug.
2. Run the intake interview:
   • Client (the party we represent, or the internal business unit if in-house)
   • Counterparty (the other side — may be multiple)
   • Matter type (read the plugin's practice profile for typical categories; for corporate-legal: M&A buy-side | M&A sell-side | financing | board matter | entity reorg | integration project | other)
   • Confidentiality level (standard | heightened | clean-team — heightened prompts extra care in cross-matter settings)
   • Key facts (2–5 sentences: what this matter is about, who the stakeholders are, what's at stake)
   • Matter-specific overrides to the practice playbook (e.g., "client requires 24-month LoL cap not 12", "counterparty is a strategic partner — relationship-preserving tone")
   • Related matters (slugs of any connected matters)
3. Write matters/<slug>/matter.md using the template below.
4. Seed matters/<slug>/history.md with a single "Opened" entry.
5. Create an empty matters/<slug>/notes.md.
6. Do not auto-switch to the new matter. Ask: "Want to switch to <slug> now? (/corporate-legal:matter-workspace switch <slug>)"

list

Enumerate matters/*/matter.md. Read each file's front-matter or first few lines to extract status. Print a table:

Mark the currently-active matter with *. Include _archived/* under a separate "Archived" heading if any exist.

switch <slug>

1. Confirm matters/<slug>/matter.md exists. If not, offer /corporate-legal:matter-workspace new <slug>.
2. Edit the Active matter: line in the practice-level CLAUDE.md to Active matter: <slug>.
3. Show the user the matter.md summary so they can confirm they're on the right matter.

close <slug>

1. Confirm matters/<slug>/ exists.
2. Append a "Closed" entry to matters/<slug>/history.md with today's date.
3. Move matters/<slug>/ → matters/_archived/<slug>/.
4. If the closed matter was the active matter, set Active matter: to none — practice-level context only.

none

Set Active matter: in the practice-level CLAUDE.md to none — practice-level context only. Confirm with the user.

matter.md template

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this` in the practice-level CLAUDE.md]

# Matter: [Client] — [short description]

**Slug:** [slug]
**Opened:** [YYYY-MM-DD]
**Status:** active
**Confidentiality:** [standard / heightened / clean-team]

---

## Parties

**Client:** [name]
**Counterparty:** [name(s)]

## Matter type

[vendor MSA | customer agreement | NDA | SaaS subscription | amendment | renewal | other — with one-line rationale]

## Key facts

[2–5 sentences. What this matter is about. Who the stakeholders are. What's at stake. What makes it different from the default playbook.]

## Matter-specific overrides

*Any deviation from the practice-level playbook that applies to this matter and only this matter.*

- [e.g., "LoL cap: client requires 24 months, not house standard 12."]
- [e.g., "Tone: relationship-preserving — counterparty is a strategic partner."]
- [e.g., "Governing law: must be English law, not Delaware."]

## Related matters

- [slug — one line why related]

## Notes on confidentiality

[If heightened or clean-team, describe why. Who may see matter files. Whether cross-matter context is permissible even if globally on.]

history.md seed

# History: [Client] — [short description]

Append-only event log. Most recent at top.

---

## [YYYY-MM-DD] — Matter opened

Intake completed. Slug: `[slug]`. Status: active.
[Any initial context worth preserving beyond matter.md — e.g., "Opened in response to inbound MSA draft from [counterparty]."]

Cross-matter context

The practice-level CLAUDE.md has a Cross-matter context: flag. When it's off (the default), a skill working in matter A never reads files in matters/B/ for any other B. Period. This is the confidentiality guarantee the setting exists to provide.

When it's on, a skill may read files across matter folders only when the user explicitly asks it to (e.g., "compare our position on liability caps across the last five vendor matters"). Even when on, the default is to load only the active matter unless the user asks for a cross-matter view.

What this skill does not do

• Run a conflicts check. Conflicts are the practitioner's/firm's job; the intake captures what the user declares.
• Enforce retention. Closing archives a matter; it does not delete. Retention policy is out of scope.
• Auto-route outputs. The substantive skill decides where to write; this skill tells it which folder is active, not what to put in it.
• Decide whether cross-matter is appropriate. It reads the flag and obeys.

/written-consent

1. Load ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → Board & Secretary (consents repository, resolution language, state of incorporation, board composition).
2. Use the workflow below.
3. Identify the action and classify (routine / review-flag).
4. If review-flag: show outside counsel warning and confirm before proceeding.
5. Search consents repository for closest precedent. If no repository: use seed consents from ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md.
6. Draft consent in house format using precedent as base.
7. Output: consent draft + signatory checklist + review prompts.

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /corporate-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

Most routine board approvals don't need a meeting. Officer appointments, equity grants, bank authorizations, contract approvals above the officer threshold, intercompany arrangements — these happen by unanimous written consent. This skill drafts them quickly in your house format, finds the prior consent that's closest to what you need, and flags the actions where you should be getting outside counsel eyes before anyone signs.

Scope warning — read before drafting

This skill is designed for day-to-day consents with direct precedents in your repository or seed documents. Routine actions — officer appointments, equity grants, annual authorizations, standard contract approvals — are the right use case. The skill finds a prior consent that closely matches, adapts it to the current action, and produces a clean draft.

For major one-off actions, outside counsel review is prudent regardless of what this skill produces. This includes: M&A transactions (asset purchases, stock purchases, mergers, investments), financing rounds, equity issuances to new investors, change-of-control provisions, dissolution or winding down, material real estate transactions, and any action that will be scrutinized in a subsequent due diligence process.

The skill will flag automatically when the action looks like a major one-off. That flag is not a block — you can proceed. It is a prompt to think about whether a clean precedent-adapted draft is sufficient for this particular action.

Major action + urgency = stop

A board consent for a major one-off action (M&A, financing, dissolution, capital structure change, director election tied to a financing or M&A) that the user wants signed TODAY — "send for DocuSign this afternoon," "meeting in an hour," "signing tonight," "we need this before market open" — goes through outside counsel review. Not because the plugin can't draft it — because a wrong consent on a major action is a one-way door, and the urgency pressure is exactly when mistakes happen.

Trigger (both must be true):

1. The action is in the Review flag — major one-off category below (M&A, financing, dissolution, capital structure change, change-of-control provision, director election tied to a financing or M&A, material real estate transaction, any action that will appear in a future financing or M&A data room).
2. The user's ask contains an irreversibility signal — "send for DocuSign," "sign today," "board is signing this afternoon/tonight," "need this before [market open / closing / the meeting at X]," any phrasing that commits the consent to signature on the same turn.

When both are true, output this and stop:

⛔ Major action + same-day signature — I won't mark this ready to sign.

This is [action type], which is a one-way door. You've asked for it to be signed today. That combination is exactly when mistakes on a board consent become hardest to unwind.

I'll draft it — happily — but I won't mark it ready to sign without an outside-counsel look. If outside counsel is already engaged on this deal, hand them this draft. If not, this is the thing outside counsel is for. Your professional regulator (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent) can point you to a lawyer referral service that can find one same-day if needed.

Two ways forward:

1. I draft, outside counsel reviews, then signatures — the normal path for a major corporate action. Tell me to draft and I will.
2. Outside counsel is already on this deal and cleared the draft path — tell me who reviewed and when. I'll proceed and include a note that outside counsel has the draft.

I will not draft in "ready-to-send" form under same-day pressure without one of those two. This is not a delay — it's the only way a same-day major-action consent is defensible if anyone ever looks at the file.

Do not proceed to Step 1 or any drafting under this gate without an explicit response choosing path 1 or path 2. A routine consent with no major-action trigger, or a major-action consent without the same-day signature ask, follows the normal flow below — the "Outside counsel review recommended" flag on the major-one-off category still applies but does not hard-stop.

Load context

• ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → ## Board & Secretary:
  • Consents repository location
  • House resolution language
  • State of incorporation (for notice requirements)
  • Board composition (for signatory list)
  • Written consents — scope and any limits

No-precedent hard stop

If (a) no consents repository is configured in ## Board & Secretary → Consents repository, AND (b) no seed consent document has been provided to this skill (either uploaded this session or referenced in the ## Board & Secretary → Consent format section with extracted resolution/recital/authorisation language from a specific seed), STOP before drafting. Do not proceed to Step 1 intake, do not draft from a generic template, do not "get started" with a filler format.

Output exactly this block and wait for a response:

No precedent available — stopping before draft.

I don't have a precedent to match. A board consent drafted without your house format will need more correction than it saves — resolution language, recital depth, authorisation boilerplate, and signature-block conventions all carry house-specific choices that the reviewer will rewrite from scratch if I start from a generic template.

Two ways to unblock:

1. Paste or upload a prior consent (any recent UWC from this company in any category — I extract the format, not the substance), OR
2. Tell me "draft from a generic template anyway — I'll adjust the formalities myself" — only pick this if you know you'll rework the resolution language, recital style, and authorisation block by hand before circulation. Say it explicitly; I will not infer it.

Which do you want to do?

Do NOT proceed without an explicit response choosing one of those two paths. Draft attempts absent a precedent are the highest-rework-to-value output this skill can produce — the hard stop is intentional.

Step 1: Identify the action

Ask the user what action the board needs to approve. Gather:

• What is being approved? (One sentence.)
• Any supporting detail? For example: the name of the officer being appointed, the grant amount and price for an equity grant, the counterparty and contract value for a contract approval.
• Effective date: Today, or a specific date?
• Signatories: Full board, or a specific committee? If the ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md written-consent scope says certain actions require a meeting rather than consent, flag it now.
• Any director conflict? Does any director have a material interest in the action being approved? If yes: flag it. The conflicted director may still be able to sign depending on state law and the nature of the conflict, but the consent should disclose it and the user should confirm.

Action classification

Classify the action before searching for precedent:

Routine — direct precedent likely:

• Officer appointment or removal
• Equity grant (option, RSU, restricted stock) to existing plan participants
• Bank account authorization or signatory update
• Approval of a contract below a material threshold
• Annual authorization resolutions (tax matters, benefits plans, etc.)
• Intercompany loan or services agreement at arm's length terms
• Registered agent or registered office change

Review flag — major one-off, outside counsel prudent:

• M&A transaction (acquisition, merger, asset purchase, investment)
• New financing round or debt facility
• Equity issuance to a new investor
• Change-of-control provision or trigger
• Approval of an agreement that itself requires board approval under the company's charter or stockholder agreements
• Dissolution, winding down, or bankruptcy filing
• Material real estate transaction
• Any action that will appear as a board approval exhibit in a future financing or M&A data room

If the action is in the review-flag category, show this before drafting:

⚠️ Outside counsel review recommended. This looks like [action type], which is a major corporate action where a precedent-adapted draft may not be sufficient. Consider having outside counsel review before circulation. Want me to proceed with a draft anyway?

Step 2: Search for precedent

If consents repository is connected

Search the repository for the closest prior consent. Search strategy:

1. Search by action type keyword (e.g., "officer appointment", "equity grant", "bank authorization")
2. Return the most recent matching consent, or ask the user to choose if multiple close matches exist:

I found [N] prior consents that look like this:

1. [Consent title / description] — [Date]
2. [Consent title / description] — [Date]

Which one is closest to what you need? Or should I use the most recent?

3. Read the selected consent. Extract: resolution language, recital structure, authorization language, any specific conditions or carve-outs.
4. Note any differences between the prior action and the current one that will need to be updated in the draft.

If no repository (seed documents only)

Extract the format from the seed consents in ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md. Note that no precedent search is available — the draft will follow house format but without substantive precedent matching. Flag this to the user:

No consents repository is connected, so I'm working from your seed documents for format. For this action type specifically, you may want to check whether you have a prior consent to use as a substantive starting point.

Step 3: Draft the consent

Use the house format. The structure below is the standard — adapt to match the precedent or seed format exactly.

UNANIMOUS WRITTEN CONSENT
[OF THE BOARD OF DIRECTORS / OF THE [COMMITTEE NAME]]
OF [COMPANY NAME]

[Date]

The undersigned, constituting all of the members of the
[Board of Directors / [Committee]] of [Company Name], a [State] [corporation /
limited liability company] (the "Company"), hereby adopt the following
resolutions by written consent pursuant to [Section X of the [State] General
Corporation Law / applicable operating agreement], in lieu of a meeting:

[AGENDA ITEM / ACTION HEADING — if multiple resolutions]

WHEREAS, [background recital — one or two sentences stating the relevant facts
and why the board is being asked to act]; and

WHEREAS, [additional recital if needed]; and

NOW, THEREFORE, BE IT RESOLVED, that [the specific action being approved,
in precise language — name names, state amounts, reference the specific
agreement or instrument where applicable];

RESOLVED FURTHER, that [any related or implementing resolution — e.g., the
specific officers authorized to sign documents, the authority granted];

RESOLVED FURTHER, that the officers of the Company are, and each of them
hereby is, authorized and directed, in the name and on behalf of the Company,
to take all actions and to execute and deliver all documents, instruments,
certificates and agreements as such officers may deem necessary or appropriate
to carry out the intent and purposes of the foregoing resolutions; and

RESOLVED FURTHER, that any actions previously taken by any officer of the
Company in connection with the foregoing are hereby ratified, confirmed and
approved in all respects.

[Repeat WHEREAS / RESOLVED block for each additional action if multi-resolution consent]

This Written Consent may be executed in one or more counterparts, each of
which shall be deemed an original and all of which together shall constitute
one and the same instrument. Electronic signatures shall be deemed original
signatures for all purposes.

[SIGNATURE BLOCKS — one per required signatory]

_______________________________
[Director Name]
[Title, if applicable]
Date: _______________

[Repeat for each director / committee member]

Resolution drafting notes

• Be precise. Vague resolutions create problems in due diligence. "Approved the transaction" is not useful. "Approved the Asset Purchase Agreement dated [date] between [Buyer] and [Company], substantially in the form attached hereto as Exhibit A" is.
• Name the authorized signatories. Don't just say "officers" if a specific officer needs authority for a specific thing. Name them.
• Reference exhibits. If a document is being approved, attach it as an exhibit and reference it in the resolution. The consent is only as useful as its specificity.
• Match the house language exactly. "RESOLVED, THAT" vs. "BE IT RESOLVED" vs. "RESOLVED" — use whatever is in the precedent or seed documents. Do not switch formats within a consent.

Step 4: Confirm the consent rules for the state of incorporation

Check the state of incorporation in ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md. Research the written-consent requirements for that state before drafting:

• Is unanimity required for a board written consent, or is a lower threshold permitted?
• Is notice to non-signatory directors required? On what timing?
• Is notice to non-signatory stockholders required (for stockholder consents)? On what timing?
• What form of signature is valid (wet ink, electronic, counterparts)?
• Does the charter or bylaws override any default rule — e.g., a higher signature threshold, a different notice window, a restriction on which actions can be taken by consent?

Cite the controlling statute section and any charter/bylaw provisions relied on. Verify currency — state corporate codes are amended regularly. Flag uncertainty for attorney verification rather than stating a rule you haven't confirmed.

If ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md records a house position on any of these questions, apply it and note the legal backstop being relied on. Add a short "State-law notice" block to the output summarizing what you confirmed (or flagged) so the user isn't left wondering.

Step 4.5: Consequential-action gate (execute consent)

Before proceeding to output: Read ## Who's using this in ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md. If the Role is Non-lawyer:

Executing a written consent has legal consequences — it binds the entity and becomes a corporate record. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:

• What the action is (the resolution)
• What the analysis found (state-law notice, signature threshold, any flagged conflicts)
• Open questions (anything flagged for attorney verification above)
• What could go wrong (invalid consent, breach of fiduciary duty, signature defect, conflict not properly handled)
• What to ask the attorney (is this the right vehicle; are there missing recitals; does the charter/bylaws permit consent for this action)

If you need to find an attorney, solicitor, barrister, or other authorised legal professional: contact your professional regulator (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent) for a referral service.

Do not produce the final signatory-ready draft past this gate without an explicit yes. Research, format extraction, and a marked-DRAFT for attorney review are fine.

Step 5: Output

Produce:

1. The consent draft — complete, ready to review and circulate. The executed written consent itself is a corporate record, not privileged; do not apply the work-product header to the consent as circulated. The drafting notes, signatory tracker, and analysis below are work product — prepend the work-product header from ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md ## Outputs (it differs by user role — see ## Who's using this):

   [WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]
   

2. Signatory checklist:

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

SIGNATORY CHECKLIST — [Action] — [Date]

Required signatories (unanimous consent required):
□ [Director Name 1]
□ [Director Name 2]
□ [Director Name 3]
[etc. — pulled from board composition in `~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md`]

Conflict disclosures:
[None / [Director Name] has a disclosed interest — confirm whether recusal or disclosure is appropriate]

State law notice: [confirmed-rule-for-state-of-incorporation / confirm]

3. Review prompts:

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

BEFORE CIRCULATING — check:
□ Resolution language precisely describes the action (no vague approvals)
□ Correct effective date
□ All required exhibits attached and referenced
□ Authorised signatories named correctly
□ Any director conflicts disclosed or resolved
□ For major actions: outside counsel has reviewed

4. Final note on the draft — add before circulation. Prepend to the consent draft as a separate pre-execution note, then strip before the consent is signed:

This is a draft for attorney review, not an executed consent. Executing it binds the entity and becomes a corporate record — a licensed attorney reviews, edits as needed, and takes professional responsibility before it goes out. Do not circulate for signature unreviewed.

What this skill does not do

• It does not determine whether an action legally requires board approval — that judgment belongs to the attorney.
• It does not advise on director fiduciary duties or conflict of interest resolution — it flags conflicts, the attorney handles them.
• It does not replace outside counsel review for major transactions — the scope warning is genuine, not boilerplate.
• It does not circulate the consent — output is for the attorney to review and send via their own process.
• It does not track returned signatures — the signatory checklist is a starting point; signature tracking is manual or handled by your document management process.

/cold-start-interview

1. Check ~/.claude/plugins/config/claude-for-legal/employment-legal/CLAUDE.md. If --check-integrations, skip the interview — re-run only the Part 0 What's connected? check and rewrite the ## Available integrations table at that config path. When probing: only report ✓ if an MCP tool call actually succeeded. Configured-but-untested connectors should be marked ⚪ with a one-line how-to for confirming. Never report ✓ based on .mcp.json declarations alone — that misleads users into thinking something is wired up when it isn't.
2. Run the interview below (Part 0 first — role + integrations — then footprint): states/countries, hiring/term review triggers, severance practice.
3. Seed docs: handbook + 3 termination memos.
4. Build jurisdiction-specific escalation table.
5. If a populated CLAUDE.md (no [PLACEHOLDER] markers) exists at ~/.claude/plugins/cache/claude-for-legal/employment-legal/*/CLAUDE.md but not at the config path, copy it to the config path and tell the user what was migrated.
6. Write ~/.claude/plugins/config/claude-for-legal/employment-legal/CLAUDE.md, creating parent directories as needed.

Cold-Start Interview: Employment Counsel

Purpose

Employment law is jurisdictional down to the bone. The right answer in Texas is the wrong answer in California. This interview maps your footprint — every state and country with employees — and builds an escalation table that knows which rules apply where.

Cold-start check

Read ~/.claude/plugins/config/claude-for-legal/employment-legal/CLAUDE.md:

• Does not exist → start the interview.
• Contains <!-- SETUP PAUSED AT: --> → greet the user and offer to resume from that section.
• Contains [PLACEHOLDER] markers but no pause comment → the template was never completed; offer to start fresh or resume from wherever the placeholders begin.
• Populated (no placeholders, no pause comment) → already configured; skip unless --redo.

The template structure lives at ${CLAUDE_PLUGIN_ROOT}/CLAUDE.md — use it as the section scaffold. Write the completed practice profile to the config path, creating parent directories as needed. If a CLAUDE.md exists at the old cache path ~/.claude/plugins/cache/claude-for-legal/employment-legal/*/CLAUDE.md but not here, copy it forward.

Check for the shared company profile

Look for ~/.claude/plugins/config/claude-for-legal/company-profile.md.

• If it exists: Read it. Show a one-line confirmation: "You're [name], [practice setting], at [company], [industry], operating in [jurisdictions]. Right? (Or say 'update' to change the shared profile.)" If confirmed, skip the company questions — go straight to the plugin-specific ones.
• If it doesn't exist: You'll be the first plugin this user set up. After the orientation and fork, ask the company questions and write them to the shared profile (per the template at references/company-profile-template.md in the plugin root), then continue with the plugin-specific questions. Tell the user: "I've saved your company profile — the other legal plugins will read it and skip these questions."

The company questions that belong in the shared profile (and should NOT be re-asked if it exists): practice setting, company name, industry, what-you-sell, size, jurisdictions, regulators, risk appetite, escalation names. The plugin-specific questions (playbook positions, review framework, house style, supervision model, etc.) stay per-plugin.

Install scope check

Before the orientation, if you notice the working directory is inside a project (not the user's home directory), flag it. Say once:

Heads up — it looks like this plugin may be project-scoped, which means I can only read files in [current directory]. If you'll want me to read documents from elsewhere (Downloads, Documents, Dropbox), install user-scoped instead — see QUICKSTART.md. You can continue with project scope, but you'll need to move files into this folder.

Ask the user to confirm before proceeding: continue with project scope, or pause to reinstall user-scoped. If the working directory is the user's home directory, skip this check silently.

Before the interview starts

Open with the fork-first preamble. Keep it to 3-4 short lines. Ask quick-or-full before anything else.

employment-legal is for people who handle hiring, terminations, investigations, leave, policies, worker classification, and international expansion. Not your area? /legal-builder-hub:related-skills-surfacer.

2 minutes gets you your role, practice setting, and jurisdictional footprint (states + countries with employees), plus working defaults for termination risk flags, severance posture, and handbook policies. 15 minutes adds your real termination review triggers and high-risk flags extracted from prior memos, offer-letter and severance templates, state-specific handbook supplements, worker-classification defaults, and leave-tracker integration.

Quick or full? (Upgrade any time with /cold-start-interview --full.)