nda-review

Files (14)

• SKILL.md
• baseline-mutual.md · acceptance/fixtures/
• recipient-onesided.md · acceptance/fixtures/
• unusual-edge.md · acceptance/fixtures/
• baseline-mutual.golden.json · acceptance/snapshots/
• recipient-onesided.golden.json · acceptance/snapshots/
• unusual-edge.golden.json · acceptance/snapshots/
• example_mutual.md · examples/
• example_unilateral_recipient.md · examples/
• issue_checklist.md · reference/
• perspective_lens.md · reference/
• red_flags.md · reference/
• severity_rubric.md · reference/
• test-plan.md

SKILL.md (first lines)

# NDA Review

Conduct a structured review of a non-disclosure agreement from the user's stated perspective and produce a report that an in-house lawyer can act on without redoing the analysis. The output is a draft for human review, not a final word; treat it accordingly.

## When this skill applies

Apply when the user provides an NDA (sometimes called a confidentiality agreement, CDA, or confidential disclosure agreement) and asks for review, redline guidance, risk assessment, or a recommendation. The user's perspective — discloser, recipient, or mutual — fundamentally changes the analysis; require it before proceeding if not supplied.

Do not apply this skill to:

- Confidentiality clauses inside larger agreements (MSAs, employment agreements, settlement agreements). Those clauses interact with the surrounding agreement; isolated review misleads. Tell the user a separate review of the parent agreement is needed.
- Documents that are not NDAs, even if they touch on confidentiality (data processing agreements, security addenda, BAAs). Refer the user to the appropriate skill.
- NDAs in employment contexts (employee confidentiality agreements, separation agreements with NDA components). These have employment-law overlays this skill does not cover.

## Inputs

The skill requires the NDA itself and the user's perspective. If perspective is not provided, ask:

> "Before I review, which side are you on? Discloser (you're sharing information and want strong protections on the recipient), recipient (you're receiving information and want narrow obligations on yourself), or mutual (both parties are exchanging information and you want balanced, symmetric terms)?"

If the user describes a situation that does not cleanly fit one of these (e.g., "we're sharing information but only a small amount; mostly we're receiving"), default to the perspective covering the larger exposure and note the asymmetry in the report. For mostly-receiving-with-some-sharing, treat as recipient and add a note about the discloser-side exposure.

Optional inputs (jurisdiction, deal_type, prior_agreements, standard_positions) refine the analysis if provided. Do not block on them.

The `deal_type` input materially affects severity calibration. The same provision can be material in one deal context and minor in another. Examples:

- A non-solicit clause is **material in vendor_evaluation or customer_engagement** (the parties are not contemplating organizational integration; non-solicit is unbargained-for restraint), and **minor-to-acceptable in ma_diligence or partnership** (organizational integration is on the table; non-solicit is part of standard deal-protection package).
- A standstill provision is **material/critical outside ma_diligence** (the parties are not contemplating an acquisition; standstill restricts conduct unrelated to the confidentiality purpose) and **standard-and-acceptable in ma_diligence** (it serves a legitimate deal-protection function).
- IP assignment of feedback is **critical in vendor_evaluation** (recipient gives up IP rights to evaluate a product) and **less unusual in partnership** (where reciprocal IP exchange may be in scope, though still warrants scrutiny).
- A 5-year confidentiality term is **material in general_commercial** (longer than standard) and **minor-to-standard in ma_diligence** (M&A-grade information warrants longer protection).

When `deal_type` is not provided, default to **general_commercial** and note in the report that severity calibration assumed general commercial context; calibration may differ if a specific deal type applies.

The `prior_agreements` input drives Pass 4's conflict-with-prior-agreements analysis. When provided, examine the document for:

- Express references to the named prior agreements (and whether the references are accurate).
- Integration / entire-agreement clauses that would extinguish protections in the prior agreement.
- Provisions that conflict with terms the user mentioned in the prior agreement.

When `prior_agreements` is not provided, do not speculate about prior agreements; the conflict-with-prior-agreements analysis is skipped.

## Workflow

Produce the review in five passes. Do them in this order — earlier passes inform later ones.

### Pass 1: Document orientation

Before substantive review, read the document and orient:

- Is this actually an NDA, or a different agreement type? If it's not an NDA, stop and tell the user.
- Is it mutual, unilateral toward discloser, or unilateral toward recipient? Compare this to the user's stated perspective; flag any mismatch (e.g., user says "we're recipient" but document is unilateral toward the *other* party — meaning the user has obligations the user thinks the other side has).
- Note governing law, jurisdiction, and term length at a glance.
- Estimate document length and complexity. NDAs over ~5 pages typically have non-standard provisions worth flagging on length alone.

