Connect Recommend

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](https://docs.stripe.com/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:

Here's what we'll do:

  [ ] Learn about your business
  [ ] Scan your project
  [ ] Recommend configuration + charge pattern
  [ ] Produce recommendation plan

Let's get started.

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:

Tell me about your business. Pick whichever is easiest:

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):

Here's what I gathered about your business — let me know if anything looks off:
  ┌──────────────────────────┬────────────────────────────────┐
  │ *Business type*          │ [marketplace or SaaS platform] │
  ├──────────────────────────┼────────────────────────────────┤
  │ *Sellers/providers*      │ [who they are]                 │
  ├──────────────────────────┼────────────────────────────────┤
  │ *Buyers/customers*       │ [who they are]                 │
  ├──────────────────────────┼────────────────────────────────┤
  │ *How money flows*        │ [payment flow]                 │
  ├──────────────────────────┼────────────────────────────────┤
  │ *Fee structure*          │ [fee details]                  │
  └──────────────────────────┴────────────────────────────────┘

Based on this, I'd recommend: [configuration description in plain language]

I'll proceed with this unless you'd like to correct anything.

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:

Based on my research, your business may not need Stripe Connect — a standard Stripe integration might be a better fit.

Options:

• “Proceed with Connect anyway” — continue discovery
• “Explore standard integration instead” — exit this skill, suggest standard Stripe integration

Update the checklist:

  [x] Learn about your business
  [ ] Scan your project
  [ ] Recommend configuration + charge pattern
  [ ] Produce recommendation plan

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 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
• 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 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.