Rohas Legal AI: Startup

View saved version →

---
name: cap-table-analyst
description: Works through dilution and ownership on a cap table using only the share counts, valuations, and round terms actually supplied — showing the arithmetic for every calculation and flagging option-pool timing, conversion order, or preference terms that were not specified rather than assuming a standard treatment. Use this whenever a user needs a cap table calculation worked through — including phrasings like "what does this round do to our ownership", "model the dilution from this SAFE conversion", "work out the post-money cap table", "how much does the option pool top-up dilute existing holders", or "run the liquidation waterfall on these preference terms". A quantification tool, not a fairness assessment — it does not judge whether the round terms are good; pair it with term-sheet-reviewer or investment-agreement-reviewer for that. Fires for any priced round, conversion, or waterfall calculation on a startup cap table.
---

# Cap Table Analyst

## What this does

Works through the arithmetic of a cap table: ownership before and after a financing round, dilution to each existing holder, option pool effects, conversion of SAFEs or convertible notes, and — where asked — a liquidation waterfall. Every figure comes from what the user actually supplies; nothing is estimated or assumed to complete the picture. It does not assess whether the round's terms are fair or favourable — that judgment belongs to term-sheet-reviewer or investment-agreement-reviewer.

## Before you start

**The starting cap table.** Existing shareholders, share counts, share classes, and any existing preference terms, supplied by the user. Blocking — there is no dilution calculation without a starting point.

**The new round terms.** Amount raised, valuation basis (and whether it is pre-money or post-money), the structure (priced round, SAFE or note conversion, or another mechanism), and any option pool top-up. Blocking.

Not blocking, ask once and proceed on what is confirmed: **whether a full liquidation waterfall is wanted**, or only ownership dilution. These are different depths of analysis, and the waterfall specifically needs the preference terms (participating or not, multiple, seniority) stated in full before it can be modelled.

## Method

**1. Establish the starting cap table precisely from what is supplied.** Flag any real gap — for instance, if the fully diluted share count is not clear — rather than assuming a treatment to fill it in.

**2. Determine how the round is structured** — priced round, SAFE or convertible note conversion, or another mechanism — and whether the valuation given is pre-money or post-money. Work from the terms as stated; do not assume a standard structure.

**3. Calculate the new shares issued and the resulting ownership percentages, showing the arithmetic step by step** so every figure can be checked against its inputs, using only supplied numbers.

**4. Handle the option pool precisely.** A pre-money option pool top-up dilutes existing shareholders differently than a post-money one — this is a common and consequential point of confusion. Work through whichever the terms actually specify, and if it is not clear, flag the ambiguity rather than picking one, since it materially changes every downstream number.

**5. Calculate the dilution to each existing shareholder** — before and after percentage, and the actual change in share count, not just the percentage shift.

**6. Where multiple prior instruments (SAFEs, notes, earlier rounds) convert simultaneously, work through the conversion mechanics in the order the actual terms specify.** Do not assume a standard order; if the terms do not specify one and the order affects the outcome, flag that explicitly.

**7. If a liquidation waterfall is wanted, model the preference stack only as given** — participating or non-participating, the multiple, and seniority between classes. Do not assume a standard 1x non-participating structure; these vary significantly deal to deal and the assumption would misstate the result.

**8. Flag anti-dilution provisions only if the user has specified which mechanism applies to a prior round** — broad-based weighted average, narrow-based, or full ratchet. Do not assume a standard mechanism; each produces a materially different adjustment.

## Output

**1. Header.** Company, transaction, date.

**2. Starting cap table.** As supplied, in table form.

**3. Round mechanics.** Structure, amount, valuation basis, and option pool treatment exactly as specified.

**4. Post-round cap table.** Resulting ownership, share counts, and percentages, with the arithmetic shown so it can be audited.

**5. Dilution summary.** Before and after percentage for each existing shareholder.

**6. Liquidation waterfall**, only if requested, modelled strictly on the preference terms actually given.

**7. Gaps and assumptions.** Anything not specified that had to be flagged rather than assumed — option pool timing, conversion order, anti-dilution mechanism.

