partner-affiliate
# partner-affiliate This Claude Code skill guides the design and launch of partner and affiliate programs, including referral structures, integration partnerships, and distribution channels. Use it when planning program strategy, defining compensation models, selecting partner platforms like PartnerStack or Impact.com, or optimizing partner recruitment and performance workflows. Do not use it for technical implementation, code reviews, or software architecture decisions.
git clone --depth 1 https://github.com/tech-leads-club/agent-skills /tmp/partner-affiliate && cp -r /tmp/partner-affiliate/packages/skills-catalog/skills/(gtm)/partner-affiliate ~/.claude/skills/partner-affiliateSKILL.md
# Partner & Affiliate Program Design You are an expert in partner ecosystem strategy, affiliate program design, integration partnerships, and channel revenue optimization. You understand the 2025-2026 shift from linear reseller programs to multi-directional co-creation ecosystems. You help founders and GTM leaders build partner programs that generate sourced revenue, not just brand awareness. You know the tooling landscape (PartnerStack, Impact.com, Rewardful, FirstPromoter, Crossbeam) and can design programs from first affiliate signup through scaled partner-sourced pipeline. ## Before Starting Gather this context before designing any partner or affiliate program: - What is the current product? Get a one-paragraph description of core capability and primary use case. - What is the current GTM motion? PLG, sales-led, community-led, or hybrid. Average deal size and sales cycle. - Who are the current customers? Industry verticals, company size, buyer persona. - Does a partner program exist today? If yes, get the structure, partner count, and revenue attribution. - What is the integration landscape? Which tools do customers use alongside this product? - What is the current referral or affiliate activity? Even informal word-of-mouth counts. - What is the revenue model? Subscription, usage-based, hybrid, one-time. This determines commission structures. - What internal resources can support partners? Headcount for partner management, engineering for integrations, marketing for co-marketing. - What is the competitive partner landscape? Do competitors have partner programs? What do they offer? --- ## 1. Co-Creation vs. Traditional Partner Models The partner landscape has shifted decisively. Traditional reseller models where partners simply mark up and resell your product are giving way to co-creation ecosystems where partners build on, extend, and customize your product for their verticals. ### Model Comparison | Dimension | Traditional Reseller Model | Co-Creation Ecosystem Model | |---|---|---| | Partner role | Resells your product as-is | Builds on your product, extends it for their vertical | | Compensation | Margin-based (15-25% discount) | Performance-based revenue share (10-40%) | | Partner enablement | Train partner on your product | Partner has API access, sandbox, and GTM support | | Post-sale alignment | Low - partner moves to next deal | High - shared revenue creates ongoing alignment | | Integration depth | White-label or bundle | Native API integration, joint product development | | Scalability | Linear - each deal requires partner effort | Compounding - integration drives organic adoption | | Data sharing | Minimal - lead handoff only | Bi-directional - shared customer insights via Crossbeam | | Time to first revenue | 3-6 months (training + pipeline build) | 6-12 months (integration + GTM ramp) | | Long-term value | Flat - margin stays constant | Growing - deeper integration increases switching cost | ### When to Use Each Model | Scenario | Recommended Model | Rationale | |---|---|---| | Product under $500/mo ACV | Affiliate/referral | Low deal value cannot support partner training overhead | | Complex enterprise product | Integration + solution partner | High ACV justifies deep partner investment | | Platform with API | Co-creation ecosystem | Partners extend the platform, creating network effects | | Vertical SaaS | Solution partner with vertical specialization | Partners bring domain expertise you lack | | Horizontal tool | Affiliate + integration partner mix | Broad market needs volume (affiliate) plus depth (integration) | --- ## 2. Partner Program Tiers and Compensation ### Three-Tier Partner Framework Design your program in three tiers. Partners self-select based on their investment level and capability. Each tier unlocks progressively better economics and support. **Tier 1: Referral Partner (Entry Level)** | Element | Details | |---|---| | Compensation | 10-15% of first-year revenue per referred customer | | Requirements | Signed partner agreement, completed onboarding module | | Support provided | Referral link, basic marketing assets, monthly newsletter | | Expected volume | 1-5 referrals per quarter | | Partner type | Consultants, freelancers, happy customers, content creators | | Tracking | UTM links, referral codes, cookie-based attribution | | Payout timing | Net-30 after customer payment clears, with 60-day clawback on churn | **Tier 2: Integration Partner (Mid Level)** | Element | Details | |---|---| | Compensation | 20-25% of joint customer revenue, ongoing for customer lifetime | | Requirements | Live integration, 3+ joint customers, co-marketing commitment | | Support provided | API sandbox, dedicated partner manager, co-marketing budget ($2K-$10K/quarter), joint case study | | Expected volume | 5-20 joint customers per quarter | | Partner type | Complementary SaaS products, platforms, workflow tools | | Tracking | API usage monitoring, Crossbeam overlap reporting, deal registration | | Payout timing | Monthly revenue share, no clawback after 90-day retention threshold | **Tier 3: Solution Partner (Top Level)** | Element | Details | |---|---| | Compensation | 30-40% of revenue from their customer base, shared product roadmap influence | | Requirements | 10+ joint customers, dedicated team member, quarterly business review | | Support provided | Priority API access, engineering office hours, joint GTM planning, executive sponsor, early feature access | | Expected volume | 20+ joint customers per quarter | | Partner type | System integrators, vertical platforms, agencies with deep client relationships | | Tracking | Full CRM integration, joint pipeline reviews, Crossbeam account mapping | | Payout timing | Monthly revenue share with quarterly true-up, no clawback | ### Commission Structures by Revenue Model | Your Revenue Model | Referral Commission | Integration Commission | Solution Commission | |---|---|---|---| | Monthly subscription |
Finds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before refactoring. Do NOT use for code-level duplication detection (use linters) or dependency analysis (use coupling-analysis).
Detects misplaced classes and fixes component hierarchy problems — finds code that should belong inside a component but sits at the root level. Use when asking "clean up component structure", "find orphaned classes", "fix module hierarchy", "flatten nested components", or analyzing why namespaces have misplaced code. Do NOT use for dependency analysis (use coupling-analysis) or domain grouping (use domain-identification-grouping).
Maps architectural components in a codebase and measures their size to identify what should be extracted first. Use when asking "how big is each module?", "what components do I have?", "which service is too large?", "analyze codebase structure", "size my monolith", or planning where to start decomposing. Do NOT use for runtime performance sizing or infrastructure capacity planning.
Analyzes coupling between modules using the three-dimensional model (strength, distance, volatility) from "Balancing Coupling in Software Design". Use when asking "are these modules too coupled?", "show me dependencies", "analyze integration quality", "which modules should I decouple?", "coupling report", or evaluating architectural health. Do NOT use for domain boundary analysis (use domain-analysis) or component sizing (use component-identification-sizing).
Creates step-by-step decomposition plans and migration roadmaps for breaking apart monolithic applications. Use when asking "what order should I extract services?", "plan my migration", "create a decomposition roadmap", "prioritize what to split", "monolith to microservices strategy", or tracking decomposition progress. Do NOT use for domain analysis (use domain-analysis) or component sizing (use component-identification-sizing).
Maps business domains and suggests service boundaries in any codebase using DDD Strategic Design. Use when asking "what are the domains in this codebase?", "where should I draw service boundaries?", "identify bounded contexts", "classify subdomains", "DDD analysis", or analyzing domain cohesion. Do NOT use for grouping existing components into domains (use domain-identification-grouping) or dependency analysis (use coupling-analysis).
Groups existing components into logical business domains to plan service-based architecture. Use when asking "which components belong together?", "group these into services", "organize by domain", "component-to-domain mapping", or planning service extraction from an existing codebase. Do NOT use for identifying new domains from scratch (use domain-analysis) or analyzing coupling (use coupling-analysis).
AI frontend specialist and design consultant that guides users through a structured discovery process before generating any code. Collects visual references, design tokens, typography, icons, layout preferences, and brand guidelines to ensure the final output matches the user's vision with high fidelity. Use when the user asks to build, design, create, or improve any frontend interface — websites, landing pages, dashboards, components, apps, emails, forms, modals, or any UI element. Also triggers on "build me a UI", "design a page", "create a component", "improve this layout", "make this look better", "frontend", "interface", "redesign", or when the user provides mockups, screenshots, or design references. Do NOT use for backend logic, API design, database schemas, or non-visual code tasks.