connect-recommend

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Connect Recommend

Connect配置推荐

Recommend the right Stripe Connect integration shape. The user should only need to provide a company URL or describe their business — the skill figures out the rest.

为您推荐合适的Stripe Connect集成方案。用户只需提供公司网址或描述业务情况，本技能即可完成后续分析。

Interaction Model

交互模型

AskUserQuestion is the primary interaction tool. Every decision point in this skill MUST use AskUserQuestion 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 an AskUserQuestion offering concrete next actions.

AskUserQuestion是核心交互工具。本技能中的每一个决策节点都必须使用AskUserQuestion，提供清晰的编号选项和简短说明。每次只提一个问题——切勿使用户感到负担。

自动执行低成本操作。以下操作无需征得用户同意：

生成Markdown格式的推荐方案——直接生成即可
扫描代码库——直接扫描即可
读取参考文件——直接读取即可

切勿以被动文本结束对话。每一个停顿节点都必须以AskUserQuestion结束，提供具体的后续操作选项。

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.

在生成任何面向用户的输出前，请阅读
references/terminology-rules.md
。将这些规则应用于所有推荐文本、警告信息、说明内容和决策总结。

核心原则：使用字段值（仪表盘+费用归属+负余额责任归属+收费模式）描述配置，而非简写代码。

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 surface out-of-scope limitations when they are directly relevant to what the user asked about. Do not proactively list constraints or unsupported features (e.g., OAuth, international expansion) when the user has not asked about them. "Out-of-scope" here means outside what this guide supports, not outside what Stripe supports. Research these topics in Stripe's public documentation (docs.stripe.com) rather than saying they're out-of-scope.

保持回复简洁。用户是在做决策，而非阅读文档。

先给出推荐结论，再附上简短理由
技术细节（API路径、权限检查）放在最终Markdown方案的「详情」部分——不要直接放在主推荐内容中
警告块：最多2-3句话。说明问题和解决方法。除非用户询问，否则无需深入解释机制
决策总结：仅使用项目符号，每项决策一行
交互模式下，单次回复的内容不得超过约40行

仅当用户询问的内容直接相关时，才说明超出范围的限制。不要主动列出约束条件或不支持的功能（如OAuth、国际化扩展），除非用户提及。此处的「超出范围」指本指南不支持的内容，而非Stripe不支持的内容。如需了解这些主题，请查阅Stripe公开文档（docs.stripe.com），而非直接告知用户超出范围。

Instructions

操作步骤

Step 0 — Show progress

步骤0 — 展示进度

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)