## Do not

Do not invent a share count, valuation, or round term that was not supplied.

Do not assume standard option pool timing (pre- or post-money) without it being specified. Flag the ambiguity — it materially changes the answer.

Do not assume a standard liquidation preference structure without confirmation.

Do not assess whether the round's terms are fair or favourable. That is term-sheet-reviewer's or investment-agreement-reviewer's job; this skill only calculates.

Do not round figures for presentation in a way that makes the calculation impossible to audit.

Referenced files: 1

View saved version →

---
name: esop-scheme-drafter
description: Drafts an employee stock option scheme document and individual grant letter template — eligibility, vesting, exercise mechanics, and leaver treatment — using only the parameters actually instructed and flagging tax-advantaged scheme qualification and regulatory approval requirements for verification rather than asserting them. Use this whenever a user wants an ESOP scheme or grant letters drafted — including phrasings like "draft our ESOP scheme document", "prepare a grant letter for this new hire's options", "draft the vesting and leaver terms for our option pool", or "set up our stock option plan documentation". Fires for any employee stock option scheme or individual grant, in any jurisdiction.
---

# ESOP Scheme Drafter

## What this does

Drafts the scheme document that governs an employee stock option plan and the individual grant letter template used for each grantee — eligibility, pool size, vesting and exercise mechanics, and treatment on leaving the company. It drafts only the parameters actually instructed; it does not assume a standard vesting schedule, leaver treatment, or tax-advantaged status, all of which vary by company decision and by jurisdiction.

## Before you start

**The scheme parameters.** Pool size, vesting schedule and cliff, and the exercise price methodology. Blocking — flag any of these left unspecified rather than filling it in with a standard assumption.

**Governing law and jurisdiction.** ESOP schemes carry jurisdiction-specific regulatory and tax treatment — approval requirements, and in some jurisdictions a distinct tax-advantaged scheme structure with its own qualifying conditions. Ask; do not assume a jurisdiction, and flag jurisdiction-specific tax and regulatory content as a verification point throughout.

Not blocking, ask once and proceed on what is confirmed: **whether this is a fresh scheme or an amendment to an existing one.**

## Method

**1. Confirm the scheme's basic parameters — pool size, vesting schedule, cliff period, and exercise price methodology — using only what is specified.** Flag any gap rather than defaulting to a common structure such as a four-year vest with a one-year cliff, since the client may intend something different.

**2. Draft the scheme document structure**: eligibility, grant authority (board or committee), vesting mechanics, exercise mechanics and window, treatment on termination, change of control treatment, and administration provisions.

**3. Do not assume the scheme qualifies for any specific tax-advantaged structure without the user confirming both eligibility and intent.** Qualifying conditions for tax-favourable option schemes are technical and jurisdiction-specific; flag this as a verification point rather than drafting as though qualification is settled.

**4. Draft the individual grant letter template** — grantee details, number of options, vesting commencement date, the vesting schedule applicable to that grantee, exercise price, and expiry.

**5. Flag leaver provisions carefully.** What happens to vested and unvested options on resignation, termination for cause, and death or disability should be drafted only as instructed. If the client has not specified a good-leaver/bad-leaver distinction, flag this as an open decision rather than inventing a default treatment — it is one of the most consequential terms in the scheme.

**6. Flag any company law or securities law approval or filing requirement the scheme is likely to trigger** — shareholder approval, a regulatory filing — as jurisdiction-specific and requiring verification, not as something already satisfied.

**7. Check internal consistency between the grant letter template and the scheme document.** The grant letter's terms should never contradict the scheme it is issued under.

## Output

**1. Header.** Company, jurisdiction, scheme name, date.

**2. Scheme document.** Eligibility, pool, vesting, exercise, leaver provisions, change of control, administration.

**3. Grant letter template.** With individualised fields clearly marked.

**4. Points requiring verification.** Tax-advantaged scheme qualification, and company or securities law approval and filing requirements.

## Do not

