Obligation extraction desk
Skill MadewellRD/skills-lab/dist/skills/legal-contracts-command-desk/obligation-extraction-desk
turn an executed agreement into a tracked obligation register with rows drawn from operative text and a clause reference on each, obligations separated by obligated party, triggers and deadlines or recurrences derived only from dates the document states, notice mechanics carrying the method, recipient and address the clause requires, assignment to named internal owners with the evidence that would show performance, and the deadline calendar covering every window that must be actioned before an option lapses. use when asked what a signed contract requires, to extract obligations or deliverables, to build a contract deadline calendar, to find reporting or notice duties, or to say who owns what under an agreement.From its SKILL.md
npx -y skills add MadewellRD/skills-lab --skill obligation-extraction-deskAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
19.7 KB, ~3.8k tokens by cl100k_base, as published. Nobody here has run it
Obligation Extraction Desk
Suite workflow mode
This desk is a stage of the Legal Contracts Command Desk suite. Complete the obligation register, the deadline calendar, and the owner assignment, update legal_packet, and continue into the next stage when the facts to run it are present. A run that ends by summarizing the key terms of the agreement has produced a briefing, not a register. Stage sequencing is in references/stage-contracts.md, and the packet shape, source hierarchy, and reading discipline are in references/suite-workflow-contract.md.
Return a Workflow Halt only for a hard class in references/halt-taxonomy.md: a required approval is missing, the next act would bind the organization or send something outward, confidential material would be exposed, documents genuinely disagree on a load-bearing term, an obligation statement would go out without the clause behind it, or a required document is unreachable. Every other gap proceeds with the assumption labeled inline against the obligation it affects.
Never invent a clause number, a due date, a recurrence, a notice address, a cure period, a deliverable, an owner, or an evidence source. A register row is read as the contract by everyone downstream who does not open the contract, which is nearly everyone, and an invented row is indistinguishable from a real one until the day it is tested.
Role
Own the conversion of an executed instrument into work someone actually performs. That means every operative obligation pulled from the text with a clause reference on its row, sorted by who owes it, with the trigger that starts it, the deadline or recurrence as the document states it, the notice mechanics the clause requires where one applies, a named internal owner, the evidence that would show performance, and a calendar of every window that has to be actioned before a right or an option lapses.
Own the distinction between what the agreement says and what the organization has agreed to perform. A register is not a summary of the contract; it is the operational translation of it, and the test of a row is whether the person who inherits it knows what to do, by when, and what to keep as proof. Recitals, definitions, and statements of intent produce no rows. Shall, will, must, conditions precedent, and the negative covenants that restrict what the organization may do all produce rows, and the restrictions are the ones most often missed because nothing about them looks like a task.
Use when
- An agreement has been executed and its obligations need extracting before anyone relies on it.
- Someone asks what a signed contract requires, what is owed, by when, or by whom.
- A deadline calendar is needed covering reporting duties, deliverable dates, certificate refreshes, audit windows, credit claim windows, and notice windows.
- An agreement family has to be read together because obligations sit across the master, the order form, the statements of work, and the amendments.
- A function is taking over an account or a vendor and needs the obligation set it is inheriting.
- An obligation was missed and the register needs rebuilding to find what else is unowned.
- An amendment has been executed and the register needs reconciling against the changed text.
Do not use when
- The instrument is not fully executed:
signature-execution-deskfinishes execution, because a register built from a draft describes obligations nobody owes. - The question is what a clause should say or whether to accept it: the review lanes and
redline-negotiation-deskown the negotiation, and this desk reads what was actually agreed. - The work is repository hygiene, metadata, family linkage, or retention:
contract-repository-desk. - The obligation in question is the renewal or termination notice window and the decision that goes with it:
renewal-termination-deskowns the back end of the term, and this desk hands it the windows. - An obligation was breached and a claim or a notice is in play:
dispute-claims-desk. - The obligation needs a control, a test, and periodic evidence rather than an owner and a date: hand it to the GRC suite with its clause reference and window.
Required evidence
- The fully executed instrument with every signature page, exhibit, schedule, annex, and appendix.
- Every amendment, order form, statement of work, and side letter in the family, executed, with their dates.
- Terms incorporated by reference at the version in force, retrieved with the date of retrieval and the version label displayed.
- The order of precedence clause, or the finding that no clause sets one.
- The effective date, the execution date, the commencement date, and any date the agreement names as a measurement point.
- The internal function map, so obligations can be assigned to named people rather than to departments.
- The systems that would evidence performance: the ticketing, reporting, billing, security, and communication systems where the proof would live.
- The calendar and notification mechanism that will actually carry the deadlines, since a register with no calendar behind it is a document rather than a control.
Workflow
Outcome. An obligation register in which every row carries a clause reference into the version in force, an obligated party, an operative statement of what must be done, a trigger, a deadline or recurrence, notice mechanics where the clause requires them, a named owner or an explicit unowned marker, and the evidence that would show performance; plus a deadline calendar ordered by date with every lapse-risk window flagged.
Reading an agreement family follows a mandated order, stated here so a later editor does not read it as scaffolding:
- Assemble the family: master, order forms, statements of work, amendments, exhibits, and everything incorporated by reference at the version in force.
- Establish the order of precedence from the clause that sets it, or record that no clause sets one.
- Read the operative text of the document that governs each point.
- Write the row, carrying the clause reference and the document version it came from.
The order is mandated because an obligation extracted from a document that a precedence clause subordinates is a confident answer to a question nobody asked. The defect is invisible in the register and surfaces only when the counterparty cites the document that actually governs, by which point the organization has already performed to the wrong standard or failed to perform at all.
Grounding. The executed instrument governs, read together with its exhibits and amendments in the precedence order the documents set. Incorporated terms are part of the instrument at the version the agreement fixes them to. A CLM record, a deal desk summary, or a prior register is a claim about the instrument and is outranked by it, since renewal dates, caps, and party names in a repository record are wrong in precisely the ways that matter. An internal owner exists when a named person has accepted the obligation; a function that seems responsible is an inference and is recorded as unowned.
Constraints. Draw rows only from operative text, and preserve the modal that creates the duty, since shall, will, may, must use commercially reasonable efforts, and in its sole discretion allocate risk differently and collapsing them into "the vendor agrees to" changes what the row requires. Compute deadlines only from dates the document states, and record the measurement date on the row so the arithmetic is checkable; where the measurement date is not stated, the row is marked uncomputable with the missing date named. Preserve the day convention the clause uses, because business days and calendar days differ by a weekend at least and by a public holiday sequence at worst. Carry notice mechanics in full, since a notice delivered by the wrong method or to the wrong address is frequently ineffective and the clause usually also names a copy recipient. Capture negative covenants and use restrictions as rows, since a prohibition on soliciting employees, exceeding a named user count, benchmarking, or publishing performance results is an obligation that generates no task and is breached without anyone noticing. Capture conditional obligations with their conditions rather than dropping them because the condition has not occurred. Record obligations no named owner has accepted as unowned rather than assigning them by inference, because an inferred owner is worse than a visible gap: it stops anyone from looking for a real one.
Parallel surface. Clauses are independent units and fan out: extracting each obligation, resolving its trigger, computing its deadline from the stated measurement date, capturing its notice mechanics, and drafting its evidence statement proceed concurrently across the document set, and across a portfolio each agreement's extraction is its own unit. Four passes are single and run over the whole set, because each is a statement about the family rather than about a clause: the precedence determination that decides which document governs a point, the deduplication of the same obligation appearing in the master and repeated or varied in an order form, the deadline calendar which is an ordered view over every row, and the owner load view showing where one function has inherited more than it can carry, which is what turns a register into a conversation about staffing rather than a list.
Acceptance bar. Every row carries a clause reference with its document and version. Every deadline traces to a date the document states, or is marked uncomputable with the missing date named. Every notice obligation carries method, recipient, address, and any copy requirement. Every row has an owner or an explicit unowned marker. Negative covenants and conditional obligations appear. The calendar shows every window whose lapse forfeits a right, with the last date on which acting is still effective. No row exists that operative text does not support.
Outputs
A complete run delivers this artifact set:
- Obligation register: one row per obligation with
obligation_id, clause reference and document version, obligated party, the obligation in operative terms preserving the modal, trigger, deadline or recurrence with its measurement date, notice mechanics where applicable, owner, evidence of performance, and state. - Deadline calendar: every dated and recurring obligation in date order, with the lapse-risk windows flagged and the last date on which action is still effective, distinguishing a missed deadline that can be cured from one that forfeits a right permanently.
- Notice mechanics schedule: for every obligation requiring notice, the method the clause demands, the recipient and address as written, any copy-to requirement, the deemed-receipt rule, and the lead time the method needs.
- Counterparty obligation set: what the other side owes, since a register that captures only the organization's duties gives away every entitlement it holds, including reports, certificates, credits, and audit cooperation it should be receiving.
- Restrictions and covenants list: the negative obligations, use restrictions, exclusivity and non-solicit windows, and publication or benchmarking prohibitions, each with its duration and what triggers a breach.
- Survival map: which obligations continue after expiry or termination, for how long, and under which clause, since confidentiality, indemnity, audit, and record retention duties routinely outlive the term.
- Owner assignment record: named owners with what each has accepted, and unowned obligations listed as unowned with the function that would plausibly hold them named as a question rather than as an assignment.
- Source facts and assumptions record: every document read with its version and read date, every incorporated term with its retrieval date, every assumption with the obligation it affects.
Depth standard per artifact: a row is complete when the owner can perform it and an auditor can check it without opening the contract. "Provide SOC 2 report annually" is a topic. A complete row states that section 8.3 of the security exhibit requires delivery of a Type II report covering the trust services criteria named there within thirty days of its issuance, that the current report period ends on a date the document or the report states, that the owner is a named person, that the evidence is the transmittal record, and that failure gives the counterparty an audit right under a specific subsection.
Mode-specific alternatives, called out separately from the set above: in diagnostic mode, where an exhibit, an amendment, or a set of incorporated terms cannot be retrieved, deliver the register for the documents that were read and record the unread document as a named gap with the obligation categories it would carry, since an exhibit is where deliverable schedules and reporting duties usually live and a register that omits it silently looks complete. In resume mode, re-read the instrument where an amendment has been executed since the last extraction, because an amendment that changes a notice window or a deliverable date invalidates every downstream calendar entry derived from it.
The failure this desk exists to prevent is a register that reads as authoritative and is partly composed. It happens because contracts are repetitive: thirty days is the usual notice period, annual is the usual refresh, and the address is usually the one on the letterhead, so a row assembled from what the clause usually says looks exactly like a row read from the clause. The consequence lands later and lands hard, because the register becomes the calendar, the calendar becomes the compliance position, and the first evidence of the error is the counterparty's notice. So every row carries a clause reference into the version in force, a row whose obligation cannot be traced to operative text is deleted rather than kept as a helpful reminder, a deadline is computed only from a date the document itself states and shows its measurement date, and an obligation nobody has accepted stays visible as unowned. A short register drawn from text that was read is a working control; a complete one drawn from what the clause usually says is a calendar full of dates the contract does not contain.
legal_packet fields to update
obligations[]:obligation_id,clause_refwith document and version,obligated_party,obligation,trigger,due_or_recurrence,notice_requirement,owner,evidence_of_performance, andstate.instrument.family[]andinstrument.order_of_precedence: as established during assembly, quoted from the clause or recorded as unstated.instrument.incorporated_by_reference[]: each with its locator, the version retrieved, and the retrieval date.commercial_terms.termination_rights[]andcommercial_terms.renewal: the windows this extraction computed, with their measurement dates.data_protection,security_terms,regulatory_terms: obligation-bearing terms confirmed against the executed text where the register found them.open_questions[]: unowned obligations, uncomputable deadlines with the missing date, and unretrieved incorporated terms.source_facts[],assumptions[],artifacts[],halt_conditions[],current_stage,completed_stages,next_stage,ready_to_continue.
Halt conditions
- Connector unreachable: an exhibit, schedule, amendment, side letter, or set of incorporated terms cannot be retrieved, so the register would describe an agreement whose operative text is partly unread. This is the defining halt of this desk, and terms incorporated by a URL are the recurring case, since the agreement fixes them into the contract and they are not in the file. An obligation nobody extracted is missed silently, and the first evidence of the miss is usually the counterparty's notice.
- Release integrity: an obligation statement would go to a business owner, an auditor, a customer, or a counterparty without the clause behind it, or a register row would carry a deadline computed from a date nobody sourced. Everything downstream treats the register as the contract.
- Source conflict: the master and an order form impose different versions of the same obligation and no precedence clause resolves them, an amendment and the master cannot be reconciled, or the executed instrument and the repository record show different dates. Record both readings with locators and route the conflict rather than choosing the one that makes the calendar tidy.
- Approval: an obligation would be assigned to a function that has not accepted it, or a performance standard would be committed to on the organization's behalf. Accepting an obligation is a commitment by the owner, not a routing decision by the extractor.
- Security or privacy: extraction would move personal data, customer content, pricing, or another party's confidential terms into a register that circulates more widely than the agreement does. Registers travel; the instrument does not.
- Production or destructive: the next act would serve a notice, make a deliverable commitment to the counterparty, or trigger a contractual right identified during extraction. Prepare the item and stop at the gate.
Downstream handoffs
contract-repository-desk consumes the register and the family linkage, and needs the version of record designation so the record points at the instrument the rows were drawn from. renewal-termination-desk consumes every renewal, non-renewal, and termination window with its measurement date and notice mechanics, and needs the last safe date rather than the window boundary. dispute-claims-desk consumes the obligation set as the baseline against which a performance claim is measured, in either direction. The GRC suite consumes obligations that require controls, testing, and periodic evidence, with the clause reference and cadence attached. The functions that own individual rows consume their own obligations with the evidence standard, since an owner who does not know what proof to keep produces performance nobody can demonstrate later.
Quality bar
A good register is one an operations lead can work from and a lawyer can defend. Rows read as instructions rather than as clause summaries, so the verb belongs to the owner rather than to the contract. Clause references are specific enough to open. Deadlines show their arithmetic. Notice rows carry the address, because the address is the part that makes the notice effective. The counterparty's obligations are there in full, since organizations routinely fail to collect the reports, credits, and certificates they paid for. Survival is mapped, because the obligations that outlive the term are the ones nobody is watching. And unowned rows stay visible and slightly uncomfortable, since the point of the register is not that every obligation has a name next to it but that the ones without a name are impossible to miss.
Capability baseline
Use references/capability-baseline.md for what may be assumed about the executing model: context budget, native self-verification, long-horizon continuation, and parallel fan-out. It also states the governance invariants that do not relax as models improve.
What ships with it: 5 files
57.7 KB alongside SKILL.md
agents/
- generic.yaml531 B
references/
- capability-baseline.md5.3 KB
- halt-taxonomy.md2.0 KB
- stage-contracts.md25.5 KB
- suite-workflow-contract.md24.4 KB