Agent Skills
› mohitagw15856/pm-claude-skills
› contract-renewal-tracker
contract-renewal-tracker
GitHub管理合同续约，计算通知截止日期而非仅续约日。提供库存清单、决策缓冲提醒及谈判检查表，防止自动续约陷阱，支持重新谈判或退出。
触发场景
track our contracts and renewals
we got auto-renewed again
when do we have to decide on this vendor
set up renewal management
安装
npx skills add mohitagw15856/pm-claude-skills --skill contract-renewal-tracker -g -y
SKILL.md
Frontmatter
{
"name": "contract-renewal-tracker",
"homepage": "https:\/\/mohitagw15856.github.io\/pm-claude-skills\/skill\/contract-renewal-tracker.html",
"metadata": {
"openclaw": {
"emoji": "🧠"
}
},
"description": "Never get auto-renewed into another year again — the contract inventory with the dates that matter (notice deadlines, not renewal dates), the calendar system with decision-time buffers, and the renewal-decision ritual that renegotiates instead of rubber-stamping. Use when asked track our contracts and renewals, we got auto-renewed again, when do we have to decide on this vendor, or set up renewal management. Produces the inventory with notice-deadline math, the alert system, the renewal-decision checklist, and the negotiation-window playbook."
}
Contract Renewal Tracker Skill
The auto-renewal ambush is a calendar failure wearing a legal costume: the contract renews on March 1, but the decision died on January 29 — the 30-day notice deadline nobody tracked (vendor-breakup-email learned this the hard way; this skill prevents needing that lesson). The tracker inventories every contract with the date that matters (notice deadline = renewal date − notice period − decision buffer), alerts at decision-time (not deadline-time — an alert with no time to decide is a countdown to the default), and attaches the renewal ritual: every renewal is a negotiation window and a vendor-comparison-matrix-lite moment, because the rubber-stamp renewal is where pricing quietly ratchets.
What This Skill Produces
- The inventory — every contract: vendor, cost, term, renewal date, notice period, the computed act-by date, owner
- The alert system — calendar entries at act-by minus the decision buffer, with owners, in a shared calendar that survives personnel changes
- The renewal ritual — the decision checklist: usage audit, market check, the renegotiation ask, then renew/renegotiate/exit
- The negotiation playbook — what the renewal window makes possible (the only time vendor leverage flips to you)
Required Inputs
Ask for these if not provided:
- The contract population — every recurring agreement: software (subscription-audit finds the small ones), services, leases, insurance, maintenance; the inventory hunt mirrors the subscription hunt at company scale
- The terms, from the documents — renewal dates and notice periods from the contracts (memory says "sometime in spring"; the contract says "60 days written notice" — the tos-decoder-grade reading of the renewal clauses)
- The owners — who decides each contract's fate; unowned contracts auto-renew by definition
- The calendar infrastructure — where alerts live such that they survive the tracker's author leaving (the shared calendar, not the personal one)
Framework: The Tracker Rules
- The act-by date is the only date: renewal date − notice period − decision buffer (30 days for simple tools, 90 for anything needing a vendor-comparison-matrix evaluation) = the date on the calendar. Tracking renewal dates instead of act-by dates is the ambush with better documentation.
- Alerts carry the decision, not just the date: the calendar entry names the contract, the cost, the owner, and the question ("Renew CRM at $18k? Act by Feb 15; notice by Mar 1; renews Apr 1") — an alert that requires archaeology to act on gets snoozed into the default.
- The ritual runs three checks before any renewal: usage (are we using what we pay for? — seat counts and feature audits routinely fund the year's savings) · market (the 30-minute competitive-scan-lite: has the category moved?) · the ask (the renegotiation email — see rule 4). Renew-as-is is a legitimate outcome of the ritual; as a default it's a pricing escalator.
- The window is your only leverage: vendors price renewals expecting rubber stamps — the notice window is the one period where "we're evaluating alternatives" is both true-sounding and consequence-bearing. The playbook asks: multi-year for a discount (only where the tool is proven), seat right-sizing, the competitor quote on the table (the-price-pushback dynamics, reversed — you're the client now). Even the ask that fails costs one email.
- The tracker survives its author: shared calendar, the inventory in the team's space (spreadsheet-handover-grade documentation), owners named per contract, and the quarterly sweep (new contracts in — the intake rule: no signature without an inventory row — departed owners' contracts reassigned). Auto-renewal ambushes cluster in the quarter after the tracker's owner leaves.
Output Format
Renewal Tracker: [org/team] — [N] contracts, [$X] annual
The Inventory
| Contract | Cost/yr | Renews | Notice | Act by | Owner |
|---|
The Alert System
[Calendar: act-by minus buffer, per contract · the alert's decision-carrying format · the shared-calendar rule]
The Renewal Ritual
[Usage audit → market check → the renegotiation ask → renew / renegotiate / exit (per vendor-breakup-email)]
The Intake + Survival Rules
[No signature without an inventory row · quarterly sweep · owner-departure reassignment]
Quality Checks
- Every date came from the contract's actual clause, not memory
- The calendar carries act-by dates with decision buffers, not renewal dates
- Every contract has a named owner
- The ritual's three checks run before any renewal
- The intake rule and quarterly sweep keep the inventory current
Anti-Patterns
- Do not track renewal dates — the act-by date is the decision's real deadline
- Do not alert without the decision context — archaeology-requiring alerts get snoozed into defaults
- Do not rubber-stamp proven tools — the usage audit and the ask cost minutes and fund budgets
- Do not keep the tracker personal — the ambushes cluster after the owner leaves
- Do not sign anything into the void — no inventory row, no signature; the intake rule is the whole system's moat
版本历史
- 471c606 当前 2026-07-22 13:18