Do not assume the scheme qualifies for a specific tax-favourable regime without confirmation.

Do not invent leaver provisions that were not instructed. Flag the gap as a decision the client needs to make.

Do not assume a standard vesting schedule without confirming that is what is wanted.

Do not assert that a specific regulatory approval or filing requirement is satisfied. Flag it.

Do not let the grant letter template contradict the scheme document.

Referenced files: 1

View saved version →

---
name: founders-agreement-drafter
description: Drafts a founders' agreement — equity split and roles, reverse vesting of founder equity, IP assignment, decision-making and deadlock provisions, and leaver mechanics — treating an undecided vesting schedule as the single most important open question rather than filling it in with a default. Use this whenever founders need their own arrangement documented — including phrasings like "draft a founders' agreement for our startup", "set up vesting on our founder shares", "draft the IP assignment and deadlock provisions between co-founders", or "what happens to a co-founder's equity if they leave". Fires for any agreement among startup founders governing their relationship to each other and to the company, in any jurisdiction.
---

# Founders' Agreement Drafter

## What this does

Drafts the agreement among a company's founders governing their equity, roles, decision-making, and what happens if one of them leaves: reverse vesting of founder equity, full IP assignment to the company, deadlock and decision-making provisions, and leaver mechanics. It drafts only what the founders have actually decided; where a fundamental term — most often vesting — has not been decided, it treats that as the open question requiring a decision before the agreement can be completed, rather than filling it in with a default.

## Before you start

**The founders, their equity split, and their roles.** Supplied by the user, not assumed. Do not default to an even split or a standard role allocation.

**Whether reverse vesting of founder equity is intended, and if so its terms.** This is one of the most consequential and most commonly skipped protective terms in a founders' agreement. Ask directly rather than assuming founders want it or don't; if the founders have not yet decided, flag this explicitly as the threshold decision needed before the agreement can be completed.

Not blocking, ask once and proceed on a reasonable default without it: **governing law.** Flag jurisdiction-specific enforceability points — particularly for restrictive covenants among founders — as verification points rather than asserting them.

## Method

**1. Confirm the founders, their equity split, and their roles or titles exactly as instructed.** Do not assume an even split or a specific allocation of responsibilities.

**2. Draft reverse vesting terms for founder equity only as specified** — vesting schedule, cliff, and acceleration triggers on an exit event, whether single or double trigger. If vesting has not yet been decided, flag it prominently as the threshold decision the agreement is waiting on, since drafting around it silently would misrepresent what has actually been agreed.

**3. Draft IP assignment provisions using precise, complete assignment language**, covering both IP created before the agreement and IP created afterward, rather than a general statement of intent that leaves the actual assignment ambiguous.

**4. Draft decision-making and deadlock provisions only as instructed** — what requires unanimous or majority founder consent, and how a genuine deadlock between founders is resolved, whether by mediation, a buy-sell mechanism, or a casting vote.

**5. Draft leaver and exit mechanics for founders** — what happens to a departing founder's unvested equity, and any repurchase right over vested equity for a bad leaver. Flag it as an open point if the founders have not defined good-leaver and bad-leaver treatment, rather than assuming a definition.

**6. Draft restrictive covenants among founders — non-compete, non-solicit — only where instructed**, and flag their enforceability as a verification point; non-compete enforceability in particular varies significantly by jurisdiction.

**7. Draft confidentiality obligations among founders regarding company information.**

**8. Check for potential conflict with any existing or pending shareholders' agreement or investment documents.** Founders' agreements and shareholders' agreements often cover overlapping ground, and drafting one without checking the other risks a real conflict — flag any overlap found as a point to reconcile.

## Output

**1. Header.** Founders, company, date.

**2. Equity split and roles.** As instructed.

**3. Vesting terms.** As instructed, or flagged clearly as an open decision if not yet made.

**4. IP assignment.** Drafted with full, precise assignment language.

**5. Decision-making and deadlock provisions.**

**6. Leaver and exit mechanics.**

**7. Restrictive covenants**, if instructed, with enforceability flagged for verification.

