142 added, 48 removed. Audit A to A.
---
name: kelly-clm
- description: Lightweight contract lifecycle management App-in-Skill for contract inventory, lifecycle status, owners, obligations, renewal notices, and simple approval reminders. Use when the user invokes $kelly-clm or /kelly-clm, mentions CLM, contract lifecycle management, 合同管理, 合同台账, contract repository, obligation tracking, renewal reminders, notice deadlines, contract owners, signature readiness, or wants a simple local UI to review contract status without doing detailed legal redlines.
+ description: Lightweight contract lifecycle management App-in-Skill (Busabase App-in-Skill) for contract inventory, lifecycle status, owners, obligations, renewal notices, and simple approval reminders. Use when the user invokes $kelly-clm or /kelly-clm, mentions CLM, contract lifecycle management, 合同管理, 合同台账, contract repository, obligation tracking, renewal reminders, notice deadlines, contract owners, signature readiness, or wants a simple UI to review contract status without doing detailed legal redlines.
---
# Kelly CLM
## Overview
- Use this skill as a lightweight contract lifecycle desk. It tracks contract records, lifecycle stage, owner, renewal/notice dates, obligations, and approval reminders in a local browser UI.
+ Kelly CLM is a Busabase Cloud App-in-Skill. Its canonical product surface is
+ the AirApp in Busabase, not a separate local-data product. The same Hono
+ source supports an explicitly requested local preview with OAuth connection
+ bootstrap. It is a lightweight contract lifecycle desk: contract inventory,
+ lifecycle stage, owner assignment, renewal/notice dates, obligations, and a
+ simple approval/reminder queue.
- This skill is intentionally simpler than `kelly-legal-contracts`: use `kelly-clm` for contract operations and reminders; use `kelly-legal-contracts` when the user needs detailed legal clause review, fallback language, redline positions, or legal issue lists.
+ This skill is intentionally simpler than `kelly-legal-contracts`: use
+ `kelly-clm` for contract operations and reminders; use `kelly-legal-contracts`
+ when the user needs detailed legal clause review, fallback language, redline
+ positions, or legal issue lists.
- ## Product Pattern
+ This is a direct-manipulation control panel, not a review-then-approve
+ queue: creating or editing a contract, marking an obligation done,
+ acknowledging a renewal notice, and recording an approval decision are all
+ direct writes made straight through `busabase-sdk` from the browser — the
+ same way `kelly-lead-funnel`'s kanban stage moves and
+ `kelly-revshare-simulator`'s scenario CRUD work. There is no separate
+ decisions/handoff-log bucket; a decision writes directly onto the item's own
+ Busabase record. Obligations and approval reminders themselves enter
+ Busabase through an external process (the operator or an agent workflow
+ adding them directly in Busabase) — the AirApp only ever decides on them
+ (mark done / acknowledge / approve), it never creates them; only contracts
+ are created/edited through the browser.
- Read `references/clm-notes.md` before changing scope. The app borrows only common CLM patterns: central repository, lifecycle status, owner assignment, obligation tracking, renewal reminders, simple workflow approvals, and handoff records.
+ Default behavior is AirApp-first. Unless the user explicitly asks only for
+ explanation, give the user the clickable AirApp URL. Start localhost only
+ when local preview/debugging is explicitly requested; it uses the same
+ Busabase resources and never offers another data provider. Use chat-only
+ mode only when the user says "纯聊天", "chat only", "不要打开 UI", or similar.
- ## Local App
+ Read `references/clm-notes.md` before changing scope. The app borrows only
+ common CLM patterns: central repository, lifecycle status, owner assignment,
+ obligation tracking, renewal reminders, simple workflow approvals, and
+ handoff records.
- Start the app with:
+ ## Mandatory Dependencies
- ```bash
- skills/kelly-clm/app/start.sh
- ```
+ 1. Read and follow `$kelly-app-skill-creator` for product behavior, visual
+ quality, responsive layout, and the complete canonical `app/` artifact.
+ 2. Read and follow `$busabase` for connection, target Space, node discovery,
+ ChangeRequests, review, and merge behavior.
+ 3. Read and follow `$busabase-app-creator` for resource modeling, AirApp
+ runtime limits, security, validation, and deployment.
- The app runs on `127.0.0.1`, defaults to port `3000` through `4000`, and accepts `KELLY_CLM_UI_PORT`.
+ If a dependency is unavailable, preserve this skill's artifact and product
+ contracts, stop before the unavailable Busabase operation, and report the
+ exact missing dependency. Do not invent a second data backend.
- Views:
+ ## App UI Screenshots
- - `#/overview`: lifecycle pipeline, key metrics, upcoming renewals, at-risk obligations.
- - `#/contracts`: searchable contract inventory.
- - `#/contracts/<id>`: contract detail with dates, owners, obligations, and reminders.
- - `#/obligations`: obligation tracker by owner, due date, and status.
- - `#/renewals`: renewal and notice-deadline board.
- - `#/approvals`: simple approval/reminder queue; decisions write local handoff records only.
- - `#/settings`: boundary and demo/config summary.
+ <table>
+ <tr>
+ <td width="50%"><img src="assets/screenshots/overview.webp" alt="Kelly CLM overview"></td>
+ <td width="50%"><img src="assets/screenshots/contracts.webp" alt="Kelly CLM contract inventory"></td>
+ </tr>
+ <tr>
+ <td><strong>Overview</strong><br>Lifecycle dashboard with stage pipeline, upcoming renewals, and at-risk obligations.</td>
+ <td><strong>Contracts</strong><br>Searchable contract inventory with owner, stage, value, and dates; create/edit directly.</td>
+ </tr>
+ <tr>
+ <td width="50%"><img src="assets/screenshots/obligations.webp" alt="Kelly CLM obligations"></td>
+ <td width="50%"><img src="assets/screenshots/renewals.webp" alt="Kelly CLM renewals"></td>
+ </tr>
+ <tr>
+ <td><strong>Obligations</strong><br>Owner-assigned obligation tracker with due dates, status, and a mark-done action.</td>
+ <td><strong>Renewals</strong><br>Renewal board with notice deadlines and a renewal-notice acknowledgement action.</td>
+ </tr>
+ <tr>
+ <td colspan="2" width="100%"><img src="assets/screenshots/approvals.webp" alt="Kelly CLM approvals"></td>
+ </tr>
+ <tr>
+ <td colspan="2"><strong>Approvals</strong><br>Approval/reminder queue for renewal notices and obligation owners, with approve / request-changes / block written directly onto the record.</td>
+ </tr>
+ </table>
- Demo routes:
+ ## Boundary
- ```text
- /?demo=overview&lang=en#/overview
- /?demo=contracts&lang=en#/contracts
- /?demo=obligations&lang=en#/obligations
- /?demo=renewals&lang=en#/renewals
- /?demo=approvals&lang=en#/approvals
- ```
+ - This skill is an operations tracker, not legal advice.
+ - The app never sends emails, starts e-signature, updates a remote CLM,
+ accepts terms, signs contracts, or contacts counterparties.
+ - The AirApp reads and writes its own Busabase Bases only; there is no
+ execution/merge step beyond the direct write itself. There is no delete
+ operation anywhere in this skill's UI (create/edit a contract, mark an
+ obligation done, acknowledge a renewal notice, and record an approval
+ decision are all create/update writes), so unlike
+ `kelly-revshare-simulator`'s scenario delete, no Busabase
+ review-before-merge step is ever needed here.
+ - Keep contract text, counterparties, prices, and notes out of committed
+ files. Use demo data for screenshots.
- Use `lang=zh` for Chinese UI screenshots.
+ ## Busabase Resources
- ## Boundary
+ Three Bases under one application Folder (`kelly-clm`), declared in
+ `app/app/js/config.js` and `app/resource-map.json`:
- - This skill is an operations tracker, not legal advice.
- - The app never sends emails, starts e-signature, updates a remote CLM, accepts terms, signs contracts, or contacts counterparties.
- - Approval buttons write local decision records only; any external action must happen through the user or a separate explicitly approved connector.
- - Keep contract text, counterparties, prices, and notes out of committed files. Use demo data for screenshots.
+ - `contracts`: one row per contract — counterparty, type, lifecycle stage,
+ owner, business owner, value, start/end dates, renewal date, notice
+ deadline, next action, risk, and renewal-notice acknowledgement timestamp.
+ Created/edited directly by the operator through the browser.
+ - `obligations`: one row per contract obligation/milestone — linked contract,
+ title, owner, due date, status, and evidence note. Status is toggled
+ directly by the operator (mark done / reopen).
+ - `approvals`: one row per approval/reminder handoff linked to a contract —
+ title, summary, and status. The operator's decision (approve / request
+ changes / block) is written directly onto this row.
- ## Workflow
+ Resources provision lazily through an idempotent Busabase ChangeRequest the
+ first time the app runs in a Space.
- 1. Collect or import contract summary fields: counterparty, contract type, owner, stage, value, start/end date, renewal date, notice deadline, and key obligations.
- 2. Populate the local app snapshot or use demo mode when no private data is available.
- 3. Send the user to the app for review of upcoming renewals, at-risk obligations, and pending approvals.
- 4. Treat approved items as handoffs only. Do not perform external side effects from the app.
+ ## Views
- ## Screenshot Scenes
+ - `#/overview`: lifecycle pipeline, key metrics, upcoming renewals, and
+ at-risk obligations.
+ - `#/contracts`: searchable contract inventory.
+ - `#/contracts/new`: new contract form (direct create).
+ - `#/contracts/<id>`: contract detail with dates, owners, obligations, and
+ an inline edit form (direct update).
+ - `#/obligations`: obligation tracker by owner, due date, and status, with a
+ mark-done/reopen action per row.
+ - `#/renewals`: renewal and notice-deadline board, with an acknowledge
+ action per contract carrying a notice deadline.
+ - `#/approvals`: approval/reminder queue; approve / request-changes / block
+ write the decision directly onto the approval record.
+ - `#/settings`: boundary and demo/config summary.
- Screenshots live in `assets/screenshots/`:
+ ## Demo Mode
- - `overview.png`: lifecycle dashboard.
- - `contracts.png`: contract inventory.
- - `obligations.png`: obligation tracker.
- - `renewals.png`: renewal board.
- ## App workflow
+ - `?demo=1` opens a deterministic, fully offline mock of four contracts
+ (Nimbus Analytics MSA, Orbit Processor DPA, Luma Implementation SOW, Acme
+ Mutual NDA), four obligations, and two approvals. It never reads or writes
+ Busabase; demo create/edit/mark-done/acknowledge/decision actions only
+ update the in-memory snapshot already rendered in the browser tab.
+ - `lang=en` or `lang=zh` forces UI chrome language for screenshots.
- Default to the local app for review. Use chat-only mode only when the user explicitly asks for "chat only", "no UI", "纯聊天", or "不要打开 UI".
+ ## Local App
- ## Execution reports
+ Default behavior is AirApp-first — give the user the clickable AirApp URL.
+ Start `pnpm --dir app dev` only when local preview/debugging is explicitly
+ requested.
- Re-read the active provider's decisions immediately before any approved execution. Record each concrete operation, target, status, timestamp, and error in the provider-backed execution report; keep app actions local-only.
+ ## Completion Criteria
+
+ Finish only when:
+
+ - the skill contains the complete canonical `app/` project and
+ `pnpm --dir app dev` remains supported;
+ - all persistent config, state, and domain data use `busabase-sdk` and the
+ declared resource map — no local JSON, browser storage, or provider
+ choice;
+ - Vault values and API credentials never reach browser-visible surfaces;
+ - local setup offers Cloud/custom URL OAuth plus the explicit Demo path,
+ while a deployed AirApp uses its ambient session;
+ - Overview, Contracts, Obligations, Renewals, Approvals, and Help & Settings
+ render on desktop and phone widths;
+ - `pnpm --dir app run check` and `node --test` pass.
+
+ ## Stop Conditions
+
+ Stop before consequential Busabase mutation when the target Space is
+ ambiguous, the current user lacks permission, or a same-slug resource is not
+ application-owned. Never perform e-signature, counterparty contact, or any
+ other external side effect from the AirApp.