Use this skill when the user asks about Stripe Connect configuration, charge patterns, Dashboard access, or how to get started with Connect, is building a marketplace, platform, multi-vendor store, gig platform, or subscription platform, needs to pay out sellers, vendors, or providers, mentions spli

Connect recommend Recommend the right Stripe Connect integration configuration. The user only needs to provide a company URL or describe their business — the skill figures out the rest. Interaction model User must confirm interactions . Every decision point in this skill MUST be confirmed with the user with clear, numbered options and short descriptions. One question at a time — never overwhelm the user. Auto act on low cost actions . Never ask permission for: Generating the markdown recommendation plan — just generate it Scanning the codebase — just scan it Reading reference files — just read them Never end with passive text . Every stopping point must end with a prompt to the user offering concrete next actions. Terminology rules (user facing output) Before generating any user facing output, read <references/terminology rules.md . Apply those rules to all recommendation text, warnings, explanations, and decision summaries. Key principle: describe configurations using field values (Dashboard + fee ownership + negative balance liability ownership + charge pattern), not shorthand codes. Output Brevity Keep responses concise. The user is making decisions, not reading documentation. Lead with the recommendation, follow with brief rationale Technical details (API paths, capability checks) go in a “Details” section of the final markdown plan — not inline in the main recommendation Warning blocks: 2 3 sentences maximum. State the issue and the fix. No mechanism deep dives unless the user asks. Decision summary: bullet points only, one line per decision Never output more than ~40 lines in a single response during interactive mode Only mention out of scope limitations when they’re directly relevant to what the user asked about . Don’t proactively list constraints or unsupported features (for example, OAuth, international expansion) when the user hasn’t asked about them. “Out of scope” here means outside what this guide supports, not outside what Stripe supports. Research these topics in the Stripe public documentation (docs.stripe.com) rather than saying they’re out of scope. Instructions Step 0 — Show progress Display the progress checklist so the user knows what to expect: Step 1 — Learn about the business (ALWAYS runs first) This is the most important step. Before scanning any code or asking technical questions, understand what the business is . 1a. Check if the user already provided a URL or business description in their message. Look for: A URL (for example, https://... , www. , .com , .io ) A business description (for example, “I’m building a marketplace for…”, “We connect freelancers with…”) A company name that can be searched 1b. If nothing was provided , ask immediately using AskUserQuestion — this is the FIRST question the user sees: Options: “I have a URL” — user provides URL, then research it “Let me describe it” — user provides description, then research it “Just scan my codebase” — skip to Step 2, rely on codebase signals only “Skip — ask me questions instead” — skip to Step 3 with full questionnaire 1c. Research the business — read and follow the company researcher instructions: Read <references/company researcher.md and perform those research steps, using the company URL (if provided) and business description (if provided) as inputs. The research produces a structured analysis with confidence levels (HIGH/MEDIUM/LOW) for each decision dimension. 1d. Parse the agent’s output — it returns a Research Findings table with confidence levels per dimension. Read the decision matrix at <references/decision matrix.md and map the findings to a recommended configuration. Then determine pre fill behavior per dimension: HIGH confidence : Auto fill — don’t ask about this dimension MEDIUM confidence : Suggest the inferred value and ask for quick confirmation LOW confidence : Ask the original open ended question in Step 3 1e. Present what you learned to the user (use second person, conversational confirmation tone): For MEDIUM confidence items, append: “I’m also assuming [X] — sound right?” If the agent flags “not connect” (business doesn’t need Connect), ask the user: Options: “Proceed with Connect anyway” — continue discovery “Explore standard integration instead” — exit this skill, suggest standard Stripe integration Update the checklist: 1f. Validate fee economics (ALWAYS runs, even on auto filled values) If the platform fee (from auto fill or user input) appears low AND any of these conditions apply: Charge pattern is destination or separate (platform pays Stripe fees by default) Charge pattern is direct AND fees collector: "application" (platform still pays Stripe fees) Then: ALWAYS show a margin warning regardless of how the fee was obtained Warn: “Your platform fee might be below Stripe’s processing fees at standard rates. Because the platform pays the Stripe processing fees, your net margin could be thin or negative. Check [stripe.com/pricing](https://stripe.com/pricing) for your region’s rates.” If the charge pattern is destination or direct (with fees collector: "application" ): The platform needs to calculate application fee amount as platform fee + estimated Stripe processing fee (so that the platform preserves its margin) and (if the platform owns pricing) use the [Platform Pricing Tool](https://dashboard.stripe.com/settings/connect/platform pricing) If the charge pattern is separate (separate charges and transfers): application fee amount is NOT compatible. They need to calculate the net transfer amount to preserve margin instead of using application fee amount . Recommend monitoring the [margin report](https://docs.stripe.com/connect/margin reports.md) in the Stripe Dashboard This check MUST run even when the fee was auto filled with HIGH confidence. The user needs to understand the fee economics before proceeding. Step 2 — Auto detect project context Run this AFTER Step 1 (or in parallel if the user said “scan my codebase”). Use codebase signals to supplement or corroborate the company research. Don’t ask before scanning — just scan. 1. Existing Connect config : Check for connect recommend plan.md or any file at the project root that resembles a prior recommendation plan (for example, a file containing Recommended Connect integration plan ). If found, read it and note the prior configuration — use it to pre fill or validate decisions in later steps, and present it to the user before asking questions they’ve already answered. 2. Existing Stripe integration patterns : Use Grep to search for Connect specific patterns already in the codebase: Connected account creation or references ( connected account , account id , stripe account ) Charge patterns in use ( destination , on behalf of , transfer data , separate charges ) Transfer or payout logic ( transfers.create , payouts.create ) Webhook handlers for Connect events ( account.updated , capability , payout ) Existing application fee amount usage If codebase signals contradict the company research, note the discrepancy and ask the user to clarify. Present findings briefly (don’t repeat what Step 1 already covered): If a prior plan was found, ask the user: Options: “Use it as a starting point” — pre fill all decisions from the prior plan, then confirm each with the user in Step 3 “Start fresh” — ignore the prior plan and run full discovery Update the checklist: Step 3 — Ask remaining discovery questions For any dimension not already filled with HIGH confidence from Step 1, ask the corresponding question to the user. Skip dimensions that were auto filled or explicitly confirmed. Read <references/discovery questions.md for complete question scripts, option mappings, and edge case logic for Step 3, Step 3b (hybrid flows), Step 3c (sales led/scope detection), and the fee structure checkpoint. If Step 1 was skipped entirely, ask all six discovery questions one at a time: Q1: Business model Q2: Parties in the platform Q3: Payment flow Q4: Dashboard and onboarding preference Q5: Dispute and refund ownership + risk management + loss liability Q6: Fee structure + application fee amount calculation Critical guardrails (must enforce in all discovery paths): For marketplace or intermediary checkout flows, default to destination charges unless behavior clearly indicates each seller runs their own checkout or payment relationship. If the business mixes its own brand sales with marketplace or intermediary flows, trigger Step 3b hybrid flow handling and map each flow to its own charge pattern and responsibility settings. If the user needs hold and release timing, recommend separate charges and transfers (destination charges can’t hold funds and aren’t appropriate for hold and release behavior). For SaaS with independent sellers that own customer relationships, use full dashboard + direct charges + embedded onboarding. If the user asks “what account type should I use?”, reframe during discovery to Accounts v2 explicit fields ( dashboard , defaults.responsibilities , and merchant or recipient by funds flow), not legacy account types. Read <references/account types.md for the full v2 configuration reference. When describing low margin scenarios, present warnings and risks before mitigation steps. If dashboard: "none" is selected, include a concise full scope warning about custom UI responsibilities. For destination or separate recommendations with losses collector: "application" , explain the causal chain: platform owns negative balance liability and connected account negative balances enable dispute time transfer reversals. Keep risk management and negative balance liability as separate decisions. Trigger Step 3c when enterprise or sales led signals appear ( on behalf of , cross border complexity, non Connect products, or sales gated configs). Fee structure checkpoint before Step 4: 1. Confirm fee type and fee amount 2. Confirm how application fee amount is calculated 3. Confirm whether a margin warning is required 4. Include stripe.com/pricing link in output context Step 4 — Generate recommendation Read the decision matrix at <references/decision matrix.md and apply it to the user’s answers. For charge pattern details, read <references/charge patterns.md . Step 4a — Compatibility validation (MANDATORY before presenting recommendation) Read <references/compatibility matrix.md and cross check the proposed (dashboard, fees collector, losses collector) + chargePattern combination against the compatibility matrix. 1. BLOCKED combination? Do NOT present it. Output a visible BLOCKED warning with ALL of these: The exact blocked config tuple (for example, losses collector: "stripe" + destination charges ) A 2 3 sentence explanation of the MECHANISM of failure (for example, “With destination charges and a dispute, Stripe debits the disputed amount from the platform’s balance. The platform must then manually reverse the transfer to recover funds from the connected account — but reverse transfer defaults to false on both refunds and disputes, so recovery isn’t automatic. With losses collector: 'stripe' , the platform has no mechanism to push negative balance recovery onto the connected account, so it silently absorbs the loss.”) The recommended fix (nearest ALLOWED alternative — usually switching losses collector to "application" or switching to direct charges) Then re run the recommendation with the corrected configuration. 2. CAUTION combination? Present the recommendation but include a visible warning callout explaining the specific tradeoff (for example, “dashboard visibility limitations for direct charges when using dashboard: \"express\" ”). 3. Additional compatibility checks (include concise warnings wh

connect-recommend