### Pass 2: Standard-protection check

Walk through the standard NDA checklist in `reference/issue_checklist.md`. For each item, determine:

- **Present and standard:** the document has this clause and it falls within the normal range.
- **Present but unusual:** the document addresses this issue but with non-standard scope, severity, or carveouts.
- **Missing:** the document does not address this issue.
- **N/A:** this issue does not apply given the document type, perspective, or business context.

The standard checklist covers: definition of confidential information, exclusions from confidentiality, permitted uses, permitted disclosures (employees, advisors, legal compulsion), term and duration of confidentiality obligations, return/destruction of materials, residuals, no-license language, equitable remedies and injunctive relief, governing law and venue, assignment, integration and amendment, and notice requirements.

### Pass 3: Asymmetry and one-sidedness check

Specifically examine the document for asymmetry against the user's perspective. Per `reference/perspective_lens.md`, certain provisions read very differently from each side:

- **Discloser perspective:** weak definitions of confidential information, broad exclusions, short terms, narrow injunctive relief, weak return/destruction, broad permitted disclosures, residuals clauses — all favor the recipient and erode discloser protection.
- **Recipient perspective:** broad definitions, narrow exclusions, long terms (especially perpetual obligations on trade secrets in the wrong jurisdictions), broad injunctive relief, harsh return/destruction with certifications, narrow permitted disclosures (especially blocking advisor disclosure), liquidated damages — all expand recipient obligations.
- **Mutual perspective:** check that obligations and protections actually run symmetrically. Mutual NDAs that look mutual but have asymmetric exclusions, term, or remedies are a common drafting move worth flagging.

### Pass 4: Operational and red-flag check

Look for provisions that create operational risk regardless of perspective:

- **Non-solicitation clauses inside NDAs.** Common in unilateral-toward-discloser drafts. Often unenforceable in California; problematic in other states. Flag whenever present.
- **Non-competition clauses.** Same flagging — and stronger enforceability concerns. Flag as critical whenever present in an NDA outside an M&A context.
- **Non-circumvention clauses.** Common in deal-broker contexts; often vague enough to create operational restrictions the user did not bargain for.
- **No-hire clauses.** Increasingly disfavored in some jurisdictions; flag whenever present.
- **IP assignment language** purporting to assign work product or feedback. Should not be in an NDA; flag as material.
- **Most-favored-nation clauses** on confidentiality terms. Unusual; flag for context.
- **Consequential / liquidated damages** for breach. Flag.
- **Indemnification provisions.** Should not be in a standard NDA; flag as material.
- **Audit rights** (recipient permitting discloser to audit recipient's compliance). Common in regulated-data NDAs; flag for proportionality.
- **Public-statement restrictions** ("non-disparagement"). Out of scope for an NDA; flag.
- **Broad publicity restrictions** ("you may not announce that we are talking"). Common; flag for whether the restriction is mutual and reasonable.
- **Survival provisions** that cause obligations to outlive the rest of the agreement. Standard for confidentiality, but check what *else* survives.
- **Conflicts with existing agreements.** If the user provided a `prior_agreements` input, examine the document for references to those agreements, integration clauses that would extinguish prior protections, and provisions that conflict with terms in the prior agreements. Flag any potential conflicts. If `prior_agreements` was not provided, this check is skipped.

See `reference/red_flags.md` for the full list.

### Pass 5: Produce the report

The report has a fixed structure (specified in the Output section). Populate it with the findings from the prior passes. Calibrate severity using the rubric in `reference/severity_rubric.md`. Cite specific section/clause numbers for every finding so the user can navigate the document.

## Output

Produce the report in markdown with this exact structure:

```markdown
# NDA Review: [Document name or counterparty]

**Perspective:** [discloser | recipient | mutual]
**Document type:** [Mutual NDA | Unilateral NDA toward discloser | Unilateral NDA toward recipient]
**Governing law:** [jurisdiction or "not specified"]
**Term:** [duration or "perpetual" or "not specified"]

## Bottom line

[Two to four sentences. State the overall posture of the document toward the user's perspective (favorable, balanced, unfavorable, materially unfavorable). State whether it is signable as-is, signable with minor edits, requires negotiation, or should be rejected. Identify the single most important issue.]

## Critical issues

[Issues rated "critical" per the severity rubric. Each issue has its own subsection with: clause reference, what the document says, why it's a problem from the user's perspective, suggested redline language. Omit this section if there are no critical issues; do not pad.]

## Material issues

From LegalQuants/lq-ai, Apache-2.0.

More from LegalQuants/lq-ai