agentleFS
skills-agents-coskills-agents-co/skills-and-agents-library/vendor-contract-extraction/SKILL.md

vendor-contract-extraction

Skill1 starsChanged 31 days agoMITView on GitHub

Extract key terms, risk provisions, cost obligations, renewal/termination clauses, and authorized user counts across a vendor portfolio into one risk-and-cost register. Use to build or refresh a vendor risk and cost inventory.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Do NOT use this for a deep single-contract review.

    line 24
  2. Distinctive:

    Connectors are convenience, not a requirement: If a contract or spend system is connected (e.g.

    line 33
  3. Distinctive:

    Read each contract. For multi-file vendors, read the base agreement and every amendment / order form together so later terms override …

    line 43
  4. Distinctive:

    Flag, do not invent: If a term is missing or ambiguous, write "not found / unclear — confirm".

    line 76
  5. Distinctive:

    Never infer a notice period, a cost, or a renewal date that the contract does not state.

    line 77

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Vendor Contract Extraction

What this does

Reads a set of vendor contracts and pulls each one into a single structured register — one row per vendor — capturing term and renewal dates, notice periods, annual cost and payment terms, the auto-renew flag, key risk provisions, and authorized user counts. It flags the things that bite you: auto-renewals whose notice window is open, costs with no cap, and terms it could not find. The output is one consolidated risk-and-cost register you can act on.

This is the breadth tool. It sweeps the whole portfolio into a structured table. If you instead need one agreement read deeply into a risk memo, that is a different job — see "When to use it".

When to use it

  • You have a folder of vendor contracts and no single place that says what you owe, when each renews, and where the risk sits.
  • A renewal or budget cycle is coming and you need a current inventory of cost and notice deadlines.
  • You want to refresh an existing register after new contracts came in or terms changed.

Do NOT use this for a deep single-contract review. Reading one agreement clause by clause into a risk memo is the depth job, and it is a separate skill (contract-review). This skill trades depth for coverage: it is structured and portfolio-wide, not a narrative memo on one document.

Inputs — how to give it the data

  • Default: drag in the files. Drop the vendor contract files (PDF, Word, scans) or paste their text. A folder of contracts is the normal case here, not the exception — multi-file is expected.
  • Optional: an existing register to update. Hand over the current register (spreadsheet or CSV) and the skill updates rows in place and adds new vendors rather than starting from scratch.
  • Connectors are convenience, not a requirement. If a contract or spend system is connected (e.g. a contract repository, an AP or spend tool like bill.com / Ramp / Sage), it can pull from there, but nothing here requires an integration. File drag-in always works.
  • Scanned / OCR'd contracts are provisional. Numbers and dates read off an image or a noisy OCR layer are marked "confirm against source" — they are not treated as clean data until a human checks them against the original.
  • One vendor can span several files. A base agreement plus order forms and amendments is one vendor row; note every source file that fed the row.

Steps

  1. Read each contract. For multi-file vendors, read the base agreement and every amendment / order form together so later terms override earlier ones.
  2. Extract, per vendor, the suggested default field set (confirm or extend this in plan mode — it is a starting set, not a hardcode): vendor name; contract term (start/end); renewal type and date; notice period to cancel; annual cost; payment terms; auto-renew flag; key risk provisions (liability caps, indemnity, data/security, exclusivity, price-escalation); authorized user / seat counts; and the source contract + section for each field.
  3. Compile into one register, one row per vendor, with a source citation (file + section/clause) for every value.
  4. Flag the action items: auto-renewals whose notice window is open or about to open, costs with no cap or with uncapped escalators, and any term you could not find.
  5. Mark each individual value that came from a scanned/OCR'd source as "confirm against source" — field by field, not the whole row. If only the cost came off a scan, only the cost is provisional.

Rules (confirm in the plan)

Surface these in plan mode before the first run and let the operator fill them in. They are the tacit judgments the skill should not guess.

  • The exact fields the register must carry — the canonical column set and their order:
  • The renewal-window alert threshold — how many days before a notice deadline counts as "act now" versus "watch":

Output

One consolidated vendor risk-and-cost register, one row per vendor, each value carrying its source citation (file + section/clause). The suggested default columns are: vendor; term and renewal dates; notice period; annual cost; payment terms; auto-renew flag; key risk provisions; authorized user counts; and the source contract + section per field. This is a starting set the operator confirms or extends in plan mode, not a fixed schema. A short flag list rides on top: auto-renewals inside their notice window, uncapped or escalating costs, and missing/ambiguous terms. The register is a draft for a human to review and act on, not a set of decisions already made.

Error handling

  • Cite the source for every field. Each value names its source contract and section/clause. A value with no citation does not belong in the register.
  • Flag, do not invent. If a term is missing or ambiguous, write "not found / unclear — confirm". Never infer a notice period, a cost, or a renewal date that the contract does not state.
  • Never silently pass an auto-renewal. An auto-renewal whose notice window is open or about to open is always flagged for human action — the skill does not decide to let it lapse or to cancel.
  • Provisional is field-level, not row-level. Mark the specific field that came from a scan or a noisy OCR layer "confirm against source" — not the whole row. If only the cost came off a scan but the renewal date is clean digital text, only the cost is provisional. A row-level warning is too coarse; flag the exact value a human needs to recheck.
  • Treat the output like a smart intern's work — about 90% right. Audit it, especially the flagged rows. The decision to renew, renegotiate, or cancel stays with a human.

Eval contract

  • Spec: A correct run reads a set of vendor contracts and returns one register, one row per vendor, where every extracted value cites its source contract + section, auto-renewals inside their notice window are flagged, and missing terms are marked "not found", not guessed.
  • Rubric (hard-fail gates in bold):
    1. Every extracted register field cites its source contract + section; a value with no citation is an automatic fail.
    2. No fabricated values: any term the contract does not state is marked "not found / unclear — confirm", never inferred.
    3. An auto-renewal whose notice window is open or about to open is flagged, not silently passed.
    4. The register is one row per vendor with the operator-confirmed field set; multi-file vendors are consolidated into a single row that lists every source file AND applies the later term when an amendment supersedes the base contract.
    5. The output is a draft register plus a flag list for a human to act on; it does not cancel, renew, or commit anything on its own.
    6. Provisional markers are field-level: a value read from a scan or noisy OCR is marked "confirm against source" on THAT field, not as a row-level warning. Marking the whole row provisional when only one field came from a scan, or leaving a scan-sourced value unmarked, is a fail.
  • Self-test:
    • Input: a synthetic two-contract folder, evaluated as of a pinned reference date of 2026-01-15, where one contract auto-renews on 2026-03-01 with a 60-day cancellation notice period (so its notice window is open as of the reference date). Output MUST flag that vendor's auto-renewal as inside its notice window AND cite the source contract + section for every field it filled. Output MUST NOT leave the auto-renewal unflagged or list a value without a source citation. (The reference date is pinned so this test does not go flaky after publication.)
    • Input: a synthetic contract that simply omits any notice period. Output MUST mark the notice period "not found / unclear — confirm". Output MUST NOT invent or infer a notice period.
    • Input: a synthetic single vendor spread across two files — a base agreement and a later amendment that changes the renewal date and raises the annual cost. Output MUST consolidate both files into ONE vendor row, apply the LATER term (the amendment's renewal date and cost), and cite BOTH source files (the base agreement and the amendment) on the affected fields. Output MUST NOT emit two separate rows for the one vendor or apply the superseded base-contract term.
    • Input: a synthetic contract where the annual cost was read off a noisy OCR'd scan while the renewal date came from clean digital text. Output MUST mark ONLY the cost field provisional ("confirm against source") and leave the cleanly-sourced renewal date unmarked. Output MUST NOT mark the whole row provisional or leave the scan-sourced cost unmarked.
  • Version: 1.0.0

Learn more: https://skillsandagents.co/skills/vendor-contract-extraction/

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.