VC Blueprint
Skill Library

NDA Review.

Review an inbound NDA against the firm's sign-or-comment criteria and return a clear go/no-go with the minimum set of redline comments. Triggers on 'can we sign this NDA,' 'review this NDA,' 'redline this NDA,' 'any issues with the NDA,' or any incoming confidentiality agreement that needs sign-off.

Pure Operations
S.1

Install

Download the bundle, then drop it into your skills directory — typically ~/.opencode/skills/ or the equivalent for your runtime. The skill activates automatically once its description matches the current task.

Download nda-review.skillZipped SKILL.md bundle
S.2

Manifest

Compatibility
  • OpenCode
  • Any frontier model that accepts SKILL.md
Tools the skill expects
ReadWriteEditAskUserQuestion
S.3

Why we maintain it

An investment firm signs NDAs constantly and is almost always the receiving party, not the discloser. The risk isn't signing a bad NDA — it's slowing every deal down by marking up boilerplate. This skill encodes the firm's actual house position: default to signing, flag only real dealbreakers (foreign governing law, perpetual terms, standstills, exclusivity, indemnification running outbound), and ignore the long list of clauses that come up constantly but never matter. Output is a two-line approval for clean NDAs and a tight numbered redline for the rest — short enough to read on a phone before the next call.

S.4

SKILL.md

The full skill body, exactly as the host runtime loads it. This is the source of truth — the download is the same content packaged as a standard bundle.

name: nda-review description: Review an NDA (non-disclosure agreement, confidentiality agreement, CDA, mutual NDA, or one-way NDA) against GICP's standard sign-or-comment criteria and return a clear go/no-go recommendation with redline comments only where they're actually needed. Use this skill whenever a user uploads, pastes, or links to an NDA and asks any variant of "can we sign this?", "is this NDA ok?", "should we mark this up?", "review this NDA", "redline this NDA", "what's wrong with this NDA?", "any issues with the NDA?", "look at this confidentiality agreement", "does this NDA pass?", or any other request to assess whether an NDA is acceptable for GICP to execute. Also trigger when an email, deal thread, or memo references an incoming NDA that needs sign-off, even if the user doesn't explicitly say "review." The skill is deliberately narrow — it flags only real problems and errs strongly toward signing rather than commenting.

NDA Review

GICP's house playbook for reviewing inbound NDAs. The goal is to sign quickly when the NDA is acceptable and to send the minimum set of comments back when it isn't. We are a buyer of confidential information, not a seller — every NDA we sign is to look at someone else's data room or hear their pitch. Over-commenting slows deals and signals that we're a difficult counterparty.

Operating principles

  1. Default to signing. If the core criteria are met, recommend signing as-is. Do not invent reasons to comment.
  2. Only flag real problems. A "real problem" is something that is a dealbreaker or requires a fix before signing. Do not flag things that are merely "worth noting," "on the long side but acceptable," "unusual but not a dealbreaker," "worth being aware of," or any other soft observation. If it doesn't require action, it doesn't go in the output.
  3. One pass, one set of comments. Bundle every required change into a single redline. Do not generate "nice-to-haves."
  4. Plain English, not legalese. Comments should be short and tell the counterparty what to change, not lecture them on why.
  5. Flag, don't block. Some issues are dealbreakers; most are "fix this and we'll sign." Be explicit which is which.

The core criteria

Check these in order. Each one has a pass/fix/reject outcome.

