---
name: non-standard-terms-detection
version: 1.0.0
deployment_target: plugin
status: PROPOSED
description: "Scans deal notes and opportunity fields for payment terms, contract structures, and custom provisions outside the standard playbook. Detection patterns: payment terms net >30 days, multi-year ramps/price locks, SLA commitments, data residency requirements, indemnification carve-outs, source code escrow. Routes to Legal or Finance when required. Triggers: 'non-standard terms', 'off-playbook deal', 'custom provisions', 'payment terms', 'SLA commitment', 'data residency'."
---
[PROPOSED]
# Non-Standard Terms Detection
Catches off-playbook provisions before they become legal or financial surprises.
**Reference:** Governance tiers → `../../../shared/revops-domain-model.md §9`
**Config reads:** `payment_terms_standard_days`, `linear_connected`
---
## Pre-flight
Read `~/.claude/plugins/config/claude-for-customer-success/rev-ops/CLAUDE.md` and
`~/.claude/plugins/config/claude-for-customer-success/company-profile.md`.
If either is missing or contains `[PLACEHOLDER]` markers, stop and prompt for
`/rev-ops:cold-start-interview`.
Note from config: `payment_terms_standard_days`, `linear_connected`
**G-code dependency:** All G-code guardrails referenced in this skill (G1–G9) are defined in the CLAUDE.md config loaded above. If Pre-flight halts or config is missing, G-codes are undefined — do not proceed with partial config.
---
## Use when
- Deal notes or contract terms contain non-standard language that needs flagging before close
- Legal or finance review triggers need to be identified from deal context
- Deal desk submission requires non-standard terms inventory
## Do NOT use for
- Full deal desk routing (use deal-desk-workflow-management)
- Revenue leakage structural analysis (use revenue-leakage-scanning)
- ARR classification (use deal-classification)
## Typical Activation
"Non-standard terms", "flag unusual contract terms", "what terms need legal review", "non-standard terms for [deal]", "check deal notes for flags"
---
## Reasoning Protocol
Before generating output, apply these primers:
1. **CLASSIFY**: What type of non-standard terms request is this?
- Single-deal scan (one account — full pattern check across all six detection categories)
- Deal desk pre-submission review (comprehensive inventory before deal desk routing)
- Targeted provision check (user flagging a specific clause type — payment terms, SLA, data residency)
- Batch pipeline scan (multiple deals flagged for terms review before quarter close)
2. **CONSTRAINTS**: What limits the solution space?
1. Confirm activation — user requesting terms review for a specific deal or set of deals
2. Pull deal notes and contract fields from HubSpot; declare connector status and data-as-of timestamp per G6
3. Apply G1 — payment terms affecting revenue recognition require Finance routing before deal close
4. Apply Write-tier — Linear issue creation to Legal or Finance requires explicit user confirmation before execution
5. Confirm `payment_terms_standard_days` from config before classifying payment term deviations
6. Confirm `linear_connected` from config before proposing Linear issue creation
7. Route mandatory provisions (indemnification carve-outs, source code escrow) to Legal regardless of deal size
3. **EXPERT CHECK**: What would a veteran RevOps deal desk analyst verify before surfacing findings?
- Are payment terms classified against the configured standard, not a generic assumption? Net 30 is common
but not universal — the configured `payment_terms_standard_days` is the baseline, not training memory.
- Is the Finance routing trigger applied correctly for deferred or quarterly billing? These structures
affect revenue recognition timing, not just cash flow — RevRecog review is a separate requirement
from Finance approval, and both must surface explicitly.
- Are mandatory Legal provisions flagged unconditionally? Indemnification carve-outs and source code
escrow requests are mandatory Legal review regardless of other deal signals — they cannot be
downgraded based on deal size or segment.
- Is the Write-tier confirmation surfaced before queuing any Linear issue? A finding log and an issue
are different outputs — the finding goes in the report; the issue requires explicit confirmation.
4. **ANTI-PATTERNS**: Common mistakes to avoid:
- Classifying payment terms against a generic net-30 assumption instead of `payment_terms_standard_days`
- Omitting RevRecog review flag on deferred/quarterly billing structures (Finance approval ≠ RevRecog review)
- Downgrading mandatory Legal provisions (indemnification, source code escrow) based on deal size
- Queuing Linear issues without surfacing Write-tier confirmation prompt first (G9 analog for legal routing)
- Pulling HubSpot deal notes without data-as-of timestamp (G6 violation)
**After execution**, verify:
- G1 qualifier present — payment terms with RevRecog implications flagged for Finance routing before close
- G6 data-as-of label applied to all HubSpot deal note reads
- Write-tier confirmation surfaced for all proposed Linear issues — none queued autonomously
- Mandatory provisions (indemnification, source code escrow) routed to Legal unconditionally
- Confidence: High when HubSpot connected and deal notes current; Moderate when connector unavailable or terms sourced from rep-provided notes only
- Confidence: [High] when HubSpot connected and deal notes current / [Medium] when connector unavailable or terms from rep-provided notes / [Low] if all inputs are manual or unverified
---
## Detection Patterns and Routing
```
Payment terms:
net > payment_terms_standard_days → Finance review
quarterly/deferred billing → Finance + RevRecog review
Multi-year structures:
Price lock clauses → Finance approval
Ramp schedules → Finance + RevOps approval
Renewal caps → Legal + Finance review
Custom provisions:
SLA commitments → Legal + CS Ops review
Data residency requirements → Legal + Eng review
Indemnification carve-outs → Legal review (mandatory)
Source code escrow requests → Legal + Eng review (mandatory)
```
---
## Output
```
NON-STANDARD TERMS — [Account Name]
[HubSpot ✓ live — as of YYYY-MM-DD]
Findings:
[Term type] Standard: [what's standard] Found: [what's in the deal]
Route to: [Legal / Finance / Both] Priority: [HIGH/MEDIUM]
No non-standard terms detected: [if clean]
Linear issues to create:
[ ] Legal: [specific provision] — confirm to create
[ ] Finance: [specific provision] — confirm to create
```
## Reference Files
| File | Purpose |
|------|---------|
| `references/reasoning-blueprint.md` | Problem classification taxonomy, domain heuristics, common failure modes, and expert judgment patterns for this skill |
## Security & Permissions
**Network access:** None direct — all external data access is mediated by host-provided MCP connector tools (HubSpot, CS platform, Slack, Linear). This skill makes no direct outbound HTTP calls.
**Filesystem scope:** None — this skill does not read or write local files. All data is provided at runtime via parameters or MCP connector responses.
**Subprocess execution:** None.
**Dynamic code execution:** None — pseudocode in this skill represents the logic contract and is not executed at runtime.
**Data sensitivity:** Inputs may contain confidential deal and pipeline data. Handle with RevOps-level confidentiality.
## Trust & Verification
**Input trust model:** All user-provided parameters are treated as untrusted at intake. Numeric inputs are validated for plausible range before use in calculations. String inputs are not evaluated as code.
**Output trust model:** All outputs are proposals or analytical inputs — no outputs constitute approved decisions, revenue commitments, or system actions without explicit human confirmation.
**Connector data:** Data retrieved via MCP connectors is treated as read-only observed state. Timestamps and data-as-of labels are applied to all connector-sourced values per G6.
**Write-tier confirmation:** Any proposed write to HubSpot, Linear, or Slack is surfaced as a draft requiring explicit user confirmation before execution.
## Guardrails
- G1: RevRecog implications require Finance routing before deal close
- Write-tier: Issue creation requires confirmation