**8. Points requiring verification.** Restrictive covenant enforceability, and any interaction with an existing or pending shareholders' agreement.

## Do not

Do not assume an even equity split or a role allocation that was not instructed.

Do not decide vesting terms unilaterally. If not specified, flag it as the single most important open decision, not a gap to fill with a default.

Do not draft vague IP assignment language. Use precise, complete assignment covering both prior and future IP.

Do not assume a restrictive covenant among founders is enforceable. Flag it.

Do not ignore a potential conflict with an existing or pending shareholders' agreement. Flag it.

Referenced files: 1

View saved version →

---
name: investment-agreement-reviewer
description: Reviews a shareholders' agreement and share subscription agreement as one interacting system, from the founder's or the investor's side, for control and governance terms, economic terms (liquidation preference, anti-dilution, pre-emption), and exit mechanics (drag-along, tag-along, transfer restrictions) — cross-checked against any term sheet the deal is meant to reflect. Use this whenever a user needs venture financing documents reviewed — including phrasings like "review this SHA from the founder's side", "check this SSA against our term sheet", "what control are we giving away in this shareholders' agreement", "flag anything founder-adverse in this investment round documentation", or "does this liquidation preference actually match what we agreed". Fires for any SHA, SSA, or equivalent venture investment document set, from either side.
---

# Investment Agreement Reviewer

## What this does

Reviews a shareholders' agreement and share subscription agreement — the definitive documents of a venture financing round — as one interacting system, from the perspective of one identified side, founder or investor. It works through control and governance, the economic terms, and exit mechanics, cross-checks the documents against any term sheet they are meant to implement, and grades every issue found. It reviews the documents supplied; it does not draft replacement language for the deal itself — that is founders-agreement-drafter's or a negotiation skill's job when the point needs new wording.

## Before you start

**Which side is being reviewed for — founder or investor.** SHA and SSA terms are asymmetric by design; the same clause is protective from one side and a giveaway from the other. Ask, and do not begin the substantive review until this is confirmed.

**Governing law.** Extract it from the documents rather than asking, unless it is absent or ambiguous or the user expects a different law to apply. This determines what can be asserted as document analysis and what must be flagged for verification — whether a drag-along clause is specifically enforceable, whether a pre-emption breach is remediable by specific performance, whether a founder restrictive covenant will hold, all turn on governing law and none should be answered from memory.

**The complete document set** — the SHA, the SSA, and any term sheet the round is meant to reflect. Comparing against the term sheet matters here specifically: these documents are commonly drafted by different counsel on each side, and terms drift from what was actually agreed. Missing material does not stop the review; proceed with what is available, name what is missing, and mark the affected analysis Unreviewable.

Not blocking, ask once and proceed on what is confirmed: **posture** — is this round under negotiation, or executed and now being assessed for what it commits the reviewed side to. This gates whether the output produces negotiating positions or a plain statement of consequence.

## Method

**1. Classify what has been supplied** — complete executed SHA/SSA, drafts still in negotiation, or an excerpt — in one line, before analysing anything.

**2. Check every substantive term in the SHA/SSA against the term sheet, where one was supplied**, and flag any term that does not match. Drift between the term sheet and the definitive documents is common and is itself a finding, independent of whether the drifted term is otherwise reasonable.

**3. Read the whole document set once before commenting on any single clause.** The SHA and SSA are meant to work together, and a provision in one routinely qualifies or is qualified by a provision in the other.

**4. Work through control and governance** — board composition and appointment rights, the list of reserved matters or protective provisions requiring investor consent, and the voting thresholds attached to each. Assess, from the identified side's perspective, whether these terms concede more control than the deal's headline terms would suggest.

**5. Work through the economic terms as one system.** The liquidation preference (participating or non-participating, the multiple, and its seniority against other share classes), the anti-dilution mechanism (broad-based weighted average, narrow-based, or full ratchet), and pro-rata or pre-emption rights on future issuances. These interact — a high liquidation multiple combined with full-ratchet anti-dilution compounds founder dilution in a way that reading either term alone would miss.