1. Governing law

  • Pass: Governed by the law of any U.S. state. Do not flag, comment on, or note the choice of U.S. state. Delaware, New York, California, Washington, Texas, and every other U.S. state are all acceptable without comment.
  • Fix: Foreign governing law (UK, Cayman, Singapore, Israel, EU member state, etc.). Comment: change governing law to Delaware (or New York, or the counterparty's home state if U.S.).
  • Reject: Counterparty refuses any U.S. governing law after one round of pushback.

Also check jurisdiction/venue clause if separate from governing law. Foreign exclusive jurisdiction is the same problem even if governing law is U.S. Flag it. U.S.-state exclusive jurisdiction is not a problem and should not be flagged.

2. Term

  • Pass: 1, 2, or 3 years from the effective date. Do not flag.
  • Pass: 4–5 years. This is acceptable. Do not flag.
  • Fix (firm): More than 5 years, or "perpetual," or "indefinite." Comment to reduce to 2 years.
  • Special case: Trade secrets are commonly carved out and protected for as long as they qualify as trade secrets under applicable law. This is market and acceptable — do not comment on it.
  • Special case: "Survives termination" language alone is fine if the underlying term is reasonable. However, broad "survives until the information becomes public" language that effectively makes obligations perpetual for non-public information is a problem — flag it.

3. Affirmative obligations beyond the deal

The rule: GICP can be asked to return or destroy confidential information upon request. We cannot accept any obligation to proactively deliver materials we created (notes, analyses, memos, scoring outputs) to the counterparty.

  • Pass: Standard "return or destroy upon written request" language. Standard exception for archival/backup copies retained per GICP's record-retention policies. Standard exception for materials retained to comply with legal/regulatory obligations.
  • Fix (firm): Any requirement to (a) hand over GICP-generated analysis, notes, or work product to the counterparty; (b) certify destruction in writing within an unreasonably short window (anything under 15 business days from request); (c) destroy materials held by GICP's outside advisors (lawyers, accountants) — those should be carved out.
  • Also flag in this section (these fit the spirit of the rule even though you didn't list them):
    • Non-solicit of employees — Acceptable only if (i) ≤12 months, (ii) limited to employees GICP actually met or learned about through the process, and (iii) excludes general job postings and recruiter-sourced candidates. Anything broader: comment.
    • Non-compete or standstill against GICP — In a sourcing NDA (we're evaluating an investment), a one-way standstill that restricts GICP from investing in competitors is a dealbreaker. Comment to strike or hard reject. A mutual standstill in an M&A context is different and may be acceptable depending on deal stage.
    • Exclusivity — An NDA should never contain exclusivity. If it does, strike.
    • Indemnification running from GICP to counterparty — Off-market in a sourcing NDA. Comment to strike. If counterparty refuses, escalate to outside counsel.

4. Sharing with advisors and third parties

GICP must be able to share confidential information with our advisors (lawyers, accountants, consultants, technical diligence providers) and our limited partners (on a confidential, need-to-know basis).

  • Pass: "Representatives" or "Affiliates" defined to include directors, officers, employees, attorneys, accountants, financial advisors, consultants, and (ideally) limited partners and prospective co-investors. GICP responsible for breach by its Representatives.
  • Fix (firm): Definition limited to employees only, or requires counterparty's prior written consent for each disclosure to an advisor. Comment to broaden.
  • Fix (firm): Requirement that GICP employees sign per-deal NDAs before receiving Confidential Information. Comment to strike — GICP employees are already bound by firm-wide confidentiality obligations.
  • Fix (firm): Requirement of written approval before making copies of Confidential Information. Comment to strike — diligence inherently requires working copies, internal memos, and shared file storage.

What to ignore (do not comment on these)

These come up constantly and are not worth a comment unless they're egregious:

  • Choice of U.S. state for governing law or jurisdiction
  • Definition of "Confidential Information" — standard formulations are all fine
  • Standard carve-outs (publicly available, independently developed, lawfully received from third party, required by law)
  • "Residuals" clauses in either direction
  • Equitable remedies / injunctive relief language
  • No-warranty / no-representation language
  • Notice provisions
  • Entire agreement, severability, counterparts, electronic signature — boilerplate
  • Choice of language (assuming English)
  • Trade secret carve-outs from the term (see Criterion 2)
  • One-way vs. mutual structure (the common case is one-way with GICP receiving — no comment needed)
  • "Best efforts" vs. "reasonable measures" standard of care — not a required fix on its own
  • Anything that is "unusual but not a dealbreaker," "worth noting," "worth being aware of," or "on the long side but acceptable"

If you find yourself drafting a comment on any of the above, stop and re-read this section.

Output format

Respond directly in chat. Do not create a Word doc, PDF, or any other file. Keep it simple and scannable on a phone.

Clean NDAs (no required fixes)

If the NDA passes all core criteria, the response is short. Two lines max:

Recommendation: Sign as-is. No required fixes.

Want me to send to DocuSign? If yes, Mark or Shaw?

Do not add a "Notes" section. Do not add observations, context, or things "worth flagging." If there's nothing to fix, say nothing beyond the recommendation and the DocuSign handoff question.

NDAs that need fixes

Two sections only:

Recommendation

One line: Sign with comments or Do not sign / escalate.

Issues found

Numbered list. For each issue:

  • Section reference (clause number, section name, or page)
  • What the NDA says (one-sentence paraphrase, not a verbatim block quote)
  • Why it's a problem (one sentence)
  • Proposed fix (the exact language change or strike, as a markup-style instruction)
  • Severity: Dealbreaker / Required fix

Only include issues that require action. Do not include a "Notes," "Observations," or "Worth flagging" section under any circumstances. If something doesn't require a fix, it doesn't appear in the output.

How to actually do the review

  1. Read the NDA end-to-end first. Don't pattern-match on the first few clauses.
  2. Identify the core checks by clause and mark pass/fix/reject for each.
  3. Scan for the spirit-of-the-rule additions (non-solicit, standstill, exclusivity, advisor restrictions, indemnification).
  4. Check whether the NDA is mutual or one-way. A one-way NDA where GICP is the disclosing party is unusual and worth flagging up — that is a real problem because we typically receive, not disclose. A one-way NDA where GICP is the receiving party is the common case and requires no comment on the structure itself.
  5. Resist the urge to mark up style. If the counterparty's lawyer wrote it in a way you wouldn't, that is not a comment.
  6. Before writing the output, audit your issue list. For every issue, ask: does this require the counterparty to change something before GICP will sign? If no, delete it. If you can't decide, delete it.
  7. Write the output. Be terse. The deal team is reading on their phone.

After the review: DocuSign handoff

If the recommendation is Sign as-is (no required fixes), end the response by asking the user whether they'd like to kick off execution via DocuSign. Ask in one short follow-up line. Two questions, asked at the same time:

  1. Do you want to send this to DocuSign now?
  2. If yes, should it go to Mark or Shaw for signature?

If the user says yes, use the Docusign connector to create the envelope. Use createEnvelope with the NDA as the document and the chosen signer (Mark or Shaw) as the recipient. Confirm in chat once the envelope is created.

If the recommendation is Sign with comments, do not offer the DocuSign step — the NDA needs to go back to counterparty for revisions first.

If the recommendation is Do not sign / escalate, do not offer the DocuSign step.

When to escalate to outside counsel

This skill produces a first-pass review, not a legal opinion. Escalate to GICP's outside counsel when:

  • The NDA contains a standstill, non-compete, or exclusivity provision the counterparty won't drop
  • The NDA contains an indemnification obligation running from GICP to the counterparty that the counterparty won't drop
  • The deal size is above $50M and the NDA has any non-trivial deviation from market
  • The counterparty is a foreign sovereign, state-owned enterprise, or sanctioned-jurisdiction entity
  • You are reviewing a clean-team agreement, a JV term sheet disguised as an NDA, or anything labeled "Master Confidentiality Agreement" with multi-deal scope

Flag the escalation in the Recommendation line.

Reference materials

The references/ directory contains:

  • comment-templates.md — Pre-written redline comments for the most common issues, ready to paste into Word
  • red-flags-quickref.md — One-page cheat sheet of dealbreaker clauses with example language
← Back to the Skill Library