步骤1 — 了解业务（必须首先执行）

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 (e.g.
```
https://...
```
,
```
www.
```
,
```
.com
```
,
```
.io
```
)
A business description (e.g. "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 — invoke the company-researcher agent:

Use the

Task

tool with

subagent_type: "general-purpose"

to invoke the company-researcher agent. In your prompt, include:

The company URL (if provided)
The business description (if provided)
Ask the agent to read
```
agents/company-researcher.md
```
for its instructions

The agent will return 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

skills/connect-recommend/references/decision-matrix.md

and map the findings to a recommended configuration. Then determine pre-fill behavior per dimension:

HIGH confidence: Auto-fill — do not 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), use AskUserQuestion:

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 may be below Stripe's processing fees at standard rates. Since the platform pays Stripe's processing fees with destination charges, your net margin could be very thin or negative. Check stripe.com/pricing for your region's rates."
Strongly recommend: calculating
```
application_fee_amount
```
as platform fee + estimated Stripe processing fee (so the platform's margin is preserved) and (if platform owns pricing) using the Platform Pricing Tool
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.

这是最重要的步骤。在扫描代码或询问技术问题之前，务必先了解业务的核心性质。

1a. 检查用户是否已在消息中提供网址或业务描述，查找以下内容：

网址（如
```
https://...
```
、
```
www.
```
、
```
.com
```
、
```
.io
```
）
业务描述（如「我正在构建一个...的市场平台」、「我们连接自由职业者与...」）
可用于搜索的公司名称

1b. 如果未提供任何信息，立即使用AskUserQuestion提问——这是用户看到的第一个问题：

请描述您的业务。选择最便捷的方式：

选项：

"我有网址" — 用户提供网址后，进行调研
"我来描述业务" — 用户提供描述后，进行调研
"直接扫描我的代码库" — 跳过步骤2，仅依赖代码库信号
"跳过——直接问我问题" — 跳过步骤3，进入完整问卷环节

1c. 调研业务 — 调用company-researcher agent：

使用

Task

工具，设置

subagent_type: "general-purpose"

来调用company-researcher agent。在提示语中包含：

公司网址（若提供）
业务描述（若提供）
要求该agent阅读
```
agents/company-researcher.md
```
中的操作说明

该agent将返回结构化分析结果，包含每个决策维度的置信度（高/中/低）。

1d. 解析agent的输出 — 它会返回一个包含各维度置信度的调研结果表格。阅读

skills/connect-recommend/references/decision-matrix.md

中的决策矩阵，将调研结果映射为推荐配置。然后确定各维度的预填充规则：

高置信度：自动填充——无需询问该维度
中置信度：建议推断值，并请求快速确认
低置信度：询问步骤3中的原始开放式问题

1e. 向用户展示调研结果（使用第二人称、对话式确认语气）：

以下是我了解到的您的业务信息——如有错误请告知：
  ┌──────────────────────────┬────────────────────────────────┐
  │ *业务类型*               │ [市场平台或SaaS平台]            │
  ├──────────────────────────┼────────────────────────────────┤
  │ *卖家/服务提供者*        │ [群体类型]                      │
  ├──────────────────────────┼────────────────────────────────┤
  │ *买家/客户*              │ [群体类型]                      │
  ├──────────────────────────┼────────────────────────────────┤
  │ *资金流转方式*           │ [支付流程]                      │
  ├──────────────────────────┼────────────────────────────────┤
  │ *费用结构*               │ [费用详情]                      │
  └──────────────────────────┴────────────────────────────────┘

基于以上信息，我推荐：[用通俗语言描述配置]

如无异议，我将按此方案推进。

对于中置信度的项目，补充：「我同时假设[X]——是否正确？」

如果agent标记为「not-connect」（业务无需Connect），使用AskUserQuestion：

根据调研，您的业务可能无需Stripe Connect——标准Stripe集成或许更适合您。

选项：

"仍继续使用Connect" — 继续探索流程
"转而了解标准集成" — 退出本技能，推荐标准Stripe集成

更新进度清单：

  [x] 了解您的业务
  [ ] 扫描您的项目
  [ ] 推荐配置与收费模式
  [ ] 生成推荐方案

1f. 验证费用经济性（必须执行，即使是自动填充的值）

若平台费用（自动填充或用户输入）较低，且满足以下任一条件：

收费模式为
```
destination
```
或
```
separate
```
（默认由平台支付Stripe费用）
收费模式为
```
direct
```
且
```
fees_collector: "application"
```
（仍由平台支付Stripe费用）

则：

无论费用来源如何，必须显示利润警告
警告内容：「您的平台费用可能低于Stripe标准费率下的处理费。由于使用destination charges时平台需支付Stripe处理费，您的净利润可能非常微薄甚至为负。请查看stripe.com/pricing了解您所在地区的费率。」
强烈建议：将
```
application_fee_amount
```
计算为平台费用+预估Stripe处理费（以保障平台利润）；若平台拥有定价权，使用平台定价工具
推荐监控Stripe仪表盘中的利润报告

即使费用是高置信度自动填充的，也必须执行此检查。用户需要在推进前了解费用经济性。

Step 2 — Auto-detect project context

步骤2 — 自动检测项目上下文

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. Do not ask before scanning — just scan.

Existing Connect config: Check for
```
connect-recommend-plan.md
```
or any file at the project root that resembles a prior recommendation plan (e.g., contains
```
## 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 surface it to the user before asking questions they've already answered.
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):

Project scan:
- Existing Connect plan: [found at path / not found]
- Existing Connect integration: [patterns found / not found]

If a prior plan was found, use AskUserQuestion:

I found an existing Connect recommendation plan at [path].

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:

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

在步骤1之后执行（若用户选择「扫描我的代码库」，可并行执行）。使用代码库信号补充或验证业务调研结果。扫描前无需询问——直接扫描即可。

现有Connect配置：检查项目根目录下的
```
connect-recommend-plan.md
```
或任何类似的历史推荐方案文件（如包含
```
## Recommended Connect integration plan
```
的文件）。若找到，读取并记录历史配置——用于后续步骤的预填充或验证，并在询问用户已回答过的问题前告知用户。
现有Stripe集成模式：使用Grep搜索代码库中已有的Connect特定模式：
- 关联账户创建或引用（
```
connected_account
```
  、
```
account_id
```
  、
```
stripe_account
```
  ）
- 当前使用的收费模式（
```
destination
```
  、
```
on_behalf_of
```
  、
```
transfer_data
```
  、
```
separate_charges
```
  ）
- 转账或付款逻辑（
```
transfers.create
```
  、
```
payouts.create
```
  ）
- Connect事件的Webhook处理器（
```
account.updated
```
  、
```
capability
```
  、
```
payout
```
  ）
- 现有
```
application_fee_amount
```
  的使用情况

若代码库信号与业务调研结果矛盾，记录差异并请用户澄清。

简要展示调研结果（不要重复步骤1已涵盖的内容）：

项目扫描结果：
- 现有Connect方案：[路径已找到/未找到]
- 现有Connect集成：[已发现模式/未发现]

若找到历史方案，使用AskUserQuestion：

我在[路径]找到一份现有Connect推荐方案。

选项：

"以此为起点" — 从历史方案预填充所有决策，然后在步骤3中与用户逐一确认
"重新开始" — 忽略历史方案，执行完整探索流程

更新进度清单：

  [x] 了解您的业务
  [x] 扫描您的项目
  [ ] 推荐配置与收费模式
  [ ] 生成推荐方案

Step 3 — Ask remaining discovery questions

步骤3 — 询问剩余探索问题

For any dimension not already filled with HIGH confidence from Step 1, ask the corresponding question using AskUserQuestion. 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/refund ownership + risk management + loss liability
Q6: Fee structure +
```
application_fee_amount
```
calculation

Critical guardrails (must enforce in all discovery paths):

For marketplace/intermediary checkout flows, default to destination charges unless behavior clearly indicates each seller runs their own checkout/payment relationship.
If the business mixes own-brand sales with marketplace/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 cannot hold funds and are not 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
```
/
```
recipient
```
by funds flow), not legacy account types.
When describing low-margin scenarios, present warning/risk before mitigation steps.
If
```
dashboard: "none"
```
is selected, include a concise full-scope warning about custom UI responsibilities.
For destination/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/sales-led signals appear (
```
on_behalf_of
```
, cross-border complexity, non-Connect products, or sales-gated configs).

Fee structure checkpoint before Step 4:

Confirm fee type and fee amount
Confirm how
```
application_fee_amount
```
is calculated
Confirm whether a margin warning is required
Include stripe.com/pricing link in output context

对于步骤1中未以高置信度填充的维度，使用AskUserQuestion询问相应问题。跳过已自动填充或明确确认的维度。

**阅读

references/discovery-questions.md

**获取步骤3、步骤3b（混合流程）、步骤3c（销售主导/范围检测）和费用结构检查点的完整问题脚本、选项映射和边缘情况逻辑。

若完全跳过步骤1，需逐一询问以下6个探索问题：

Q1：业务模式
Q2：平台参与方
Q3：支付流程
Q4：仪表盘与入驻偏好
Q5：纠纷/退款归属+风险管理+损失责任
Q6：费用结构+
```
application_fee_amount
```
计算

关键规则（所有探索路径必须遵守）：

对于市场/中介结账流程，默认使用destination charges，除非明确显示每个卖家独立管理结账/支付关系。
若业务混合自有品牌销售与市场/中介流程，触发步骤3b混合流程处理，为每个流程映射对应的收费模式和责任设置。
若用户需要资金暂存与释放功能，推荐separate charges and transfers（destination charges无法暂存资金，不适合此类场景）。
对于拥有独立卖家且卖家拥有客户关系的SaaS，使用full dashboard + direct charges + embedded onboarding。
若用户询问「我应该使用哪种账户类型？」，在探索过程中重新表述为Accounts v2的明确字段（
```
dashboard
```
、
```
defaults.responsibilities
```
和按资金流转划分的
```
merchant
```
/
```
recipient
```
），而非旧版账户类型。
描述低利润场景时，先展示警告/风险，再给出缓解步骤。
若选择
```
dashboard: "none"
```
，需包含关于自定义UI责任的简洁全面警告。
对于destination/separate推荐且
```
losses_collector: "application"
```
的情况，解释因果链：平台承担负余额责任，关联账户的负余额允许在纠纷时撤销转账。
将风险管理和负余额责任作为独立决策。
当出现企业/销售主导信号（
```
on_behalf_of
```
、跨境复杂性、非Connect产品或销售 gated配置）时，触发步骤3c。

步骤4前的费用结构检查点：

确认费用类型和金额
确认
```
application_fee_amount
```
的计算方式
确认是否需要利润警告
在输出中包含stripe.com/pricing链接

Step 4 — Generate recommendation

步骤4 — 生成推荐方案

Read the decision matrix at

skills/connect-recommend/references/decision-matrix.md

and apply it to the user's answers.

Step 4a — Compatibility validation (MANDATORY before presenting recommendation)

Read

skills/connect-recommend/references/compatibility-matrix.md

and cross-check the proposed

(dashboard, fees_collector, losses_collector)

chargePattern

combination against the compatibility matrix.

BLOCKED combination? Do NOT present it. Output a visible BLOCKED warning with ALL of these:
- The exact blocked config tuple (e.g.,
```
losses_collector: "stripe" + destination charges
```
  )
- A 2-3 sentence explanation of the MECHANISM of failure (e.g., "With destination charges, when a customer disputes a charge, Stripe reverses the transfer from the connected account. If losses_collector is 'stripe', the connected account's balance can go negative — but the platform silently carries this liability despite the config saying Stripe is responsible.")
- 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.
CAUTION combination? Present the recommendation but include a visible warning callout explaining the specific tradeoff (e.g., "dashboard visibility limitations for direct charges when using
```
dashboard: \"express\"
```
").
Additional compatibility checks (include concise warnings when triggered):
- If the user mentioned OAuth for connecting accounts, include a 1-2 sentence warning that accounts can disconnect and recommend embedded onboarding for stronger platform control.
- If
```
dashboard: "none"
```
  , include a concise warning that the platform must own onboarding/remediation, refund/dispute flows, and earnings/payout surfaces; recommend Express dashboard with embedded components as a lower-maintenance alternative.
- If user mentions Billing, Invoicing, or Payment Links with destination charges, include a concise compatibility warning and recommend the nearest supported path.
- If
```
dashboard: "full"
```
  + charge pattern is
```
destination
```
  or
```
separate
```
  , include a concise warning that full dashboard is optimized for direct charges and recommend switching dashboard type or charge pattern.
- If
```
dashboard: "express"
```
  +
```
fees_collector: "stripe"
```
  , treat as BLOCKED and recommend either switching to full dashboard (Stripe-owned pricing) or platform-owned pricing.
Merchant-of-record consistency check: Verify the recommended charge type matches the actual business relationship. Direct charges = connected account provides goods/services directly. Destination/separate charges and transfers = platform owns the customer relationship. Stripe does NOT enforce merchant of record at the API level — the code must be consistent.
Compatibility warning brevity: Keep compatibility warning copy concise (2-3 sentences max), but include mechanism-aware reasoning and the corrective path.

Step 4b — Recommend embedded components

Embedded components are recommended, as they enable platforms to build full-featured dashboards of their own, especially when accounts are configured with

dashboard: "none"

and even if accounts are configured with (

dashboard: "full"

dashboard: "express"

). Select components based on user needs:

Baseline (always include):

```
account_onboarding
```
```
notification_banner
```
(required; keeps connected accounts healthy/enabled as requirements evolve)
```
account_management
```

Common additions:

Transaction history →
```
payments
```
(use
```
payment_details
```
if building a custom payments list)
Disputes → included with
```
payments
```
but can use
```
disputes_list
```
if also building a standalone disputes page
Payout operations/earnings →
```
payouts
```

Reporting/reconciliation →

balance_report

payout_reconciliation_report

Charge-pattern compatibility caveats:

Destination charges (without
```
on_behalf_of
```
): payment/dispute surfaces show reduced detail. The
```
destination_on_behalf_of_charge_management
```
setting does not apply to plain destination charges.
Destination charges with
```
on_behalf_of
```
: payment/dispute surfaces show reduced detail unless
```
destination_on_behalf_of_charge_management
```
is enabled. This setting applies only to destination charges that use the
```
on_behalf_of
```
parameter — not plain destination charges or separate charges.
Separate charges and transfers: payment/dispute surfaces show reduced detail. There is no equivalent management setting for this charge pattern.
Direct: payment/dispute surfaces operate with full fidelity.

When recommending payment or dispute components with destination charges that use

on_behalf_of

, add: "Enable

destination_on_behalf_of_charge_management

only if the platform is using destination charges with

on_behalf_of

and wants their connected accounts to view payment details, manage refunds, or manage disputes, and the integration handles the required transfer reversals when there are disputes. This applies only to destination charges with the

on_behalf_of

parameter, not plain destination charges or separate charges."

Out of scope component families:

Issuing/Treasury/Capital/Tax component sets (route through Step 3c scope handling).

Be prepared to output a list of embedded components in the next step.

Update the checklist:

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

阅读

skills/connect-recommend/references/decision-matrix.md

中的决策矩阵，并将其应用于用户的回答。

步骤4a — 兼容性验证（展示推荐前必须执行）

阅读

skills/connect-recommend/references/compatibility-matrix.md

，将拟议的

(dashboard, fees_collector, losses_collector)

chargePattern

组合与兼容性矩阵交叉核对。

组合被阻止？ 不得展示该方案。输出醒目的BLOCKED警告，包含以下所有内容：
- 确切的被阻止配置元组（如
```
losses_collector: "stripe" + destination charges
```
  ）
- 2-3句话解释失败机制（如「使用destination charges时，当客户发起拒付，Stripe会撤销关联账户的转账。若losses_collector设为'stripe'，关联账户余额可能变为负数——但尽管配置显示由Stripe负责，平台仍会默默承担此责任。」）
- 推荐的修复方案（最接近的允许替代方案——通常是将
```
losses_collector
```
  改为
```
"application"
```
  或切换为direct charges）然后使用修正后的配置重新生成推荐方案。
组合需注意？ 展示推荐方案，但包含醒目的警告框，说明具体的权衡（如「使用
```
dashboard: "express"
```
时，direct charges的仪表盘可见性受限」）。
额外兼容性检查（触发时包含简洁警告）：
- 若用户提及使用OAuth关联账户，包含1-2句话的警告，说明账户可能断开连接，并推荐使用嵌入式入驻以增强平台控制。
- 若
```
dashboard: "none"
```
  ，包含简洁警告，说明平台必须负责入驻/补救、退款/纠纷流程以及收益/付款界面；推荐使用Express仪表盘加嵌入式组件作为低维护替代方案。
- 若用户提及将Billing、Invoicing或Payment Links与destination charges结合使用，包含简洁的兼容性警告，并推荐最接近的支持路径。
- 若
```
dashboard: "full"
```
  且收费模式为
```
destination
```
  或
```
separate
```
  ，包含简洁警告，说明full dashboard针对direct charges优化，推荐切换仪表盘类型或收费模式。
- 若
```
dashboard: "express"
```
  +
```
fees_collector: "stripe"
```
  ，视为被阻止，推荐切换为full dashboard（Stripe定价）或平台自有定价。
商户一致性检查：验证推荐的收费类型是否符合实际业务关系。Direct charges = 关联账户直接提供商品/服务。Destination/separate charges and transfers = 平台拥有客户关系。Stripe不会在API层面强制商户身份——代码必须保持一致。
兼容性警告简洁性：兼容性警告内容需简洁（最多2-3句话），但需包含机制说明和纠正路径。

步骤4b — 推荐嵌入式组件

推荐使用嵌入式组件，因为它们使平台能够构建自己的全功能仪表盘，尤其是当账户配置为

dashboard: "none"

时，即使账户配置为

dashboard: "full"

或

dashboard: "express"

也适用。根据用户需求选择组件：

基础组件（必选）：

```
account_onboarding
```
```
notification_banner
```
（必填；随着要求变化，保持关联账户正常运行）
```
account_management
```

常见附加组件：

交易记录 →
```
payments
```
（若构建自定义支付列表，使用
```
payment_details
```
）
纠纷 → 包含在
```
payments
```
中，但如果同时构建独立纠纷页面，可使用
```
disputes_list
```
付款操作/收益 →
```
payouts
```

报告/对账 →

balance_report

、

payout_reconciliation_report

收费模式兼容性注意事项：

Destination charges（无
```
on_behalf_of
```
）：支付/纠纷界面显示的细节有限。
```
destination_on_behalf_of_charge_management
```
设置不适用于普通destination charges。
Destination charges（含
```
on_behalf_of
```
）：支付/纠纷界面显示的细节有限，除非启用
```
destination_on_behalf_of_charge_management
```
。此设置仅适用于使用
```
on_behalf_of
```
参数的destination charges——不适用于普通destination charges或separate charges。
Separate charges and transfers：支付/纠纷界面显示的细节有限。此收费模式无等效管理设置。
Direct charges：支付/纠纷界面功能完整。

当推荐含

on_behalf_of

的destination charges对应的支付或纠纷组件时，补充：「仅当平台使用含

on_behalf_of

的destination charges，且希望关联账户查看支付详情、管理退款或处理纠纷，同时集成能够处理纠纷时所需的转账撤销操作时，才启用

destination_on_behalf_of_charge_management

。此设置仅适用于使用

on_behalf_of

参数的destination charges，不适用于普通destination charges或separate charges。」

超出范围的组件系列：

Issuing/Treasury/Capital/Tax组件集（通过步骤3c范围处理）。

准备在下一步输出嵌入式组件列表。

更新进度清单：

  [x] 了解您的业务
  [x] 扫描您的项目
  [x] 推荐配置与收费模式
  [ ] 生成推荐方案

Step 5 — Generate recommendation plan

步骤5 — 生成推荐方案文档

Read
references/recommendation-template.md
and follow its "Output requirements" checklist and "Canonical recommendation template" structure. That file is the single source of truth for required sections, wording, and formatting. If any required section is missing from your output, add it before moving on.

Then use AskUserQuestion:

Does this recommendation look right?

Options (max 4 — AskUserQuestion hard limit):

"Looks good" — proceed to Step 6
"Change something" — ask which aspect to change (dashboard/responsibility settings, charge pattern, fee structure, or fee calculation) then re-ask the relevant question
"Explain more about the options" — read reference docs and explain alternatives

Generate the final recommendation plan. If the user asks, also write the exact same markdown to

connect-recommend-plan.md

at the project root.

When they accept the plan, update the checklist:

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

**阅读

references/recommendation-template.md

**并遵循其「输出要求」清单和「标准推荐模板」结构。该文件是所需章节、措辞和格式的唯一权威来源。若输出中缺少任何必填章节，请补充完整后再继续。

然后使用AskUserQuestion：

此推荐方案是否符合您的需求？

选项（最多4个——AskUserQuestion硬限制）：

"符合要求" — 推进至步骤6
"需要修改" — 询问需修改的方面（仪表盘/责任设置、收费模式、费用结构或费用计算），然后重新询问相关问题
"详细说明选项" — 查阅参考文档并解释替代方案

生成最终推荐方案。若用户要求，将相同的Markdown内容写入项目根目录下的

connect-recommend-plan.md

文件。

当用户接受方案后，更新进度清单：

  [x] 了解您的业务
  [x] 扫描您的项目
  [x] 推荐配置与收费模式
  [x] 生成推荐方案

Step 6 — Explain what belongs in code vs Dashboard, and next actions

步骤6 — 说明代码实现与仪表盘操作的划分，以及后续行动

Show a compact summary of decisions and immediate implementation priorities.

Briefly explain:

In your code: charge pattern behavior,
```
application_fee_amount
```
math, transfer/reversal handling, and webhook handlers
In Stripe Dashboard: platform profile settings, pricing tool configuration, connected-account visibility, Radar for Platforms settings, and operational monitoring
During onboarding/runtime: capability activation, payouts readiness, and account-state transitions

IMPORTANT: Always end with AskUserQuestion. Never end with passive text.

Use AskUserQuestion:

What would you like to do next?

Options:

"Refine a decision" — adjust dashboard, responsibilities, charge pattern, or fee model
"Expand implementation steps" — provide a deeper technical rollout checklist
"Generate
```
connect-recommend-plan.md
```
and build" — write the plan to a markdown file and handoff to a coding agent

展示决策的简洁总结和即时实施优先级。

简要说明：

代码中实现：收费模式逻辑、
```
application_fee_amount
```
计算、转账/撤销处理、Webhook处理器
Stripe仪表盘操作：平台资料设置、定价工具配置、关联账户可见性、Radar for Platforms设置、运营监控
入驻/运行期间：权限激活、付款准备、账户状态转换

重要提示：始终以AskUserQuestion结束对话。切勿以被动文本结束。

使用AskUserQuestion：

您接下来想进行什么操作？

选项：

"调整决策" — 修改仪表盘、责任、收费模式或费用模型
"扩展实施步骤" — 提供更详细的技术部署清单
"生成
```
connect-recommend-plan.md
```
并开始开发" — 将方案写入Markdown文件，移交至编码agent