@diottodev/runic 1.0.0 → 1.1.0

package/commercial/commercial-skills/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: commercial-skills
+description: Use when reviewing, approving, or designing commercial motion — pricing models, deal review, discount approval, partnership economics, channel mix, commercial policy, RFP/RFI response, bookings forecast. Triggers on "review this deal", "should we discount", "pricing model", "partner economics", "RFP response", "bookings forecast", "channel mix". Forks context to route to one of seven Commercial sub-skills (pricing-strategist, deal-desk, partnerships-architect, channel-economics, commercial-policy, rfp-responder, commercial-forecaster) and returns a digest. Distinct from business-growth (sales execution) and c-level-advisor/cro-advisor (strategic CRO judgment).
+context: fork
+version: 2.8.0
+author: claude-code-skills
+license: MIT
+tags: [commercial, pricing, deal-desk, partnerships, channel, rfp, forecast, cro, orchestrator]
+compatible_tools: [claude-code, codex-cli, cursor, antigravity, opencode, gemini-cli]
+---
+
+# Commercial — Domain Orchestrator
+
+The Commercial surface is **per-deal economics and packaging**: how the company prices, packages, approves, and forecasts revenue. This orchestrator forks its context, routes your inquiry to one of seven sub-skills, then returns a digest. Heavy intake (RFP PDFs, pipeline exports, partner agreements) stays in the forked context.
+
+## When to invoke
+
+| Symptom | Sub-skill |
+|---|---|
+| "We're losing deals on price — should we drop prices or repackage?" | `pricing-strategist` |
+| "Can we approve a 40% discount on this Enterprise deal?" | `deal-desk` |
+| "Should we sign with this reseller? What's their tier?" | `partnerships-architect` |
+| "Is our partner channel actually profitable?" | `channel-economics` |
+| "What should our standard discount matrix look like?" | `commercial-policy` |
+| "Help me respond to this 60-page RFP" | `rfp-responder` |
+| "What's our Q4 bookings forecast at current conversion?" | `commercial-forecaster` |
+
+## Routing logic (deterministic)
+
+Same two-signal threshold pattern as `business-operations-skills`. Single-signal → clarifying question. Mixed signals → highest-confidence first, chain second in follow-up turn.
+
+### Signal table
+
+| Signal class | Keywords | Sub-skill |
+|---|---|---|
+| **PRICING** | pricing, price, packaging, tier, WTP, willingness to pay, Van Westendorp, value pricing | `pricing-strategist` |
+| **DEAL** | deal, discount, approval, margin, T&Cs, redline, exception, MSA | `deal-desk` |
+| **PARTNERSHIP** | partner, reseller, OEM, co-sell, joint GTM, revenue share, channel agreement | `partnerships-architect` |
+| **CHANNEL_ECON** | channel mix, cost to serve, channel ROI, direct vs partner, channel economics | `channel-economics` |
+| **POLICY** | commercial policy, discount matrix, T&C library, exception policy, deal framework | `commercial-policy` |
+| **RFP** | RFP, RFI, RFQ, proposal request, vendor questionnaire, security questionnaire | `rfp-responder` |
+| **FORECAST** | forecast, bookings, billings, ARR, NRR forecast, pipeline math, funnel projection | `commercial-forecaster` |
+
+## Workflow (Matt Pocock grill discipline)
+
+Derived from Matt Pocock's `grill-with-docs` pattern: **explore-then-ask, one question per turn with a recommended answer, walk the decision tree depth-first, track dependencies, anchor every challenge in the SaaS pricing / deal desk canon** (`references/`).
+
+### Step 1 — Explore before asking
+
+Check the user's working directory first:
+- Is there a deal record, pricing comp table, RFP doc, or pipeline export already in the workspace?
+- Does the inquiry already disambiguate the lane (e.g., "review this 60-page RFP" — that's `rfp-responder`, no question needed)?
+- Is there an artifact filename that resolves the lane (`pipeline-Q4.csv` → forecast; `MSA-redline.docx` → deal)?
+
+If the workspace resolves the lane, **route silently**.
+
+### Step 2 — If still ambiguous, ONE forcing question with a recommended answer
+
+Matt's rule: never bundle. Always recommend.
+
+Pattern:
+```
+Q1/1: [precise question naming the two candidate lanes]
+Recommended: [Lane X, because <signal-table rationale>]
+
+(Confirm, or override?)
+```
+
+### Step 3 — Decision-tree walk for multi-lane inquiries
+
+If the inquiry legitimately crosses two lanes (e.g., "this RFP wants a discount we don't normally give" = RFP + DEAL + maybe POLICY), walk depth-first:
+
+1. Highest-confidence lane first → run sub-skill in forked context → digest
+2. Ask: "Now run [second lane]? Recommended: yes, because [dependency]."
+3. Confirm before chaining.
+
+Never silently chain.
+
+### Step 4 — Invoke sub-skill in forked context
+
+Forward original prompt + structured inputs (pipeline CSV, RFP doc path, pricing comp table, MSA redline).
+
+### Step 5 — Return digest with cited canon challenge
+
+≤ 200 words: analyzed, top 3 findings (anchored to canon citation), top 3 next actions (named approver where applicable), artifact path, and **one grill challenge** for the user. Examples:
+
+- "Your deal scorecard shows 38% margin after discount. Skok's For Entrepreneurs benchmark says SaaS deals < 70% gross margin pre-discount need scrutiny. Did you model fulfillment cost or just COGS?"
+- "Your packaging has 14 features in Better and 16 in Best. Madhavan Ramanujam (Monetizing Innovation): tiers with no clear differentiator make 70% of customers pick the cheapest. What's the one feature that forces an upgrade?"
+
+## Forcing-question library (grill-with-docs pattern)
+
+Grill the user on lane-defining decisions before invoking the sub-skill. One per turn, recommended answer, canon citation:
+
+- **PRICING lane**: "Before picking a model: is your customer paying for outcomes, seats, or usage? Recommended: outcomes (value-based) if you can measure them. Anti-pattern (Ramanujam 2016 *Monetizing Innovation*): seat-based pricing on a usage-variable product caps your TAM at 20% of WTP."
+- **DEAL lane**: "Before approving: what's the gross margin at full discount, **and** what does next quarter's pipeline look like at the same terms? Recommended: model both. Anti-pattern (Tunguz benchmarks): one 40% precedent reshapes 3 quarters of pipeline."
+- **FORECAST lane**: "Before forecasting: are you using stage-conversion rates from the last 4 quarters, or the last 12? Recommended: last 4 weighted heavier. Anti-pattern (Skok, OpenView): equal-weighting 12 months hides the recent slowdown."
+- **PARTNERSHIP lane**: "Before signing: does the partner have **independent demand**, or are they reselling our pipeline? Recommended: insist on indep demand evidence. Anti-pattern (Forrester channel research): channel-led deals from your own pipeline cost more than direct."
+
+Never run a sub-skill until the lane-defining decision is locked.
+
+## Assumptions
+
+1. User has commercial authority OR is preparing analysis for someone who does.
+2. User wants **deterministic decision support**, not the final answer — the human approves the deal, sets the price, signs the partner.
+3. Inputs may be partial — every sub-skill ships templated dummy data so the user can see the shape before filling in their own.
+
+## Non-goals
+
+- Not a CRM, CPQ system, or contract repository.
+- Does not auto-approve deals. Every output is **a score + recommendation + human-approver routing**.
+- Does not store deal history across sessions.
+
+## Distinct from
+
+- **`business-growth/sales-engineer`** — that's the **technical sale** (demos, POCs). Commercial is **economic shape** of the deal.
+- **`business-growth/revenue-operations`** — that's **process** (lead routing, SDR motion). Commercial is **per-deal economics + policy**.
+- **`business-growth/contract-and-proposal-writer`** — that's **authoring** prose. Commercial is **decision logic + structured response**.
+- **`c-level-advisor/cro-advisor`** — that's strategic CRO judgment ("when do we hire VP Sales?"). Commercial is tactical ("approve this discount").
+- **`finance/financial-analysis`** — that's **close + report**. Commercial is **forecast + per-deal economics**.
+
+## Output artifacts
+
+| Sub-skill | Artifact |
+|---|---|
+| pricing-strategist | `pricing_model.md` + `wtp_analysis.json` |
+| deal-desk | `deal_scorecard.md` + `discount_approval_routing.json` |
+| partnerships-architect | `partner_tier_assignment.md` + `revshare_model.json` |
+| channel-economics | `channel_mix_analysis.md` + `cost_to_serve.json` |
+| commercial-policy | `commercial_policy.md` (discount matrix + exception flow) |
+| rfp-responder | `rfp_response.md` + `winrate_estimate.json` |
+| commercial-forecaster | `forecast.md` + `pipeline_math.json` |
+
+## Anti-patterns (do not)
+
+- ❌ Recommend a specific price — recommend a **range + model**, user picks the number
+- ❌ Auto-approve discounts above policy — every >X% discount routes to a named human approver
+- ❌ Generate an RFP response without proof points the user can verify
+- ❌ Forecast bookings without surfacing the **conversion assumption** explicitly
+- ❌ Run all 7 sub-skills "to be thorough" — pick one, digest, chain if needed
+
+## References
+
+- SaaS pricing canon: Tomasz Tunguz, David Skok, Bessemer Venture Partners
+- Deal desk: SaaStr playbooks, Winning by Design
+- Path-B build pattern: `documentation/implementation/bizops-commercial-expansion-plan.md`

package/commercial/deal-desk/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: deal-desk
+description: Use when reviewing a specific inbound deal before close — when sales has asked for a discount that exceeds AE authority, when the customer has redlined the MSA, when per-deal economics (margin after discount, multi-year payment shape, indemnity exposure) need to be quantified, or when discount approval needs to be routed to a named human approver (Sales Director, VP Sales, CFO, CRO, General Counsel). Covers deal review, discount approval routing, per-deal margin scoring, deal exception handling, MSA redline triage, contract landmine detection (uncapped indemnity, MFN, perpetual license-back, missing DPA), and named-approver chain assembly. NEVER auto-approves — every output is a numeric scorecard plus a routing recommendation to a named human.
+version: 2.8.0
+author: claude-code-skills
+license: MIT
+tags: [commercial, deal-desk, discount, margin, approval, redline, msa, terms]
+compatible_tools: [claude-code, codex-cli, cursor, antigravity, opencode, gemini-cli]
+---
+
+# deal-desk
+
+Per-deal review and discount-approval routing. Scores deal margin + risk, routes discount approval to the right human, redlines T&Cs against commercial policy. **Never auto-approves.** Every output is a score plus a routing recommendation to a named human approver.
+
+## Purpose
+
+Deal Desk / RevOps / sales leadership live at the moment between *sales-team-asks-for-discount* and *CFO/CRO/legal-signs*. This skill quantifies the asks and routes them.
+
+Three deterministic tools:
+
+1. `deal_scorer.py` — Scores a deal 0-100 across 5 dimensions (margin, risk, strategic value, commercial fit, term shape) and assigns one of four verdicts: **APPROVE / REVIEW / ESCALATE / DECLINE** — each tied to a named approver chain.
+2. `discount_approval_router.py` — Maps a discount-percent + deal-size + tier to a named approver chain (AE → Manager → Director → VP → CFO/CRO) with estimated cycle days. Honors industry-tuned policy bands.
+3. `terms_redliner.py` — Detects 10 founder/seller-killer patterns in deal terms (uncapped indemnity, MFN, perpetual license-back, missing DPA, NET-60+, broad non-solicit, etc.) with severity + standard counter + named legal/commercial approver.
+
+## When to use
+
+Invoke this skill when:
+
+- Sales has flagged a discount request above AE authority.
+- A customer has returned a redlined MSA and you need triage before routing to legal.
+- The deal needs CFO sign-off and you want a defensible margin breakdown.
+- An RFP response requires multi-year terms and you need to score the shape.
+- A renewal expansion is bundled with a discount and you need to verify policy fit.
+- You're building a deal-desk approval queue and need consistent routing.
+
+**Do NOT use this skill to**: author the proposal (use `business-growth/contract-and-proposal-writer`), redesign the discount matrix (use the `commercial-policy` sibling skill), or do deep legal redline of full contract text (use `c-level-advisor/skills/general-counsel-advisor`).
+
+## Workflow
+
+1. **Intake the deal** — Sales/AE fills `assets/deal_intake_template.md` with ARR, term, discount, payment terms, customer tier, strategic flags, and any customer-flagged term redlines (20-min fill-out).
+2. **Score margin + risk** — Run `deal_scorer.py --input deal.json --profile {saas|enterprise-software|services|marketplace}`. Read the composite + per-dimension breakdown + verdict.
+3. **Route the discount** — Run `discount_approval_router.py --input deal.json --profile <same>`. Get the named approver chain + estimated cycle days. Modifiers (enterprise floor, SMB fast-lane) are surfaced explicitly.
+4. **Flag the redlines** — Run `terms_redliner.py --input deal_terms.json`. Get ranked CRITICAL/HIGH/MEDIUM/LOW findings with the counter-language and the approver who must sign each.
+5. **Assemble the packet** — Combine the three outputs into a deal-desk review packet. Always include the named approver chain. The packet is **a recommendation**, not an approval.
+
+## Scripts
+
+| Script | Purpose | Industry profiles |
+|---|---|---|
+| `scripts/deal_scorer.py` | 5-dimension scorecard with verdict + chain | saas, enterprise-software, services, marketplace |
+| `scripts/discount_approval_router.py` | Discount % → named approver chain + cycle days | saas, enterprise-software, services, marketplace |
+| `scripts/terms_redliner.py` | 10-pattern landmine scanner with counters | n/a (terms-driven) |
+
+All three: stdlib-only, `--help`, `--sample`, `--input <json>`, `--output {human,json}`.
+
+## References
+
+- `references/deal_desk_canon.md` — Deal-desk operating practice: SaaStr playbooks (Jason Lemkin), Winning by Design (van der Kooij + Reichl), Forrester research, RevOps Co-op, OpenView benchmarks, Bridge Group AE comp, Salesforce Deal Desk best practices.
+- `references/discount_economics.md` — Discount math + LTV impact: David Skok (For Entrepreneurs), Bessemer State of the Cloud, Tomasz Tunguz, OpenView NRR research, Pacific Crest + KeyBanc SaaS surveys, Insight Partners revenue ops. Includes worked margin math (a 30% discount on an 80% gross-margin product loses 37.5% of margin, not 30%).
+- `references/contract_landmines.md` — 10+ named landmine patterns with example counter-language: YC startup library, Robert Klingberg (Founder's Guide to SaaS Agreements), Bowman + Brooke redline guides, IACCM/WorldCC commercial management research, Practical Law contracts library, Bradley Tusk on enterprise contracts, GC100 guidance.
+
+## Assumptions
+
+- The skill assumes the **commercial policy already exists** (discount bands, payment-terms norms, indemnity caps). It applies the policy; it does not design it. See the `commercial-policy` sibling skill for policy design.
+- Industry profiles bake in *customary* thresholds. If your company has a documented discount matrix, pass it via `policy_thresholds` in the input JSON to override.
+- The terms redliner detects the 10 most common landmines. It is **not** a substitute for General Counsel review on the full contract.
+- Scoring weights (margin 30%, risk 20%, strategic 15%, commercial 20%, term 15%) reflect a CFO-leaning bias. RevOps-led shops may want to reweight; the weights are constants at the top of `score_deal()` and are easy to tune.
+
+## Anti-patterns
+
+- **Auto-approving deals.** This skill never says "approved". Every verdict (including `APPROVE`) names the human(s) who must sign. The output is a recommendation.
+- **Skipping the redline scan** because the score is high. A high composite with `UNCAPPED_INDEMNITY` is still a DECLINE — critical signals override composite.
+- **Using this for legal review of arbitrary contract text.** This skill takes a *structured* terms JSON. For prose redlining, use `c-level-advisor/skills/general-counsel-advisor/scripts/contract_risk_scanner.py`.
+- **Treating the discount router as a discount calculator.** It routes a discount the AE/customer has already proposed; it does not calculate the right discount. Pricing logic lives in `commercial/skills/pricing-strategist`.
+- **Routing every deal to CFO.** The router stops at the lowest-authority hop that can sign the deal. Over-escalation slows the funnel and trains AEs to over-discount.
+- **Hand-editing the chain to skip a hop.** Modifiers (enterprise floor, SMB fast-lane) are explicit; hidden skips defeat the audit trail.
+
+## Distinct from
+
+| Sibling | Scope | Difference |
+|---|---|---|
+| `commercial/skills/pricing-strategist` | Sets the pricing **model** (per-seat vs usage vs tiered, list prices, packaging) | Operates at the strategy layer — not per deal |
+| `business-growth/contract-and-proposal-writer` | **Authors** proposals, SOWs, MSAs | Output is a document; deal-desk is the gate **before** signing |
+| `commercial/skills/commercial-policy` (sibling) | Designs the discount matrix and approval thresholds | Deal-desk **applies** that policy to one deal at a time |
+| `c-level-advisor/skills/general-counsel-advisor` | Deep legal redline + term-sheet analysis | Operates on full contract prose; deal-desk uses structured terms JSON |
+| `c-level-advisor/skills/cfo-advisor` | Burn rate, unit economics, fundraising models | Strategic finance; deal-desk is one-deal granularity |
+
+## Quick examples
+
+```bash
+# Score a deal
+python3 scripts/deal_scorer.py --sample
+python3 scripts/deal_scorer.py --input my_deal.json --profile enterprise-software
+
+# Route the discount
+python3 scripts/discount_approval_router.py --sample
+python3 scripts/discount_approval_router.py --input my_deal.json --profile saas
+
+# Flag the redlines
+python3 scripts/terms_redliner.py --sample
+python3 scripts/terms_redliner.py --input my_deal_terms.json --output json
+```
+
+The sample (a 28%-discount enterprise SaaS deal with uncapped indemnity + MFN) correctly DECLINEs at 55.4 / 100 composite and routes to AE → Deal Desk → VP Sales → CFO → CRO → General Counsel.
+
+## Forcing-question library (Matt Pocock grill discipline)
+
+Walked one at a time by `/cs:grill-commercial` or the Commercial orchestrator. Recommended answer + canon citation per question. Never bundled.
+
+1. **"What's the gross margin at full discount, AND what does next quarter's pipeline look like at the same terms?"**
+   Recommended: model both. Refuse to approve until the AE can articulate the precedent risk.
+   Canon: David Skok (For Entrepreneurs — discount math), Tomasz Tunguz benchmarks. Anti-pattern: one 40% precedent reshapes 3 quarters of pipeline.
+
+2. **"Is this discount inside or outside the standard discount matrix?"**
+   Recommended: if outside, surface the policy exception explicitly and route to the named exception approver.
+   Canon: OpenView discount benchmarks, RevOps Co-op playbooks.
+
+3. **"What's the strategic value beyond ARR — logo, reference, expansion path?"**
+   Recommended: require a named, verifiable expansion or reference commitment in writing.
+   Canon: SaaStr (Jason Lemkin) on logo discounts; Winning by Design on commitment language.
+
+4. **"Has the customer signed an indemnity cap, a liability cap, and a DPA (if EU data)?"**
+   Recommended: required. Uncapped indemnity is a critical-signal override that blocks APPROVE regardless of margin.
+   Canon: WorldCC (formerly IACCM) commercial management research, GC100 contract guidance.
+
+5. **"What payment terms — NET-30, NET-45, or NET-60+?"**
+   Recommended: prefer NET-30; NET-45+ is a cash flow drag worth quantifying.
+   Canon: KeyBanc SaaS Survey, Pacific Crest data — every 15 days of payment terms costs ~2% of effective deal value.
+
+6. **"Is the term multi-year with annual prepay, or annual auto-renew?"**
+   Recommended: multi-year prepay > annual prepay > annual auto-renew. Auto-renew without 60-day notice is a redline.
+   Canon: Salesforce Deal Desk best practices, OpenView NRR studies.
+
+7. **"Who is the named human approver at each hop of the discount chain?"**
+   Recommended: surface the name, not just the role. "VP Sales" is not an approver; "Maria Singh, VP Sales" is.
+   Canon: Bridge Group SaaS AE compensation research — named approval reduces precedent drift by 50%+.
+
+Walk depth-first. Lock 1-4 before opening 5-7. After all 7 are answered, invoke `deal_scorer.py` → `discount_approval_router.py` → `terms_redliner.py` in sequence.

package/commercial/partnerships-architect/SKILL.md

@@ -0,0 +1,202 @@
+---
+name: partnerships-architect
+description: "Use when a startup is approached by a prospective partner and someone has to decide should we sign this partner, at what partner tier (referral / reseller / OEM / SI-consulting / strategic alliance), with what joint GTM commitment, and at what revshare. Classifies partner tier from independent-demand evidence vs. preferential-terms hunting, designs a 90-day joint GTM plan, models revshare against direct-sale margin, and surfaces kill criteria for unwinding under-performing partnerships. For Head of Partnerships, Head of BD, and Founder-CEOs doing reseller agreement, OEM deal, or strategic alliance review — not technical sale enablement, not channel cost economics, not M&A."
+version: 2.8.0
+author: claude-code-skills
+license: MIT
+tags: [commercial, partnerships, channel-partners, joint-gtm, revshare, oem, reseller, strategic-alliance]
+compatible_tools: [claude-code, codex-cli, cursor, antigravity, opencode, gemini-cli]
+---
+
+# partnerships-architect
+
+## Purpose
+
+Help Head of Partnerships, Head of BD, and Founder-CEOs answer four questions when a
+prospective partner shows up:
+
+1. **Is this a real partner, or someone hunting preferential terms without independent demand?**
+2. **At what tier should we sign them?** (Referral / Reseller / OEM / SI-Consulting / Strategic Alliance)
+3. **What's the 90-day joint GTM plan that proves the partnership works?**
+4. **What revshare makes economic sense — and at what point does the partnership beat direct sale?**
+
+The skill emits a tier verdict + GTM plan + revshare band with explicit kill criteria. It
+does **not** sign the deal. The human, after running this skill, decides.
+
+## When to use
+
+- A prospective partner has approached and asked for reseller / OEM / "strategic" terms
+- You're designing a new partner program tier structure
+- You're reviewing an existing partnership that's underperforming and need to decide: re-tier, restructure GTM, or unwind
+- A Big Logo wants a "strategic alliance" — and you need to validate it's real, not vendor-lock theatre
+- A consulting firm or SI wants services revshare on your product
+- A platform vendor offers OEM / white-label and you need to model the math
+- You suspect "partner-sourced" deals are actually your own pipeline being skimmed for margin
+
+**Do not use for:**
+- Technical demos and POCs → `business-growth/sales-engineer`
+- Cost-to-serve and ROI math on existing channel → sibling `channel-economics`
+- Whole-company revenue strategy → `c-level-advisor/cro-advisor`
+- Acquiring a company instead of partnering → `c-level-advisor/ma-playbook`
+- Per-deal discount approval inside a signed partner contract → `deal-desk`
+
+## Workflow
+
+### Step 1 — Intake (≈ 20 min)
+
+Fill `assets/partnership_intake_template.md`. Capture: partner_name, partner_type, evidence
+of independent demand (named accounts they've sourced, end-customer relationships,
+their sales team size), strategic value (geo / product / brand / channel economics),
+commitments they've offered (joint marketing spend, dedicated headcount, certification,
+sales targets).
+
+If the intake template can't be honestly filled out, the prospective partner has not
+demonstrated enough substance to evaluate. Stop. Go back to them.
+
+### Step 2 — Tier classify
+
+Run `scripts/partner_tier_classifier.py --input intake.json --profile saas --output markdown`.
+Output ranks the partner into 1 of 5 tiers — REFERRAL / RESELLER / OEM / SI-CONSULTING /
+STRATEGIC — with deterministic floors. STRATEGIC requires named_accounts ≥ 5 AND
+multi-year commit AND dedicated resources. Skill emits rationale + kill criteria.
+
+### Step 3 — Joint GTM plan
+
+Run `scripts/joint_gtm_planner.py --input gtm.json --profile saas --output markdown`.
+Output: 90-day plan with pre-launch milestones (training, certification, materials),
+launch motion (target accounts, sales play, MDF allocation), mid-quarter checkpoint, and
+90-day success criteria. Validates: cannot plan channel-led GTM for REFERRAL tier; cannot
+plan white-label for non-OEM tier.
+
+### Step 4 — Revshare model
+
+Run `scripts/revshare_modeler.py --input revshare.json --output markdown`. Computes
+margin per deal direct vs. via partner, recommended revshare % band based on partner
+contribution depth (sourced > influenced > delivered), break-even partner ROI, and
+long-term economics — at projected scale, does partner economics beat direct?
+
+### Step 5 — Decide
+
+Take tier + GTM plan + revshare band into the partnership committee. Skill does not sign
+the partner — you do. Document kill criteria in the contract so the unwind is mechanical
+when triggered.
+
+## Scripts
+
+- `scripts/partner_tier_classifier.py` — 5-tier classifier with deterministic floors per tier
+- `scripts/joint_gtm_planner.py` — 90-day joint GTM plan generator with tier-validated motion
+- `scripts/revshare_modeler.py` — revshare band + break-even ROI + long-term economics
+
+All scripts: stdlib only. `--help` and `--sample` work on all three.
+
+## References
+
+- `references/channel_partner_canon.md` — Caro on HP indirect channels, Chintagunta on channel economics, Hessling on partner programs, Forrester channel software stack, IDC channel research, Tien Tzuo subscription-channel models, Geoffrey Moore whole-product partnerships
+- `references/joint_gtm_canon.md` — Aaron Ross *Predictable Revenue* (cold-source vs partner), Winning by Design, Jay McBain on co-sell, Microsoft Partner Network playbook, AWS Partner Network research, SiriusDecisions partner benchmarks, Bridge Group SaaS partner data
+- `references/partnership_anti_patterns.md` — Forrester partner-led-from-your-pipeline research, Tom Tunguz on channel conflict, Hessling failure analyses, MIT Sloan on disproportionate strategic revshare, HP channel post-mortems, IBM channel-conflict cases, Salesforce AppExchange research
+
+## Assumptions
+
+- A partner who cannot produce evidence of independent demand (named accounts, end-customer
+  relationships, their own sales team) is hunting preferential terms, not a partner.
+- Industry profiles (`--profile`) tune defaults — they don't override your data.
+- Revshare % bands are recommendations; the contract negotiation, MDF policy, and
+  exclusivity terms are human commercial decisions outside this skill.
+- "Partner-sourced" requires the partner to have introduced the deal AND owned the
+  primary relationship. "Partner-influenced" pays at a lower band. Pay attribution
+  matters more than slide-deck claims.
+- This skill is for partnership design, not signed-partner deal management — once
+  signed, per-deal commercial review routes to `deal-desk`.
+- Kill criteria are mandatory. A partnership without a written unwind trigger compounds
+  the bad-partner problem over years.
+
+## Anti-patterns
+
+- **"Partner = anyone who asked."** A partner with no independent demand is a discount hunter.
+  Run the tier classifier — REFERRAL tier exists precisely to absorb these without giving
+  away reseller margin.
+- **Granting OEM / white-label terms without margin sufficient to fund support.** OEM means
+  you support a customer you don't own. If the revshare doesn't fund Tier-2 support cost,
+  the OEM deal is a losing trade.
+- **Paying sourced-tier revshare on influenced-only deals.** Influenced ≠ sourced. The deal
+  was going to close anyway. Pay the influenced rate.
+- **No kill criteria for under-performing partner.** "Strategic alliances" without sunset
+  clauses become permanent obligations after the executive sponsor leaves.
+- **Channel conflict ignored until reps quit.** When your direct rep and your partner both
+  show up at the same account, you lose either the rep or the partner. Decide the rules of
+  engagement before, not after.
+- **Exclusive territory granted to a weak partner.** This locks out the strong partner who
+  would have actually sourced the deals.
+- **MDF without ROI accountability.** Market Development Funds without named pipeline,
+  reported ROI, and a quarterly true-up are subsidy, not investment.
+- **No offboarding plan when partnership ends.** Customer continuity, data hand-back, IP
+  cleanup, and brand take-down must be pre-negotiated. They're impossible to negotiate after
+  the relationship has soured.
+
+## Distinct from
+
+- **business-growth/sales-engineer** — technical sale: demos, POCs, integration scoping.
+  Operates after the partnership decision is made and a deal is in flight.
+- **channel-economics** (sibling) — cost-to-serve and ROI math on an existing channel.
+  Quantifies whether a signed partner is profitable. partnerships-architect decides
+  whether to sign in the first place and at what tier.
+- **c-level-advisor/cro-advisor** — strategic CRO judgment (when to hire a VP Channel,
+  whole-company revenue mix decisions). partnerships-architect is per-partnership.
+- **c-level-advisor/ma-playbook** — when the answer is "acquire them" not "partner with
+  them." Trigger: the partner has independent moat you cannot replicate, or the
+  partnership requires equity to align incentives. Re-route to ma-playbook.
+- **deal-desk** — per-deal discount approval on signed partner contracts.
+
+## Forcing-question library (Matt Pocock grill discipline)
+
+Walked one at a time by `/cs:grill-commercial` or the orchestrator. Recommended answer +
+canon citation per question. Never bundled. Lock 1-3 before opening 4-6.
+
+1. **"Name 5 end customers this partner has already sold to in the last 12 months — at companies you would target yourself."**
+   Recommended: if they cannot, they have no independent demand. Sign at REFERRAL tier only,
+   if at all. Reseller/OEM/Strategic floors require demonstrated end-customer relationships.
+   Canon: Joe Hessling — partner-program failure analyses identify "no independent demand"
+   as the #1 root cause of dead partner tiers.
+
+2. **"Is this partner asking for preferential commercial terms, or asking how to bring you customers?"**
+   Recommended: discount hunters lead with terms; real partners lead with accounts. Listen
+   to the first 30 minutes of the first meeting.
+   Canon: Forrester channel research — 60%+ of "partner inquiries" at early-stage SaaS are
+   discount hunting, not channel investment.
+
+3. **"What's the joint value proposition in one sentence, and who is the named end-customer it serves?"**
+   Recommended: if there is no joint value prop distinct from either party's solo offering,
+   there is no partnership — there is co-marketing at best.
+   Canon: Geoffrey Moore (*Crossing the Chasm*) — whole-product partnerships exist when
+   neither party alone delivers the customer outcome.
+
+4. **"At what % discount / revshare does this partnership beat the direct-sale economics, and at what scale?"**
+   Recommended: model break-even pipeline volume. If partner-sourced deals must exceed
+   30% of channel volume to beat direct, and partner can plausibly deliver 5%, you have
+   built a losing program.
+   Canon: Pradeep Chintagunta (Chicago Booth) on channel economics — channel partnerships
+   without volume floor break even in theory and lose money in practice.
+
+5. **"What are the named kill criteria for unwinding this partnership, and are they in the contract?"**
+   Recommended: minimum pipeline floor by quarter, minimum certified resources, minimum
+   joint deals closed, 90-day cure period. Unwinding without pre-agreed criteria becomes
+   a 2-year legal battle.
+   Canon: IBM channel-conflict case studies (1990s post-divestiture) — undocumented kill
+   criteria converted bad partners into permanent obligations.
+
+6. **"If this partner sells to one of YOUR direct accounts, who wins — your rep or them?"**
+   Recommended: Rules of Engagement in writing, signed before kickoff. Territory by named
+   account, by segment, or by geo. Conflict resolution at named human, not committee.
+   Canon: Jay McBain (Canalys) — channel conflict is the #1 partner program killer; written
+   ROE published before partner signs prevents 80% of disputes.
+
+7. **"Is this a partnership, or should this be an acquisition?"**
+   Recommended: if the partner has independent moat you cannot replicate AND the
+   partnership requires multi-year exclusivity AND the partnership requires equity-like
+   alignment, you're describing an acquisition. Re-route to `ma-playbook`.
+   Canon: HP channel post-mortems (Indigo, EDS partial integrations) — partnerships
+   structured as acquisitions-without-equity destroy more value than either pure path.
+
+Walk depth-first. Lock 1-3 (is this a real partner?) before opening 4-7 (is the structure
+right?). After all 7 are answered, invoke `partner_tier_classifier.py` →
+`joint_gtm_planner.py` → `revshare_modeler.py` in sequence.

package/commercial/pricing-strategist/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: pricing-strategist
+description: "Use when designing or revisiting product pricing — selecting a pricing model (subscription seat-based, usage-based, value-based, freemium, or hybrid), running Van Westendorp Price Sensitivity Meter analysis on WTP survey data, or designing Good/Better/Best packaging tiers. Recommends a model and a price range with trade-offs, never a single number. For Commercial leads, Product Marketing, and CMOs at the pricing-design moment — not deal-by-deal discounting, not brand positioning."
+version: 2.8.0
+author: claude-code-skills
+license: MIT
+tags: [commercial, pricing, packaging, wtp, van-westendorp, value-based-pricing, saas-pricing]
+compatible_tools: [claude-code, codex-cli, cursor, antigravity, opencode, gemini-cli]
+---
+
+# pricing-strategist
+
+## Purpose
+
+Help Commercial, Product Marketing, and CMO functions answer three questions at the pricing-design moment:
+
+1. **Which pricing model fits this product + customer + market?** (subscription seat-based, usage-based, value-based, freemium, hybrid)
+2. **What does the customer actually pay before it feels too expensive?** (Van Westendorp PSM on WTP survey responses)
+3. **How should we package this into tiers?** (Good / Better / Best — with anti-pattern detection)
+
+The skill recommends **a model and a range**. The human picks the number, owns the trade-offs, and runs the GTM.
+
+## When to use
+
+- Launching a new SaaS / API / AI tool and choosing the first pricing model
+- Revisiting pricing after 18+ months of GTM data (model shift, not just price increase)
+- Designing or redesigning tier packaging (Good/Better/Best, Bronze/Silver/Gold)
+- You have Van Westendorp survey data and want the optimal price range
+- A board / exec is asking "what should we charge?" and you need the structured answer
+- You suspect your packaging has anti-patterns (decoy tier, feature dump, no upgrade trigger)
+
+**Do not use for:**
+- Per-deal discount approval → `deal-desk`
+- Strategic CMO positioning, brand, category creation → `c-level-advisor/cmo-advisor`
+- Whole-company revenue strategy → `c-level-advisor/cro-advisor`
+- Technical-sale enablement → `business-growth/sales-engineer`
+
+## Workflow
+
+### Step 1 — Assess customer context
+
+Fill `assets/pricing_brief_template.md` (≈ 20 min). Capture: industry, deal size avg, customer count, value drivers, adoption curve, consumption pattern (seat / usage / value / hybrid), competitor models.
+
+### Step 2 — Pick the pricing model
+
+Run `scripts/pricing_model_picker.py --input brief.json --profile saas --output markdown`. Output ranks 5 models by fit-score 0-100 with trade-offs. Decision logic is deterministic: low usage variance + high seat-attach → subscription wins; power-law usage + variable customer value → usage-based wins.
+
+### Step 3 — Validate WTP with Van Westendorp PSM
+
+If you have survey data (≥ 4 questions per respondent: too cheap / bargain / getting expensive / too expensive), run `scripts/wtp_analyzer.py --input survey.json --output markdown`. Output: 4 intersection points (OPP, IDP, PMC, PME) and the Range of Acceptable Prices.
+
+PSM gives a **range**, not the price. See `references/van_westendorp_methodology.md` for common misinterpretations.
+
+### Step 4 — Design packaging
+
+Run `scripts/packaging_designer.py --input features.json --profile saas --output markdown`. Output: 3-tier Good/Better/Best assignment with anti-pattern flags (decoy tier, feature dump, no upgrade trigger, Bronze loss leader, Enterprise no-anchor).
+
+### Step 5 — Decide
+
+Take model + range + packaging into the pricing committee. Skill does not commit the number — you do.
+
+## Scripts
+
+- `scripts/pricing_model_picker.py` — 5-model fit scorer (subscription / usage / value / freemium / hybrid)
+- `scripts/wtp_analyzer.py` — Van Westendorp PSM implementation
+- `scripts/packaging_designer.py` — Good/Better/Best tier designer with anti-pattern detection
+
+All scripts: stdlib only. `--help` and `--sample` work on all three.
+
+## References
+
+- `references/saas_pricing_canon.md` — Skok, Tunguz, Campbell, Ramanujam, BVP, Shevlin, Stanford GSB
+- `references/van_westendorp_methodology.md` — original 1976 paper, NMS refinement, Conjoint.ly, Sawtooth, ESOMAR, Lipovetsky, Decision Analyst
+- `references/packaging_anti_patterns.md` — ProfitWell, OpenView, BVP vertical SaaS, Ramanujam, Poyar, SaaS Capital
+
+## Assumptions
+
+- Pricing decisions are joint: Commercial owns the model + tier shape, Product owns the features-per-tier, Finance owns the discount envelope, Legal owns the contract.
+- Van Westendorp PSM is a **directional** tool. N ≥ 30 minimum, N ≥ 100 preferred. Below 30, the script emits a sample-size warning.
+- "Value-based pricing" requires a measurable customer value driver (revenue lift, cost saved, time recovered). If you can't measure it, don't pick value-based.
+- Industry profiles tune defaults — they don't override your data.
+- This is a decision-support skill, not a price oracle. Output is a model + range, never the number.
+
+## Anti-patterns
+
+- **Recommending a specific number.** This skill emits a model and a range. Final price is a human commercial decision involving deal-desk policy, competitive intel, and strategic intent that this skill cannot know.
+- **Using PSM with N < 30.** Statistical noise dominates. The script warns; respect the warning.
+- **Treating PSM as "the price."** PSM gives a Range of Acceptable Prices (RAP) and an Optimal Price Point (OPP). Test the range in market, don't anchor on a single intersection.
+- **Picking value-based pricing without a measurable value metric.** Without instrumentation to show customer ROI, value-based collapses into "whatever they'll pay" — which is just bad usage-based pricing.
+- **Designing tiers before picking a model.** Tier structure depends on the model. Run pricing_model_picker first.
+- **Packaging "feature dumps" into the Best tier.** If Best has 3x the features for 2x the price, customers buy Better and never upgrade. See `packaging_anti_patterns.md`.
+- **Hidden usage-based pricing inside subscription tiers.** "Up to 100k API calls/mo, then $X per 1k" disguised as a "Pro tier" is two pricing models in one. Customers notice. Pick one.
+- **Confusing this skill with deal-desk.** Pricing strategy = the menu. Deal-desk = approving discounts off the menu. Different decision, different cadence, different owner.
+
+## Distinct from
+
+- **deal-desk** — per-deal discount approval, MEDDIC, deal scoring. Operates daily on existing pricing.
+- **c-level-advisor/cmo-advisor** — strategic positioning, brand, category. Pricing strategist consumes positioning as input, doesn't generate it.
+- **c-level-advisor/cro-advisor** — full-funnel revenue strategy, comp plans, territory design. Pricing strategist is one input to CRO.
+- **business-growth/sales-engineer** — technical sale, POC scoping. Sales engineering operates after pricing is set.
+
+## Forcing-question library (Matt Pocock grill discipline)
+
+Walked one at a time by `/cs:grill-commercial` or the orchestrator. Recommended answer + canon citation per question. Never bundled.
+
+1. **"Is your customer paying for outcomes, seats, or usage?"**
+   Recommended: outcomes (value-based) if you can measure them; usage if marginal cost is variable; seats only if usage is roughly flat per user.
+   Canon: Ramanujam 2016 (*Monetizing Innovation*) — Mistake #1 of 9: seat-based pricing on a usage-variable product caps TAM at ~20% of WTP.
+
+2. **"Do you have a measurable value metric, or are you guessing?"**
+   Recommended: instrument the value metric BEFORE going to market with value-based pricing.
+   Canon: Patrick Campbell / ProfitWell research — value-based without instrumentation collapses into bad usage-based pricing.
+
+3. **"What's the variance in customer usage across your top decile vs. median?"**
+   Recommended: variance > 10x → usage-based wins; variance < 3x → subscription wins; in between → hybrid with usage overage.
+   Canon: Kyle Poyar (*Growth Unhinged*) — high-variance products lose 60%+ of revenue on flat-rate plans.
+
+4. **"What's your competitor's pricing model, and why are you choosing the same or different?"**
+   Recommended: surface the differentiation hypothesis explicitly. Identical pricing = identical value claim.
+   Canon: David Skok (*For Entrepreneurs*) — pricing is a positioning signal.
+
+5. **"What sample size do you have for WTP analysis, and is it segmented?"**
+   Recommended: N≥30 per segment for PSM, N≥100 for conjoint.
+   Canon: van Westendorp 1976 / Sawtooth Software methodology — sub-30 PSM is statistical noise.
+
+6. **"What's the ONE feature that forces a tier upgrade?"**
+   Recommended: every Better and Best tier needs a single non-negotiable upgrade trigger.
+   Canon: Ramanujam (*Monetizing Innovation*) — Mistake #4: tiers with no clear differentiator make 70% of customers pick the cheapest.
+
+Walk depth-first. Lock 1-3 before opening 4-6. After all 6 are answered, invoke `pricing_model_picker.py` → `wtp_analyzer.py` → `packaging_designer.py` in sequence.