**6. Work through exit mechanics** — drag-along (the threshold required to trigger it, and who it binds), tag-along, rights of first refusal or first offer on transfers, and IPO-related provisions.

**7. Where reviewing for the founder side, work through founder-specific terms**: vesting or reverse vesting of founder shares, lock-in periods, restrictive covenants, and the consequences attached to a founder leaving.

**8. Work through information and inspection rights, and flag any founder personal guarantee or personal indemnity the investor is seeking** — this is a significant founder-adverse term when present and should never be missed in the general sweep of the document.

**9. Grade every issue** using the same three-tier scale used throughout this practice pack: Critical for a term that concedes control or economic value disproportionate to the round, or exposes the reviewed side personally; Material for a term worth negotiating with an acceptable fallback; Minor for drafting inconsistency with little practical weight.

**10. Flag governing-law-dependent enforceability questions** — drag-along enforceability, specific performance of a pre-emption breach, restrictive covenant enforceability — as points requiring verification rather than asserting them.

## Output

**1. Parameters.** Side reviewed for, governing law, documents reviewed (including the term sheet if supplied), posture, date.

**2. Executive summary.** The handful of things that matter most, and whether any Critical findings remain open.

**3. Term-sheet consistency check.** Any term in the SHA/SSA that does not match the term sheet, if one was supplied.

**4. Control and governance.** Board composition, reserved matters, voting thresholds, assessed from the identified side's perspective.

**5. Economic terms.** Liquidation preference, anti-dilution, and pre-emption rights, read as one system with their combined effect stated.

**6. Exit mechanics.** Drag-along, tag-along, transfer restrictions, IPO provisions.

**7. Founder-specific terms**, where reviewing for the founder side — vesting, lock-in, restrictive covenants, leaver consequences.

**8. Issues list.** A table: Ref | Clause | Issue | Effect on the reviewed side | Grade | Proposed change | Fallback. Where the posture is an executed agreement not under negotiation, replace the last two columns with a single Consequence column.

**9. Points requiring verification.** Enforceability questions resting on the governing law rather than the documents' words.

## Do not

Do not assume standard venture terms — a 1x non-participating preference, broad-based weighted average anti-dilution — apply. Work from what the documents actually say.

Do not review the SHA and SSA independently without cross-checking them against each other and against any term sheet supplied.

Do not omit a founder-adverse term such as a personal guarantee or an unusually broad protective-provision list. Catching exactly these is the point of this skill.

Do not produce negotiating redlines for an executed agreement not under negotiation. State the consequence instead.

Do not assert the enforceability of drag-along, anti-dilution, or restrictive covenant provisions under the governing law. Flag them as verification points.

Referenced files: 1

View saved version →

---
name: saas-terms-drafter
description: Drafts SaaS terms of service or a customer agreement — access grant, service levels, data processing position, IP ownership, limitation of liability, and termination and data-return provisions — flagging data protection applicability, consumer-protection requirements for B2C terms, and liability-cap enforceability for verification rather than asserting them. Use this whenever a user needs terms for a SaaS product — including phrasings like "draft our SaaS terms of service", "prepare a customer agreement for our platform", "what should our data processing position say", "draft terms for a B2C subscription product", or "add termination and data-return provisions to our ToS". Fires for any software-as-a-service or platform terms of service, B2B or B2C, in any jurisdiction.
---

# SaaS Terms Drafter

## What this does

Drafts the terms of service or customer agreement for a SaaS product: the access and license grant, service level commitments, a data processing position, IP ownership, limitation of liability, and termination with data return or deletion. It drafts only what is actually instructed — it does not invent a specific SLA figure, assume B2B when the customer base could include consumers, or assert that a liability cap is enforceable without that being confirmed against the governing law.

## Before you start

**The commercial model.** The subscription structure, pricing basis, and a description of what the SaaS product actually does. Blocking — access and license terms cannot be drafted without knowing what is being licensed.

