{"items":[{"id":"cmugucv6d00mwqu06fw9jpelb","slug":"travisvn-awesome-claude-skills-awesome-claude-skills","name":"Awesome Claude Skills","description":"A curated list of awesome Claude Skills, resources, and tools for customizing Claude AI workflows β particularly Claude Code","authorId":"gh:travisvn","authorName":"travisvn","version":"0.1.0","category":"MCP","securityLevel":"Community","downloadsCount":0,"githubStars":15170,"pricePerCall":0,"manifest":{"name":"Awesome Claude Skills","tools":[],"category":"MCP","entrypoint":{"args":["-y","github:travisvn/awesome-claude-skills"],"type":"mcp-stdio","command":"npx"},"description":"A curated list of awesome Claude Skills, resources, and tools for customizing Claude AI workflows β particularly Claude Code","permissions":["shell","network"],"schemaVersion":1},"repoUrl":"https://github.com/travisvn/awesome-claude-skills","tags":["agentic-coding","anthropic","awesome","awesome-list","awesome-lists","claude","claude-ai","claude-code","claude-desktop","claude-skills","claudeskills","mcp"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"awesome-claude-skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T10:52:07.717Z","lockfiles":[]},"forks":1990,"owner":"travisvn","stars":15170,"topics":["agentic-coding","anthropic","awesome","awesome-list","awesome-lists","claude","claude-ai","claude-code","claude-desktop","claude-skills","claudeskills"],"license":null,"fullName":"travisvn/awesome-claude-skills","homepage":null,"language":null,"pushedAt":"2026-04-28T19:30:24Z","avatarUrl":"https://avatars.githubusercontent.com/u/2686415?v=4","crawledAt":"2026-09-25T10:52:07.481Z","openIssues":839,"manifestFile":"README.md","manifestPath":"README.md","defaultBranch":"main"},"readme":"
\n\n# Awesome Claude Skills\n\n[](https://awesome.re)\n[]()\n[](CONTRIBUTING.md)\n\n> A curated list of awesome Claude Skills, resources, and tools for customizing Claude AI workflows\n\n**Claude Skills** teach Claude how to **perform tasks in a repeatable way**\n\nThey are specialized folders containing instructions, scripts, and resources that Claude dynamically discovers and loads when relevant to tasks.\n\n### How Skills Work\n\nSkills employ a **progressive disclosure architecture** for efficiency:\n\n1. **Metadata loading** (~100 tokens): Claude scans available Skills to identify relevant matches\n2. **Full instructions** (<5k tokens): Load when Claude determines the Skill applies\n3. **Bundled resources**: Files and executable code load only as needed\n\nThis design allows multiple Skills to remain available without overwhelming Claude's context window.\n\n## π Getting Started\n\n### Claude.ai Web Interface\n\n1. Go to [Settings > Capabilities](https://claude.ai/settings/capabilities)\n2. Enable Skills toggle\n3. Browse available skills or upload custom skills\n4. **For Team/Enterprise**: Admin must enable Skills organization-wide first\n\n### Claude Code CLI\n\n```bash\n# Install skills from marketplace\n/plugin marketplace add anthropics/skills\n\n# Or install from local directory\n/plugin add /path/to/skill-directory\n```\n\n### Claude API\n\nSkills are accessible via the `/v1/skills` API endpoint. See the [Skills API documentation](https://platform.claude.com/docs/en/api/beta/skills) for detailed integration examples.\n\n```python\nimport anthropic\n\nclient = anthropic.Client(api_key=\"your-api-key\")\n# See API docs for full implementation details\n```\n\n## π― Official Skills\n\n### Document Skills\n\nSkills for working with complex file formats:\n\n- **[docx](https://github.com/anthropics/skills/tree/main/skills/docx)** - Create, edit, and analyze Word documents with support for tracked changes, comments, formatting preservation, and text extraction\n- **[pdf](https://github.com/anthropics/skills/tree/main/skills/pdf)** - Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms\n- **[pptx](https://github.com/anthropics/skills/tree/main/skills/pptx)** - Create, edit, and analyze PowerPoint presentations with support for layouts, templates, charts, and automated slide generation\n- **[xlsx](https://github.com/anthropics/skills/tree/main/skills/xlsx)** - Create, edit, and analyze Excel spreadsheets with support for formulas, formatting, data analysis, and visualization\n\n### Design & Creative\n\n- **[algorithmic-art](https://github.com/anthropics/skills/tree/main/skills/algorithmic-art)** - Create generative art using p5.js with seeded randomness, flow fields, and particle systems\n- **[canvas-design](https://github.com/anthropics/skills/tree/main/skills/canvas-design)** - Design beautiful visual art in .png and .pdf formats using design philosophies\n- **[slack-gif-creator](https://github.com/anthropics/skills/tree/main/skills/slack-gif-creator)** - Create animated GIFs optimized for Slack's size constraints\n\n### Development\n\n- **[frontend-design](https://github.com/anthropics/skills/blob/main/skills/frontend-design)** - Instructs Claude to avoid \"AI slop\" or generic aesthetics and to make bold design decisions. Works very well for React & Tailwind.\n- **[web-artifacts-builder](https://github.com/anthropics/skills/tree/main/skills/web-artifacts-builder)** - Build complex claude.ai HTML artifacts using React, Tailwind CSS, and shadcn/ui components\n- **[mcp-builder](https://github.com/anthropics/skills/tree/main","createdAt":"2026-09-25T10:52:07.766Z","updatedAt":"2026-09-25T10:52:07.766Z"},{"id":"cmugwhth501hbqu06gtmvvspa","slug":"wesammustafa-claude-code-everything-you-need-to-know-claude-md-r","name":"claude-md-review","description":"Audit a CLAUDE.md file for the patterns that actually degrade Claude Code's output β vagueness, unnamed files, stale facts, and bloat. Use when asked to review, audit, improve, shrink, or fix a CLAUDE.md, and when a project's results feel inconsistent or Claude keeps rediscovering the same context.","authorId":"gh:wesammustafa","authorName":"wesammustafa","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":3046,"pricePerCall":0,"manifest":{"name":"claude-md-review","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Audit a CLAUDE.md file for the patterns that actually degrade Claude Code's output β vagueness, unnamed files, stale facts, and bloat. Use when asked to review, audit, improve, shrink, or fix a CLAUDE.md, and when a project's results feel inconsistent or Claude keeps rediscovering the same context.","permissions":[],"systemPrompt":"# CLAUDE.md Review\n\nAudit a `CLAUDE.md` against the failure modes that actually cost output quality.\n\n**Premise:** `CLAUDE.md` loads into context on every single session, so every line is either paying rent or costing you tokens on every turn forever. Most \"the model isn't following instructions\" problems are instruction problems.\n\n## Steps\n\n1. Read the target file (default `./CLAUDE.md`; also check `~/.claude/CLAUDE.md` and any nested `**/CLAUDE.md` if the project has them, since the closest one wins).\n2. Score each dimension below and quote the specific lines that fail.\n3. Output the report format at the bottom. Propose concrete rewrites, not \"consider being more specific.\"\n\n## What to check\n\n**Specificity** β the highest-leverage dimension.\n- Flag unfalsifiable directives: \"write clean code\", \"follow best practices\", \"be careful\", \"use good naming\".\n- Every rule should be checkable by reading a diff. `\"Refactor functions over 40 lines\"` is checkable; `\"keep functions short\"` is not.\n\n**Named anchors.**\n- Rules that reference \"the config\", \"our API layer\", or \"the usual pattern\" force rediscovery every session. Replace with real paths: `src/config/env.ts`, `src/api/client.ts`.\n- Verify every path, command, and filename mentioned still exists. Report the dead ones β a `CLAUDE.md` pointing at a deleted file actively misleads.\n\n**Staleness.**\n- Version numbers, model names, and tool commands that no longer match the repo.\n- Instructions for a framework, script, or directory that's since been removed.\n- Cross-check build/test/lint commands against `package.json`, `Makefile`, `pyproject.toml`, or equivalent β a wrong test command is worse than none.\n\n**Bloat and rent.**\n- Anything derivable from the code itself (file tree listings, dependency lists, restating what a function does). Claude can read the repo.\n- Long procedures that only apply to one occasional task: those belong in a skill, whose body loads only when used, rather than in context on every turn.\n- Generic advice that applies to all software everywhere and therefore teaches nothing about *this* project.\n\n**Conflicts.**\n- Rules that contradict each other, or contradict what the code actually does. Flag both sides and ask which wins.\n- Precedence surprises: a nested `CLAUDE.md` or `~/.claude/CLAUDE.md` overriding what the author expects.\n\n**What's missing.** The gaps worth calling out, if absent:\n- How to run tests, build, and lint β the three things needed to self-verify a change.\n- Non-obvious project constraints (a directory that must not be touched, a generated file, a required migration step).\n- Conventions that are genuinely surprising and not visible from a quick read of the code.\n\n## Output format\n\n```\n## CLAUDE.md review β ( lines)\n\n**Verdict:** \n\n### Blocking\n- L: β \n\n### Worth fixing\n- L: β \n\n### Delete (costs context on every session, earns nothing)\n- Lβ: \n\n### Missing\n- β \n\n**Estimated size after edits:** lines (from )\n```\n\n## Rules\n\n- Quote real line numbers and real text. Never invent a finding to fill a section.\n- If a section has no findings, write `None.` β a clean file is a valid result.\n- Prefer deleting to rewriting. The best `CLAUDE.md` is short enough that people actually read it.\n- Do not edit the file unless asked. Report first.","schemaVersion":1},"repoUrl":"https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/tree/main/.claude/skills/claude-md-review","tags":["agent-skills","agentic-coding","ai-agents","anthropic","anthropic-claude","best-practices","claude","claude-ai","claude-code","claude-code-guide","claude-code-hooks","claude-code-skills"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Code-Everything-You-Need-to-Know","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T11:51:58.064Z","lockfiles":[]},"forks":352,"owner":"wesammustafa","stars":3046,"topics":["agent-skills","agentic-coding","ai-agents","anthropic","anthropic-claude","best-practices","claude","claude-ai","claude-code","claude-code-guide","claude-code-hooks","claude-code-skills","claude-code-tutorial","claude-skills","guide","mcp","mcp-servers","prompt-engineering","subagents","tutorial"],"license":"MIT","fullName":"wesammustafa/Claude-Code-Everything-You-Need-to-Know","homepage":null,"language":"Python","pushedAt":"2026-07-28T11:00:38Z","avatarUrl":"https://avatars.githubusercontent.com/u/33235742?v=4","crawledAt":"2026-09-25T11:51:57.607Z","openIssues":13,"manifestFile":"SKILL.md","manifestPath":".claude/skills/claude-md-review/SKILL.md","defaultBranch":"main"},"readme":"# CLAUDE.md Review\n\nAudit a `CLAUDE.md` against the failure modes that actually cost output quality.\n\n**Premise:** `CLAUDE.md` loads into context on every single session, so every line is either paying rent or costing you tokens on every turn forever. Most \"the model isn't following instructions\" problems are instruction problems.\n\n## Steps\n\n1. Read the target file (default `./CLAUDE.md`; also check `~/.claude/CLAUDE.md` and any nested `**/CLAUDE.md` if the project has them, since the closest one wins).\n2. Score each dimension below and quote the specific lines that fail.\n3. Output the report format at the bottom. Propose concrete rewrites, not \"consider being more specific.\"\n\n## What to check\n\n**Specificity** β the highest-leverage dimension.\n- Flag unfalsifiable directives: \"write clean code\", \"follow best practices\", \"be careful\", \"use good naming\".\n- Every rule should be checkable by reading a diff. `\"Refactor functions over 40 lines\"` is checkable; `\"keep functions short\"` is not.\n\n**Named anchors.**\n- Rules that reference \"the config\", \"our API layer\", or \"the usual pattern\" force rediscovery every session. Replace with real paths: `src/config/env.ts`, `src/api/client.ts`.\n- Verify every path, command, and filename mentioned still exists. Report the dead ones β a `CLAUDE.md` pointing at a deleted file actively misleads.\n\n**Staleness.**\n- Version numbers, model names, and tool commands that no longer match the repo.\n- Instructions for a framework, script, or directory that's since been removed.\n- Cross-check build/test/lint commands against `package.json`, `Makefile`, `pyproject.toml`, or equivalent β a wrong test command is worse than none.\n\n**Bloat and rent.**\n- Anything derivable from the code itself (file tree listings, dependency lists, restating what a function does). Claude can read the repo.\n- Long procedures that only apply to one occasional task: those belong in a skill, whose body loads only when used, rather than in context on every turn.\n- Generic advice that applies to all software everywhere and therefore teaches nothing about *this* project.\n\n**Conflicts.**\n- Rules that contradict each other, or contradict what the code actually does. Flag both sides and ask which wins.\n- Precedence surprises: a nested `CLAUDE.md` or `~/.claude/CLAUDE.md` overriding what the author expects.\n\n**What's missing.** The gaps worth calling out, if absent:\n- How to run tests, build, and lint β the three things needed to self-verify a change.\n- Non-obvious project constraints (a directory that must not be touched, a generated file, a required migration step).\n- Conventions that are genuinely surprising and not visible from a quick read of the code.\n\n## Output format\n\n```\n## CLAUDE.md review β ( lines)\n\n**Verdict:** \n\n### Blocking\n- L: β \n\n### Worth fixing\n- L: β \n\n### Delete (costs context on every session, earns nothing)\n- Lβ: \n\n### Missing\n- β \n\n**Estimated size after edits:** lines (from )\n```\n\n## Rules\n\n- Quote real line numbers and real text. Never invent a finding to fill a section.\n- If a section has no findings, write `None.` β a clean file is a valid result.\n- Prefer deleting to rewriting. The best `CLAUDE.md` is short enough that people actually read it.\n- Do not edit the file unless asked. Report first.","createdAt":"2026-09-25T11:51:58.073Z","updatedAt":"2026-09-25T11:51:58.073Z"},{"id":"cmuh0s8l603pmqu06wam7p6p6","slug":"borghei-claude-skills-contract-and-proposal-writer","name":"contract-and-proposal-writer","description":"Generate business documents β contracts, proposals, SOWs, NDAs, MSAs β with jurisdiction-aware clauses for US, EU, UK, and DACH. Use when starting client engagements, writing proposals, drafting agreements, or needing GDPR-compliant DPAs.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"contract-and-proposal-writer","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Generate business documents β contracts, proposals, SOWs, NDAs, MSAs β with jurisdiction-aware clauses for US, EU, UK, and DACH. Use when starting client engagements, writing proposals, drafting agreements, or needing GDPR-compliant DPAs.","permissions":[],"systemPrompt":"# Contract & Proposal Writer\n\n**Tier:** POWERFUL\n**Category:** Business Growth\n**Tags:** contracts, proposals, SOW, NDA, MSA, GDPR, legal templates, freelance\n\n## Overview\n\nGenerate professional, jurisdiction-aware business documents: freelance contracts, project proposals, statements of work, NDAs, and master service agreements. Outputs structured Markdown with conversion instructions for DOCX and PDF. Covers US (Delaware), EU (GDPR), UK, and DACH (German law) jurisdictions with clause libraries for each.\n\n**This is not a substitute for legal counsel.** Use these templates as strong starting points. Review with an attorney for engagements over $50K or involving complex IP, equity, or regulatory requirements.\n\n---\n\n## Core Capabilities\n\n- Fixed-price and hourly development contracts\n- Monthly consulting retainer agreements\n- Project proposals with timeline and budget breakdown\n- Statements of Work (SOW) with deliverables matrix and acceptance criteria\n- NDAs (mutual and one-way)\n- Master Service Agreements (MSA) with SOW attachment framework\n- SaaS partnership agreements (reseller, referral, white-label, integration)\n- GDPR Data Processing Addenda (Art. 28) for EU/DACH\n- Jurisdiction-specific clause library (US, EU, UK, DACH)\n- Change order and scope management clauses\n\n---\n\n## Clarify First\n\nBefore drafting the document, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Document type** β contract, proposal, SOW, NDA, or MSA (selects the template and required clauses)\n- [ ] **Jurisdiction** β US-Delaware, EU, UK, or DACH (drives IP, liability, and governing-law clauses; DACH needs Nutzungsrechte, EU needs a DPA)\n- [ ] **Engagement model + value** β fixed-price, hourly, retainer, or revenue-share and total value (drives payment terms and liability cap)\n- [ ] **Personal data involved** β triggers a mandatory GDPR Art. 28 DPA for EU/DACH engagements\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the document.\n\n## Workflow\n\n### Step 1: Requirements Gathering\n\nGather before drafting:\n\n| Question | Why It Matters |\n|----------|---------------|\n| Document type? | Contract, proposal, SOW, NDA, MSA |\n| Jurisdiction? | US-Delaware, EU, UK, DACH |\n| Engagement model? | Fixed-price, hourly, retainer, revenue-share |\n| Parties? | Legal names, roles, registered addresses |\n| Scope summary? | 1-3 sentences describing the work |\n| Total value or rate? | Drives payment terms and liability caps |\n| Timeline? | Start date, end date or duration, milestones |\n| Special requirements? | IP assignment, white-label, subcontractors, non-compete |\n| Personal data involved? | Triggers GDPR DPA requirement in EU/DACH |\n\n### Step 2: Template Selection\n\n| Document Type | Engagement Model | Template |\n|--------------|-----------------|----------|\n| Dev contract | Fixed-price | Template A: Fixed-Price Development |\n| Dev contract | Hourly/Retainer | Template B: Consulting Retainer |\n| Partnership | Revenue-share | Template C: SaaS Partnership |\n| NDA | Mutual | Template NDA-M |\n| NDA | One-way (discloser/recipient) | Template NDA-OW |\n| SOW | Any | Template SOW (attaches to MSA or standalone) |\n| Proposal | Any | Template P: Project Proposal |\n\n### Step 3: Generate & Fill\n\nFill all `[BRACKETED]` placeholders. Flag missing information as `[REQUIRED - description]`. Never leave blanks -- an incomplete contract is more dangerous than no contract.\n\n### Step 4: Review Checklist\n\nBefore sending any generated document:\n\n- [ ] All `[BRACKETED]` placeholders filled\n- [ ] Correct jurisdiction selected and consistent throughout\n- [ ] Payment terms match engagement model\n- [ ] IP clause matches jurisdiction requirements\n- [ ] Liability cap is reasonable (typically 1x-3x contract value)\n- [ ] Termination clauses include both for-cause and for-convenience\n- [ ] DPA included if personal data is processed (EU/DACH mandatory)\n- [ ] Force majeure clause included for engagements over 3 months\n- [ ] Change order process defined for fixed-price contracts\n- [ ] Acceptance criteria defined for each deliverable\n\n---\n\n## Clause Library\n\n### Payment Terms\n\n| Model | Standard Terms | Risk Notes |\n|-------|---------------|------------|\n| Fixed-price | 50% upfront, 25% at beta, 25% at acceptance | Best for defined scope |\n| Hourly | Net-30, monthly invoicing | Requires time tracking |\n| Retainer | Monthly prepaid, 1st of month | Include overflow rate |\n| Milestone | Per-milestone invoicing | Define milestones precisely |\n| Revenue-share | Net-30 after month close, minimum threshold | Requires audit rights |\n\n**Late payment:** 1.5% per month (US standard), up to statutory maximum in EU/DACH.\n\n### Intellectual Property\n\n| Jurisdiction | Default IP Ownership | Key Requirement |\n|-------------|---------------------|-----------------|\n| US (Delaware) | Work-for-hire doctrine | Must be in writing, 9 qualifying categories |\n| EU | Author retains moral rights | Separate written assignment needed |\n| UK | Employer owns (if employee) | Contractor: explicit assignment required |\n| DACH (Germany) | Author retains Urheberrecht permanently | Must transfer Nutzungsrechte (usage rights) explicitly |\n\n**Pre-existing IP:** Always carve out pre-existing tools, libraries, and frameworks. Grant client a perpetual, royalty-free license to use pre-existing IP as embedded in deliverables.\n\n**Portfolio rights:** Developer retains right to display work in portfolio unless client requests confidentiality in writing within 30 days.\n\n### Liability\n\n| Risk Level | Cap | When to Use |\n|-----------|-----|-------------|\n| Standard | 1x total fees paid | Most projects |\n| High-risk | 3x total fees paid | Critical infrastructure, regulated industries |\n| Uncapped (mutual) | No cap, mutual indemnification | Enterprise partnerships |\n\n**Always exclude:** Indirect, incidental, and consequential damages (both parties).\n\n### Termination\n\n| Type | Notice Period | Financial Treatment |\n|------|-------------|-------------------|\n| For cause | 14-day cure period | Pay for work completed |\n| For convenience (client) | 30 days written notice | Pay for work completed + 10-20% of remaining value |\n| For convenience (either) | 30-60 days | Pay for work completed |\n| Immediate (material breach uncured) | 7 days post-notice | Pro-rata payment |\n\n### Confidentiality\n\n- Standard term: 3 years post-termination\n- Trade secrets: Perpetual (as long as information remains a trade secret)\n- Return/destruction: All confidential materials returned or certified destroyed within 30 days of termination\n- Exceptions: Publicly known, independently developed, received from third party, required by law\n\n### Dispute Resolution\n\n| Jurisdiction | Recommended Forum | Rules |\n|-------------|-------------------|-------|\n| US | Binding arbitration | AAA Commercial Rules, Delaware venue |\n| EU | ICC arbitration or local courts | ICC Rules, venue in capital of governing law |\n| UK | LCIA arbitration, London | LCIA Rules, English law |\n| DACH | DIS arbitration or Landgericht | DIS Rules, German law |\n\n---\n\n## Jurisdiction-Specific Requirements\n\n### US (Delaware)\n- Governing law: State of Delaware (most business-friendly)\n- Work-for-hire doctrine applies (Copyright Act 101)\n- Non-compete: Enforceable with reasonable scope/duration/geography\n- Electronic signatures: Valid under ESIGN Act and UETA\n\n### EU (GDPR)\n- Data Processing Addendum required if handling personal data\n- IP assignment may require separate written deed in some member states\n- Consumer protection laws may override contract terms for B2C\n- Right to withdraw within 14 days for distance contracts (B2C)\n\n### UK (Post-Brexit)\n- Governed by English law (most common choice)\n- IP: Patents Act 1977, CDPA 1988\n- UK GDPR (post-Brexit equivalent) applies for data processing\n- Electronic signatures: Valid under Electronic Communications Act 2000\n\n### DACH (Germany / Austria / Switzerland)\n- BGB (Buergerliches Gesetzbuch) governs contracts\n- Schriftform (written form) required for certain clauses (para 126 BGB)\n- Author always retains moral rights (Urheberpersoernlichkeitsrecht) -- cannot be transferred\n- Must explicitly transfer Nutzungsrechte (usage rights) with scope and duration\n- Non-competes: Maximum 2 years, compensation required (para 74 HGB)\n- DSGVO (German GDPR implementation) mandatory for personal data\n- Kuendigungsfristen: Statutory notice periods apply and cannot be shortened below minimum\n\n---\n\n## GDPR Data Processing Addendum (Template Block)\n\nRequired for any EU/DACH engagement involving personal data:\n\n```markdown\n## DATA PROCESSING ADDENDUM (Art. 28 GDPR/DSGVO)\n\nController: [CLIENT LEGAL NAME]\nProcessor: [SERVICE PROVIDER LEGAL NAME]\n\n### Processing Scope\nProcessor processes personal data solely to perform services under the Agreement.\n\n### Categories of Data Subjects\n[End users / Employees / Customers of Controller]\n\n### Categories of Personal Data\n[Names, email addresses, usage data, IP addresses, payment information]\n\n### Processing Duration\nTerm of the Agreement. Deletion within [30] days of termination.\n\n### Processor Obligations\n1. Process only on Controller's documented instructions\n2. Ensure authorized persons committed to confidentiality\n3. Implement Art. 32 technical and organizational measures\n4. Assist with data subject rights requests within [10] business days\n5. Notify Controller of personal data breach within [72] hours\n6. No sub-processors without prior written consent\n7. Delete or return all personal data upon termination\n8. Make available information to demonstrate compliance\n\n### Current Sub-Processors\n| Sub-Processor | Location | Purpose |\n|--------------|----------|---------|\n| [AWS/GCP/Azure] | [Region] | Cloud infrastructure |\n| [Stripe] | [US/EU] | Payment processing |\n\n### Cross-Border Transfers\nTransfers outside EEA: [ ] Standard Contractual Clauses [ ] Adequacy Decision [ ] BCRs\n```\n\n---\n\n## Project Proposal Template (Template P)\n\n```markdown\n# PROJECT PROPOSAL\n\n**Prepared for:** [Client Name]\n**Prepared by:** [Your Name / Company]\n**Date:** [Date]\n**Valid until:** [Date + 30 days]\n\n---\n\n## Executive Summary\n[2-3 sentences: what you will build, the business problem it solves, and the expected outcome]\n\n## Understanding of Requirements\n[Demonstrate you understand the client's problem. Reference their specific situation, not generic boilerplate]\n\n## Proposed Solution\n[Technical approach, architecture overview, technology choices with rationale]\n\n## Scope of Work\n\n### In Scope\n- [Deliverable 1: specific description]\n- [Deliverable 2: specific description]\n- [Deliverable 3: specific description]\n\n### Out of Scope\n- [Explicitly list what is NOT included -- prevents scope creep]\n\n### Assumptions\n- [Client provides X by Y date]\n- [Access to Z system will be available]\n\n## Timeline\n\n| Phase | Deliverables | Duration | Dates |\n|-------|-------------|----------|-------|\n| Discovery | Requirements document, architecture plan | 1 week | [Dates] |\n| Development | Core features, API integration | 4 weeks | [Dates] |\n| Testing | QA, UAT, bug fixes | 1 week | [Dates] |\n| Launch | Deployment, monitoring, handoff | 1 week | [Dates] |\n\n## Investment\n\n| Item | Cost |\n|------|------|\n| Discovery & Planning | [Amount] |\n| Development | [Amount] |\n| Testing & QA | [Amount] |\n| Project Management | [Amount] |\n| **Total** | **[Amount]** |\n\n### Payment Schedule\n- 50% upon contract signing\n- 25% at beta delivery\n- 25% upon final acceptance\n\n## Why Us\n[2-3 concrete differentiators. Reference relevant experience, not just claims]\n\n## Next Steps\n1. Review and approve this proposal\n2. Sign agreement (attached)\n3. Kick-off meeting within [5] business days\n```\n\n---\n\n## Document Conversion\n\n```bash\n# Markdown to DOCX (basic)\npandoc contract.md -o contract.docx --reference-doc=template.docx\n\n# With numbered sections (legal style)\npandoc contract.md -o contract.docx --number-sections -V fontsize=11pt\n\n# Markdown to PDF (via LaTeX)\npandoc contract.md -o contract.pdf -V geometry:margin=1in -V fontsize=11pt\n\n# Batch convert all contracts\nfor f in contracts/*.md; do\n pandoc \"$f\" -o \"${f%.md}.docx\" --reference-doc=template.docx\ndone\n```\n\n---\n\n## Common Pitfalls\n\n| Pitfall | Consequence | Prevention |\n|---------|-------------|------------|\n| Missing IP assignment language | Unclear ownership, disputes | Always include explicit IP clause per jurisdiction |\n| Vague acceptance criteria | Endless revision cycles | Define \"accepted\" = written sign-off within X days |\n| No change order process | Scope creep on fixed-price | Include change order clause with pricing mechanism |\n| Jurisdiction mismatch | Unenforceable clauses | Match governing law to where parties operate |\n| Missing liability cap | Unlimited exposure | Always cap liability at 1-3x contract value |\n| Oral amendments | Unenforceable modifications | Require written amendments signed by both parties |\n| No DPA for EU data | GDPR violation, up to 4% global revenue fine | Always include DPA when processing EU personal data |\n| Missing force majeure | No protection against unforeseeable events | Include for engagements over 3 months |\n\n---\n\n## Best Practices\n\n1. Use milestone payments over net-30 for projects over $10K -- reduces cash flow risk for both parties\n2. Always include a change order clause in fixed-price contracts\n3. For DACH: include Schriftformklausel (written form clause) explicitly\n4. Define response time SLAs in retainer agreements (e.g., 4h urgent / 24h normal)\n5. Keep templates in version control; review annually as laws change\n6. For NDAs: always specify return/destruction of confidential materials on termination\n7. Include a survival clause -- specify which clauses survive termination (confidentiality, IP, liability)\n8. For EU/DACH: check if consumer protection laws apply (B2C engagements have additional requirements)\n\n---\n\n## Related Skills\n\n| Skill | Use When |\n|-------|----------|\n| **ceo-advisor** | Strategic decisions about partnerships and business models |\n| **cfo-advisor** | Financial terms, pricing strategy, revenue recognition |\n| **launch-strategy** | Contract timing around product launches |\n\n---\n\n## Tool Reference\n\n### 1. contract_clause_checker.py\n\n**Purpose:** Validate a contract document (as structured JSON) against required clauses for a given jurisdiction and engagement type.\n\n```bash\npython scripts/contract_clause_checker.py contract.json --jurisdiction us-delaware\npython scripts/contract_clause_checker.py contract.json --jurisdiction eu --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `contract.json` | Yes | JSON file with contract clauses and metadata |\n| `--jurisdiction` | No | Jurisdiction to check against: us-delaware, eu, uk, dach (default: us-delaware) |\n| `--type` | No | Contract type: fixed-price, hourly, retainer, nda, msa (default: fixed-price) |\n| `--json` | No | Output results as JSON |\n\n### 2. proposal_cost_estimator.py\n\n**Purpose:** Generate a project cost estimate with phase breakdown, payment schedule, and margin analysis.\n\n```bash\npython scripts/proposal_cost_estimator.py --hourly-rate 150 --hours 200 --phases 4\npython scripts/proposal_cost_estimator.py --hourly-rate 150 --hours 200 --phases 4 --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `--hourly-rate` | Yes | Hourly rate in dollars |\n| `--hours` | Yes | Estimated total hours |\n| `--phases` | No | Number of project phases (default: 3) |\n| `--margin` | No | Desired profit margin percentage (default: 20) |\n| `--currency` | No | Currency code (default: USD) |\n| `--json` | No | Output results as JSON |\n\n### 3. contract_comparison_analyzer.py\n\n**Purpose:** Compare two contract versions and identify differences in key clauses, payment terms, and risk areas.\n\n```bash\npython scripts/contract_comparison_analyzer.py contract_v1.json contract_v2.json\npython scripts/contract_comparison_analyzer.py contract_v1.json contract_v2.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `contract_v1.json` | Yes | JSON file with first contract version |\n| `contract_v2.json` | Yes | JSON file with second contract version |\n| `--json` | No | Output results as JSON |\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Solution |\n|---------|-------------|----------|\n| Placeholders left in final document | Rushed filling process | Use contract_clause_checker.py to scan for unfilled [BRACKETED] placeholders before sending |\n| IP clause is unenforceable in EU/DACH | Using US work-for-hire language in EU context | Switch to explicit Nutzungsrechte transfer for DACH; use separate written assignment deed for EU |\n| Client disputes scope after signing | Vague acceptance criteria or missing change order process | Define \"accepted\" = written sign-off within X business days; include change order clause with pricing mechanism |\n| Payment disputes on hourly contracts | No time tracking requirement or unclear invoicing terms | Specify time tracking tool, invoicing frequency (monthly), and payment terms (net-30) in the contract |\n| GDPR non-compliance penalty risk | Missing DPA for EU/DACH engagements involving personal data | Always include Art. 28 DPA when processing EU personal data; use the template block in this skill |\n| Contract fails legal review | Jurisdiction mismatch or missing mandatory clauses | Run contract_clause_checker.py against the target jurisdiction before legal review |\n\n---\n\n## Success Criteria\n\n- All [BRACKETED] placeholders filled before document delivery\n- Correct jurisdiction selected and consistent throughout (verified by contract_clause_checker.py)\n- Payment terms match engagement model with clear invoicing cadence\n- IP clause matches jurisdiction requirements (work-for-hire for US, Nutzungsrechte for DACH)\n- Liability cap set at 1-3x contract value with consequential damages excluded\n- DPA included for all EU/DACH engagements involving personal data\n- Change order process defined for all fixed-price contracts\n\n---\n\n## Scope & Limitations\n\n- **In scope:** Contract templates, proposal generation, clause libraries, jurisdiction-specific compliance, document comparison, cost estimation\n- **Out of scope:** Legal advice, contract negotiation strategy, litigation support, regulatory filings\n- **Not legal counsel:** These templates are starting points; review with an attorney for engagements over $50K or involving complex IP, equity, or regulatory requirements\n- **Jurisdiction coverage:** US (Delaware), EU (general), UK, DACH (Germany/Austria/Switzerland); other jurisdictions may require additional legal review\n- **Currency:** Cost estimator defaults to USD; adjust for local currency in international engagements\n\n---\n\n## Integration Points\n\n- **ceo-advisor** -- Strategic decisions about partnership structures and business models that drive contract type selection\n- **cfo-advisor** -- Financial terms, revenue recognition, and pricing strategy that inform payment schedule and margin targets\n- **customer-success-manager** -- SOW and MSA structures for customer engagements; renewal terms feed into CS workflows\n- **pricing-strategy** -- When proposal pricing needs strategic positioning against competitors or market rates\n- **revenue-operations** -- Contract values and payment schedules feed into pipeline forecasting and revenue recognition","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/contract-and-proposal-writer","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/contract-and-proposal-writer/SKILL.md","defaultBranch":"main"},"readme":"# Contract & Proposal Writer\n\n**Tier:** POWERFUL\n**Category:** Business Growth\n**Tags:** contracts, proposals, SOW, NDA, MSA, GDPR, legal templates, freelance\n\n## Overview\n\nGenerate professional, jurisdiction-aware business documents: freelance contracts, project proposals, statements of work, NDAs, and master service agreements. Outputs structured Markdown with conversion instructions for DOCX and PDF. Covers US (Delaware), EU (GDPR), UK, and DACH (German law) jurisdictions with clause libraries for each.\n\n**This is not a substitute for legal counsel.** Use these templates as strong starting points. Review with an attorney for engagements over $50K or involving complex IP, equity, or regulatory requirements.\n\n---\n\n## Core Capabilities\n\n- Fixed-price and hourly development contracts\n- Monthly consulting retainer agreements\n- Project proposals with timeline and budget breakdown\n- Statements of Work (SOW) with deliverables matrix and acceptance criteria\n- NDAs (mutual and one-way)\n- Master Service Agreements (MSA) with SOW attachment framework\n- SaaS partnership agreements (reseller, referral, white-label, integration)\n- GDPR Data Processing Addenda (Art. 28) for EU/DACH\n- Jurisdiction-specific clause library (US, EU, UK, DACH)\n- Change order and scope management clauses\n\n---\n\n## Clarify First\n\nBefore drafting the document, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Document type** β contract, proposal, SOW, NDA, or MSA (selects the template and required clauses)\n- [ ] **Jurisdiction** β US-Delaware, EU, UK, or DACH (drives IP, liability, and governing-law clauses; DACH needs Nutzungsrechte, EU needs a DPA)\n- [ ] **Engagement model + value** β fixed-price, hourly, retainer, or revenue-share and total value (drives payment terms and liability cap)\n- [ ] **Personal data involved** β triggers a mandatory GDPR Art. 28 DPA for EU/DACH engagements\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the document.\n\n## Workflow\n\n### Step 1: Requirements Gathering\n\nGather before drafting:\n\n| Question | Why It Matters |\n|----------|---------------|\n| Document type? | Contract, proposal, SOW, NDA, MSA |\n| Jurisdiction? | US-Delaware, EU, UK, DACH |\n| Engagement model? | Fixed-price, hourly, retainer, revenue-share |\n| Parties? | Legal names, roles, registered addresses |\n| Scope summary? | 1-3 sentences describing the work |\n| Total value or rate? | Drives payment terms and liability caps |\n| Timeline? | Start date, end date or duration, milestones |\n| Special requirements? | IP assignment, white-label, subcontractors, non-compete |\n| Personal data involved? | Triggers GDPR DPA requirement in EU/DACH |\n\n### Step 2: Template Selection\n\n| Document Type | Engagement Model | Template |\n|--------------|-----------------|----------|\n| Dev contract | Fixed-price | Template A: Fixed-Price Development |\n| Dev contract | Hourly/Retainer | Template B: Consulting Retainer |\n| Partnership | Revenue-share | Template C: SaaS Partnership |\n| NDA | Mutual | Template NDA-M |\n| NDA | One-way (discloser/recipient) | Template NDA-OW |\n| SOW | Any | Template SOW (attaches to MSA or standalone) |\n| Proposal | Any | Template P: Project Proposal |\n\n### Step 3: Generate & Fill\n\nFill all `[BRACKETED]` placeholders. Flag missing information as `[REQUIRED - description]`. Never leave blanks -- an incomplete contract is more dangerous than no contract.\n\n### Step 4: Review Checklist\n\nBefore sending any generated document:\n\n- [ ] All `[BRACKETED]` placeholders filled\n- [ ] Correct jurisdiction selected and consistent throughout\n- [ ] Payment terms match engagement model\n- [ ] IP clause matches jurisdiction requirements\n- [ ] Liability cap is reasonable (typically 1x-3x contract value)\n- [ ] Termination clauses include both for-cause and for-convenience\n- [ ] DPA included if personal data is processed (EU/DACH mandatory)\n- [ ] Force majeure clause in","createdAt":"2026-09-25T13:52:02.682Z","updatedAt":"2026-09-25T13:52:02.682Z"},{"id":"cmuh0s8m303q1qu06dge1rsr9","slug":"borghei-claude-skills-deal-desk","name":"deal-desk","description":"Deal desk: reviews, approves, and structures non-standard sales deals. Use when standing up a deal desk, building approval-threshold matrices, designing deal-review packets, routing deals, or auditing deals for compliance.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"deal-desk","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Deal desk: reviews, approves, and structures non-standard sales deals. Use when standing up a deal desk, building approval-threshold matrices, designing deal-review packets, routing deals, or auditing deals for compliance.","permissions":[],"systemPrompt":"# Deal Desk\n\nEnd-to-end deal-desk operational practice: charter, approval thresholds, deal-review packet design, routing automation, velocity analysis, and the governance that turns \"every deal is a snowflake\" into \"we close non-standard deals in 48 hours predictably.\"\n\nThis skill is provider-agnostic: works whether your CRM is Salesforce, HubSpot, Pipedrive, or homegrown. The patterns and decisions transfer.\n\n---\n\n## When to use this skill\n\n| Situation | Skill applies |\n|-----------|---------------|\n| Starting a deal-desk function from scratch | Yes β start with **charter design** |\n| Reviewing existing deal-desk for slowness / inconsistency | Yes β use `scripts/deal_velocity_analyzer.py` + **bottleneck patterns** |\n| Defining who can approve what discount / term | Yes β use **approval threshold matrix** + `scripts/discount_authority_router.py` |\n| Building the deal-review packet template | Yes β see **deal-review packet** section + `scripts/deal_review_packet.py` |\n| Approving / declining a specific deal | Use the packet generator + approval router |\n| Setting pricing strategy | Use `business-growth/pricing-strategy` first |\n| Forecasting / measuring pipeline | Use `business-growth/revenue-operations` |\n| Negotiating an individual contract | Pair with `business-growth/contract-and-proposal-writer` |\n\n---\n\n## What deal desk does (and doesn't)\n\n**Does:**\n- Review non-standard deals: discounts beyond rep authority, custom legal terms, custom SLAs, multi-product bundles, payment terms outside policy\n- Make the approval decision (or route to the right approver)\n- Structure the deal: pricing, terms, ramp schedule, success criteria\n- Maintain the deal-desk **policy** β what's standard, what needs approval\n- Track deal velocity (time from request β decision β signature)\n- Produce evidence for finance / audit (every concession traceable)\n\n**Doesn't:**\n- Set the published pricing (that's pricing strategy)\n- Negotiate with the customer (that's the sales rep / AE)\n- Close the sale (that's the rep + customer success)\n- Run the order-to-cash workflow (that's billing / RevOps)\n- Replace legal review (legal is one of the approvers, not the function itself)\n\nA clean deal-desk = the lubricant. Without it, every non-standard deal turns into a multi-week negotiation among engineering / product / legal / finance / executive. With it, those people are consulted by deal desk as needed and the rep gets a yes/no in days.\n\n---\n\n## Deal-desk charter (template)\n\nEvery deal desk needs a written charter. Use this template:\n\n```yaml\npurpose:\n Deal Desk reviews, approves, and structures non-standard deals to enable\n sales to close faster while keeping commercial / legal / financial risk\n within company tolerance.\n\nscope:\n In-scope:\n - All deals > $X ARR\n - All deals with discount > Y%\n - All deals with non-standard terms (custom SLAs, custom legal language,\n payment terms beyond Net 30, ramp deals, multi-year discounts > 12 months\n of standard, bundles spanning multiple product lines)\n - All renewals with > 20% expansion or > 10% contraction\n - All deals to enterprise (>1000 employees) or regulated industries\n Out-of-scope:\n - Self-serve / PLG transactions\n - Standard renewals within auto-renewal terms\n - Trial extensions < 30 days\n - Add-ons < $X per existing customer\n\nsla:\n - Standard deal-desk review (no exec approval needed): 1 business day\n - Deal needing CFO/CRO approval: 2 business days\n - Deal needing CEO/Board approval: 5 business days\n - Legal-only review (no commercial concession): 2 business days\n\nintake_format:\n Sales submits via [Salesforce form / CPQ tool / Slack form]. Required fields:\n - Customer name + size + industry\n - Product(s) + ACV\n - Requested deviation from standard (specific list)\n - Justification (competitor situation, customer constraint, strategic value)\n - Standard-pricing total + requested total\n - Contract length + payment terms\n - Implementation / SLA requirements\n\ndecision_inputs:\n - Customer LTV estimate\n - Strategic value (logo, reference, vertical foothold)\n - Risk (credit, compliance, integration)\n - Margin impact\n\noutputs:\n - Approve / decline / counter\n - If approve: signed approval packet with terms, conditions, expiration date\n - If counter: list of negotiable items + non-negotiables\n - If decline: reasoning + alternatives\n\nteam:\n Deal-desk lead: \n Deal-desk analysts: \n Standing approvers: CRO, CFO, General Counsel, VP Product (escalation paths)\n Consulted as-needed: Engineering Lead, Security Lead, Customer Success Lead\n\nmetrics:\n - Median time-to-decision (target: 1 business day)\n - Decision distribution (% approved, % declined, % countered)\n - Discount-on-discount % (deals where requested discount was further negotiated up)\n - Discount % vs ACV (correlation; outliers reviewed monthly)\n - Win rate of deal-desk-approved deals\n - Concession follow-through (did the customer keep their side?)\n```\n\nSee [references/deal-desk-charter-and-process.md](references/deal-desk-charter-and-process.md) for the full charter template, including sub-charters per region, intake form spec, and the standard SLAs.\n\n---\n\n## Approval threshold matrix\n\nThe matrix defines: for each deal characteristic (discount %, contract length, custom term type), who can approve it.\n\n### Standard matrix template\n\n| Deal characteristic | Rep | Sales Manager | Director | VP Sales | CRO | CFO | CEO |\n|---------------------|-----|---------------|----------|----------|-----|-----|-----|\n| Discount 0-10% | β | | | | | | |\n| Discount 10-20% | | β | | | | | |\n| Discount 20-30% | | | β | | | | |\n| Discount 30-40% | | | | β | | | |\n| Discount 40-50% | | | | | β | | |\n| Discount > 50% | | | | | | | β |\n| ACV > $250k | | β | | | | | |\n| ACV > $1M | | | | β | | | |\n| ACV > $5M | | | | | | | β |\n| Multi-year > 12mo standard | | β | | | | | |\n| Non-standard payment terms | | | | | | β | |\n| Custom SLA / penalties | | | | (with CCO) | | | |\n| Custom legal language | | | | | | | (Legal must concur) |\n| MSA red-line on liability cap | | | | | | | (Legal must concur) |\n| Most-favored-nation clause | | | | | | β | |\n| Acceptance criteria / payment-on-acceptance | | | | | | β | |\n| Multi-product / cross-BU bundle | | | (each BU lead approves) | | | | |\n| Whitelabel / OEM rights | | | | | | | β |\n\nCustomize per company stage, ACV distribution, and authority preference (some orgs want CRO at 30%, others delegate further down).\n\n### Stacking rule\n\nWhen multiple non-standard items apply, **the highest required approver applies.** A $1M deal at 25% discount with custom SLA needs VP Sales (ACV) AND Director (discount) AND VP Sales+CCO (custom SLA) β effectively requires VP Sales sign-off + CCO + Legal concurrence.\n\nUse `scripts/discount_authority_router.py --deal deal.yaml` to compute the required approvers for any deal.\n\nSee [references/approval-thresholds-and-routing.md](references/approval-thresholds-and-routing.md) for the full matrix design guide, regional variants, escalation paths, and routing automation patterns.\n\n---\n\n## The deal-review packet\n\nEvery non-standard deal gets a packet. Without it, approvers ask the same questions repeatedly and decisions take days instead of hours.\n\n### Standard packet structure\n\n```markdown\n# Deal Review: \n\n## Summary\n- Customer: \n- ACV: $\n- Discount %: <%> (vs standard $)\n- Contract: , \n- Decision needed by: \n\n## Standard vs Requested\n| Item | Standard | Requested | Delta |\n|------|----------|-----------|-------|\n| ACV | $X | $Y | -Z% |\n| Term | 12mo | 36mo | +24mo |\n| Payment | Net 30 | Net 60 | +30d |\n| SLA | 99.5% | 99.9% | +0.4% |\n| Liability cap | 1x fees | 2x fees | +1x |\n| Termination for convenience | No | Yes (90d) | New |\n\n## Justification\n- Why customer wants this: \n- Why we're considering: \n- Customer leverage: \n\n## Financial impact\n- Standard ARR: $X\n- Discounted ARR: $Y (Z% off)\n- Net new gross margin: $A (with cost overlay)\n- Projected LTV with this discount: $B\n- Discount payback if customer renews: \n\n## Strategic value\n- Logo value: \n- Reference value: \n- Vertical foothold: \n- Competitive replacement: \n\n## Risk\n- Credit risk: \n- Compliance risk: \n- Technical fit risk: \n- Concession follow-through: \n\n## Required approvers (per matrix)\n- [ ] Director: \n- [ ] VP Sales: \n- [ ] CFO: \n- [ ] Legal: \n\n## Recommendation (from deal desk)\n β with reasoning\n\n## Conditions if approved\n- Discount expires \n- Customer must agree to: \n- Customer agrees this is single-instance (not precedent)\n- Payment must close by \n```\n\nUse `scripts/deal_review_packet.py --deal deal.yaml` to generate this packet from a deal spec.\n\n---\n\n## Velocity analysis\n\nA slow deal desk strangles sales. Measure and tune.\n\n### Key metrics\n\n| Metric | Healthy | Warning |\n|--------|---------|---------|\n| Median time-to-decision | < 1 business day | > 3 days |\n| 90th percentile time-to-decision | < 3 business days | > 7 days |\n| % of deals waiting on a single approver > 24h | < 10% | > 30% |\n| Deals stuck > 7 days | 0 | > 5 |\n| Sales rep satisfaction with deal desk (NPS) | > 50 | < 0 |\n| % approved (high approval rate may mean threshold too low) | 60-80% | > 95% or < 40% |\n| Discount-on-discount: deals where customer negotiated up after deal-desk approval | < 10% | > 30% |\n\nRun `scripts/deal_velocity_analyzer.py --deals deals.csv` to compute these from a CRM export.\n\n### Common bottlenecks\n\n| Bottleneck | Diagnosis | Fix |\n|------------|-----------|-----|\n| Single approver bottleneck (one person on everything) | Routing matrix concentrated authority | Delegate; add back-ups; raise thresholds |\n| Legal review takes a week | Legal sees every deal | Standard MSA + pre-approved clause library; Legal only on deviations |\n| Engineering needed for SLA review | Custom SLAs every time | Publish standard SLA tiers; only deviations route to eng |\n| Approval cycle back-and-forth | Packet missing key info | Use the standard packet template; reject incomplete submissions |\n| Long executive lag | Exec doesn't have context for every deal | Weekly deal review meeting for batch decisions on smaller items |\n| Sales submits incomplete packets | Reps don't know what to include | Intake form that enforces required fields |\n| No SLA enforcement | Deals sit in queue with no urgency | Publish + report SLA; aging dashboard visible to leadership |\n\nSee [references/discount-and-concession-playbook.md](references/discount-and-concession-playbook.md) for the discount/concession patterns: legitimate reasons for each concession type, how to evaluate, alternatives to discounting, and how to structure performance-based discounts.\n\n---\n\n## Clarify First\n\nBefore generating the deal-desk artifact, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Task type** β standing up the desk (charter + matrix) vs reviewing one deal (packet) (determines which template you produce)\n- [ ] **Deal specifics: ACV + requested deviation** β discount %, term, payment, custom SLA/legal (sets the Standard-vs-Requested table and which approvers the matrix requires)\n- [ ] **Approval authority structure** β who can approve what (RepβManagerβDirectorβVPβCRO/CFO/CEO + Legal) (drives the threshold matrix and routing)\n- [ ] **Strategic value + risk** β logo/reference value, credit/compliance risk (drives the packet's justification and recommendation)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the artifact.\n\n## End-to-end workflows\n\n### Workflow: A rep submits a non-standard deal\n\n1. **Rep submits** via intake form: customer + ACV + requested deviation + justification\n2. **Deal desk triages** within 4h: assigns analyst, validates packet completeness, requests missing info\n3. **Deal desk reviews** within 1 business day: financial impact, strategic value, risk\n4. **Deal desk recommends** approve / counter / decline\n5. **Route to approver(s)** per matrix (auto via `scripts/discount_authority_router.py`)\n6. **Approver decides** within SLA\n7. **If approved**: packet signed off, conditions sent to rep with expiration\n8. **If countered**: deal desk works with rep on alternative structure\n9. **If declined**: clear reason + alternatives sent to rep + customer\n\n### Workflow: Stand up a deal desk from scratch\n\n1. **Draft charter** with sales, finance, legal sign-off\n2. **Build the approval matrix** β interview key stakeholders, document existing tribal knowledge\n3. **Design intake form** β CRM-integrated or Slack-bot\n4. **Hire / appoint deal desk lead + analyst(s)**\n5. **Train sales** β what triggers deal desk, what info is needed, what to expect\n6. **Soft launch** β manual operation for 1 month; track metrics\n7. **Iterate** β refine thresholds, automate routing, publish SLAs\n8. **Quarterly review** β metrics, threshold adjustments, charter updates\n\n### Workflow: Audit deal-desk performance\n\n1. **Export deals** from CRM for the period (CSV with deal IDs, stages, approval timestamps, discounts)\n2. **Run velocity analyzer** β compute medians, percentiles, aging, approver bottlenecks\n3. **Sample 10-20 deals** for qualitative review (was the packet complete? were conditions met?)\n4. **Identify patterns** β are certain reps over-discounting? are certain customers getting MFN clauses inappropriately?\n5. **Propose adjustments** β to charter, thresholds, intake form, training\n6. **Present to leadership** with metrics + recommendations\n\n### Workflow: Quarterly threshold review\n\nThresholds drift. Quarterly:\n\n1. **Pull discount distribution** for the quarter\n2. **Identify outliers** β deals where discount % was anomalous for ACV / segment\n3. **Compare approval rates** by threshold β if 30%+ discount deals get approved 95%+ of the time, the threshold is too low\n4. **Compare win rates** by discount band β does deeper discount actually improve win rate, or does it just give up margin?\n5. **Adjust thresholds** based on data + market shift\n6. **Publish new matrix** with effective date; train sales\n\n---\n\n## Anti-patterns\n\n- **Deal desk as bottleneck.** SLAs published but ignored; deals stack up; sales builds workarounds. Measure + enforce SLAs.\n- **Deal desk that always says yes.** Approval rate > 95% means thresholds are too low β you're rubber-stamping. Tighten or raise thresholds.\n- **Deal desk that always says no.** Approval rate < 40% means policy is too strict OR sales doesn't understand it. Investigate root cause.\n- **No deal-desk policy.** Every deal evaluated case-by-case. Inconsistent decisions; legal exposure; reps gaming the system.\n- **Concentrated authority.** One person approves everything β bottleneck + bus factor. Delegate.\n- **Pricing strategy disguised as deal-desk policy.** If 80% of deals need discounting, the published price is wrong. Fix pricing.\n- **Discount creep.** Each deal raises the bar for the next; eventually published price is irrelevant. Track + reset.\n- **Concession with no quid pro quo.** Customer asks for 20% discount; you give 20% discount. Always trade: 20% for case study, 20% for 3yr contract, etc.\n- **No expiration on quotes.** Customer can come back in 6 months and demand the same terms. Always time-box (typically 30-60 days).\n- **Single-instance language never enforced.** \"This is a one-time exception\" β next year the customer cites it as precedent.\n\n---\n\n## Tooling outputs\n\n| Script | Input | Output |\n|--------|-------|--------|\n| `scripts/deal_review_packet.py` | Deal spec YAML | Markdown deal-review packet with summary, financials, strategic value, risk, approver list, recommendation template |\n| `scripts/discount_authority_router.py` | Deal spec YAML + approval matrix YAML | Required approver(s), routing order, escalation path, SLA-aware ordering |\n| `scripts/deal_velocity_analyzer.py` | CSV of deals from CRM export | Median / p90 time-to-decision, aging dashboard, approver bottleneck identification, discount-on-discount analysis |\n\nAll scripts: stdlib only, argparse CLI, JSON or markdown output.\n\n---\n\n## References\n\n- [deal-desk-charter-and-process.md](references/deal-desk-charter-and-process.md) β full charter template, intake form spec, SLA framework\n- [approval-thresholds-and-routing.md](references/approval-thresholds-and-routing.md) β matrix design, regional variants, escalation paths, automation patterns\n- [discount-and-concession-playbook.md](references/discount-and-concession-playbook.md) β concession types, legitimate reasons, alternatives, performance-based structures\n\n---\n\n## Related skills\n\n- `business-growth/pricing-strategy` β sets the prices that deal desk enforces deviations from\n- `business-growth/revenue-operations` β measures the pipeline; deal-desk metrics flow into RevOps dashboards\n- `business-growth/contract-and-proposal-writer` β drafts the final contract once deal desk approves\n- `business-growth/channel-economics` β channel deals have their own deal-desk patterns\n- `business-growth/partnerships-architect` β partner-mediated deals route through both deal desk + partnerships\n- `business-growth/commercial-policy` β the broader governance framework deal desk enforces\n- `sales-success/sales-engineer` β provides technical validation in packet\n- `sales-success/sales-operations` β owns CRM / forecast accuracy that deal desk feeds","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/deal-desk","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/deal-desk/SKILL.md","defaultBranch":"main"},"readme":"# Deal Desk\n\nEnd-to-end deal-desk operational practice: charter, approval thresholds, deal-review packet design, routing automation, velocity analysis, and the governance that turns \"every deal is a snowflake\" into \"we close non-standard deals in 48 hours predictably.\"\n\nThis skill is provider-agnostic: works whether your CRM is Salesforce, HubSpot, Pipedrive, or homegrown. The patterns and decisions transfer.\n\n---\n\n## When to use this skill\n\n| Situation | Skill applies |\n|-----------|---------------|\n| Starting a deal-desk function from scratch | Yes β start with **charter design** |\n| Reviewing existing deal-desk for slowness / inconsistency | Yes β use `scripts/deal_velocity_analyzer.py` + **bottleneck patterns** |\n| Defining who can approve what discount / term | Yes β use **approval threshold matrix** + `scripts/discount_authority_router.py` |\n| Building the deal-review packet template | Yes β see **deal-review packet** section + `scripts/deal_review_packet.py` |\n| Approving / declining a specific deal | Use the packet generator + approval router |\n| Setting pricing strategy | Use `business-growth/pricing-strategy` first |\n| Forecasting / measuring pipeline | Use `business-growth/revenue-operations` |\n| Negotiating an individual contract | Pair with `business-growth/contract-and-proposal-writer` |\n\n---\n\n## What deal desk does (and doesn't)\n\n**Does:**\n- Review non-standard deals: discounts beyond rep authority, custom legal terms, custom SLAs, multi-product bundles, payment terms outside policy\n- Make the approval decision (or route to the right approver)\n- Structure the deal: pricing, terms, ramp schedule, success criteria\n- Maintain the deal-desk **policy** β what's standard, what needs approval\n- Track deal velocity (time from request β decision β signature)\n- Produce evidence for finance / audit (every concession traceable)\n\n**Doesn't:**\n- Set the published pricing (that's pricing strategy)\n- Negotiate with the customer (that's the sales rep / AE)\n- Close the sale (that's the rep + customer success)\n- Run the order-to-cash workflow (that's billing / RevOps)\n- Replace legal review (legal is one of the approvers, not the function itself)\n\nA clean deal-desk = the lubricant. Without it, every non-standard deal turns into a multi-week negotiation among engineering / product / legal / finance / executive. With it, those people are consulted by deal desk as needed and the rep gets a yes/no in days.\n\n---\n\n## Deal-desk charter (template)\n\nEvery deal desk needs a written charter. Use this template:\n\n```yaml\npurpose:\n Deal Desk reviews, approves, and structures non-standard deals to enable\n sales to close faster while keeping commercial / legal / financial risk\n within company tolerance.\n\nscope:\n In-scope:\n - All deals > $X ARR\n - All deals with discount > Y%\n - All deals with non-standard terms (custom SLAs, custom legal language,\n payment terms beyond Net 30, ramp deals, multi-year discounts > 12 months\n of standard, bundles spanning multiple product lines)\n - All renewals with > 20% expansion or > 10% contraction\n - All deals to enterprise (>1000 employees) or regulated industries\n Out-of-scope:\n - Self-serve / PLG transactions\n - Standard renewals within auto-renewal terms\n - Trial extensions < 30 days\n - Add-ons < $X per existing customer\n\nsla:\n - Standard deal-desk review (no exec approval needed): 1 business day\n - Deal needing CFO/CRO approval: 2 business days\n - Deal needing CEO/Board approval: 5 business days\n - Legal-only review (no commercial concession): 2 business days\n\nintake_format:\n Sales submits via [Salesforce form / CPQ tool / Slack form]. Required fields:\n - Customer name + size + industry\n - Product(s) + ACV\n - Requested deviation from standard (specific list)\n - Justification (competitor situation, customer constraint, strategic value)\n - Standard-pricing total + requested total\n - Contract length + payment terms\n - Implementation / SLA requ","createdAt":"2026-09-25T13:52:02.715Z","updatedAt":"2026-09-25T13:52:02.715Z"},{"id":"cmuh0s8jh03oyqu06dmht6jhx","slug":"borghei-claude-skills-churn-prevention","name":"churn-prevention","description":"SaaS churn reduction covering cancel flow design, dynamic save offers, exit survey architecture, dunning sequences, payment recovery, win-back campaigns, and churn impact modeling.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"churn-prevention","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"SaaS churn reduction covering cancel flow design, dynamic save offers, exit survey architecture, dunning sequences, payment recovery, win-back campaigns, and churn impact modeling.","permissions":[],"systemPrompt":"# Churn Prevention\n\nProduction-grade SaaS churn reduction framework covering cancel flow architecture, dynamic save offer mapping, exit survey design, dunning sequence engineering, payment recovery optimization, win-back campaigns, and churn impact modeling. Addresses both voluntary churn (customers who decide to leave) and involuntary churn (customers who leave due to payment failure).\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [Churn Taxonomy](#churn-taxonomy)\n- [Cancel Flow Architecture](#cancel-flow-architecture)\n- [Exit Survey Design](#exit-survey-design)\n- [Dynamic Save Offer System](#dynamic-save-offer-system)\n- [Dunning Sequence Engineering](#dunning-sequence-engineering)\n- [Win-Back Campaign Framework](#win-back-campaign-framework)\n- [Churn Health Scoring](#churn-health-scoring)\n- [Metrics and Benchmarks](#metrics-and-benchmarks)\n- [Churn Impact Calculator](#churn-impact-calculator)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore designing the churn-prevention system, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Voluntary vs involuntary churn split** β which dominates (determines whether to build cancel flow/save offers or dunning/payment recovery)\n- [ ] **Existing cancel flow vs instant/support cancellation** β sets build-from-scratch vs optimize mode\n- [ ] **Current MRR + ARPU + billing cycle** β sizes the dollar impact and the save-offer budget\n- [ ] **Payment processor** β Stripe / Braintree / Paddle / Recurly (determines card-updater and dunning retry implementation)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| Current monthly churn rate? (voluntary vs involuntary split) | Determines which lever to pull |\n| Do you have a cancel flow, or is cancellation instant/via support? | Determines build vs optimize mode |\n| What payment processor? (Stripe, Braintree, Paddle) | Affects dunning implementation |\n| Average contract value and billing cycle? | Sizes the save offer budget |\n| Current MRR? | Calculates the dollar impact of churn reduction |\n| SaaS model? (self-serve vs sales-assisted) | Determines intervention type |\n| Do you collect exit reasons today? | Data availability for save offer mapping |\n\n---\n\n## Churn Taxonomy\n\n### Voluntary Churn (Customer Decides to Leave)\n\n| Type | Signal | Addressable? |\n|------|--------|-------------|\n| Value gap | Not getting enough value for the price | Yes -- save offers, feature education |\n| Product-market mismatch | Wrong ICP, product does not fit their use case | Partially -- downgrade or pivot |\n| Competitor switch | Found a better alternative | Yes -- competitive counter-offers |\n| Budget cut | Cannot afford it anymore | Yes -- discount or pause |\n| Project completion | Seasonal or project-based need | Yes -- pause option |\n| Poor experience | Bad support, bugs, frustration | Yes -- human intervention |\n| Never activated | Signed up, never used it | Partially -- reactivation before cancel |\n\n### Involuntary Churn (Payment Fails)\n\n| Cause | % of Failed Payments | Recoverable? |\n|-------|---------------------|-------------|\n| Expired card | 40-50% | Yes -- card updater service |\n| Insufficient funds | 20-30% | Yes -- smart retry timing |\n| Bank decline (fraud flag) | 10-15% | Sometimes -- customer must contact bank |\n| Account closed | 5-10% | No -- customer must provide new card |\n| Network error | 5-10% | Yes -- automatic retry |\n\n---\n\n## Cancel Flow Architecture\n\n### The 5-Stage Cancel Flow\n\n```\n[Cancel Button] β [Exit Survey] β [Dynamic Save Offer] β [Confirmation] β [Post-Cancel]\n```\n\n### Stage 1: Cancel Trigger\n\n- Cancel option is findable (Settings > Account > Cancel). Do not hide it.\n- Clicking \"Cancel\" starts the flow -- it does not immediately cancel the account\n- Works on both desktop and mobile\n\n### Stage 2: Exit Survey (Required, 1 Question)\n\n**Question:** \"What is the main reason you are cancelling?\"\n\nPresent as radio buttons (not a dropdown). Maximum 8 options:\n\n| Reason | Internal Code |\n|--------|--------------|\n| Too expensive for the value I get | PRICE |\n| Not using it enough | LOW_USAGE |\n| Missing a feature I need | MISSING_FEATURE |\n| Switching to a different product | COMPETITOR |\n| My project or need ended | PROJECT_END |\n| Too complicated to use | COMPLEXITY |\n| Just testing, did not plan to keep it | TESTING |\n| Other (with optional text field) | OTHER |\n\n**Rules:**\n- Survey is required before showing the save offer (the answer determines the offer)\n- One question only. No multi-page surveys.\n- Optional free-text field for \"Other\" and as a supplement to any selection\n- Track response distribution monthly to identify systemic issues\n\n### Stage 3: Dynamic Save Offer\n\n**Map each exit reason to exactly one save offer:**\n\n| Exit Reason | Save Offer | Offer Copy |\n|------------|-----------|------------|\n| PRICE | 30-50% discount for 2-3 months | \"We'd like to offer you [X]% off for the next [N] months\" |\n| LOW_USAGE | Pause account for 1-3 months | \"Pause your account and come back when you need it\" |\n| MISSING_FEATURE | Roadmap preview + workaround | \"[Feature] is coming in [Q]. Here's how to achieve it now\" |\n| COMPETITOR | Competitive comparison + discount | \"Here's how we compare to [competitor]. Plus [X]% off\" |\n| PROJECT_END | Pause option | \"Pause instead of cancel -- your data stays safe\" |\n| COMPLEXITY | Free onboarding session | \"Let us set it up for you -- free 30-min session with our team\" |\n| TESTING | No offer -- let them go | \"Thanks for trying us out. You're welcome back anytime.\" |\n| OTHER | General retention offer | \"Before you go -- we'd love to make this right. [Contact support]\" |\n\n**Offer presentation rules:**\n- One clear offer per screen (not multiple choices)\n- Quantify the value: \"Save $120 over the next 3 months\" not \"Get a discount\"\n- CTA: \"Accept Offer\" vs \"Continue Cancelling\" (both clearly labeled)\n- No countdown timers, no fake urgency\n- No guilt-trip copy\n\n### Stage 4: Confirmation\n\nIf they decline the save offer or there is no offer to make:\n\n```\nββββββββββββββββββββββββββββββββββββββββββ\nβ We're sorry to see you go β\nβ β\nβ What happens when you cancel: β\nβ - Your data is saved for 90 days β\nβ - Access continues until [date] β\nβ - You can reactivate anytime β\nβ β\nβ [Yes, Cancel My Account] β\nβ [Wait, I Changed My Mind] β\nβ β\nβ No pre-checked boxes. β\nβ No confusing language. β\nββββββββββββββββββββββββββββββββββββββββββ\n```\n\n### Stage 5: Post-Cancel\n\n| Timing | Channel | Message |\n|--------|---------|---------|\n| Immediately | Email | Cancellation confirmation + data retention policy + reactivation link |\n| Day 7 | Email | \"We miss you\" + single CTA to reactivate + what they are missing |\n| Day 30 | Email | Product update + relevant improvement + reactivation offer |\n| Day 60 | Email | Final win-back with strongest offer (if applicable) |\n\n---\n\n## Exit Survey Design\n\n### Data Analysis Framework\n\nTrack exit survey responses monthly and calculate:\n\n| Metric | Formula | Action Threshold |\n|--------|---------|-----------------|\n| Reason distribution | % of cancels per reason | Any reason > 30% = systemic issue |\n| Save rate by reason | Saved / Cancel attempts per reason | Any reason < 5% save rate = wrong offer |\n| Reason trend | Month-over-month change | Increasing trend = worsening problem |\n| Feature gap frequency | Count of \"missing feature\" with specific feature named | Top 3 missing features = product roadmap input |\n\n### Competitive Intelligence from Exit Surveys\n\nWhen users select \"Switching to a different product\":\n\n- Ask a follow-up: \"Which product are you switching to?\" (optional, free text or dropdown)\n- Track the top 3 competitors winning your churners\n- Feed this data into competitive-teardown skill for quarterly analysis\n\n---\n\n## Dynamic Save Offer System\n\n### Offer Economics\n\n| Offer Type | Cost to Business | Save Rate Benchmark | When Profitable |\n|-----------|-----------------|---------------------|----------------|\n| 30% discount (3 months) | 30% of 3 months revenue | 15-25% | If LTV after save > discount cost |\n| 50% discount (2 months) | 50% of 2 months revenue | 20-30% | If retained customer stays 6+ months |\n| Pause (1-3 months) | $0 (no revenue during pause) | 25-40% | If 50%+ reactivate after pause |\n| Free onboarding session | CS team time (~$50-100) | 10-20% | If ARPU > $100/month |\n| Downgrade to lower tier | Revenue reduction | 30-50% | If some revenue > no revenue |\n| Feature unlock | $0 (already built) | 5-15% | Always profitable |\n\n### Save Offer Decision Tree\n\n```\nUser selects exit reason β\nβββ PRICE β\nβ βββ Customer ARPU > median? β Offer 30% discount\nβ βββ Customer ARPU < median? β Offer downgrade to cheaper plan\nβββ LOW_USAGE β\nβ βββ Last login > 30 days? β Offer pause\nβ βββ Last login < 30 days? β Offer usage tips + discount\nβββ MISSING_FEATURE β\nβ βββ Feature on roadmap? β Share roadmap + workaround\nβ βββ Feature not planned? β Offer discount or acknowledge gap\nβββ COMPETITOR β\nβ βββ Known competitor? β Show comparison + retention offer\nβ βββ Unknown competitor? β General retention offer\nβββ PROJECT_END β\nβ βββ Always β Offer pause\nβββ COMPLEXITY β\nβ βββ Enterprise/high-value? β Offer dedicated onboarding session\nβ βββ SMB/low-value? β Offer guided tutorial link\nβββ TESTING β\n βββ Always β No offer, let go gracefully\n```\n\n---\n\n## Dunning Sequence Engineering\n\nFailed payments cause 20-40% of total churn. Most of it is recoverable with proper dunning.\n\n### Smart Retry Schedule\n\nDo not retry immediately after failure. Cards often recover within 3-7 days.\n\n| Retry | Timing | Why This Timing |\n|-------|--------|-----------------|\n| Initial charge | Day 0 | Normal billing cycle |\n| Retry 1 | Day 3 | Most card issues resolve within 72 hours |\n| Retry 2 | Day 7 | Paycheck cycle alignment |\n| Retry 3 | Day 12 | Second paycheck cycle |\n| Retry 4 | Day 18 | Final attempt before service action |\n| Service action | Day 21 | Downgrade or cancel |\n\n### Card Updater Services\n\nEnable automatic card updating to prevent expired card churn:\n\n| Processor | Service | How to Enable |\n|-----------|---------|---------------|\n| Stripe | Automatic card updates | Enabled by default on most plans |\n| Braintree | Account Updater | Must enable in merchant settings |\n| Paddle | Built-in | Automatic |\n| Recurly | Account Updater | Configuration required |\n\n### Dunning Email Sequence\n\n| Day | Subject Line | Body Focus | CTA |\n|-----|-------------|-----------|-----|\n| 0 | \"Your [Product] payment didn't go through\" | Factual, no blame. Card may be expired or funds unavailable. | [Update Payment Method] |\n| 3 | \"Action needed: update your payment for [Product]\" | Remind what they will lose access to. | [Update Payment Method] |\n| 7 | \"Your [Product] account is at risk\" | List features/data they have created. Mild urgency. | [Update Payment Method] |\n| 14 | \"Final notice: your [Product] access ends in 7 days\" | Clear deadline. Offer to help if bank issue. | [Update Payment Method] + [Contact Support] |\n| 21 | \"Your [Product] account has been paused\" | Account status change. Data is safe. Easy reactivation. | [Reactivate Account] |\n\n**Email rules:**\n- Every email links directly to the payment update page (not the dashboard)\n- No guilt, no shame. Card failures happen.\n- Subject lines are specific (include product name)\n- Include the amount owed and the card last 4 digits\n- Offer a support channel for customers who need help\n\n---\n\n## Win-Back Campaign Framework\n\n### Win-Back Timing\n\n| Window | Success Rate | Approach |\n|--------|-------------|---------|\n| Day 7 post-cancel | 5-10% | Gentle reminder, no pressure |\n| Day 30 post-cancel | 3-7% | Product update + offer |\n| Day 60 post-cancel | 2-5% | Strongest offer + fresh start |\n| Day 90+ post-cancel | 1-3% | Major product change only |\n\n### Win-Back Email Sequence\n\n**Day 7 Email:**\n- Subject: \"Your [Product] account is waiting for you\"\n- Body: What they left behind (data, projects, team). One CTA: reactivate.\n- No discount. Just value reminder.\n\n**Day 30 Email:**\n- Subject: \"Here's what's new in [Product]\"\n- Body: 2-3 specific improvements since they left. One CTA: reactivate.\n- Small incentive: \"Come back with 1 month free\"\n\n**Day 60 Email:**\n- Subject: \"We'd love to have you back -- [offer]\"\n- Body: Strongest offer (50% off 3 months or extended free period). Clear deadline.\n- Final significant outreach attempt.\n\n---\n\n## Churn Health Scoring\n\n### Leading Indicators of Churn\n\n| Signal | Weight | Detection |\n|--------|--------|-----------|\n| Login frequency declining (week over week) | High | Usage analytics |\n| Feature usage dropping | High | Feature event tracking |\n| Support ticket escalation | High | Help desk data |\n| NPS response < 7 | High | Survey data |\n| Invoice dispute or payment question | Medium | Billing system |\n| Champion left the company | High | Contact monitoring |\n| Contract renewal in < 90 days | Medium | CRM data |\n| Competitor evaluation detected | High | Sales intelligence |\n\n### Risk Score Calculation\n\n```\nRisk Score = Sum of (Signal Weight x Signal Present)\n\n0-20: Low risk (monitor)\n21-40: Moderate risk (proactive outreach)\n41-60: High risk (intervention required)\n61+: Critical risk (executive escalation)\n```\n\n---\n\n## Metrics and Benchmarks\n\n### Key Metrics\n\n| Metric | Formula | Good | Excellent |\n|--------|---------|------|-----------|\n| Save rate | Customers saved / Cancel attempts | 10-15% | 20%+ |\n| Voluntary churn rate | Voluntary cancels / Total customers (monthly) | < 3% | < 1.5% |\n| Involuntary churn rate | Failed payment cancels / Total customers (monthly) | < 1.5% | < 0.5% |\n| Payment recovery rate | Failed payments recovered / Total failed | 25-35% | 40%+ |\n| Win-back rate | Reactivations / Cancellations (90-day window) | 5-10% | 10%+ |\n| Exit survey completion rate | Surveys completed / Cancel attempts | > 70% | > 90% |\n| Save offer acceptance rate | Offers accepted / Offers shown | 15-25% | 30%+ |\n\n### Red Flags\n\n| Signal | Diagnosis | Action |\n|--------|-----------|--------|\n| Save rate < 5% | Offers not matching reasons | Rebuild offer-reason mapping |\n| Exit survey completion < 60% | Survey too long or optional | Make it required, 1 question |\n| Recovery rate < 20% | Retry logic or emails broken | Audit dunning sequence |\n| Single reason > 40% | Systemic product/pricing issue | Escalate to product/leadership |\n| Churn rate > 5% monthly | Business is likely contracting | Churn prevention alone will not fix; review ICP + product |\n\n---\n\n## Churn Impact Calculator\n\n### Quick Estimate\n\n```\nMonthly MRR at risk = Total MRR x Monthly churn rate\nAnnual MRR saved by 1% churn reduction = Total MRR x 0.01 x 12\nAnnual MRR saved by 20% save rate = (Monthly MRR at risk x 0.20) x 12\n\nExample:\n MRR: $500,000\n Monthly churn: 4% = $20,000/month lost\n Reduce to 3% = $5,000/month saved = $60,000/year\n Add 20% save rate on remaining = $3,000/month saved = $36,000/year\n Total annual impact: $96,000\n```\n\n---\n\n## Output Artifacts\n\n| Artifact | Format | Description |\n|----------|--------|-------------|\n| Cancel Flow Design | 5-stage flow with copy | Complete flow from trigger to post-cancel |\n| Exit Survey | Radio button options + mapping | 6-8 reasons with save offer mapping |\n| Save Offer System | Decision tree | Reason-to-offer mapping with economics |\n| Dunning Sequence | 5-email sequence | Subject lines, body copy, timing, retry schedule |\n| Win-Back Campaign | 3-email sequence | Day 7, 30, 60 emails with subject lines and offers |\n| Churn Scorecard | Metric table | Current metrics vs benchmarks with gap analysis |\n| Impact Model | Revenue calculation | Dollar impact of churn reduction at various improvement levels |\n\n---\n\n## Related Skills\n\n- **customer-success-manager** -- Use for health scoring, QBRs, and expansion revenue. Not for cancel flow or dunning design.\n- **pricing-strategy** -- Use when churn root cause is pricing or packaging mismatch. Not for save offer design.\n- **onboarding-cro** -- Use when churn traces back to poor activation. If users never experienced value, fix onboarding first.\n- **referral-program** -- Use for acquisition. Churn prevention handles the other end of the funnel.\n\n---\n\n## Tool Reference\n\n### 1. churn_impact_calculator.py\n\n**Purpose:** Calculate the revenue impact of churn reduction at various improvement levels.\n\n```bash\npython scripts/churn_impact_calculator.py --mrr 500000 --churn-rate 4.0 --save-rate 20\npython scripts/churn_impact_calculator.py --mrr 500000 --churn-rate 4.0 --save-rate 20 --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `--mrr` | Yes | Current monthly recurring revenue in dollars |\n| `--churn-rate` | Yes | Current monthly churn rate as percentage (e.g., 4.0 for 4%) |\n| `--save-rate` | No | Cancel flow save rate as percentage (default: 15) |\n| `--target-churn` | No | Target churn rate as percentage (default: current minus 1) |\n| `--json` | No | Output results as JSON |\n\n### 2. dunning_sequence_analyzer.py\n\n**Purpose:** Analyze dunning email sequence effectiveness and recommend retry timing optimizations.\n\n```bash\npython scripts/dunning_sequence_analyzer.py dunning_data.json\npython scripts/dunning_sequence_analyzer.py dunning_data.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `dunning_data.json` | Yes | JSON file with failed payment and retry data |\n| `--json` | No | Output results as JSON |\n\n**Input JSON format:**\n```json\n{\n \"failed_payments\": [\n {\n \"payment_id\": \"PAY-001\",\n \"amount\": 99.00,\n \"failure_reason\": \"expired_card\",\n \"retry_attempts\": [\n {\"day\": 0, \"recovered\": false},\n {\"day\": 3, \"recovered\": false},\n {\"day\": 7, \"recovered\": true}\n ]\n }\n ]\n}\n```\n\n### 3. exit_survey_analyzer.py\n\n**Purpose:** Analyze exit survey responses to identify churn patterns, save offer effectiveness, and systemic issues.\n\n```bash\npython scripts/exit_survey_analyzer.py survey_data.json\npython scripts/exit_survey_analyzer.py survey_data.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `survey_data.json` | Yes | JSON file with exit survey response data |\n| `--json` | No | Output results as JSON |\n| `--period` | No | Analysis period label (default: \"current\") |\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Solution |\n|---------|-------------|----------|\n| Save rate below 5% across all reasons | Save offers do not match exit reasons | Rebuild the exit-reason-to-offer mapping using survey data; run exit_survey_analyzer.py to identify mismatches |\n| Exit survey completion under 60% | Survey is optional or too long | Make the single-question survey required before showing the save offer; remove multi-page flows |\n| Payment recovery rate below 20% | Retry logic misconfigured or dunning emails not sending | Audit dunning sequence with dunning_sequence_analyzer.py; verify email deliverability and retry schedule |\n| Single exit reason exceeds 40% of responses | Systemic product or pricing issue | Escalate to product or leadership; this is not solvable with cancel flow alone |\n| Churn rate above 5% monthly | Likely ICP, product-market fit, or pricing problem | Churn prevention alone will not fix this; pair with pricing-strategy and product feedback loops |\n| Win-back emails have zero reactivations | Emails not reaching inbox or offers are weak | Check deliverability (SPF, DKIM, DMARC); test stronger offers; verify reactivation links work |\n| Involuntary churn rising while voluntary is stable | Card updater not enabled or retry timing is poor | Enable automatic card updating on your payment processor; review retry schedule in dunning_sequence_analyzer.py |\n\n---\n\n## Success Criteria\n\n- Monthly voluntary churn rate below 2.5% (below 1.5% is excellent)\n- Monthly involuntary churn rate below 1.0% (below 0.5% is excellent)\n- Cancel flow save rate of 15-25% (above 20% is excellent)\n- Payment recovery rate of 30%+ on failed payments\n- Exit survey completion rate above 80%\n- Win-back reactivation rate of 5-10% within 90 days post-cancel\n- Save offer acceptance rate above 20% with retained customers staying 6+ months post-save\n\n---\n\n## Scope & Limitations\n\n- **In scope:** Cancel flow design, exit survey architecture, save offer mapping, dunning sequences, payment recovery, win-back campaigns, churn impact modeling\n- **Out of scope:** Product-market fit analysis, pricing restructuring, ICP redefinition, customer acquisition\n- **Data dependency:** Scripts analyze point-in-time snapshots from JSON input; no real-time CRM integration\n- **Not predictive ML:** All scoring is deterministic and algorithmic -- no machine learning models\n- **Legal note:** Cancel flows must comply with FTC guidelines (US) and consumer protection laws (EU) -- do not make cancellation unreasonably difficult\n- **Revenue estimates:** Impact calculations are projections based on input assumptions, not guarantees\n\n---\n\n## Integration Points\n\n- **customer-success-manager** -- Feed health scores into churn risk assessment; use churn data to calibrate health score thresholds\n- **pricing-strategy** -- When exit survey data shows PRICE as the dominant reason (>30%), escalate to pricing-strategy for structural pricing review\n- **onboarding-cro** -- When exit survey data shows LOW_USAGE or COMPLEXITY as top reasons, the root cause is often poor activation; fix onboarding first\n- **revenue-operations** -- Pipeline and forecast models should account for churn reduction impact on net revenue retention (NRR)\n- **referral-program** -- Retained customers from save offers are candidates for referral program enrollment after 90 days of continued usage","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/churn-prevention","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/churn-prevention/SKILL.md","defaultBranch":"main"},"readme":"# Churn Prevention\n\nProduction-grade SaaS churn reduction framework covering cancel flow architecture, dynamic save offer mapping, exit survey design, dunning sequence engineering, payment recovery optimization, win-back campaigns, and churn impact modeling. Addresses both voluntary churn (customers who decide to leave) and involuntary churn (customers who leave due to payment failure).\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [Churn Taxonomy](#churn-taxonomy)\n- [Cancel Flow Architecture](#cancel-flow-architecture)\n- [Exit Survey Design](#exit-survey-design)\n- [Dynamic Save Offer System](#dynamic-save-offer-system)\n- [Dunning Sequence Engineering](#dunning-sequence-engineering)\n- [Win-Back Campaign Framework](#win-back-campaign-framework)\n- [Churn Health Scoring](#churn-health-scoring)\n- [Metrics and Benchmarks](#metrics-and-benchmarks)\n- [Churn Impact Calculator](#churn-impact-calculator)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore designing the churn-prevention system, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Voluntary vs involuntary churn split** β which dominates (determines whether to build cancel flow/save offers or dunning/payment recovery)\n- [ ] **Existing cancel flow vs instant/support cancellation** β sets build-from-scratch vs optimize mode\n- [ ] **Current MRR + ARPU + billing cycle** β sizes the dollar impact and the save-offer budget\n- [ ] **Payment processor** β Stripe / Braintree / Paddle / Recurly (determines card-updater and dunning retry implementation)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| Current monthly churn rate? (voluntary vs involuntary split) | Determines which lever to pull |\n| Do you have a cancel flow, or is cancellation instant/via support? | Determines build vs optimize mode |\n| What payment processor? (Stripe, Braintree, Paddle) | Affects dunning implementation |\n| Average contract value and billing cycle? | Sizes the save offer budget |\n| Current MRR? | Calculates the dollar impact of churn reduction |\n| SaaS model? (self-serve vs sales-assisted) | Determines intervention type |\n| Do you collect exit reasons today? | Data availability for save offer mapping |\n\n---\n\n## Churn Taxonomy\n\n### Voluntary Churn (Customer Decides to Leave)\n\n| Type | Signal | Addressable? |\n|------|--------|-------------|\n| Value gap | Not getting enough value for the price | Yes -- save offers, feature education |\n| Product-market mismatch | Wrong ICP, product does not fit their use case | Partially -- downgrade or pivot |\n| Competitor switch | Found a better alternative | Yes -- competitive counter-offers |\n| Budget cut | Cannot afford it anymore | Yes -- discount or pause |\n| Project completion | Seasonal or project-based need | Yes -- pause option |\n| Poor experience | Bad support, bugs, frustration | Yes -- human intervention |\n| Never activated | Signed up, never used it | Partially -- reactivation before cancel |\n\n### Involuntary Churn (Payment Fails)\n\n| Cause | % of Failed Payments | Recoverable? |\n|-------|---------------------|-------------|\n| Expired card | 40-50% | Yes -- card updater service |\n| Insufficient funds | 20-30% | Yes -- smart retry timing |\n| Bank decline (fraud flag) | 10-15% | Sometimes -- customer must contact bank |\n| Account closed | 5-10% | No -- customer must provide new card |\n| Network error | 5-10% | Yes -- automatic retry |\n\n---\n\n## Cancel Flow Architecture\n\n### The 5-Stage Cancel Flow\n\n```\n[Cancel Button] β [Exit Survey] β [Dynamic Save Offer] β [Confirmation] β [Post-Cancel]\n```\n\n### Stage 1: Cancel Trigger\n\n- Cancel option is findable (Settings > Account > Cancel). Do not hide it.\n- Clicking \"Cancel\" starts the flow -- it does n","createdAt":"2026-09-25T13:52:02.621Z","updatedAt":"2026-09-25T13:52:02.621Z"},{"id":"cmuh0s8ik03opqu06byln99vj","slug":"borghei-claude-skills-channel-economics","name":"channel-economics","description":"Channel economics: design and analyze the financial structure of go-to-market channels. Use when picking a channel mix, modeling partner margin or TCO, designing partner tiers and rebates, or analyzing channel conflict.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"channel-economics","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Channel economics: design and analyze the financial structure of go-to-market channels. Use when picking a channel mix, modeling partner margin or TCO, designing partner tiers and rebates, or analyzing channel conflict.","permissions":[],"systemPrompt":"# Channel Economics\n\nEnd-to-end financial modeling and design of go-to-market channels: direct sales economics, reseller / distributor margin structures, marketplace fees, partner tier economics, channel conflict resolution, and the TCO frameworks that compare channel options apples-to-apples.\n\nThis skill provides the financial backbone for channel strategy. For strategic partnership design (which channel to invest in, how to structure the partnership), see `business-growth/partnerships-architect`. For partner-deal-level approval mechanics, see `business-growth/deal-desk`.\n\n---\n\n## When to use this skill\n\n| Situation | Skill applies |\n|-----------|---------------|\n| Deciding direct vs partner-led for a new product | Yes β start with **channel model decision tree** |\n| Designing a partner tier structure (silver/gold/platinum) | Yes β see **partner tier economics** |\n| Modeling a specific partner deal's margin / payback | Yes β `scripts/channel_margin_calculator.py` |\n| Analyzing channel conflict (overlapping direct + partner deals) | Yes β see **channel conflict** + `scripts/channel_mix_optimizer.py` |\n| Building a partner program rebate / SPIFF structure | Yes β see **rebate design** |\n| Comparing AWS Marketplace vs direct list-price economics | Yes β `scripts/channel_margin_calculator.py --channel marketplace` |\n| Negotiating a specific partner contract | Use `business-growth/contract-and-proposal-writer` for the contract; this for the economics |\n| Strategic partnership design (joint go-to-market, OEM, white-label) | Use `business-growth/partnerships-architect` first |\n\n---\n\n## The channel model decision tree\n\nSix core channel models. Most companies use a mix.\n\n```\nWhat's the product's complexity + price point?\n\nLow complexity, low price (< $10k ACV):\nβββ Self-serve / PLG β no channel\nβββ E-commerce β direct via web\nβββ Marketplace (AWS / Azure / GCP / Salesforce AppExchange) β if buyer already there\n\nMedium complexity, mid-market price ($10k - $250k ACV):\nβββ Inside sales / SDR-led direct β if buyer journey is well-understood\nβββ Reseller / VAR (Value-Added Reseller) β if local presence / language matters\nβββ Marketplace β if buyer prefers procurement via existing relationship\nβββ Embedded / OEM β if your product is a component in someone else's offering\n\nHigh complexity, enterprise ($250k+ ACV):\nβββ Direct field sales β standard for high-touch enterprise\nβββ Strategic SI / Integrator (Accenture, Deloitte, etc.) β if implementation is a substantial project\nβββ ISV / Embedded β if you're a feature in a larger platform\nβββ Reseller / Distributor β for regional or vertical specialty\n\nOperational / managed-service buyer:\nβββ MSP (Managed Service Provider) β if customer wants outsourced operations\n```\n\nSee [references/channel-models-direct-partner-marketplace.md](references/channel-models-direct-partner-marketplace.md) for each model in depth: economic structure, typical margin splits, when each works / fails, contract patterns.\n\n---\n\n## Margin and TCO framework\n\nApples-to-apples channel comparison requires a consistent TCO model. The naive comparison (\"direct gets 100%, reseller gets 70%\") misses critical costs.\n\n### True channel TCO formula\n\n```\nChannel Contribution Margin\n = Channel-attributed Revenue\n β COGS\n β Partner Discount/Commission\n β Channel-specific Sales Cost (allocated)\n β Channel-specific Marketing Cost (MDF, co-marketing)\n β Partner Enablement Cost (training, certification)\n β Channel Operations Cost (channel manager headcount)\n β Channel-specific Support Cost (T1 partner support)\n```\n\n### Side-by-side comparison\n\nFor a $100k ACV deal:\n\n| Component | Direct | Reseller (30% off) | AWS Marketplace |\n|-----------|--------|---------------------|-----------------|\n| Customer payment | $100,000 | $100,000 | $100,000 |\n| Reseller / marketplace fee | $0 | -$30,000 (30% discount) | -$3,000 (3% AWS fee) |\n| Revenue to us | $100,000 | $70,000 | $97,000 |\n| COGS (15%) | -$15,000 | -$10,500 | -$14,550 |\n| Sales cost (allocated CAC) | -$25,000 | -$5,000 | -$8,000 |\n| Marketing cost (MDF / listing) | -$2,000 | -$8,000 | -$5,000 |\n| Partner enablement (amortized) | $0 | -$3,000 | -$1,500 |\n| Channel ops (amortized) | $0 | -$2,000 | -$1,000 |\n| Support cost | -$5,000 | -$3,000 | -$5,000 |\n| **Net contribution** | **$53,000** | **$38,500** | **$61,950** |\n| **% of ACV** | 53% | 38.5% | 62% |\n\nThe \"30% discount\" reseller deal is more like 14.5% margin difference once everything's counted. Marketplace can look better than direct on per-deal basis (Amazon's sales team brings the buyer) β but volume varies.\n\nUse `scripts/channel_margin_calculator.py --deal deal.yaml --channel ` to model this for any deal.\n\nSee [references/margin-and-tco-frameworks.md](references/margin-and-tco-frameworks.md) for the full TCO framework, per-cost-line guidance, and how to allocate \"fully-loaded\" sales / marketing / ops costs.\n\n---\n\n## Partner tier economics\n\nMulti-tier partner programs (Authorized β Silver β Gold β Platinum) are common. Designed badly, they reward effort that isn't valuable; designed well, they reward outcomes that drive growth.\n\n### Standard tier structure\n\n| Tier | Annual revenue threshold | Discount % | Other benefits | Requirements |\n|------|-------------------------|------------|----------------|--------------|\n| Authorized | None | 10% | Standard support | Sign partner agreement; 1 certified person |\n| Silver | $100k | 15% | Co-marketing eligible (limited MDF) | $100k achieved; 3 certified people; 2 customer wins |\n| Gold | $500k | 20% + 5% rebate at threshold | Dedicated channel manager; MDF; deal registration; lead sharing | $500k achieved; 5 certified; 5 wins; 80% renewal rate |\n| Platinum | $2M | 25% + 7% rebate at threshold | Top-tier support; joint roadmap; preferred status; press release rights | $2M achieved; 10 certified; 10 wins; 90% renewal; participation in advisory board |\n\n### Tier design principles\n\n1. **Outcome-based, not effort-based.** Reward revenue + retention, not training hours or marketing event count.\n2. **Achievable but stretching.** Each tier should be a 12-18 month stretch from the prior.\n3. **Differentiable benefits.** Each tier needs benefits a partner actively wants (not just \"more support\").\n4. **Renewable status.** Tiers re-evaluated annually. Partners can move down if they don't maintain.\n5. **Anti-gaming protection.** Discount-stacking, registration gaming, transfer pricing β design out.\n\nUse `scripts/partner_tier_economics.py --tiers tiers.yaml` to model tier economics: gross margin per tier, partner-side incentive, break-even revenue per partner per tier.\n\n---\n\n## Rebate / SPIFF design\n\nThree common reward structures, each with trade-offs:\n\n### Front-end discount\n\nPartner buys from you at a discount; sells to customer at list (or close). Margin = the spread.\n\n**Pros:** Simple. Cash flow goes to partner immediately.\n**Cons:** Hard to incentivize specific behaviors. Discount is locked in regardless of performance.\n\n### Back-end rebate\n\nPartner pays full price (or near it); earns rebate quarterly / annually based on revenue / tier achievement.\n\n**Pros:** Ties reward to actual achievement; behaviors can be incentivized (e.g., bonus for selling new products).\n**Cons:** Cash-flow burden on partner. Complex to administer.\n\n### MDF (Marketing Development Funds) / SPIFF\n\nPer-deal or per-period bonuses for specific actions: bring leads, attend events, certify staff.\n\n**Pros:** Highly targetable. Rewards specific behaviors you want.\n**Cons:** Easy to game; admin overhead high; partners often expect it without producing.\n\n### Typical mix\n\n| Partner type | Front-end | Back-end | MDF/SPIFF |\n|--------------|-----------|----------|-----------|\n| Reseller (transactional) | 70-80% of total comp | 10-20% | 5-10% |\n| VAR (consultative selling) | 50-60% | 20-30% | 10-20% |\n| Distributor (volume play) | 80-90% | 5-15% | 5% |\n| ISV / Embedded | n/a (rev share) | 100% | 0 |\n| MSP | 40-60% | 20-30% | 10-30% |\n\n---\n\n## Channel conflict\n\nChannel conflict happens when multiple sales paths chase the same customer. Common forms:\n\n### Direct-vs-partner conflict\n\n| Scenario | Resolution pattern |\n|----------|---------------------|\n| Direct rep finds opportunity also touched by partner | Deal registration: first to register wins; partner gets credit if they brought it |\n| Partner finds direct customer | If direct is already engaged: partner deferred (with consolation MDF perhaps); if not: partner leads |\n| Customer asks for direct after partner-led pilot | Honor partner relationship for term; transition at next renewal if appropriate |\n\n### Partner-vs-partner conflict\n\n| Scenario | Resolution pattern |\n|----------|---------------------|\n| Two resellers both pursuing same account | First-registered wins; second is offered alternative leads / regional swap |\n| Vertical specialist vs geographic | Vertical wins (customer values vertical expertise more) |\n| New partner pursues incumbent partner's customer | Incumbent has right of first refusal for 90 days |\n\n### Marketplace-vs-direct conflict\n\nCustomer can buy via AWS Marketplace OR direct. If price is lower direct, customer feels gamed. If price is same, why not just use marketplace? Common resolution:\n\n- **Same price** direct vs marketplace (customer doesn't get punished for procurement choice)\n- **Quota credit** to the direct rep when customer chooses marketplace (so rep isn't disincentivized)\n- **Marketplace listing visibility** as a value-add, not as a different pricing channel\n\nSee [references/channel-conflict-resolution.md](references/channel-conflict-resolution.md) for the full conflict-resolution playbook including deal registration process, neutral arbitration, conflict-of-interest disclosure.\n\n---\n\n## Clarify First\n\nBefore modeling the channel economics, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Channel model(s) in scope** β direct, reseller/VAR, distributor, marketplace, OEM, or MSP (sets which decision-tree branch and TCO comparison to run)\n- [ ] **Target ACV / price point** β sub-$10k vs mid-market vs enterprise (selects the viable channel branch and sizes per-deal margin)\n- [ ] **Fully-loaded cost lines** β COGS %, allocated sales/marketing/ops/support costs (drives the TCO contribution-margin model, not just the headline discount)\n- [ ] **Partner contribution + tier intent** β what the partner does (lead, sell, implement) and whether you're designing tiers/rebates (drives tier economics + rebate/SPIFF mix)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the model.\n\n## End-to-end workflows\n\n### Workflow: Design a new partner program\n\n1. **Pick channel models** β direct + reseller? marketplace? OEM? β using the decision tree\n2. **Model the economics** β `scripts/channel_margin_calculator.py` per channel option at expected ACV\n3. **Design tier structure** β `scripts/partner_tier_economics.py` to size the gates and benefits\n4. **Define rebate / SPIFF mix** β per tier and partner type\n5. **Write the partner agreement** (with `business-growth/contract-and-proposal-writer`)\n6. **Build channel ops** β deal registration, MDF approval, certification tracking\n7. **Hire channel manager(s)** β usually 1 manager per 10-15 active partners\n8. **Pilot with 3-5 partners** β measure, iterate, then scale\n\n### Workflow: Evaluate a specific partner deal\n\n1. **Inputs**: ACV, partner discount %, expected close, partner's contribution (lead source? sales effort? implementation?)\n2. **Calculate net contribution** β `scripts/channel_margin_calculator.py --deal deal.yaml --channel partner`\n3. **Compare to direct alternative** β would this deal have closed direct? at what cost?\n4. **Decide**: approve / counter / decline (often via deal desk if it's a non-standard partner discount)\n\n### Workflow: Channel mix analysis\n\n1. **Inputs**: actual revenue by channel for last 4 quarters\n2. **Run mix optimizer** β `scripts/channel_mix_optimizer.py --revenue revenue.csv` examines contribution margin per channel + identifies under-/over-invested channels\n3. **Recommend rebalancing** β e.g., \"Reseller channel: 20% of revenue, 8% of contribution margin β reduce investment; marketplace: 15% of revenue, 25% of contribution β increase listing visibility\"\n4. **Quarterly review**: present to CRO / CFO\n\n### Workflow: Resolve a channel conflict\n\n1. **Document the conflict** β accounts involved, parties, history\n2. **Apply the registration rule** β first-registered partner wins absent overriding facts\n3. **Consider exceptions** β strategic logo, customer preference, vertical expertise\n4. **Communicate decision** β both parties, with reasoning, in writing\n5. **Compensate the loser** β alternative leads, MDF, regional swap; preserve the relationship\n\n---\n\n## Anti-patterns\n\n- **Direct + partner at same price.** Customer feels punished for not using direct (or vice versa); kills partner motivation. Price-to-customer must be consistent across channels.\n- **Discount-only partner program.** Partners that only get a discount have no skin in your success; treat you as another vendor; switch easily.\n- **Endless partner expansion without enablement.** Signing 200 partners that don't sell anything; channel manager headcount can't scale; partners stale.\n- **Marketplace as afterthought.** Listing on AWS Marketplace without dedicated investment (listing optimization, co-sell programs) = marketplace generates nothing.\n- **Channel manager as glorified email forwarder.** CM should drive partner pipeline, not just relay leads.\n- **Rebates with no audit.** Partner self-reports revenue; you trust it; reality is 20% off. Build verification.\n- **MDF spent on activities that don't drive pipeline.** Partner runs a great event, generates no pipeline. MDF should require pipeline outcome.\n- **Channel conflict policy that isn't followed.** Policy says first-registered wins, but exec overrides every time β policy is theater.\n- **Different commission per channel for same deal.** Direct rep gets 8% on $100k deal, channel rep gets 6% on $100k deal β direct rep refuses partner help; channel rep undercut.\n- **OEM / embedded deals priced like resale.** OEM = customer doesn't see you at all; ASP can be 50-80% of list. Resale = customer sees you. Different economics; different price points.\n\n---\n\n## Tooling outputs\n\n| Script | Input | Output |\n|--------|-------|--------|\n| `scripts/channel_margin_calculator.py` | Deal spec YAML + channel type | Per-channel net contribution margin, cost line breakdown, comparison vs direct baseline |\n| `scripts/partner_tier_economics.py` | Tier definitions YAML | Per-tier: gross margin to us, gross margin to partner, partner break-even, tier graduation incentive analysis |\n| `scripts/channel_mix_optimizer.py` | Revenue CSV (by channel + quarter) | Per-channel revenue contribution, per-channel margin contribution, recommended rebalancing |\n\nAll scripts: stdlib only, argparse CLI, JSON or markdown output.\n\n---\n\n## References\n\n- [channel-models-direct-partner-marketplace.md](references/channel-models-direct-partner-marketplace.md) β 6 channel models in depth + economic structure + when each works\n- [margin-and-tco-frameworks.md](references/margin-and-tco-frameworks.md) β full TCO framework, allocation guidance, per-channel cost models\n- [channel-conflict-resolution.md](references/channel-conflict-resolution.md) β registration process, conflict patterns, arbitration\n\n---\n\n## Related skills\n\n- `business-growth/partnerships-architect` β strategic partnership design (this skill = the economics; that one = the strategy)\n- `business-growth/deal-desk` β approval mechanics for partner deals (this skill = \"what does it cost\"; deal desk = \"should we approve\")\n- `business-growth/pricing-strategy` β sets list pricing that channel economics deviates from\n- `business-growth/revenue-operations` β channel revenue is segmented in RevOps reporting\n- `business-growth/contract-and-proposal-writer` β drafts partner agreements\n- `sales-success/sales-operations` β runs channel ops (deal registration, MDF approval, certification tracking)\n- `c-level-advisor/cs-cro-advisor` β strategic channel-mix decisions are CRO-level","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/channel-economics","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/channel-economics/SKILL.md","defaultBranch":"main"},"readme":"# Channel Economics\n\nEnd-to-end financial modeling and design of go-to-market channels: direct sales economics, reseller / distributor margin structures, marketplace fees, partner tier economics, channel conflict resolution, and the TCO frameworks that compare channel options apples-to-apples.\n\nThis skill provides the financial backbone for channel strategy. For strategic partnership design (which channel to invest in, how to structure the partnership), see `business-growth/partnerships-architect`. For partner-deal-level approval mechanics, see `business-growth/deal-desk`.\n\n---\n\n## When to use this skill\n\n| Situation | Skill applies |\n|-----------|---------------|\n| Deciding direct vs partner-led for a new product | Yes β start with **channel model decision tree** |\n| Designing a partner tier structure (silver/gold/platinum) | Yes β see **partner tier economics** |\n| Modeling a specific partner deal's margin / payback | Yes β `scripts/channel_margin_calculator.py` |\n| Analyzing channel conflict (overlapping direct + partner deals) | Yes β see **channel conflict** + `scripts/channel_mix_optimizer.py` |\n| Building a partner program rebate / SPIFF structure | Yes β see **rebate design** |\n| Comparing AWS Marketplace vs direct list-price economics | Yes β `scripts/channel_margin_calculator.py --channel marketplace` |\n| Negotiating a specific partner contract | Use `business-growth/contract-and-proposal-writer` for the contract; this for the economics |\n| Strategic partnership design (joint go-to-market, OEM, white-label) | Use `business-growth/partnerships-architect` first |\n\n---\n\n## The channel model decision tree\n\nSix core channel models. Most companies use a mix.\n\n```\nWhat's the product's complexity + price point?\n\nLow complexity, low price (< $10k ACV):\nβββ Self-serve / PLG β no channel\nβββ E-commerce β direct via web\nβββ Marketplace (AWS / Azure / GCP / Salesforce AppExchange) β if buyer already there\n\nMedium complexity, mid-market price ($10k - $250k ACV):\nβββ Inside sales / SDR-led direct β if buyer journey is well-understood\nβββ Reseller / VAR (Value-Added Reseller) β if local presence / language matters\nβββ Marketplace β if buyer prefers procurement via existing relationship\nβββ Embedded / OEM β if your product is a component in someone else's offering\n\nHigh complexity, enterprise ($250k+ ACV):\nβββ Direct field sales β standard for high-touch enterprise\nβββ Strategic SI / Integrator (Accenture, Deloitte, etc.) β if implementation is a substantial project\nβββ ISV / Embedded β if you're a feature in a larger platform\nβββ Reseller / Distributor β for regional or vertical specialty\n\nOperational / managed-service buyer:\nβββ MSP (Managed Service Provider) β if customer wants outsourced operations\n```\n\nSee [references/channel-models-direct-partner-marketplace.md](references/channel-models-direct-partner-marketplace.md) for each model in depth: economic structure, typical margin splits, when each works / fails, contract patterns.\n\n---\n\n## Margin and TCO framework\n\nApples-to-apples channel comparison requires a consistent TCO model. The naive comparison (\"direct gets 100%, reseller gets 70%\") misses critical costs.\n\n### True channel TCO formula\n\n```\nChannel Contribution Margin\n = Channel-attributed Revenue\n β COGS\n β Partner Discount/Commission\n β Channel-specific Sales Cost (allocated)\n β Channel-specific Marketing Cost (MDF, co-marketing)\n β Partner Enablement Cost (training, certification)\n β Channel Operations Cost (channel manager headcount)\n β Channel-specific Support Cost (T1 partner support)\n```\n\n### Side-by-side comparison\n\nFor a $100k ACV deal:\n\n| Component | Direct | Reseller (30% off) | AWS Marketplace |\n|-----------|--------|---------------------|-----------------|\n| Customer payment | $100,000 | $100,000 | $100,000 |\n| Reseller / marketplace fee | $0 | -$30,000 (30% discount) | -$3,000 (3% AWS fee) |\n| Revenue to us | $100,000 | $70,000 | $97,000 |\n| COGS (15%) | -$15,000 | -$10,500 | -$14,550 |\n| Sales cost ","createdAt":"2026-09-25T13:52:02.588Z","updatedAt":"2026-09-25T13:52:02.588Z"},{"id":"cmuh0s8jv03p4qu06czo4hyam","slug":"borghei-claude-skills-commercial-policy","name":"commercial-policy","description":"Commercial policy: the governance framework defining what terms sales can offer and what triggers approval. Use when authoring a policy charter, defining discount/payment/liability rules, auditing deals, or generating a regional policy.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"commercial-policy","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Commercial policy: the governance framework defining what terms sales can offer and what triggers approval. Use when authoring a policy charter, defining discount/payment/liability rules, auditing deals, or generating a regional policy.","permissions":[],"systemPrompt":"# Commercial Policy\n\nEnd-to-end commercial-policy authoring and governance: defining the rules that govern what sales can offer, what triggers approval, and what's prohibited. Pairs with our deal-desk (operational enforcement) and pricing-strategy (price-setting) skills β this is the policy that those execute against.\n\nA good commercial policy:\n- Makes deal-desk faster (fewer ambiguous cases)\n- Makes sales reps more autonomous (clearer authority)\n- Makes legal reviews lighter (most cases already covered)\n- Reduces concession drift over time\n- Provides audit-ready governance documentation\n\n---\n\n## When to use this skill\n\n| Situation | Skill applies |\n|-----------|---------------|\n| Authoring commercial policy from scratch | Yes β start with **policy charter template** + `scripts/commercial_policy_generator.py` |\n| Refreshing an existing policy (annual) | Yes β see **annual policy review** workflow |\n| Auditing recent deals for policy compliance | Yes β `scripts/policy_compliance_checker.py` |\n| Analyzing terms-deviation patterns | Yes β `scripts/terms_deviation_analyzer.py` |\n| Tailoring policy for new region / vertical | Yes β `scripts/commercial_policy_generator.py --region ` |\n| Drafting sales training on policy | Yes β see **training section** |\n| Setting prices (not policy on deviations) | Use `business-growth/pricing-strategy` |\n| Per-deal approval | Use `business-growth/deal-desk` |\n| Writing the specific contract | Use `business-growth/contract-and-proposal-writer` |\n\n---\n\n## What commercial policy covers\n\nStandard scope:\n\n| Domain | Policy area |\n|--------|-------------|\n| **Pricing** | Standard pricing, discount thresholds, MFN, rebates, custom-bundle pricing |\n| **Contract** | Standard term length, payment terms, renewal terms, termination, customer audit rights |\n| **Legal** | Acceptable MSA modifications, liability cap, indemnification, jurisdiction, IP |\n| **Operational** | SLA tiers, custom SLAs, security commitments, dedicated infrastructure |\n| **Customer commitments** | Reference / case study / press release obligations |\n| **Channel** | Partner discount tiers, channel-conflict rules, deal-registration |\n| **Special terms** | Performance-based payment, acceptance criteria, ramp deals |\n\nWhat it doesn't cover:\n- Day-to-day pricing decisions (that's pricing strategy)\n- Per-deal approval mechanics (that's deal-desk operations)\n- Sales targets / quota (that's compensation policy)\n- Customer success / churn-prevention tactics\n\n---\n\n## Commercial policy charter (template)\n\nThe foundational document. Every company that does $5M+ ARR needs one. Use this template:\n\n```markdown\n# Commercial Policy Charter\n\n## Purpose\nThis Commercial Policy defines the rules that govern commercial terms\noffered to customers. It is binding on all customer-facing functions\n(Sales, Customer Success, Partner / Channel) and is enforced by Deal Desk.\n\n## Scope\nApplies to:\n- All new customer agreements\n- All renewals (with material change)\n- All partner-mediated deals\n- All custom / non-standard agreements\n\nDoes not apply to:\n- Self-serve / PLG transactions per standard published terms\n- Auto-renewals at standard terms\n\n## Owners and Approvers\n- Policy owner: CRO + CFO + General Counsel (jointly)\n- Operational enforcement: Deal Desk\n- Updates: quarterly review by policy owners\n- Material changes: board awareness\n\n## Pricing Policy\n\n### Standard pricing\n- All new customers offered at published list pricing\n- Published price is canonical; deviations require approval per matrix\n\n### Discount approval matrix\n[Per the deal-desk approval matrix β see business-growth/deal-desk]\n\n### Maximum allowed discount\n- Standard maximum: 50%\n- Beyond 50%: CEO + Board awareness required\n- Discount > 60%: only with explicit strategic-rationale documented and CEO sign-off\n\n### Most Favored Nation (MFN)\n- Not granted by default\n- Granted only with: strategic-tier customer + CRO + CFO + GC approval\n- Always scoped narrowly: same product, same volume, same term length, same geography\n- Disclosure-only (never automatic price-match)\n\n### Rebates\n- Performance-based rebates allowed per partner-program tier\n- Customer-tier rebates: discouraged; if granted, time-bounded and explicit\n\n## Contract Policy\n\n### Standard term\n- 12-month contract with annual prepay\n- Auto-renew unless 90-day notice\n\n### Term flexibility\n- < 12 months: requires Director approval\n- 24-36 months: Director approval\n- > 36 months: VP Sales approval\n- Multi-year discounts: per discount matrix\n\n### Payment terms\n- Standard: Net 30, annual prepay\n- Net 45-60: Director approval\n- Net 90+: CFO approval\n- Custom milestone-based: CFO approval; revenue recognition impact reviewed\n\n### Renewal\n- Standard: auto-renew, same terms, same price (or per published renewal pricing)\n- Renewal expansion > 20%: deal-desk review\n- Renewal contraction > 10%: deal-desk review + customer success consultation\n\n### Termination\n- Standard: termination for convenience requires 90-day notice\n- Termination for cause: 30-day cure period\n- Customer-requested termination flexibility: Director approval\n- Mid-term termination rights: VP Sales approval\n\n## Legal Policy\n\n### MSA modifications\n- Pre-approved modifications: tracked list in approved-modifications appendix\n- Custom modifications: General Counsel approval required\n- Customer-supplied MSA: full GC review; default to push back to our MSA\n\n### Liability cap\n- Standard: 1x annual fees\n- 2x annual fees: GC + CFO approval\n- > 2x annual fees: CEO sign-off\n- Carve-outs: IP infringement, gross negligence, willful misconduct β always uncapped\n\n### Indemnification\n- Standard mutual indemnification per template\n- Customer-favorable indemnification: GC approval\n- Defense / settlement control: vendor by default; customer-controlled needs CEO\n\n### Jurisdiction and governing law\n- Standard: vendor's jurisdiction\n- Customer jurisdiction: GC approval\n- Arbitration vs litigation: per template; deviations need GC\n\n### IP\n- Standard: each party retains pre-existing; joint inventions per default\n- Customer-favorable IP terms: GC approval\n- Source code escrow: only for OEM / strategic; never standard customer\n\n## Operational Policy\n\n### SLA tiers\n- Standard published SLA (99.5%)\n- Enhanced SLA (99.9%): per published pricing\n- Custom SLA: Customer Success + Engineering approval; pricing premium per agreement\n- Custom SLA with penalties: CRO + CCO + Engineering approval\n\n### Security commitments\n- Standard SOC 2 / ISO 27001 commitments per template\n- Custom security: CISO + GC approval\n- Customer audit rights: GC approval (limited to annual, with notice, third-party auditor)\n\n### Dedicated infrastructure\n- Not standard; available only with CTO + GC approval\n- Premium pricing required\n\n## Customer Commitments\n\n### Reference / case study requests\n- Standard: requested but not required\n- Discounted deals (> 15%): case study or reference required as condition\n- Strategic logos: explicit case study + press release commitment\n\n## Channel Policy\n\n### Partner-mediated deals\n- Per Partner Agreement; discount per tier\n- Deal registration governs conflict\n- Direct rep authority same as direct deals on partner-led opportunities\n\n## Special Terms\n\n### Performance-based payment\n- Payment-on-acceptance / acceptance criteria: CFO + GC approval\n- Milestone payments: CFO approval\n\n### Ramp deals\n- β€ 3 months: Sales Manager\n- 3-12 months: Director\n- > 12 months: VP Sales\n\n### Source code escrow (for customer)\n- Not standard; available only with CTO + GC approval\n\n## Documentation Requirements\n\nEvery non-standard deal documented per Deal Desk packet template:\n- Deviation explicitly listed\n- Justification documented\n- Approver identified\n- Customer commitments (if any) explicit\n- Expiration / conditions clear\n\n## Annual Review\n\nThis policy is reviewed annually by CRO + CFO + GC.\nMaterial changes communicated to sales with training.\n\n## Effective Date\n\n## Last Updated\n\n## Approved By\n- CRO: \n- CFO: \n- GC: \n- Board (acknowledgement): \n```\n\nSee [references/commercial-policy-charter.md](references/commercial-policy-charter.md) for the full annotated charter with notes on each section's typical contentious issues.\n\n---\n\n## Discount and terms policy details\n\nSee [references/discount-and-terms-policy.md](references/discount-and-terms-policy.md) for deeper guidance on:\n\n- Discount-percentage policy by ACV bracket\n- MFN clause design (when to allow, how to scope)\n- Performance-based rebate structures\n- Multi-year discount mechanics\n- Payment-term flexibility and revenue-recognition implications\n- Renewal pricing policy (escalators, holds, contraction)\n\n---\n\n## Contract and commercial guardrails\n\nSee [references/contract-and-commercial-guardrails.md](references/contract-and-commercial-guardrails.md) for deeper guidance on:\n\n- Acceptable MSA modifications (a list-based, not case-by-case approach)\n- Liability cap negotiation\n- Termination rights design\n- IP and joint-development clauses\n- Customer audit rights\n- Cross-jurisdictional terms (EU vs US vs APAC)\n\n---\n\n## Clarify First\n\nBefore generating the policy, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Company stage + ARR scale** β drives whether a full charter is warranted and how tight thresholds should be\n- [ ] **Approver structure** β who owns the policy and sits in the chain (CRO/CFO/GC, VP Sales, Director) (populates Owners/Approvers and every approval line)\n- [ ] **Region / jurisdiction** β US / EU / APAC (changes payment norms, governing law, and triggers a regional overlay)\n- [ ] **Max discount + liability risk appetite** β the discount ceiling and liability-cap tolerance (drives the Pricing and Legal policy sections)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the policy.\n\n## End-to-end workflows\n\n### Workflow: Author commercial policy from scratch\n\n1. **Assemble policy committee** β CRO + CFO + GC sponsors + Deal Desk Lead + Sales Operations\n2. **Inventory current deals** β what terms have been offered? What's been ad-hoc?\n3. **Identify policy gaps** β areas where ad-hoc behavior is hurting (concession drift, customer surprises)\n4. **Draft charter** using template; one section per domain\n5. **Internal review** β Sales VP, Eng VP, CISO, Customer Success VP, Finance for revenue recognition\n6. **Pilot** with sales managers for 30 days β collect feedback\n7. **Final approval** β CRO + CFO + GC sign-off; board awareness\n8. **Sales training** β workshop + recorded session + quick-reference cards\n9. **Publish** to sales wiki / partner portal / customer-facing communications team\n10. **Quarterly review** thereafter\n\n### Workflow: Refresh existing policy (annual)\n\n1. **Pull deal data** for past 12 months: discount distribution, terms deviations, approvals\n2. **Identify drift** β what's the deviation rate by policy category?\n3. **Survey sales managers** β what's working / what's blocking\n4. **Survey customers** β what terms have been requested but declined?\n5. **Identify market shifts** β competitive landscape, customer expectations\n6. **Draft amendments** β specific policy changes with rationale\n7. **Approve** with CRO + CFO + GC\n8. **Communicate changes** to sales with training\n9. **Update charter** + effective date\n\n### Workflow: Audit deal compliance\n\n1. **Export deals** from CRM for the period\n2. **Run compliance checker** β `scripts/policy_compliance_checker.py --deals deals.csv --policy policy.yaml`\n3. **Review non-compliant deals** β investigate each: was the deviation approved? was it documented?\n4. **Categorize**:\n - Compliant with approved deviation: OK\n - Non-compliant unapproved: investigate; corrective action\n - Compliant but suggests policy gap: amend policy\n5. **Report** to policy committee; track corrective actions\n\n### Workflow: Generate region-specific policy\n\n1. **Identify region-specific requirements** β currency, jurisdiction, payment norms, regulatory\n2. **Run** `scripts/commercial_policy_generator.py --base policy.yaml --region ` to get base + regional overlay\n3. **Tailor** further with local team (regional VP Sales, regional GC, regional CFO)\n4. **Approve** through standard governance\n5. **Communicate** to regional sales\n\n---\n\n## Anti-patterns\n\n- **Policy without enforcement.** Written policy + ad-hoc execution = policy is theater.\n- **Policy that's never updated.** Markets shift; competitive landscape changes; policy goes stale.\n- **Policy with no compliance audit.** Without measurement, you can't tell if policy is followed.\n- **Policy too restrictive.** When sales bypasses constantly, the policy is wrong; tighten or loosen.\n- **Policy too lax.** When everyone \"complies\" but margin still erodes, policy doesn't constrain enough.\n- **Policy authored without sales input.** Reps see it as imposed; comply minimally.\n- **Policy with no training.** Reps don't know what they can offer; default to over-asking deal desk.\n- **Policy that's a contract appendix.** Buried in legal docs; never read.\n- **Same policy across regions** when market conditions differ substantially.\n- **Policy reviewed only after a customer complaint.** Reactive only.\n\n---\n\n## Tooling outputs\n\n| Script | Input | Output |\n|--------|-------|--------|\n| `scripts/policy_compliance_checker.py` | Deal CSV + policy YAML | Per-deal: compliant / non-compliant with policy violation listing; aggregate compliance metrics |\n| `scripts/terms_deviation_analyzer.py` | Deal CSV | Deviation patterns: which terms most often deviate? from which standard? by what magnitude? |\n| `scripts/commercial_policy_generator.py` | Base policy YAML + optional region overlay | Generated policy document (markdown), tailored to company stage, ICP, region |\n\nAll scripts: stdlib only, argparse CLI, JSON or markdown output.\n\n---\n\n## References\n\n- [commercial-policy-charter.md](references/commercial-policy-charter.md) β full annotated charter with notes on each section\n- [discount-and-terms-policy.md](references/discount-and-terms-policy.md) β discount, MFN, rebate, payment-terms policy depth\n- [contract-and-commercial-guardrails.md](references/contract-and-commercial-guardrails.md) β MSA modifications, liability, termination, IP\n\n---\n\n## Related skills\n\n- `business-growth/deal-desk` β operational enforcement of policy\n- `business-growth/pricing-strategy` β sets prices that policy governs deviations from\n- `business-growth/contract-and-proposal-writer` β drafts contracts respecting policy\n- `business-growth/channel-economics` β channel deals subject to policy (with overlay for partners)\n- `business-growth/partnerships-architect` β partnership terms subject to commercial-policy oversight\n- `c-level-advisor/cs-cro-advisor` β CRO is co-owner of policy\n- `c-level-advisor/cs-cfo-advisor` β CFO is co-owner of policy\n- `ra-qm-team/soc2-compliance-expert` β policy compliance is audit-relevant evidence","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/commercial-policy","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/commercial-policy/SKILL.md","defaultBranch":"main"},"readme":"# Commercial Policy\n\nEnd-to-end commercial-policy authoring and governance: defining the rules that govern what sales can offer, what triggers approval, and what's prohibited. Pairs with our deal-desk (operational enforcement) and pricing-strategy (price-setting) skills β this is the policy that those execute against.\n\nA good commercial policy:\n- Makes deal-desk faster (fewer ambiguous cases)\n- Makes sales reps more autonomous (clearer authority)\n- Makes legal reviews lighter (most cases already covered)\n- Reduces concession drift over time\n- Provides audit-ready governance documentation\n\n---\n\n## When to use this skill\n\n| Situation | Skill applies |\n|-----------|---------------|\n| Authoring commercial policy from scratch | Yes β start with **policy charter template** + `scripts/commercial_policy_generator.py` |\n| Refreshing an existing policy (annual) | Yes β see **annual policy review** workflow |\n| Auditing recent deals for policy compliance | Yes β `scripts/policy_compliance_checker.py` |\n| Analyzing terms-deviation patterns | Yes β `scripts/terms_deviation_analyzer.py` |\n| Tailoring policy for new region / vertical | Yes β `scripts/commercial_policy_generator.py --region ` |\n| Drafting sales training on policy | Yes β see **training section** |\n| Setting prices (not policy on deviations) | Use `business-growth/pricing-strategy` |\n| Per-deal approval | Use `business-growth/deal-desk` |\n| Writing the specific contract | Use `business-growth/contract-and-proposal-writer` |\n\n---\n\n## What commercial policy covers\n\nStandard scope:\n\n| Domain | Policy area |\n|--------|-------------|\n| **Pricing** | Standard pricing, discount thresholds, MFN, rebates, custom-bundle pricing |\n| **Contract** | Standard term length, payment terms, renewal terms, termination, customer audit rights |\n| **Legal** | Acceptable MSA modifications, liability cap, indemnification, jurisdiction, IP |\n| **Operational** | SLA tiers, custom SLAs, security commitments, dedicated infrastructure |\n| **Customer commitments** | Reference / case study / press release obligations |\n| **Channel** | Partner discount tiers, channel-conflict rules, deal-registration |\n| **Special terms** | Performance-based payment, acceptance criteria, ramp deals |\n\nWhat it doesn't cover:\n- Day-to-day pricing decisions (that's pricing strategy)\n- Per-deal approval mechanics (that's deal-desk operations)\n- Sales targets / quota (that's compensation policy)\n- Customer success / churn-prevention tactics\n\n---\n\n## Commercial policy charter (template)\n\nThe foundational document. Every company that does $5M+ ARR needs one. Use this template:\n\n```markdown\n# Commercial Policy Charter\n\n## Purpose\nThis Commercial Policy defines the rules that govern commercial terms\noffered to customers. It is binding on all customer-facing functions\n(Sales, Customer Success, Partner / Channel) and is enforced by Deal Desk.\n\n## Scope\nApplies to:\n- All new customer agreements\n- All renewals (with material change)\n- All partner-mediated deals\n- All custom / non-standard agreements\n\nDoes not apply to:\n- Self-serve / PLG transactions per standard published terms\n- Auto-renewals at standard terms\n\n## Owners and Approvers\n- Policy owner: CRO + CFO + General Counsel (jointly)\n- Operational enforcement: Deal Desk\n- Updates: quarterly review by policy owners\n- Material changes: board awareness\n\n## Pricing Policy\n\n### Standard pricing\n- All new customers offered at published list pricing\n- Published price is canonical; deviations require approval per matrix\n\n### Discount approval matrix\n[Per the deal-desk approval matrix β see business-growth/deal-desk]\n\n### Maximum allowed discount\n- Standard maximum: 50%\n- Beyond 50%: CEO + Board awareness required\n- Discount > 60%: only with explicit strategic-rationale documented and CEO sign-off\n\n### Most Favored Nation (MFN)\n- Not granted by default\n- Granted only with: strategic-tier customer + CRO + CFO + GC approval\n- Always scoped narrowly: same product, same volume, same term len","createdAt":"2026-09-25T13:52:02.636Z","updatedAt":"2026-09-25T13:52:02.636Z"},{"id":"cmuh0s8kc03paqu06zf5xqjlw","slug":"borghei-claude-skills-competitive-teardown","name":"competitive-teardown","description":"Systematic competitor analysis covering product teardowns, 12-dimension scoring rubric, feature comparison matrices, SWOT analysis, pricing model deconstruction, UX audits, and strategic action plans with stakeholder presentation templates.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"competitive-teardown","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Systematic competitor analysis covering product teardowns, 12-dimension scoring rubric, feature comparison matrices, SWOT analysis, pricing model deconstruction, UX audits, and strategic action plans with stakeholder presentation templates.","permissions":[],"systemPrompt":"# Competitive Teardown\n\nProduction-grade competitor analysis framework covering systematic data collection across 6 intelligence sources, a 12-dimension scoring rubric, feature comparison matrices, SWOT analysis, pricing model deconstruction, UX audit methodology, and strategic action plans. Produces battle-card-ready output and stakeholder presentation templates.\n\n---\n\n## Table of Contents\n\n- [When to Use](#when-to-use)\n- [Teardown Workflow](#teardown-workflow)\n- [Data Collection Framework](#data-collection-framework)\n- [12-Dimension Scoring Rubric](#12-dimension-scoring-rubric)\n- [Feature Comparison Matrix](#feature-comparison-matrix)\n- [Pricing Analysis Framework](#pricing-analysis-framework)\n- [SWOT Analysis Template](#swot-analysis-template)\n- [UX Audit Methodology](#ux-audit-methodology)\n- [Positioning Map](#positioning-map)\n- [Action Plan Framework](#action-plan-framework)\n- [Battle Card Template](#battle-card-template)\n- [Stakeholder Presentation](#stakeholder-presentation)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## When to Use\n\n| Trigger | Teardown Scope |\n|---------|---------------|\n| Before product strategy or roadmap session | Full teardown (2-4 competitors) |\n| Competitor launches major feature or pricing change | Focused teardown (1 competitor, updated dimensions only) |\n| Quarterly competitive review | Update existing teardowns + trend analysis |\n| Before a sales pitch (battle card needed) | Single-competitor battle card |\n| Entering a new market segment | Full teardown of segment incumbents |\n\n---\n\n## Clarify First\n\nBefore running the teardown, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Competitors + primary focus** β the 2-4 names and which is the main threat (sets scorecard columns and depth)\n- [ ] **Your own product baseline** β so the 12-dimension scorecard and feature matrix have a \"you\" column to compare against\n- [ ] **Decision this feeds** β roadmap session, sales battle card, or new-market entry (determines full teardown vs single battle card vs segment incumbents)\n- [ ] **Available data sources** β pricing pages, 50+ reviews, product access (the rubric needs evidence; thin data caps which dimensions are scorable)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the teardown.\n\n## Teardown Workflow\n\n### Step-by-Step Process\n\n1. **Define competitors** -- List 2-4 competitors. Confirm which is the primary focus.\n2. **Collect data** -- Gather intelligence from at least 3 of the 6 sources per competitor.\n3. **Score using rubric** -- Apply the 12-dimension rubric to produce a numeric scorecard.\n4. **Generate comparison outputs** -- Feature matrix, pricing analysis, SWOT, positioning map.\n5. **Build action plan** -- Translate findings into quick wins, medium-term, and strategic priorities.\n6. **Package for stakeholders** -- Assemble the presentation or battle card.\n\n### Validation Checkpoints\n\n- Before scoring: Confirm you have pricing data, 20+ user reviews, and recent product data\n- Before action plan: Every dimension should have a score and supporting evidence\n- Before presentation: Every recommendation should tie back to a data point\n\n---\n\n## Data Collection Framework\n\n### Source 1: Website and Product Analysis\n\n| Data Point | Where to Find | What It Signals |\n|-----------|--------------|-----------------|\n| Pricing tiers and price points | Pricing page | Market positioning, target segment |\n| Feature lists per tier | Pricing + feature pages | Packaging strategy |\n| Primary CTA and messaging | Homepage hero | Positioning and ICP |\n| Case studies and customer logos | Case study page, homepage | Target segments, social proof |\n| Integration partnerships | Integrations page | Ecosystem strategy |\n| Trust signals | Footer, security page | Enterprise readiness |\n| Job postings | Careers page, LinkedIn | Growth direction, tech stack |\n\n### Source 2: User Reviews\n\n**Platforms:** G2, Capterra, TrustRadius, App Store, Product Hunt\n\n| Category | What to Track | Strategic Value |\n|----------|-------------|-----------------|\n| Praise themes | What users love (top 5 themes) | Their defensible strengths |\n| Complaint themes | What users hate (top 5 themes) | Your opportunities |\n| Feature requests | What users want but do not have | Product roadmap gaps |\n| Switching mentions | Why users left competitors | Competitive migration paths |\n| Rating trends | Quarter-over-quarter rating change | Improving or declining |\n\n**Sample size target:** 50+ reviews per competitor for reliable themes.\n\n### Source 3: Job Postings\n\n| Signal | What It Means |\n|--------|--------------|\n| High engineering hiring | Product investment, scaling |\n| AI/ML roles | AI features coming |\n| Sales team expansion | Moving upmarket or expanding geographically |\n| Customer success roles | Retention focus, enterprise motion |\n| Compliance/legal roles | Regulatory expansion |\n| Reduced postings | Cost cutting, potential contraction |\n\n### Source 4: SEO and Content Analysis\n\n| Metric | Tool | Strategic Value |\n|--------|------|-----------------|\n| Top 20 organic keywords | Ahrefs, SEMrush, GSC | Content strategy and targeting |\n| Domain authority | Ahrefs, Moz | Brand strength |\n| Blog publishing cadence | Manual check | Content investment level |\n| Ranking pages (product vs blog vs docs) | Ahrefs | Traffic composition |\n\n### Source 5: Social Media and Community\n\n| Platform | What to Track |\n|----------|-------------|\n| Twitter/X | Product announcements, customer praise, complaints |\n| Reddit | Honest reviews, comparison threads |\n| LinkedIn | Thought leadership, hiring signals, employee count |\n| Community forums | Feature requests, workarounds, power user patterns |\n| Discord/Slack | Community size, engagement level |\n\n### Source 6: Financial and Market Data\n\n| Source | Data Available |\n|-------|---------------|\n| Crunchbase | Funding, valuation, investors, employee count |\n| LinkedIn | Employee count trend (growth proxy) |\n| Public filings (if public) | Revenue, growth rate, churn |\n| Industry reports | Market share estimates |\n\n---\n\n## 12-Dimension Scoring Rubric\n\nScore each competitor (and your own product) on a 1-5 scale with evidence notes.\n\n| # | Dimension | 1 (Weak) | 3 (Average) | 5 (Best-in-class) |\n|---|-----------|----------|-------------|-------------------|\n| 1 | Features | Core only, many gaps | Solid coverage | Comprehensive + unique capabilities |\n| 2 | Pricing | Confusing or overpriced | Market-rate, clear | Transparent, flexible, fair |\n| 3 | UX / Design | Confusing, high friction | Functional, adequate | Delightful, minimal friction |\n| 4 | Performance | Slow, unreliable | Acceptable | Fast, high uptime, responsive |\n| 5 | Documentation | Sparse, outdated | Decent coverage | Comprehensive, searchable, with examples |\n| 6 | Support | Email only, slow response | Chat + email, reasonable SLA | 24/7, multiple channels, fast |\n| 7 | Integrations | 0-5 native integrations | 6-25 integrations | 26+ or deep ecosystem (API + marketplace) |\n| 8 | Security | No mentions | SOC2 claimed | SOC2 Type II + ISO 27001 + GDPR |\n| 9 | Scalability | No enterprise tier | Mid-market ready | Enterprise-grade (SSO, SCIM, SLA) |\n| 10 | Brand | Generic, unmemorable | Decent positioning | Strong, differentiated, recognized |\n| 11 | Community | None | Forum or Slack exists | Active, vibrant, user-generated content |\n| 12 | Innovation | No releases in 6+ months | Quarterly releases | Frequent, meaningful, well-communicated |\n\n### Scoring Output Format\n\n| Dimension | Your Product | Competitor A | Competitor B | Competitor C |\n|-----------|-------------|-------------|-------------|-------------|\n| Features | 4 | 3 | 5 | 3 |\n| Pricing | 3 | 4 | 3 | 4 |\n| ... | ... | ... | ... | ... |\n| **Total (/60)** | **38** | **35** | **42** | **33** |\n\n---\n\n## Feature Comparison Matrix\n\n### Matrix Structure\n\n| Feature Category | Your Product | Competitor A | Competitor B | Notes |\n|-----------------|-------------|-------------|-------------|-------|\n| **Core Features** | | | | |\n| Feature 1 | Full | Full | Partial | Comp B lacks [specific capability] |\n| Feature 2 | Full | Missing | Full | Our differentiator |\n| Feature 3 | Partial | Full | Full | Gap to close |\n| **Platform** | | | | |\n| Web app | Yes | Yes | Yes | |\n| iOS app | Yes | No | Yes | Comp A gap |\n| API access | Full | Limited | Full | |\n| **Enterprise** | | | | |\n| SSO | Yes | No | Yes | |\n| Audit logs | Yes | Yes | No | |\n| Custom SLA | Yes | Yes | Yes | |\n\n**Score per cell:** Full = 5, Partial = 3, Basic = 2, Missing = 0\n\n---\n\n## Pricing Analysis Framework\n\n### Pricing Model Comparison\n\n| Attribute | Your Product | Competitor A | Competitor B |\n|-----------|-------------|-------------|-------------|\n| Model type | Per seat | Usage-based | Flat rate |\n| Free tier | Yes (3 users) | Yes (limited) | No |\n| Entry price | $15/user/mo | $29/mo (up to 1K events) | $49/mo |\n| Mid-tier price | $35/user/mo | $99/mo | $99/mo |\n| Enterprise | Custom | Custom | $249/mo |\n| Annual discount | 20% | 15% | 2 months free |\n| Trial | 14-day free | 7-day free | 30-day money-back |\n\n### Pricing Position Map\n\n| Position | Characteristic | Your Strategy |\n|----------|---------------|---------------|\n| Price leader | Lowest price, may signal lower quality | Win on value, not features |\n| Value leader | Best features-per-dollar ratio | Win on differentiation |\n| Premium | Highest price, justified by brand/features | Win on exclusivity and support |\n| Disruptor | Radically different model (free, usage-based) | Win on accessibility |\n\n---\n\n## SWOT Analysis Template\n\nFor each competitor, produce:\n\n### Competitor SWOT\n\n| Quadrant | Points |\n|----------|--------|\n| **Strengths** (Their advantages) | 3-5 bullets, each anchored to a data signal |\n| **Weaknesses** (Their vulnerabilities) | 3-5 bullets, each tied to reviews, missing features, or complaints |\n| **Opportunities for Us** | What their weaknesses create for us |\n| **Threats to Us** | What their strengths mean for our position |\n\n**Evidence rule:** Every bullet must cite the data source (review quote, pricing page, job posting count, feature comparison, etc.).\n\n---\n\n## UX Audit Methodology\n\n### First-Run Experience Audit\n\n| Dimension | What to Measure | How to Score |\n|-----------|----------------|--------------|\n| Time to first value (TTFV) | Minutes from signup to first meaningful output | < 5 min = 5, 5-15 min = 3, > 15 min = 1 |\n| Steps to activation | Number of screens/actions before core value | < 3 = 5, 3-7 = 3, > 7 = 1 |\n| Credit card required | Required at signup? | No = 5, Optional = 3, Required = 1 |\n| Onboarding quality | Wizard, tooltips, empty states | Comprehensive = 5, Basic = 3, None = 1 |\n| SSO available | Google, Microsoft, etc. | Yes = 5, No = 1 |\n\n### Core Workflow Audit\n\nFor the 3 most common workflows, compare:\n\n| Workflow | Steps (Yours) | Steps (Competitor) | Friction Points |\n|----------|-------------|-------------------|-----------------|\n| [Primary workflow] | N | N | Specific UX issues |\n| [Secondary workflow] | N | N | Specific UX issues |\n| [Tertiary workflow] | N | N | Specific UX issues |\n\n---\n\n## Positioning Map\n\n### 2x2 Positioning Map\n\nChoose the two axes most relevant to your market:\n\n| Common Axis Pairs | When to Use |\n|-------------------|-------------|\n| Simple / Complex x Low Price / High Price | General product comparison |\n| SMB / Enterprise x Narrow / Broad Features | Market segment analysis |\n| Self-Serve / Sales-Led x Point Solution / Platform | Go-to-market comparison |\n| Technical / Non-Technical x Niche / Horizontal | Audience analysis |\n\n### Map Template\n\n```\n High Price / Enterprise\n β\n β\n [Competitor B] β [Competitor C]\n β\n Simple ββββββββββββββββββΌβββββββββββββββββββ Complex\n β\n [YOUR PRODUCT] β [Competitor A]\n β\n β\n Low Price / SMB\n```\n\n---\n\n## Action Plan Framework\n\n### Three Horizons\n\n| Horizon | Timeframe | Effort | Examples |\n|---------|-----------|--------|---------|\n| Quick wins | 0-4 weeks | Low | Publish comparison pages, update pricing page, add missing trust badges |\n| Medium-term | 1-3 months | Moderate | Build top-requested integration, improve onboarding TTFV, launch free tier |\n| Strategic | 3-12 months | High | Enter new market segment, build API v2, achieve SOC2 Type II |\n\n### Priority Scoring\n\nFor each action item, score:\n\n| Factor | Weight | Scale |\n|--------|--------|-------|\n| Competitive impact | 40% | How much does this close or widen a gap? |\n| Customer demand | 30% | How many customers/prospects request this? |\n| Implementation effort | 20% | How hard is this to build/execute? |\n| Revenue impact | 10% | Direct revenue contribution? |\n\n---\n\n## Battle Card Template\n\n### One-Page Battle Card\n\n```\nCOMPETITOR: [Name]\nLAST UPDATED: [Date]\nTHREAT LEVEL: [LOW / MEDIUM / HIGH / CRITICAL]\n\nTHEIR POSITIONING: [1 sentence]\nOUR POSITIONING AGAINST THEM: [1 sentence]\n\nWHERE THEY WIN:\n- [Strength 1 with evidence]\n- [Strength 2 with evidence]\n- [Strength 3 with evidence]\n\nWHERE WE WIN:\n- [Advantage 1 with evidence]\n- [Advantage 2 with evidence]\n- [Advantage 3 with evidence]\n\nLANDMINES (questions that expose their weaknesses):\n- \"How does [competitor] handle [weakness area]?\"\n- \"Can you show me [feature they lack]?\"\n- \"What do their customers say about [common complaint]?\"\n\nOBJECTION HANDLING:\n- \"They're cheaper\" β [Response with value framing]\n- \"They have [feature]\" β [Response with alternative/roadmap]\n- \"Everyone uses them\" β [Response with differentiation]\n\nPRICING COMPARISON:\n[Quick comparison table]\n\nCUSTOMER QUOTE:\n\"[Quote from a customer who switched from this competitor to you]\"\n```\n\n---\n\n## Stakeholder Presentation\n\n### 7-Slide Structure\n\n| Slide | Content |\n|-------|---------|\n| 1. Executive Summary | Threat level, top strength, top opportunity, recommended action |\n| 2. Market Position | 2x2 positioning map with all players |\n| 3. Feature Scorecard | 12-dimension scores, total comparison |\n| 4. Pricing Analysis | Pricing comparison table + key pricing insight |\n| 5. UX Comparison | Where they win (3 bullets) vs where we win (3 bullets) |\n| 6. Voice of Customer | Top 3 competitor complaints from reviews (quoted) |\n| 7. Action Plan | Quick wins, medium-term, strategic priorities |\n\n---\n\n## Output Artifacts\n\n| Artifact | Format | Description |\n|----------|--------|-------------|\n| Data Collection Report | Structured notes per source | Raw intelligence organized by source type |\n| 12-Dimension Scorecard | Scored table with evidence | Numeric comparison across all dimensions |\n| Feature Comparison Matrix | Grid table | Feature-by-feature comparison with scoring |\n| Pricing Analysis | Comparison table + position map | Model comparison, tier mapping, positioning |\n| SWOT Analysis | Per-competitor 4-quadrant | Anchored to data signals |\n| UX Audit | Scored checklist | TTFV, steps, friction analysis |\n| Positioning Map | 2x2 diagram | Visual market position |\n| Action Plan | Three-horizon table | Prioritized competitive responses |\n| Battle Card | One-page template | Sales-ready competitive reference |\n| Stakeholder Presentation | 7-slide outline | Executive-ready competitive briefing |\n\n---\n\n## Related Skills\n\n- **competitor-alternatives** -- Use for creating comparison and alternative pages for SEO/marketing. Competitive-teardown provides the intelligence; competitor-alternatives produces the marketing content.\n- **pricing-strategy** -- Use when competitive analysis reveals pricing misalignment. Feed teardown pricing data into pricing-strategy.\n- **page-cro** -- Use for optimizing your comparison or competitor landing pages for conversion.\n- **content-creator** -- Use for writing competitive content (blog posts, comparison guides) based on teardown findings.\n\n---\n\n## Tool Reference\n\n### 1. competitor_scorer.py\n\n**Purpose:** Score competitors across the 12-dimension rubric and generate a numeric comparison scorecard.\n\n```bash\npython scripts/competitor_scorer.py competitor_data.json\npython scripts/competitor_scorer.py competitor_data.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `competitor_data.json` | Yes | JSON file with competitor dimension scores and evidence |\n| `--json` | No | Output results as JSON |\n| `--weights` | No | Custom dimension weights as JSON string (default: equal weights) |\n\n### 2. feature_matrix_builder.py\n\n**Purpose:** Build a feature comparison matrix from structured feature data and calculate coverage scores.\n\n```bash\npython scripts/feature_matrix_builder.py features.json\npython scripts/feature_matrix_builder.py features.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `features.json` | Yes | JSON file with feature comparison data |\n| `--json` | No | Output results as JSON |\n\n### 3. battle_card_generator.py\n\n**Purpose:** Generate a one-page battle card from competitor data for sales team use.\n\n```bash\npython scripts/battle_card_generator.py competitor_profile.json\npython scripts/battle_card_generator.py competitor_profile.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `competitor_profile.json` | Yes | JSON file with competitor profile data |\n| `--json` | No | Output results as JSON |\n| `--format` | No | Output format: text (default) or markdown |\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Solution |\n|---------|-------------|----------|\n| Scoring feels subjective across analysts | No shared rubric calibration | Use the 12-dimension rubric with explicit 1/3/5 definitions; have two analysts score independently and reconcile |\n| Data is stale within weeks of teardown | Fast-moving competitors | Set calendar reminders for monthly pricing checks and quarterly full refreshes; use competitor_scorer.py to track score changes over time |\n| Feature matrix has too many rows to be useful | Trying to capture every micro-feature | Group features into 8-12 categories; detail only the top differentiators |\n| Battle cards are not used by sales | Too long, too academic, or not actionable | Keep to one page; lead with \"Where We Win\" and \"Landmines\"; validate with 3 sales reps before distributing |\n| Review data is contradictory | Small sample size or selection bias | Target 50+ reviews per competitor across G2, Capterra, and TrustRadius; weight recent reviews more heavily |\n| Cannot get pricing data for enterprise tiers | Custom pricing not published | Use sales intel (request a demo), G2 pricing data, or customer interviews for directional estimates |\n| SWOT analysis has no actionable output | Analysis lacks connection to action plan | Every SWOT bullet must map to a specific quick-win, medium-term, or strategic action |\n\n---\n\n## Success Criteria\n\n- 12-dimension scorecard completed with evidence notes for every score\n- Feature matrix covers at least 80% of features that prospects evaluate\n- Battle cards reviewed and approved by 3+ sales representatives\n- Pricing data verified within the last 30 days\n- Teardown produces at least 3 actionable quick wins and 2 strategic priorities\n- Stakeholder presentation reviewed and feedback incorporated within 1 week\n- Teardown data refreshed quarterly with score trend tracking\n\n---\n\n## Scope & Limitations\n\n- **In scope:** Product analysis, feature comparison, pricing deconstruction, UX audit, SWOT analysis, battle card creation, action plan generation\n- **Out of scope:** Primary market research (customer interviews, surveys), financial modeling, legal competitive analysis, intellectual property assessment\n- **Data dependency:** Quality depends on publicly available data, user reviews, and product access; some competitors may have limited public information\n- **Bias risk:** Teardowns conducted by internal teams may have confirmation bias; consider external validation for high-stakes decisions\n- **Point-in-time:** Teardowns are snapshots; competitors evolve continuously -- schedule regular refreshes\n\n---\n\n## Integration Points\n\n- **competitor-alternatives** -- Teardown provides the data; competitor-alternatives produces the marketing content (comparison and alternative pages)\n- **pricing-strategy** -- When teardown reveals pricing misalignment, feed pricing data into pricing-strategy for repositioning analysis\n- **page-cro** -- Use for optimizing your comparison or competitor landing pages for conversion after teardown produces the content\n- **sales-engineer** -- Battle cards feed directly into sales engineering competitive positioning and RFP responses\n- **customer-success-manager** -- When exit surveys reveal COMPETITOR as a top churn reason, use teardown data to understand what competitors offer that you do not","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/competitive-teardown","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/competitive-teardown/SKILL.md","defaultBranch":"main"},"readme":"# Competitive Teardown\n\nProduction-grade competitor analysis framework covering systematic data collection across 6 intelligence sources, a 12-dimension scoring rubric, feature comparison matrices, SWOT analysis, pricing model deconstruction, UX audit methodology, and strategic action plans. Produces battle-card-ready output and stakeholder presentation templates.\n\n---\n\n## Table of Contents\n\n- [When to Use](#when-to-use)\n- [Teardown Workflow](#teardown-workflow)\n- [Data Collection Framework](#data-collection-framework)\n- [12-Dimension Scoring Rubric](#12-dimension-scoring-rubric)\n- [Feature Comparison Matrix](#feature-comparison-matrix)\n- [Pricing Analysis Framework](#pricing-analysis-framework)\n- [SWOT Analysis Template](#swot-analysis-template)\n- [UX Audit Methodology](#ux-audit-methodology)\n- [Positioning Map](#positioning-map)\n- [Action Plan Framework](#action-plan-framework)\n- [Battle Card Template](#battle-card-template)\n- [Stakeholder Presentation](#stakeholder-presentation)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## When to Use\n\n| Trigger | Teardown Scope |\n|---------|---------------|\n| Before product strategy or roadmap session | Full teardown (2-4 competitors) |\n| Competitor launches major feature or pricing change | Focused teardown (1 competitor, updated dimensions only) |\n| Quarterly competitive review | Update existing teardowns + trend analysis |\n| Before a sales pitch (battle card needed) | Single-competitor battle card |\n| Entering a new market segment | Full teardown of segment incumbents |\n\n---\n\n## Clarify First\n\nBefore running the teardown, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Competitors + primary focus** β the 2-4 names and which is the main threat (sets scorecard columns and depth)\n- [ ] **Your own product baseline** β so the 12-dimension scorecard and feature matrix have a \"you\" column to compare against\n- [ ] **Decision this feeds** β roadmap session, sales battle card, or new-market entry (determines full teardown vs single battle card vs segment incumbents)\n- [ ] **Available data sources** β pricing pages, 50+ reviews, product access (the rubric needs evidence; thin data caps which dimensions are scorable)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the teardown.\n\n## Teardown Workflow\n\n### Step-by-Step Process\n\n1. **Define competitors** -- List 2-4 competitors. Confirm which is the primary focus.\n2. **Collect data** -- Gather intelligence from at least 3 of the 6 sources per competitor.\n3. **Score using rubric** -- Apply the 12-dimension rubric to produce a numeric scorecard.\n4. **Generate comparison outputs** -- Feature matrix, pricing analysis, SWOT, positioning map.\n5. **Build action plan** -- Translate findings into quick wins, medium-term, and strategic priorities.\n6. **Package for stakeholders** -- Assemble the presentation or battle card.\n\n### Validation Checkpoints\n\n- Before scoring: Confirm you have pricing data, 20+ user reviews, and recent product data\n- Before action plan: Every dimension should have a score and supporting evidence\n- Before presentation: Every recommendation should tie back to a data point\n\n---\n\n## Data Collection Framework\n\n### Source 1: Website and Product Analysis\n\n| Data Point | Where to Find | What It Signals |\n|-----------|--------------|-----------------|\n| Pricing tiers and price points | Pricing page | Market positioning, target segment |\n| Feature lists per tier | Pricing + feature pages | Packaging strategy |\n| Primary CTA and messaging | Homepage hero | Positioning and ICP |\n| Case studies and customer logos | Case study page, homepage | Target segments, social proof |\n| Integration partnerships | Integrations page | Ecosystem strategy |\n| Trust signals | Footer, security page | Enterprise readiness |\n| Job postings | Careers page, LinkedIn | Growth direction, tech stack |\n\n### Sour","createdAt":"2026-09-25T13:52:02.653Z","updatedAt":"2026-09-25T13:52:02.653Z"},{"id":"cmuh0s8ku03pgqu06clxdps6e","slug":"borghei-claude-skills-competitor-alternatives","name":"competitor-alternatives","description":"Create competitor comparison and alternative pages for SEO and sales enablement. Use when building alternative pages, vs pages, or competitor-vs-competitor pages, planning comparison content, or managing competitor data.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"competitor-alternatives","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Create competitor comparison and alternative pages for SEO and sales enablement. Use when building alternative pages, vs pages, or competitor-vs-competitor pages, planning comparison content, or managing competitor data.","permissions":[],"systemPrompt":"# Competitor & Alternative Pages\n\nProduction-grade framework for creating competitor comparison and alternative pages. Covers 4 page formats, centralized competitor data architecture, deep research methodology, SEO optimization, content templates, and ongoing maintenance strategy. Designed for both SEO traffic capture and sales enablement.\n\n---\n\n## Table of Contents\n\n- [When to Use](#when-to-use)\n- [Core Principles](#core-principles)\n- [The 4 Page Formats](#the-4-page-formats)\n- [Content Architecture](#content-architecture)\n- [Research Methodology](#research-methodology)\n- [Essential Content Sections](#essential-content-sections)\n- [SEO Strategy](#seo-strategy)\n- [Maintenance and Updates](#maintenance-and-updates)\n- [Quality Standards](#quality-standards)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## When to Use\n\n| Trigger | Action |\n|---------|--------|\n| Prospects comparing you to competitors | Create vs-pages for top 3 competitors |\n| Search volume exists for \"[competitor] alternative\" | Create singular alternative pages |\n| Sales team needs battle card content | Create vs-pages with objection handling |\n| Competitor has comparison pages about you | Create counter-comparison pages |\n| SEO gap on competitor-branded keywords | Build full alternative page set |\n\n---\n\n## Clarify First\n\nBefore writing the comparison content, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Page format** β singular alternative, plural alternatives, you-vs-competitor, or competitor-vs-competitor (selects the page structure template)\n- [ ] **Primary goal** β SEO traffic capture vs sales enablement (changes tone, depth, and whether to include objection handling)\n- [ ] **Target competitor + data freshness** β who, and how recent the pricing/feature data is (every claim must be verifiable)\n- [ ] **Honest positioning** β who you genuinely win for and who the competitor wins for (drives the trust-building \"who it's for\" sections)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the page.\n\n## Core Principles\n\n### 1. Honesty Builds Trust\n- Acknowledge competitor strengths explicitly\n- Be accurate about your own limitations\n- Readers are actively comparing -- they will verify your claims\n- A dishonest comparison page damages your brand more than no page at all\n\n### 2. Help Them Decide (Not Just Sell)\n- Different tools genuinely fit different needs\n- Be explicit about who you are best for AND who the competitor is best for\n- Reduce evaluation friction -- save prospects research time\n\n### 3. Depth Over Checkbox Tables\n- Go beyond feature checklists (every competitor does those)\n- Explain WHY differences matter for specific use cases\n- Include real scenarios and workflows\n- Show, do not just tell\n\n### 4. Single Source of Truth\n- Centralize competitor data -- do not maintain facts across 10 pages\n- Updates propagate to all pages automatically\n- Track last-verified date per data point\n\n---\n\n## The 4 Page Formats\n\n### Format 1: [Competitor] Alternative (Singular)\n\n**Intent:** User is actively looking to switch FROM a specific competitor.\n\n**URL:** `/alternatives/[competitor]` or `/[competitor]-alternative`\n\n**Keywords:** \"[Competitor] alternative\", \"alternative to [Competitor]\", \"switch from [Competitor]\"\n\n**Page Structure:**\n\n```\n1. Why people look for alternatives (validate their pain, 2-3 paragraphs)\n2. TL;DR: You as the alternative (quick positioning, 3-4 bullets)\n3. Detailed comparison (features, pricing, support -- paragraph format, not just tables)\n4. Who should switch (and who should NOT -- be honest)\n5. Migration path (what transfers, what needs reconfiguration)\n6. Testimonials from customers who switched\n7. CTA: Start free trial or request demo\n```\n\n### Format 2: [Competitor] Alternatives (Plural)\n\n**Intent:** User is researching options broadly, earlier in the buying journey.\n\n**URL:** `/alternatives/[competitor]-alternatives` or `/best-[competitor]-alternatives`\n\n**Keywords:** \"[Competitor] alternatives\", \"best [Competitor] alternatives\", \"tools like [Competitor]\"\n\n**Page Structure:**\n\n```\n1. Why people look for alternatives (common pain points, 2-3 paragraphs)\n2. What to look for in an alternative (evaluation criteria framework)\n3. List of 5-7 alternatives (you first, but include real options)\n4. Summary comparison table\n5. Detailed breakdown of each alternative (150-200 words each)\n6. Recommendation by use case (\"Best for [X]: [Tool]\")\n7. CTA\n```\n\n**Important:** Include 5-7 REAL alternatives. Being genuinely helpful ranks better and builds trust.\n\n### Format 3: You vs [Competitor]\n\n**Intent:** User is directly comparing you to a specific competitor.\n\n**URL:** `/vs/[competitor]` or `/compare/[you]-vs-[competitor]`\n\n**Keywords:** \"[You] vs [Competitor]\", \"[Competitor] vs [You]\"\n\n**Page Structure:**\n\n```\n1. TL;DR summary (key differences in 2-3 sentences)\n2. At-a-glance comparison table (8-12 dimensions)\n3. Detailed comparison by category (paragraph format per category):\n - Features\n - Pricing\n - Ease of use / UX\n - Support and documentation\n - Integrations\n - Security and compliance\n4. Who [You] is best for (3-4 bullets)\n5. Who [Competitor] is best for (3-4 bullets -- be honest)\n6. What customers say (testimonials from switchers)\n7. Migration support\n8. CTA\n```\n\n### Format 4: [Competitor A] vs [Competitor B]\n\n**Intent:** User is comparing two competitors (neither is you directly).\n\n**URL:** `/compare/[competitor-a]-vs-[competitor-b]`\n\n**Page Structure:**\n\n```\n1. Overview of both products (neutral, factual)\n2. Comparison by category (same categories as Format 3)\n3. Who each is best for\n4. \"Consider a third option\" (introduce yourself naturally)\n5. Three-way comparison table (both competitors + you)\n6. CTA\n```\n\n**Why this works:** Captures competitor-branded search traffic, positions you as a knowledgeable authority, and introduces you to buyers who might not have considered you.\n\n---\n\n## Content Architecture\n\n### Centralized Competitor Data\n\nCreate a single data file per competitor that feeds all comparison pages.\n\n**Competitor Data Structure:**\n\n```\nCompetitor: [Name]\nLast Verified: [Date]\nWebsite: [URL]\n\nPositioning:\n - Tagline: [Their tagline]\n - Target audience: [Who they target]\n - Primary differentiator: [What they claim is unique]\n\nPricing:\n - Free tier: [Yes/No, details]\n - Entry price: [$X/mo]\n - Mid-tier price: [$X/mo]\n - Enterprise: [Custom / $X/mo]\n - Billing: [Monthly, Annual, Both]\n - Trial: [Length, CC required?]\n\nFeatures:\n - [Category 1]: [Rating 1-5, notes]\n - [Category 2]: [Rating 1-5, notes]\n - [Category 3]: [Rating 1-5, notes]\n\nStrengths:\n - [Strength 1 with evidence]\n - [Strength 2 with evidence]\n\nWeaknesses:\n - [Weakness 1 with evidence source]\n - [Weakness 2 with evidence source]\n\nBest For: [Description of ideal customer]\nNot Ideal For: [Description of poor fit]\n\nCommon Complaints (from reviews):\n - [Complaint 1] (source: G2/Capterra/etc.)\n - [Complaint 2]\n - [Complaint 3]\n\nMigration Notes:\n - Data export: [Available? Format?]\n - API migration: [Available?]\n - Switching time: [Estimated]\n```\n\n---\n\n## Research Methodology\n\n### Deep Research Process\n\nFor each competitor:\n\n1. **Sign up and use the product** -- Create a real account, go through onboarding, test core workflows. There is no substitute for hands-on experience.\n2. **Pricing verification** -- Screenshot current pricing page. Note what is included at each tier. Check for hidden costs.\n3. **Review mining** -- Read 50+ reviews on G2, Capterra, TrustRadius. Categorize into praise themes, complaint themes, and feature requests.\n4. **Customer feedback** -- Talk to your customers who switched from (or to) this competitor. Capture switching reasons and experience quotes.\n5. **Content audit** -- Review their positioning, their comparison pages about you (if any), their changelog, their blog.\n6. **Financial/growth signals** -- Check Crunchbase for funding, LinkedIn for employee count trends, job postings for strategic direction.\n\n### Verification Schedule\n\n| Frequency | What to Verify |\n|-----------|---------------|\n| Monthly | Pricing (check for changes) |\n| Quarterly | Feature set, major product updates |\n| When notified | Customer reports competitor change |\n| Annually | Full refresh of all competitor data |\n\n---\n\n## Essential Content Sections\n\n### TL;DR Summary\n\nEvery comparison page starts with a 2-3 sentence summary for scanners. This is the most-read section.\n\n**Template:** \"[Your product] is the better choice if you need [differentiator 1] and [differentiator 2]. [Competitor] is better if [their strength]. The biggest differences are [difference 1] and [difference 2].\"\n\n### Paragraph Comparisons (Not Just Tables)\n\nFor each comparison dimension, write a paragraph explaining:\n- How each product handles this area\n- Why the differences matter\n- Who the difference matters most to\n\n**Tables complement paragraphs. They do not replace them.**\n\n### Pricing Comparison\n\nInclude:\n- Tier-by-tier price comparison\n- What is included at each tier (not just the name)\n- Hidden costs (setup fees, overage charges, add-on pricing)\n- Total cost calculation for a sample team size (e.g., \"For a team of 10\")\n\n### Who It Is For\n\nBe explicit about ideal customer for each option:\n\n| Product | Best For | Not Ideal For |\n|---------|----------|---------------|\n| Your product | [Specific persona/use case] | [Honest admission of limitations] |\n| Competitor | [Specific persona/use case] | [Their documented weaknesses] |\n\n### Migration Section\n\n| Element | Content |\n|---------|---------|\n| What transfers | Data, settings, integrations that migrate |\n| What needs reconfiguration | What must be set up fresh |\n| Support offered | Migration assistance, documentation |\n| Estimated time | \"Most teams migrate in [timeframe]\" |\n| Customer quote | Quote from someone who switched |\n\n---\n\n## SEO Strategy\n\n### Keyword Targeting\n\n| Format | Primary Keywords | Secondary Keywords |\n|--------|-----------------|-------------------|\n| Singular alternative | \"[Competitor] alternative\" | \"switch from [Competitor]\", \"replace [Competitor]\" |\n| Plural alternatives | \"[Competitor] alternatives\" | \"best [Competitor] alternatives\", \"tools like [Competitor]\" |\n| Vs page | \"[You] vs [Competitor]\" | \"[Competitor] vs [You]\", \"[You] or [Competitor]\" |\n| Competitor vs competitor | \"[A] vs [B]\" | \"[B] vs [A]\", \"[A] or [B]\" |\n\n### On-Page SEO\n\n- Title tag: \"[Your Product] vs [Competitor]: Detailed Comparison [Year]\"\n- Meta description: Summarize the key difference and who each is best for\n- H1: Match the primary keyword\n- Schema: Consider FAQPage schema for comparison questions\n\n### Internal Linking\n\n- Link between all competitor pages (alternative <-> vs page for same competitor)\n- Link from feature pages to relevant comparisons\n- Link from blog posts mentioning competitors\n- Create a hub page: `/compare/` or `/alternatives/` linking to all comparison content\n\n---\n\n## Maintenance and Updates\n\n### Update Triggers\n\n| Trigger | Action | Priority |\n|---------|--------|----------|\n| Competitor changes pricing | Update pricing comparison on all affected pages | High |\n| Competitor launches major feature | Update feature comparison + add \"Recent Changes\" note | High |\n| Your product launches feature that closes a gap | Update comparison to reflect new advantage | High |\n| New customer switching testimonial | Add to relevant comparison pages | Medium |\n| Quarterly review cycle | Verify all data points, refresh screenshots | Medium |\n\n### Freshness Signals\n\n- Include \"Last updated: [Month Year]\" on every comparison page\n- Update the date only when actual content changes are made\n- Add \"Recent changes\" section at the top when a competitor makes significant updates\n\n---\n\n## Quality Standards\n\n### Legal Safety\n\n- All claims must be verifiable from public sources or customer quotes\n- Do not make claims about competitor uptime, reliability, or security that you cannot verify\n- Use \"at the time of writing\" or \"as of [date]\" for factual claims\n- Do not copy competitor content -- summarize and analyze\n\n### Credibility Rules\n\n- Acknowledge genuine competitor strengths (do not be a hit piece)\n- Include \"Who [Competitor] is best for\" -- this builds trust\n- Use customer quotes from both sides (your customers AND competitor reviews)\n- Cite sources for data claims (review platforms, pricing pages, public reports)\n- Do not use aggressive language or disparaging tone\n\n---\n\n## Output Artifacts\n\n| Artifact | Format | Description |\n|----------|--------|-------------|\n| Competitor Data File | Structured data per competitor | Centralized competitor profile for all pages |\n| Page Set Plan | Prioritized list | Which pages to build first, with target keywords and estimated search volume |\n| Alternative Page (Singular) | Full page copy | Complete page with all sections |\n| Vs Page | Full page copy | Comparison page with table and narrative sections |\n| Alternatives Page (Plural) | Full page copy | Multi-competitor roundup page |\n| Migration Guide | Reusable content block | Migration copy for inclusion across pages |\n| Hub Page | Linked index | Central page linking to all comparison content |\n\n---\n\n## Related Skills\n\n- **competitive-teardown** -- Use for deep competitive intelligence BEFORE creating pages. Teardown provides the data; this skill produces the content.\n- **seo-audit** -- Use to validate comparison pages meet on-page SEO requirements before publishing.\n- **page-cro** -- Use for optimizing comparison page conversion rates (CTA placement, social proof, layout).\n- **content-creator** -- Use for writing supporting competitive blog content based on comparison data.\n- **programmatic-seo** -- Use when you have 10+ competitors and want to generate comparison pages at scale using templates.\n\n---\n\n## Tool Reference\n\n### 1. comparison_page_planner.py\n\n**Purpose:** Generate a prioritized comparison page plan from competitor data with keyword targets and estimated search volume.\n\n```bash\npython scripts/comparison_page_planner.py competitors.json\npython scripts/comparison_page_planner.py competitors.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `competitors.json` | Yes | JSON file with competitor names and search volume estimates |\n| `--json` | No | Output results as JSON |\n| `--brand` | No | Your brand name for URL slug generation (default: \"your-product\") |\n\n### 2. competitor_data_tracker.py\n\n**Purpose:** Track and manage centralized competitor data files with staleness detection and update reminders.\n\n```bash\npython scripts/competitor_data_tracker.py competitor_profiles/\npython scripts/competitor_data_tracker.py competitor_profiles/ --json\npython scripts/competitor_data_tracker.py competitor_profiles/ --stale-days 60\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `competitor_profiles/` | Yes | Directory containing competitor profile JSON files |\n| `--json` | No | Output results as JSON |\n| `--stale-days` | No | Number of days before data is considered stale (default: 90) |\n\n### 3. comparison_content_scorer.py\n\n**Purpose:** Score existing comparison page content against quality and SEO best practices.\n\n```bash\npython scripts/comparison_content_scorer.py page_content.json\npython scripts/comparison_content_scorer.py page_content.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `page_content.json` | Yes | JSON file with comparison page content and metadata |\n| `--json` | No | Output results as JSON |\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Solution |\n|---------|-------------|----------|\n| Comparison pages not ranking for target keywords | Thin content or poor on-page SEO | Add 1500+ words of paragraph content (not just tables); ensure H1 matches primary keyword; add FAQ with schema markup |\n| Pages rank but do not convert | Missing CTA or weak value proposition | Add CTA after every major section; include migration section and risk reversal (free trial, no CC); use comparison_content_scorer.py to audit |\n| Competitor data becomes outdated quickly | No update process in place | Use competitor_data_tracker.py with --stale-days 30 for pricing, 90 for features; assign ownership for monthly checks |\n| Sales team does not use comparison content | Pages are too marketing-focused | Create sales-specific versions with objection handling, landmine questions, and talk tracks; test with 3 reps before publishing |\n| Legal pushback on competitor claims | Unverifiable or aggressive claims | Cite public sources for every claim; use \"as of [date]\" qualifiers; acknowledge competitor strengths honestly |\n| Too many competitors to cover | Trying to create pages for every competitor | Prioritize using comparison_page_planner.py; start with top 3-5 competitors by search volume and deal frequency |\n\n---\n\n## Success Criteria\n\n- Comparison pages ranking on page 1 for \"[competitor] alternative\" within 6 months\n- Each comparison page converts at 3%+ (visitor to CTA click)\n- All competitor data verified within the last 90 days (use competitor_data_tracker.py)\n- Pages include honest \"Who [Competitor] is best for\" section (builds trust, reduces bounce)\n- At least 1 customer testimonial from a switcher per comparison page\n- Hub page links to all comparison content with clear navigation\n- Quarterly content refresh with \"Last updated\" date on every page\n\n---\n\n## Scope & Limitations\n\n- **In scope:** Comparison page content strategy, SEO optimization, competitor data management, content quality scoring, page planning and prioritization\n- **Out of scope:** Primary competitive intelligence gathering (use competitive-teardown), paid advertising strategy, design/development of pages\n- **Legal constraint:** All claims must be verifiable from public sources; avoid disparaging competitors; include \"as of [date]\" for factual claims\n- **SEO timeline:** Comparison pages typically take 3-6 months to rank; plan for long-term investment\n- **Maintenance cost:** Each competitor page requires ongoing updates; budget for quarterly refreshes\n\n---\n\n## Integration Points\n\n- **competitive-teardown** -- Teardown provides the raw competitive intelligence; this skill transforms it into marketing content\n- **page-cro** -- Use for optimizing comparison page conversion rates after content is published\n- **seo-audit** -- Use to validate comparison pages meet technical SEO requirements before publishing\n- **content-creator** -- Use for writing supporting blog content (competitor comparison blog posts, switching guides)\n- **customer-success-manager** -- When customers mention competitor evaluation, comparison pages can be shared proactively","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/competitor-alternatives","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/competitor-alternatives/SKILL.md","defaultBranch":"main"},"readme":"# Competitor & Alternative Pages\n\nProduction-grade framework for creating competitor comparison and alternative pages. Covers 4 page formats, centralized competitor data architecture, deep research methodology, SEO optimization, content templates, and ongoing maintenance strategy. Designed for both SEO traffic capture and sales enablement.\n\n---\n\n## Table of Contents\n\n- [When to Use](#when-to-use)\n- [Core Principles](#core-principles)\n- [The 4 Page Formats](#the-4-page-formats)\n- [Content Architecture](#content-architecture)\n- [Research Methodology](#research-methodology)\n- [Essential Content Sections](#essential-content-sections)\n- [SEO Strategy](#seo-strategy)\n- [Maintenance and Updates](#maintenance-and-updates)\n- [Quality Standards](#quality-standards)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## When to Use\n\n| Trigger | Action |\n|---------|--------|\n| Prospects comparing you to competitors | Create vs-pages for top 3 competitors |\n| Search volume exists for \"[competitor] alternative\" | Create singular alternative pages |\n| Sales team needs battle card content | Create vs-pages with objection handling |\n| Competitor has comparison pages about you | Create counter-comparison pages |\n| SEO gap on competitor-branded keywords | Build full alternative page set |\n\n---\n\n## Clarify First\n\nBefore writing the comparison content, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Page format** β singular alternative, plural alternatives, you-vs-competitor, or competitor-vs-competitor (selects the page structure template)\n- [ ] **Primary goal** β SEO traffic capture vs sales enablement (changes tone, depth, and whether to include objection handling)\n- [ ] **Target competitor + data freshness** β who, and how recent the pricing/feature data is (every claim must be verifiable)\n- [ ] **Honest positioning** β who you genuinely win for and who the competitor wins for (drives the trust-building \"who it's for\" sections)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the page.\n\n## Core Principles\n\n### 1. Honesty Builds Trust\n- Acknowledge competitor strengths explicitly\n- Be accurate about your own limitations\n- Readers are actively comparing -- they will verify your claims\n- A dishonest comparison page damages your brand more than no page at all\n\n### 2. Help Them Decide (Not Just Sell)\n- Different tools genuinely fit different needs\n- Be explicit about who you are best for AND who the competitor is best for\n- Reduce evaluation friction -- save prospects research time\n\n### 3. Depth Over Checkbox Tables\n- Go beyond feature checklists (every competitor does those)\n- Explain WHY differences matter for specific use cases\n- Include real scenarios and workflows\n- Show, do not just tell\n\n### 4. Single Source of Truth\n- Centralize competitor data -- do not maintain facts across 10 pages\n- Updates propagate to all pages automatically\n- Track last-verified date per data point\n\n---\n\n## The 4 Page Formats\n\n### Format 1: [Competitor] Alternative (Singular)\n\n**Intent:** User is actively looking to switch FROM a specific competitor.\n\n**URL:** `/alternatives/[competitor]` or `/[competitor]-alternative`\n\n**Keywords:** \"[Competitor] alternative\", \"alternative to [Competitor]\", \"switch from [Competitor]\"\n\n**Page Structure:**\n\n```\n1. Why people look for alternatives (validate their pain, 2-3 paragraphs)\n2. TL;DR: You as the alternative (quick positioning, 3-4 bullets)\n3. Detailed comparison (features, pricing, support -- paragraph format, not just tables)\n4. Who should switch (and who should NOT -- be honest)\n5. Migration path (what transfers, what needs reconfiguration)\n6. Testimonials from customers who switched\n7. CTA: Start free trial or request demo\n```\n\n### Format 2: [Competitor] Alternatives (Plural)\n\n**Intent:** User is researching options broadly, earlier in the buying journey.\n\n**URL:** `/alter","createdAt":"2026-09-25T13:52:02.670Z","updatedAt":"2026-09-25T13:52:02.670Z"},{"id":"cmuh0s8lp03psqu069tjnnoy7","slug":"borghei-claude-skills-customer-success-manager","name":"customer-success-manager","description":"Monitors customer health, predicts churn risk, and identifies expansion opportunities using weighted scoring models for SaaS customer success","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"customer-success-manager","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Monitors customer health, predicts churn risk, and identifies expansion opportunities using weighted scoring models for SaaS customer success","permissions":[],"systemPrompt":"# Customer Success Manager\n\nProduction-grade customer success analytics with multi-dimensional health scoring, churn risk prediction, and expansion opportunity identification. Three Python CLI tools provide deterministic, repeatable analysis using standard library only -- no external dependencies, no API calls, no ML models.\n\n---\n\n## Table of Contents\n\n- [Capabilities](#capabilities)\n- [Input Requirements](#input-requirements)\n- [Output Formats](#output-formats)\n- [How to Use](#how-to-use)\n- [Scripts](#scripts)\n- [Reference Guides](#reference-guides)\n- [Templates](#templates)\n- [Best Practices](#best-practices)\n- [Limitations](#limitations)\n\n---\n\n## Capabilities\n\n- **Customer Health Scoring**: Multi-dimensional weighted scoring across usage, engagement, support, and relationship dimensions with Red/Yellow/Green classification\n- **Churn Risk Analysis**: Behavioral signal detection with tier-based intervention playbooks and time-to-renewal urgency multipliers\n- **Expansion Opportunity Scoring**: Adoption depth analysis, whitespace mapping, and revenue opportunity estimation with effort-vs-impact prioritization\n- **Segment-Aware Benchmarking**: Configurable thresholds for Enterprise, Mid-Market, and SMB customer segments\n- **Trend Analysis**: Period-over-period comparison to detect improving or declining trajectories\n- **Executive Reporting**: QBR templates, success plans, and executive business review templates\n\n---\n\n## Input Requirements\n\nAll scripts accept a JSON file as positional input argument. See `assets/sample_customer_data.json` for complete examples.\n\n### Health Score Calculator\n\n```json\n{\n \"customers\": [\n {\n \"customer_id\": \"CUST-001\",\n \"name\": \"Acme Corp\",\n \"segment\": \"enterprise\",\n \"arr\": 120000,\n \"usage\": {\n \"login_frequency\": 85,\n \"feature_adoption\": 72,\n \"dau_mau_ratio\": 0.45\n },\n \"engagement\": {\n \"support_ticket_volume\": 3,\n \"meeting_attendance\": 90,\n \"nps_score\": 8,\n \"csat_score\": 4.2\n },\n \"support\": {\n \"open_tickets\": 2,\n \"escalation_rate\": 0.05,\n \"avg_resolution_hours\": 18\n },\n \"relationship\": {\n \"executive_sponsor_engagement\": 80,\n \"multi_threading_depth\": 4,\n \"renewal_sentiment\": \"positive\"\n },\n \"previous_period\": {\n \"usage_score\": 70,\n \"engagement_score\": 65,\n \"support_score\": 75,\n \"relationship_score\": 60\n }\n }\n ]\n}\n```\n\n### Churn Risk Analyzer\n\n```json\n{\n \"customers\": [\n {\n \"customer_id\": \"CUST-001\",\n \"name\": \"Acme Corp\",\n \"segment\": \"enterprise\",\n \"arr\": 120000,\n \"contract_end_date\": \"2026-06-30\",\n \"usage_decline\": {\n \"login_trend\": -15,\n \"feature_adoption_change\": -10,\n \"dau_mau_change\": -0.08\n },\n \"engagement_drop\": {\n \"meeting_cancellations\": 2,\n \"response_time_days\": 5,\n \"nps_change\": -3\n },\n \"support_issues\": {\n \"open_escalations\": 1,\n \"unresolved_critical\": 0,\n \"satisfaction_trend\": \"declining\"\n },\n \"relationship_signals\": {\n \"champion_left\": false,\n \"sponsor_change\": false,\n \"competitor_mentions\": 1\n },\n \"commercial_factors\": {\n \"contract_type\": \"annual\",\n \"pricing_complaints\": false,\n \"budget_cuts_mentioned\": false\n }\n }\n ]\n}\n```\n\n### Expansion Opportunity Scorer\n\n```json\n{\n \"customers\": [\n {\n \"customer_id\": \"CUST-001\",\n \"name\": \"Acme Corp\",\n \"segment\": \"enterprise\",\n \"arr\": 120000,\n \"contract\": {\n \"licensed_seats\": 100,\n \"active_seats\": 95,\n \"plan_tier\": \"professional\",\n \"available_tiers\": [\"professional\", \"enterprise\", \"enterprise_plus\"]\n },\n \"product_usage\": {\n \"core_platform\": {\"adopted\": true, \"usage_pct\": 85},\n \"analytics_module\": {\"adopted\": true, \"usage_pct\": 60},\n \"integrations_module\": {\"adopted\": false, \"usage_pct\": 0},\n \"api_access\": {\"adopted\": true, \"usage_pct\": 40},\n \"advanced_reporting\": {\"adopted\": false, \"usage_pct\": 0}\n },\n \"departments\": {\n \"current\": [\"engineering\", \"product\"],\n \"potential\": [\"marketing\", \"sales\", \"support\"]\n }\n }\n ]\n}\n```\n\n---\n\n## Output Formats\n\nAll scripts support two output formats via the `--format` flag:\n\n- **`text`** (default): Human-readable formatted output for terminal viewing\n- **`json`**: Machine-readable JSON output for integrations and pipelines\n\n---\n\n## Clarify First\n\nBefore running the analysis, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Which analysis** β health score, churn risk, or expansion opportunity (selects which of the three scripts and its input schema)\n- [ ] **Customer segment** β Enterprise / Mid-Market / SMB (segment-aware thresholds change every Red/Yellow/Green and risk-tier cutoff)\n- [ ] **Previous-period data availability** β without it, trend analysis (declining vs improving) cannot run\n- [ ] **Renewal date / contract end** β drives the time-to-renewal urgency multiplier in churn scoring\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the output.\n\n## How to Use\n\n### Quick Start\n\n```bash\n# Health scoring\npython scripts/health_score_calculator.py assets/sample_customer_data.json\npython scripts/health_score_calculator.py assets/sample_customer_data.json --format json\n\n# Churn risk analysis\npython scripts/churn_risk_analyzer.py assets/sample_customer_data.json\npython scripts/churn_risk_analyzer.py assets/sample_customer_data.json --format json\n\n# Expansion opportunity scoring\npython scripts/expansion_opportunity_scorer.py assets/sample_customer_data.json\npython scripts/expansion_opportunity_scorer.py assets/sample_customer_data.json --format json\n```\n\n### Workflow Integration\n\n```bash\n# 1. Score customer health across portfolio\npython scripts/health_score_calculator.py customer_portfolio.json --format json > health_results.json\n\n# 2. Identify at-risk accounts\npython scripts/churn_risk_analyzer.py customer_portfolio.json --format json > risk_results.json\n\n# 3. Find expansion opportunities in healthy accounts\npython scripts/expansion_opportunity_scorer.py customer_portfolio.json --format json > expansion_results.json\n\n# 4. Prepare QBR using templates\n# Reference: assets/qbr_template.md\n```\n\n---\n\n## Scripts\n\n### 1. health_score_calculator.py\n\n**Purpose:** Multi-dimensional customer health scoring with trend analysis and segment-aware benchmarking.\n\n**Dimensions and Weights:**\n| Dimension | Weight | Metrics |\n|-----------|--------|---------|\n| Usage | 30% | Login frequency, feature adoption, DAU/MAU ratio |\n| Engagement | 25% | Support ticket volume, meeting attendance, NPS/CSAT |\n| Support | 20% | Open tickets, escalation rate, avg resolution time |\n| Relationship | 25% | Executive sponsor engagement, multi-threading depth, renewal sentiment |\n\n**Classification:**\n- Green (75-100): Healthy -- customer achieving value\n- Yellow (50-74): Needs attention -- monitor closely\n- Red (0-49): At risk -- immediate intervention required\n\n**Usage:**\n```bash\npython scripts/health_score_calculator.py customer_data.json\npython scripts/health_score_calculator.py customer_data.json --format json\n```\n\n### 2. churn_risk_analyzer.py\n\n**Purpose:** Identify at-risk accounts with behavioral signal detection and tier-based intervention recommendations.\n\n**Risk Signal Weights:**\n| Signal Category | Weight | Indicators |\n|----------------|--------|------------|\n| Usage Decline | 30% | Login trend, feature adoption change, DAU/MAU change |\n| Engagement Drop | 25% | Meeting cancellations, response time, NPS change |\n| Support Issues | 20% | Open escalations, unresolved critical, satisfaction trend |\n| Relationship Signals | 15% | Champion left, sponsor change, competitor mentions |\n| Commercial Factors | 10% | Contract type, pricing complaints, budget cuts |\n\n**Risk Tiers:**\n- Critical (80-100): Immediate executive escalation\n- High (60-79): Urgent CSM intervention\n- Medium (40-59): Proactive outreach\n- Low (0-39): Standard monitoring\n\n**Usage:**\n```bash\npython scripts/churn_risk_analyzer.py customer_data.json\npython scripts/churn_risk_analyzer.py customer_data.json --format json\n```\n\n### 3. expansion_opportunity_scorer.py\n\n**Purpose:** Identify upsell, cross-sell, and expansion opportunities with revenue estimation and priority ranking.\n\n**Expansion Types:**\n- **Upsell**: Upgrade to higher tier or more of existing product\n- **Cross-sell**: Add new product modules\n- **Expansion**: Additional seats or departments\n\n**Usage:**\n```bash\npython scripts/expansion_opportunity_scorer.py customer_data.json\npython scripts/expansion_opportunity_scorer.py customer_data.json --format json\n```\n\n---\n\n## Reference Guides\n\n| Reference | Description |\n|-----------|-------------|\n| `references/health-scoring-framework.md` | Complete health scoring methodology, dimension definitions, weighting rationale, threshold calibration |\n| `references/cs-playbooks.md` | Intervention playbooks for each risk tier, onboarding, renewal, expansion, and escalation procedures |\n| `references/cs-metrics-benchmarks.md` | Industry benchmarks for NRR, GRR, churn rates, health scores, expansion rates by segment and industry |\n\n---\n\n## Templates\n\n| Template | Purpose |\n|----------|---------|\n| `assets/qbr_template.md` | Quarterly Business Review presentation structure |\n| `assets/success_plan_template.md` | Customer success plan with goals, milestones, and metrics |\n| `assets/onboarding_checklist_template.md` | 90-day onboarding checklist with phase gates |\n| `assets/executive_business_review_template.md` | Executive stakeholder review for strategic accounts |\n\n---\n\n## Best Practices\n\n1. **Score regularly**: Run health scoring weekly for Enterprise, bi-weekly for Mid-Market, monthly for SMB\n2. **Act on trends, not snapshots**: A declining Green is more urgent than a stable Yellow\n3. **Combine signals**: Use all three scripts together for a complete customer picture\n4. **Calibrate thresholds**: Adjust segment benchmarks based on your product and industry\n5. **Document interventions**: Track what actions you took and outcomes for playbook refinement\n6. **Prepare with data**: Run scripts before every QBR and executive meeting\n\n---\n\n## Limitations\n\n- **No real-time data**: Scripts analyze point-in-time snapshots from JSON input files\n- **No CRM integration**: Data must be exported manually from your CRM/CS platform\n- **Deterministic only**: No predictive ML -- scoring is algorithmic based on weighted signals\n- **Threshold tuning**: Default thresholds are industry-standard but may need calibration for your business\n- **Revenue estimates**: Expansion revenue estimates are approximations based on usage patterns\n\n---\n\n---\n\n## Tool Reference\n\n### 1. health_score_calculator.py\n\n**Purpose:** Multi-dimensional customer health scoring with trend analysis and segment-aware benchmarking.\n\n```bash\npython scripts/health_score_calculator.py customer_data.json\npython scripts/health_score_calculator.py customer_data.json --format json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `customer_data.json` | Yes | JSON file with customer health data (usage, engagement, support, relationship metrics) |\n| `--format` | No | Output format: text (default) or json |\n\n**Dimensions and Weights:** Usage (30%), Engagement (25%), Support (20%), Relationship (25%)\n\n**Classification:** Green (75-100), Yellow (50-74), Red (0-49) -- thresholds adjust by segment (Enterprise, Mid-Market, SMB)\n\n### 2. churn_risk_analyzer.py\n\n**Purpose:** Identify at-risk accounts with behavioral signal detection and tier-based intervention recommendations.\n\n```bash\npython scripts/churn_risk_analyzer.py customer_data.json\npython scripts/churn_risk_analyzer.py customer_data.json --format json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `customer_data.json` | Yes | JSON file with churn risk signals (usage decline, engagement drop, support issues, relationship signals, commercial factors) |\n| `--format` | No | Output format: text (default) or json |\n\n**Risk Tiers:** Critical (80-100), High (60-79), Medium (40-59), Low (0-39)\n\n**Signal Weights:** Usage Decline (30%), Engagement Drop (25%), Support Issues (20%), Relationship Signals (15%), Commercial Factors (10%)\n\n### 3. expansion_opportunity_scorer.py\n\n**Purpose:** Identify upsell, cross-sell, and expansion opportunities with revenue estimation and priority ranking.\n\n```bash\npython scripts/expansion_opportunity_scorer.py customer_data.json\npython scripts/expansion_opportunity_scorer.py customer_data.json --format json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `customer_data.json` | Yes | JSON file with customer contract, product usage, and department data |\n| `--format` | No | Output format: text (default) or json |\n\n**Expansion Types:** Upsell (tier upgrade), Cross-sell (new modules), Expansion (seats/departments)\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Solution |\n|---------|-------------|----------|\n| Health scores do not correlate with actual churn | Default thresholds do not match your product | Calibrate segment thresholds using historical churn data; compare 90-day retained vs churned cohorts |\n| All accounts show as Yellow | Thresholds too strict or data quality issues | Review input data completeness; adjust benchmarks in health_score_calculator.py constants for your industry |\n| Churn risk scores are uniformly low | Missing key signals (champion left, competitor mentions) | Ensure all signal categories have data; missing data defaults to low risk, which understates actual risk |\n| Expansion scores do not reflect reality | Product usage data is incomplete or stale | Verify product_usage fields cover all modules; run with fresh data exports from your product analytics |\n| Scripts error on input data | JSON format does not match expected schema | Reference the Input Requirements section for exact JSON structure; validate JSON before running |\n| Trend analysis shows no change | Previous period data not provided | Include the previous_period block in health score input for meaningful trend comparison |\n| Intervention recommendations feel generic | Segment is not specified | Always include the segment field (enterprise, mid-market, smb) for segment-appropriate playbooks |\n\n---\n\n## Success Criteria\n\n- Health scores run weekly for Enterprise, bi-weekly for Mid-Market, monthly for SMB accounts\n- Portfolio health distribution: 60%+ Green, less than 15% Red\n- Churn risk critical accounts have executive escalation within 48 hours\n- Expansion pipeline generated covers 20%+ of net retention target\n- Health score trends (improving/declining) drive proactive outreach before renewal window\n- QBR preparation includes health score, risk assessment, and expansion opportunities for every strategic account\n- Intervention playbooks followed for all High and Critical risk accounts\n\n---\n\n## Scope & Limitations\n\n- **In scope:** Customer health scoring, churn risk analysis, expansion opportunity identification, segment benchmarking, trend analysis, QBR preparation\n- **Out of scope:** CRM integration, real-time monitoring, predictive ML modeling, automated outreach\n- **Data dependency:** Scripts analyze point-in-time JSON snapshots; data must be exported manually from your CRM/CS platform\n- **Deterministic scoring:** All analysis is algorithmic based on weighted signals -- no machine learning predictions\n- **Threshold tuning:** Default thresholds are industry-standard benchmarks; calibrate for your specific product and customer base\n- **Revenue estimates:** Expansion revenue estimates are approximations based on usage patterns, not binding forecasts\n\n---\n\n## Integration Points\n\n- **churn-prevention** -- High-risk accounts from churn_risk_analyzer.py should trigger cancel flow optimization and save offer review\n- **revenue-operations** -- Expansion opportunities feed into pipeline forecasting; health scores inform forecast confidence\n- **onboarding-cro** -- When health scores show low usage in early lifecycle, the root cause is often poor activation\n- **pricing-strategy** -- When expansion analysis reveals pricing as a barrier to upsell, feed into pricing-strategy for packaging review\n- **competitive-teardown** -- When churn risk signals include competitor mentions, use teardown data to build counter-positioning\n\n---\n\n**Last Updated:** March 2026\n**Tools:** 3 Python CLI tools\n**Dependencies:** Python 3.7+ standard library only","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/customer-success-manager","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/customer-success-manager/SKILL.md","defaultBranch":"main"},"readme":"# Customer Success Manager\n\nProduction-grade customer success analytics with multi-dimensional health scoring, churn risk prediction, and expansion opportunity identification. Three Python CLI tools provide deterministic, repeatable analysis using standard library only -- no external dependencies, no API calls, no ML models.\n\n---\n\n## Table of Contents\n\n- [Capabilities](#capabilities)\n- [Input Requirements](#input-requirements)\n- [Output Formats](#output-formats)\n- [How to Use](#how-to-use)\n- [Scripts](#scripts)\n- [Reference Guides](#reference-guides)\n- [Templates](#templates)\n- [Best Practices](#best-practices)\n- [Limitations](#limitations)\n\n---\n\n## Capabilities\n\n- **Customer Health Scoring**: Multi-dimensional weighted scoring across usage, engagement, support, and relationship dimensions with Red/Yellow/Green classification\n- **Churn Risk Analysis**: Behavioral signal detection with tier-based intervention playbooks and time-to-renewal urgency multipliers\n- **Expansion Opportunity Scoring**: Adoption depth analysis, whitespace mapping, and revenue opportunity estimation with effort-vs-impact prioritization\n- **Segment-Aware Benchmarking**: Configurable thresholds for Enterprise, Mid-Market, and SMB customer segments\n- **Trend Analysis**: Period-over-period comparison to detect improving or declining trajectories\n- **Executive Reporting**: QBR templates, success plans, and executive business review templates\n\n---\n\n## Input Requirements\n\nAll scripts accept a JSON file as positional input argument. See `assets/sample_customer_data.json` for complete examples.\n\n### Health Score Calculator\n\n```json\n{\n \"customers\": [\n {\n \"customer_id\": \"CUST-001\",\n \"name\": \"Acme Corp\",\n \"segment\": \"enterprise\",\n \"arr\": 120000,\n \"usage\": {\n \"login_frequency\": 85,\n \"feature_adoption\": 72,\n \"dau_mau_ratio\": 0.45\n },\n \"engagement\": {\n \"support_ticket_volume\": 3,\n \"meeting_attendance\": 90,\n \"nps_score\": 8,\n \"csat_score\": 4.2\n },\n \"support\": {\n \"open_tickets\": 2,\n \"escalation_rate\": 0.05,\n \"avg_resolution_hours\": 18\n },\n \"relationship\": {\n \"executive_sponsor_engagement\": 80,\n \"multi_threading_depth\": 4,\n \"renewal_sentiment\": \"positive\"\n },\n \"previous_period\": {\n \"usage_score\": 70,\n \"engagement_score\": 65,\n \"support_score\": 75,\n \"relationship_score\": 60\n }\n }\n ]\n}\n```\n\n### Churn Risk Analyzer\n\n```json\n{\n \"customers\": [\n {\n \"customer_id\": \"CUST-001\",\n \"name\": \"Acme Corp\",\n \"segment\": \"enterprise\",\n \"arr\": 120000,\n \"contract_end_date\": \"2026-06-30\",\n \"usage_decline\": {\n \"login_trend\": -15,\n \"feature_adoption_change\": -10,\n \"dau_mau_change\": -0.08\n },\n \"engagement_drop\": {\n \"meeting_cancellations\": 2,\n \"response_time_days\": 5,\n \"nps_change\": -3\n },\n \"support_issues\": {\n \"open_escalations\": 1,\n \"unresolved_critical\": 0,\n \"satisfaction_trend\": \"declining\"\n },\n \"relationship_signals\": {\n \"champion_left\": false,\n \"sponsor_change\": false,\n \"competitor_mentions\": 1\n },\n \"commercial_factors\": {\n \"contract_type\": \"annual\",\n \"pricing_complaints\": false,\n \"budget_cuts_mentioned\": false\n }\n }\n ]\n}\n```\n\n### Expansion Opportunity Scorer\n\n```json\n{\n \"customers\": [\n {\n \"customer_id\": \"CUST-001\",\n \"name\": \"Acme Corp\",\n \"segment\": \"enterprise\",\n \"arr\": 120000,\n \"contract\": {\n \"licensed_seats\": 100,\n \"active_seats\": 95,\n \"plan_tier\": \"professional\",\n \"available_tiers\": [\"professional\", \"enterprise\", \"enterprise_plus\"]\n },\n \"product_usage\": {\n \"core_platform\": {\"adopted\": true, \"usage_pct\": 85},\n \"analytics_module\": {\"adopted\": true, \"usage_pct\": 60},\n \"integrations_module\": {\"adopted\": false, \"usage_pct\": 0},\n ","createdAt":"2026-09-25T13:52:02.701Z","updatedAt":"2026-09-25T13:52:02.701Z"},{"id":"cmuh0s8ml03q7qu06q9z9p2oz","slug":"borghei-claude-skills-form-cro","name":"form-cro","description":"Form optimization for lead capture, contact, demo request, application, and checkout forms. Covers field-cost analysis, multi-step form design, validation UX, mobile optimization, and A/B testing frameworks.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"form-cro","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Form optimization for lead capture, contact, demo request, application, and checkout forms. Covers field-cost analysis, multi-step form design, validation UX, mobile optimization, and A/B testing frameworks.","permissions":[],"systemPrompt":"# Form CRO\n\nProduction-grade form optimization framework covering field-cost analysis, layout engineering, multi-step form architecture, validation UX patterns, mobile-specific optimization, and structured A/B test design. Applicable to lead capture, contact, demo request, application, survey, and checkout forms. For signup/registration flows, use signup-flow-cro.\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [Field-Cost Analysis Framework](#field-cost-analysis-framework)\n- [Multi-Step vs Single-Step Decision](#multi-step-vs-single-step-decision)\n- [Field Design Patterns](#field-design-patterns)\n- [Validation UX](#validation-ux)\n- [CTA and Submit Button Optimization](#cta-and-submit-button-optimization)\n- [Mobile Form Optimization](#mobile-form-optimization)\n- [Trust and Context Elements](#trust-and-context-elements)\n- [Form Type Playbooks](#form-type-playbooks)\n- [A/B Test Framework](#ab-test-framework)\n- [Metrics and Measurement](#metrics-and-measurement)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore optimizing the form, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Form type** β lead capture, contact, demo, application, or checkout (sets the optimal field count and playbook)\n- [ ] **Current fields + which are used in follow-up** β reveals which fields to cut or enrich (the core of field-cost analysis)\n- [ ] **Current completion rate + where users abandon** β baseline and the specific friction point to target\n- [ ] **Compliance requirements** β GDPR/HIPAA fields that cannot be removed (constrains the field reduction)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the audit.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| What type of form? (lead capture, contact, demo, application, checkout) | Different types have different optimal field counts |\n| How many fields currently? | Establishes baseline friction level |\n| What is the current completion rate? | Benchmark for improvement |\n| Where do users abandon? (if field-level analytics exist) | Identifies the specific friction point |\n| Mobile vs desktop split? | Mobile forms need separate optimization |\n| What happens with submitted data? | Determines which fields are truly necessary |\n| Which fields are actually used in follow-up? | Often reveals 30-50% of fields are never used |\n| Any compliance requirements? (GDPR, HIPAA) | Constrains what can be removed |\n\n---\n\n## Field-Cost Analysis Framework\n\nEvery field has a cost measured in abandonment. The question is not \"what data would be nice to have\" but \"what data is worth the conversion loss.\"\n\n### Field Cost Matrix\n\n| Field Type | Estimated Abandonment Cost | Justification Threshold |\n|-----------|---------------------------|------------------------|\n| Email | Baseline (near zero for gated content) | Always justified for lead forms |\n| First name | +2-3% drop | Justified if personalization drives follow-up |\n| Last name | +2-3% drop | Rarely justified for first touch |\n| Phone number | +5-10% drop | Only if sales will call within 24 hours |\n| Company name | +3-5% drop | Justified for B2B qualification |\n| Company size | +3-5% drop | Justified only if routing decisions depend on it |\n| Job title | +3-5% drop | Can often be enriched post-submission |\n| Industry | +2-3% drop | Can often be enriched post-submission |\n| Message/textarea | +5-8% drop | Justified for contact forms, not for lead capture |\n| Budget | +8-12% drop | Only justified for high-intent demo/sales forms |\n| Custom question | +3-5% per question | Must directly affect lead routing or qualification |\n\n### The Enrichment Test\n\nBefore including any field, ask: **Can this be enriched after submission?**\n\n| Field | Enrichable? | Method | Keep in Form? |\n|-------|------------|--------|---------------|\n| Company name | Yes (from email domain) | Clearbit, Apollo, manual lookup | Remove |\n| Company size | Yes (from company name) | Enrichment API | Remove |\n| Industry | Yes (from company name) | Enrichment API | Remove |\n| Job title | Partially (from LinkedIn) | Manual enrichment | Remove unless critical for routing |\n| Phone number | No | Must be provided | Keep only if sales calls immediately |\n| Budget | No | Must be stated | Keep only for high-intent forms |\n\n### Recommended Field Sets by Form Type\n\n| Form Type | Minimum Fields | Optimal Fields | Maximum Fields |\n|-----------|---------------|----------------|----------------|\n| Newsletter signup | Email | Email | Email + First name |\n| Content download | Email | Email + First name | Email + Name + Company |\n| Contact form | Email + Message | Email + Name + Message | Email + Name + Subject + Message |\n| Demo request | Email + Company | Email + Name + Company + Role | + Phone + Use case + Team size |\n| Application form | Varies by requirement | -- | All required fields (justified individually) |\n\n---\n\n## Multi-Step vs Single-Step Decision\n\n### Decision Criteria\n\n| Factor | Single-Step | Multi-Step |\n|--------|------------|------------|\n| Total fields | < 5 fields | > 5 fields |\n| Field complexity | Simple text inputs | Mix of dropdowns, checkboxes, conditional fields |\n| User motivation | Low-commitment (newsletter, content) | High-commitment (demo, application) |\n| Qualification need | No routing needed | Different paths based on answers |\n| Mobile proportion | < 30% mobile | > 50% mobile |\n\n### Multi-Step Best Practices\n\n**Step structure:**\n- Step 1: Easiest fields (email, name) -- lowest friction to start\n- Step 2: Qualifying information (company, role, use case)\n- Step 3: Specific details (budget, timeline, message)\n\n**Progress indication:**\n- Show progress bar with step count (\"Step 2 of 3\")\n- Show completion percentage\n- Label each step with what it covers (\"Your Details\", \"Company Info\", \"Project Details\")\n\n**Psychological commitment:**\n- Once a user completes Step 1, they are 40-60% more likely to complete the form (sunk cost effect)\n- Capture the email in Step 1 so you can follow up even if they abandon later\n\n**Back navigation:**\n- Always allow users to go back to previous steps\n- Preserve entered data when navigating between steps\n- Never reset the form on back navigation\n\n---\n\n## Field Design Patterns\n\n### Field Labels\n\n| Pattern | When to Use | Example |\n|---------|-------------|---------|\n| Above-field labels | Default for most forms | Label sits above the input |\n| Inline labels (floating) | Space-constrained layouts | Label moves from inside to above on focus |\n| Left-aligned labels | Wide desktop forms | Label to the left of field |\n| Placeholder-only labels | Never | Disappears on input, accessibility failure |\n\n### Field Types\n\n| Data Needed | Best Input Type | Avoid |\n|------------|-----------------|-------|\n| Email | `type=\"email\"` with validation | Plain text input |\n| Phone | `type=\"tel\"` with format mask | Plain text input |\n| Country | Searchable dropdown | Long static dropdown |\n| Company size | Button group (1-10, 11-50, 51-200, 200+) | Free text input |\n| Interest/topic | Checkbox group (max 6 options) | Multi-select dropdown |\n| Message | Textarea (3-4 rows visible) | Single-line text input |\n| Date | Native date picker | Three separate dropdowns |\n\n### Conditional Fields\n\nShow additional fields based on earlier answers. This reduces visible complexity while capturing necessary data.\n\n**Example:** \"What is your primary goal?\" dropdown shows \"Budget range\" only if they select \"Ready to buy\" or \"Evaluating solutions.\"\n\n**Rules:**\n- Conditional fields appear with smooth animation (not instant jump)\n- Only 1-2 conditional fields per trigger\n- Conditional fields are never required (the trigger answer may change)\n\n---\n\n## Validation UX\n\n### Real-Time vs Submit-Time Validation\n\n| Validation Type | When to Use |\n|----------------|-------------|\n| Real-time (on blur) | Email format, phone format, required fields |\n| On submit | Complex validation, server-side checks |\n| Inline suggestions | Company name auto-complete, address lookup |\n\n### Error Message Design\n\n| Pattern | Good | Bad |\n|---------|------|-----|\n| Position | Below the field, in context | Top of form, disconnected |\n| Tone | \"Please enter a valid email address\" | \"Error: Invalid input\" |\n| Specificity | \"Phone must include area code\" | \"Invalid phone number\" |\n| Color | Red text + red border on field | Red banner at top of page |\n| Icon | Error icon next to message | No visual indicator |\n\n### Success Indicators\n\n- Green checkmark on valid fields (especially email and phone)\n- Positive microcopy: \"Looks good!\" on valid email\n- Do NOT flash green/red on every keystroke -- validate on blur (when user leaves the field)\n\n---\n\n## CTA and Submit Button Optimization\n\n### Button Copy Framework\n\n| Form Type | Weak Copy | Strong Copy | Strongest Copy |\n|-----------|-----------|-------------|----------------|\n| Content download | Submit | Download Guide | Get My Free Guide |\n| Demo request | Submit | Request Demo | Schedule My Demo |\n| Contact form | Send | Send Message | Get in Touch |\n| Newsletter | Subscribe | Join Newsletter | Get Weekly Tips |\n| Free trial | Sign Up | Start Free Trial | Start Building Free |\n\n**Rules:**\n- Use first person (\"Get My...\" not \"Get Your...\")\n- Specify what they get, not what they do\n- Include \"Free\" when applicable\n- Keep under 5 words\n\n### Button Design\n\n| Element | Best Practice |\n|---------|---------------|\n| Color | High contrast against form background, consistent with brand CTA color |\n| Size | Full-width on mobile, min 44px height for touch targets |\n| Position | Immediately below last field, no gap |\n| Loading state | Show spinner + \"Sending...\" to prevent double-submit |\n| Disabled state | Disabled until required fields are valid (with clear visual distinction) |\n\n---\n\n## Mobile Form Optimization\n\n### Mobile-Specific Rules\n\n| Rule | Implementation |\n|------|---------------|\n| Touch targets | Minimum 44x44px for all interactive elements |\n| Keyboard types | `type=\"email\"` for email, `type=\"tel\"` for phone, `type=\"number\"` for numeric |\n| Auto-focus | Focus first field on page load (with keyboard open) |\n| Sticky submit | Pin submit button to bottom of viewport on long forms |\n| Input spacing | Minimum 8px between fields to prevent mis-taps |\n| Dropdown alternatives | Use button groups or radio buttons instead of dropdowns on mobile |\n| Auto-fill | Support browser auto-fill for standard fields (name, email, phone, address) |\n\n### Mobile vs Desktop Form Differences\n\n| Aspect | Desktop | Mobile |\n|--------|---------|--------|\n| Layout | 1 or 2 columns | Always 1 column |\n| Field count | Up to 8 | Max 5 per step |\n| Dropdown | Standard dropdown | Bottom sheet or full-screen picker |\n| Help text | Hover tooltips | Always-visible inline text |\n| Validation | On blur | On blur + on submit summary |\n\n---\n\n## Trust and Context Elements\n\n### Trust Signals Near Forms\n\n| Signal | Placement | Impact |\n|--------|-----------|--------|\n| Privacy assurance | Below submit button | \"We'll never share your email\" |\n| Security badges | Next to form container | SSL, SOC2, GDPR compliance |\n| Testimonial | Adjacent to form | Social proof reduces hesitation |\n| Response time | Below submit button | \"We respond within 2 hours\" |\n| Subscriber/user count | Above or within form | \"Join 10,000+ subscribers\" |\n\n### Context Reinforcement\n\n| Element | Purpose | Example |\n|---------|---------|---------|\n| Form header | Remind what they get | \"Get your free SEO audit report\" |\n| Bullet list above form | Reinforce value | \"You'll get: Full site analysis, Priority fix list, 30-min review call\" |\n| Expected next step | Set expectations | \"After submitting, we'll email your report within 24 hours\" |\n\n---\n\n## Form Type Playbooks\n\n### Lead Capture (Gated Content)\n\n**Goal:** Maximize completions while capturing qualified leads.\n- Fields: Email only (or Email + First name maximum)\n- CTA: Value-specific (\"Get My Report\", \"Download Checklist\")\n- Trust: \"No spam, unsubscribe anytime\"\n- Post-submit: Immediate download + thank you page + follow-up email\n\n### Demo Request\n\n**Goal:** Capture qualified prospects ready for sales conversation.\n- Fields: Email + Name + Company (+ Phone and Team size optional)\n- CTA: \"Schedule My Demo\"\n- Trust: \"30-minute call, no commitment\"\n- Post-submit: Calendar booking page or confirmation with scheduling link\n- Consider: Embedded calendar (Calendly/Cal.com) instead of form\n\n### Contact Form\n\n**Goal:** Enable communication while routing to correct team.\n- Fields: Email + Name + Subject dropdown + Message\n- CTA: \"Send Message\"\n- Trust: \"We respond within [X] hours\"\n- Post-submit: Confirmation with expected response time\n- Consider: Adding department/topic routing dropdown\n\n### Quote Request\n\n**Goal:** Capture enough detail for accurate quoting.\n- Fields: Multi-step form with project details\n- CTA: \"Get My Quote\"\n- Trust: \"Free quote, no obligation\"\n- Post-submit: Quote delivery timeline + human follow-up\n\n---\n\n## A/B Test Framework\n\n### High-Impact Tests (Run First)\n\n| Test | Hypothesis | Success Metric |\n|------|-----------|----------------|\n| Remove phone field | Removing phone increases completion by 5-10% | Completion rate |\n| Single-step to multi-step | Multi-step increases completion for 6+ field forms | Completion rate + submission quality |\n| CTA copy change | Value-specific copy increases clicks by 10-20% | Click-through rate |\n| Add social proof | Testimonial near form increases trust | Completion rate |\n\n### Medium-Impact Tests\n\n| Test | Hypothesis | Success Metric |\n|------|-----------|----------------|\n| Field order change | Easiest fields first increases step-1 completion | Step completion rates |\n| Inline validation | Real-time feedback reduces form errors | Error rate + completion rate |\n| Add progress bar | Visual progress on multi-step increases completion | Completion rate |\n| Embedded calendar vs form | Calendar reduces friction for demo requests | Booking rate |\n\n### Measurement Rules\n\n- Run each test for minimum 2 weeks or 200 conversions per variant (whichever is longer)\n- Track both quantity (completion rate) and quality (lead score, SQL rate)\n- A test that increases completions but decreases lead quality is not a win\n\n---\n\n## Metrics and Measurement\n\n### Key Metrics\n\n| Metric | Formula | Benchmark |\n|--------|---------|-----------|\n| Form completion rate | Submissions / Form views | 20-40% for lead forms, 5-15% for long forms |\n| Field-level drop-off | Abandonment per field | Identify the highest-drop field |\n| Time to complete | Avg seconds from first interaction to submit | < 60s for simple forms, < 3min for complex |\n| Error rate | Users who see error / total users | < 10% |\n| Mobile completion rate | Mobile submissions / Mobile form views | Should be within 20% of desktop rate |\n\n### Instrumentation Requirements\n\nTrack these events in your analytics:\n- Form view (impression)\n- Form interaction (first field focus)\n- Per-field completion (on blur, per field)\n- Form submission attempt\n- Form submission success\n- Form validation error (per field)\n\n---\n\n## Output Artifacts\n\n| Artifact | Format | Description |\n|----------|--------|-------------|\n| Form Audit Report | Issue/Impact/Fix/Priority table | Per-field analysis with estimated abandonment cost |\n| Recommended Field Set | Justified list | Required vs optional vs enrichable fields with rationale |\n| Field Layout Specification | Annotated outline | Order, grouping, label style, validation rules, mobile adaptations |\n| CTA Copy Options | 3-option table | Button text variants with reasoning and expected impact |\n| A/B Test Plan | Prioritized table | Top 5 tests with hypothesis, variant, metric, and priority |\n| Mobile Optimization Checklist | Checkbox list | Mobile-specific fixes with implementation notes |\n\n---\n\n## Related Skills\n\n- **signup-flow-cro** -- Use when the form is an account creation or trial registration flow. Form-cro is for lead capture, contact, and demo forms.\n- **popup-cro** -- Use when the form lives inside a modal or popup. Form-cro handles the form itself; popup-cro handles the trigger, timing, and container.\n- **page-cro** -- Use when the page surrounding the form needs optimization (headline, value prop, layout).\n- **onboarding-cro** -- Use when post-form-submission activation is the bottleneck, not the form itself.\n\n---\n\n## Tool Reference\n\n### 1. form_scorer.py\n\n**Purpose:** Score a form against CRO best practices across field count, field types, CTA quality, mobile readiness, and trust signals.\n\n```bash\npython scripts/form_scorer.py form_config.json\npython scripts/form_scorer.py form_config.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `form_config.json` | Yes | JSON file with form fields, CTA, and context metadata |\n| `--json` | No | Output results as JSON |\n\n### 2. field_cost_analyzer.py\n\n**Purpose:** Calculate the estimated abandonment cost of each form field and recommend fields to remove, keep, or make enrichable.\n\n```bash\npython scripts/field_cost_analyzer.py form_fields.json\npython scripts/field_cost_analyzer.py form_fields.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `form_fields.json` | Yes | JSON file with form fields and their types |\n| `--json` | No | Output results as JSON |\n| `--monthly-visitors` | No | Monthly form visitors for dollar impact estimate (default: 1000) |\n| `--current-rate` | No | Current form completion rate as percentage (default: 25) |\n| `--value-per-lead` | No | Dollar value per lead for ROI calculation (default: 50) |\n\n### 3. ab_test_calculator.py\n\n**Purpose:** Calculate A/B test sample size, duration, and statistical significance for form optimization experiments.\n\n```bash\npython scripts/ab_test_calculator.py --baseline 25 --lift 10 --traffic 500\npython scripts/ab_test_calculator.py --baseline 25 --lift 10 --traffic 500 --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `--baseline` | Yes | Current conversion rate as percentage (e.g., 25 for 25%) |\n| `--lift` | Yes | Minimum detectable lift as percentage (e.g., 10 for 10% relative lift) |\n| `--traffic` | Yes | Daily traffic (visitors per day to the form) |\n| `--confidence` | No | Confidence level as percentage (default: 95) |\n| `--json` | No | Output results as JSON |\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Solution |\n|---------|-------------|----------|\n| Form completion rate below 15% | Too many fields or high-friction fields present | Run field_cost_analyzer.py to identify and remove high-cost fields; target email-only for first-touch lead forms |\n| Mobile completion rate 50%+ lower than desktop | Form not optimized for touch input | Ensure 44px touch targets, single-column layout, native keyboard types; replace dropdowns with button groups on mobile |\n| Users start but do not finish the form | Friction in middle fields (phone, budget, message) | Move high-friction fields to later steps in a multi-step form; capture email in step 1 |\n| High error rate on email or phone fields | Validation too aggressive or unclear error messages | Validate on blur (not keystroke); use specific error copy (\"Please include @ in email\") not generic (\"Invalid input\") |\n| A/B test results are inconclusive after 4 weeks | Insufficient sample size or too small a lift target | Use ab_test_calculator.py to confirm required sample size; consider testing bigger changes (field removal vs copy tweak) |\n| CTA clicks are low despite good page traffic | CTA copy is generic or button is not prominent enough | Replace \"Submit\" with value-specific copy (\"Get My Report\"); ensure CTA is full-width on mobile, high-contrast color |\n\n---\n\n## Success Criteria\n\n- Form completion rate above 25% for lead capture forms (above 35% is excellent)\n- Mobile completion rate within 20% of desktop rate\n- Error rate below 10% of form interactions\n- Field-level drop-off identifies specific friction points with clear remediation\n- Each form field has documented justification (business need or enrichable post-submission)\n- A/B tests run for minimum 200 conversions per variant before declaring winner\n- Post-form-submission follow-up occurs within 24 hours for demo and contact forms\n\n---\n\n## Scope & Limitations\n\n- **In scope:** Form field optimization, CTA copy, validation UX, mobile optimization, trust signal placement, A/B test design, field cost analysis\n- **Out of scope:** Page-level CRO (use page-cro), popup trigger optimization (use popup-cro), signup/registration flows (use signup-flow-cro), post-submission nurture sequences\n- **Data dependency:** Field-level analytics (per-field drop-off) provide the most actionable data but require analytics instrumentation\n- **Compliance constraint:** GDPR/HIPAA may require specific fields that cannot be removed; document compliance requirements before optimizing\n- **Statistical validity:** A/B test recommendations require sufficient traffic volume; low-traffic forms may need longer test durations or alternative evaluation methods\n\n---\n\n## Integration Points\n\n- **page-cro** -- When the form converts well but the surrounding page does not drive form interactions, optimize the page-level elements first\n- **popup-cro** -- When the form is inside a popup or modal, trigger timing and container design are handled by popup-cro\n- **signup-flow-cro** -- For account creation and registration forms (not lead capture), use signup-flow-cro which handles multi-step auth flows\n- **onboarding-cro** -- When post-form-submission activation is the bottleneck, not the form completion rate itself\n- **free-tool-strategy** -- Free tools often include lead capture forms; use form-cro to optimize the capture form within the tool","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/form-cro","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/form-cro/SKILL.md","defaultBranch":"main"},"readme":"# Form CRO\n\nProduction-grade form optimization framework covering field-cost analysis, layout engineering, multi-step form architecture, validation UX patterns, mobile-specific optimization, and structured A/B test design. Applicable to lead capture, contact, demo request, application, survey, and checkout forms. For signup/registration flows, use signup-flow-cro.\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [Field-Cost Analysis Framework](#field-cost-analysis-framework)\n- [Multi-Step vs Single-Step Decision](#multi-step-vs-single-step-decision)\n- [Field Design Patterns](#field-design-patterns)\n- [Validation UX](#validation-ux)\n- [CTA and Submit Button Optimization](#cta-and-submit-button-optimization)\n- [Mobile Form Optimization](#mobile-form-optimization)\n- [Trust and Context Elements](#trust-and-context-elements)\n- [Form Type Playbooks](#form-type-playbooks)\n- [A/B Test Framework](#ab-test-framework)\n- [Metrics and Measurement](#metrics-and-measurement)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore optimizing the form, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Form type** β lead capture, contact, demo, application, or checkout (sets the optimal field count and playbook)\n- [ ] **Current fields + which are used in follow-up** β reveals which fields to cut or enrich (the core of field-cost analysis)\n- [ ] **Current completion rate + where users abandon** β baseline and the specific friction point to target\n- [ ] **Compliance requirements** β GDPR/HIPAA fields that cannot be removed (constrains the field reduction)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the audit.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| What type of form? (lead capture, contact, demo, application, checkout) | Different types have different optimal field counts |\n| How many fields currently? | Establishes baseline friction level |\n| What is the current completion rate? | Benchmark for improvement |\n| Where do users abandon? (if field-level analytics exist) | Identifies the specific friction point |\n| Mobile vs desktop split? | Mobile forms need separate optimization |\n| What happens with submitted data? | Determines which fields are truly necessary |\n| Which fields are actually used in follow-up? | Often reveals 30-50% of fields are never used |\n| Any compliance requirements? (GDPR, HIPAA) | Constrains what can be removed |\n\n---\n\n## Field-Cost Analysis Framework\n\nEvery field has a cost measured in abandonment. The question is not \"what data would be nice to have\" but \"what data is worth the conversion loss.\"\n\n### Field Cost Matrix\n\n| Field Type | Estimated Abandonment Cost | Justification Threshold |\n|-----------|---------------------------|------------------------|\n| Email | Baseline (near zero for gated content) | Always justified for lead forms |\n| First name | +2-3% drop | Justified if personalization drives follow-up |\n| Last name | +2-3% drop | Rarely justified for first touch |\n| Phone number | +5-10% drop | Only if sales will call within 24 hours |\n| Company name | +3-5% drop | Justified for B2B qualification |\n| Company size | +3-5% drop | Justified only if routing decisions depend on it |\n| Job title | +3-5% drop | Can often be enriched post-submission |\n| Industry | +2-3% drop | Can often be enriched post-submission |\n| Message/textarea | +5-8% drop | Justified for contact forms, not for lead capture |\n| Budget | +8-12% drop | Only justified for high-intent demo/sales forms |\n| Custom question | +3-5% per question | Must directly affect lead routing or qualification |\n\n### The Enrichment Test\n\nBefore including any field, ask: **Can this be enriched after submission?**\n\n| Field | Enrichable? | Method | Keep in Form? |\n|-------|------------|--------|-------------","createdAt":"2026-09-25T13:52:02.733Z","updatedAt":"2026-09-25T13:52:02.733Z"},{"id":"cmuh0s8n103qdqu06erkcgrpm","slug":"borghei-claude-skills-free-tool-strategy","name":"free-tool-strategy","description":"Free tool marketing strategy covering idea evaluation, tool design, lead capture architecture, SEO landing pages, launch playbook, and ROI measurement for calculators, generators, checkers, graders, and interactive tools.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"free-tool-strategy","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Free tool marketing strategy covering idea evaluation, tool design, lead capture architecture, SEO landing pages, launch playbook, and ROI measurement for calculators, generators, checkers, graders, and interactive tools.","permissions":[],"systemPrompt":"# Free Tool Strategy\n\nProduction-grade framework for building free tools that generate traffic, leads, and backlinks. Covers idea evaluation with a 6-factor scoring system, tool design patterns, lead capture architecture, SEO landing page strategy, launch playbook, and ROI measurement. Applicable to calculators, generators, checkers, graders, converters, templates, and interactive visualizations.\n\n---\n\n## Table of Contents\n\n- [When to Build vs When Not To](#when-to-build-vs-when-not-to)\n- [Tool Type Selection](#tool-type-selection)\n- [6-Factor Evaluation Framework](#6-factor-evaluation-framework)\n- [Tool Design Principles](#tool-design-principles)\n- [Lead Capture Architecture](#lead-capture-architecture)\n- [SEO Landing Page Strategy](#seo-landing-page-strategy)\n- [Launch Playbook](#launch-playbook)\n- [Distribution Channels](#distribution-channels)\n- [Measurement Framework](#measurement-framework)\n- [Maintenance and Iteration](#maintenance-and-iteration)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## When to Build vs When Not To\n\n**Build a free tool when:**\n- Search volume exists for \"[topic] calculator/generator/checker\" (> 500/month)\n- No excellent free alternative exists (or you can be 10x better)\n- The tool naturally connects to your paid product\n- You have engineering resources to build AND maintain it\n- The tool produces shareable, bookmark-worthy output\n\n**Do NOT build when:**\n- A well-established free tool already exists and is sufficient\n- The tool would be a thin wrapper with no unique value\n- You cannot maintain it post-launch\n- The tool requires data you do not have or cannot access\n- Total addressable search volume is < 200/month\n\n---\n\n## Clarify First\n\nBefore designing the free tool, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Tool concept + type** β calculator, generator, checker, grader, converter, template, or visualization (drives build complexity and lead-capture fit)\n- [ ] **Target keyword + search volume** β the \"free [tool]\" search demand (a core factor in the 6-factor go/no-go score)\n- [ ] **Primary goal** β leads, SEO traffic, backlinks, or brand (selects the tool type and gate strategy)\n- [ ] **Connection to your paid product** β without it, leads won't convert (determines whether to build at all)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the plan.\n\n## Tool Type Selection\n\n| Tool Type | What It Does | Build Complexity | Lead Capture Fit | SEO Value | Example |\n|-----------|-------------|-----------------|-----------------|-----------|---------|\n| Calculator | Takes inputs, outputs a number/range | Low-Medium | High (email the full report) | High | ROI calculator, LTV calculator, salary calculator |\n| Generator | Creates text, ideas, or structured content | Low (template) to High (AI) | Medium (save/download results) | High | Headline generator, name generator, bio writer |\n| Checker/Auditor | Analyzes a URL, text, or file and scores it | Medium-High | Very high (full report via email) | Very high | SEO audit, readability checker, accessibility checker |\n| Grader | Scores something against a rubric | Medium | High (detailed scorecard) | High | Website grader, email subject line grader |\n| Converter | Transforms input from one format to another | Low-Medium | Low (utility, quick use) | Medium | Unit converter, file converter, timezone converter |\n| Template Library | Pre-built fillable documents | Very low | Medium (download gated) | High | Contract templates, brief templates, spreadsheet templates |\n| Interactive Visualization | Shows data or concepts visually | High | Medium | Very high (link magnet) | Market maps, comparison charts, trend visualizers |\n\n### Selection Decision Tree\n\n```\nWhat do you want to generate?\nβββ Leads (email capture) β Checker/Auditor or Calculator (report gating)\nβββ SEO traffic β Calculator or Checker (high search volume keywords)\nβββ Backlinks β Interactive Visualization or Template Library (link magnet)\nβββ Brand awareness β Generator (shareable output, social virality)\nβββ All of the above β Checker/Auditor (highest combined value)\n```\n\n---\n\n## 6-Factor Evaluation Framework\n\nScore each tool idea 1-5 on each factor. Maximum score: 30.\n\n| Factor | What to Check | 1 (Weak) | 3 (Moderate) | 5 (Strong) |\n|--------|--------------|----------|-------------|-----------|\n| Search Volume | Monthly searches for \"free [tool]\" | < 100/mo | 500-2,000/mo | > 5,000/mo |\n| Competition | Quality of existing free tools | Excellent tools exist | Decent tools, room to improve | No good free alternatives |\n| Build Effort | Engineering time required | Months of work | 1-2 weeks | Days |\n| Lead Capture Potential | Natural email gate opportunity | Forced gate kills UX | Reasonable gate | Natural fit (report, saved results) |\n| SEO Value | Topical authority and backlink potential | Thin, one-page utility | Moderate content depth | Deep use case, link magnet |\n| Viral Potential | Will users share results or embed? | Nobody would share | Some sharing potential | Results are inherently shareable |\n\n### Scoring Thresholds\n\n| Score | Decision |\n|-------|----------|\n| 25-30 | Build immediately -- strong across all factors |\n| 20-24 | Strong candidate -- validate search volume before committing |\n| 15-19 | Conditional -- only if resources are available and strategic fit is strong |\n| < 15 | Do not build -- rethink the concept or find a different angle |\n\n---\n\n## Tool Design Principles\n\n### Value Before Gate\n\n**The cardinal rule:** Give the core value first. Gate the upgrade.\n\n| Good | Bad |\n|------|-----|\n| Show the score immediately, offer to email the full report | \"Enter your email to see your results\" |\n| Display the generated content, gate the save/export | Block all output behind email wall |\n| Free basic analysis, premium detailed breakdown | Nothing visible without signup |\n\n### Minimal Friction Input\n\n- Maximum 3 inputs to get initial results\n- No account required for core value\n- Progressive disclosure: simple first, detailed on request\n- Smart defaults where possible (auto-detect, pre-fill)\n\n### Shareable Output\n\nDesign results so users want to share them:\n\n| Mechanism | Implementation |\n|-----------|---------------|\n| Unique results URL | Each run gets a shareable permalink |\n| Social share buttons | \"Tweet your score\" with pre-filled text |\n| Downloadable report | PDF or CSV export |\n| Embeddable badge/widget | \"Scored 92/100 by [Your Tool]\" badge |\n| Visual score card | Social-media-ready image with result |\n\n### Mobile-First Design\n\n- All inputs work on touch screens\n- Results render cleanly on mobile\n- Share buttons trigger native share sheet\n- No hover-dependent UI elements\n\n---\n\n## Lead Capture Architecture\n\n### When to Gate\n\n| Gate Decision | Criteria |\n|--------------|---------|\n| Gate with email | Results are complex (report format), ongoing value (re-run monthly), personalized output |\n| Do NOT gate | Core result is a single number, competition offers the same ungated, primary goal is SEO/backlinks |\n\n### Progressive Capture\n\nDo not ask for everything at once. Build the profile over multiple interactions.\n\n| Interaction | What to Capture | How |\n|------------|----------------|-----|\n| First use | Email (to save or email results) | Inline form after results display |\n| Return use | Name + Role | Contextual prompt, not a blocking form |\n| Repeated use | Company + Team size | If they request team features or saved history |\n\n### Capture Form Design\n\n- Email-only first gate (single field + submit button)\n- Position the form AFTER results are shown (not before)\n- Explain the value: \"Email me a detailed breakdown\" not \"Sign up\"\n- Privacy text: \"We'll send your report. No spam.\"\n- Never require account creation for the free tool\n\n---\n\n## SEO Landing Page Strategy\n\n### Page Structure\n\n```\nH1: Free [Tool Name] -- [What It Does in One Phrase]\nSubhead: [Who it is for] + [what problem it solves]\n\n[THE TOOL -- above the fold, interactive]\n\nH2: How [Tool Name] Works\n (3-4 steps with screenshots)\n\nH2: Why [Audience] Use [Tool Name]\n (Benefits, use cases, 3-5 paragraphs)\n\nH2: [Related Question 1] (FAQ-style, keyword-targeted)\nH2: [Related Question 2]\nH2: [Related Question 3]\n\nH2: Frequently Asked Questions\n (5-7 FAQs with FAQPage schema)\n```\n\n### SEO Requirements\n\n- Target keyword in: H1, URL slug, meta title, first 100 words, 2+ subheadings\n- Meta title: \"Free [Tool Name]: [Action Verb] Your [Outcome] | [Brand]\"\n- Meta description: Include the keyword + what the tool does + \"Free, no signup required\"\n- URL: `/tools/[tool-name]` or `/free-[tool-name]`\n\n### Schema Markup\n\nAdd `SoftwareApplication` schema:\n\n```json\n{\n \"@context\": \"https://schema.org\",\n \"@type\": \"SoftwareApplication\",\n \"name\": \"Free [Tool Name]\",\n \"applicationCategory\": \"BusinessApplication\",\n \"offers\": {\n \"@type\": \"Offer\",\n \"price\": \"0\",\n \"priceCurrency\": \"USD\"\n },\n \"description\": \"[What the tool does]\",\n \"operatingSystem\": \"Web\"\n}\n```\n\nAlso add FAQPage schema for the FAQ section.\n\n---\n\n## Launch Playbook\n\n### Pre-Launch (1-2 Weeks Before)\n\n- [ ] SEO landing page published and indexed\n- [ ] Schema markup validated\n- [ ] Outreach target list built (who links to similar tools?)\n- [ ] Product Hunt draft prepared (if applicable)\n- [ ] Social media teaser content created\n- [ ] Email announcement drafted for existing audience\n\n### Launch Week\n\n| Day | Channel | Action |\n|-----|---------|--------|\n| Day 1 | Email list | Announcement to existing subscribers |\n| Day 1 | Social media | Launch post on Twitter/X, LinkedIn |\n| Day 1 | Product Hunt | Submit (if applicable, aim for Tuesday-Thursday) |\n| Day 2 | Community | Share in relevant Slack groups, Discord, Reddit |\n| Day 3 | Outreach | Email bloggers, newsletter editors who cover tools |\n| Day 5 | Content | Publish blog post about the tool with use cases |\n| Day 7 | Social media | Results round-up, engagement post |\n\n### Post-Launch (Weeks 2-8)\n\n- [ ] Monitor search rankings for target keywords\n- [ ] Track backlinks with GSC or Ahrefs\n- [ ] Reach out to \"best [category] tools\" listicle authors\n- [ ] Submit to tool directories (Free Tools, AlternativeTo, etc.)\n- [ ] Iterate based on usage data (most-used features, drop-off points)\n\n---\n\n## Distribution Channels\n\n### Organic Channels\n\n| Channel | Approach | Expected Impact |\n|---------|----------|----------------|\n| SEO | Target \"[type] calculator/checker\" keywords | Long-term, compounding traffic |\n| Product Hunt | Launch listing | Spike traffic + backlinks |\n| Hacker News | \"Show HN\" post if technically interesting | Spike traffic + developer backlinks |\n| Reddit | Share in relevant subreddits (genuinely helpful, not spammy) | Moderate traffic + community feedback |\n| Twitter/X | Launch thread with tool demo | Engagement + social proof |\n| LinkedIn | Professional use case post | B2B lead generation |\n| Industry newsletters | Pitch to curators | Targeted audience + backlinks |\n\n### Link Acquisition\n\n| Source | Approach |\n|--------|---------|\n| \"Best [category] tools\" listicles | Find existing lists, pitch for inclusion |\n| Resource pages | Find industry resource compilations, suggest your tool |\n| Blog posts mentioning the problem your tool solves | Reach out with \"we built a free tool for this\" |\n| Comparison sites | Submit to tool comparison platforms |\n| Educational content | Pitch to courses, tutorials, guides that cover related topics |\n\n---\n\n## Measurement Framework\n\n### Key Metrics\n\n| Metric | What It Tells You | Target (90 days) |\n|--------|------------------|-----------------|\n| Tool usage (sessions) | Is anyone using it? | 500+ sessions/month |\n| Completion rate | Do users finish using it? | > 60% |\n| Lead conversion rate | Is it generating leads? | 5-15% of completions |\n| Organic traffic | Is it ranking? | 500+ sessions/month from organic |\n| Referring domains | Is it earning backlinks? | 10+ organic backlinks |\n| Email to pipeline rate | Is it generating qualified leads? | Track in CRM |\n| Bounce rate | Is the tool engaging? | < 50% |\n\n### ROI Calculation\n\n```\nMonthly Cost = Engineering hours x Hourly rate + Hosting cost\nMonthly Value = (Leads x Lead-to-Customer Rate x ACV) + (Backlink value estimate)\n\nBreak-even month = Total build cost / Monthly value\nTarget: Break-even within 6 months\n```\n\n---\n\n## Maintenance and Iteration\n\n### Ongoing Maintenance Requirements\n\n| Task | Frequency | Why |\n|------|-----------|-----|\n| Check for broken APIs/data sources | Monthly | External dependencies change |\n| Update calculations/logic if standards change | As needed | Accuracy maintains trust |\n| Review and fix UX issues from user feedback | Quarterly | Continuous improvement |\n| Update SEO landing page content | Semi-annually | Content freshness |\n| Check analytics for usage trends | Monthly | Identify optimization opportunities |\n\n### Iteration Based on Data\n\n| Signal | Action |\n|--------|--------|\n| High usage, low lead capture | Improve gate positioning or offer |\n| Low usage, high search ranking | Improve tool UX and value |\n| High leads, low quality | Add qualifying questions to capture form |\n| High bounce rate | Improve above-fold messaging and tool visibility |\n| Low search ranking | Improve page content depth and backlink acquisition |\n\n---\n\n## Output Artifacts\n\n| Artifact | Format | Description |\n|----------|--------|-------------|\n| Tool Idea Evaluation | Scored comparison matrix | 6-factor evaluation of candidate ideas |\n| Tool UX Specification | Inputs/outputs/flow design | Inputs, outputs, lead capture flow, share mechanics |\n| Landing Page Copy | Full page content | H1, subhead, how it works, FAQ, meta tags |\n| Launch Plan | Phased checklist | Pre-launch, launch week, post-launch with channel-specific actions |\n| Measurement Dashboard | Metric table | KPIs with targets at 30/60/90 days |\n| ROI Model | Revenue calculation | Break-even analysis based on traffic and conversion assumptions |\n| Maintenance Schedule | Task calendar | Ongoing tasks with frequency and ownership |\n\n---\n\n## Related Skills\n\n- **seo-audit** -- Use for auditing existing pages and keyword opportunities. Not for tool-based content assets.\n- **schema-markup** -- Use for implementing SoftwareApplication and FAQPage schema on the tool landing page.\n- **form-cro** -- Use for optimizing the lead capture form within the tool.\n- **page-cro** -- Use for optimizing the landing page conversion rate.\n- **content-creator** -- Use for writing the blog post and social content supporting the tool launch.\n\n---\n\n## Tool Reference\n\n### 1. tool_idea_scorer.py\n\n**Purpose:** Score free tool ideas against the 6-factor evaluation framework and rank candidates.\n\n```bash\npython scripts/tool_idea_scorer.py tool_ideas.json\npython scripts/tool_idea_scorer.py tool_ideas.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `tool_ideas.json` | Yes | JSON file with tool idea names and 6-factor scores |\n| `--json` | No | Output results as JSON |\n\n### 2. tool_roi_calculator.py\n\n**Purpose:** Calculate the ROI and break-even timeline for a free tool based on traffic, conversion, and cost assumptions.\n\n```bash\npython scripts/tool_roi_calculator.py --build-cost 5000 --monthly-traffic 2000 --conversion-rate 8 --lead-value 50\npython scripts/tool_roi_calculator.py --build-cost 5000 --monthly-traffic 2000 --conversion-rate 8 --lead-value 50 --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `--build-cost` | Yes | Total build cost in dollars (engineering time + design) |\n| `--monthly-traffic` | Yes | Expected monthly sessions after 90 days |\n| `--conversion-rate` | Yes | Expected lead conversion rate as percentage |\n| `--lead-value` | Yes | Dollar value per captured lead |\n| `--monthly-hosting` | No | Monthly hosting/maintenance cost (default: 50) |\n| `--json` | No | Output results as JSON |\n\n### 3. launch_checklist_generator.py\n\n**Purpose:** Generate a phased launch checklist (pre-launch, launch week, post-launch) customized to the tool type and distribution channels.\n\n```bash\npython scripts/launch_checklist_generator.py --tool-type calculator --channels seo,producthunt,social\npython scripts/launch_checklist_generator.py --tool-type checker --channels seo,email --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `--tool-type` | Yes | Tool type: calculator, generator, checker, grader, converter, template, visualization |\n| `--channels` | No | Comma-separated launch channels (default: seo,social,email) |\n| `--json` | No | Output results as JSON |\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Solution |\n|---------|-------------|----------|\n| High traffic to tool but low lead capture | Gate is too aggressive or positioned before value delivery | Show core results first, then gate the detailed report or export; use email-only capture form |\n| Tool built but no organic traffic after 3 months | SEO landing page is thin or keywords are too competitive | Add 1500+ words of supporting content (how it works, use cases, FAQ); target long-tail keywords |\n| Tool is used once but users do not return | No recurring value or no save/bookmark mechanism | Add saved results, email reports, or periodic re-run reminders; consider a \"monitor\" mode |\n| Build cost exceeded estimate | Scope creep during development | Use tool_roi_calculator.py upfront to set budget ceiling; define MVP scope and ship in 2 weeks max |\n| Product Hunt launch got minimal traction | Poor timing or weak positioning | Launch Tuesday-Thursday; lead with the user benefit, not the technology; get 5+ early upvotes from network |\n| Tool generates leads but low conversion to paid | Tool attracts wrong audience or no connection to paid product | Ensure the tool solves a problem your paid product also addresses; add contextual upgrade prompts |\n\n---\n\n## Success Criteria\n\n- Tool scores 20+ on the 6-factor evaluation framework before committing to build\n- Tool achieves 500+ monthly sessions within 90 days of launch\n- Lead conversion rate of 5-15% of tool completions\n- Tool earns 10+ organic backlinks within 6 months\n- Break-even achieved within 6 months (verified by tool_roi_calculator.py)\n- Completion rate above 60% (users who start using the tool finish the workflow)\n- At least 1 supporting blog post and social launch content published at launch\n\n---\n\n## Scope & Limitations\n\n- **In scope:** Tool idea evaluation, ROI modeling, launch planning, distribution strategy, lead capture architecture, SEO landing page strategy, measurement framework\n- **Out of scope:** Engineering implementation, design/UI work, paid advertising strategy, AI/ML-powered tool features\n- **Build constraint:** All tools should be buildable in 1-4 weeks; if longer, the scope is too large for a free marketing tool\n- **Maintenance cost:** Every tool requires ongoing maintenance (monthly checks, quarterly content updates); budget for this before building\n- **No API dependencies:** Free tools should use client-side logic where possible to avoid ongoing API costs and reliability issues\n\n---\n\n## Integration Points\n\n- **form-cro** -- Use for optimizing the lead capture form embedded within the free tool\n- **page-cro** -- Use for optimizing the SEO landing page that hosts the tool for conversion\n- **seo-audit** -- Use for validating the tool landing page meets technical SEO requirements\n- **content-creator** -- Use for writing the launch blog post, social content, and outreach emails\n- **schema-markup** -- Use for implementing SoftwareApplication and FAQPage schema on the tool page","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/free-tool-strategy","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/free-tool-strategy/SKILL.md","defaultBranch":"main"},"readme":"# Free Tool Strategy\n\nProduction-grade framework for building free tools that generate traffic, leads, and backlinks. Covers idea evaluation with a 6-factor scoring system, tool design patterns, lead capture architecture, SEO landing page strategy, launch playbook, and ROI measurement. Applicable to calculators, generators, checkers, graders, converters, templates, and interactive visualizations.\n\n---\n\n## Table of Contents\n\n- [When to Build vs When Not To](#when-to-build-vs-when-not-to)\n- [Tool Type Selection](#tool-type-selection)\n- [6-Factor Evaluation Framework](#6-factor-evaluation-framework)\n- [Tool Design Principles](#tool-design-principles)\n- [Lead Capture Architecture](#lead-capture-architecture)\n- [SEO Landing Page Strategy](#seo-landing-page-strategy)\n- [Launch Playbook](#launch-playbook)\n- [Distribution Channels](#distribution-channels)\n- [Measurement Framework](#measurement-framework)\n- [Maintenance and Iteration](#maintenance-and-iteration)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## When to Build vs When Not To\n\n**Build a free tool when:**\n- Search volume exists for \"[topic] calculator/generator/checker\" (> 500/month)\n- No excellent free alternative exists (or you can be 10x better)\n- The tool naturally connects to your paid product\n- You have engineering resources to build AND maintain it\n- The tool produces shareable, bookmark-worthy output\n\n**Do NOT build when:**\n- A well-established free tool already exists and is sufficient\n- The tool would be a thin wrapper with no unique value\n- You cannot maintain it post-launch\n- The tool requires data you do not have or cannot access\n- Total addressable search volume is < 200/month\n\n---\n\n## Clarify First\n\nBefore designing the free tool, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Tool concept + type** β calculator, generator, checker, grader, converter, template, or visualization (drives build complexity and lead-capture fit)\n- [ ] **Target keyword + search volume** β the \"free [tool]\" search demand (a core factor in the 6-factor go/no-go score)\n- [ ] **Primary goal** β leads, SEO traffic, backlinks, or brand (selects the tool type and gate strategy)\n- [ ] **Connection to your paid product** β without it, leads won't convert (determines whether to build at all)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the plan.\n\n## Tool Type Selection\n\n| Tool Type | What It Does | Build Complexity | Lead Capture Fit | SEO Value | Example |\n|-----------|-------------|-----------------|-----------------|-----------|---------|\n| Calculator | Takes inputs, outputs a number/range | Low-Medium | High (email the full report) | High | ROI calculator, LTV calculator, salary calculator |\n| Generator | Creates text, ideas, or structured content | Low (template) to High (AI) | Medium (save/download results) | High | Headline generator, name generator, bio writer |\n| Checker/Auditor | Analyzes a URL, text, or file and scores it | Medium-High | Very high (full report via email) | Very high | SEO audit, readability checker, accessibility checker |\n| Grader | Scores something against a rubric | Medium | High (detailed scorecard) | High | Website grader, email subject line grader |\n| Converter | Transforms input from one format to another | Low-Medium | Low (utility, quick use) | Medium | Unit converter, file converter, timezone converter |\n| Template Library | Pre-built fillable documents | Very low | Medium (download gated) | High | Contract templates, brief templates, spreadsheet templates |\n| Interactive Visualization | Shows data or concepts visually | High | Medium | Very high (link magnet) | Market maps, comparison charts, trend visualizers |\n\n### Selection Decision Tree\n\n```\nWhat do you want to generate?\nβββ Leads (email capture) β Checker/Auditor or Calculator (report gating)\nβββ SEO traffic β Calculator or Checker (high ","createdAt":"2026-09-25T13:52:02.749Z","updatedAt":"2026-09-25T13:52:02.749Z"},{"id":"cmuh0s8ne03qjqu06snpqsf0h","slug":"borghei-claude-skills-onboarding-cro","name":"onboarding-cro","description":"Post-signup user onboarding optimization covering activation metrics, time-to-value reduction, onboarding flow design, empty state optimization, multi-channel coordination, and stalled user recovery.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"onboarding-cro","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Post-signup user onboarding optimization covering activation metrics, time-to-value reduction, onboarding flow design, empty state optimization, multi-channel coordination, and stalled user recovery.","permissions":[],"systemPrompt":"# Onboarding CRO\n\nProduction-grade user onboarding optimization framework covering activation definition, time-to-value engineering, flow architecture, empty state design, multi-channel coordination, stalled user recovery, and experiment design. Focused on the critical window between signup and habitual product usage.\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [Activation Definition Framework](#activation-definition-framework)\n- [Onboarding Flow Architecture](#onboarding-flow-architecture)\n- [Time-to-Value Engineering](#time-to-value-engineering)\n- [Empty State Design](#empty-state-design)\n- [Onboarding Patterns by Product Type](#onboarding-patterns-by-product-type)\n- [Multi-Channel Coordination](#multi-channel-coordination)\n- [Stalled User Recovery](#stalled-user-recovery)\n- [Onboarding Checklist Design](#onboarding-checklist-design)\n- [Tooltip and Tour Design](#tooltip-and-tour-design)\n- [Metrics and Measurement](#metrics-and-measurement)\n- [Experiment Framework](#experiment-framework)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore designing the onboarding, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Product type** β B2B SaaS, B2C app, marketplace, or content platform (selects the onboarding pattern)\n- [ ] **Activation event (aha moment)** β the action correlated with 30-day retention (defines what the whole flow drives toward)\n- [ ] **Current activation rate + where users drop off** β baseline and the biggest funnel bottleneck to fix\n- [ ] **Day-1/7/30 retention** β sets urgency and whether the problem is onboarding vs product-market fit\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| What is the product type? (B2B SaaS, B2C app, marketplace, content platform) | Determines the onboarding pattern |\n| What is the core value proposition? | Defines what the aha moment should demonstrate |\n| What happens immediately after signup? | Identifies the current first-run experience |\n| What action correlates most with 30-day retention? | Defines the activation event |\n| Where do users drop off? (funnel data if available) | Pinpoints the biggest bottleneck |\n| What is the current activation rate? | Baseline for improvement |\n| What is Day-1 / Day-7 / Day-30 retention? | Context for urgency |\n\n---\n\n## Activation Definition Framework\n\n### Finding the Aha Moment\n\nThe aha moment is the specific action that, once completed, makes a user significantly more likely to retain. It is NOT a feature -- it is the moment the user experiences the core value.\n\n**Method to identify it:**\n\n1. **Cohort comparison:** Compare 90-day retained users vs churned users. What actions did retained users do in the first 7 days that churned users did not?\n2. **Correlation analysis:** For each candidate action, calculate the correlation between completing that action in week 1 and being retained at day 30.\n3. **Timing analysis:** When do retained users complete this action? (Day 1? Day 3? Day 7?)\n\n### Activation Event Examples\n\n| Product Type | Activation Event | Why This Works |\n|-------------|-----------------|----------------|\n| Project management | Create project + invite 1 team member | Collaboration creates switching costs |\n| Analytics tool | Install tracking + view first report | Seeing their own data is the value |\n| Design tool | Create first design + export or share | Output = value realized |\n| CRM | Import contacts + log first activity | Data investment creates lock-in |\n| Marketplace | Complete first transaction | Transaction = value delivered |\n| Content platform | Follow 3+ sources + consume 5+ items | Personalization drives habit |\n| Communication tool | Send first message + get a reply | Two-sided value activation |\n\n### Activation Metric Structure\n\n```\nActivation Rate = Users who reach activation event / Total signups\n (within first N days)\n\nTarget: 40-60% activation within 7 days for B2C\n 25-40% activation within 14 days for B2B\n```\n\n---\n\n## Onboarding Flow Architecture\n\n### Flow Type Selection\n\n| Approach | Best For | Risk | Mitigation |\n|----------|----------|------|------------|\n| Product-first (drop into product) | Simple products, B2C, mobile apps | Blank slate overwhelm | Pre-populated sample data |\n| Guided setup (wizard) | Products needing configuration | Adds friction before value | Keep to 3-5 steps max |\n| Value-first (show results immediately) | Products with demo data | May not feel personalized | Use their data if possible |\n| Template-first | Creative/productivity tools | Choice paralysis | Curate 3-5 starter templates |\n| Video walkthrough | Complex B2B products | Users skip videos | Keep under 90 seconds |\n\n### The First 30-Second Rule\n\nWhatever flow type you choose, within 30 seconds of landing in the product, the user must:\n\n1. See a clear single next action (not 5 options)\n2. Understand what the product will do for them\n3. Have a visible path forward (no dead ends)\n\n### Flow Design Principles\n\n| Principle | Implementation |\n|-----------|---------------|\n| One goal per session | First session focuses ONLY on reaching the aha moment |\n| Do, don't show | User performs the action, not watches a tutorial about it |\n| Progress creates motivation | Show advancement (checklist, progress bar, celebration) |\n| Defer complexity | Advanced settings and features surface AFTER activation |\n| Always escapable | Users can skip or dismiss any onboarding element |\n| Remember state | If user leaves and returns, resume where they left off |\n\n---\n\n## Time-to-Value Engineering\n\n### Time-to-Value (TTV) Reduction Framework\n\nTTV is the elapsed time between signup and the user experiencing core value. Shorter = better.\n\n| Bottleneck | Detection | Fix | Expected TTV Reduction |\n|-----------|-----------|-----|----------------------|\n| Setup required before use | Users drop off during setup | Reduce required setup steps, use defaults | 30-50% |\n| Waiting for data | No value until data arrives | Provide sample/demo data immediately | 40-60% |\n| Waiting for team members | Value requires collaboration | Enable solo value first, then team | 20-40% |\n| Integration required | Cannot function without connecting tools | Offer manual input as alternative | 30-50% |\n| Learning curve | Product too complex for quick win | Guided first action with templates | 20-30% |\n| Approval/verification required | Email verification, admin approval | Defer verification to after first value | 40-60% |\n\n### Quick Win Architecture\n\nDesign the onboarding to deliver a \"quick win\" within the first 3 minutes:\n\n1. Identify the simplest valuable output the product can deliver\n2. Pre-populate inputs where possible\n3. Minimize decisions (use smart defaults)\n4. Celebrate the output (\"You just created your first [X]!\")\n5. Immediately show the next step\n\n---\n\n## Empty State Design\n\nEmpty states are onboarding moments, not dead ends. Every blank screen is an opportunity to guide the user toward activation.\n\n### Empty State Anatomy\n\n```\nβββββββββββββββββββββββββββββββββββββββ\nβ β\nβ [Illustration or Preview] β Show what this will look like with data\nβ β\nβ What this section does β 1 sentence, benefit-focused\nβ β\nβ [Primary CTA: Create First X] β Single clear action\nβ β\nβ Or try with sample data β β Low-friction alternative\nβ β\nβββββββββββββββββββββββββββββββββββββββ\n```\n\n### Empty State Rules\n\n| Rule | Good | Bad |\n|------|------|-----|\n| Show the end state | Preview with sample data | Completely blank screen |\n| Single CTA | \"Create your first project\" | \"Learn more\" + \"Watch video\" + \"Read docs\" |\n| Explain the value | \"Track your team's progress in one view\" | \"No projects found\" |\n| Offer sample data | \"Try with example data\" link | Force creation from scratch |\n\n---\n\n## Onboarding Patterns by Product Type\n\n### B2B SaaS\n\n```\nSignup β Setup Wizard (3-5 steps) β First Value Action β Team Invite β Deep Setup\n βββ Company info βββ Template selection βββ Email invites\n βββ Role/goal selection βββ Quick configuration βββ Permissions\n βββ Integration connect βββ First output created\n```\n\n**Key metric:** Time from signup to first team collaboration\n\n### Marketplace / Two-Sided\n\n```\nSignup β Complete Profile β Browse/Discover β First Transaction β Repeat Loop\n βββ Photo/avatar βββ Curated feed βββ Guided first action\n βββ Preferences βββ Search + filters βββ Transaction completion\n βββ Verification βββ Saved/bookmarked\n```\n\n**Key metric:** Time from signup to first completed transaction\n\n### Mobile App (B2C)\n\n```\nInstall β Permission Requests β Quick Win β Push Notification Setup β Habit Loop\n βββ Location (if needed) βββ Core action βββ Value-based ask\n βββ Notifications βββ Immediate result βββ Frequency choice\n βββ Camera/contacts βββ Celebration\n```\n\n**Key metric:** Day-1 retention rate\n\n### Content / Media Platform\n\n```\nSignup β Interest Selection β Personalized Feed β First Engagement β Social Connection\n βββ Topic picks βββ Curated content βββ Read/watch/listen\n βββ Creator follows βββ Algorithmic mix βββ Like/save/share\n βββ Format preferences βββ Notification prefs\n```\n\n**Key metric:** Sessions per week in first 14 days\n\n---\n\n## Multi-Channel Coordination\n\n### Email + In-App Matrix\n\n| Trigger | In-App Action | Email Action | Timing |\n|---------|--------------|--------------|--------|\n| Signup complete | Welcome screen with first step | Welcome email with single CTA | Immediate |\n| Step 1 complete | Show step 2 | -- (don't email for every step) | Immediate |\n| 24 hours, incomplete onboarding | Persistent banner/checklist | \"Complete your setup\" email | 24h after signup |\n| 72 hours, not activated | Welcome back modal | \"Here's what you can do\" email | 72h after signup |\n| Activation achieved | Celebration modal + next feature | Celebration email + next step | Immediate |\n| Day 7, feature discovery | Contextual tooltip | \"Did you know?\" feature email | Day 7 |\n| Day 14, engagement dip | -- | Re-engagement with use case examples | Day 14 |\n\n### Email Design Rules\n\n- Each email has ONE CTA that drives back into the product\n- Personalize based on actions already taken (do not ask them to do what they already did)\n- Keep emails short (< 150 words body)\n- Subject line references the specific next step, not generic \"Welcome to [Product]\"\n\n---\n\n## Stalled User Recovery\n\n### Stalled User Definition\n\n| Stalled State | Criteria | Recovery Priority |\n|--------------|----------|------------------|\n| Never started | Signed up, never logged in again | Medium (may be wrong ICP) |\n| Partially onboarded | Completed 1-2 setup steps, stopped | High (invested effort, hit a wall) |\n| Active but not activated | Logged in 3+ times, never reached aha moment | Highest (engaged but stuck) |\n| Activated but churning | Reached aha moment, usage declining | High (retention problem, not onboarding) |\n\n### Recovery Tactics\n\n| Stalled State | Tactic 1 | Tactic 2 | Tactic 3 |\n|--------------|----------|----------|----------|\n| Never started | \"We set up [X] for you\" email | Pre-populated account | -- |\n| Partially onboarded | \"Pick up where you left off\" email | Simplify remaining steps | Offer live help |\n| Active but not activated | In-app guided walkthrough | \"Users like you do [X]\" suggestion | Human outreach for high-value |\n| Activated but churning | Feature discovery emails | Usage tips based on their workflow | CSM outreach for enterprise |\n\n### Human Touch Triggers\n\nFor high-value accounts (enterprise, high ACV), trigger human outreach when:\n- User is > 48 hours stalled in onboarding\n- User visits help docs more than 3 times in a session\n- User starts and abandons the same action 2+ times\n- User's engagement score drops below threshold after initial activation\n\n---\n\n## Onboarding Checklist Design\n\n### When to Use a Checklist\n\n- Multiple setup steps required before full value\n- Product has several features to discover\n- Self-serve B2B products where users self-onboard\n- Products with a clear \"fully set up\" state\n\n### Checklist Best Practices\n\n| Rule | Implementation |\n|------|---------------|\n| 3-7 items | Fewer than 3 = not worth a checklist. More than 7 = overwhelming. |\n| Order by value | Most impactful action first |\n| Start with quick wins | First item should be completable in < 60 seconds |\n| Show progress | Progress bar or \"3 of 5 complete\" counter |\n| Pre-check completed items | If they already did something, mark it done |\n| Celebrate completion | Animation, confetti, \"You're all set!\" message |\n| Dismissable | \"I'll do this later\" option. Never trap users. |\n| Persistent but not blocking | Sidebar widget or dashboard card, not a blocking modal |\n\n### Checklist Item Design\n\nEach item should include:\n- Clear action label (\"Import your contacts\")\n- Why it matters (\"So you can track interactions\")\n- Estimated time (\"Takes about 2 minutes\")\n- CTA button (\"Import Now\")\n\n---\n\n## Tooltip and Tour Design\n\n### When to Use Tooltips/Tours\n\n- Complex UI where features are not self-evident\n- Power features users might miss\n- UI changes after a major update\n- Features that require specific discovery order\n\n### Tour Best Practices\n\n| Rule | Implementation |\n|------|---------------|\n| Max 3-5 steps per tour | More than 5 and users will dismiss |\n| Dismissable at any time | \"Skip tour\" on every step |\n| Don't repeat for returning users | Track tour completion, never show again |\n| Highlight the actual UI element | Spotlight effect on the element being explained |\n| Action-oriented | \"Click here to create a project\" not \"This is where projects live\" |\n| Progressive | Show basic tour on day 1, advanced features tour on day 7 |\n\n---\n\n## Metrics and Measurement\n\n### Key Metrics\n\n| Metric | Formula | Target |\n|--------|---------|--------|\n| Activation rate | Users reaching activation / Total signups | B2C: 40-60%, B2B: 25-40% |\n| Time to activation | Median time from signup to activation event | B2C: < 1 day, B2B: < 7 days |\n| Onboarding completion rate | Users completing all steps / Total signups | > 60% |\n| Day-1 retention | Users returning day after signup / Total signups | > 40% |\n| Day-7 retention | Users active 7 days after signup / Total signups | > 25% |\n| Day-30 retention | Users active 30 days after signup / Total signups | > 15% |\n| Checklist completion rate | Users finishing all items / Users who saw checklist | > 50% |\n\n### Funnel Analysis Template\n\n```\nSignup 100%\nβββ First login 85% (-15% never return)\nβββ Setup step 1 70% (-15% drop during setup)\nβββ Setup step 2 55% (-15% setup friction)\nβββ First value action 40% (-15% blank slate / confusion)\nβββ Activation event 30% (-10% incomplete value delivery)\nβββ Day-7 return 20% (-10% no habit formed)\n```\n\nFocus optimization on the step with the largest absolute drop.\n\n---\n\n## Experiment Framework\n\n### High-Impact Experiments\n\n| Experiment | Hypothesis | Metric |\n|-----------|-----------|--------|\n| Reduce setup steps | Fewer steps = higher completion | Activation rate |\n| Pre-populate with sample data | Reduces blank slate anxiety | Time to first value action |\n| Add onboarding checklist | Progress visibility increases completion | Onboarding completion rate |\n| Defer email verification | Removes friction before value | Time to activation |\n| Personalize by role/goal | Relevant path increases activation | Activation rate by segment |\n\n### Medium-Impact Experiments\n\n| Experiment | Hypothesis | Metric |\n|-----------|-----------|--------|\n| Welcome video vs text | Video may improve or hurt depending on product | Activation rate + time on first screen |\n| Checklist order change | Value-first ordering improves completion | Checklist completion rate |\n| Guided tour vs self-discover | Tours help complex products | Feature adoption rate |\n| In-app chat during onboarding | Real-time help reduces stalls | Stall rate, activation rate |\n\n---\n\n## Output Artifacts\n\n| Artifact | Format | Description |\n|----------|--------|-------------|\n| Activation Definition Doc | Structured definition | Aha moment, activation event, success metric, measurement plan |\n| Onboarding Flow Diagram | Step-by-step flow | Post-signup flow with drop-off points and decision branches |\n| Checklist Specification | Item-by-item design | 3-7 items with action, rationale, time estimate, and CTA |\n| Email Trigger Map | Trigger/timing/goal table | Conditions and content for each onboarding email |\n| Empty State Copy | Per-screen design | Illustration description, headline, body, CTA for each empty state |\n| Experiment Backlog | Prioritized table | Test ideas ranked by expected impact and effort |\n| Stalled User Playbook | Decision tree | Detection criteria, recovery tactics, escalation rules |\n\n---\n\n## Related Skills\n\n- **signup-flow-cro** -- Use for optimizing the registration flow before users enter the product. Onboarding-cro starts after signup is complete.\n- **paywall-upgrade-cro** -- Use when onboarding leads into upgrade moments. Do not show paywalls before the aha moment is reached.\n- **churn-prevention** -- Use when users activate but then churn. If they never activate, the problem is onboarding, not churn.\n- **page-cro** -- Use when the marketing page before signup is the bottleneck, not the post-signup experience.\n\n---\n\n## Tool Reference\n\n### 1. activation_funnel_analyzer.py\n\n**Purpose:** Analyze an onboarding activation funnel to identify the biggest drop-off points and estimate the impact of fixing each step.\n\n```bash\npython scripts/activation_funnel_analyzer.py funnel_data.json\npython scripts/activation_funnel_analyzer.py funnel_data.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `funnel_data.json` | Yes | JSON file with funnel step names and user counts |\n| `--json` | No | Output results as JSON |\n\n### 2. onboarding_checklist_scorer.py\n\n**Purpose:** Score an onboarding checklist design against best practices (item count, ordering, quick wins, progress indication).\n\n```bash\npython scripts/onboarding_checklist_scorer.py checklist.json\npython scripts/onboarding_checklist_scorer.py checklist.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `checklist.json` | Yes | JSON file with checklist items and their properties |\n| `--json` | No | Output results as JSON |\n\n### 3. ttv_estimator.py\n\n**Purpose:** Estimate time-to-value (TTV) based on onboarding steps and identify bottlenecks that can be reduced or eliminated.\n\n```bash\npython scripts/ttv_estimator.py onboarding_steps.json\npython scripts/ttv_estimator.py onboarding_steps.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `onboarding_steps.json` | Yes | JSON file with onboarding steps, estimated minutes, and requirements |\n| `--json` | No | Output results as JSON |\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Solution |\n|---------|-------------|----------|\n| Activation rate below 25% (B2B) or 40% (B2C) | Aha moment not reached fast enough | Run ttv_estimator.py to identify TTV bottlenecks; target first value within 5 minutes |\n| Users complete onboarding but do not return Day 7 | Onboarding leads to setup, not to value | Restructure flow so the first session delivers a meaningful output, not just configuration |\n| Onboarding checklist completion below 50% | Too many items or first item is too complex | Reduce to 3-7 items; start with a quick win completable in under 60 seconds; use onboarding_checklist_scorer.py to audit |\n| Stalled users at 40%+ of signups | Blank slate problem or unclear next step | Add pre-populated sample data and empty state CTAs; implement stalled user recovery emails at 24h and 72h |\n| Day-1 retention below 30% | First-run experience has dead ends or confusion | Apply the 30-second rule: within 30 seconds, user sees a single next action, understands the value, and has a path forward |\n| Email onboarding sequences have low open rates | Generic subject lines or wrong timing | Personalize subject lines to reference the specific next step; send at trigger-based timing, not fixed schedules |\n| Team invite rate is low | Invite step placed before value is demonstrated | Defer team invite until after the user has experienced core value individually |\n\n---\n\n## Success Criteria\n\n- Activation rate of 30-40% within 14 days for B2B (40-60% for B2C)\n- Time-to-first-value under 5 minutes (verified by ttv_estimator.py)\n- Onboarding completion rate above 60%\n- Day-1 retention above 40%\n- Day-7 retention above 25%\n- Stalled user recovery emails achieve 10%+ reactivation rate\n- Onboarding checklist scores 70+ on onboarding_checklist_scorer.py assessment\n\n---\n\n## Scope & Limitations\n\n- **In scope:** Activation definition, onboarding flow design, time-to-value engineering, empty state design, checklist design, tooltip/tour design, email coordination, stalled user recovery, experiment design\n- **Out of scope:** Signup/registration flow (use signup-flow-cro), marketing page optimization (use page-cro), long-term retention strategy, feature development\n- **Data dependency:** Best results require funnel analytics (per-step drop-off data); without this, optimization is based on heuristics\n- **Product type matters:** B2B SaaS, marketplace, mobile app, and content platforms have fundamentally different onboarding patterns; use the correct pattern for your product type\n- **No silver bullet:** If the product does not deliver value, no amount of onboarding optimization will fix retention; validate product-market fit first\n\n---\n\n## Integration Points\n\n- **signup-flow-cro** -- Optimizes the registration flow before onboarding begins; hand-off point is the moment after successful account creation\n- **churn-prevention** -- When users activate but then churn, the problem shifts from onboarding to retention; use churn-prevention for post-activation churn\n- **paywall-upgrade-cro** -- Upgrade prompts should only appear after the aha moment is reached; never show paywalls during initial onboarding\n- **page-cro** -- When the bottleneck is the marketing page (users are not signing up), optimize the page before optimizing onboarding\n- **customer-success-manager** -- For enterprise accounts, human-assisted onboarding complements product-led flows; CS team should monitor activation metrics","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/onboarding-cro","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/onboarding-cro/SKILL.md","defaultBranch":"main"},"readme":"# Onboarding CRO\n\nProduction-grade user onboarding optimization framework covering activation definition, time-to-value engineering, flow architecture, empty state design, multi-channel coordination, stalled user recovery, and experiment design. Focused on the critical window between signup and habitual product usage.\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [Activation Definition Framework](#activation-definition-framework)\n- [Onboarding Flow Architecture](#onboarding-flow-architecture)\n- [Time-to-Value Engineering](#time-to-value-engineering)\n- [Empty State Design](#empty-state-design)\n- [Onboarding Patterns by Product Type](#onboarding-patterns-by-product-type)\n- [Multi-Channel Coordination](#multi-channel-coordination)\n- [Stalled User Recovery](#stalled-user-recovery)\n- [Onboarding Checklist Design](#onboarding-checklist-design)\n- [Tooltip and Tour Design](#tooltip-and-tour-design)\n- [Metrics and Measurement](#metrics-and-measurement)\n- [Experiment Framework](#experiment-framework)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore designing the onboarding, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Product type** β B2B SaaS, B2C app, marketplace, or content platform (selects the onboarding pattern)\n- [ ] **Activation event (aha moment)** β the action correlated with 30-day retention (defines what the whole flow drives toward)\n- [ ] **Current activation rate + where users drop off** β baseline and the biggest funnel bottleneck to fix\n- [ ] **Day-1/7/30 retention** β sets urgency and whether the problem is onboarding vs product-market fit\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| What is the product type? (B2B SaaS, B2C app, marketplace, content platform) | Determines the onboarding pattern |\n| What is the core value proposition? | Defines what the aha moment should demonstrate |\n| What happens immediately after signup? | Identifies the current first-run experience |\n| What action correlates most with 30-day retention? | Defines the activation event |\n| Where do users drop off? (funnel data if available) | Pinpoints the biggest bottleneck |\n| What is the current activation rate? | Baseline for improvement |\n| What is Day-1 / Day-7 / Day-30 retention? | Context for urgency |\n\n---\n\n## Activation Definition Framework\n\n### Finding the Aha Moment\n\nThe aha moment is the specific action that, once completed, makes a user significantly more likely to retain. It is NOT a feature -- it is the moment the user experiences the core value.\n\n**Method to identify it:**\n\n1. **Cohort comparison:** Compare 90-day retained users vs churned users. What actions did retained users do in the first 7 days that churned users did not?\n2. **Correlation analysis:** For each candidate action, calculate the correlation between completing that action in week 1 and being retained at day 30.\n3. **Timing analysis:** When do retained users complete this action? (Day 1? Day 3? Day 7?)\n\n### Activation Event Examples\n\n| Product Type | Activation Event | Why This Works |\n|-------------|-----------------|----------------|\n| Project management | Create project + invite 1 team member | Collaboration creates switching costs |\n| Analytics tool | Install tracking + view first report | Seeing their own data is the value |\n| Design tool | Create first design + export or share | Output = value realized |\n| CRM | Import contacts + log first activity | Data investment creates lock-in |\n| Marketplace | Complete first transaction | Transaction = value delivered |\n| Content platform | Follow 3+ sources + consume 5+ items | Personalization drives habit |\n| Communication tool | Send first message + get a reply | Two-sided value activatio","createdAt":"2026-09-25T13:52:02.762Z","updatedAt":"2026-09-25T13:52:02.762Z"},{"id":"cmuh0s8nu03qpqu061dsa05v9","slug":"borghei-claude-skills-page-cro","name":"page-cro","description":"Landing page and marketing page conversion rate optimization covering value proposition clarity, headline effectiveness, CTA hierarchy, visual flow, social proof placement, objection handling, and structured A/B testing.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"page-cro","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Landing page and marketing page conversion rate optimization covering value proposition clarity, headline effectiveness, CTA hierarchy, visual flow, social proof placement, objection handling, and structured A/B testing.","permissions":[],"systemPrompt":"# Page CRO\n\nProduction-grade conversion rate optimization framework for marketing pages. Covers the 7-dimension analysis framework, page-type-specific playbooks, copy alternatives methodology, above-the-fold engineering, social proof hierarchy, objection handling patterns, and structured A/B test design.\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [The 7-Dimension CRO Framework](#the-7-dimension-cro-framework)\n- [Above-the-Fold Engineering](#above-the-fold-engineering)\n- [Social Proof Hierarchy](#social-proof-hierarchy)\n- [Objection Handling Architecture](#objection-handling-architecture)\n- [Page-Type Playbooks](#page-type-playbooks)\n- [Copy Alternatives Methodology](#copy-alternatives-methodology)\n- [Traffic Source Matching](#traffic-source-matching)\n- [A/B Test Framework](#ab-test-framework)\n- [Metrics and Benchmarks](#metrics-and-benchmarks)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore optimizing the page, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Page type** β homepage, landing page, pricing, feature, or blog (selects the page-type playbook and benchmark)\n- [ ] **Traffic source** β organic, paid, email, or social (drives message-match requirements)\n- [ ] **Primary conversion goal + current rate** β focuses the 7-dimension analysis and sets the baseline\n- [ ] **Behavioral data available** β heatmaps / session recordings (reveals friction that analytics alone cannot)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the audit.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| What page type? (homepage, landing page, pricing, feature, blog) | Determines the CRO framework to apply |\n| What is the primary conversion goal? | Focuses the analysis |\n| Where is traffic coming from? (organic, paid, email, social) | Drives message-match requirements |\n| What is the current conversion rate? | Establishes the baseline |\n| What does the post-click flow look like? | The page may convert fine but the next step fails |\n| Do you have heatmaps or session recordings? | Behavioral data reveals what analytics cannot |\n| What have you already tried? | Avoids re-testing failed experiments |\n\n---\n\n## The 7-Dimension CRO Framework\n\nAnalyze every marketing page across these 7 dimensions, in order of typical impact.\n\n### Dimension 1: Value Proposition Clarity (Highest Impact)\n\n**The 5-second test:** Can a first-time visitor understand what this is, who it is for, and why they should care within 5 seconds?\n\n| Signal | Pass | Fail |\n|--------|------|------|\n| Primary benefit is stated explicitly | \"Save 10 hours/week on reporting\" | \"Next-generation analytics platform\" |\n| Written in customer language | \"See which campaigns drive revenue\" | \"Multi-touch attribution solution\" |\n| Differentiator is clear | \"The only CRM built for agencies\" | \"A better CRM\" |\n| Specificity | Includes numbers, timeframes, outcomes | Vague superlatives (\"powerful\", \"innovative\") |\n\n### Dimension 2: Headline Effectiveness\n\n**Headline scoring rubric:**\n\n| Criteria | Score 0 | Score 1 | Score 2 |\n|----------|---------|---------|---------|\n| Communicates core value | No | Partially | Clearly |\n| Specific (numbers, outcomes) | Generic | Somewhat specific | Very specific |\n| Addresses target audience | Generic | Implied | Explicit |\n| Matches traffic source | No connection | Loose match | Exact message match |\n| Emotional or logical hook | Neither | One | Both |\n\n**Total: 0-10. Score < 6 = rewrite needed.**\n\n### Dimension 3: CTA Hierarchy and Placement\n\n| Check | Pass | Fail |\n|-------|------|------|\n| One clear primary CTA | Single, prominent action | Multiple competing CTAs |\n| CTA visible without scrolling | Above the fold | Below the fold only |\n| CTA copy communicates value | \"Start Free Trial\" | \"Submit\" |\n| CTA repeated at decision points | After benefits, after social proof, at bottom | Only at top or only at bottom |\n| Secondary CTA is clearly secondary | Smaller, different color, text link | Same visual weight as primary |\n\n### Dimension 4: Visual Hierarchy and Scannability\n\n| Check | Pass | Fail |\n|-------|------|------|\n| Most important element is most prominent | Headline + CTA dominate | Navigation or image dominates |\n| Scannable in 10 seconds | Key points visible via headings, bold, bullets | Wall of text |\n| Adequate white space | Breathing room between sections | Cluttered, dense layout |\n| Images support the message | Product screenshots, relevant imagery | Stock photos, decorative graphics |\n| F-pattern or Z-pattern layout | Content follows natural eye flow | Random placement |\n\n### Dimension 5: Social Proof and Trust\n\n| Check | Pass | Fail |\n|-------|------|------|\n| Customer logos visible | Recognizable logos above the fold | No logos or unknown companies |\n| Testimonials are specific | \"Increased revenue by 40%\" | \"Great product!\" |\n| Testimonials are attributed | Full name, title, company, photo | Anonymous or first-name-only |\n| Trust badges present (where relevant) | Security, compliance, awards | No trust indicators |\n| Numbers-based proof | \"10,000+ teams use...\" | No scale indicators |\n\n### Dimension 6: Objection Handling\n\n| Check | Pass | Fail |\n|-------|------|------|\n| Price/value objection addressed | ROI calculation, \"starts at $X\" | No pricing context |\n| \"Will this work for me?\" answered | Use cases, industry examples | Generic positioning only |\n| Risk reduction offered | Free trial, guarantee, no CC required | No risk reversal |\n| Implementation concern addressed | \"Set up in 5 minutes\" | No setup/complexity context |\n| FAQ section present | Addresses top 5 objections | No FAQ or irrelevant questions |\n\n### Dimension 7: Friction Points\n\n| Check | Pass | Fail |\n|-------|------|------|\n| Form is optimized | Minimal fields, clear labels | Too many fields, unclear purpose |\n| Next step is clear | Obvious path forward from every section | Confusing navigation or dead ends |\n| Mobile experience | Fully responsive, touch-friendly | Desktop-only design |\n| Load time | < 3 seconds | > 5 seconds |\n| No distracting elements | Clean, focused design | Popups, auto-play video, chat widget on load |\n\n---\n\n## Above-the-Fold Engineering\n\nThe above-the-fold area is the most valuable real estate on any page. It determines whether visitors scroll or bounce.\n\n### Required Elements (Above the Fold)\n\n```\nββββββββββββββββββββββββββββββββββββββββββββ\nβ [Nav: Logo + 3-5 links + Primary CTA] β\nββββββββββββββββββββββββββββββββββββββββββββ€\nβ β\nβ HEADLINE: Primary value proposition β\nβ β\nβ SUBHEADLINE: Supporting detail β\nβ β\nβ [PRIMARY CTA BUTTON] β\nβ [Secondary CTA: text link] β\nβ β\nβ [Social proof: logos or stat] β\nβ β\nβ [Hero image or product screenshot] β\nβ β\nββββββββββββββββββββββββββββββββββββββββββββ\n```\n\n### Above-the-Fold Rules\n\n- Headline is the largest text on the page\n- CTA button is the most visually prominent interactive element\n- Social proof appears above the fold (even just logo strip)\n- Hero image shows the product in use (not abstract graphics)\n- No auto-play video or animation that distracts from the CTA\n- Navigation is minimal (3-5 items max, CTA in nav)\n\n---\n\n## Social Proof Hierarchy\n\nNot all social proof is equal. Use the right type at the right location.\n\n### Social Proof Power Ranking\n\n| Rank | Type | Strength | Best Placement |\n|------|------|----------|----------------|\n| 1 | Case study with metrics | \"Company X increased revenue 40% in 3 months\" | Mid-page, after benefits section |\n| 2 | Named testimonial with photo | Full name, title, company, headshot | Near CTA, after objection handling |\n| 3 | Aggregate numbers | \"10,000+ teams\" or \"4.8/5 on G2\" | Above the fold, near headline |\n| 4 | Customer logos | Recognizable brand logos | Above the fold, logo strip |\n| 5 | Awards/badges | \"G2 Leader 2026\", \"SOC2 Certified\" | Footer or near CTA |\n| 6 | Generic testimonial | \"Great product!\" -- no specifics | Do not use (no credibility) |\n\n### Placement Rules\n\n- Logo strip: Above the fold, below the CTA\n- Testimonials: After the section that makes the claim they validate\n- Case studies: Mid-page, as their own section\n- Numbers: Inline with headline or subheadline\n- Trust badges: Near the primary CTA and near the form\n\n---\n\n## Objection Handling Architecture\n\n### The 5 Universal Objections\n\nEvery product page must address these five objections. If the page does not, conversions leak.\n\n| Objection | How to Address | Page Element |\n|-----------|---------------|--------------|\n| \"Is this worth the money?\" | ROI calculator, pricing comparison, \"saves X hours\" | Benefits section + pricing context |\n| \"Will this work for my situation?\" | Industry examples, use case sections, persona targeting | \"Who uses this\" section |\n| \"Is this hard to set up?\" | \"Set up in 5 minutes\", onboarding preview, integration logos | Feature section or FAQ |\n| \"What if it doesn't work?\" | Free trial, money-back guarantee, no CC required | Near CTA |\n| \"Why this over alternatives?\" | Comparison table, differentiators, switcher testimonials | Mid-page or FAQ |\n\n### FAQ Design for Objection Handling\n\nThe FAQ section should be the last defense before conversion. Structure it to address the 5 objections:\n\n1. \"How long does setup take?\" (complexity objection)\n2. \"Can I cancel anytime?\" (commitment objection)\n3. \"What's included in the free trial?\" (value objection)\n4. \"Do you integrate with [popular tool]?\" (compatibility objection)\n5. \"How is this different from [competitor]?\" (alternatives objection)\n\n---\n\n## Page-Type Playbooks\n\n### Homepage\n\n| Element | Best Practice |\n|---------|---------------|\n| Audience | Cold visitors who may not know you |\n| Headline | Position the company, not a single feature |\n| CTA split | Primary: \"Start Free Trial\" / Secondary: \"See Demo\" or \"Learn More\" |\n| Content | Overview of benefits, social proof, feature highlights, use cases |\n| Navigation | Full site navigation (unlike landing pages) |\n\n### Landing Page (Paid Traffic)\n\n| Element | Best Practice |\n|---------|---------------|\n| Navigation | Remove or minimize (no escape routes) |\n| Headline | Message-match with the ad that drove the click |\n| CTA | Single action, repeated 2-3 times down the page |\n| Content | Complete argument on one page: problem > solution > proof > CTA |\n| Social proof | Directly relevant to the ad audience |\n\n### Pricing Page\n\n| Element | Best Practice |\n|---------|---------------|\n| Plan presentation | Good-Better-Best with recommended plan highlighted |\n| Toggle | Annual/Monthly with savings percentage shown |\n| Feature comparison | Full table below the fold |\n| FAQ | \"Which plan is right for me?\" as first question |\n| CTA | Per-plan CTA with plan-specific copy |\n| Social proof | Logos and testimonials relevant to each tier |\n\n### Feature Page\n\n| Element | Best Practice |\n|---------|---------------|\n| Headline | Benefit of the feature, not the feature name |\n| Content | Use cases > technical capabilities |\n| Demo | Screenshot, GIF, or interactive demo |\n| CTA | \"Try this feature\" or \"Start Free Trial\" |\n| Internal links | Link to related features and pricing |\n\n### Blog Post\n\n| Element | Best Practice |\n|---------|---------------|\n| CTA type | Contextual inline CTA matching the content topic |\n| Placement | After introduction, at natural breaks, at end |\n| CTA style | Inline banner or text link, not aggressive popup |\n| Content CTA | Offer a related resource (template, checklist, tool) |\n\n---\n\n## Copy Alternatives Methodology\n\nWhen recommending copy changes, always provide 2-3 alternatives with reasoning.\n\n### Alternative Generation Framework\n\nFor each key element (headline, subheadline, CTA), generate variants across these axes:\n\n| Axis | Variant A | Variant B | Variant C |\n|------|-----------|-----------|-----------|\n| Benefit focus | Outcome-focused | Problem-focused | Feature-focused |\n| Specificity | Numbers and data | Customer quote | Use case scenario |\n| Tone | Direct and assertive | Conversational | Aspirational |\n\n### Example\n\n**Current headline:** \"Marketing Automation Software\"\n\n| Variant | Copy | Rationale |\n|---------|------|-----------|\n| A (outcome) | \"Generate 3X More Qualified Leads Without Adding Headcount\" | Specific outcome + pain point |\n| B (problem) | \"Stop Losing Leads Because Your Team Can't Follow Up Fast Enough\" | Addresses the pain directly |\n| C (social proof) | \"How 2,000+ Marketing Teams Hit Their Pipeline Targets\" | Authority + specificity |\n\n**Recommendation:** Test A first (most specific), B if A does not outperform current (different psychological angle).\n\n---\n\n## Traffic Source Matching\n\nDifferent traffic sources require different page optimization strategies.\n\n| Source | Visitor State | Page Must Do |\n|--------|-------------|-------------|\n| Paid search (brand) | Knows you, high intent | Fast path to action, minimal education |\n| Paid search (non-brand) | Problem-aware, solution-seeking | Prove you solve their specific problem |\n| Paid social | Interrupted, low intent | Hook attention, educate, build interest |\n| Organic search | Research-mode | Comprehensive content, gradual conversion |\n| Email | Already engaged | Deliver on the email promise, reduce friction |\n| Referral | Pre-sold by referrer | Validate referrer's recommendation, fast CTA |\n\n### Message Match Audit\n\nFor paid traffic: Compare the ad copy with the landing page headline. They must share:\n- The same language/terminology\n- The same promise\n- The same offer\n- Visual consistency (if display ad)\n\n**Mismatch = wasted ad spend.** Users who click an ad about \"free SEO audit\" and land on a generic homepage will bounce.\n\n---\n\n## A/B Test Framework\n\n### Test Priority Matrix\n\n| Priority | What to Test | Expected Impact |\n|----------|-------------|-----------------|\n| 1 | Headline copy | 10-30% conversion lift |\n| 2 | CTA copy and color | 5-20% conversion lift |\n| 3 | Social proof placement | 5-15% conversion lift |\n| 4 | Above-the-fold layout | 5-20% conversion lift |\n| 5 | Form field reduction | 5-10% completion lift |\n| 6 | Hero image vs video | 2-10% lift (variable) |\n\n### Test Design Rules\n\n- One variable per test (unless running a multivariate test with sufficient traffic)\n- Minimum 200 conversions per variant before declaring a winner\n- Run for full business cycles (minimum 2 weeks)\n- Track downstream metrics (not just page conversion, but lead quality / revenue)\n\n### Fix vs Test Decision\n\n| Situation | Action |\n|-----------|--------|\n| Obvious UX problem (broken form, missing CTA) | Fix immediately, no test needed |\n| Missing social proof | Add it, no test needed |\n| Headline copy alternative | A/B test |\n| Layout change | A/B test |\n| Removing page elements | A/B test |\n| Adding a new section | A/B test |\n\n---\n\n## Metrics and Benchmarks\n\n### Conversion Rate Benchmarks\n\n| Page Type | Below Average | Average | Good | Excellent |\n|-----------|-------------|---------|------|-----------|\n| SaaS homepage | < 2% | 2-4% | 4-7% | > 7% |\n| Landing page (paid) | < 5% | 5-10% | 10-20% | > 20% |\n| Pricing page | < 3% | 3-5% | 5-10% | > 10% |\n| Blog post (to email) | < 1% | 1-3% | 3-5% | > 5% |\n| Feature page | < 2% | 2-5% | 5-8% | > 8% |\n\n### Key Metrics\n\n| Metric | What It Tells You |\n|--------|------------------|\n| Bounce rate | Is the page meeting visitor expectations? |\n| Scroll depth | How much of the page are visitors seeing? |\n| Time on page | Are visitors reading or immediately leaving? |\n| CTA click rate | Is the CTA compelling and visible? |\n| Form start rate | Are visitors beginning the conversion process? |\n| Form completion rate | Are they finishing it? |\n\n---\n\n## Output Artifacts\n\n| Artifact | Format | Description |\n|----------|--------|-------------|\n| CRO Audit Report | 7-dimension analysis | Per-dimension assessment with severity ratings |\n| Quick Wins List | Bullet list (max 5) | Implementable today with expected impact |\n| High-Impact Recommendations | Structured list | Each with rationale, effort estimate, and success metric |\n| Copy Alternatives | Side-by-side table | 2-3 variants per key element with reasoning |\n| A/B Test Plan | Prioritized table | Hypothesis, variant, success metric, priority |\n| Traffic Source Matching Audit | Source x page element table | Message match assessment per traffic source |\n\n---\n\n## Related Skills\n\n- **form-cro** -- Use when the form on the page is the specific bottleneck (field optimization, validation, mobile form UX).\n- **signup-flow-cro** -- Use when users convert on the page but drop off during the signup/registration process.\n- **popup-cro** -- Use when considering a popup as an additional conversion layer on the page.\n- **onboarding-cro** -- Use when post-conversion activation is the real problem and the page itself converts adequately.\n- **pricing-strategy** -- Use when the pricing page needs structural redesign (tier structure, value metric), not just CRO tweaks.\n\n---\n\n## Tool Reference\n\n### 1. page_cro_scorer.py\n\n**Purpose:** Score a marketing page across the 7 CRO dimensions and generate an audit report with severity ratings.\n\n```bash\npython scripts/page_cro_scorer.py page_audit.json\npython scripts/page_cro_scorer.py page_audit.json --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `page_audit.json` | Yes | JSON file with page elements and dimension checks |\n| `--json` | No | Output results as JSON |\n\n### 2. headline_scorer.py\n\n**Purpose:** Score headline effectiveness against the 5-criteria rubric and generate copy alternatives.\n\n```bash\npython scripts/headline_scorer.py --headline \"Marketing Automation Software\" --audience \"B2B marketers\" --traffic-source paid-search\npython scripts/headline_scorer.py --headline \"Marketing Automation Software\" --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `--headline` | Yes | The headline text to score |\n| `--audience` | No | Target audience description (default: \"general\") |\n| `--traffic-source` | No | Primary traffic source: organic, paid-search, paid-social, email, referral (default: organic) |\n| `--json` | No | Output results as JSON |\n\n### 3. conversion_benchmark_calculator.py\n\n**Purpose:** Calculate conversion rate benchmarks for a given page type, traffic source, and industry, and assess current performance.\n\n```bash\npython scripts/conversion_benchmark_calculator.py --page-type landing-page --traffic paid --current-rate 8.5\npython scripts/conversion_benchmark_calculator.py --page-type homepage --traffic organic --current-rate 3.0 --json\n```\n\n| Flag | Required | Description |\n|------|----------|-------------|\n| `--page-type` | Yes | Page type: homepage, landing-page, pricing, feature, blog |\n| `--traffic` | Yes | Traffic source: organic, paid, email, social, referral |\n| `--current-rate` | Yes | Current conversion rate as percentage |\n| `--industry` | No | Industry for benchmarks: saas, ecommerce, fintech, healthcare, education (default: saas) |\n| `--json` | No | Output results as JSON |\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Solution |\n|---------|-------------|----------|\n| High bounce rate (>70%) on landing page | Message mismatch with traffic source or poor above-the-fold | Audit message match: compare ad copy with landing page headline; ensure value proposition is visible in first 5 seconds |\n| Page converts on desktop but not mobile | Mobile UX not optimized | Check touch targets (44px+), form field count on mobile, CTA visibility without scrolling; score with page_cro_scorer.py |\n| CTA click rate below 2% | CTA is generic, below the fold, or visually weak | Replace \"Submit\" with value-specific copy; ensure CTA is visible above fold and repeated after key sections |\n| High scroll depth but low conversion | Visitors read but are not convinced to act | Add social proof near CTA positions; address objections in FAQ; add risk reversal (free trial, no CC) |\n| A/B test shows no significant winner after 4 weeks | Change too small to detect or insufficient traffic | Use ab_test_calculator.py from form-cro to validate sample size; test bigger changes (headline rewrite vs word swap) |\n| Paid traffic converts worse than organic | Landing page not tailored to paid traffic intent | Create dedicated landing pages for paid campaigns with message match; remove navigation on paid landing pages |\n| Social proof section is ignored | Generic testimonials or poor placement | Use specific, attributed testimonials with metrics; place after the section that makes the claim they validate |\n\n---\n\n## Success Criteria\n\n- Page CRO score of 70+ across the 7-dimension framework (scored by page_cro_scorer.py)\n- Headline scores 7+ on the 10-point rubric (scored by headline_scorer.py)\n- Conversion rate at or above industry benchmark for page type (verified by conversion_benchmark_calculator.py)\n- Above-the-fold contains: headline, CTA, and at least one social proof element\n- Message match verified for all paid traffic campaigns (ad copy matches landing page headline)\n- Mobile conversion rate within 20% of desktop rate\n- Every page addresses at least 3 of the 5 universal objections\n\n---\n\n## Scope & Limitations\n\n- **In scope:** Page-level conversion optimization, headline effectiveness, CTA hierarchy, social proof placement, objection handling, traffic source matching, A/B test prioritization\n- **Out of scope:** Form optimization (use form-cro), signup flow optimization (use signup-flow-cro), popup optimization (use popup-cro), pricing structure changes (use pricing-strategy)\n- **Page speed:** This skill covers CRO elements, not technical performance; pages loading >3 seconds need technical optimization first\n- **Traffic minimum:** A/B testing recommendations require 200+ conversions per variant; low-traffic pages should implement best practices without testing\n- **Qualitative input:** Heatmaps and session recordings provide critical behavioral data that analytics alone cannot reveal; consider investing in these tools\n\n---\n\n## Integration Points\n\n- **form-cro** -- When the form on the page is the bottleneck (field optimization, validation UX, mobile form experience)\n- **signup-flow-cro** -- When users convert on the page but drop off during the signup/registration process\n- **popup-cro** -- When considering a popup as an additional conversion layer on top of the page\n- **onboarding-cro** -- When post-conversion activation is the real problem and the page itself converts adequately\n- **pricing-strategy** -- When the pricing page needs structural redesign (tier structure, value metric), not just CRO tweaks\n- **competitive-teardown** -- When comparison pages need competitive data to build credible content","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/page-cro","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/page-cro/SKILL.md","defaultBranch":"main"},"readme":"# Page CRO\n\nProduction-grade conversion rate optimization framework for marketing pages. Covers the 7-dimension analysis framework, page-type-specific playbooks, copy alternatives methodology, above-the-fold engineering, social proof hierarchy, objection handling patterns, and structured A/B test design.\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [The 7-Dimension CRO Framework](#the-7-dimension-cro-framework)\n- [Above-the-Fold Engineering](#above-the-fold-engineering)\n- [Social Proof Hierarchy](#social-proof-hierarchy)\n- [Objection Handling Architecture](#objection-handling-architecture)\n- [Page-Type Playbooks](#page-type-playbooks)\n- [Copy Alternatives Methodology](#copy-alternatives-methodology)\n- [Traffic Source Matching](#traffic-source-matching)\n- [A/B Test Framework](#ab-test-framework)\n- [Metrics and Benchmarks](#metrics-and-benchmarks)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore optimizing the page, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Page type** β homepage, landing page, pricing, feature, or blog (selects the page-type playbook and benchmark)\n- [ ] **Traffic source** β organic, paid, email, or social (drives message-match requirements)\n- [ ] **Primary conversion goal + current rate** β focuses the 7-dimension analysis and sets the baseline\n- [ ] **Behavioral data available** β heatmaps / session recordings (reveals friction that analytics alone cannot)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the audit.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| What page type? (homepage, landing page, pricing, feature, blog) | Determines the CRO framework to apply |\n| What is the primary conversion goal? | Focuses the analysis |\n| Where is traffic coming from? (organic, paid, email, social) | Drives message-match requirements |\n| What is the current conversion rate? | Establishes the baseline |\n| What does the post-click flow look like? | The page may convert fine but the next step fails |\n| Do you have heatmaps or session recordings? | Behavioral data reveals what analytics cannot |\n| What have you already tried? | Avoids re-testing failed experiments |\n\n---\n\n## The 7-Dimension CRO Framework\n\nAnalyze every marketing page across these 7 dimensions, in order of typical impact.\n\n### Dimension 1: Value Proposition Clarity (Highest Impact)\n\n**The 5-second test:** Can a first-time visitor understand what this is, who it is for, and why they should care within 5 seconds?\n\n| Signal | Pass | Fail |\n|--------|------|------|\n| Primary benefit is stated explicitly | \"Save 10 hours/week on reporting\" | \"Next-generation analytics platform\" |\n| Written in customer language | \"See which campaigns drive revenue\" | \"Multi-touch attribution solution\" |\n| Differentiator is clear | \"The only CRM built for agencies\" | \"A better CRM\" |\n| Specificity | Includes numbers, timeframes, outcomes | Vague superlatives (\"powerful\", \"innovative\") |\n\n### Dimension 2: Headline Effectiveness\n\n**Headline scoring rubric:**\n\n| Criteria | Score 0 | Score 1 | Score 2 |\n|----------|---------|---------|---------|\n| Communicates core value | No | Partially | Clearly |\n| Specific (numbers, outcomes) | Generic | Somewhat specific | Very specific |\n| Addresses target audience | Generic | Implied | Explicit |\n| Matches traffic source | No connection | Loose match | Exact message match |\n| Emotional or logical hook | Neither | One | Both |\n\n**Total: 0-10. Score < 6 = rewrite needed.**\n\n### Dimension 3: CTA Hierarchy and Placement\n\n| Check | Pass | Fail |\n|-------|------|------|\n| One clear primary CTA | Single, prominent action | Multiple competing CTAs |\n| CTA visible without scrolling | Above the fold | Below the fold only |\n| CTA copy communicates value | \"Start Free Trial\" | \"Submi","createdAt":"2026-09-25T13:52:02.778Z","updatedAt":"2026-09-25T13:52:02.778Z"},{"id":"cmuh0s8o803qvqu0615gzhhk4","slug":"borghei-claude-skills-partnerships-architect","name":"partnerships-architect","description":"Design strategic partnerships β technology, channel, co-marketing β and the programs that scale them. Use when evaluating a partner, picking a partnership type, designing a partner program, structuring a deal, or modeling ROI.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"partnerships-architect","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Design strategic partnerships β technology, channel, co-marketing β and the programs that scale them. Use when evaluating a partner, picking a partnership type, designing a partner program, structuring a deal, or modeling ROI.","permissions":[],"systemPrompt":"# Partnerships Architect\n\nEnd-to-end strategic partnership design and scaling: partnership type selection (tech integration vs channel vs OEM vs strategic), deal structures, partner program design (tiers, benefits, requirements), partner evaluation, and ROI modeling that justifies (or kills) a partnership investment.\n\nThis skill is provider-agnostic and works across SaaS, infrastructure, marketplace, and platform companies.\n\n---\n\n## When to use this skill\n\n| Situation | Skill applies |\n|-----------|---------------|\n| Evaluating a potential partner | Yes β use `scripts/partner_evaluation_scorer.py` + **evaluation framework** |\n| Picking partnership type for a specific opportunity | Yes β see **partnership type decision tree** |\n| Designing a partner program from scratch | Yes β see **partner program design** + `scripts/partner_program_designer.py` |\n| Structuring a specific partnership deal | Yes β see **partnership deal structures** |\n| Modeling partnership ROI | Yes β `scripts/partnership_roi_modeler.py` |\n| Auditing existing partner portfolio | Yes β use evaluation scorer across all partners |\n| Per-deal partner economics | Use `business-growth/channel-economics` |\n| Per-deal partner approval | Use `business-growth/deal-desk` |\n| Writing the partner contract | Use `business-growth/contract-and-proposal-writer` |\n\n---\n\n## Partnership types β the decision tree\n\nFive primary partnership types. Different goals; different structures; different success metrics.\n\n```\nWhat's the primary goal of this partnership?\n\nGrow our distribution reach\nβββ Customer-pays-them, they-pay-us β Reseller / Distributor / VAR\nβββ Customer-pays-us, we-pay-them β Affiliate / Referral\nβββ Joint sale to mutual customer β Co-sell\n\nEmbed our product in their offering\nβββ Customer doesn't see us (white-label) β OEM\nβββ Customer sees us as embedded β Embedded ISV / Powered-by\nβββ We're an option in their marketplace β Marketplace listing\n\nCombine our product with theirs (better together)\nβββ Pre-integrated, certified β Tech / Integration Partner\nβββ Bundled offering β Solution Partner\nβββ Joint product (rare) β Joint Venture\n\nBuild market presence together\nβββ Joint events, content, PR β Co-marketing Partner\nβββ Industry positioning β Strategic Alliance\nβββ Standards / consortium β Standards Partner\n\nAchieve a specific strategic goal\nβββ Block a competitor β Defensive partnership\nβββ Enter a new market β Market entry partnership\nβββ Acquire capability β Strategic alliance (often pre-acquisition)\n```\n\nSee [references/partnership-types.md](references/partnership-types.md) for each type in depth: economic structure, contract patterns, KPIs, when each works / fails.\n\n---\n\n## Partner evaluation framework\n\nNot every potential partner is worth the investment. Use this framework before committing.\n\n### Six evaluation dimensions\n\n| Dimension | What to assess | Score (1-5) |\n|-----------|----------------|-------------|\n| **Strategic fit** | Does this partnership advance our strategy? Customer base overlap / vertical / region? | |\n| **Economic potential** | Realistic pipeline / revenue contribution over 24 months? | |\n| **Partner credibility** | Brand, financial stability, technical capability, customer references | |\n| **Mutual commitment** | Are they investing equally? Senior sponsor on their side? Resources committed? | |\n| **Operational fit** | Can our systems / processes / culture work together? | |\n| **Exit-ability** | If it doesn't work, can we wind down cleanly? Are we creating dependencies we can't reverse? |\n\n### Scoring rubric\n\n- 5 β strong yes\n- 4 β yes with minor caveats\n- 3 β mixed; substantial uncertainty\n- 2 β weak; significant concerns\n- 1 β no; deal-breaker\n\n**Total 25-30**: green-light; invest with confidence\n**Total 18-24**: yellow; structure carefully; small pilot first\n**Total < 18**: red; decline or substantially restructure\n\nUse `scripts/partner_evaluation_scorer.py --partner partner.yaml` to score a specific potential partner.\n\n### Killer questions to ask\n\nBefore signing any significant partnership:\n\n1. **What does success look like in 12 months?** If both sides can't articulate the same answer, you don't have alignment.\n2. **What's their commitment level?** Headcount assigned? Budget? Executive sponsorship?\n3. **What's the realistic pipeline in next 12 months?** Specific accounts? Or vague \"we have customers\"?\n4. **Who's the day-to-day owner on each side?** Names + tenure + reporting line.\n5. **What happens if we don't hit our shared metrics?** Course-correct? Wind down? Renegotiate?\n\nIf you can't get clear answers, the partnership is wishful thinking.\n\n---\n\n## Partnership deal structures\n\nDifferent deal types call for different structures. Standard patterns:\n\n### Structure A: Standard reseller agreement\n\n- **Term**: 1-3 years, auto-renew\n- **Discount**: per published tier matrix\n- **Exclusivity**: usually non-exclusive\n- **Termination**: 90-day notice both sides\n- **Use when**: typical channel relationship\n\n### Structure B: Co-sell agreement (mutual customer)\n\n- **Term**: 1-2 years\n- **Compensation**: shared commission OR referral fee\n- **Joint marketing commitment**: optional\n- **Use when**: complementary offerings; existing or target shared customers\n\n### Structure C: OEM agreement\n\n- **Term**: 3-7 years (long; relationship-heavy)\n- **Royalty / rev-share**: % of partner revenue OR per-instance fee\n- **Exclusivity**: often partial (specific use case / market)\n- **Source code escrow**: usually required\n- **Termination**: complex (typically 12-24 months notice; transition rights)\n- **Use when**: deeply embedded technical relationship; high mutual investment\n\n### Structure D: Strategic alliance\n\n- **Term**: open-ended; reviewed annually\n- **Resources committed**: explicit (e.g., 2 FTEs per side, $X budget per year, joint roadmap session quarterly)\n- **Governance**: steering committee (executive sponsors meet quarterly)\n- **Specific deliverables**: joint product features, joint customer wins, joint thought leadership\n- **Use when**: 5+ year strategic relationship; not transactional\n\n### Structure E: Tech / integration partnership\n\n- **Term**: 1-3 years\n- **Compensation**: typically none direct; mutual value from joint customers\n- **Certification process**: defined (testing, documentation)\n- **Marketplace listing**: typically included\n- **Co-marketing**: optional but common\n- **Use when**: integration creates joint customer value; no direct revenue flow\n\nSee [references/partnership-deal-structures.md](references/partnership-deal-structures.md) for the full deal-structure templates with negotiation guides.\n\n---\n\n## Partner program design\n\nWhen you scale beyond a few partners, you need a program.\n\n### Three pillars of a partner program\n\n| Pillar | Components |\n|--------|------------|\n| **Recruitment** | Target partner profile; outreach motion; intake / qualification; onboarding |\n| **Enablement** | Training; certification; technical resources; sandbox; partner portal; marketing materials |\n| **Activation** | Deal registration; lead sharing; MDF / co-marketing; co-selling motion; quarterly business reviews |\n\n### Standard program elements\n\n- **Partner agreement** (master): tenant-of-the-relationship\n- **Tier structure** (Authorized β Silver β Gold β Platinum): different benefits + requirements per tier\n- **Deal registration**: protect partner-developed opportunities\n- **Certification program**: train + test partners on your product\n- **Partner portal**: deal reg, MDF, training, marketing materials, lead sharing\n- **MDF (Marketing Development Funds)**: co-funded marketing\n- **Channel manager(s)**: 1 per 10-15 active partners\n- **Annual partner conference**: community building + recognition\n\nSee [references/partner-program-design.md](references/partner-program-design.md) for the full program template including tier definitions, benefit / requirement matrices, and the \"Year 1 / Year 2 / Year 3\" maturity model.\n\nUse `scripts/partner_program_designer.py --org-spec org.yaml` to generate a baseline program design based on company stage + ICP + target partner volume.\n\n---\n\n## Partnership ROI modeling\n\nPartnerships consume real investment. Headcount, MDF, technology, executive time. Model the ROI before committing.\n\n### ROI model template\n\n```\n3-year cumulative partnership P&L\n\nYear 1 (investment year):\n Revenue from partnership: $X\n Costs:\n Partnership manager headcount: $200k\n Engineering integration (one-time): $300k\n Marketing / co-launch: $50k\n Partner enablement (content, training): $50k\n Travel / events: $30k\n TOTAL Y1 cost: $630k\n Y1 net: $X - $630k\n\nYear 2:\n Revenue from partnership: $Y (growth)\n Costs:\n Partnership manager: $200k\n Engineering ongoing: $100k\n Marketing: $80k\n Enablement: $30k\n Travel / events: $40k\n TOTAL Y2 cost: $450k\n Y2 net: $Y - $450k\n\nYear 3:\n Revenue: $Z (mature)\n Costs: $400k (stable)\n Y3 net: $Z - $400k\n\n3-year cumulative net: ($X + $Y + $Z) - $1,480k\n```\n\nIf 3-year cumulative net is negative, the partnership doesn't pay back. Common reasons:\n- Revenue estimates too optimistic\n- Forgotten costs (executive time, opportunity cost)\n- Partner under-performs on commitments\n- Market shift makes the partnership less relevant\n\nUse `scripts/partnership_roi_modeler.py --partnership partnership.yaml` for the full model.\n\n---\n\n## Clarify First\n\nBefore designing the partnership, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Partnership goal + type** β distribution, embed (OEM/ISV), better-together (tech/integration), market presence, or strategic (selects the decision-tree branch and deal structure)\n- [ ] **Single deal vs scaled program** β structuring one partnership vs designing tiers/portfolio (determines deal-structure vs program-design output)\n- [ ] **Partner specifics for evaluation** β their pipeline expectation, commitment, and credibility (feeds the 6-dimension scorer and green/yellow/red call)\n- [ ] **ROI inputs** β expected revenue and the real costs (headcount, integration, MDF) (drives the 3-year P&L payback)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## End-to-end workflows\n\n### Workflow: Evaluate a new partner opportunity\n\n1. **Initial conversation** with potential partner β understand their pitch\n2. **Gather data** for evaluation: their company, their pipeline expectations, their commitment\n3. **Score using evaluation framework** β `scripts/partner_evaluation_scorer.py`\n4. **If score < 18**: decline or pilot-scope only\n5. **If score 18-24**: pilot scope (3-6 months, limited investment)\n6. **If score 25+**: standard partnership agreement; full investment\n\n### Workflow: Stand up a partner program\n\n1. **Define target partner profile (TPP)**: ideal partner attributes (size, vertical, region, capability)\n2. **Pick partnership types** in scope (resellers? OEM? tech partners?)\n3. **Design tier structure** β `scripts/partner_program_designer.py`\n4. **Build foundational tools**: partner portal, deal-reg, certification\n5. **Recruit pilot cohort** (3-5 partners) β manual, high-touch\n6. **Iterate based on pilot feedback** β usually 6 months\n7. **Scale recruitment** β content marketing, outbound, partner events\n8. **Add channel managers** as portfolio grows (1 per 10-15 active partners)\n\n### Workflow: Structure a specific partnership deal\n\n1. **Identify partnership type** using the decision tree\n2. **Score the partner** β `scripts/partner_evaluation_scorer.py`\n3. **Pick deal structure** matching the type\n4. **Model ROI** β `scripts/partnership_roi_modeler.py`\n5. **Draft term sheet** (key business terms)\n6. **Negotiate** β alignment on commitment, timelines, exit\n7. **Legal review** + contract β `business-growth/contract-and-proposal-writer`\n8. **Internal approval** β Deal Desk + CRO/CFO/CEO depending on scale\n\n### Workflow: Audit existing partner portfolio\n\n1. **List all active partners** + key data: revenue, costs, deals, tier\n2. **Score each** against evaluation framework β `scripts/partner_evaluation_scorer.py`\n3. **Identify low-ROI partners** β bottom quartile by contribution per investment hour\n4. **Decide per partner**:\n - **Invest more** (top quartile, expand commitment)\n - **Maintain** (middle, status quo)\n - **Wind down** (bottom; explicit timeline to exit gracefully)\n5. **Quarterly review** of portfolio with CRO\n\n---\n\n## Anti-patterns\n\n- **\"Strategic\" partnership that's actually transactional.** If the only thing exchanging is money, it's transactional; call it that. Strategic means joint goals + shared roadmap + executive commitment.\n- **Partner stack with no portfolio strategy.** Signing every partner that asks. Quality > quantity. 10 productive partners beat 100 zombies.\n- **No partnership owner.** Partnership exists in nobody's job. It withers.\n- **Resource asymmetry.** You commit 3 FTEs; they commit 0.5. The partnership skews to their convenience.\n- **Promises without commitments.** \"We'll do joint webinars.\" When? With what budget? Whose role to organize?\n- **Open-ended exclusivity.** \"Exclusive in this region forever\" without performance gates. Lose flexibility for nothing in return.\n- **OEM deal with no source-code escrow.** Customer-impact risk if your company goes away.\n- **Strategic alliance with no governance.** No quarterly review = no executive engagement = partnership drifts.\n- **Partner program with no enablement.** Partners can't sell what they don't understand.\n- **Tier benefits that aren't worth tier requirements.** Partners don't advance because there's no incentive.\n- **Co-marketing dollars wasted on activities without pipeline.** Great event, zero attribution.\n\n---\n\n## Tooling outputs\n\n| Script | Input | Output |\n|--------|-------|--------|\n| `scripts/partner_evaluation_scorer.py` | Partner spec YAML | 6-dimension score (1-5 each), total, recommendation (green-light / yellow / red) |\n| `scripts/partnership_roi_modeler.py` | Partnership spec YAML | 3-year P&L, payback period, sensitivity analysis |\n| `scripts/partner_program_designer.py` | Org spec YAML | Recommended program structure: tiers, benefits, requirements, headcount needed |\n\nAll scripts: stdlib only, argparse CLI, JSON or markdown output.\n\n---\n\n## References\n\n- [partnership-types.md](references/partnership-types.md) β 5 partnership types in depth + economic structure + when each works\n- [partnership-deal-structures.md](references/partnership-deal-structures.md) β deal templates per type + negotiation guides\n- [partner-program-design.md](references/partner-program-design.md) β full program design with tier matrices + maturity model\n\n---\n\n## Related skills\n\n- `business-growth/channel-economics` β per-deal financial mechanics underneath partnership structure\n- `business-growth/deal-desk` β per-deal approval mechanics for partner-mediated deals\n- `business-growth/pricing-strategy` β pricing flexibility / floor for partner deals\n- `business-growth/contract-and-proposal-writer` β partner contracts (MSA, partner agreement, OEM agreement)\n- `c-level-advisor/cs-cro-advisor` β strategic-level partnership decisions\n- `c-level-advisor/cs-ceo-advisor` β board-level alliance decisions","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/partnerships-architect","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/partnerships-architect/SKILL.md","defaultBranch":"main"},"readme":"# Partnerships Architect\n\nEnd-to-end strategic partnership design and scaling: partnership type selection (tech integration vs channel vs OEM vs strategic), deal structures, partner program design (tiers, benefits, requirements), partner evaluation, and ROI modeling that justifies (or kills) a partnership investment.\n\nThis skill is provider-agnostic and works across SaaS, infrastructure, marketplace, and platform companies.\n\n---\n\n## When to use this skill\n\n| Situation | Skill applies |\n|-----------|---------------|\n| Evaluating a potential partner | Yes β use `scripts/partner_evaluation_scorer.py` + **evaluation framework** |\n| Picking partnership type for a specific opportunity | Yes β see **partnership type decision tree** |\n| Designing a partner program from scratch | Yes β see **partner program design** + `scripts/partner_program_designer.py` |\n| Structuring a specific partnership deal | Yes β see **partnership deal structures** |\n| Modeling partnership ROI | Yes β `scripts/partnership_roi_modeler.py` |\n| Auditing existing partner portfolio | Yes β use evaluation scorer across all partners |\n| Per-deal partner economics | Use `business-growth/channel-economics` |\n| Per-deal partner approval | Use `business-growth/deal-desk` |\n| Writing the partner contract | Use `business-growth/contract-and-proposal-writer` |\n\n---\n\n## Partnership types β the decision tree\n\nFive primary partnership types. Different goals; different structures; different success metrics.\n\n```\nWhat's the primary goal of this partnership?\n\nGrow our distribution reach\nβββ Customer-pays-them, they-pay-us β Reseller / Distributor / VAR\nβββ Customer-pays-us, we-pay-them β Affiliate / Referral\nβββ Joint sale to mutual customer β Co-sell\n\nEmbed our product in their offering\nβββ Customer doesn't see us (white-label) β OEM\nβββ Customer sees us as embedded β Embedded ISV / Powered-by\nβββ We're an option in their marketplace β Marketplace listing\n\nCombine our product with theirs (better together)\nβββ Pre-integrated, certified β Tech / Integration Partner\nβββ Bundled offering β Solution Partner\nβββ Joint product (rare) β Joint Venture\n\nBuild market presence together\nβββ Joint events, content, PR β Co-marketing Partner\nβββ Industry positioning β Strategic Alliance\nβββ Standards / consortium β Standards Partner\n\nAchieve a specific strategic goal\nβββ Block a competitor β Defensive partnership\nβββ Enter a new market β Market entry partnership\nβββ Acquire capability β Strategic alliance (often pre-acquisition)\n```\n\nSee [references/partnership-types.md](references/partnership-types.md) for each type in depth: economic structure, contract patterns, KPIs, when each works / fails.\n\n---\n\n## Partner evaluation framework\n\nNot every potential partner is worth the investment. Use this framework before committing.\n\n### Six evaluation dimensions\n\n| Dimension | What to assess | Score (1-5) |\n|-----------|----------------|-------------|\n| **Strategic fit** | Does this partnership advance our strategy? Customer base overlap / vertical / region? | |\n| **Economic potential** | Realistic pipeline / revenue contribution over 24 months? | |\n| **Partner credibility** | Brand, financial stability, technical capability, customer references | |\n| **Mutual commitment** | Are they investing equally? Senior sponsor on their side? Resources committed? | |\n| **Operational fit** | Can our systems / processes / culture work together? | |\n| **Exit-ability** | If it doesn't work, can we wind down cleanly? Are we creating dependencies we can't reverse? |\n\n### Scoring rubric\n\n- 5 β strong yes\n- 4 β yes with minor caveats\n- 3 β mixed; substantial uncertainty\n- 2 β weak; significant concerns\n- 1 β no; deal-breaker\n\n**Total 25-30**: green-light; invest with confidence\n**Total 18-24**: yellow; structure carefully; small pilot first\n**Total < 18**: red; decline or substantially restructure\n\nUse `scripts/partner_evaluation_scorer.py --partner partner.yaml` to score a specific potential partner.\n\n### Killer questio","createdAt":"2026-09-25T13:52:02.792Z","updatedAt":"2026-09-25T13:52:02.792Z"},{"id":"cmuh0s8on03r4qu068kgksq05","slug":"borghei-claude-skills-paywall-upgrade-cro","name":"paywall-upgrade-cro","description":"In-app paywall and upgrade screen optimization covering feature gate design, usage limit UX, trial expiration flows, upgrade trigger timing, save offer strategy, and ethical monetization patterns.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"paywall-upgrade-cro","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"In-app paywall and upgrade screen optimization covering feature gate design, usage limit UX, trial expiration flows, upgrade trigger timing, save offer strategy, and ethical monetization patterns.","permissions":[],"systemPrompt":"# Paywall & Upgrade Screen CRO\n\nProduction-grade framework for in-product upgrade flows. Covers feature gate design, usage limit UX, trial expiration sequences, upgrade trigger timing, dark pattern avoidance, and ethical monetization. Distinct from public pricing pages (use page-cro for those) -- this focuses on in-product moments where users have already experienced value.\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [The Value-First Principle](#the-value-first-principle)\n- [Paywall Trigger Architecture](#paywall-trigger-architecture)\n- [Paywall Screen Design](#paywall-screen-design)\n- [Feature Gate Patterns](#feature-gate-patterns)\n- [Usage Limit UX](#usage-limit-ux)\n- [Trial Expiration Flows](#trial-expiration-flows)\n- [Timing and Frequency Rules](#timing-and-frequency-rules)\n- [Upgrade Flow Optimization](#upgrade-flow-optimization)\n- [Dark Pattern Avoidance](#dark-pattern-avoidance)\n- [Platform-Specific Considerations](#platform-specific-considerations)\n- [Metrics and Benchmarks](#metrics-and-benchmarks)\n- [A/B Test Framework](#ab-test-framework)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore designing the paywall, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Upgrade model** β freemium-to-paid, trial-to-paid, or tier upgrade (determines the paywall type and trigger architecture)\n- [ ] **Free vs paid boundary** β what is gated (defines the value gap the paywall communicates)\n- [ ] **Aha moment** β so triggers fire only after value is experienced (the value-first principle)\n- [ ] **Platform** β web, iOS, or Android (IAP rules and commissions constrain web vs app flows)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| What is the upgrade model? (freemium to paid, trial to paid, tier upgrade) | Determines the paywall type |\n| What is free vs paid? | Defines the value gap to communicate |\n| What triggers upgrade prompts today? | Identifies current trigger points |\n| What is the current free-to-paid conversion rate? | Baseline for improvement |\n| What is the aha moment for users? | Determines when the paywall should appear |\n| What pricing model? (per seat, usage, flat) | Affects paywall messaging |\n| Mobile app, web app, or both? | Platform-specific requirements |\n\n---\n\n## The Value-First Principle\n\nThe single most important rule in paywall design: **The user must have experienced real value before seeing an upgrade prompt.**\n\n### Value-First Checklist\n\n- [ ] User has completed the activation event (aha moment reached)\n- [ ] User has used the product at least 2-3 times\n- [ ] User has created or stored data they would lose\n- [ ] The upgrade feels like a natural next step, not a trap\n\n### When to Show vs When NOT to Show\n\n| Show | Do Not Show |\n|------|------------|\n| After aha moment is reached | During onboarding |\n| When user hits a genuine limit | On first login |\n| When user clicks a paid feature | When user is in the middle of a task |\n| After milestone completion | Immediately after a frustrating experience |\n| On session start (gentle reminder) | After every action |\n\n---\n\n## Paywall Trigger Architecture\n\n### Trigger Types\n\n| Trigger | When It Fires | Best For |\n|---------|--------------|----------|\n| Feature gate | User clicks a locked feature | Feature-differentiated tiers |\n| Usage limit | User reaches a quota | Usage-based pricing |\n| Trial expiration | Trial period ending | Time-limited trial models |\n| Time-based | After N days of active use | Freemium nurture |\n| Milestone-based | After user achieves X | Upsell at success moments |\n| Team-based | When team grows past free seat limit | Per-seat models |\n\n### Trigger Priority Map\n\n| User State | Primary Trigger | Timing |\n|-----------|----------------|--------|\n| Activated, under limits | Feature gate (when they try paid feature) | On click |\n| Approaching limit | Soft warning (80% of limit) | Proactive |\n| Hit limit | Usage limit paywall | On action that exceeds limit |\n| Trial day 7 of 14 | Trial ending reminder | Session start |\n| Trial day 13 of 14 | Urgent trial expiration | Session start + email |\n| Trial day 14 | Trial expired | On login |\n| Active for 30+ days, free | Value-based upgrade prompt | Session start, once per week |\n\n---\n\n## Paywall Screen Design\n\n### Screen Anatomy\n\n```\nβββββββββββββββββββββββββββββββββββββββ\nβ [X Close / \"Not now\"] β Escape hatch (always visible)\nβ β\nβ HEADLINE: Value-focused β \"Unlock [feature] to [benefit]\"\nβ β\nβ [Feature preview / screenshot] β Show what they are missing\nβ β\nβ KEY BENEFITS: β\nβ - Benefit 1 β\nβ - Benefit 2 β\nβ - Benefit 3 β\nβ β\nβ PRICE: $X/month β Clear, simple pricing\nβ (or plan comparison) β\nβ β\nβ [UPGRADE CTA - Primary] β \"Start Pro Plan\"\nβ [Maybe Later - Secondary] β Clear secondary action\nβ β\nβ \"Join 5,000+ teams on Pro\" β Social proof\nβββββββββββββββββββββββββββββββββββββββ\n```\n\n### Copy Patterns by Trigger Type\n\n| Trigger | Headline Pattern | CTA Pattern |\n|---------|-----------------|-------------|\n| Feature gate | \"Unlock [Feature] to [Benefit]\" | \"Upgrade to [Plan]\" |\n| Usage limit | \"You've used all [N] [resources]\" | \"Get Unlimited [Resources]\" |\n| Trial expiring | \"Your trial ends in [N] days\" | \"Continue with [Plan]\" |\n| Milestone | \"You just hit [milestone]! Keep growing with Pro\" | \"Upgrade & Keep Growing\" |\n| Time-based | \"[Product] Pro helps teams like yours [benefit]\" | \"See Pro Features\" |\n\n---\n\n## Feature Gate Patterns\n\n### Soft Gate (Preview + Lock)\n\nUser can see what the feature does but cannot use it fully.\n\n```\nββββββββββββββββββββββββββββββββ\nβ [Feature Preview] β Blurred screenshot or partial result\nβ β\nβ [Lock Icon] Pro Feature β\nβ β\nβ [Feature name] lets you: β\nβ - Capability 1 β\nβ - Capability 2 β\nβ β\nβ [Upgrade to Pro - $X/mo] β\nβ [Maybe Later] β\nββββββββββββββββββββββββββββββββ\n```\n\n### Hard Gate (Block + Explain)\n\nUser cannot access the feature at all. Show the value clearly.\n\n```\nββββββββββββββββββββββββββββββββ\nβ [Lock Icon] β\nβ β\nβ This feature is available β\nβ on the Pro plan β\nβ β\nβ What you get: β\nβ - Benefit 1 β\nβ - Benefit 2 β\nβ - Benefit 3 β\nβ β\nβ [Upgrade to Pro] β\nβ [Compare Plans] β\nββββββββββββββββββββββββββββββββ\n```\n\n### Feature Gate Design Rules\n\n- Always explain WHY the feature is valuable (not just that it is locked)\n- Show what the feature produces (output preview) when possible\n- Include a \"Compare Plans\" link for users who want more detail\n- Do not gate features the user was already using during trial\n\n---\n\n## Usage Limit UX\n\n### Approaching Limit (80% Warning)\n\n```\nββββββββββββββββββββββββββββββββββββ\nβ [Progress Bar: 80%] β\nβ You've used 80 of 100 credits β\nβ β\nβ [Get More Credits] [Dismiss] β\nββββββββββββββββββββββββββββββββββββ\n```\n\n### At Limit (100%)\n\n```\nββββββββββββββββββββββββββββββββββββββββ\nβ [Progress Bar: 100%] β\nβ You've reached your monthly limit β\nβ β\nβ Free: 100 credits | Pro: Unlimited β\nβ β\nβ [Upgrade to Pro] β\nβ [Delete items to free space] β Alternative action\nββββββββββββββββββββββββββββββββββββββββ\n```\n\n### Usage Limit Rules\n\n- Show usage context before the limit hits (progress indicators in the UI)\n- Provide an alternative action (delete, archive, export) when possible\n- Never delete user data when limits are reached\n- Allow grace period (do not cut off mid-task)\n\n---\n\n## Trial Expiration Flows\n\n### Trial Countdown Sequence\n\n| Day | Channel | Message | Tone |\n|-----|---------|---------|------|\n| Day 7 (of 14) | In-app banner | \"7 days left in your trial\" | Informational |\n| Day 10 | Email | \"4 days left -- here's what you've accomplished\" | Value summary |\n| Day 12 | In-app modal | \"2 days left -- don't lose access to [feature]\" | Mild urgency |\n| Day 13 | Email | \"Tomorrow is your last day\" | Urgency + offer |\n| Day 14 | In-app full screen | \"Your trial has ended\" | Clear options |\n| Day 15 | Email | \"We kept your data safe -- reactivate anytime\" | Reassurance |\n\n### Trial Expiration Screen Design\n\n```\nβββββββββββββββββββββββββββββββββββββββββββ\nβ Your trial has ended β\nβ β\nβ What you accomplished during trial: β\nβ - Created [N] projects β Personalized data\nβ - Invited [N] team members β\nβ - Saved an estimated [X] hours β\nβ β\nβ What happens now: β\nβ - Your data is saved for 30 days β\nβ - Read-only access to existing work β\nβ - Full access resumes when you upgrade β\nβ β\nβ [Continue with Pro - $X/mo] β\nβ [Remind Me Later] [Downgrade to Free] β\nβββββββββββββββββββββββββββββββββββββββββββ\n```\n\n---\n\n## Timing and Frequency Rules\n\n### Frequency Caps\n\n| Rule | Implementation |\n|------|---------------|\n| Max 1 paywall per session | Do not interrupt twice in one visit |\n| 3-7 day cooldown after dismissal | If they click \"Not now\", wait at least 3 days |\n| Never during active task | If user is creating, editing, or mid-workflow, do not interrupt |\n| Cap at 3 per month | After 3 dismissals in a month, stop showing until next month |\n| Track annoyance signals | If user closes paywall within 1 second repeatedly, increase cooldown |\n\n### Escalation Pattern\n\n| Attempt | Approach | Invasiveness |\n|---------|----------|-------------|\n| 1 | Subtle banner or sidebar widget | Low |\n| 2 | Modal with value proposition | Medium |\n| 3 | Modal with special offer (discount/extended trial) | Medium-High |\n| 4+ | Reduce frequency, switch to email nurture | Low (change channel) |\n\n---\n\n## Upgrade Flow Optimization\n\n### From Paywall Click to Payment\n\n| Step | Optimization |\n|------|-------------|\n| 1. Click upgrade CTA | Opens upgrade flow (do not redirect to external page if avoidable) |\n| 2. Plan selection | Pre-select the recommended plan, show comparison |\n| 3. Payment | Pre-fill known info (email, name), support all payment methods |\n| 4. Confirmation | Immediate access to paid features, confirmation email |\n| 5. Post-upgrade | Guide to newly unlocked features, celebration moment |\n\n### Friction Reduction\n\n- Keep the upgrade flow in-context (modal or slide-out, not a full page redirect)\n- Pre-fill all known information\n- Support saved payment methods and one-click upgrade for returning upgraders\n- Show price clearly before the payment step (no surprise charges)\n\n---\n\n## Dark Pattern Avoidance\n\n### Patterns to NEVER Use\n\n| Dark Pattern | Why It Fails | Ethical Alternative |\n|-------------|-------------|---------------------|\n| Hidden close button | Breaks trust, generates support tickets | Clear X in top-right corner |\n| Shame copy (\"No, I don't want to grow my business\") | Manipulative, reduces brand respect | \"Maybe later\" or \"Not now\" |\n| Countdown timer (fake urgency) | Users discover it resets, destroys credibility | Only use for genuinely expiring offers |\n| Confusing plan selection | Users feel tricked, higher refund rate | Clear plan names with honest comparison |\n| Blocking critical actions | Users feel trapped, generates churn | Allow continued use of existing features |\n| Making downgrade difficult | Regulatory risk (especially in EU/CA) | One-click downgrade option |\n\n---\n\n## Platform-Specific Considerations\n\n### iOS App Store\n\n- Apple requires in-app purchase (IAP) for digital goods/services\n- Apple takes 30% commission (15% for small business program)\n- Must comply with App Store Review Guidelines 3.1\n- Cannot link to external payment pages from within the app\n- Must clearly communicate subscription terms and renewal\n\n### Google Play\n\n- Similar IAP requirements as iOS\n- Google Play billing required for digital goods\n- 15% commission on first $1M in annual revenue, then 30%\n- Must provide clear subscription management\n\n### Web App\n\n- Full control over payment flow and presentation\n- Can offer any payment method\n- No platform commission\n- Can A/B test freely without app review delays\n\n---\n\n## Metrics and Benchmarks\n\n### Key Metrics\n\n| Metric | Formula | Benchmark |\n|--------|---------|-----------|\n| Paywall impression rate | Users who see paywall / Active users | Track, no universal benchmark |\n| Paywall CTR | Upgrade clicks / Paywall impressions | 5-15% |\n| Upgrade completion rate | Completed upgrades / Upgrade clicks | 30-60% |\n| Free-to-paid conversion | Paid users / Total free users | 2-5% for freemium, 15-30% for trial |\n| Revenue per user (ARPU) | Total revenue / Active users | Segment-dependent |\n| Post-upgrade churn (30-day) | Churned within 30 days / New paid users | < 10% |\n\n### Warning Signals\n\n| Signal | Diagnosis | Action |\n|--------|-----------|--------|\n| CTR < 3% | Paywall copy or timing is wrong | Test different triggers and messaging |\n| Completion < 20% | Upgrade flow has too much friction | Simplify payment flow |\n| Post-upgrade churn > 15% | Value not matching expectations | Review feature access and onboarding |\n| Free-to-paid < 1% | Paywall appears before value is delivered | Delay triggers until after activation |\n\n---\n\n## A/B Test Framework\n\n### High-Impact Tests\n\n| Test | Hypothesis | Metric |\n|------|-----------|--------|\n| Trigger timing (earlier vs later) | Later trigger = higher conversion rate | Free-to-paid conversion |\n| Soft gate vs hard gate | Soft gate (preview) converts better | Feature gate CTR |\n| Copy variation | Value-focused vs urgency-focused | Paywall CTR |\n| Price presentation | Monthly vs annual default | ARPU |\n\n### Test Measurement\n\n- Run for minimum 2 weeks or 100 conversions per variant\n- Track upgrade rate AND 30-day post-upgrade retention\n- A test that increases upgrades but increases churn is a net negative\n\n---\n\n## Output Artifacts\n\n| Artifact | Format | Description |\n|----------|--------|-------------|\n| Paywall Trigger Map | Trigger x timing x frequency table | All trigger points with rules and cooldowns |\n| Screen Copy Set | Complete screen designs | Headline, benefits, CTA, escape hatch for each paywall type |\n| Upgrade Flow Diagram | Step-by-step flow | Paywall click to post-upgrade confirmation |\n| Dark Pattern Audit | Checklist | Review of existing paywall for manipulative patterns |\n| Trial Expiration Sequence | Day-by-day plan | In-app + email sequence for trial countdown |\n| A/B Test Backlog | Prioritized table | Test ideas ranked by expected impact |\n\n---\n\n## Tool Reference\n\n### 1. paywall_trigger_auditor.py\n\nAudits paywall trigger configuration for timing, frequency, and coverage issues. Reads a JSON file of trigger rules and user event data, then flags misconfigured triggers, missing cooldowns, and dark-pattern risks.\n\n```bash\npython scripts/paywall_trigger_auditor.py triggers.json --format text\npython scripts/paywall_trigger_auditor.py triggers.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `triggers.json` | positional | Path to JSON file with trigger rules and event data |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n### 2. upgrade_funnel_analyzer.py\n\nAnalyzes upgrade funnel step-by-step conversion from paywall impression through payment completion. Identifies the highest-drop steps, calculates stage-over-stage conversion, and benchmarks against industry targets.\n\n```bash\npython scripts/upgrade_funnel_analyzer.py funnel.json --format text\npython scripts/upgrade_funnel_analyzer.py funnel.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `funnel.json` | positional | Path to JSON file with funnel step data |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n### 3. paywall_copy_scorer.py\n\nScores paywall screen copy against proven conversion patterns. Evaluates headline structure, benefit clarity, CTA strength, social proof presence, and dark-pattern risk. Outputs a 0-100 score with itemized feedback.\n\n```bash\npython scripts/paywall_copy_scorer.py copy.json --format text\npython scripts/paywall_copy_scorer.py copy.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `copy.json` | positional | Path to JSON file with paywall copy elements |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Resolution |\n|---------|-------------|------------|\n| Paywall CTR below 3% | Trigger fires before user reaches aha moment or copy is feature-focused instead of benefit-focused | Delay trigger until after activation event; rewrite headline to outcome-based messaging (lifts CTR up to 23% per Strava case study) |\n| Upgrade completion below 20% | Too much friction in payment flow (redirects, missing payment methods, surprise charges) | Keep flow in-context (modal/slide-out), pre-fill known info, show price before payment step |\n| Post-upgrade churn above 15% | Value expectation mismatch -- paid experience does not match what the paywall promised | Audit feature access post-upgrade, add guided tour of newly unlocked features, align copy with actual capabilities |\n| Free-to-paid conversion below 1% | Paywall appears before value is delivered or free tier is too generous | Map activation events and ensure paywall only fires after aha moment; review free vs paid feature boundary |\n| Users close paywall within 1 second repeatedly | Paywall is interrupting workflow or appearing too frequently | Increase cooldown to 7+ days after dismissal, cap at 3 per month, switch to less intrusive format (banner vs modal) |\n| Mobile paywall underperforms desktop by >30% | iOS/Android IAP friction, small dismiss targets, or full-screen overlay on mobile | Ensure 44x44px touch targets, use bottom-sheet format on mobile, comply with App Store guidelines |\n| Trial expiration emails have low open rate | Generic subject lines, wrong send timing, or email deliverability issues | Personalize with usage data (\"You created 12 projects\"), send at user's active hours, check spam score |\n\n---\n\n## Success Criteria\n\n- Free-to-paid conversion rate reaches 2-5% for freemium models or 15-30% for trial models within 90 days of optimization\n- Paywall CTR stabilizes at 5-15% across all trigger types\n- Upgrade completion rate (paywall click to payment) exceeds 30%\n- Post-upgrade 30-day retention exceeds 90% (churn below 10%)\n- Paywall annoyance signals (sub-1-second dismissals) decrease to below 5% of impressions\n- Zero dark patterns present in paywall audit (no shame copy, no hidden close buttons, no fake urgency)\n- Annual plan adoption reaches 40%+ of new upgrades when annual toggle defaults are implemented (benchmark: 20-40% lift)\n\n---\n\n## Scope & Limitations\n\n**In scope:** In-product upgrade flows including feature gates, usage limit screens, trial expiration sequences, upgrade trigger timing, save offer strategy, paywall screen design, and A/B test frameworks for freemium-to-paid and trial-to-paid conversion.\n\n**Out of scope:** Public-facing pricing pages (use page-cro), the pricing model itself (use pricing-strategy), post-signup onboarding before the aha moment (use onboarding-cro), initial registration flows (use signup-flow-cro), and post-upgrade churn intervention (use churn-prevention). This skill does not cover App Store Optimization (ASO) or paid acquisition strategies. Scripts operate on local data only -- no integrations with payment processors, analytics platforms, or A/B testing tools.\n\n**Limitations:** Conversion benchmarks are based on aggregate SaaS/app industry data and may vary significantly by vertical, price point, and audience. Mobile paywall performance is highly dependent on platform-specific IAP requirements (Apple 30% commission, Google Play billing). Scripts analyze static snapshots; real-time paywall optimization requires integration with analytics and experimentation platforms not provided here.\n\n---\n\n## Integration Points\n\n- **pricing-strategy** -- Feed pricing tier structure and value metric into paywall copy and plan comparison design\n- **onboarding-cro** -- Coordinate activation event definitions; paywall triggers should fire only after onboarding confirms aha moment\n- **churn-prevention** -- Post-upgrade churn data feeds back into paywall expectation-setting; save offers should align with churn prevention playbook\n- **page-cro** -- Public pricing page design feeds into in-app upgrade flow consistency; ensure messaging alignment\n- **signup-flow-cro** -- Registration flow completion triggers trial start; trial duration and paywall timing depend on signup context\n- **popup-cro** -- Share frequency capping logic and suppression rules; paywall modals follow same UX principles as marketing popups\n\n---\n\n## Related Skills\n\n- **page-cro** -- Use for public pricing page optimization. Paywall-upgrade-cro handles in-product upgrade moments.\n- **onboarding-cro** -- Use when users have not reached activation. Do not show paywalls before the aha moment.\n- **pricing-strategy** -- Use when the pricing model itself needs redesigning (tier structure, value metric, price points).\n- **churn-prevention** -- Use when users upgrade but then churn. If they never upgrade, the problem is here.\n- **signup-flow-cro** -- Use for the initial registration flow. Paywall-upgrade-cro handles post-signup monetization.","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/paywall-upgrade-cro","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/paywall-upgrade-cro/SKILL.md","defaultBranch":"main"},"readme":"# Paywall & Upgrade Screen CRO\n\nProduction-grade framework for in-product upgrade flows. Covers feature gate design, usage limit UX, trial expiration sequences, upgrade trigger timing, dark pattern avoidance, and ethical monetization. Distinct from public pricing pages (use page-cro for those) -- this focuses on in-product moments where users have already experienced value.\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [The Value-First Principle](#the-value-first-principle)\n- [Paywall Trigger Architecture](#paywall-trigger-architecture)\n- [Paywall Screen Design](#paywall-screen-design)\n- [Feature Gate Patterns](#feature-gate-patterns)\n- [Usage Limit UX](#usage-limit-ux)\n- [Trial Expiration Flows](#trial-expiration-flows)\n- [Timing and Frequency Rules](#timing-and-frequency-rules)\n- [Upgrade Flow Optimization](#upgrade-flow-optimization)\n- [Dark Pattern Avoidance](#dark-pattern-avoidance)\n- [Platform-Specific Considerations](#platform-specific-considerations)\n- [Metrics and Benchmarks](#metrics-and-benchmarks)\n- [A/B Test Framework](#ab-test-framework)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore designing the paywall, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Upgrade model** β freemium-to-paid, trial-to-paid, or tier upgrade (determines the paywall type and trigger architecture)\n- [ ] **Free vs paid boundary** β what is gated (defines the value gap the paywall communicates)\n- [ ] **Aha moment** β so triggers fire only after value is experienced (the value-first principle)\n- [ ] **Platform** β web, iOS, or Android (IAP rules and commissions constrain web vs app flows)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| What is the upgrade model? (freemium to paid, trial to paid, tier upgrade) | Determines the paywall type |\n| What is free vs paid? | Defines the value gap to communicate |\n| What triggers upgrade prompts today? | Identifies current trigger points |\n| What is the current free-to-paid conversion rate? | Baseline for improvement |\n| What is the aha moment for users? | Determines when the paywall should appear |\n| What pricing model? (per seat, usage, flat) | Affects paywall messaging |\n| Mobile app, web app, or both? | Platform-specific requirements |\n\n---\n\n## The Value-First Principle\n\nThe single most important rule in paywall design: **The user must have experienced real value before seeing an upgrade prompt.**\n\n### Value-First Checklist\n\n- [ ] User has completed the activation event (aha moment reached)\n- [ ] User has used the product at least 2-3 times\n- [ ] User has created or stored data they would lose\n- [ ] The upgrade feels like a natural next step, not a trap\n\n### When to Show vs When NOT to Show\n\n| Show | Do Not Show |\n|------|------------|\n| After aha moment is reached | During onboarding |\n| When user hits a genuine limit | On first login |\n| When user clicks a paid feature | When user is in the middle of a task |\n| After milestone completion | Immediately after a frustrating experience |\n| On session start (gentle reminder) | After every action |\n\n---\n\n## Paywall Trigger Architecture\n\n### Trigger Types\n\n| Trigger | When It Fires | Best For |\n|---------|--------------|----------|\n| Feature gate | User clicks a locked feature | Feature-differentiated tiers |\n| Usage limit | User reaches a quota | Usage-based pricing |\n| Trial expiration | Trial period ending | Time-limited trial models |\n| Time-based | After N days of active use | Freemium nurture |\n| Milestone-based | After user achieves X | Upsell at success moments |\n| Team-based | When team grows past free seat limit | Per-seat models |\n\n### Trigger Priority Map\n\n| User State | Primary Trigger | Timing |\n|-----------","createdAt":"2026-09-25T13:52:02.807Z","updatedAt":"2026-09-25T13:52:02.807Z"},{"id":"cmuh0s8ph03rgqu06mx8021he","slug":"borghei-claude-skills-pricing-strategy","name":"pricing-strategy","description":"SaaS pricing design and optimization covering value metric selection, tier architecture, price point research, pricing page design, price increase execution, and competitive pricing analysis.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"pricing-strategy","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"SaaS pricing design and optimization covering value metric selection, tier architecture, price point research, pricing page design, price increase execution, and competitive pricing analysis.","permissions":[],"systemPrompt":"# Pricing Strategy\n\nProduction-grade SaaS pricing framework covering the three pricing axes (value metric, packaging, price point), value-based pricing methodology, tier architecture, pricing research methods, pricing page design, price increase execution, and competitive pricing positioning. Pricing is positioning -- the right price communicates as much about your product as your marketing does.\n\n## Core Capabilities\n\n- **Three pricing axes (in order)** β lock the value metric (how it scales), then packaging (what's in each tier), then test the price point (the number). Most teams skip to price point; that is backwards.\n- **Value metric & tier design** β select a metric that scales with customer value and is hard to game; architect Good-Better-Best tiers with deliberate feature allocation and naming.\n- **Value-based pricing** β price inside the corridor (above the next-best alternative, below perceived value), at 10-20% of documented value delivered.\n- **Pricing research** β Van Westendorp, MaxDiff, competitor benchmarking, willingness-to-pay interviews.\n- **Pricing page, price increases & competition** β page design (above/below fold, annual toggle), price-increase playbook (strategy, timeline, comms, impact), competitive positioning and health diagnostics.\n\n## Use when\n\n- The user asks to \"design pricing\", \"set prices\", or \"choose a value metric\"\n- Pricing tiers need to be restructured (Good-Better-Best, add/remove tiers, repackage features)\n- A price increase is planned and needs execution design (strategy, timing, communication, grandfathering)\n- Conversion on the pricing page is flat or declining\n- Freemium vs free trial decision needs to be made, or the freemium tier is cannibalizing paid\n- Competitor pricing shifts require a positioning response\n- The user says \"our pricing feels off\" or asks for a pricing audit\n\n## Clarify First\n\nBefore designing the pricing, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Operating mode** β design from scratch, optimize existing, or price increase (each has a different validation gate and workflow)\n- [ ] **Value metric** β how price scales (seats, usage, etc.) (must be locked before tiers and price points)\n- [ ] **Current pricing + the symptom** β existing tiers and the specific failure, e.g. \"middle tier too narrow\" (optimize mode needs a named failure mode before any change)\n- [ ] **Target segment + willingness-to-pay** β SMB vs enterprise price sensitivity (sets the value corridor and price points)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## Operating Modes\n\n- **Mode 1 β Design From Scratch:** No pricing exists or full rebuild needed. Work value metric β tier structure β price points β page design. *Validate:* value metric chosen before tier design; tiers locked before price points; price points tested against the corridor before page design.\n- **Mode 2 β Optimize Existing Pricing:** Pricing exists but conversion is low, expansion flat, or customers feel mispriced. Audit, benchmark, find specific improvements. *Validate:* the diagnosis names a specific failure mode (e.g., \"middle tier too narrow\") before any change is proposed.\n- **Mode 3 β Price Increase:** Prices need to go up without burning relationships. *Validate:* grandfather policy defined, communication window set (90+ days for annual customers), and expected churn modeled before the first notice.\n\n## References\n\nLoad the reference that matches the task β keep this file lean and pull detail on demand:\n\n- **[references/pricing-models.md](references/pricing-models.md)** β the three pricing axes, value metric selection (table, criteria, red flags), tier architecture (Good-Better-Best, feature allocation, naming), and value-based pricing corridor. Read when designing or restructuring pricing.\n- **[references/research-and-page-design.md](references/research-and-page-design.md)** β Van Westendorp, MaxDiff, competitor benchmarking, WTP interviews, pricing page design, and the freemium vs free trial decision. Read when researching willingness-to-pay or designing the page.\n- **[references/price-increase-and-competitive.md](references/price-increase-and-competitive.md)** β price increase strategy/timeline/comms/impact, competitive position map and positioning strategy, and pricing health signals. Read when raising prices or positioning against competitors.\n- **[references/tools-and-diagnostics.md](references/tools-and-diagnostics.md)** β output artifacts, the three Python scripts (analyzer, sensitivity calculator, increase modeler), troubleshooting table, success criteria, and anti-patterns. Read when producing deliverables, running tools, or debugging a pricing problem.\n\n## Scope & Limitations\n\n**In scope:** Value metric selection, tier architecture design, price point research (Van Westendorp, competitor benchmarking, willingness-to-pay interviews), pricing page design specifications, price increase strategy and execution, freemium vs free trial decision frameworks, competitive pricing analysis and positioning, and pricing health diagnostics.\n\n**Out of scope:** Pricing page visual design and CRO (use page-cro), in-app upgrade prompts and paywalls (use paywall-upgrade-cro), signup flow optimization after pricing page (use signup-flow-cro), churn intervention when churn is the root cause (use churn-prevention), and full competitive analysis beyond pricing (use competitive-teardown). Scripts do not integrate with billing systems (Stripe, Chargebee, etc.) or analytics platforms.\n\n**Limitations:** Van Westendorp analysis requires minimum 30 survey respondents for statistical validity. Pricing benchmarks are based on aggregate SaaS industry data and vary significantly by vertical, company stage, and geography. Credit-based and usage-based pricing models (growing to 38% of SaaS in 2026) have different optimization dynamics than flat-rate or per-seat models. Price elasticity varies by customer segment -- enterprise buyers are less price-sensitive than SMB.\n\n## Integration Points\n\n- **page-cro** -- Pricing page layout, CTA placement, and social proof design should follow page-cro best practices\n- **paywall-upgrade-cro** -- In-app upgrade screens must reflect the same tier structure and messaging as the public pricing page\n- **competitive-teardown** -- Competitive pricing data from teardowns feeds directly into pricing position map and tier design\n- **churn-prevention** -- Churn analysis by price point and tier informs whether pricing is causing retention issues\n- **signup-flow-cro** -- Signup flow design depends on pricing model (CC-required vs free trial vs freemium)\n- **revenue-operations** -- GTM efficiency metrics (LTV:CAC, Magic Number) validate whether pricing supports unit economics\n\n## Related Skills\n\n- **page-cro** -- Use for optimizing the pricing page conversion rate (layout, CTA, social proof). Not for pricing structure or tier design.\n- **churn-prevention** -- Use when churn is the underlying issue. Fix retention before raising prices.\n- **competitive-teardown** -- Use for comprehensive competitive analysis. Feed teardown pricing data into this skill.\n- **paywall-upgrade-cro** -- Use for in-app upgrade prompts and paywalls. Different from public pricing page design.\n- **signup-flow-cro** -- Use for optimizing the signup flow that follows pricing page conversion.","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/pricing-strategy","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/pricing-strategy/SKILL.md","defaultBranch":"main"},"readme":"# Pricing Strategy\n\nProduction-grade SaaS pricing framework covering the three pricing axes (value metric, packaging, price point), value-based pricing methodology, tier architecture, pricing research methods, pricing page design, price increase execution, and competitive pricing positioning. Pricing is positioning -- the right price communicates as much about your product as your marketing does.\n\n## Core Capabilities\n\n- **Three pricing axes (in order)** β lock the value metric (how it scales), then packaging (what's in each tier), then test the price point (the number). Most teams skip to price point; that is backwards.\n- **Value metric & tier design** β select a metric that scales with customer value and is hard to game; architect Good-Better-Best tiers with deliberate feature allocation and naming.\n- **Value-based pricing** β price inside the corridor (above the next-best alternative, below perceived value), at 10-20% of documented value delivered.\n- **Pricing research** β Van Westendorp, MaxDiff, competitor benchmarking, willingness-to-pay interviews.\n- **Pricing page, price increases & competition** β page design (above/below fold, annual toggle), price-increase playbook (strategy, timeline, comms, impact), competitive positioning and health diagnostics.\n\n## Use when\n\n- The user asks to \"design pricing\", \"set prices\", or \"choose a value metric\"\n- Pricing tiers need to be restructured (Good-Better-Best, add/remove tiers, repackage features)\n- A price increase is planned and needs execution design (strategy, timing, communication, grandfathering)\n- Conversion on the pricing page is flat or declining\n- Freemium vs free trial decision needs to be made, or the freemium tier is cannibalizing paid\n- Competitor pricing shifts require a positioning response\n- The user says \"our pricing feels off\" or asks for a pricing audit\n\n## Clarify First\n\nBefore designing the pricing, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Operating mode** β design from scratch, optimize existing, or price increase (each has a different validation gate and workflow)\n- [ ] **Value metric** β how price scales (seats, usage, etc.) (must be locked before tiers and price points)\n- [ ] **Current pricing + the symptom** β existing tiers and the specific failure, e.g. \"middle tier too narrow\" (optimize mode needs a named failure mode before any change)\n- [ ] **Target segment + willingness-to-pay** β SMB vs enterprise price sensitivity (sets the value corridor and price points)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## Operating Modes\n\n- **Mode 1 β Design From Scratch:** No pricing exists or full rebuild needed. Work value metric β tier structure β price points β page design. *Validate:* value metric chosen before tier design; tiers locked before price points; price points tested against the corridor before page design.\n- **Mode 2 β Optimize Existing Pricing:** Pricing exists but conversion is low, expansion flat, or customers feel mispriced. Audit, benchmark, find specific improvements. *Validate:* the diagnosis names a specific failure mode (e.g., \"middle tier too narrow\") before any change is proposed.\n- **Mode 3 β Price Increase:** Prices need to go up without burning relationships. *Validate:* grandfather policy defined, communication window set (90+ days for annual customers), and expected churn modeled before the first notice.\n\n## References\n\nLoad the reference that matches the task β keep this file lean and pull detail on demand:\n\n- **[references/pricing-models.md](references/pricing-models.md)** β the three pricing axes, value metric selection (table, criteria, red flags), tier architecture (Good-Better-Best, feature allocation, naming), and value-based pricing corridor. Read when designing or restructuring pricing.\n- **[references/research-and-page-design.md](references/research-and-page-design.md)** β","createdAt":"2026-09-25T13:52:02.837Z","updatedAt":"2026-09-25T13:52:02.837Z"},{"id":"cmuh0s8p203raqu06jwsuuggq","slug":"borghei-claude-skills-popup-cro","name":"popup-cro","description":"Popup and modal optimization for conversion. Covers exit-intent, slide-ins, banners, timing optimization, frequency capping, audience targeting, compliance, and A/B testing frameworks for lead capture, promotions, and announcements.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"popup-cro","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Popup and modal optimization for conversion. Covers exit-intent, slide-ins, banners, timing optimization, frequency capping, audience targeting, compliance, and A/B testing frameworks for lead capture, promotions, and announcements.","permissions":[],"systemPrompt":"# Popup CRO\n\nProduction-grade popup optimization framework covering format selection, trigger engineering, audience targeting, frequency capping, copy design, compliance requirements, and structured A/B testing. Handles lead capture, promotional, announcement, and feedback popups across web and mobile.\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [Format Selection Matrix](#format-selection-matrix)\n- [Trigger Engineering](#trigger-engineering)\n- [Audience Targeting](#audience-targeting)\n- [Frequency and Suppression Rules](#frequency-and-suppression-rules)\n- [Popup Copy Architecture](#popup-copy-architecture)\n- [Strategy by Business Type](#strategy-by-business-type)\n- [Mobile Popup Design](#mobile-popup-design)\n- [Compliance Requirements](#compliance-requirements)\n- [Multi-Popup Conflict Resolution](#multi-popup-conflict-resolution)\n- [A/B Test Framework](#ab-test-framework)\n- [Metrics and Benchmarks](#metrics-and-benchmarks)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore designing the popup, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Popup purpose** β lead capture, promotion, announcement, or feedback (selects format and trigger)\n- [ ] **Existing popups running** β needed for multi-popup conflict and priority resolution\n- [ ] **Visitor + device mix** β new vs returning, mobile vs desktop (drives targeting and mobile-safe format choice)\n- [ ] **Compliance regime** β GDPR/CCPA consent requirements (constrains data capture and consent UX)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the strategy.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| What is the popup purpose? (lead capture, promotion, announcement, feedback) | Determines format and trigger |\n| What existing popups are running? | Conflict resolution needed |\n| What traffic sources? (paid, organic, direct) | Targeting and trigger strategy |\n| New vs returning visitor split? | Personalization opportunity |\n| Mobile vs desktop traffic split? | Mobile compliance requirements |\n| Current popup performance? (if exists) | Baseline for optimization |\n| Any compliance requirements? (GDPR, CCPA) | Legal constraints on data capture |\n\n---\n\n## Format Selection Matrix\n\n| Format | Best For | Intrusiveness | Mobile Friendly | Conversion Rate |\n|--------|----------|--------------|-----------------|-----------------|\n| Center modal | High-value offers, exit intent | High | With adaptation | 3-10% |\n| Slide-in (corner) | Newsletter, content offers | Low | Yes | 1-5% |\n| Top bar | Announcements, promotions | Very low | Yes | 0.5-2% |\n| Bottom bar | Cookie consent, CTAs | Very low | Yes | 0.5-2% |\n| Full-screen overlay | Major promotions, welcome mats | Very high | No (Google penalizes) |2-8% |\n| Inline expansion | Content upgrades within articles | Very low | Yes | 2-7% |\n| Exit-intent modal | Final capture attempt | Medium | Desktop only | 2-5% |\n\n### Format Decision Tree\n\n```\nWhat is the goal?\nβββ Lead capture (email)\nβ βββ Blog/content page β Slide-in (scroll trigger) or inline expansion\nβ βββ Landing page β Exit-intent modal\nβ βββ Homepage β Time-delayed center modal\nβββ Promotion/discount\nβ βββ E-commerce β Center modal (entry or timed)\nβ βββ SaaS β Top bar with countdown\nβββ Announcement\nβ βββ New feature β Top bar (sticky)\nβ βββ Event/webinar β Slide-in or center modal\nβββ Feedback/survey\n βββ Post-interaction β Slide-in (bottom corner)\n```\n\n---\n\n## Trigger Engineering\n\n### Trigger Types and Use Cases\n\n| Trigger | How It Works | Best For | Risk |\n|---------|-------------|----------|------|\n| Exit intent | Mouse moves toward browser close/back | Last-chance capture | Desktop only |\n| Time delay | Appears after N seconds | Low-commitment offers | Too early = annoying |\n| Scroll depth | Appears at N% scroll | Content-engaged visitors | Must calibrate to content length |\n| Page count | Appears after N page views | Multi-visit engagement | Requires cookie tracking |\n| Click trigger | User clicks a specific element | Lead magnets, CTAs | Requires obvious trigger element |\n| Inactivity | No interaction for N seconds | Re-engagement | Can feel intrusive |\n\n### Optimal Trigger Settings\n\n| Trigger | Setting | Rationale |\n|---------|---------|-----------|\n| Time delay | 15-30 seconds | < 10s feels aggressive, > 60s misses visitors |\n| Scroll depth | 50-70% | User has consumed enough content to be engaged |\n| Page count | 2-3 pages | Visitor has shown interest beyond a single page |\n| Exit intent | Mouse leaves viewport | Last opportunity before they leave |\n| Click trigger | Prominent CTA button or text link | Explicit user intent |\n\n### Trigger Combinations\n\nLayer triggers for better targeting:\n\n| Combination | When to Use |\n|------------|-------------|\n| Scroll 50% + Time 20s | Ensures both engagement and time on page |\n| Page count 3 + Exit intent | Only show to visitors who have browsed multiple pages and are leaving |\n| Click trigger + Email not captured | Only show form to non-subscribers |\n\n---\n\n## Audience Targeting\n\n### Segmentation Rules\n\n| Segment | Popup Strategy |\n|---------|---------------|\n| New visitors (first visit) | Welcome offer, newsletter signup, content upgrade |\n| Returning visitors (2-5 visits) | Deeper offer, free trial, demo request |\n| Returning visitors (5+ visits) | Direct CTA, consultation offer |\n| Email subscribers | Never show email capture popup |\n| Existing customers | Feature announcements, upgrade offers only |\n| Paid traffic visitors | Message-matched offer, no generic popup |\n| Mobile visitors | Non-intrusive format only (slide-in or bottom bar) |\n\n### Exclusion Rules\n\nAlways exclude these segments from popups:\n\n- Users who already converted (subscribed, signed up, purchased)\n- Users who dismissed the same popup in this session\n- Users who dismissed the same popup in the last 7 days\n- Users in the checkout or payment flow\n- Users on legal/compliance pages (privacy, terms)\n\n---\n\n## Frequency and Suppression Rules\n\n### Frequency Caps\n\n| Rule | Setting | Rationale |\n|------|---------|-----------|\n| Max popups per session | 1 | Multiple popups per visit destroys trust |\n| Cooldown after dismissal | 7 days minimum | Respect the user's \"no\" |\n| Cooldown after close (X button) | 3-7 days | Less aggressive than dismissal |\n| Max popups per month | 3-4 | More than this and users feel harassed |\n| Post-conversion suppression | Permanent for that popup type | Never ask again once they converted |\n\n### Suppression Priority\n\nIf multiple popups compete for the same user in the same session, use this priority:\n\n| Priority | Popup Type | Why |\n|----------|-----------|-----|\n| 1 | Cookie consent / legal | Required by law |\n| 2 | Exit intent (if triggered) | Last chance, highest intent signal |\n| 3 | Time-delayed / scroll-triggered | Planned engagement |\n| 4 | Announcement bar | Lowest priority, always available |\n\n---\n\n## Popup Copy Architecture\n\n### Anatomy of High-Converting Popup Copy\n\n```\nHEADLINE: What they get (benefit-focused, 6-10 words)\nSUBHEADLINE: Why they should care (supporting detail, 1 sentence)\n[FORM: Minimum fields]\n[PRIMARY CTA: Action-oriented, 2-4 words]\n[DECLINE TEXT: Respectful, neutral, 3-6 words]\n[TRUST ELEMENT: Privacy or social proof, 1 line]\n```\n\n### Copy Examples by Type\n\n**Newsletter Signup:**\n- Headline: \"Get Weekly Growth Tactics\"\n- Subheadline: \"Join 15,000 marketers who get our Tuesday newsletter\"\n- CTA: \"Subscribe\"\n- Decline: \"No thanks\"\n- Trust: \"Unsubscribe anytime. No spam.\"\n\n**Content Upgrade:**\n- Headline: \"Get the Full SEO Checklist\"\n- Subheadline: \"85 checks organized by priority. PDF download.\"\n- CTA: \"Send Me the Checklist\"\n- Decline: \"I'll skip it\"\n- Trust: \"Free. No credit card required.\"\n\n**Exit Intent (E-commerce):**\n- Headline: \"Wait -- 15% Off Your First Order\"\n- Subheadline: \"Use code WELCOME15 at checkout\"\n- CTA: \"Claim My Discount\"\n- Decline: \"I'll pay full price\"\n- Trust: \"Valid for 24 hours\"\n\n### Decline Text Rules\n\n- Never use shame language (\"No, I don't want to save money\")\n- Keep it neutral: \"No thanks\", \"Maybe later\", \"Not now\", \"I'll skip it\"\n- Font size should be readable (not tiny text designed to be missed)\n- Position clearly below or beside the CTA\n\n---\n\n## Strategy by Business Type\n\n### E-commerce\n\n| Popup | Trigger | Offer |\n|-------|---------|-------|\n| Welcome discount | Entry (new visitors, 5-second delay) | 10-15% off first order |\n| Exit intent | Mouse exit on product/cart page | Higher discount or free shipping |\n| Cart abandonment | Return visit after cart abandonment | Reminder + incentive |\n| Post-purchase | Thank you page | Referral offer or cross-sell |\n\n### B2B SaaS\n\n| Popup | Trigger | Offer |\n|-------|---------|-------|\n| Content upgrade | Scroll 50% on blog post | Related PDF, checklist, template |\n| Demo request | Pricing page exit intent | \"Talk to sales\" with calendar link |\n| Newsletter | Blog, 3rd page view | Weekly insights email |\n| Feature announcement | Login, existing users | New feature with CTA to try it |\n\n### Content / Media\n\n| Popup | Trigger | Offer |\n|-------|---------|-------|\n| Newsletter | Scroll 60% on article | \"Get articles like this weekly\" |\n| Content gate | After 3 free articles | Subscription or email for access |\n| Social follow | Scroll bottom of article | Follow on social platforms |\n\n---\n\n## Mobile Popup Design\n\n### Google Intrusive Interstitials Policy\n\nGoogle penalizes mobile pages that show intrusive interstitials. Avoid:\n- Full-screen popups that cover the main content\n- Popups that the user must dismiss before accessing content\n- Above-the-fold layouts where the popup pushes content below the fold\n\n### Mobile-Safe Formats\n\n| Format | Mobile Safe? | Notes |\n|--------|-------------|-------|\n| Bottom bar | Yes | Small, non-blocking |\n| Top bar | Yes | Small, dismissable |\n| Slide-in (small) | Yes | Corner, < 30% of screen |\n| Center modal (small) | Conditional | Only if easily dismissable and shown after engagement |\n| Full-screen overlay | No | Penalized by Google |\n| Exit intent | N/A | Not available on mobile |\n\n### Mobile Design Rules\n\n- Touch targets minimum 44x44px for close button and CTA\n- Close button (X) must be clearly visible and easily tappable\n- Popup must not cover more than 50% of the screen\n- Form inputs must trigger appropriate mobile keyboards\n- Test on actual mobile devices (not just responsive preview)\n\n---\n\n## Compliance Requirements\n\n### GDPR (EU)\n\n- Checkbox for consent (pre-checked is not valid consent)\n- Clear privacy policy link\n- State what you will do with their email\n- Easy unsubscribe in all subsequent emails\n- Data processing purpose must be specified\n\n### CCPA (California)\n\n- \"Do Not Sell My Personal Information\" link if applicable\n- Privacy policy must be accessible\n- Users can request data deletion\n\n### CAN-SPAM (US)\n\n- Must honor unsubscribe requests within 10 business days\n- Must include physical address in emails\n- Subject lines cannot be deceptive\n\n### Cookie Consent (EU/UK)\n\n- Cookie consent banner takes priority over all other popups\n- Must not set non-essential cookies before consent\n- Must offer granular consent options\n\n---\n\n## Multi-Popup Conflict Resolution\n\n### Priority System\n\nIf your site runs multiple popups, implement these rules:\n\n1. **Legal popups first** -- Cookie consent before any other popup\n2. **One popup per session** -- After legal popup, only one marketing popup\n3. **Priority ranking** -- Exit intent > Scroll-triggered > Time-delayed > Announcement bar\n4. **No stacking** -- Never show two popups simultaneously\n5. **Queue system** -- If multiple popups qualify, show highest priority and suppress the rest for this session\n\n### Implementation Rules\n\n- Maintain a global popup state manager\n- Each popup checks the state before rendering\n- Record which popups the user has seen, dismissed, or converted on\n- Share state across tabs if possible (localStorage)\n\n---\n\n## A/B Test Framework\n\n### High-Impact Tests\n\n| Test | Hypothesis | Metric |\n|------|-----------|--------|\n| Trigger timing (15s vs 30s vs scroll) | Scroll trigger captures more engaged users | Conversion rate + bounce rate |\n| Offer type (discount vs content) | Content offers attract higher-quality leads | Conversion rate + lead quality |\n| Copy variation (benefit vs urgency) | Benefit-focused converts better long-term | Conversion rate |\n| Format (modal vs slide-in) | Slide-in has lower bounce impact | Conversion rate + bounce rate |\n| Decline text (neutral vs shame-free) | Neutral decline text maintains trust | Brand sentiment + repeat visits |\n\n### Test Rules\n\n- Run each test for minimum 1,000 impressions per variant\n- Track both popup conversion rate AND page-level metrics (bounce, time on page)\n- A popup that converts 10% but increases bounce by 20% is a net negative\n\n---\n\n## Metrics and Benchmarks\n\n### Key Metrics\n\n| Metric | Formula | Benchmark |\n|--------|---------|-----------|\n| Popup conversion rate | Conversions / Impressions | 2-5% (good), 5-10% (excellent) |\n| Popup view rate | Impressions / Eligible page views | Depends on trigger settings |\n| Bounce rate impact | Bounce rate with popup - without | Should be < 5% increase |\n| Email quality score | Popup leads who engage / Total popup leads | > 30% open subsequent emails |\n| Revenue per popup lead | Revenue from popup leads / Total popup leads | Compare to other lead sources |\n\n---\n\n## Output Artifacts\n\n| Artifact | Format | Description |\n|----------|--------|-------------|\n| Popup Strategy Map | Type x trigger x audience x frequency table | Complete popup inventory with conflict rules |\n| Complete Copy Set | Per-popup copy | Headline, subheadline, CTA, decline text, trust element |\n| Mobile Adaptation Guide | Per-format recommendations | Mobile-safe formats, sizing, dismiss behavior |\n| Compliance Checklist | Per-regulation requirements | GDPR, CCPA, CAN-SPAM, cookie consent |\n| A/B Test Plan | Prioritized table | Hypotheses ranked by expected impact |\n| Multi-Popup Priority Map | Priority ranking | Conflict resolution rules for concurrent popups |\n\n---\n\n## Tool Reference\n\n### 1. popup_strategy_auditor.py\n\nAudits existing popup configurations for compliance, frequency conflicts, targeting gaps, and mobile safety. Reads a JSON inventory of popups and flags issues against best practices.\n\n```bash\npython scripts/popup_strategy_auditor.py popups.json --format text\npython scripts/popup_strategy_auditor.py popups.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `popups.json` | positional | Path to JSON file with popup inventory and rules |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n### 2. popup_ab_test_calculator.py\n\nCalculates statistical significance for popup A/B tests. Takes impressions and conversions for control and variant, computes conversion rates, relative lift, confidence level, and recommends whether to ship, continue testing, or abandon.\n\n```bash\npython scripts/popup_ab_test_calculator.py test.json --format text\npython scripts/popup_ab_test_calculator.py test.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `test.json` | positional | Path to JSON file with A/B test data |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n### 3. popup_roi_estimator.py\n\nEstimates revenue impact of popup lead capture by modeling lead volume, conversion rates, and customer lifetime value. Compares popup-sourced leads against other channels.\n\n```bash\npython scripts/popup_roi_estimator.py roi_data.json --format text\npython scripts/popup_roi_estimator.py roi_data.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `roi_data.json` | positional | Path to JSON file with popup performance and revenue data |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Resolution |\n|---------|-------------|------------|\n| Popup conversion rate below 2% | Wrong trigger timing, weak offer, or poor copy | Test scroll-triggered (50-70%) vs time-delayed; use benefit-focused headline; add countdown timer (lifts to 14.4% avg per 2026 benchmarks) |\n| Bounce rate increases >5% after adding popup | Popup fires too early or covers too much screen on mobile | Increase time delay to 15-30s or switch to scroll trigger; use slide-in format instead of center modal |\n| Email list quality drops (low open rates from popup leads) | Generic offer attracts low-intent subscribers | Switch to content upgrade offers specific to the page; add qualification question |\n| Multiple popups fire in same session | No global popup state manager or priority system implemented | Implement session-level state tracking via localStorage; enforce one-popup-per-session rule with priority ranking |\n| Mobile popup triggers Google penalty | Full-screen overlay or popup covers content before engagement | Switch to bottom bar, slide-in (<30% screen), or inline expansion format; test with Google Mobile-Friendly Tool |\n| Exit-intent not working on mobile | Exit-intent relies on mouse movement which does not exist on mobile | Use scroll-up or inactivity trigger as mobile alternative; segment trigger rules by device type |\n| Cookie consent popup conflicts with marketing popup | No priority system; both fire simultaneously | Legal popups always take priority; queue marketing popup to fire only after consent is given |\n\n---\n\n## Success Criteria\n\n- Popup conversion rate reaches 3-5% (good) or 5-10% (excellent) within 30 days of optimization\n- Bounce rate impact stays below 5% increase compared to no-popup baseline\n- Email lead quality maintains >30% open rate on subsequent emails from popup-sourced leads\n- Mobile popup compliance passes Google Mobile-Friendly Test with zero warnings\n- Frequency capping limits impressions to max 1 per session and 3-4 per month per user\n- Zero GDPR/CCPA compliance violations in popup consent flows\n- Gamified or countdown-enhanced popups reach 13%+ average conversion rate (2026 benchmark)\n\n---\n\n## Scope & Limitations\n\n**In scope:** Popup and modal format selection, trigger engineering, audience targeting, frequency capping, copy architecture, mobile-safe design, multi-popup conflict resolution, compliance requirements (GDPR, CCPA, CAN-SPAM, cookie consent), and structured A/B testing for lead capture, promotional, announcement, and feedback popups.\n\n**Out of scope:** Form field-level optimization within popups (use form-cro), page-level conversion optimization around the popup (use page-cro), in-app onboarding modals and tooltips (use onboarding-cro), registration flows triggered by popups (use signup-flow-cro). Scripts operate on local data only -- no integrations with popup platforms (OptinMonster, Wisepops, etc.) or analytics tools.\n\n**Limitations:** Conversion benchmarks are aggregate industry averages from 2025-2026 studies (Popupsmart 10K+ campaigns, Wisepops 1B+ displays) and vary significantly by industry, traffic source, and offer type. Exit-intent detection is desktop-only; mobile alternatives (scroll-up, inactivity) have different performance characteristics. Google intrusive interstitial penalties apply to mobile search traffic specifically -- direct/paid traffic is less affected.\n\n---\n\n## Integration Points\n\n- **form-cro** -- Popup form fields should follow form-cro field reduction and validation standards\n- **page-cro** -- Page conversion should be optimized before layering popups; popup performance depends on page quality\n- **signup-flow-cro** -- Popup-to-signup handoff should maintain context and pre-fill captured email\n- **paywall-upgrade-cro** -- In-app upgrade modals share frequency capping and UX principles with marketing popups\n- **onboarding-cro** -- Product onboarding tooltips and modals should use separate state management from marketing popups\n- **referral-program** -- Post-purchase or post-conversion popups can trigger referral program prompts\n\n---\n\n## Related Skills\n\n- **form-cro** -- Use when the form inside the popup needs field-level optimization (field count, validation, layout).\n- **page-cro** -- Use when the page surrounding the popup needs conversion optimization. Fix the page first, then add popups.\n- **onboarding-cro** -- Use when popups/modals are part of in-app onboarding (tooltips, checklists, feature tours).\n- **signup-flow-cro** -- Use when the popup leads into a registration flow that needs optimization.","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/popup-cro","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/popup-cro/SKILL.md","defaultBranch":"main"},"readme":"# Popup CRO\n\nProduction-grade popup optimization framework covering format selection, trigger engineering, audience targeting, frequency capping, copy design, compliance requirements, and structured A/B testing. Handles lead capture, promotional, announcement, and feedback popups across web and mobile.\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [Format Selection Matrix](#format-selection-matrix)\n- [Trigger Engineering](#trigger-engineering)\n- [Audience Targeting](#audience-targeting)\n- [Frequency and Suppression Rules](#frequency-and-suppression-rules)\n- [Popup Copy Architecture](#popup-copy-architecture)\n- [Strategy by Business Type](#strategy-by-business-type)\n- [Mobile Popup Design](#mobile-popup-design)\n- [Compliance Requirements](#compliance-requirements)\n- [Multi-Popup Conflict Resolution](#multi-popup-conflict-resolution)\n- [A/B Test Framework](#ab-test-framework)\n- [Metrics and Benchmarks](#metrics-and-benchmarks)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore designing the popup, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Popup purpose** β lead capture, promotion, announcement, or feedback (selects format and trigger)\n- [ ] **Existing popups running** β needed for multi-popup conflict and priority resolution\n- [ ] **Visitor + device mix** β new vs returning, mobile vs desktop (drives targeting and mobile-safe format choice)\n- [ ] **Compliance regime** β GDPR/CCPA consent requirements (constrains data capture and consent UX)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the strategy.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| What is the popup purpose? (lead capture, promotion, announcement, feedback) | Determines format and trigger |\n| What existing popups are running? | Conflict resolution needed |\n| What traffic sources? (paid, organic, direct) | Targeting and trigger strategy |\n| New vs returning visitor split? | Personalization opportunity |\n| Mobile vs desktop traffic split? | Mobile compliance requirements |\n| Current popup performance? (if exists) | Baseline for optimization |\n| Any compliance requirements? (GDPR, CCPA) | Legal constraints on data capture |\n\n---\n\n## Format Selection Matrix\n\n| Format | Best For | Intrusiveness | Mobile Friendly | Conversion Rate |\n|--------|----------|--------------|-----------------|-----------------|\n| Center modal | High-value offers, exit intent | High | With adaptation | 3-10% |\n| Slide-in (corner) | Newsletter, content offers | Low | Yes | 1-5% |\n| Top bar | Announcements, promotions | Very low | Yes | 0.5-2% |\n| Bottom bar | Cookie consent, CTAs | Very low | Yes | 0.5-2% |\n| Full-screen overlay | Major promotions, welcome mats | Very high | No (Google penalizes) |2-8% |\n| Inline expansion | Content upgrades within articles | Very low | Yes | 2-7% |\n| Exit-intent modal | Final capture attempt | Medium | Desktop only | 2-5% |\n\n### Format Decision Tree\n\n```\nWhat is the goal?\nβββ Lead capture (email)\nβ βββ Blog/content page β Slide-in (scroll trigger) or inline expansion\nβ βββ Landing page β Exit-intent modal\nβ βββ Homepage β Time-delayed center modal\nβββ Promotion/discount\nβ βββ E-commerce β Center modal (entry or timed)\nβ βββ SaaS β Top bar with countdown\nβββ Announcement\nβ βββ New feature β Top bar (sticky)\nβ βββ Event/webinar β Slide-in or center modal\nβββ Feedback/survey\n βββ Post-interaction β Slide-in (bottom corner)\n```\n\n---\n\n## Trigger Engineering\n\n### Trigger Types and Use Cases\n\n| Trigger | How It Works | Best For | Risk |\n|---------|-------------|----------|------|\n| Exit intent | Mouse moves toward browser close/back | Last-chance capture | Desktop only |\n| Time delay | Appears after N seconds | Low-commitment offers | Too early = annoying |\n| Scroll depth | Appears","createdAt":"2026-09-25T13:52:02.823Z","updatedAt":"2026-09-25T13:52:02.823Z"},{"id":"cmuh0s8pu03rmqu065y9ozq3u","slug":"borghei-claude-skills-referral-program","name":"referral-program","description":"Referral and affiliate program design covering referral loop architecture, incentive design, trigger moment optimization, viral coefficient modeling, affiliate program structure, and optimization playbook.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"referral-program","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Referral and affiliate program design covering referral loop architecture, incentive design, trigger moment optimization, viral coefficient modeling, affiliate program structure, and optimization playbook.","permissions":[],"systemPrompt":"# Referral Program\n\nProduction-grade referral and affiliate program framework covering the 4-stage referral loop, incentive design methodology, trigger moment optimization, share mechanics, viral coefficient modeling, affiliate program architecture, and systematic optimization playbook. Designed to build programs that compound, not collect dust.\n\n## Core Capabilities\n\n- **Program type & loop design** β referral vs affiliate decision, plus the 4-stage loop (trigger β share β convert β reward)\n- **Incentive design** β single- vs double-sided, reward types, tiered gamification, reward economics against LTV/CAC\n- **Trigger & share mechanics** β in-product and email trigger points, share channel priority, first-person share copy\n- **Referred-user experience** β referral landing page, attribution rules, program copy set (prompts, emails, dashboards)\n- **Growth math** β K-factor modeling, revenue impact models, and lever-by-lever K improvement\n- **Affiliate framework** β commission models, tier systems, partner toolkit, recruitment\n- **Optimization** β diagnose-before-optimize playbook, metric benchmarks, troubleshooting, and three Python tools\n\n## When to Use\n\n- The user asks to \"design a referral program\", \"launch an affiliate program\", or \"improve viral growth\"\n- The decision between customer referral vs affiliate program needs to be made\n- An existing referral program has stalled (K-factor <1, low share rate, low referred-user conversion)\n- Reward structure needs sizing against CAC, margin, or LTV\n- Trigger moments need to be identified (when to ask, which in-product events, which lifecycle emails)\n- The user says \"word-of-mouth isn't working\" or \"we want to add a refer-a-friend flow\"\n\n## Clarify First\n\nBefore designing the referral program, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Program type** β customer referral vs affiliate (enthusiastic/social customers vs team buyers) (selects the entire framework)\n- [ ] **Trigger moment** β the in-product or lifecycle point where you ask (a broken Stage 1 can't be fixed by a bigger reward at Stage 4)\n- [ ] **Reward economics** β first-payment value, margin, and CAC (caps the reward at <30% of first payment)\n- [ ] **Current referral rate (if any)** β decides single- vs double-sided incentive and which stage to fix first\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## Quick Start\n\n1. **Pick the program type** β use the Referral vs Affiliate Decision table (enthusiastic/social customers β referral; team buyers β affiliate).\n2. **Build the loop in order** β trigger β share β convert β reward; a broken Stage 1 can't be fixed by a bigger reward at Stage 4.\n3. **Size the incentive** β cap reward at <30% of first payment; go double-sided if referral rate <1%.\n4. **Model and validate** β run the scripts (`referral_economics_calculator.py`, `referral_funnel_analyzer.py`, `affiliate_commission_modeler.py`) to size rewards, find the weakest stage, and model affiliate tiers.\n5. **Optimize by priority** β fix awareness first, then share flow, then referred experience, then the incentive.\n\n## References\n\nLoad the reference that matches the task β keep this file lean and pull detail on demand:\n\n- **[references/loop-and-incentives.md](references/loop-and-incentives.md)** β Referral vs Affiliate decision table, the full 4-stage loop with per-stage tables, incentive design (single/double-sided, reward types, tiers, economics), and trigger moment architecture. Read when designing the core program.\n- **[references/share-and-experience.md](references/share-and-experience.md)** β share channel priority, share message templates, referral landing page layout, attribution rules, and the program copy set (in-app prompt, dashboard, post-activation email). Read when building the sharing flow and referred-user experience.\n- **[references/modeling-and-affiliate.md](references/modeling-and-affiliate.md)** β K-factor calculation and improvement levers, plus the full affiliate framework (commission structure, tier system, toolkit, recruitment). Read when modeling growth math or designing an affiliate program.\n- **[references/optimization-and-operations.md](references/optimization-and-operations.md)** β optimization playbook, key metrics and benchmarks, revenue impact model, output artifacts, full tool reference, troubleshooting table, success criteria, and anti-patterns. Read when diagnosing a stalled program or operating the scripts.\n\n## Scope & Limitations\n\n**In scope:** Customer referral program design (4-stage loop), incentive structure (single-sided, double-sided, tiered), trigger moment architecture, share mechanics, referral landing page specifications, viral coefficient modeling, affiliate program framework (commission models, tier systems, recruitment), and systematic optimization playbook.\n\n**Out of scope:** Referral landing page visual design and CRO (use page-cro), signup flow optimization for referred users (use signup-flow-cro), post-signup onboarding for referred users (use onboarding-cro), churn prevention for referred customers (use churn-prevention), and reward pricing alignment (use pricing-strategy). Scripts operate on local data only -- no integrations with referral platforms (ReferralHero, Viral Loops, PartnerStack, etc.).\n\n**Limitations:** K-factor benchmarks assume consumer or prosumer SaaS; B2B enterprise referral programs have different dynamics (lower K but higher per-referral value). Affiliate commission benchmarks (20-30% recurring) are SaaS-specific; marketplace and e-commerce commissions follow different models. Attribution windows (30-90 day cookies) face increasing limitations from browser privacy features (Safari ITP, Chrome third-party cookie deprecation). Revenue projections are estimates based on provided conversion rates.\n\n## Integration Points\n\n- **pricing-strategy** -- Referral reward sizing must align with pricing margins and LTV; reward should be <30% of first payment\n- **signup-flow-cro** -- Referred user signup flow should pre-fill email, show referrer context, and minimize friction\n- **onboarding-cro** -- Referred users may need different onboarding path (they arrive with context from the referrer)\n- **churn-prevention** -- Monitor referred customer retention separately; high referral churn wastes acquisition spend\n- **page-cro** -- Referral landing page conversion optimization follows page-cro methodology\n- **popup-cro** -- Post-purchase or post-milestone popups are natural referral trigger points","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/referral-program","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/referral-program/SKILL.md","defaultBranch":"main"},"readme":"# Referral Program\n\nProduction-grade referral and affiliate program framework covering the 4-stage referral loop, incentive design methodology, trigger moment optimization, share mechanics, viral coefficient modeling, affiliate program architecture, and systematic optimization playbook. Designed to build programs that compound, not collect dust.\n\n## Core Capabilities\n\n- **Program type & loop design** β referral vs affiliate decision, plus the 4-stage loop (trigger β share β convert β reward)\n- **Incentive design** β single- vs double-sided, reward types, tiered gamification, reward economics against LTV/CAC\n- **Trigger & share mechanics** β in-product and email trigger points, share channel priority, first-person share copy\n- **Referred-user experience** β referral landing page, attribution rules, program copy set (prompts, emails, dashboards)\n- **Growth math** β K-factor modeling, revenue impact models, and lever-by-lever K improvement\n- **Affiliate framework** β commission models, tier systems, partner toolkit, recruitment\n- **Optimization** β diagnose-before-optimize playbook, metric benchmarks, troubleshooting, and three Python tools\n\n## When to Use\n\n- The user asks to \"design a referral program\", \"launch an affiliate program\", or \"improve viral growth\"\n- The decision between customer referral vs affiliate program needs to be made\n- An existing referral program has stalled (K-factor <1, low share rate, low referred-user conversion)\n- Reward structure needs sizing against CAC, margin, or LTV\n- Trigger moments need to be identified (when to ask, which in-product events, which lifecycle emails)\n- The user says \"word-of-mouth isn't working\" or \"we want to add a refer-a-friend flow\"\n\n## Clarify First\n\nBefore designing the referral program, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Program type** β customer referral vs affiliate (enthusiastic/social customers vs team buyers) (selects the entire framework)\n- [ ] **Trigger moment** β the in-product or lifecycle point where you ask (a broken Stage 1 can't be fixed by a bigger reward at Stage 4)\n- [ ] **Reward economics** β first-payment value, margin, and CAC (caps the reward at <30% of first payment)\n- [ ] **Current referral rate (if any)** β decides single- vs double-sided incentive and which stage to fix first\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## Quick Start\n\n1. **Pick the program type** β use the Referral vs Affiliate Decision table (enthusiastic/social customers β referral; team buyers β affiliate).\n2. **Build the loop in order** β trigger β share β convert β reward; a broken Stage 1 can't be fixed by a bigger reward at Stage 4.\n3. **Size the incentive** β cap reward at <30% of first payment; go double-sided if referral rate <1%.\n4. **Model and validate** β run the scripts (`referral_economics_calculator.py`, `referral_funnel_analyzer.py`, `affiliate_commission_modeler.py`) to size rewards, find the weakest stage, and model affiliate tiers.\n5. **Optimize by priority** β fix awareness first, then share flow, then referred experience, then the incentive.\n\n## References\n\nLoad the reference that matches the task β keep this file lean and pull detail on demand:\n\n- **[references/loop-and-incentives.md](references/loop-and-incentives.md)** β Referral vs Affiliate decision table, the full 4-stage loop with per-stage tables, incentive design (single/double-sided, reward types, tiers, economics), and trigger moment architecture. Read when designing the core program.\n- **[references/share-and-experience.md](references/share-and-experience.md)** β share channel priority, share message templates, referral landing page layout, attribution rules, and the program copy set (in-app prompt, dashboard, post-activation email). Read when building the sharing flow and referred-user experience.\n- **[references/modeling-and-affiliate.md](refe","createdAt":"2026-09-25T13:52:02.850Z","updatedAt":"2026-09-25T13:52:02.850Z"},{"id":"cmuh0s8q803rsqu06jw86f8cs","slug":"borghei-claude-skills-revenue-operations","name":"revenue-operations","description":"Analyzes pipeline coverage, tracks forecast accuracy with MAPE, and calculates GTM efficiency metrics for SaaS revenue optimization","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"revenue-operations","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Analyzes pipeline coverage, tracks forecast accuracy with MAPE, and calculates GTM efficiency metrics for SaaS revenue optimization","permissions":[],"systemPrompt":"# Revenue Operations\n\nPipeline analysis, forecast accuracy tracking, and GTM efficiency measurement for SaaS revenue teams.\n\n## Table of Contents\n\n- [Quick Start](#quick-start)\n- [Tools Overview](#tools-overview)\n - [Pipeline Analyzer](#1-pipeline-analyzer)\n - [Forecast Accuracy Tracker](#2-forecast-accuracy-tracker)\n - [GTM Efficiency Calculator](#3-gtm-efficiency-calculator)\n- [Revenue Operations Workflows](#revenue-operations-workflows)\n - [Weekly Pipeline Review](#weekly-pipeline-review)\n - [Forecast Accuracy Review](#forecast-accuracy-review)\n - [GTM Efficiency Audit](#gtm-efficiency-audit)\n - [Quarterly Business Review](#quarterly-business-review)\n- [Reference Documentation](#reference-documentation)\n- [Templates](#templates)\n\n---\n\n## Clarify First\n\nBefore running the analysis, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Which analysis** β pipeline health, forecast accuracy, or GTM efficiency (selects the script and its input schema)\n- [ ] **Quota / target** β the number pipeline coverage and Magic Number are measured against\n- [ ] **Data export readiness** β deals with stage/value/age/close-date, or forecast-vs-actual periods (the tools consume specific JSON; forecast trend needs 3+ periods)\n- [ ] **Company stage + sales motion** β seed vs growth, PLG vs enterprise (benchmarks vary widely by stage and motion)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the output.\n\n## Quick Start\n\n```bash\n# Analyze pipeline health and coverage\npython scripts/pipeline_analyzer.py --input assets/sample_pipeline_data.json --format text\n\n# Track forecast accuracy over multiple periods\npython scripts/forecast_accuracy_tracker.py assets/sample_forecast_data.json --format text\n\n# Calculate GTM efficiency metrics\npython scripts/gtm_efficiency_calculator.py assets/sample_gtm_data.json --format text\n```\n\n---\n\n## Tools Overview\n\n### 1. Pipeline Analyzer\n\nAnalyzes sales pipeline health including coverage ratios, stage conversion rates, deal velocity, aging risks, and concentration risks.\n\n**Input:** JSON file with deals, quota, and stage configuration\n**Output:** Coverage ratios, conversion rates, velocity metrics, aging flags, risk assessment\n\n**Usage:**\n\n```bash\n# Text report (human-readable)\npython scripts/pipeline_analyzer.py --input pipeline.json --format text\n\n# JSON output (for dashboards/integrations)\npython scripts/pipeline_analyzer.py --input pipeline.json --format json\n```\n\n**Key Metrics Calculated:**\n- **Pipeline Coverage Ratio** -- Total pipeline value / quota target (healthy: 3-4x)\n- **Stage Conversion Rates** -- Stage-to-stage progression rates\n- **Sales Velocity** -- (Opportunities x Avg Deal Size x Win Rate) / Avg Sales Cycle\n- **Deal Aging** -- Flags deals exceeding 2x average cycle time per stage\n- **Concentration Risk** -- Warns when >40% of pipeline is in a single deal\n- **Coverage Gap Analysis** -- Identifies quarters with insufficient pipeline\n\n**Input Schema:**\n\n```json\n{\n \"quota\": 500000,\n \"stages\": [\"Discovery\", \"Qualification\", \"Proposal\", \"Negotiation\", \"Closed Won\"],\n \"average_cycle_days\": 45,\n \"deals\": [\n {\n \"id\": \"D001\",\n \"name\": \"Acme Corp\",\n \"stage\": \"Proposal\",\n \"value\": 85000,\n \"age_days\": 32,\n \"close_date\": \"2025-03-15\",\n \"owner\": \"rep_1\"\n }\n ]\n}\n```\n\n### 2. Forecast Accuracy Tracker\n\nTracks forecast accuracy over time using MAPE, detects systematic bias, analyzes trends, and provides category-level breakdowns.\n\n**Input:** JSON file with forecast periods and optional category breakdowns\n**Output:** MAPE score, bias analysis, trends, category breakdown, accuracy rating\n\n**Usage:**\n\n```bash\n# Track forecast accuracy\npython scripts/forecast_accuracy_tracker.py forecast_data.json --format text\n\n# JSON output for trend analysis\npython scripts/forecast_accuracy_tracker.py forecast_data.json --format json\n```\n\n**Key Metrics Calculated:**\n- **MAPE** -- Mean Absolute Percentage Error: mean(|actual - forecast| / |actual|) x 100\n- **Forecast Bias** -- Over-forecasting (positive) vs under-forecasting (negative) tendency\n- **Weighted Accuracy** -- MAPE weighted by deal value for materiality\n- **Period Trends** -- Improving, stable, or declining accuracy over time\n- **Category Breakdown** -- Accuracy by rep, product, segment, or any custom dimension\n\n**Accuracy Ratings:**\n| Rating | MAPE Range | Interpretation |\n|--------|-----------|----------------|\n| Excellent | <10% | Highly predictable, data-driven process |\n| Good | 10-15% | Reliable forecasting with minor variance |\n| Fair | 15-25% | Needs process improvement |\n| Poor | >25% | Significant forecasting methodology gaps |\n\n**Input Schema:**\n\n```json\n{\n \"forecast_periods\": [\n {\"period\": \"2025-Q1\", \"forecast\": 480000, \"actual\": 520000},\n {\"period\": \"2025-Q2\", \"forecast\": 550000, \"actual\": 510000}\n ],\n \"category_breakdowns\": {\n \"by_rep\": [\n {\"category\": \"Rep A\", \"forecast\": 200000, \"actual\": 210000},\n {\"category\": \"Rep B\", \"forecast\": 280000, \"actual\": 310000}\n ]\n }\n}\n```\n\n### 3. GTM Efficiency Calculator\n\nCalculates core SaaS GTM efficiency metrics with industry benchmarking, ratings, and improvement recommendations.\n\n**Input:** JSON file with revenue, cost, and customer metrics\n**Output:** Magic Number, LTV:CAC, CAC Payback, Burn Multiple, Rule of 40, NDR with ratings\n\n**Usage:**\n\n```bash\n# Calculate all GTM efficiency metrics\npython scripts/gtm_efficiency_calculator.py gtm_data.json --format text\n\n# JSON output for dashboards\npython scripts/gtm_efficiency_calculator.py gtm_data.json --format json\n```\n\n**Key Metrics Calculated:**\n\n| Metric | Formula | Target |\n|--------|---------|--------|\n| Magic Number | Net New ARR / Prior Period S&M Spend | >0.75 |\n| LTV:CAC | (ARPA x Gross Margin / Churn Rate) / CAC | >3:1 |\n| CAC Payback | CAC / (ARPA x Gross Margin) months | <18 months |\n| Burn Multiple | Net Burn / Net New ARR | <2x |\n| Rule of 40 | Revenue Growth % + FCF Margin % | >40% |\n| Net Dollar Retention | (Begin ARR + Expansion - Contraction - Churn) / Begin ARR | >110% |\n\n**Input Schema:**\n\n```json\n{\n \"revenue\": {\n \"current_arr\": 5000000,\n \"prior_arr\": 3800000,\n \"net_new_arr\": 1200000,\n \"arpa_monthly\": 2500,\n \"revenue_growth_pct\": 31.6\n },\n \"costs\": {\n \"sales_marketing_spend\": 1800000,\n \"cac\": 18000,\n \"gross_margin_pct\": 78,\n \"total_operating_expense\": 6500000,\n \"net_burn\": 1500000,\n \"fcf_margin_pct\": 8.4\n },\n \"customers\": {\n \"beginning_arr\": 3800000,\n \"expansion_arr\": 600000,\n \"contraction_arr\": 100000,\n \"churned_arr\": 300000,\n \"annual_churn_rate_pct\": 8\n }\n}\n```\n\n---\n\n## Revenue Operations Workflows\n\n### Weekly Pipeline Review\n\nUse this workflow for your weekly pipeline inspection cadence.\n\n1. **Generate pipeline report:**\n ```bash\n python scripts/pipeline_analyzer.py --input current_pipeline.json --format text\n ```\n\n2. **Review key indicators:**\n - Pipeline coverage ratio (is it above 3x quota?)\n - Deals aging beyond threshold (which deals need intervention?)\n - Concentration risk (are we over-reliant on a few large deals?)\n - Stage distribution (is there a healthy funnel shape?)\n\n3. **Document using template:** Use `assets/pipeline_review_template.md`\n\n4. **Action items:** Address aging deals, redistribute pipeline concentration, fill coverage gaps\n\n### Forecast Accuracy Review\n\nUse monthly or quarterly to evaluate and improve forecasting discipline.\n\n1. **Generate accuracy report:**\n ```bash\n python scripts/forecast_accuracy_tracker.py forecast_history.json --format text\n ```\n\n2. **Analyze patterns:**\n - Is MAPE trending down (improving)?\n - Which reps or segments have the highest error rates?\n - Is there systematic over- or under-forecasting?\n\n3. **Document using template:** Use `assets/forecast_report_template.md`\n\n4. **Improvement actions:** Coach high-bias reps, adjust methodology, improve data hygiene\n\n### GTM Efficiency Audit\n\nUse quarterly or during board prep to evaluate go-to-market efficiency.\n\n1. **Calculate efficiency metrics:**\n ```bash\n python scripts/gtm_efficiency_calculator.py quarterly_data.json --format text\n ```\n\n2. **Benchmark against targets:**\n - Magic Number signals GTM spend efficiency\n - LTV:CAC validates unit economics\n - CAC Payback shows capital efficiency\n - Rule of 40 balances growth and profitability\n\n3. **Document using template:** Use `assets/gtm_dashboard_template.md`\n\n4. **Strategic decisions:** Adjust spend allocation, optimize channels, improve retention\n\n### Quarterly Business Review\n\nCombine all three tools for a comprehensive QBR analysis.\n\n1. Run pipeline analyzer for forward-looking coverage\n2. Run forecast tracker for backward-looking accuracy\n3. Run GTM calculator for efficiency benchmarks\n4. Cross-reference pipeline health with forecast accuracy\n5. Align GTM efficiency metrics with growth targets\n\n---\n\n## Reference Documentation\n\n| Reference | Description |\n|-----------|-------------|\n| [RevOps Metrics Guide](references/revops-metrics-guide.md) | Complete metrics hierarchy, definitions, formulas, and interpretation |\n| [Pipeline Management Framework](references/pipeline-management-framework.md) | Pipeline best practices, stage definitions, conversion benchmarks |\n| [GTM Efficiency Benchmarks](references/gtm-efficiency-benchmarks.md) | SaaS benchmarks by stage, industry standards, improvement strategies |\n\n---\n\n## Templates\n\n| Template | Use Case |\n|----------|----------|\n| [Pipeline Review Template](assets/pipeline_review_template.md) | Weekly/monthly pipeline inspection documentation |\n| [Forecast Report Template](assets/forecast_report_template.md) | Forecast accuracy reporting and trend analysis |\n| [GTM Dashboard Template](assets/gtm_dashboard_template.md) | GTM efficiency dashboard for leadership review |\n| [Sample Pipeline Data](assets/sample_pipeline_data.json) | Example input for pipeline_analyzer.py |\n| [Expected Output](assets/expected_output.json) | Reference output from pipeline_analyzer.py |\n\n---\n\n## Tool Reference\n\n### 1. pipeline_analyzer.py\n\nAnalyzes sales pipeline health including coverage ratios, stage conversion rates, sales velocity, deal aging risks, and concentration risks.\n\n```bash\npython scripts/pipeline_analyzer.py --input pipeline.json --format text\npython scripts/pipeline_analyzer.py --input pipeline.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `--input` | required | Path to JSON file with deals, quota, and stage configuration |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n### 2. forecast_accuracy_tracker.py\n\nTracks forecast accuracy over time using MAPE, detects systematic bias, analyzes trends, and provides category-level breakdowns.\n\n```bash\npython scripts/forecast_accuracy_tracker.py forecast_data.json --format text\npython scripts/forecast_accuracy_tracker.py forecast_data.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `forecast_data.json` | positional | Path to JSON file with forecast periods and optional category breakdowns |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n### 3. gtm_efficiency_calculator.py\n\nCalculates core SaaS GTM efficiency metrics with industry benchmarking, ratings, and improvement recommendations.\n\n```bash\npython scripts/gtm_efficiency_calculator.py gtm_data.json --format text\npython scripts/gtm_efficiency_calculator.py gtm_data.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `gtm_data.json` | positional | Path to JSON file with revenue, cost, and customer metrics |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Resolution |\n|---------|-------------|------------|\n| Pipeline coverage below 3x quota | Insufficient top-of-funnel activity or poor lead-to-opportunity conversion | Audit lead sources and conversion rates by stage; increase outbound activity or marketing spend in underperforming channels |\n| Forecast MAPE above 25% | Inconsistent deal stage criteria, sandbagging, or lack of inspection rigor | Standardize stage exit criteria; implement weekly pipeline reviews tied to velocity not just activity; coach high-bias reps individually |\n| Magic Number below 0.5 | GTM spend is inefficient relative to new ARR generated | Review channel ROI; reduce spend in low-performing channels; improve rep productivity before adding headcount |\n| LTV:CAC below 3:1 | CAC too high or churn eroding lifetime value | Address churn first (use churn-prevention skill); then optimize CAC by shifting to lower-cost acquisition channels |\n| Deals slipping past forecast close date | Lack of deal qualification, missing champion, or no compelling event | Implement MEDDIC/BANT qualification; require compelling event documentation for commit-stage deals |\n| Pipeline heavily concentrated in early stages | Poor stage progression indicating stalled deals or loose qualification | Set maximum stage age limits; implement automated alerts for deals exceeding 2x average cycle per stage |\n| Net Dollar Retention below 100% | Contraction and churn outpacing expansion revenue | Prioritize expansion playbooks for healthy accounts; conduct exit interviews for churning accounts; review pricing tier structure |\n\n---\n\n## Success Criteria\n\n- Pipeline coverage ratio stabilizes at 3-4x quota with healthy stage distribution\n- Forecast MAPE improves to below 15% (Good) or below 10% (Excellent) within two quarters\n- Magic Number exceeds 0.75 indicating efficient GTM spend\n- LTV:CAC ratio exceeds 3:1 with CAC payback under 18 months\n- Rule of 40 score exceeds 40% (revenue growth % + FCF margin %)\n- Net Dollar Retention exceeds 110% driven by expansion revenue\n- Deal slippage rate drops below 30% (improved from 2024 industry average of 44%)\n\n---\n\n## Scope & Limitations\n\n**In scope:** Pipeline health analysis (coverage, velocity, aging, concentration), forecast accuracy measurement (MAPE, bias, trends, category breakdowns), GTM efficiency metrics (Magic Number, LTV:CAC, CAC Payback, Burn Multiple, Rule of 40, NDR), weekly/monthly/quarterly review workflows, and QBR preparation combining all three analysis dimensions.\n\n**Out of scope:** CRM system administration or data extraction (tools consume JSON exports), deal-level sales coaching (tools flag deals but do not prescribe sales tactics), marketing attribution modeling, customer success health scoring (use customer-success-manager skill), and real-time pipeline monitoring. Tools analyze point-in-time snapshots; continuous monitoring requires integration with CRM/BI platforms.\n\n**Limitations:** Benchmarks are based on aggregate SaaS industry data and vary by company stage (seed, Series A-C, growth, public), vertical, and sales motion (PLG vs enterprise). Pipeline analysis assumes deal data includes accurate stage, value, age, and close date fields. Forecast accuracy requires minimum 3 periods for trend analysis. GTM metrics require accurate financial data that may not be available in early-stage companies.\n\n---\n\n## Integration Points\n\n- **sales-engineer** -- Pipeline deals requiring technical validation route through sales-engineer POC and RFP workflows\n- **customer-success-manager** -- Post-close handoff; NDR metrics depend on customer success health scoring and expansion plays\n- **pricing-strategy** -- Pricing model impacts pipeline velocity, deal sizes, and conversion rates; pricing changes require pipeline reforecasting\n- **churn-prevention** -- Churn rate directly impacts LTV:CAC and NDR metrics; reducing churn improves all GTM efficiency measures\n- **c-level-advisor** -- GTM efficiency metrics feed directly into board-level reporting and strategic resource allocation decisions","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/revenue-operations","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/revenue-operations/SKILL.md","defaultBranch":"main"},"readme":"# Revenue Operations\n\nPipeline analysis, forecast accuracy tracking, and GTM efficiency measurement for SaaS revenue teams.\n\n## Table of Contents\n\n- [Quick Start](#quick-start)\n- [Tools Overview](#tools-overview)\n - [Pipeline Analyzer](#1-pipeline-analyzer)\n - [Forecast Accuracy Tracker](#2-forecast-accuracy-tracker)\n - [GTM Efficiency Calculator](#3-gtm-efficiency-calculator)\n- [Revenue Operations Workflows](#revenue-operations-workflows)\n - [Weekly Pipeline Review](#weekly-pipeline-review)\n - [Forecast Accuracy Review](#forecast-accuracy-review)\n - [GTM Efficiency Audit](#gtm-efficiency-audit)\n - [Quarterly Business Review](#quarterly-business-review)\n- [Reference Documentation](#reference-documentation)\n- [Templates](#templates)\n\n---\n\n## Clarify First\n\nBefore running the analysis, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Which analysis** β pipeline health, forecast accuracy, or GTM efficiency (selects the script and its input schema)\n- [ ] **Quota / target** β the number pipeline coverage and Magic Number are measured against\n- [ ] **Data export readiness** β deals with stage/value/age/close-date, or forecast-vs-actual periods (the tools consume specific JSON; forecast trend needs 3+ periods)\n- [ ] **Company stage + sales motion** β seed vs growth, PLG vs enterprise (benchmarks vary widely by stage and motion)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the output.\n\n## Quick Start\n\n```bash\n# Analyze pipeline health and coverage\npython scripts/pipeline_analyzer.py --input assets/sample_pipeline_data.json --format text\n\n# Track forecast accuracy over multiple periods\npython scripts/forecast_accuracy_tracker.py assets/sample_forecast_data.json --format text\n\n# Calculate GTM efficiency metrics\npython scripts/gtm_efficiency_calculator.py assets/sample_gtm_data.json --format text\n```\n\n---\n\n## Tools Overview\n\n### 1. Pipeline Analyzer\n\nAnalyzes sales pipeline health including coverage ratios, stage conversion rates, deal velocity, aging risks, and concentration risks.\n\n**Input:** JSON file with deals, quota, and stage configuration\n**Output:** Coverage ratios, conversion rates, velocity metrics, aging flags, risk assessment\n\n**Usage:**\n\n```bash\n# Text report (human-readable)\npython scripts/pipeline_analyzer.py --input pipeline.json --format text\n\n# JSON output (for dashboards/integrations)\npython scripts/pipeline_analyzer.py --input pipeline.json --format json\n```\n\n**Key Metrics Calculated:**\n- **Pipeline Coverage Ratio** -- Total pipeline value / quota target (healthy: 3-4x)\n- **Stage Conversion Rates** -- Stage-to-stage progression rates\n- **Sales Velocity** -- (Opportunities x Avg Deal Size x Win Rate) / Avg Sales Cycle\n- **Deal Aging** -- Flags deals exceeding 2x average cycle time per stage\n- **Concentration Risk** -- Warns when >40% of pipeline is in a single deal\n- **Coverage Gap Analysis** -- Identifies quarters with insufficient pipeline\n\n**Input Schema:**\n\n```json\n{\n \"quota\": 500000,\n \"stages\": [\"Discovery\", \"Qualification\", \"Proposal\", \"Negotiation\", \"Closed Won\"],\n \"average_cycle_days\": 45,\n \"deals\": [\n {\n \"id\": \"D001\",\n \"name\": \"Acme Corp\",\n \"stage\": \"Proposal\",\n \"value\": 85000,\n \"age_days\": 32,\n \"close_date\": \"2025-03-15\",\n \"owner\": \"rep_1\"\n }\n ]\n}\n```\n\n### 2. Forecast Accuracy Tracker\n\nTracks forecast accuracy over time using MAPE, detects systematic bias, analyzes trends, and provides category-level breakdowns.\n\n**Input:** JSON file with forecast periods and optional category breakdowns\n**Output:** MAPE score, bias analysis, trends, category breakdown, accuracy rating\n\n**Usage:**\n\n```bash\n# Track forecast accuracy\npython scripts/forecast_accuracy_tracker.py forecast_data.json --format text\n\n# JSON output for trend analysis\npython scripts/forecast_accuracy_tracker.py forecast_data.json --format json\n```\n\n**Key Metrics Calculated:**\n","createdAt":"2026-09-25T13:52:02.864Z","updatedAt":"2026-09-25T13:52:02.864Z"},{"id":"cmuh0s8qt03ryqu06c0f5fgck","slug":"borghei-claude-skills-sales-engineer","name":"sales-engineer","description":"Analyzes RFP responses for coverage gaps, builds competitive feature matrices, and plans proof-of-concept engagements for pre-sales engineering","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"sales-engineer","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Analyzes RFP responses for coverage gaps, builds competitive feature matrices, and plans proof-of-concept engagements for pre-sales engineering","permissions":[],"systemPrompt":"# Sales Engineer Skill\n\nA production-ready skill package for pre-sales engineering that bridges technical expertise and sales execution. Provides automated analysis for RFP/RFI responses, competitive positioning, and proof-of-concept planning.\n\n## Overview\n\n**Role:** Sales Engineer / Solutions Architect\n**Domain:** Pre-Sales Engineering, Solution Design, Technical Demos, Proof of Concepts\n**Business Type:** SaaS / Pre-Sales Engineering\n\n### What This Skill Does\n\n- **RFP/RFI Response Analysis** - Score requirement coverage, identify gaps, generate bid/no-bid recommendations\n- **Competitive Technical Positioning** - Build feature comparison matrices, identify differentiators and vulnerabilities\n- **POC Planning** - Generate timelines, resource plans, success criteria, and evaluation scorecards\n- **Demo Preparation** - Structure demo scripts with talking points and objection handling\n- **Technical Proposal Creation** - Framework for solution architecture and implementation planning\n- **Win/Loss Analysis** - Data-driven competitive assessment for deal strategy\n\n### Key Metrics\n\n| Metric | Description | Target |\n|--------|-------------|--------|\n| Win Rate | Deals won / total opportunities | >30% |\n| Sales Cycle Length | Average days from discovery to close | <90 days |\n| POC Conversion Rate | POCs resulting in closed deals | >60% |\n| Customer Engagement Score | Stakeholder participation in evaluation | >75% |\n| RFP Coverage Score | Requirements fully addressed | >80% |\n\n## Clarify First\n\nBefore producing the deliverable, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Which deliverable** β RFP/RFI coverage analysis, competitive matrix, or POC plan (selects the tool and phase)\n- [ ] **Customer requirements + priorities** β the must/should/nice-to-have list (drives weighted coverage and the bid/no-bid call)\n- [ ] **Competitor(s) in the deal** β needed for the feature matrix, differentiators, and battlecard\n- [ ] **POC scope + success criteria** β when planning a POC, the use cases and measurable go/no-go bar (prevents an unbounded POC)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## 5-Phase Workflow\n\n### Phase 1: Discovery & Research\n\n**Objective:** Understand customer requirements, technical environment, and business drivers.\n\n**Activities:**\n1. Conduct technical discovery calls with stakeholders\n2. Map customer's current architecture and pain points\n3. Identify integration requirements and constraints\n4. Document security and compliance requirements\n5. Assess competitive landscape for this opportunity\n\n**Tools:** Use `rfp_response_analyzer.py` to score initial requirement alignment.\n\n**Output:** Technical discovery document, requirement map, initial coverage assessment.\n\n### Phase 2: Solution Design\n\n**Objective:** Design a solution architecture that addresses customer requirements.\n\n**Activities:**\n1. Map product capabilities to customer requirements\n2. Design integration architecture\n3. Identify customization needs and development effort\n4. Build competitive differentiation strategy\n5. Create solution architecture diagrams\n\n**Tools:** Use `competitive_matrix_builder.py` to identify differentiators and vulnerabilities.\n\n**Output:** Solution architecture, competitive positioning, technical differentiation strategy.\n\n### Phase 3: Demo Preparation & Delivery\n\n**Objective:** Deliver compelling technical demonstrations tailored to stakeholder priorities.\n\n**Activities:**\n1. Build demo environment matching customer's use case\n2. Create demo script with talking points per stakeholder role\n3. Prepare objection handling responses\n4. Rehearse failure scenarios and recovery paths\n5. Collect feedback and adjust approach\n\n**Templates:** Use `demo_script_template.md` for structured demo preparation.\n\n**Output:** Customized demo, stakeholder-specific talking points, feedback capture.\n\n### Phase 4: POC & Evaluation\n\n**Objective:** Execute a structured proof-of-concept that validates the solution.\n\n**Activities:**\n1. Define POC scope, success criteria, and timeline\n2. Allocate resources and set up environment\n3. Execute phased testing (core, advanced, edge cases)\n4. Track progress against success criteria\n5. Generate evaluation scorecard\n\n**Tools:** Use `poc_planner.py` to generate the complete POC plan.\n\n**Templates:** Use `poc_scorecard_template.md` for evaluation tracking.\n\n**Output:** POC plan, evaluation scorecard, go/no-go recommendation.\n\n### Phase 5: Proposal & Closing\n\n**Objective:** Deliver a technical proposal that supports the commercial close.\n\n**Activities:**\n1. Compile POC results and success metrics\n2. Create technical proposal with implementation plan\n3. Address outstanding objections with evidence\n4. Support pricing and packaging discussions\n5. Conduct win/loss analysis post-decision\n\n**Templates:** Use `technical_proposal_template.md` for the proposal document.\n\n**Output:** Technical proposal, implementation timeline, risk mitigation plan.\n\n## Python Automation Tools\n\n### 1. RFP Response Analyzer\n\n**Script:** `scripts/rfp_response_analyzer.py`\n\n**Purpose:** Parse RFP/RFI requirements, score coverage, identify gaps, and generate bid/no-bid recommendations.\n\n**Coverage Categories:**\n- **Full (100%)** - Requirement fully met by current product\n- **Partial (50%)** - Requirement partially met, workaround or configuration needed\n- **Planned (25%)** - On product roadmap, not yet available\n- **Gap (0%)** - Not supported, no current plan\n\n**Priority Weighting:**\n- Must-Have: 3x weight\n- Should-Have: 2x weight\n- Nice-to-Have: 1x weight\n\n**Bid/No-Bid Logic:**\n- **Bid:** Coverage score >70% AND must-have gaps <=3\n- **Conditional Bid:** Coverage score 50-70% OR must-have gaps 2-3\n- **No-Bid:** Coverage score <50% OR must-have gaps >3\n\n**Usage:**\n```bash\n# Human-readable output\npython scripts/rfp_response_analyzer.py assets/sample_rfp_data.json\n\n# JSON output\npython scripts/rfp_response_analyzer.py assets/sample_rfp_data.json --format json\n\n# Help\npython scripts/rfp_response_analyzer.py --help\n```\n\n**Input Format:** See `assets/sample_rfp_data.json` for the complete schema.\n\n### 2. Competitive Matrix Builder\n\n**Script:** `scripts/competitive_matrix_builder.py`\n\n**Purpose:** Generate feature comparison matrices, calculate competitive scores, identify differentiators and vulnerabilities.\n\n**Feature Scoring:**\n- **Full (3)** - Complete feature support\n- **Partial (2)** - Partial or limited feature support\n- **Limited (1)** - Minimal or basic feature support\n- **None (0)** - Feature not available\n\n**Usage:**\n```bash\n# Human-readable output\npython scripts/competitive_matrix_builder.py competitive_data.json\n\n# JSON output\npython scripts/competitive_matrix_builder.py competitive_data.json --format json\n```\n\n**Output Includes:**\n- Feature comparison matrix with scores\n- Weighted competitive scores per product\n- Differentiators (features where our product leads)\n- Vulnerabilities (features where competitors lead)\n- Win themes based on differentiators\n\n### 3. POC Planner\n\n**Script:** `scripts/poc_planner.py`\n\n**Purpose:** Generate structured POC plans with timeline, resource allocation, success criteria, and evaluation scorecards.\n\n**Default Phase Breakdown:**\n- **Week 1:** Setup - Environment provisioning, data migration, configuration\n- **Weeks 2-3:** Core Testing - Primary use cases, integration testing\n- **Week 4:** Advanced Testing - Edge cases, performance, security\n- **Week 5:** Evaluation - Scorecard completion, stakeholder review, go/no-go\n\n**Usage:**\n```bash\n# Human-readable output\npython scripts/poc_planner.py poc_data.json\n\n# JSON output\npython scripts/poc_planner.py poc_data.json --format json\n```\n\n**Output Includes:**\n- POC plan with phased timeline\n- Resource allocation (SE, engineering, customer)\n- Success criteria with measurable metrics\n- Evaluation scorecard (functionality, performance, integration, usability, support)\n- Risk register with mitigation strategies\n- Go/No-Go recommendation framework\n\n## Reference Knowledge Bases\n\n| Reference | Description |\n|-----------|-------------|\n| `references/rfp-response-guide.md` | RFP/RFI response best practices, compliance matrix, bid/no-bid framework |\n| `references/competitive-positioning-framework.md` | Competitive analysis methodology, battlecard creation, objection handling |\n| `references/poc-best-practices.md` | POC planning methodology, success criteria, evaluation frameworks |\n\n## Asset Templates\n\n| Template | Purpose |\n|----------|---------|\n| `assets/technical_proposal_template.md` | Technical proposal with executive summary, solution architecture, implementation plan |\n| `assets/demo_script_template.md` | Demo script with agenda, talking points, objection handling |\n| `assets/poc_scorecard_template.md` | POC evaluation scorecard with weighted scoring |\n| `assets/sample_rfp_data.json` | Sample RFP data for testing the analyzer |\n| `assets/expected_output.json` | Expected output from rfp_response_analyzer.py |\n\n## Communication Style\n\n- **Technical yet accessible** - Translate complex concepts for business stakeholders\n- **Confident and consultative** - Position as trusted advisor, not vendor\n- **Evidence-based** - Back every claim with data, demos, or case studies\n- **Stakeholder-aware** - Tailor depth and focus to audience (CTO vs. end user vs. procurement)\n\n## Integration Points\n\n- **Marketing Skills** - Leverage competitive intelligence and messaging frameworks from `../../marketing/`\n- **Product Team** - Coordinate on roadmap items flagged as \"Planned\" in RFP analysis from `../../product-team/`\n- **C-Level Advisory** - Escalate strategic deals requiring executive engagement from `../../c-level-advisor/`\n- **Customer Success** - Hand off POC results and success criteria to CSM from `../customer-success-manager/`\n\n---\n\n## Tool Reference\n\n### 1. rfp_response_analyzer.py\n\nParses RFP/RFI requirements and scores coverage using Full/Partial/Planned/Gap categories. Generates weighted coverage scores, gap analysis, effort estimation, and bid/no-bid recommendations.\n\n```bash\npython scripts/rfp_response_analyzer.py rfp_data.json\npython scripts/rfp_response_analyzer.py rfp_data.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `rfp_data.json` | positional | Path to JSON file with RFP requirements and coverage data |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n**Bid/No-Bid Logic:**\n- **Bid:** Coverage score >70% AND must-have gaps <=3\n- **Conditional Bid:** Coverage score 50-70% OR must-have gaps 2-3\n- **No-Bid:** Coverage score <50% OR must-have gaps >3\n\n### 2. competitive_matrix_builder.py\n\nGenerates feature comparison matrices, calculates weighted competitive scores, identifies differentiators and vulnerabilities, and produces win themes.\n\n```bash\npython scripts/competitive_matrix_builder.py competitive_data.json\npython scripts/competitive_matrix_builder.py competitive_data.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `competitive_data.json` | positional | Path to JSON file with feature comparison data |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n**Scoring:** Full (3), Partial (2), Limited (1), None (0)\n\n### 3. poc_planner.py\n\nGenerates structured POC plans with phased timelines, resource allocation, success criteria, evaluation scorecards, risk registers, and go/no-go frameworks.\n\n```bash\npython scripts/poc_planner.py poc_data.json\npython scripts/poc_planner.py poc_data.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `poc_data.json` | positional | Path to JSON file with POC scope and requirements |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n**Default Phase Breakdown:** Week 1 Setup, Weeks 2-3 Core Testing, Week 4 Advanced Testing, Week 5 Evaluation\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Resolution |\n|---------|-------------|------------|\n| RFP coverage score below 50% triggering No-Bid | Product gaps in must-have requirements or incorrect coverage assessment | Review gap items -- distinguish true gaps from items addressable via configuration, integration, or roadmap commitment; reassess before declining |\n| Competitive matrix shows vulnerabilities in 3+ categories | Product gaps relative to a specific competitor, or scoring does not reflect actual competitive dynamics | Validate scoring with field SEs who have competed against this vendor; focus battlecard on differentiators where you lead, not where you trail |\n| POC-to-close conversion below 60% | POC scope too broad, success criteria not aligned with buyer priorities, or wrong stakeholders involved | Narrow POC to 3-5 use cases tied to buyer's stated pain; get written agreement on success criteria before starting; ensure executive sponsor participates in evaluation |\n| Win rate below 30% | Technical win but commercial loss, late involvement in deal, or poor discovery leading to misaligned demos | Engage earlier in sales cycle; improve discovery quality using MEDDIC framework; align demo storyline to buyer's language not product features |\n| Demo-to-POC conversion below 40% | Demo did not address buyer's specific use case or was too generic | Customize every demo to buyer's stated requirements; use their data or industry-specific scenarios; include Q&A and next-step proposal at end |\n| RFP response time exceeds 2 weeks | Manual response process without templates or pre-built content library | Build a response library indexed by requirement category; use rfp_response_analyzer.py to prioritize effort on must-have items |\n| Stakeholder engagement score below 75% | Key decision-makers not involved in technical evaluation | Map stakeholder roles early; ensure executive briefing alongside technical deep-dives; send personalized follow-up to each stakeholder |\n\n---\n\n## Success Criteria\n\n- Win rate exceeds 30% across all competitive opportunities\n- Sales cycle length stays below 90 days from discovery to close\n- POC-to-close conversion rate exceeds 60%\n- RFP coverage score averages above 80% for opportunities pursued (bid decisions working correctly)\n- Competitive matrix identifies minimum 3 clear differentiators per competitor\n- Customer engagement score exceeds 75% (measured by stakeholder participation in evaluation milestones)\n- Average RFP response time drops below 5 business days with structured response library\n\n---\n\n## Scope & Limitations\n\n**In scope:** RFP/RFI response analysis and scoring, competitive feature matrix construction, proof-of-concept planning and evaluation, demo preparation frameworks, technical proposal structure, win/loss analysis methodology, and stakeholder engagement tracking across the 5-phase pre-sales workflow (Discovery, Solution Design, Demo, POC, Proposal).\n\n**Out of scope:** Sales strategy and territory planning (account executive function), pricing and commercial terms negotiation (use pricing-strategy), post-sale implementation and customer success (use customer-success-manager), marketing content and competitive messaging (use marketing skills), and product roadmap decisions based on RFP gaps (use product-team). Tools analyze static data exports -- no integrations with CRM systems (Salesforce, HubSpot) or RFP platforms (Loopio, Arphie).\n\n**Limitations:** Bid/no-bid thresholds are configurable but defaults assume B2B SaaS with 30%+ win-rate targets. Competitive matrix scoring is only as accurate as the input data -- validate scores with field experience against specific competitors. POC timelines assume standard 5-week engagement; highly regulated industries (healthcare, government) may require 2-3x longer. AI-assisted RFP tools (emerging in 2025-2026) can reduce response time 60-80% but are not integrated here.\n\n---\n\n## Integration Points\n\n- **revenue-operations** -- Pipeline deals requiring technical validation flow through SE workflow; SE win/loss data feeds pipeline analysis\n- **customer-success-manager** -- POC results and success criteria hand off to CSM for post-close adoption tracking\n- **pricing-strategy** -- Competitive pricing data from matrix builder informs pricing positioning decisions\n- **product-team** -- RFP gaps flagged as \"Planned\" or \"Gap\" feed into product roadmap prioritization\n- **c-level-advisor** -- Strategic deals requiring executive engagement escalate through C-level advisory workflow\n- **marketing** -- Competitive intelligence from marketing feeds into battlecard creation and positioning\n\n---\n\n**Last Updated:** March 2026\n**Status:** Production-ready\n**Tools:** 3 Python automation scripts\n**References:** 3 knowledge base documents\n**Templates:** 5 asset files","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/sales-engineer","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/sales-engineer/SKILL.md","defaultBranch":"main"},"readme":"# Sales Engineer Skill\n\nA production-ready skill package for pre-sales engineering that bridges technical expertise and sales execution. Provides automated analysis for RFP/RFI responses, competitive positioning, and proof-of-concept planning.\n\n## Overview\n\n**Role:** Sales Engineer / Solutions Architect\n**Domain:** Pre-Sales Engineering, Solution Design, Technical Demos, Proof of Concepts\n**Business Type:** SaaS / Pre-Sales Engineering\n\n### What This Skill Does\n\n- **RFP/RFI Response Analysis** - Score requirement coverage, identify gaps, generate bid/no-bid recommendations\n- **Competitive Technical Positioning** - Build feature comparison matrices, identify differentiators and vulnerabilities\n- **POC Planning** - Generate timelines, resource plans, success criteria, and evaluation scorecards\n- **Demo Preparation** - Structure demo scripts with talking points and objection handling\n- **Technical Proposal Creation** - Framework for solution architecture and implementation planning\n- **Win/Loss Analysis** - Data-driven competitive assessment for deal strategy\n\n### Key Metrics\n\n| Metric | Description | Target |\n|--------|-------------|--------|\n| Win Rate | Deals won / total opportunities | >30% |\n| Sales Cycle Length | Average days from discovery to close | <90 days |\n| POC Conversion Rate | POCs resulting in closed deals | >60% |\n| Customer Engagement Score | Stakeholder participation in evaluation | >75% |\n| RFP Coverage Score | Requirements fully addressed | >80% |\n\n## Clarify First\n\nBefore producing the deliverable, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Which deliverable** β RFP/RFI coverage analysis, competitive matrix, or POC plan (selects the tool and phase)\n- [ ] **Customer requirements + priorities** β the must/should/nice-to-have list (drives weighted coverage and the bid/no-bid call)\n- [ ] **Competitor(s) in the deal** β needed for the feature matrix, differentiators, and battlecard\n- [ ] **POC scope + success criteria** β when planning a POC, the use cases and measurable go/no-go bar (prevents an unbounded POC)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the deliverable.\n\n## 5-Phase Workflow\n\n### Phase 1: Discovery & Research\n\n**Objective:** Understand customer requirements, technical environment, and business drivers.\n\n**Activities:**\n1. Conduct technical discovery calls with stakeholders\n2. Map customer's current architecture and pain points\n3. Identify integration requirements and constraints\n4. Document security and compliance requirements\n5. Assess competitive landscape for this opportunity\n\n**Tools:** Use `rfp_response_analyzer.py` to score initial requirement alignment.\n\n**Output:** Technical discovery document, requirement map, initial coverage assessment.\n\n### Phase 2: Solution Design\n\n**Objective:** Design a solution architecture that addresses customer requirements.\n\n**Activities:**\n1. Map product capabilities to customer requirements\n2. Design integration architecture\n3. Identify customization needs and development effort\n4. Build competitive differentiation strategy\n5. Create solution architecture diagrams\n\n**Tools:** Use `competitive_matrix_builder.py` to identify differentiators and vulnerabilities.\n\n**Output:** Solution architecture, competitive positioning, technical differentiation strategy.\n\n### Phase 3: Demo Preparation & Delivery\n\n**Objective:** Deliver compelling technical demonstrations tailored to stakeholder priorities.\n\n**Activities:**\n1. Build demo environment matching customer's use case\n2. Create demo script with talking points per stakeholder role\n3. Prepare objection handling responses\n4. Rehearse failure scenarios and recovery paths\n5. Collect feedback and adjust approach\n\n**Templates:** Use `demo_script_template.md` for structured demo preparation.\n\n**Output:** Customized demo, stakeholder-specific talking points, feedback capture.\n\n### Phase 4: POC ","createdAt":"2026-09-25T13:52:02.883Z","updatedAt":"2026-09-25T13:52:02.883Z"},{"id":"cmuh0s8rl03s4qu06gag331mf","slug":"borghei-claude-skills-signup-flow-cro","name":"signup-flow-cro","description":"Signup and registration flow optimization covering SSO strategy, progressive profiling, field reduction, multi-step flow design, authentication UX, post-submit experience, and mobile registration patterns.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"signup-flow-cro","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Signup and registration flow optimization covering SSO strategy, progressive profiling, field reduction, multi-step flow design, authentication UX, post-submit experience, and mobile registration patterns.","permissions":[],"systemPrompt":"# Signup Flow CRO\n\nProduction-grade signup and registration optimization framework covering authentication strategy, field reduction methodology, multi-step flow architecture, SSO implementation, progressive profiling, credit card requirement analysis, post-submit experience design, and mobile-specific registration patterns. For post-signup onboarding, use onboarding-cro. For lead capture forms (not account creation), use form-cro.\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [Authentication Strategy](#authentication-strategy)\n- [Field Reduction Methodology](#field-reduction-methodology)\n- [Multi-Step Flow Architecture](#multi-step-flow-architecture)\n- [Credit Card Requirement Analysis](#credit-card-requirement-analysis)\n- [Post-Submit Experience](#post-submit-experience)\n- [Mobile Signup Optimization](#mobile-signup-optimization)\n- [Signup Flow Patterns by Product Type](#signup-flow-patterns-by-product-type)\n- [Progressive Profiling](#progressive-profiling)\n- [Error and Edge Case Handling](#error-and-edge-case-handling)\n- [A/B Test Framework](#ab-test-framework)\n- [Metrics and Benchmarks](#metrics-and-benchmarks)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore optimizing the signup flow, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Flow type** β free trial, freemium, paid, or waitlist (determines friction tolerance and minimum field set)\n- [ ] **B2B or B2C** β B2B tolerates more fields; B2C needs minimal friction (sets SSO priority and field count)\n- [ ] **Current fields + completion rate + drop-off** β baseline and the friction point to cut (each removed field ~+10%)\n- [ ] **Data truly needed before first product use** β separates must-have fields from those to defer or enrich (the \"Before First Use\" test)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the audit.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| Flow type? (free trial, freemium, paid, waitlist) | Determines friction tolerance |\n| B2B or B2C? | B2B tolerates more fields, B2C needs minimal friction |\n| How many steps/screens currently? | Baseline for optimization |\n| What fields are required? | Identifies reduction opportunities |\n| Current completion rate? | Benchmark for improvement |\n| Where do users drop off? (field-level data) | Pinpoints specific friction |\n| What data is needed before first product use? | Separates must-have from nice-to-have |\n| What compliance requirements exist? | Constrains what can be deferred |\n\n---\n\n## Authentication Strategy\n\n### Authentication Methods Ranked by Friction\n\n| Method | Friction Level | Best For | Conversion Impact |\n|--------|---------------|----------|------------------|\n| Google SSO (one-click) | Very low | B2B SaaS, productivity tools | +15-30% vs email+password |\n| Apple Sign In | Very low | iOS/Mac-heavy audience | +10-20% on Apple devices |\n| Microsoft SSO | Low | Enterprise B2B | +10-15% for enterprise |\n| GitHub SSO | Low | Developer tools | +15-25% for dev audience |\n| Magic link (email) | Low | Security-conscious, B2B | +5-10% vs password |\n| Email + password | Medium | Universal fallback | Baseline |\n| Phone + OTP | Medium | Mobile-first, B2C | Varies by market |\n| Email + password + verification | High | When verification is required | -10-20% vs no verification |\n\n### SSO Strategy Decision\n\n| Your Audience | Primary SSO | Secondary SSO | Keep Email+Password? |\n|--------------|-------------|---------------|---------------------|\n| B2B SaaS (general) | Google Workspace | Microsoft | Yes |\n| Developer tools | GitHub | Google | Yes |\n| Enterprise | Microsoft/Okta | Google | Yes (for personal evals) |\n| B2C consumer | Google | Apple | Yes |\n| Mobile-first | Apple / Google | Phone OTP | Optional |\n| Privacy-focused | Magic link | Email+password | Yes |\n\n### SSO Placement\n\n```\nββββββββββββββββββββββββββββββββββββ\nβ Create your account β\nβ β\nβ [Continue with Google] β β SSO options first\nβ [Continue with Microsoft] β\nβ β\nβ ββββ or ββββ β β Visual separator\nβ β\nβ Email: [_______________] β β Email+password as alternative\nβ Password: [_______________] β\nβ β\nβ [Create Account] β\nββββββββββββββββββββββββββββββββββββ\n```\n\n**Rules:**\n- SSO buttons above the email form (not below)\n- Use branded button styles (Google's official button, etc.)\n- \"or\" divider between SSO and email options\n- SSO reduces fields to zero (name and email come from the provider)\n\n---\n\n## Field Reduction Methodology\n\n### The \"Before First Use\" Test\n\nFor every field, ask: **Does the product literally not function without this data?**\n\n| Field | Passes Test? | Action |\n|-------|-------------|--------|\n| Email | Yes (account identity) | Keep |\n| Password | Yes (account security) | Keep (or use SSO/magic link) |\n| First name | Usually no | Defer to onboarding or profile |\n| Last name | No | Defer or drop entirely |\n| Company name | Usually no | Enrich from email domain |\n| Phone number | Rarely | Defer unless SMS verification required |\n| Job title | No | Defer to onboarding or enrich |\n| Team size | No | Defer to onboarding |\n| How did you hear about us? | Never | Post-signup survey or attribution |\n| Industry | No | Enrich from company data |\n\n### Enrichment Sources\n\n| Field | Enrichment Method | Timing |\n|-------|-------------------|--------|\n| Company name | Email domain lookup (Clearbit, Apollo) | Immediately post-signup |\n| Company size | Company data API | Immediately post-signup |\n| Industry | Company data API | Immediately post-signup |\n| Job title | LinkedIn API or manual CSM research | Before first sales contact |\n| Location | IP geolocation | On signup |\n\n### Minimum Viable Field Sets\n\n| Signup Type | Minimum Fields | Additional (if needed) |\n|------------|----------------|----------------------|\n| Freemium | Email only (or SSO) | -- |\n| Free trial (product-led) | Email + Password (or SSO) | -- |\n| Free trial (sales-assisted) | Email + Password + Company | + Role (for routing) |\n| Paid signup | Email + Password + Payment | -- |\n| Waitlist | Email | + One qualifying question |\n| Enterprise trial | Email + Company + Role | + Team size (for provisioning) |\n\n---\n\n## Multi-Step Flow Architecture\n\n### When to Use Multi-Step\n\n| Condition | Single-Step | Multi-Step |\n|-----------|------------|------------|\n| Total fields | 1-4 | 5+ |\n| Need to qualify/route | No | Yes |\n| Product needs configuration | No | Yes |\n| B2B with team setup | No | Yes |\n\n### Step Design\n\n**Step 1: Account Creation (lowest friction)**\n- Email + Password (or SSO)\n- NOTHING else on this step\n- This is where 60%+ of abandonment happens if overloaded\n\n**Step 2: Personalization (if needed)**\n- Role / goal / use case selection\n- This personalizes their product experience\n- Skip button available (\"Set up later\")\n\n**Step 3: Configuration (if needed)**\n- Team invite, integration connect, data import\n- Each sub-step is optional with \"Skip for now\"\n- Show value of completing each (\"Invite your team to collaborate\")\n\n### Progress Design\n\n- Show step count: \"Step 1 of 3\"\n- Show progress bar\n- Label each step descriptively: \"Create Account\", \"Your Role\", \"Your Team\"\n- Allow back navigation (preserve entered data)\n- Never reset the form on back navigation or browser back button\n\n---\n\n## Credit Card Requirement Analysis\n\n### Decision Framework\n\n| Factor | Require CC | Do Not Require CC |\n|--------|-----------|------------------|\n| Trial conversion goal | > 60% trial-to-paid | > 30% trial-to-paid with higher volume |\n| Product complexity | Simple, immediate value | Complex, needs exploration |\n| ACV | > $100/month | < $100/month |\n| Sales motion | Product-led | Sales-assisted |\n| Competitor practice | Competitors require CC | Competitors offer CC-free trial |\n| Target audience | Enterprise (committed buyers) | SMB/prosumer (browsers) |\n\n### Impact Analysis\n\n| Approach | Signup Volume | Trial Quality | Trial-to-Paid | Net Revenue |\n|----------|-------------|---------------|---------------|-------------|\n| No CC required | Higher (+40-80%) | Lower (more tire-kickers) | Lower (2-15%) | Often higher net |\n| CC required | Lower | Higher (committed) | Higher (40-70%) | Depends on volume |\n| CC with \"$0 charge\" | Middle | Middle | Middle (20-40%) | Middle |\n\n### Recommendation Framework\n\n**Default to no CC required** unless:\n1. Your product delivers immediate, obvious value (no learning curve)\n2. Your trial-to-paid with CC is > 50%\n3. You have a high-touch sales team to handle lower volume\n4. Support costs for free trials are unsustainable\n\n**If requiring CC:** Display prominently:\n- \"You won't be charged until [date]\"\n- \"Cancel anytime before [date]\"\n- \"We'll email you 3 days before your trial ends\"\n\n---\n\n## Post-Submit Experience\n\n### Immediately After Signup\n\n| Element | Implementation |\n|---------|---------------|\n| Auto-login | Log the user in immediately (never force a separate login) |\n| Welcome screen | Show a clear next step, not a blank dashboard |\n| Confirmation email | Send immediately, include: what to expect, key features, support contact |\n| Email verification | Defer if possible. If required, send inline and let them continue using the product before verifying |\n\n### Email Verification Strategy\n\n| Approach | Impact on Activation | When to Use |\n|----------|---------------------|-------------|\n| No verification | Best activation rate | Low-risk products, freemium |\n| Verify to unlock specific feature | Good -- users activate first | B2B SaaS with free tier |\n| Verify within 24 hours | Moderate -- creates urgency | Products that send emails |\n| Verify before any use | Worst activation rate | Regulated industries, financial products |\n\n**Default recommendation:** Let users use the product immediately. Verify within 24-48 hours. Gate only the features that require a verified email (e.g., sending emails, team invites).\n\n---\n\n## Mobile Signup Optimization\n\n### Mobile-Specific Rules\n\n| Rule | Implementation |\n|------|---------------|\n| SSO first | Google/Apple Sign In is one tap on mobile |\n| One column | Never use side-by-side fields on mobile |\n| Large inputs | Minimum 44px height for all touch targets |\n| Appropriate keyboards | `type=\"email\"`, `type=\"tel\"`, `type=\"password\"` |\n| Auto-fill support | Use standard field names for browser auto-fill |\n| Sticky CTA | Pin \"Create Account\" button to bottom of viewport |\n| No CAPTCHA | Use invisible reCAPTCHA or alternatives |\n| Password visibility | Toggle to show/hide password |\n\n### Mobile vs Desktop Signup Differences\n\n| Aspect | Desktop | Mobile |\n|--------|---------|--------|\n| Primary auth | SSO or Email+Password | SSO preferred (one-tap) |\n| Fields per screen | Up to 5 | Max 3 |\n| Password rules | Show requirements upfront | Show on interaction |\n| CAPTCHA | Standard reCAPTCHA acceptable | Invisible or none |\n| Social proof | Sidebar or adjacent | Below form or above |\n\n---\n\n## Signup Flow Patterns by Product Type\n\n### B2B SaaS Trial\n\n```\n[Google SSO] or [Email + Password]\nβ Auto-login to product\nβ Welcome screen: \"What brings you here?\" (3 options)\nβ Guided first action based on selection\nβ Team invite prompt (optional, day 2-3)\n```\n\n### B2C Consumer App\n\n```\n[Apple Sign In] or [Google Sign In] or [Email]\nβ Immediately into product\nβ Personalization (follows, preferences) inline\nβ Profile completion deferred\n```\n\n### Enterprise/Sales-Assisted\n\n```\n[Work Email + Password + Company Name]\nβ Auto-login to sandbox\nβ Role + team size (for provisioning)\nβ CSM outreach triggered for qualified accounts\nβ Guided setup with dedicated support\n```\n\n### Waitlist / Early Access\n\n```\n[Email only]\nβ Confirmation page: position in waitlist\nβ Referral mechanism: \"Jump ahead by sharing\"\nβ Weekly update email on progress\nβ Access granted email with one-click activation\n```\n\n---\n\n## Progressive Profiling\n\nCollect information over multiple sessions instead of one long form.\n\n### Progressive Profiling Schedule\n\n| Session | What to Collect | How |\n|---------|----------------|-----|\n| Signup (session 1) | Email + auth | Signup form |\n| First use (session 1-2) | Role, primary goal | In-product prompt or setup wizard |\n| Day 3-5 | Team size, use case | Contextual question in product |\n| Day 7-14 | Industry, company size | Survey or enrichment |\n| Before first payment | Billing info | Upgrade flow |\n\n### Implementation Rules\n\n- Each profiling touchpoint asks 1-2 questions maximum\n- Always explain why you are asking (\"So we can personalize your experience\")\n- Always provide a \"Skip\" option\n- Never ask for information you can enrich automatically\n- Store partial profiles and build over time\n\n---\n\n## Error and Edge Case Handling\n\n### Password Requirements\n\n| Approach | User Experience | Security |\n|----------|----------------|----------|\n| Show requirements upfront | Best -- user knows what to enter | Good |\n| Show requirements on focus | Good | Good |\n| Show errors only after submit | Bad -- frustrating | Same |\n| Real-time checkmarks | Best -- progressive validation | Good |\n\n**Recommended:** Show password requirements as a checklist that checks off in real-time as the user types.\n\n### Common Error Scenarios\n\n| Error | Bad UX | Good UX |\n|-------|--------|---------|\n| Email already registered | \"Error: account exists\" | \"This email already has an account. [Log in] or [Reset password]\" |\n| Weak password | \"Password too weak\" | Checkmarks showing which requirements are met/unmet |\n| SSO failure | Generic error page | \"Something went wrong with Google login. [Try again] or [Use email instead]\" |\n| Network error | Form clears, no message | \"Connection issue. Your data is saved. [Try again]\" |\n| Rate limiting | Blocked with no explanation | \"Too many attempts. Please try again in [N] minutes\" |\n\n---\n\n## A/B Test Framework\n\n### High-Impact Tests\n\n| Test | Hypothesis | Metric |\n|------|-----------|--------|\n| Add Google SSO | SSO increases completion by 15-30% | Signup completion rate |\n| Remove non-essential fields | Fewer fields = higher completion | Completion rate + activation rate |\n| Single-step vs multi-step | Multi-step feels easier for 5+ field forms | Completion rate |\n| CC required vs not | No CC increases volume enough to offset lower conversion | Net revenue |\n| Defer email verification | Immediate product access increases activation | Activation rate |\n\n### Measurement Rules\n\n- Track signup completion rate AND downstream activation rate\n- A test that increases signups but decreases activation is not a win\n- Track by traffic source (paid vs organic may respond differently)\n- Track mobile and desktop separately\n\n---\n\n## Metrics and Benchmarks\n\n### Key Metrics\n\n| Metric | Formula | Benchmark |\n|--------|---------|-----------|\n| Signup page visit-to-completion | Completions / Page views | 30-50% (B2B), 40-60% (B2C) |\n| SSO adoption rate | SSO signups / Total signups | 30-60% when offered |\n| Field-level drop-off | Abandonment per field | Identify highest-drop field |\n| Time to complete | Median seconds from first interaction to submit | < 45s for simple, < 2min for multi-step |\n| Mobile completion rate | Mobile completions / Mobile page views | Should be within 15% of desktop |\n| Email verification rate | Verified / Total signups | > 70% within 48 hours |\n\n---\n\n## Output Artifacts\n\n| Artifact | Format | Description |\n|----------|--------|-------------|\n| Signup Flow Audit | Issue/Impact/Fix/Priority table | Per-step analysis with estimated impact |\n| Recommended Field Set | Justified list | Required vs deferrable fields with rationale |\n| Authentication Strategy | Decision matrix | SSO options, placement, priority |\n| Flow Redesign Spec | Step-by-step outline | Screen-by-screen design with copy |\n| Progressive Profiling Plan | Session-by-session schedule | What to collect, when, and how |\n| A/B Test Plan | Prioritized table | Top 5 tests with hypothesis and expected impact |\n| Mobile Optimization Checklist | Per-element rules | Touch targets, keyboards, auto-fill, sticky CTA |\n\n---\n\n## Tool Reference\n\n### 1. signup_field_auditor.py\n\nAudits a signup form configuration for unnecessary fields, missing enrichment opportunities, and friction points. Evaluates each field against the \"Before First Use\" test and recommends which to keep, defer, or enrich.\n\n```bash\npython scripts/signup_field_auditor.py fields.json --format text\npython scripts/signup_field_auditor.py fields.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `fields.json` | positional | Path to JSON file with form field configuration |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n### 2. signup_flow_scorer.py\n\nScores a complete signup flow against conversion best practices. Evaluates SSO availability, field count, step count, mobile optimization, error handling, and post-submit experience. Outputs a 0-100 score with itemized improvements.\n\n```bash\npython scripts/signup_flow_scorer.py flow.json --format text\npython scripts/signup_flow_scorer.py flow.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `flow.json` | positional | Path to JSON file with signup flow configuration |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n### 3. cc_requirement_analyzer.py\n\nAnalyzes whether to require a credit card for trial signup. Takes business metrics (ACV, trial-to-paid rate, support costs, competitors) and recommends CC-required, CC-free, or \"$0 charge\" approach with projected volume and revenue impact.\n\n```bash\npython scripts/cc_requirement_analyzer.py business.json --format text\npython scripts/cc_requirement_analyzer.py business.json --format json\n```\n\n| Flag | Type | Description |\n|------|------|-------------|\n| `business.json` | positional | Path to JSON file with business metrics |\n| `--format` | optional | Output format: `text` (default) or `json` |\n\n---\n\n## Troubleshooting\n\n| Problem | Likely Cause | Resolution |\n|---------|-------------|------------|\n| Signup completion rate below 30% (B2B) or 40% (B2C) | Too many fields, no SSO option, or form on a separate page from the CTA | Reduce to email-only or SSO; keep form on the same page as the value proposition; each removed field improves conversion ~10% |\n| SSO adoption rate below 30% when offered | SSO buttons placed below the email form, or wrong SSO providers for the audience | Move SSO buttons above the email form with \"or\" divider; match SSO to audience (Google for B2B, Apple for iOS users) |\n| Mobile completion rate >15% below desktop | Form not optimized for touch (small inputs, wrong keyboard types, no auto-fill) | Ensure 44px min touch targets, use type=\"email\"/type=\"tel\", enable browser auto-fill, pin CTA to bottom of viewport |\n| High drop-off on password field | Complex password requirements shown only after submission, or no password visibility toggle | Show requirements as real-time checklist, add show/hide toggle, consider magic link or SSO to eliminate password entirely |\n| Email verification kills activation | Verification required before any product use blocks the critical first-session experience | Defer verification to 24-48 hours; allow product use immediately; gate only email-sending features behind verification |\n| \"Email already registered\" errors are frequent | Users forget they have accounts; error message does not help them recover | Change error to \"This email has an account. [Log in] or [Reset password]\" with direct links |\n| High abandonment on multi-step flows | Steps are not progressive, no progress indicator, or too many fields per step | Show step count and progress bar; limit step 1 to account creation only; add \"Skip for now\" on non-essential steps |\n\n---\n\n## Success Criteria\n\n- Signup page visit-to-completion rate reaches 30-50% (B2B) or 40-60% (B2C) within 60 days of optimization\n- SSO adoption reaches 30-60% of total signups when SSO is properly offered\n- Median time-to-complete stays below 45 seconds for simple flows and below 2 minutes for multi-step\n- Mobile completion rate falls within 15% of desktop completion rate\n- Email verification rate exceeds 70% within 48 hours of signup\n- Field-level drop-off analysis shows no single field causing >10% incremental abandonment\n- Post-signup activation rate (first key action) improves alongside signup rate (not a vanity metric tradeoff)\n\n---\n\n## Scope & Limitations\n\n**In scope:** Authentication strategy (SSO, magic link, email+password), field reduction methodology, multi-step flow architecture, credit card requirement analysis, post-submit experience design, mobile signup optimization, progressive profiling schedules, error and edge case handling, and A/B testing frameworks for registration flows.\n\n**Out of scope:** Post-signup onboarding and activation (use onboarding-cro), non-registration forms like lead capture or contact forms (use form-cro), landing page conversion before the signup form (use page-cro), in-app upgrade and paywall flows (use paywall-upgrade-cro). Scripts operate on local data only -- no integrations with authentication providers (Auth0, Clerk, etc.) or analytics platforms.\n\n**Limitations:** Conversion benchmarks are aggregate SaaS/app industry data and vary by vertical, price point, and audience. SSO adoption rates depend heavily on audience composition (developer audiences adopt GitHub SSO at 40%+, while SMB audiences may prefer email). Credit card requirement analysis is modeled on industry averages -- actual impact requires A/B testing in your specific context. Progressive profiling recommendations assume standard SaaS lifecycle stages.\n\n---\n\n## Integration Points\n\n- **onboarding-cro** -- Signup flow ends at account creation; onboarding-cro picks up from first login through activation\n- **form-cro** -- Field-level optimization principles (validation, keyboard types, error handling) apply to signup forms\n- **page-cro** -- Landing page quality directly impacts signup form reach; optimize the page before optimizing the form\n- **paywall-upgrade-cro** -- Trial signup configuration (CC-required, trial length) affects downstream upgrade flow design\n- **pricing-strategy** -- Pricing model (freemium vs trial) determines signup flow type and field requirements\n- **referral-program** -- Referred user signups should pre-fill referrer context and display incentive\n\n---\n\n## Related Skills\n\n- **onboarding-cro** -- Use for post-signup activation optimization. Signup-flow-cro ends when the user has an account; onboarding-cro starts there.\n- **form-cro** -- Use for non-signup forms (lead capture, contact, demo request). Different optimization framework than registration.\n- **page-cro** -- Use when the landing page leading to signup is the bottleneck, not the signup form itself.\n- **paywall-upgrade-cro** -- Use when the real challenge is converting free users to paid, not getting them to sign up.","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-growth/signup-flow-cro","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-growth/signup-flow-cro/SKILL.md","defaultBranch":"main"},"readme":"# Signup Flow CRO\n\nProduction-grade signup and registration optimization framework covering authentication strategy, field reduction methodology, multi-step flow architecture, SSO implementation, progressive profiling, credit card requirement analysis, post-submit experience design, and mobile-specific registration patterns. For post-signup onboarding, use onboarding-cro. For lead capture forms (not account creation), use form-cro.\n\n---\n\n## Table of Contents\n\n- [Initial Assessment](#initial-assessment)\n- [Authentication Strategy](#authentication-strategy)\n- [Field Reduction Methodology](#field-reduction-methodology)\n- [Multi-Step Flow Architecture](#multi-step-flow-architecture)\n- [Credit Card Requirement Analysis](#credit-card-requirement-analysis)\n- [Post-Submit Experience](#post-submit-experience)\n- [Mobile Signup Optimization](#mobile-signup-optimization)\n- [Signup Flow Patterns by Product Type](#signup-flow-patterns-by-product-type)\n- [Progressive Profiling](#progressive-profiling)\n- [Error and Edge Case Handling](#error-and-edge-case-handling)\n- [A/B Test Framework](#ab-test-framework)\n- [Metrics and Benchmarks](#metrics-and-benchmarks)\n- [Output Artifacts](#output-artifacts)\n- [Related Skills](#related-skills)\n\n---\n\n## Clarify First\n\nBefore optimizing the signup flow, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Flow type** β free trial, freemium, paid, or waitlist (determines friction tolerance and minimum field set)\n- [ ] **B2B or B2C** β B2B tolerates more fields; B2C needs minimal friction (sets SSO priority and field count)\n- [ ] **Current fields + completion rate + drop-off** β baseline and the friction point to cut (each removed field ~+10%)\n- [ ] **Data truly needed before first product use** β separates must-have fields from those to defer or enrich (the \"Before First Use\" test)\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the audit.\n\n## Initial Assessment\n\n### Required Context\n\n| Question | Why It Matters |\n|----------|---------------|\n| Flow type? (free trial, freemium, paid, waitlist) | Determines friction tolerance |\n| B2B or B2C? | B2B tolerates more fields, B2C needs minimal friction |\n| How many steps/screens currently? | Baseline for optimization |\n| What fields are required? | Identifies reduction opportunities |\n| Current completion rate? | Benchmark for improvement |\n| Where do users drop off? (field-level data) | Pinpoints specific friction |\n| What data is needed before first product use? | Separates must-have from nice-to-have |\n| What compliance requirements exist? | Constrains what can be deferred |\n\n---\n\n## Authentication Strategy\n\n### Authentication Methods Ranked by Friction\n\n| Method | Friction Level | Best For | Conversion Impact |\n|--------|---------------|----------|------------------|\n| Google SSO (one-click) | Very low | B2B SaaS, productivity tools | +15-30% vs email+password |\n| Apple Sign In | Very low | iOS/Mac-heavy audience | +10-20% on Apple devices |\n| Microsoft SSO | Low | Enterprise B2B | +10-15% for enterprise |\n| GitHub SSO | Low | Developer tools | +15-25% for dev audience |\n| Magic link (email) | Low | Security-conscious, B2B | +5-10% vs password |\n| Email + password | Medium | Universal fallback | Baseline |\n| Phone + OTP | Medium | Mobile-first, B2C | Varies by market |\n| Email + password + verification | High | When verification is required | -10-20% vs no verification |\n\n### SSO Strategy Decision\n\n| Your Audience | Primary SSO | Secondary SSO | Keep Email+Password? |\n|--------------|-------------|---------------|---------------------|\n| B2B SaaS (general) | Google Workspace | Microsoft | Yes |\n| Developer tools | GitHub | Google | Yes |\n| Enterprise | Microsoft/Okta | Google | Yes (for personal evals) |\n| B2C consumer | Google | Apple | Yes |\n| Mobile-first | Apple / Google | Phone OTP | Optional |\n| Privacy-focused | Magic link | Email+pass","createdAt":"2026-09-25T13:52:02.912Z","updatedAt":"2026-09-25T13:52:02.912Z"},{"id":"cmuh0s8s003saqu0635sgttiz","slug":"borghei-claude-skills-capacity-planner","name":"capacity-planner","description":"Headcount and delivery-capacity planning β effective capacity from raw headcount, hire/contract/defer scenarios, and capacity-vs-commitment gap reports. Use when planning a quarter, sizing a hiring ask, or testing whether a roadmap fits.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"capacity-planner","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Headcount and delivery-capacity planning β effective capacity from raw headcount, hire/contract/defer scenarios, and capacity-vs-commitment gap reports. Use when planning a quarter, sizing a hiring ask, or testing whether a roadmap fits.","permissions":[],"systemPrompt":"# Capacity Planner\n\nTurns headcount into hours you can actually commit. Most capacity plans fail the\nsame way: they count people instead of delivered hours, ignore ramp, and size\nsupply to fit the roadmap rather than the other way round. This skill computes\neffective capacity independently, matches it against risk-adjusted demand, and\npublishes the cut line.\n\n## When to use this skill\n\n- **Quarterly planning** β deciding what the team can commit to for the next 90 days\n- **Testing a roadmap** β a stakeholder has a list and wants to know if it fits\n- **Building a hiring ask** β quantifying a structural gap in hours and dollars\n- **Hire vs contract vs defer** β choosing how to close a capacity shortfall\n- **Mid-quarter replan** β the burn rate diverged and commitments need renegotiating\n- **Onboarding impact** β modelling what three new hires actually deliver this quarter\n\n## Inputs the skill expects\n\n- Team roster: name, discipline, seniority, FTE, tenure in months\n- Known absence: booked PTO days, on-call rotation weeks per person\n- Overhead estimates: meeting load and non-delivery overhead as a percentage\n- Working days and hours per day for the period\n- Candidate commitments with discipline, hour estimate, confidence band, and priority\n- For scenario work: demand curve per quarter, salary/contractor rates, start dates\n\n## Clarify First\n\nBefore generating, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Is this a supply question or a demand question?** β sizing a hiring ask and testing a roadmap use different scripts and produce different artifacts\n- [ ] **Who counts as delivery capacity?** β including managers, tech leads, or unfilled reqs at full FTE changes the answer by 10-40%\n- [ ] **Are the estimates already risk-adjusted?** β applying the confidence inflation twice overstates demand by 40%+; applying it zero times understates it by the same\n- [ ] **Is the buffer set from history or from intent?** β the unplanned-work reserve is the single largest lever on the cut line\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the artifact.\n\n## Workflows\n\n### Workflow 1 β Model effective capacity\n\nEstablishes what the team can actually deliver, computed before anyone looks at\nthe roadmap. Run this first, always.\n\n1. Build the roster: one entry per person, with real FTE and tenure in months. Use a negative `tenure_months` for someone who has not started yet.\n2. Pull **booked** PTO, not average PTO. Q3 and Q4 are not average quarters.\n3. Set `meeting_load_pct` from a calendar audit, not from memory β the gap is usually 5-10 points.\n4. Run the model and check the effective-hours ratio against the sanity band in `references/capacity-benchmarks.md`: below 45% is structurally broken, above 80% is fiction.\n5. Record the per-discipline effective hours β these are the inputs to Workflow 2.\n\n```bash\npython3 business-operations/capacity-planner/scripts/capacity_model.py \\\n --input business-operations/capacity-planner/assets/sample_team.json \\\n --format text\n```\n\n### Workflow 2 β Find the cut line\n\nMatches risk-adjusted demand against capacity in priority order and reports what\ndoes not fit.\n\n1. List every candidate commitment with discipline, raw estimate, confidence band, and priority. Mark anything already promised externally with `\"committed\": true`.\n2. Set the buffer from the trailing three quarters of actual unplanned hours. Default 20%; use 30% if the team owns customer-facing incidents.\n3. Run the gap analysis and read the cut line, not the totals.\n4. Escalate any `committed: true` item above the cut line **this week** β a promise you already know you will miss is a conversation, not a risk.\n5. Publish the below-the-line list alongside the plan. That list is the deliverable.\n\n```bash\npython3 business-operations/capacity-planner/scripts/commitment_gap.py \\\n --input business-operations/capacity-planner/assets/sample_commitments.json \\\n --buffer-pct 20 --format text\n```\n\n### Workflow 3 β Compare hire, contract, and defer\n\nApplies only to work below the cut line. Never use scenario analysis to justify\na plan that does not fit.\n\n1. Build the demand curve per quarter for the horizon β at least four quarters, eight if the gap looks structural.\n2. Define one scenario per realistic option, including a defer scenario as the zero-cost baseline.\n3. Run the comparison and read four axes, not just cost: time to relief, cost per delivered hour, reversibility, and knowledge retention.\n4. Sense-check the winner against the decision rule in `references/planning-methods.md`. A four-quarter horizon is systematically biased toward contracting because the hire/contract crossover falls at month 9-14.\n5. Write the recommendation with its lead time attached. \"Hire two engineers\" relieves the quarter after next, not this one.\n\n```bash\npython3 business-operations/capacity-planner/scripts/scenario_compare.py \\\n --input business-operations/capacity-planner/assets/sample_scenarios.json \\\n --format json\n```\n\n## Decision frameworks\n\n### Gross-to-effective conversion [PROVEN]\n\nPlanning figures for one fully-ramped IC over a 63-day quarter:\n\n| Layer | Hours | Running total |\n|-------|-------|---------------|\n| Gross (63 d x 8 h) | 504 | 504 |\n| Booked PTO (5 days) | -40 | 464 |\n| On-call (2 weeks @ 40% loss) | -32 | 432 |\n| Meetings + overhead (20%) | -86 | 346 |\n| Unplanned-work buffer (20%) | -69 | **277 committable** |\n\n**Use 270-300 committable hours per fully-ramped IC per quarter.** A tech lead\ndelivers 120-160; an engineering manager delivers 0. A mid-level hire starting on\nday one of the quarter delivers 90-110.\n\n### Which lever closes the gap\n\n| Gap size | Persists beyond 4 quarters? | Lever | Time to relief |\n|----------|----------------------------|-------|----------------|\n| Any | β | **Cut scope** [PROVEN] | Immediate |\n| Under 10% | No | **Reduce overhead** [PROVEN] | 2-4 weeks |\n| 10-30% | No | **Defer**, with a named later slot | Immediate |\n| 10-40% | No, work is separable | **Contract** [RECOMMENDED] | 1-3 weeks |\n| Any | Yes | **Hire** [PROVEN for structural gaps] | 5-8 months |\n| Large | Yes, needed within 2 quarters | **Hire + contract bridge** [RECOMMENDED] | 1-3 weeks, handover at Q+2 |\n\nConsider them in this order. Reducing overhead is the highest-ROI lever and is\nalmost always skipped because it is nobody's job β recovering 8% of effective\nhours on a ten-person team is worth most of an FTE and costs nothing.\n\nThe bridge pattern's failure mode is that the handover never happens and the\ncontractor becomes permanent at contractor rates. Put the handover date and the\nknowledge-transfer artifact in the contract itself.\n\n### Estimation inflation by confidence [RECOMMENDED]\n\n| Confidence | Definition | Multiplier |\n|-----------|------------|-----------|\n| High | Team has shipped something near-identical; design complete | 1.15x |\n| Medium | Shape understood; unknowns are known | 1.40x |\n| Low | New domain, new dependency, or design not started | 1.90x |\n\nRecalibrate against your own `actual / original estimate` history after two\nquarters. Most teams land between 1.3 and 1.6 for \"medium\". Never make an\nexternal commitment at \"low\" confidence β either de-risk it to medium first, or\ncommit the date at the inflated number.\n\n### Utilisation bands [PROVEN]\n\n| Planned utilisation | Behaviour |\n|--------------------|-----------|\n| Below 60% | Under-committed; the space fills with low-value work |\n| 70-80% | **Target.** Absorbs incidents without slipping commitments |\n| 80-90% | Every surprise costs a commitment |\n| Above 90% | Queueing effects dominate; cycle time rises non-linearly |\n\nThis is queueing theory, not motivation. Planning to 95% guarantees late\ndelivery even when every estimate is correct.\n\n## Anti-Patterns\n\n### Headcount as capacity\n**Mistake:** Multiplying FTE count by working hours and calling it capacity β 8 engineers x 504 hours = 4,032 hours available.\n**Why it happens:** It is the only number that is easy to get, and it is the number finance and leadership already track. Effective hours require measurement nobody has set up.\n**Instead:** Run the gross-to-effective waterfall every time. The real figure is 50-70% of gross, and the gap is where every over-commitment lives. If you have no measured overhead data, use 60% and start measuring this quarter.\n\n### Hiring to fix this quarter\n**Mistake:** Responding to a capacity gap by opening requisitions, then planning as if the new people contribute in the current period.\n**Why it happens:** Hiring is the lever with the clearest approval path β a headcount ask is a familiar conversation in a way that \"we are cutting three roadmap items\" is not.\n**Instead:** Hiring relieves the quarter after next at the earliest: 8-14 weeks to fill plus 3-6 months to ramp. Close the current gap by cutting scope or contracting, and trigger hiring on a three-quarter trend above 85% load rather than on one bad quarter. Onboarding into an overloaded team also ramps 20% slower, because nobody has time to onboard anyone.\n\n### The plan that fits perfectly\n**Mistake:** Presenting a capacity plan where demand lands within a few percent of supply, with nothing below the cut line.\n**Why it happens:** Estimates get quietly adjusted downward during planning until the roadmap fits the team, or the demand list is truncated before the meeting so it never appears.\n**Instead:** Treat a perfect fit as evidence of a process failure and go find which number moved. Every honest plan has a visible cut line, and the below-the-line list is the most useful artifact the exercise produces β it is what lets a stakeholder trade priorities rather than discover in week 10 that their item was never going to happen.\n\n### Buffer as optimism dial\n**Mistake:** Setting the unplanned-work reserve to whatever makes the plan work β dropping from 20% to 10% when the roadmap does not fit.\n**Why it happens:** The buffer looks like slack, and slack looks like something to be negotiated away. It has no advocate in the room.\n**Instead:** Set the buffer from the trailing three quarters of actual unplanned hours; it is a measurement, not a cushion. If unplanned work exceeded the buffer for two consecutive weeks last quarter, the correct move is to raise it. Cutting the buffer does not create capacity β it just relocates the shortfall to week 10, where it costs more.\n\n## Files\n\n| File | Purpose |\n|------|---------|\n| `scripts/capacity_model.py` | Converts roster + overhead + ramp into effective hours per person and per discipline |\n| `scripts/commitment_gap.py` | Inflates estimates by confidence, fills capacity in priority order, reports the cut line |\n| `scripts/scenario_compare.py` | Projects hire/contract/defer scenarios over a horizon with cost per delivered hour |\n| `references/capacity-benchmarks.md` | Effective-hours ratios by role, ramp curves, on-call and meeting load, utilisation bands, hire-vs-contract economics |\n| `references/planning-methods.md` | Planning sequence, demand forecasting, gap-closing levers, governance cadence, stakeholder pushback responses |\n| `assets/capacity-plan-template.md` | Quarterly capacity plan with cut line, gap options, risks, and weekly tracking |\n| `assets/sample_team.json` | Seven-person roster covering ramping hires, part-time, and multiple disciplines |\n| `assets/sample_commitments.json` | Nine commitments against the capacity produced by `capacity_model.py` on the sample roster |\n| `assets/sample_scenarios.json` | Four-quarter demand curve with hire, contract, and defer scenarios |","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-operations/capacity-planner","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-operations/capacity-planner/SKILL.md","defaultBranch":"main"},"readme":"# Capacity Planner\n\nTurns headcount into hours you can actually commit. Most capacity plans fail the\nsame way: they count people instead of delivered hours, ignore ramp, and size\nsupply to fit the roadmap rather than the other way round. This skill computes\neffective capacity independently, matches it against risk-adjusted demand, and\npublishes the cut line.\n\n## When to use this skill\n\n- **Quarterly planning** β deciding what the team can commit to for the next 90 days\n- **Testing a roadmap** β a stakeholder has a list and wants to know if it fits\n- **Building a hiring ask** β quantifying a structural gap in hours and dollars\n- **Hire vs contract vs defer** β choosing how to close a capacity shortfall\n- **Mid-quarter replan** β the burn rate diverged and commitments need renegotiating\n- **Onboarding impact** β modelling what three new hires actually deliver this quarter\n\n## Inputs the skill expects\n\n- Team roster: name, discipline, seniority, FTE, tenure in months\n- Known absence: booked PTO days, on-call rotation weeks per person\n- Overhead estimates: meeting load and non-delivery overhead as a percentage\n- Working days and hours per day for the period\n- Candidate commitments with discipline, hour estimate, confidence band, and priority\n- For scenario work: demand curve per quarter, salary/contractor rates, start dates\n\n## Clarify First\n\nBefore generating, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Is this a supply question or a demand question?** β sizing a hiring ask and testing a roadmap use different scripts and produce different artifacts\n- [ ] **Who counts as delivery capacity?** β including managers, tech leads, or unfilled reqs at full FTE changes the answer by 10-40%\n- [ ] **Are the estimates already risk-adjusted?** β applying the confidence inflation twice overstates demand by 40%+; applying it zero times understates it by the same\n- [ ] **Is the buffer set from history or from intent?** β the unplanned-work reserve is the single largest lever on the cut line\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the artifact.\n\n## Workflows\n\n### Workflow 1 β Model effective capacity\n\nEstablishes what the team can actually deliver, computed before anyone looks at\nthe roadmap. Run this first, always.\n\n1. Build the roster: one entry per person, with real FTE and tenure in months. Use a negative `tenure_months` for someone who has not started yet.\n2. Pull **booked** PTO, not average PTO. Q3 and Q4 are not average quarters.\n3. Set `meeting_load_pct` from a calendar audit, not from memory β the gap is usually 5-10 points.\n4. Run the model and check the effective-hours ratio against the sanity band in `references/capacity-benchmarks.md`: below 45% is structurally broken, above 80% is fiction.\n5. Record the per-discipline effective hours β these are the inputs to Workflow 2.\n\n```bash\npython3 business-operations/capacity-planner/scripts/capacity_model.py \\\n --input business-operations/capacity-planner/assets/sample_team.json \\\n --format text\n```\n\n### Workflow 2 β Find the cut line\n\nMatches risk-adjusted demand against capacity in priority order and reports what\ndoes not fit.\n\n1. List every candidate commitment with discipline, raw estimate, confidence band, and priority. Mark anything already promised externally with `\"committed\": true`.\n2. Set the buffer from the trailing three quarters of actual unplanned hours. Default 20%; use 30% if the team owns customer-facing incidents.\n3. Run the gap analysis and read the cut line, not the totals.\n4. Escalate any `committed: true` item above the cut line **this week** β a promise you already know you will miss is a conversation, not a risk.\n5. Publish the below-the-line list alongside the plan. That list is the deliverable.\n\n```bash\npython3 business-operations/capacity-planner/scripts/commitment_gap.py \\\n --input business-operations/capacity-planner/assets/sa","createdAt":"2026-09-25T13:52:02.928Z","updatedAt":"2026-09-25T13:52:02.928Z"},{"id":"cmuh0s8sa03sjqu06be4brt6l","slug":"borghei-claude-skills-internal-comms","name":"internal-comms","description":"Plan, sequence, and pressure-test internal announcements before they send. Use when announcing a reorg, policy, or product change, drafting an all-hands or exec update, or deciding who hears what and in which order.","authorId":"gh:borghei","authorName":"borghei","version":"0.1.0","category":"Prompt","securityLevel":"Community","downloadsCount":0,"githubStars":825,"pricePerCall":0,"manifest":{"name":"internal-comms","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Plan, sequence, and pressure-test internal announcements before they send. Use when announcing a reorg, policy, or product change, drafting an all-hands or exec update, or deciding who hears what and in which order.","permissions":[],"systemPrompt":"# Internal Communications\n\nInternal communication fails in predictable ways: the wrong people hear it first, the message\nexplains the decision but not the consequence, and nobody tests the draft before it reaches\n2,000 inboxes. This skill treats an announcement as an artifact with a blast radius, a\nsequence, and a pass/fail quality bar β not as a writing exercise.\n\nThe three levers are **who hears it in what order**, **what the message must contain**, and\n**which channel carries it**. Get those right and tone matters far less than people assume.\n\n## When to use this skill\n\n- Announcing a **reorg, layoff, or leadership change** where sequencing errors are unrecoverable\n- Rolling out a **policy change** (RTO, expenses, security, performance process) that people must act on\n- Communicating a **product or system migration** with a deadline and a required user action\n- Structuring a recurring **all-hands or weekly exec update** that currently reads as a status dump\n- **Pressure-testing a draft** before send: reading level, jargon density, missing elements\n- Deciding **channel and cadence** for a multi-week change programme rather than a one-shot email\n\n## Inputs the skill expects\n\n- The **change itself**: what is changing, effective date, whether it is reversible\n- **Audience list** with impact level (high / medium / low) and rough headcount per group\n- **Draft text**, if one exists (plain markdown or text is fine)\n- **Constraints**: embargo, legal review, regulatory disclosure, market-sensitivity\n- **Available channels** and which ones your org actually reads\n- **Who can answer questions** after send, and where\n\n## Clarify First\n\nBefore generating, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Blast radius β who is materially affected vs merely informed** β this decides whether you need a cascade (manager-first) or a single broadcast, and cascades cost 3-5 days\n- [ ] **Reversibility of the decision** β reversible changes can be announced as proposals with a feedback window; irreversible ones must never be, because inviting input you will ignore is the fastest way to lose trust\n- [ ] **Effective date and the required user action** β sets every T-offset in the plan and determines whether the message is informational or instructional\n- [ ] **Whether anything is legally or market-sensitive** β embargo constraints override the ideal sequence and force simultaneous rather than cascaded delivery\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the artifact.\n\n## Workflows\n\n### Workflow 1 β Audit a draft before it sends\n\nRun this on every announcement that reaches more than ~50 people. It takes 30 seconds and\ncatches the failure modes that generate the most follow-up questions.\n\n1. Save the draft as JSON with `title`, `body`, `audience`, and `channel`.\n2. Run the auditor. It scores five required elements (what changed, why, who is affected,\n what to do, where to ask), reading grade, jargon density, and hedging.\n3. Fix every `FAIL` element. Treat `WARN` on reading grade as advisory unless the audience\n includes non-native speakers or frontline staff, in which case treat it as `FAIL`.\n4. Re-run until the score clears 75.\n\n```bash\npython3 business-operations/internal-comms/scripts/announcement_auditor.py \\\n --input business-operations/internal-comms/assets/sample_announcement.json \\\n --min-score 75 --format text\n```\n\n### Workflow 2 β Sequence a change communication\n\n1. Describe the change and list audiences with impact and headcount.\n2. Run the sequencer. It computes blast radius, orders audiences by a\n *impact-then-influence* rule, and assigns T-offsets in days relative to broadcast.\n3. Review the manager-enablement step β if the plan says you need one and you skip it,\n managers learn about the change from their own reports, which is the single most\n common reorg comms failure.\n4. Export the plan and assign an owner per step.\n\n```bash\npython3 business-operations/internal-comms/scripts/comms_sequencer.py \\\n --input business-operations/internal-comms/assets/sample_change.json \\\n --format text\n```\n\n### Workflow 3 β Pick the channel\n\n1. Characterise the message on six dimensions: urgency, complexity, audience size,\n sensitivity, whether it needs two-way discussion, and whether it needs a durable record.\n2. Run the scorer to rank channels and see which are actively disqualified.\n3. Use the top-ranked channel as the primary, and the highest-ranked *durable* channel\n as the system of record. Never let a chat message be the record.\n\n```bash\npython3 business-operations/internal-comms/scripts/channel_fit_scorer.py \\\n --input business-operations/internal-comms/assets/sample_message_profile.json \\\n --top 4 --format json\n```\n\n## Decision frameworks\n\n### Blast radius β sequence pattern [PROVEN]\n\nBlast radius is the count of people whose *work or employment changes*, not the count who\nreceive the email.\n\n| Radius | Pattern | Lead time before broadcast | Manager enablement |\n|--------|---------|----------------------------|--------------------|\n| 1-10 | Direct 1:1 conversations, then quiet team note | Same day | Not needed |\n| 11-50 | Manager brief β team meetings β written follow-up | 1-2 days | Required, 60-min session |\n| 51-250 | Exec brief β manager brief + FAQ β all-hands β written | 3-5 days | Required, with talk track + FAQ |\n| 250+ | Add a pre-brief for informal influencers and a 2-week reinforcement cadence | 5-10 days | Required, plus a manager Q&A channel |\n\nEscape hatch: legal embargo or market sensitivity collapses this to a simultaneous broadcast.\nWhen that happens, say so in the message β \"we could not brief managers first because of\ndisclosure rules\" β rather than letting people infer carelessness.\n\n### The five required elements [PROVEN]\n\nEvery announcement of consequence answers these, in this order. A message missing any one of\nthem generates a predictable class of follow-up question.\n\n| Element | Missing it produces | Minimum bar |\n|---------|--------------------|-------------|\n| **What changed** | \"Wait, is this happening now or later?\" | One sentence, in the first paragraph, with the effective date |\n| **Why** | Rumour and worst-case theory | The actual reason, including the constraint that forced it |\n| **Who is affected** | Every reader assumes it is them | Named groups, plus an explicit \"if you are not in these groups, nothing changes for you\" |\n| **What to do** | Nothing happens | An action with a deadline, or the words \"no action needed\" |\n| **Where to ask** | Questions go to the wrong people | A named human or channel, plus when they will respond |\n\n### Message-type β structure [RECOMMENDED]\n\n| Type | Lead with | Length | Feedback window |\n|------|-----------|--------|-----------------|\n| Irreversible decision (reorg, layoff, shutdown) | The decision | 300-500 words | None β do not solicit input |\n| Reversible policy | The problem being solved | 400-700 words | 5-10 business days |\n| Migration / deadline | The action and the date | 200-350 words | Questions only |\n| Celebratory / milestone | The outcome and who did it | 150-250 words | None |\n| Bad news (incident, miss) | What happened, in plain words | 250-400 words | Post-mortem link |\n\n### Cadence for a multi-week change [RECOMMENDED]\n\nAnnounce once and people forget; announce weekly and they tune out. The pattern that holds:\n**T-0 announcement, T+3 days FAQ update, T+1 week manager check-in, T+2 weeks progress note,\nT+4 weeks close-out.** Five touches, decreasing in length. See\n`references/change-comms-cadence.md` for the full grid including reinforcement channels.\n\n## Anti-Patterns\n\n### The Broadcast Ambush\n**Mistake:** Sending a reorg or policy announcement to all-staff without briefing managers first.\n**Why it happens:** Leadership fears leaks, and a simultaneous send feels \"fair\" and egalitarian.\n**Instead:** Brief managers 24-48 hours ahead with a talk track and an FAQ, and tell them\nexplicitly what they may and may not repeat. A manager who cannot answer their team's first\nquestion loses standing that takes months to rebuild. If leak risk is genuinely severe,\ncompress the window to 2 hours rather than eliminating it.\n\n### Burying the Decision Under the Reasoning\n**Mistake:** Opening with three paragraphs of market context before stating what is changing.\n**Why it happens:** The author wants the reader to reach the same conclusion they did, so they\nreconstruct their own reasoning path.\n**Instead:** State the decision in sentence one, then the reasoning. Readers who disagree will\nread the reasoning more carefully, not less. Context-first structure reads as though you are\nbuilding a case, which signals defensiveness.\n\n### The Fake Consultation\n**Mistake:** Announcing a settled decision with \"we'd love your feedback\" attached.\n**Why it happens:** It softens the delivery and feels more collaborative than a flat directive.\n**Instead:** If the decision is settled, say so: \"This is decided. Here is what we considered.\"\nIf input can genuinely change the outcome, say what specifically is still open and by when.\nSolicited-then-ignored feedback is measurably worse for trust than no consultation at all.\n\n### Jargon as Cushioning\n**Mistake:** \"We are realigning our operating model to better leverage synergies across pods.\"\n**Why it happens:** Abstraction makes uncomfortable news feel less blunt to the person writing it.\n**Instead:** Write the sentence a person would say out loud. The auditor flags jargon density\nabove 2% of words; anything above that on a high-impact message means the draft is hiding\nsomething, and readers will assume the worst thing it could be hiding.\n\n### No Named Owner for Questions\n**Mistake:** Ending with \"reach out with any questions.\"\n**Why it happens:** Nobody wants to volunteer their calendar.\n**Instead:** Name a person or a specific channel and a response commitment (\"#change-rto,\nanswered within one business day\"). Unrouted questions become hallway conversations,\nand hallway conversations become the version of the message people remember.\n\n## Files\n\n| File | Purpose |\n|------|---------|\n| `scripts/announcement_auditor.py` | Scores a draft on required elements, reading grade, jargon, hedging, and structure |\n| `scripts/comms_sequencer.py` | Builds an ordered, T-offset communication plan from a change description and audience list |\n| `scripts/channel_fit_scorer.py` | Ranks communication channels against a six-dimension message profile |\n| `references/announcement-archetypes.md` | Eight announcement archetypes with structure, length, and worked openings |\n| `references/change-comms-cadence.md` | Timing grids, reinforcement schedules, and manager-enablement content |\n| `assets/announcement-template.md` | Fill-in template enforcing the five required elements |\n| `assets/comms-plan-template.md` | Sequencing plan table with owner, channel, and T-offset columns |\n| `assets/sample_announcement.json` | Runnable input for `announcement_auditor.py` |\n| `assets/sample_change.json` | Runnable input for `comms_sequencer.py` |\n| `assets/sample_message_profile.json` | Runnable input for `channel_fit_scorer.py` |","schemaVersion":1},"repoUrl":"https://github.com/borghei/Claude-Skills/tree/main/business-operations/internal-comms","tags":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"Claude-Skills","audit":{"files":[],"binaries":[],"findings":[],"packages":0,"auditedAt":"2026-09-25T13:52:01.544Z","lockfiles":[]},"forks":144,"owner":"borghei","stars":825,"topics":["agentic-coding","agile","ai-agents","ai-skills","business-operations","claude-code","claude-skills","compliance-automation","cursor","developer-tools","gemini-cli","github-copilot","jira","marketing","mcp-server","notion","product-management","project-management","research-ops","technical-writing"],"license":"MIT + Commons Clause","fullName":"borghei/Claude-Skills","homepage":"https://borghei.github.io/Claude-Skills","language":"HTML","pushedAt":"2026-09-21T22:28:35Z","avatarUrl":"https://avatars.githubusercontent.com/u/6253296?v=4","crawledAt":"2026-09-25T13:51:50.898Z","openIssues":0,"manifestFile":"SKILL.md","manifestPath":"business-operations/internal-comms/SKILL.md","defaultBranch":"main"},"readme":"# Internal Communications\n\nInternal communication fails in predictable ways: the wrong people hear it first, the message\nexplains the decision but not the consequence, and nobody tests the draft before it reaches\n2,000 inboxes. This skill treats an announcement as an artifact with a blast radius, a\nsequence, and a pass/fail quality bar β not as a writing exercise.\n\nThe three levers are **who hears it in what order**, **what the message must contain**, and\n**which channel carries it**. Get those right and tone matters far less than people assume.\n\n## When to use this skill\n\n- Announcing a **reorg, layoff, or leadership change** where sequencing errors are unrecoverable\n- Rolling out a **policy change** (RTO, expenses, security, performance process) that people must act on\n- Communicating a **product or system migration** with a deadline and a required user action\n- Structuring a recurring **all-hands or weekly exec update** that currently reads as a status dump\n- **Pressure-testing a draft** before send: reading level, jargon density, missing elements\n- Deciding **channel and cadence** for a multi-week change programme rather than a one-shot email\n\n## Inputs the skill expects\n\n- The **change itself**: what is changing, effective date, whether it is reversible\n- **Audience list** with impact level (high / medium / low) and rough headcount per group\n- **Draft text**, if one exists (plain markdown or text is fine)\n- **Constraints**: embargo, legal review, regulatory disclosure, market-sensitivity\n- **Available channels** and which ones your org actually reads\n- **Who can answer questions** after send, and where\n\n## Clarify First\n\nBefore generating, confirm these inputs. If any is unknown or vague, ASK β do not assume:\n\n- [ ] **Blast radius β who is materially affected vs merely informed** β this decides whether you need a cascade (manager-first) or a single broadcast, and cascades cost 3-5 days\n- [ ] **Reversibility of the decision** β reversible changes can be announced as proposals with a feedback window; irreversible ones must never be, because inviting input you will ignore is the fastest way to lose trust\n- [ ] **Effective date and the required user action** β sets every T-offset in the plan and determines whether the message is informational or instructional\n- [ ] **Whether anything is legally or market-sensitive** β embargo constraints override the ideal sequence and force simultaneous rather than cascaded delivery\n\nStop rule: ask only the 2-3 that most change the output. If the user says \"just draft it,\" proceed and list your assumptions at the top of the artifact.\n\n## Workflows\n\n### Workflow 1 β Audit a draft before it sends\n\nRun this on every announcement that reaches more than ~50 people. It takes 30 seconds and\ncatches the failure modes that generate the most follow-up questions.\n\n1. Save the draft as JSON with `title`, `body`, `audience`, and `channel`.\n2. Run the auditor. It scores five required elements (what changed, why, who is affected,\n what to do, where to ask), reading grade, jargon density, and hedging.\n3. Fix every `FAIL` element. Treat `WARN` on reading grade as advisory unless the audience\n includes non-native speakers or frontline staff, in which case treat it as `FAIL`.\n4. Re-run until the score clears 75.\n\n```bash\npython3 business-operations/internal-comms/scripts/announcement_auditor.py \\\n --input business-operations/internal-comms/assets/sample_announcement.json \\\n --min-score 75 --format text\n```\n\n### Workflow 2 β Sequence a change communication\n\n1. Describe the change and list audiences with impact and headcount.\n2. Run the sequencer. It computes blast radius, orders audiences by a\n *impact-then-influence* rule, and assigns T-offsets in days relative to broadcast.\n3. Review the manager-enablement step β if the plan says you need one and you skip it,\n managers learn about the change from their own reports, which is the single most\n common reorg comms failure.\n4. Export the plan and assign","createdAt":"2026-09-25T13:52:02.938Z","updatedAt":"2026-09-25T13:52:02.938Z"}],"total":42,"limit":24,"offset":0}