Uma Claude Skill que recebe o NDA ou MSA da contraparte em .docx, classifica cada cláusula contra o playbook red/yellow/green da empresa, propõe redlines extraídos de uma biblioteca de posições-fallback pré-redigidas e sinaliza qualquer coisa fora do playbook para um advogado humano. A skill produz um documento Word com tracked changes mais um sumário de desvios de uma página que o time in-house consegue colar no canal do deal. Coloque o playbook uma vez; rode em todo contrato inbound dali em diante.
Quando usar
Use essa skill quando um NDA, MSA, DPA, order form ou contrato de fornecedor inbound chega e você quer o redline de primeira passada ancorado em política antes de um advogado abrir o arquivo. A economia faz sentido quando o volume de contratos é alto o bastante para o ganho de tempo por deal se acumular — tipicamente um time de legal-ops lidando com 30+ contratos inbound por mês no nível Tier 2-3 de um contract review SOP. Abaixo desse volume, o overhead de manutenção do playbook ultrapassa o ganho.
A skill assume que você já tem um playbook documentado (veja o NDA playbook e o MSA redlining rubric para a estrutura que ela espera). Se o playbook ainda não existe, construa primeiro — a skill amplifica a política, ela não a inventa.
Quando NÃO usar
Aprovação final ou envio do redline de volta para a contraparte. A skill propõe; um advogado humano nomeado revisa cada mudança antes dela sair. O output é um pontapé inicial, não um sign-off.
Edições no seu próprio template de contrato source-of-truth. Mudanças de template são atualização de playbook — edite references/1-playbook-template.md diretamente para que toda execução futura pegue a nova posição. Não rode a skill no seu próprio template “para refrescar”.
Instrumentos altamente sob medida. Definitive agreements de M&A, cessões de PI complexas, side letters de indústria regulada — o playbook não consegue codificar isso. A skill vai sinalizar toda cláusula como fora-de-política e queimar tokens fazendo isso.
Drafts de rodada final de negociação. Na turn 3, os redlines são concessões específicas do deal que o playbook não consegue antecipar. A skill é só para a posição de abertura.
Privileged work product roteado por um vendor de IA não-Tier-A. Se a política de IA da sua empresa exclui o modelo que a skill chamaria, escale para um advogado humano em vez de afrouxar a política. Privilégio não vale a velocidade.
Setup
Coloque o bundle. Posicione o conteúdo de apps/web/public/artifacts/contract-redline-claude-skill/ no seu diretório de skills do Claude Code (~/.claude/skills/contract-redline/) ou faça upload da pasta para um project no Claude.ai. A skill expõe um único entry point que classifica e faz redline em um contrato passado.
Substitua os templates. O bundle vem com três arquivos-template em references/. Substitua cada um pelo conteúdo real da sua empresa antes da primeira execução:
references/1-playbook-template.md — suas posições red/yellow/green por tipo de cláusula.
references/2-fallback-positions.md — parágrafos drop-in aprovados pelo counsel que a skill substitui verbatim (sem parafrasear).
references/3-escalation-criteria.md — as regras que decidem quando uma cláusula é roteada para um humano em vez de receber um redline proposto. Criticamente, é também onde você lista os vendors de IA que autoriza para legal work product — a skill se recusa a rodar caso contrário.
Teste em um contrato conhecido. Rode contra um contrato em que você já fez redline manualmente e diff os outputs. Ajuste o playbook onde as posições da skill parecem fora; ajuste os parágrafos de fallback onde a redação soa engessada. Duas ou três iterações chegam a um bom baseline.
Conecte ao intake. Quando um novo contrato chega via intake do Ironclad ou e-mail, o revisor designado solta o .docx na skill e recebe o output com redline em cerca de 60 segundos. O revisor abre o .docx no Word, percorre as tracked changes (cada uma carrega um comentário do Word citando o ID da seção do playbook que casou) e só envia de volta à contraparte depois da sua própria revisão.
O que a skill faz de fato
A skill roda quatro sub-tarefas em ordem; elas não são paralelizadas porque cada passo depende do contexto do anterior. O método completo, com a justificativa de engenharia, mora em apps/web/public/artifacts/contract-redline-claude-skill/SKILL.md. Em resumo:
Classificar o tipo de contrato. NDA (mútuo / unilateral), MSA, DPA, order form, contrato de fornecedor, ou “outro”. Se “outro”, parar e emitir um único bloco de escalada. A skill não tenta redline em tipos de contrato que o playbook não cobre — esse é o modo de falha silenciosa mais comum.
Classificação cláusula por cláusula. Quebre o contrato por heading (com fallback para parsing por seção numerada). Para cada cláusula, casar com uma entrada do playbook por heurística de tipo de cláusula e classificar como green (aceitável), yellow (substituição por fallback), red (rewrite obrigatório), ou out-of-playbook (escalar). Toda classificação cita no output o ID da seção do playbook que casou, para que o revisor consiga auditar decisões em segundos.
Proposta de redline. Para toda cláusula yellow, cole verbatim o parágrafo de fallback correspondente de references/2-fallback-positions.md. Para toda cláusula red, cole o parágrafo must-have. Por que parágrafos pré-redigidos em vez de rewrites livres: counsel já revisou essa redação. Rewrites livres introduziriam redação nova a cada execução e forçariam o revisor a reler cada fallback do zero — destruindo o ganho de tempo.
Sinalização de escalada. Toda cláusula out-of-playbook e toda cláusula que casa uma regra em references/3-escalation-criteria.md ganha um bloco de escalada em vez de um redline. A skill não chuta.
A realidade do custo
O custo em tokens por contrato depende do tamanho e da contagem de cláusulas. Números concretos:
biblioteca de fallbacks + critérios de escalada), output ~4k tokens (rationale por
cláusula + sumário). Nos preços do Claude Sonnet 4.5 (US$ 3 / MTok input, US$ 15 / MTok output), isso fica em torno de US$ 0,08 por contrato.
MSA típico (15-25 páginas, ~10k palavras). Input ~14k tokens, output ~10k tokens. Aproximadamente US$ 0,20 por contrato.
Run rate mensal a 100 contratos (50 NDAs + 50 MSAs). Cerca de US$ 14 de custo em tokens — ordem de magnitude menor que o ganho de tempo humano (uma hora de paralegal a US$ 90/h fully loaded cobre ~640 contratos de custo da skill).
O custo real é a manutenção do playbook: counsel precisa manter references/1-playbook-template.md e references/2-fallback-positions.md atualizados. Reserve duas horas de tempo de senior counsel por trimestre para refrescar os dois, mais uma hora por trimestre para triar padrões de escalada e dobrar de volta no playbook as cláusulas out-of-playbook recorrentes.
Métrica de sucesso
Duas métricas, observadas juntas, te dizem se a skill está justificando o uso:
Redução de cycle-time em redlines de primeira passada. Baseline: tempo mediano do intake do contrato até “primeira passada de redline pronta para revisão humana”. Alvo: reduzir a mediana em 60-75%. Um time baselineado em 90 minutos por redline de primeira passada deveria aterrissar em 25-35 minutos (a skill produz em 60 segundos; a revisão humana faz o resto).
% de cláusulas sinalizadas para revisão humana. Faixa-alvo: 15-25% das cláusulas por contrato. Abaixo de 10% significa que o playbook é permissivo demais (a skill está carimbando linguagem de zona amarela como verde) — aperte o rubric. Acima de 35% significa que o playbook não cobre tipos de cláusula suficientes — estenda.
Se a métrica de cycle-time não se mexe em 30 dias após o go-live, o gargalo é o passo de revisão humana, não o redline. Causa comum: o revisor não confia nas strings de rationale e relê toda cláusula do zero. Corrija fazendo as strings de rationale citarem IDs de seção do playbook (o que a skill já faz por default) e treinando os revisores a escanear os IDs.
vs alternativas
A decisão é entre essa skill e um especialista construído por vendor:
vs LawGeex ou BlackBoiler. São produtos SaaS de vendor com modelos pré-treinados em milhões de contratos. Vencem em NDAs Tier 1 (auto-aprovação contra um playbook padrão) e em velocidade de deployment se você ainda não tem um playbook documentado. Perdem quando seu playbook tem posições incomuns que o vendor não viu, quando a transparência em nível de token importa (a skill cita os IDs de seção do seu playbook; vendors citam o confidence do próprio modelo), e em preço (seats de vendor custam US$ 500-2k/seat/mês vs ~US$ 0,20/contrato de custo em token da skill mais a amortização do tempo de paralegal).
vs Ironclad AI Assist ou Spellbook. Embutidos no CLM / Word respectivamente; UX melhor dentro da ferramenta que você já usa; mais fracos em impor seu playbook específico porque a ancoragem é parcialmente o treinamento geral do vendor. Escolha esses se você quer zero esforço de deployment e não precisa de auditoria com citação por ID de seção.
vs redlines manuais conduzidos por paralegal. O status quo na maioria das empresas. Qualidade maior em cláusulas novas (humanos fazem pattern-match melhor em linguagem incomum), custo por contrato muito maior, turnaround mais lento. A skill não é substituta do paralegal — ela desloca o tempo do paralegal de digitar para julgar.
O sweet spot da Claude Skill é o contrato de alto volume e mid-stakes em que o time in-house quer a IA fazendo a primeira passada mas espera revisão humana em todo output e exige que todo redline rastreie até uma posição documentada do playbook. Se você não consegue apontar para a entrada do playbook por trás de um redline, o redline não sai.
Pontos de atenção
Drift silencioso de playbook. Um playbook com meses de desatualização produz redlines confiantes a partir de posições velhas. Guarda: todo output escreve a data last_reviewed do playbook no cabeçalho do sumário. O revisor rejeita qualquer output em que essa data tem mais de 90 dias, e o playbook é refrescado antes de re-rodar.
Cláusula nova perdida por mismatch de heurística. Headings rimam: “non-solicitation” vs “non-compete”, “Limitation of Liability” vs “Cap on Damages”. Guarda: toda classificação de cláusula cita no output o ID da seção do playbook que casou. O revisor escaneia os IDs citados e corrige mismatches antes do redline sair. Sem a citação, o revisor não consegue dizer que a skill casou errado.
Vazamento de privilégio via vendors não-Tier-A. Drafts da contraparte contêm contexto sob privilégio advogado-cliente, especialmente em DPAs e side letters. Guarda: a skill se recusa a rodar a menos que o modelo configurado apareça na lista de vendors permitidos no topo de references/3-escalation-criteria.md. Pré-condição hard; nenhuma flag de CLI burla.
Qualidade do playbook é tudo. Um playbook vago produz redlines vagos. Codifique posições explicitamente, com linguagem de fallback de exemplo em references/2-fallback-positions.md, não princípios abstratos só em references/1-playbook-template.md.
Não é substituto para revisão jurídica. Todo output de redline é revisado por humano antes de voltar para a contraparte. A skill poupa tempo no primeiro draft, não no julgamento.
Stack
Claude — runtime da Skill (Claude Code ou Claude.ai com custom Skills habilitado).
Ironclad — CLM para intake e armazenar a versão com redline resultante. Opcional, mas o pareamento típico para um time de legal-ops rodando isso em volume.
Microsoft Word — para abrir o .docx com redline. As tracked changes nativas carregam as strings de rationale como comentários do Word.
---
name: contract-redline
description: Propose first-pass redlines on an incoming counterparty NDA or MSA by classifying every clause against the firm's playbook (red / yellow / green), drafting fallback language for fallback-position clauses, and flagging anything outside the playbook for human legal review. Use before a lawyer touches the draft, never as the final authority.
---
# Contract redline
## When to invoke
Invoke when a counterparty has sent an inbound `.docx` of an NDA, MSA, DPA, order form, or vendor agreement, and the in-house team wants a first-pass redline grounded in the firm's documented playbook before a human attorney opens the file. Typical trigger: a contract lands in the [Ironclad](/en/tools/ironclad/) intake queue (or email) and the assigned reviewer wants a 60-second head start instead of a blank page.
Do NOT invoke this skill for:
- **Final approval or sending the redline back to the counterparty.** The skill proposes; a named human attorney reviews every change before it leaves.
- **Edits to the firm's own contract-as-source-of-truth template.** Template changes are a playbook update, not a per-deal redline. Update the playbook reference file directly so every future run sees the change.
- **Anything privileged that has not been routed through a Tier-A AI vendor with a signed BAA / DPA covering legal-work product.** If your vendor list excludes the model you would call, escalate to the human attorney instead.
- **Highly bespoke instruments** (M&A definitive agreements, complex IP assignments, regulated-industry side letters). The playbook does not cover these; the skill will flag every clause as out-of-policy and waste tokens.
- **Final-round negotiation drafts.** By the time a contract is in turn 3+, the redlines are deal-specific concessions that the playbook cannot encode.
## Inputs
- Required: `incoming_draft` — path to the counterparty's `.docx` (or the pasted text if `.docx` is not available). The skill does not accept image PDFs unless an OCR pre-step has produced text.
- Required: `playbook` — path to the active red/yellow/green playbook file in `references/`. Defaults to `references/1-playbook-template.md`. Replace the template with your firm's actual positions before first run.
- Optional: `counterparty_profile` — free-text notes on the counterparty (e.g. "Fortune 100 customer, prior contract on file, low leverage on our side"). The skill uses this to bias toward the *fallback* column rather than the *red* column on yellow-zone clauses.
- Optional: `deal_context` — TCV band, strategic value, regulatory overlay, jurisdiction. Drives the escalation criteria in `references/3-escalation-criteria.md`.
## Reference files
Always read the following from `references/` before redlining. Without them, the output is a generic AI-flavored redline disconnected from firm policy.
- `references/1-playbook-template.md` — the red/yellow/green positions per clause type, plus fallback language. Replace the template with your firm's actual playbook before first use.
- `references/2-fallback-positions.md` — pre-drafted fallback paragraphs for the most-negotiated clauses (LoL cap, indemnity, IP ownership, term/termination, governing law, data protection). The skill cites these by section ID in rationale strings instead of re-drafting from scratch each run.
- `references/3-escalation-criteria.md` — the rules that decide whether a given clause flips from "skill proposes redline" to "skill flags for human attorney." Examples: any clause not present in the playbook, any clause whose proposed redline introduces a new defined term, any DPA-adjacent clause when `deal_context` mentions EU/UK data subjects.
## Method
Run the four sub-tasks in order. Do not parallelize: classification feeds fallback selection, which feeds escalation flagging.
### 1. Classify the contract type
Read the document. Identify it as one of: NDA (mutual or one-way), MSA, DPA, order form, vendor agreement, or "other." If "other," stop and emit a single escalation block telling the reviewer the playbook does not cover this instrument. Do not attempt redlines on contract types the playbook does not address — this is the most common silent-drift failure mode.
### 2. Clause-by-clause classification against playbook
Split the contract into clauses (heading-based; fall back to numbered-section parsing). For each clause:
- Match it to the corresponding playbook section by clause-type heuristic ("Limitation of Liability" / "LOL" / "Cap on Damages" all map to the LoL playbook entry).
- Classify the counterparty's drafted language as one of `green` (acceptable as drafted), `yellow` (acceptable with fallback substitution), `red` (requires removal or significant rewrite), or `out-of-playbook` (no matching playbook entry — escalate).
- Record the matched playbook section ID. Every classification cites a section so the reviewer can audit the decision.
If two clauses both seem to match a single playbook entry (e.g. two overlapping confidentiality sections), classify both and note the overlap in the output — do not silently merge.
### 3. Redline proposal with fallback selection
For every `yellow` clause, pull the corresponding fallback paragraph from `references/2-fallback-positions.md` and propose it as the replacement. For every `red` clause, propose the playbook's "must-have" position (the walk-away language). Distinguish must-have vs nice-to-have in the rationale string so the reviewer knows which redlines are negotiation-floor and which are negotiation-room.
Why this method (not "let the model rewrite freely"): pre-drafted fallback paragraphs have already been reviewed by counsel. Free-form rewrites would introduce novel language each run and force the reviewer to re-read the fallback every time — defeating the time saving.
### 4. Escalation flagging
For every clause classified `out-of-playbook`, and for every clause meeting the rules in `references/3-escalation-criteria.md`, emit an escalation block instead of a redline. The reviewer sees the original text, the trigger (why this hit escalation), and a "needs human attorney" stamp. The skill does not guess on these.
## Output format
Write a single `.docx` of the contract with tracked changes plus a sibling markdown summary. The summary's literal format:
```markdown
# Redline summary — {Contract title}
Contract type: {NDA mutual | MSA | DPA | order form | vendor agreement | other}
Playbook version: {playbook last_reviewed date}
Total clauses: {N}
- Green (no change): {count}
- Yellow (fallback proposed): {count}
- Red (must-have rewrite proposed): {count}
- Out-of-playbook (escalated): {count}
---
## Clause 4.2 — Limitation of Liability
**Original (counterparty draft):**
> Provider's aggregate liability under this Agreement shall not exceed
> the fees paid in the three (3) months preceding the claim.
**Classification:** red — playbook section LOL.001
**Proposed redline (must-have):**
> Provider's aggregate liability under this Agreement shall not exceed
> the greater of (a) twelve (12) months of fees paid preceding the claim
> or (b) USD 1,000,000.
**Rationale:** Playbook LOL.001 sets the floor at 12 months of fees with a
USD 1M minimum; 3-month caps are walk-away. Pulled fallback paragraph from
`references/2-fallback-positions.md` §LOL.001.
---
## Clause 9.3 — Source-Code Escrow
**Original:**
> Provider shall deposit source code with a mutually agreed escrow agent
> within thirty (30) days of execution.
**Escalation: out-of-playbook**
- **Trigger:** No source-code-escrow position in playbook v2026-04-12.
- **Action:** Human attorney to draft position. Do not propose redline.
---
```
The Word `.docx` carries the same redlines as native tracked changes with the rationale string attached as a Word comment on each edit. The reviewer works in Word; the markdown summary is for the deal channel and the audit trail.
## Watch-outs
- **Silent playbook drift.** If the playbook file is months out of date, the skill will confidently propose stale positions. Guard: every output writes the playbook's `last_reviewed` date in the summary header. Reviewer rejects any output where that date is older than 90 days and the playbook is refreshed before re-running.
- **Privilege leakage via non-Tier-A vendors.** Counterparty drafts can contain attorney-client-privileged context (especially in DPAs and side letters). Guard: the skill refuses to run unless the configured model appears in `references/3-escalation-criteria.md`'s allowed-vendors list. Treat this as a hard precondition; do not bypass with a CLI flag.
- **Novel clauses that pattern-match a playbook entry incorrectly.** A "non-solicitation" clause is not a "non-compete" clause, but the headings rhyme. Guard: every clause classification cites the matched playbook section ID in the output. Reviewer scans the cited IDs; mismatches surface visually and can be corrected before the redline goes back.
- **Jurisdiction differences.** A LoL position legal in Delaware may be unenforceable in Germany. Guard: `deal_context.jurisdiction`, when set to any non-US value, escalates LOL, IP, and warranty clauses to the human attorney instead of proposing a redline. Default behavior assumes US law and the summary header makes that explicit.
- **Free-form rewrites instead of fallback substitution.** The skill must pull the fallback paragraph from `references/2-fallback-positions.md` verbatim, not paraphrase. Guard: rationale strings include the fallback section ID; if any rationale lacks an ID, the reviewer treats it as a hallucinated rewrite and rejects.
# Redline playbook — TEMPLATE
> Replace this template's contents with your firm's actual red/yellow/green
> positions. The contract-redline skill reads this on every run; without
> your real playbook, every output is generic and untrustworthy.
>
> Convention: every entry has a stable ID (`LOL.001`, `IP.002`, etc.) so
> the skill can cite it in rationale strings and the reviewer can audit
> the decision in seconds.
## How to read this file
For each clause type, three columns:
- **Green (acceptable as drafted).** Do nothing. Skill leaves the clause untouched.
- **Yellow (negotiation room — propose fallback).** Skill substitutes the fallback paragraph from `2-fallback-positions.md` §<ID>.
- **Red (must-have — propose walk-away rewrite).** Skill substitutes the must-have paragraph from `2-fallback-positions.md` §<ID>.
Anything not listed below is **out-of-playbook** and goes to escalation.
## Playbook last_reviewed
`{YYYY-MM-DD}` — bump on every material edit. Skill warns if older than 90 days.
---
## Limitation of Liability — `LOL.001`
| Condition | Position |
|---|---|
| Cap ≥ 12mo fees AND ≥ USD 1M floor | green |
| Cap 6-12mo fees, no floor | yellow — propose 12mo + USD 1M floor |
| Cap < 6mo fees OR < USD 250k floor | red — must-have rewrite |
| Uncapped liability for any clause other than IP indemnity, breach of confidentiality, or willful misconduct | red |
## Indemnity — `IDM.001`
| Condition | Position |
|---|---|
| Mutual indemnity for third-party IP claims, capped at LoL | green |
| One-way indemnity (us only) for third-party IP claims | yellow — propose mutual |
| Indemnity for "any breach" or "any claim arising from the Agreement" | red — narrow to third-party IP + willful misconduct |
| Indemnity uncapped without separate uncapped basket carve-out | red |
## IP Ownership — `IP.001`
| Condition | Position |
|---|---|
| We retain ownership of pre-existing IP, customer owns customer data, work-for-hire only when explicitly scoped | green |
| Joint ownership of "improvements" or "derivative works" | yellow — propose us-owned with non-exclusive license back |
| Customer owns all IP including our pre-existing tools / methodologies | red — must-have rewrite |
## Term & Termination — `TERM.001`
| Condition | Position |
|---|---|
| Initial term ≤ 36mo, auto-renew opt-out window 30-90 days, termination for material breach with 30-day cure | green |
| Auto-renew opt-out window < 30 days | yellow — propose 60 days |
| Termination for convenience by counterparty without prorated refund | yellow — propose mutual T-for-C with refund schedule |
| No termination right for material breach | red — must-have rewrite |
## Governing Law & Venue — `LAW.001`
| Condition | Position |
|---|---|
| Delaware, New York, or our home state; venue tied to that state's courts | green |
| Counterparty's home state, US jurisdiction | yellow — propose neutral (Delaware) |
| Non-US jurisdiction (any) | escalate to human attorney; do not propose redline |
| Mandatory arbitration with class-action waiver | yellow — propose carve-out for IP injunctive relief |
## Data Protection — `DPA.001`
| Condition | Position |
|---|---|
| Standard DPA referenced as exhibit, SCCs for non-EU transfers, sub-processor list with notification | green |
| No DPA exhibit but data-handling clauses inline | yellow — propose attaching firm-standard DPA |
| EU/UK personal data + no SCCs OR no transfer impact assessment language | red — must-have rewrite |
| Any reference to GDPR with deal_context.jurisdiction = non-US | escalate |
## Confidentiality — `CONF.001`
| Condition | Position |
|---|---|
| Mutual NDA, 3-5 year survival, standard exclusions (publicly known, independently developed, etc.) | green |
| One-way NDA when we are also disclosing | yellow — propose mutual |
| Survival > 5 years for general Confidential Information (excluding trade secrets, which can be perpetual) | yellow — propose 5 years |
| No standard exclusions | red — must-have rewrite |
## Warranties & Disclaimers — `WAR.001`
| Condition | Position |
|---|---|
| Mutual warranty of authority + non-infringement, standard "as-is" disclaimer for everything else | green |
| Implied warranties of fitness/merchantability not disclaimed | yellow — propose disclaimer |
| Warranty of "uninterrupted" or "error-free" service | red — must-have rewrite |
---
## Out-of-playbook examples (for reviewer awareness)
The skill should escalate, not redline, when it sees:
- Source-code escrow clauses
- Most-favored-nation pricing clauses
- Exclusivity or non-solicitation lasting > 12 months
- Insurance coverage requirements above firm's standard policy limits
- Any clause that introduces a new defined term not in the playbook
# Fallback positions library — TEMPLATE
> Pre-drafted paragraphs that the contract-redline skill substitutes verbatim
> when proposing yellow-zone (fallback) and red-zone (must-have) redlines.
>
> Why pre-drafted: counsel has already reviewed this language. Free-form
> rewrites would introduce novel wording every run and force the reviewer
> to re-read each fallback from scratch — defeating the time saving.
>
> Replace this template's contents with paragraphs your firm's counsel has
> approved. Keep the section IDs (`LOL.001`, `IDM.001`, etc.) stable so the
> skill can cite them in rationale strings.
## Convention
Each section has two paragraphs:
- **Fallback (yellow zone).** What the skill proposes when the counterparty draft is in the playbook's yellow band — negotiation room, but acceptable.
- **Must-have (red zone).** What the skill proposes when the counterparty draft is in the playbook's red band — walk-away language.
Both are written as drop-in replacements for the counterparty clause, in the firm's house voice. The skill does not paraphrase; it pastes.
---
## §LOL.001 — Limitation of Liability
**Fallback paragraph:**
> Subject to the exceptions in §LOL.001(b), each party's aggregate liability
> arising out of or related to this Agreement shall not exceed the greater of
> (i) the fees paid or payable by Customer to Provider in the twelve (12)
> months preceding the event giving rise to the claim, or (ii) USD 500,000.
**Must-have paragraph:**
> Subject to the exceptions in §LOL.001(b), each party's aggregate liability
> arising out of or related to this Agreement shall not exceed the greater of
> (i) the fees paid or payable by Customer to Provider in the twelve (12)
> months preceding the event giving rise to the claim, or (ii) USD 1,000,000.
>
> §LOL.001(b) — Exceptions to the cap: (1) breach of confidentiality;
> (2) infringement indemnification obligations under §IDM.001; (3) willful
> misconduct or gross negligence; (4) a party's payment obligations.
---
## §IDM.001 — Indemnification
**Fallback paragraph:**
> Each party (the "Indemnifying Party") shall defend, indemnify, and hold
> harmless the other party from third-party claims alleging that the
> Indemnifying Party's materials, when used as authorized under this
> Agreement, infringe a valid patent, copyright, or trademark, or
> misappropriate a trade secret. The Indemnifying Party's obligations are
> conditioned on prompt written notice, sole control of the defense, and
> reasonable cooperation by the indemnified party.
**Must-have paragraph:**
> [Fallback paragraph above] — and the indemnification scope is limited to
> third-party intellectual-property claims and willful misconduct only.
> Indemnification of any other claim category requires a separately
> negotiated and signed addendum.
---
## §IP.001 — IP Ownership
**Fallback paragraph:**
> Each party retains all right, title, and interest in its pre-existing
> intellectual property. To the extent the parties jointly develop
> "Improvements" during the Term, Provider shall own such Improvements
> and grants Customer a perpetual, irrevocable, royalty-free, non-exclusive
> license to use them solely for Customer's internal business purposes.
**Must-have paragraph:**
> Each party retains all right, title, and interest in its pre-existing
> intellectual property and in any improvements, derivative works, or
> tools it independently develops. Customer owns Customer Data; Provider
> owns Provider's tools, methodologies, and platform. Nothing in this
> Agreement transfers ownership of either party's pre-existing IP.
---
## §TERM.001 — Term & Termination
**Fallback paragraph:**
> The Initial Term is thirty-six (36) months. Thereafter, this Agreement
> renews for successive twelve (12) month Renewal Terms unless either party
> provides written notice of non-renewal at least sixty (60) days prior to
> the end of the then-current term. Either party may terminate for material
> breach upon thirty (30) days' written notice if the breach is not cured
> within the notice period.
**Must-have paragraph:**
> [Fallback paragraph above] — and either party may terminate for material
> breach upon thirty (30) days' written notice. Termination for material
> breach is a non-waivable right; any clause attempting to disclaim or
> condition this right is void.
---
## §LAW.001 — Governing Law & Venue
**Fallback paragraph:**
> This Agreement is governed by the laws of the State of Delaware, excluding
> its conflict-of-laws principles. The parties consent to the exclusive
> jurisdiction and venue of the state and federal courts located in
> New Castle County, Delaware, except that either party may seek injunctive
> relief in any court of competent jurisdiction to protect its
> intellectual-property rights.
**Must-have paragraph:**
> [Fallback paragraph above] is the only acceptable governing-law structure.
> Non-Delaware/NY/home-state jurisdictions require human attorney review
> before proposal — the skill does not propose a non-listed jurisdiction.
---
## §DPA.001 — Data Protection
**Fallback paragraph:**
> The parties shall execute the Data Processing Addendum attached as
> Exhibit B prior to any processing of Personal Data. Where Personal Data
> is transferred from the EEA, UK, or Switzerland to a country without an
> adequacy decision, the parties shall rely on the Standard Contractual
> Clauses incorporated by reference in Exhibit B.
**Must-have paragraph:**
> [Fallback paragraph above] — and Provider shall complete a Transfer
> Impact Assessment for each cross-border transfer route, made available
> to Customer on written request. Sub-processor changes require thirty
> (30) days' advance notice with a right to object.
---
## §CONF.001 — Confidentiality
**Fallback paragraph:**
> Each party shall protect the other's Confidential Information using the
> same degree of care it uses for its own confidential information of like
> kind, but in no event less than reasonable care. Confidentiality
> obligations survive for five (5) years after termination, except that
> obligations regarding trade secrets continue for as long as the
> information remains a trade secret under applicable law.
**Must-have paragraph:**
> [Fallback paragraph above] — and the standard exclusions apply: information
> that is or becomes publicly known through no breach by the receiving party,
> was independently developed without reference to the disclosing party's
> Confidential Information, was rightfully obtained from a third party
> without confidentiality obligations, or is required to be disclosed by law
> (with prompt notice to the disclosing party).
---
## §WAR.001 — Warranties & Disclaimers
**Fallback paragraph:**
> Each party warrants that it has full corporate authority to enter into
> this Agreement and that its performance hereunder will not infringe the
> intellectual-property rights of any third party. EXCEPT FOR THE
> WARRANTIES EXPRESSLY SET FORTH IN THIS AGREEMENT, EACH PARTY DISCLAIMS
> ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING IMPLIED WARRANTIES
> OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
**Must-have paragraph:**
> [Fallback paragraph above] — and Provider does NOT warrant uninterrupted
> or error-free operation of the Service. Service-level commitments, if
> any, are governed exclusively by the SLA exhibit; no other availability
> warranty is granted.
# Escalation criteria — TEMPLATE
> Rules that decide when the contract-redline skill stops proposing redlines
> and instead routes the clause (or the whole contract) to a human attorney.
>
> The skill loads this file every run. If a clause matches any rule below,
> the skill emits an escalation block in the output instead of a tracked
> change. The reviewer sees the original text, the trigger, and "needs human
> attorney." This is the single most important guardrail in the skill —
> every entry below exists because a prior run silently produced a wrong
> redline that should have been escalated.
>
> Replace this template's contents with your firm's actual rules and keep
> the IDs (`ESC.001`, `ESC.002`, etc.) stable for citation in output.
## Allowed-vendors list (precondition)
The skill refuses to run unless the configured AI model appears in this list. This guards against privilege leakage to a non-Tier-A vendor.
- Anthropic Claude (via API or Claude.ai with the firm's enterprise tenant)
- {Add other Tier-A vendors with signed BAAs / DPAs covering legal-work product}
If the model is not on this list, the skill exits with: "Configured model {name} is not on the firm's Tier-A allowed-vendors list. Run aborted."
## Per-clause escalation rules
### `ESC.001` — Out-of-playbook clause type
Trigger: the clause does not match any entry in `1-playbook-template.md`. Action: escalate. Do not propose a redline; the playbook does not encode a position to fall back on.
Common examples: source-code escrow, most-favored-nation pricing, exclusivity periods > 12 months, insurance-coverage requirements above firm standard, data-residency requirements naming a specific country, audit rights with unannounced on-site inspections.
### `ESC.002` — Novel defined term
Trigger: the proposed redline (after fallback substitution) introduces a new defined term not present in the playbook or the original contract. Action: escalate. New defined terms cascade through the rest of the contract and the skill cannot reason about cascade effects.
### `ESC.003` — Non-US jurisdiction in deal_context
Trigger: `deal_context.jurisdiction` is set to any non-US value. Action: escalate every Limitation of Liability, IP, indemnification, and warranty clause. These positions are jurisdiction-sensitive and the playbook encodes US-law assumptions only.
### `ESC.004` — EU/UK personal data without DPA exhibit
Trigger: contract or `deal_context` mentions EU/UK data subjects AND no DPA exhibit is attached. Action: escalate the entire data-protection section to human attorney. The skill does not propose a DPA from scratch; it only swaps yellow-zone DPA-exhibit-attached language for the firm-standard DPA reference.
### `ESC.005` — Conflicting overlapping clauses
Trigger: two or more clauses in the same contract appear to address the same playbook entry (e.g. two Limitation of Liability sections, or confidentiality language in both the body and an exhibit). Action: escalate both clauses. Do not propose redlines; the skill cannot reason about which clause controls in case of conflict.
### `ESC.006` — Bespoke instrument
Trigger: contract type classified as "other" in step 1. Action: escalate the entire contract. Do not attempt clause-level redlines.
### `ESC.007` — Final-round draft signal
Trigger: the document filename, header, or first paragraph contains the strings "v3", "round 3", "final draft", "execution copy", or comparable. Action: escalate the entire contract. The playbook encodes opening positions, not late-stage concession patterns.
### `ESC.008` — Counterparty-supplied form with no track-changes acceptance
Trigger: counterparty draft is from a counterparty's standard form (clauses labelled "Customer Standard Terms," "Vendor Master Agreement," or similar) AND counterparty profile flags "low willingness to redline." Action: escalate. The skill flags every red-zone clause but does not propose redlines; the human attorney makes the call on which battles to pick.
### `ESC.009` — Regulated-industry overlay
Trigger: `deal_context.regulatory` includes any of: HIPAA, FedRAMP, PCI-DSS, SOX, FINRA, FDA-regulated. Action: escalate every clause touching data handling, audit, breach notification, sub-processing, and termination. The playbook does not encode regulator-specific carve-outs.
### `ESC.010` — Confidence drop
Trigger: the skill's clause-classification step produces a confidence score below the threshold (default: model self-reported "low confidence" or inability to cite a playbook section ID). Action: escalate the clause. Better to over-escalate than to silently mis-classify.
## What to do with escalations
Each escalation block in the output names the trigger by ID. The reviewer's SOP:
1. Read each escalation block.
2. Decide: handle inline (write the redline yourself), route to outside counsel, or accept the counterparty's clause as-drafted.
3. If the same `ESC.xxx` rule fires repeatedly across deals, that's a signal the playbook is missing coverage. Update `1-playbook-template.md` to add the clause type so the next run handles it autonomously.
## Last edited
`{YYYY-MM-DD}` — bump on every material edit.