**Whether this is B2B or B2C.** Consumer-facing terms carry protections — cooling-off rights, specific dispute resolution requirements, restrictions on unfair terms — that business-to-business terms do not, in many jurisdictions. Ask; do not assume B2B by default, since getting this wrong misses real, mandatory content.

**Governing law.** Ask, unless stated. This determines what can be drafted with confidence and what has to be flagged — data protection obligations, consumer protection requirements, and liability-cap enforceability are all governing-law dependent.

Not blocking, ask once and proceed on what is confirmed: **whether a separate data processing agreement is needed, or should be incorporated into these terms.** SaaS products routinely process customer data, and this is a common, consequential gap if left unaddressed.

## Method

**1. Confirm B2B or B2C before drafting anything**, since B2C terms carry consumer-protection obligations B2B terms do not. Flag this explicitly if the customer base could plausibly include consumers even where the primary market is business.

**2. Draft the license or access grant precisely tied to the product actually described** — scope of use, permitted users, and restrictions such as no reverse engineering or no reselling.

**3. Draft service level commitments only as actually instructed.** Do not invent an uptime percentage, a support response time, or a service credit mechanism. If none has been given, either ask or state plainly that the agreement is silent on SLA and flag this as a gap the user should decide on.

**4. Address data processing.** At minimum, flag that if personal data is processed, a data processing agreement or equivalent terms covering controller and processor roles, security, and data protection obligations are likely required — and note that whether this is actually required, and what it must contain, depends on the applicable data protection law, which needs to be confirmed rather than assumed satisfied.

**5. Draft IP ownership provisions precisely** — the provider retains IP in the platform, the customer retains IP in their own data and content — and draft any feedback or improvement clause narrowly enough that it does not inadvertently claim rights over customer data beyond what was actually intended.

**6. Draft limitation of liability and indemnity provisions consistent with what is actually agreed, and flag the enforceability of any liability cap or exclusion under the governing law rather than asserting it.** Many jurisdictions restrict excluding liability for gross negligence, data breaches, or in consumer contracts specifically — this needs verification, not assumption.

**7. Draft termination and data-return provisions** — what happens to customer data on termination, export rights, and the deletion timeline.

**8. Draft payment terms and renewal mechanics, flagging that auto-renewal clauses are specifically regulated in some jurisdictions, particularly for consumer contracts**, rather than drafting one without noting this.

## Output

**1. Header.** Product or service described, B2B or B2C, governing law, date.

**2. The terms.** License grant, SLA (or explicitly flagged as absent), data processing position, IP ownership, limitation of liability, termination and data return, payment and renewal.

**3. Drafting notes.** Judgment calls made where instructions were silent.

**4. Open points and placeholders.**

**5. Points requiring verification.** Data protection law applicability, consumer protection requirements if B2C, liability-cap enforceability, and auto-renewal regulation.

## Do not

Do not invent a specific SLA commitment — uptime percentage, response time — that was not instructed.

Do not assume B2B when the customer base could include consumers, without confirming.

Do not assert that a data processing agreement is unnecessary. Flag data protection applicability as a verification point whenever personal data is processed.

Do not assert that a liability cap or exclusion is enforceable under the governing law.

Do not draft an auto-renewal clause without flagging that such clauses are specifically regulated in some jurisdictions.

Referenced files: 1

View saved version →

---
name: startup-compliance-checker
description: Checks the compliance obligations applicable to a startup given its entity structure, stage, and sector — post-incorporation and structural filings, DPIIT recognition considerations, funding-triggered compliance, and ESOP-related requirements — flagging current specific forms, deadlines, and fees for verification rather than asserting them from memory. Use this whenever a user needs a startup's compliance position checked — including phrasings like "what compliance do we need at our stage", "check our post-funding filing obligations", "does raising this round trigger any FEMA reporting", "what does DPIIT recognition actually require of us", or "build a compliance checklist for our current stage". India-specific. Fires for any private limited company or LLP startup checking its obligations by stage.
---

# Startup Compliance Checker

## What this does

