# Obligations Extractor > Pulls every obligation, deadline, condition and notice requirement out of a contract into a structured ledger, without evaluating whether any of it is fair, onerous or negotiable. Use this whenever a user wants a list, table or calendar of what a contract actually requires — including phrasings like "list every obligation in this agreement", "what are our deadlines under this contract", "build a… - **Type:** Skill - **Install:** `agentstack add skill-rohasnagpal-legal-ai-skills-obligations-extractor` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [rohasnagpal](https://agentstack.voostack.com/s/rohasnagpal) - **Installs:** 0 - **Category:** [Productivity](https://agentstack.voostack.com/c/productivity) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [rohasnagpal](https://github.com/rohasnagpal) - **Source:** https://github.com/rohasnagpal/legal-ai-skills/tree/main/plugins/contracts/skills/obligations-extractor ## Install ```sh agentstack add skill-rohasnagpal-legal-ai-skills-obligations-extractor ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Obligations Extractor ## What this does Reads a contract and produces a complete ledger of what each party is required to do, when, on what trigger, and what happens if they do not. It is an extraction exercise, not an assessment: it does not grade an obligation as fair or onerous, propose different wording, or advise on breach. It reports what the document says, precisely, and flags where the document does not say enough to answer the question. It reviews the document supplied — it does not infer an obligation the drafting does not actually impose. ## Before you start **The complete document set.** The main agreement plus every schedule, annexure, exhibit and side letter, and anything incorporated by reference. Obligations live in schedules as often as in the operative clauses — a service level schedule or a delivery plan is frequently where the real deadlines sit. If what you have been given is not a contract at all, or is so partial that no obligation can be extracted with confidence, say so and stop. Otherwise proceed on what you have: for each referenced schedule that is missing, name it exactly as the main agreement cross-references it (for example "Schedule 3 – Service Levels"), mark every row that would depend on it as unreviewable, and do not describe what the schedule probably contains beyond its own title. Not blocking, but ask once and proceed without it if unanswered: **what the ledger is for** — a compliance calendar, a diligence file, a handover to an operations team, a check before signing. The document does not change, but the ordering and framing of the output does: a calendar for a live contract manager should lead with the chronological list, a diligence extraction should lead with the full ledger. If the user wants an assessment of whether these obligations are acceptable, balanced, or worth negotiating, say that this skill only extracts and point to contract-reviewer or termination-analyst for that judgment. ## Method **1. Classify what you have been given**, in one line — complete executed agreement, complete draft, excerpt, single schedule — before extracting anything. If it is an excerpt, say that obligations created or qualified elsewhere in the document will not appear. **2. Read the whole document once before building the ledger.** An obligation stated plainly in one clause is routinely suspended by a force majeure clause, redefined by a schedule, or made conditional by a clause appearing much later. An obligation extracted from a single pass will misstate the trigger or the deadline on the clauses that matter most. **3. Find every obligation-creating clause.** Look for the operative verbs — shall, will, must, agrees to, undertakes, is responsible for, covenants — and treat each one as a candidate row. A representation or warranty that is a pure statement of fact true at signing is not an obligation and is not extracted — note it in a separate short list only if the user asks for it. But where a warranty is repeated, brought down, or given on a continuing basis (true throughout the term, or repeated at each drawdown, delivery or renewal), extract each repetition point as a recurring obligation with its own trigger and period — a breach of a repeated warranty has the same operational consequence as a missed obligation and belongs in the ledger. Do not extract recitals or background clauses even where they use obligation language — recitals are not usually operative and the document should say so, but check. **4. Alongside obligations, capture rights and procedural mechanics that carry a deadline, notice period or exercise window** — a right to terminate on notice, an option to renew or extend, a right of first refusal, a cure period, a non-renewal notice deadline. These use permissive language ("may") rather than obligation language and are not duties, so they do not belong in the obligations ledger, but a user asking this skill to "extract the notice periods" or build a calendar needs them. Record each as a right, not an obligation: who holds it, what triggers the window, the period, and what happens if it is not exercised in time. **5. For each obligation, establish six things before it goes in the ledger:** who owes it, exactly what performance discharges it, who it is owed to, what triggers it (a date, an event, another party's prior act), the deadline or period, and what the document says happens if it is not performed. Where the document is silent on any of these, record it as blank rather than inferring a market-standard answer — a blank cell is itself the finding. **6. Separate conditional obligations from unconditional ones.** An obligation that only arises "if the Buyer exercises the option" or "following a Change of Control" is a live obligation to record, but its trigger is the condition itself, not a date — say so in the trigger column rather than forcing it into the deadline column. **7. Separate recurring obligations from one-off ones**, and for recurring obligations record the recurrence pattern (monthly, quarterly, each anniversary) rather than listing every future instance individually. **8. Trace deadlines that depend on a definition.** "Business Day", "Month", "Working Day" and similar terms change what a period actually means; if the term is used in a deadline and is undefined, flag it against that row rather than assuming a calendar-day meaning. **9. Flag the structural defects a competent extraction surfaces on its own**, without turning them into a risk opinion: an obligation with no stated deadline, a deadline with no stated consequence for missing it, a trigger that depends on an act the counterparty is never itself obliged to perform (so the obligation can never actually mature), and an obligation whose obligor is ambiguous because the clause uses a defined term inconsistently with the parties clause. **10. Note which obligations survive termination or expiry**, where the document has a survival clause or says so within the obligation itself. Where the document is silent on survival for an obligation that obviously needs to outlast the contract — confidentiality, IP assignment, indemnities — record survival as unstated rather than assuming it continues. **11. Do not calculate forward from a relative period to an actual calendar date** unless the user asks for it and an anchor date is available in the document or supplied by the user. If you do calculate a date, show the arithmetic and flag the business-day and holiday convention as something the user should confirm, since the document's definition of "day" governs and may not be a plain calendar day. ## Output **1. Header.** Classification from step 1, documents extracted from (listed by name and version), documents referred to but not supplied, parties and their exact defined-term names, date of extraction. **2. Full obligations ledger.** A table, ordered by clause number: Clause | Obligor | Obligee | Obligation | Trigger | Deadline or period | Conditions | Consequence of failure | Survives termination. Leave a cell blank where the document does not say, rather than filling it with an assumption. **3. Rights, options and procedural deadlines.** A separate table for the permissive items captured in Method step 4: Clause | Holder | Right | Trigger or window | Period | Consequence if not exercised. Keep this out of the obligations ledger — a right is not a duty — but produce it in the same pass, since notice periods and exercise windows are usually what a user asking for "the deadlines" actually needs alongside the obligations. **4. Chronological deadline and notice list.** Every hard date, notice period, exercise window and recurring deadline from both tables above, reordered by when it falls or recurs, with a Type column marking each as Obligation or Right, for direct use as a calendar. Recurring items appear once with their pattern, not as repeated future instances. **5. Conditional obligations.** A short separate list of obligations that only arise on a stated condition, with the condition stated plainly and the clause reference. **6. Gaps in the extraction.** Obligations with no deadline, deadlines with no consequence, triggers dependent on an act the counterparty is never obliged to perform, undefined terms that affect a deadline's meaning, and schedules referred to but not supplied. State each as a fact about the document, not as a risk rating. **7. Points requiring verification.** Anything a full answer would depend on outside the four corners of the document — a statutory notice period that would apply by default, a public holiday calendar for a business-day calculation, the current status of a licence or registration a clause assumes exists. Name the question; do not answer it from memory. Keep every row on a single line so the tables render. On a long contract, deliver the header and the full obligations ledger first and offer the remaining sections on request rather than producing all seven sections unprompted. ## Evidence and document controls - Cite exact clause numbers, headings or document locations for every document-derived finding where available; headings never substitute for operative language. - Distinguish document facts, user-supplied facts, assumptions and legal inferences. State when a conclusion depends on governing law, disputed facts, claims classification or material outside the contract. - Check relevant definitions, order of precedence, incorporated documents, related provisions and survival language before concluding. - Name missing schedules, annexures, policies, referenced agreements and unreadable material. Never invent clauses, quotations, authorities, defined terms, dates or commercial facts. - Warn when scans, OCR, truncation, tracked changes or incomplete extraction may affect accuracy. - Preserve confidentiality. Do not send contract contents to an external service unless the user expressly requests that connected workflow. ## Do not Do not assess whether an obligation is fair, market-standard, or worth pushing back on. That judgment belongs to contract-reviewer or negotiation-position-planner; this skill's value is a complete and neutral inventory. Do not infer an obligation from language that does not actually impose one. A clause that says a party "may" deliver early is not an obligation to deliver early, and a recital describing intent is not a covenant. Do not fill a blank cell with what the drafting probably meant. A missing deadline or missing consequence is a finding, not a gap to smooth over. Do not extract from a schedule that was not supplied. Mark that portion of the ledger unreviewable, naming the schedule only as the main agreement names it — not by what it probably contains. Do not collapse two distinct obligations owed by the same party into a single row for brevity — a ledger that merges rows to look tidy stops being usable for calendaring. Do not state a statutory default period, a public holiday calendar, or any other fact external to the document from memory. Name it as a point requiring verification. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [rohasnagpal](https://github.com/rohasnagpal) - **Source:** [rohasnagpal/legal-ai-skills](https://github.com/rohasnagpal/legal-ai-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-rohasnagpal-legal-ai-skills-obligations-extractor - Seller: https://agentstack.voostack.com/s/rohasnagpal - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.