/connect-recommend

name: connect-recommend
description: >-
  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 split
  payments, revenue sharing, multi-party payments, or similar payment
  distribution concepts, provides a company URL or business description for a
  recommendation, builds SaaS that routes money between parties (for example,
  POS, booking, invoicing — not operational SaaS without payment routing), asks
  about onboarding or KYC for merchants, sellers, and vendors, mentions
  connected account Dashboard or responsibility configurations, or asks about
  payment flows, white-label payments, or embedded payments.

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:

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]                  │
  └─────────────