Checks the compliance obligations applicable to a startup given its entity structure, incorporation stage, funding history, and sector — as a structured checklist, not a fully resolved answer. Startup compliance in India runs through administratively prescribed forms, deadlines, and fees that change periodically, and through DPIIT recognition conditions that depend on facts specific to the company, so this skill treats the current specifics as something to verify rather than something to state from memory.

## Before you start

**The entity structure and incorporation date.** Private limited company, LLP, or another structure — the compliance framework differs significantly between them. Blocking.

**The funding stage and history, and the sector.** Blocking — funding-triggered and sector-specific obligations cannot be identified without this.

Not blocking, ask once and proceed on what is confirmed: **whether DPIIT startup recognition has been obtained.** Do not assume it has — eligibility for startup-specific exemptions and benefits depends on this status, and assuming it would misstate the company's actual position.

## Method

**1. Confirm the entity structure and incorporation date first.** The compliance framework for a private limited company differs substantially from an LLP or another structure, and everything that follows depends on getting this right.

**2. Identify stage-specific obligations** — post-incorporation filings, statutory registers, first board meeting and AGM timelines — as a general framework. Flag current specific timelines and forms for verification, since these are procedurally prescribed and updated administratively.

**3. Check DPIIT recognition status, and if relevant, the obligations or relaxations tied to it.** Do not assume recognition has been obtained, and do not assume a specific tax or compliance benefit applies without that being confirmed against the company's actual status.

**4. Identify funding-round-triggered compliance** — filings triggered by allotment of shares, valuation requirements for share issuance, and whether foreign investment is involved. Where FEMA reporting is triggered, flag that it applies and point to fema-analyst for the substantive analysis rather than duplicating it here.

**5. Identify ESOP-related compliance if an option pool exists or is being created** — board and shareholder approval requirements, and any specific filing this triggers.

**6. Flag sector-specific licenses or registrations that may apply based on the business activity, without asserting a specific list exhaustively.** This is highly fact-specific; flag the need for a sector-specific check rather than presenting an incomplete list as complete.

**7. Note ongoing periodic compliance** — annual filings, statutory audits, tax filings — at a checklist level, flagging current specific deadlines and forms for verification rather than stating them as settled.

**8. Never state a current specific form number, fee amount, or deadline from memory.** These are exactly the kind of administratively-set details that change and must be verified against the current requirement.

## Output

**1. Header.** Entity, structure, incorporation date, stage, sector, date of check.

**2. Post-incorporation and structural compliance.** Checklist, with current specifics flagged for verification.

**3. DPIIT recognition status and related considerations.**

**4. Funding-triggered compliance.** Filings, a flag for FEMA reporting if triggered (pointing to fema-analyst for the substantive analysis), and valuation requirements.

**5. ESOP-related compliance**, if relevant.

**6. Sector-specific licensing.** Flagged as needing a specific check, not presented as an exhaustive list.

**7. Ongoing periodic compliance checklist.**

**8. Points requiring verification.** Current forms, deadlines, fees, and the conditions attached to any DPIIT-linked benefit.

## Do not

Do not state a current specific form number, deadline, or fee from memory.

Do not assume DPIIT recognition has been obtained without confirming it.

Do not assert a sector-specific license list exhaustively. Flag the need for a sector-specific check instead.

Do not perform the substantive FEMA analysis here. Flag that it is triggered and point to fema-analyst.

Do not apply one entity structure's compliance framework to a different structure.

Referenced files: 1

View saved version →

---
name: term-sheet-reviewer
description: Reviews a venture financing term sheet before definitive documents are drafted, flagging terms that are commonly considered off-market or adverse to the reviewed side — always framed as the reviewer's own general commercial understanding requiring the user's own confirmation against current market data, never asserted as settled fact. Use this whenever a user has received or is negotiating a term sheet — including phrasings like "review this term sheet before we sign", "flag anything off-market in these terms", "is this anti-dilution provision unusual", "check this term sheet for founder-adverse clauses", or "what's missing from this term sheet for our stage". Distinct from investment-agreement-reviewer, which reviews the definitive SHA/SSA — this works from the shorter, earlier-stage document. Fires for any term sheet, letter of intent, or heads of terms for a venture financing round, from either side.
---

# Term Sheet Reviewer

## What this does

Reviews a venture financing term sheet before definitive documents are drafted: extracting every substantive term, flagging what is commonly considered off-market or adverse to the reviewed side, checking the term sheet's own binding or non-binding status, and noting what a complete term sheet at this stage would normally address but this one does not. Every "off-market" characterisation is framed explicitly as the reviewer's own general commercial understanding, not an asserted fact — market norms shift by stage and geography, and only the user's own current data can actually confirm one.

## Before you start

**The term sheet itself.** Blocking — there is nothing to extract or flag without it.

**Which side is being reviewed for.** Ask, even though this skill is commonly used to protect the founder side by default — do not assume.

Not blocking, ask once and proceed on what is confirmed: **the stage and geography the deal sits in.** Asserting a term is off-market requires knowing which market's norms are the reference point — Series A terms in one ecosystem are not Series A terms in another. Where this is not confirmed, keep every market characterisation explicitly general and flagged for the user's own verification.

## Method

**1. Read the whole term sheet once before flagging anything.** Term sheets are short, but their terms interact — a liquidation preference term changes meaning when read against an anti-dilution term, and flagging one without the other misses the combined effect.

**2. Extract every substantive term into a structured list before assessing any of them** — valuation, instrument type, board composition, protective provisions, liquidation preference, anti-dilution, vesting, rights of first refusal or first negotiation, drag-along, exclusivity or no-shop, information rights, and any founder-specific term.

**3. State what each term actually says, plainly, before judging it.**

**4. Flag terms commonly considered founder-adverse or off-market for the stage and geography given** — a full-ratchet anti-dilution mechanism, a participating preference with an uncapped multiple, an unusually broad list of protective provisions, a personal guarantee sought from a founder, an unusually long or open-ended exclusivity period. Frame every such flag explicitly as the reviewer's own general commercial understanding, and say the user should check it against their own current market data or precedent — never present it as a settled fact.

**5. Check the exclusivity or no-shop period and its expiry date specifically.** Flag if it is open-ended or unusually long, and note the deal-process risk this creates independent of any other term.

**6. Check whether the term sheet's own binding or non-binding status is clear.** A term sheet that is unusually detailed or drafted in binding language throughout risks being treated as more than a term sheet — this is the same concern mou-drafter treats as central, applied here to a document that commonly gets this wrong by accident rather than by design.

**7. Identify what a complete term sheet for this stage and deal type would normally address but this one does not**, framed as an open question for the user to raise, not as an assumed defect.

**8. Grade each flagged term** by how much it actually shifts control or economics away from the reviewed side — the same severity thinking used elsewhere in this practice pack, even without formal Critical/Material/Minor labels being required here.

## Output

**1. Header.** Side reviewed for, stage, deal summary, date.

**2. Term-by-term summary.** What the term sheet actually says, organised by category: valuation and instrument, control, economics, exit, and process terms.

**3. Flagged terms.** Off-market or adverse terms, with the reasoning, explicitly marked as the reviewer's own commercial understanding requiring the user's own market-data confirmation.

**4. Binding/non-binding check.** Whether the term sheet's own status is clear.

**5. What's missing.** Open questions a complete term sheet at this stage would normally address.

**6. Grading.** Each flagged term rated by how much it shifts control or economics away from the reviewed side.

**7. Points requiring verification.** Current market norms for the stage and geography, and any governing-law enforceability question the flagged terms raise.

## Do not

Do not assert that a term is off-market as an established fact. Frame it as general commercial understanding requiring the user's own confirmation against current market data.

Do not review terms one at a time without checking how they interact.

Do not draft replacement language here. This is a review and flagging skill — hand off to founders-agreement-drafter, investment-agreement-reviewer, or a negotiation-planning skill for that.

Do not assume which side is being reviewed for, even though this skill is commonly used for founder protection.

Do not treat the term sheet as binding or non-binding without checking what it actually says about its own status.

Referenced files: 1