Recommander Connect

Recommandez la bonne forme d'intégration Stripe Connect. L'utilisateur ne devrait avoir à fournir que l'URL de son entreprise ou décrire son activité — la skill figure out le reste.

Modèle d'interaction

AskUserQuestion est l'outil d'interaction principal. Chaque point de décision de cette skill DOIT utiliser AskUserQuestion avec des options claires numérotées et des descriptions courtes. Une question à la fois — ne surchargez jamais l'utilisateur.

Auto-exécutez les actions à faible coût. Ne demandez jamais la permission pour :

Générer le plan de recommandation markdown — générez-le simplement
Scanner la base de code — scannez-la simplement
Lire des fichiers de référence — lisez-les simplement

Ne terminez jamais par du texte passif. Chaque point d'arrêt doit se terminer par une AskUserQuestion proposant des actions concrètes suivantes.

Règles de terminologie (sortie orientée utilisateur)

Avant de générer une sortie orientée utilisateur, lisez references/terminology-rules.md. Appliquez ces règles à tout le texte de recommandation, avertissements, explications et résumés de décisions.

Principe clé : décrivez les configurations en utilisant les valeurs de champs (tableau de bord + propriété des frais + propriété de la responsabilité de solde négatif + modèle de charge), pas des codes raccourcis.

Brièveté de la sortie

Gardez les réponses concises. L'utilisateur prend des décisions, pas en train de lire de la documentation.

Commencez par la recommandation, suivez avec une brève justification
Les détails techniques (chemins API, contrôles de capacité) vont dans une section « Détails » du plan markdown final — pas en ligne dans la recommandation principale
Blocs d'avertissement : 2-3 phrases maximum. Énoncez le problème et la solution. Pas d'approfondissements sur les mécanismes sauf si l'utilisateur le demande.
Résumé de décision : points de liste uniquement, une ligne par décision
Ne produisez jamais plus de ~40 lignes dans une seule réponse en mode interactif

Ne surfacez les limitations hors périmètre que si elles sont directement pertinentes pour ce que l'utilisateur a demandé. Ne listez pas proactivement les contraintes ou les fonctionnalités non supportées (par ex., OAuth, expansion internationale) quand l'utilisateur ne les a pas mentionnées. « Hors périmètre » ici signifie en dehors de ce que ce guide supporte, pas en dehors de ce que Stripe supporte. Recherchez ces sujets dans la documentation publique de Stripe (docs.stripe.com) plutôt que de dire qu'ils sont hors périmètre.

Instructions

Étape 0 — Montrez la progression

Affichez la liste de contrôle de progression pour que l'utilisateur sache ce qui l'attend :

Voici ce que nous allons faire :

  [ ] En savoir plus sur votre activité
  [ ] Scanner votre projet
  [ ] Recommander la configuration + le modèle de charge
  [ ] Produire le plan de recommandation

Commençons.

Étape 1 — En savoir plus sur l'activité (TOUJOURS en premier)

C'est l'étape la plus importante. Avant de scanner du code ou de poser des questions techniques, comprenez ce que fait l'activité.

1a. Vérifiez si l'utilisateur a déjà fourni une URL ou une description d'activité dans son message. Cherchez :

Une URL (par ex. https://..., www., .com, .io)
Une description d'activité (par ex. « Je crée une marketplace pour... », « Nous connectons les freelancers avec... »)
Un nom d'entreprise qui peut être recherché

1b. Si rien n'a été fourni, posez immédiatement une question avec AskUserQuestion — c'est la PREMIÈRE question que l'utilisateur voit :

Parlez-moi de votre activité. Choisissez la solution la plus facile :

Options :

« J'ai une URL » — l'utilisateur fournit l'URL, puis recherchez-la
« Laissez-moi la décrire » — l'utilisateur fournit une description, puis recherchez-la
« Scannez simplement mon code » — passez à l'Étape 2, en vous appuyant uniquement sur les signaux de la base de code
« Passer — posez-moi des questions à la place » — passez à l'Étape 3 avec un questionnaire complet

1c. Recherchez l'activité — invoquez l'agent company-researcher :

Utilisez l'outil Task avec subagent_type: "general-purpose" pour invoquer l'agent company-researcher. Dans votre invite, incluez :

L'URL de l'entreprise (si fournie)
La description de l'activité (si fournie)
Demandez à l'agent de lire agents/company-researcher.md pour ses instructions

L'agent retournera une analyse structurée avec des niveaux de confiance (HIGH/MEDIUM/LOW) pour chaque dimension de décision.

1d. Analysez la sortie de l'agent — elle retourne un tableau Research Findings avec des niveaux de confiance par dimension. Lisez la matrice de décision à skills/connect-recommend/references/decision-matrix.md et mappez les résultats à une configuration recommandée. Ensuite, déterminez le comportement de pré-remplissage par dimension :

Confiance HIGH : Pré-remplissez automatiquement — ne posez pas de question sur cette dimension
Confiance MEDIUM : Suggérez la valeur déduite et demandez une confirmation rapide
Confiance LOW : Posez la question ouverte originale à l'Étape 3

1e. Présentez ce que vous avez appris à l'utilisateur (utilisez un ton de confirmation conversationnel à la deuxième personne) :

Voici ce que j'ai rassemblé sur votre activité — dites-moi si quelque chose semble incorrect :
  ┌──────────────────────────┬────────────────────────────────┐
  │ *Type d'activité*        │ [marketplace ou plateforme SaaS] │
  ├──────────────────────────┼────────────────────────────────┤
  │ *Vendeurs/prestataires*  │ [qui ils sont]                  │
  ├──────────────────────────┼────────────────────────────────┤
  │ *Acheteurs/clients*      │ [qui ils sont]                  │
  ├──────────────────────────┼────────────────────────────────┤
  │ *Flux d'argent*          │ [flux de paiement]              │
  ├──────────────────────────┼────────────────────────────────┤
  │ *Structure des frais*    │ [détails des frais]             │
  └──────────────────────────┴────────────────────────────────┘

Basé sur cela, je recommande : [description de configuration en langage simple]

Je procéderai comme cela sauf si vous souhaitez corriger quelque chose.

Pour les éléments avec confiance MEDIUM, ajoutez : « J'assume aussi que [X] — c'est correct ? »

Si l'agent signale « not-connect » (l'activité n'a pas besoin de Connect), utilisez AskUserQuestion :

Basé sur ma recherche, votre activité pourrait ne pas avoir besoin de Stripe Connect — une intégration Stripe standard pourrait être un meilleur choix.

Options :

« Procédez avec Connect quand même » — continuez la découverte
« Explorez une intégration standard à la place » — quittez cette skill, suggérez une intégration Stripe standard

Mettez à jour la liste de contrôle :

  [x] En savoir plus sur votre activité
  [ ] Scanner votre projet
  [ ] Recommander la configuration + le modèle de charge
  [ ] Produire le plan de recommandation

1f. Validez l'économie des frais (TOUJOURS exécuté, même sur des valeurs pré-remplies)

Si les frais de la plateforme (depuis le pré-remplissage ou l'entrée utilisateur) semblent bas ET l'une de ces conditions s'applique :

Le modèle de charge est destination ou separate (la plateforme paie les frais Stripe par défaut)
Le modèle de charge est direct ET fees_collector: "application" (la plateforme paie toujours les frais Stripe)

Alors :

TOUJOURS affichez un avertissement de marge indépendamment de comment les frais ont été obtenus
Avertissez : « Vos frais de plateforme pourraient être inférieurs aux frais de traitement de Stripe aux taux standard. Puisque la plateforme paie les frais de traitement de Stripe avec les destination charges, votre marge nette pourrait être très fine ou négative. Consultez stripe.com/pricing pour les taux de votre région. »
Recommandez fortement : de calculer application_fee_amount comme frais de plateforme + frais de traitement Stripe estimés (pour que la marge de la plateforme soit préservée) et (si la plateforme possède le pricing) d'utiliser le Platform Pricing Tool
Recommandez de surveiller le rapport de marge dans le Tableau de bord Stripe

Cette vérification DOIT s'exécuter même quand les frais ont été pré-remplis avec confiance HIGH. L'utilisateur doit comprendre l'économie des frais avant de procéder.

Étape 2 — Détection automatique du contexte du projet

Exécutez cela APRÈS l'Étape 1 (ou en parallèle si l'utilisateur a dit « scannez mon code »). Utilisez les signaux de la base de code pour compléter ou corroborer la recherche d'entreprise. Ne posez pas de question avant de scanner — scannez simplement.

Config Connect existante : Vérifiez connect-recommend-plan.md ou tout fichier à la racine du projet qui ressemble à un plan de recommandation antérieur (par ex., contient ## Recommended Connect integration plan). S'il est trouvé, lisez-le et notez la configuration antérieure — utilisez-le pour pré-remplir ou valider les décisions aux étapes ultérieures, et surfacez-le à l'utilisateur avant de poser des questions auxquelles ils ont déjà répondu.
Patterns d'intégration Stripe existants : Utilisez Grep pour chercher les patterns spécifiques à Connect déjà dans la base de code :
- Création ou références de compte connecté (connected_account, account_id, stripe_account)
- Modèles de charge en utilisation (destination, on_behalf_of, transfer_data, separate_charges)
- Logique de transfert ou payout (transfers.create, payouts.create)
- Gestionnaires webhook pour les événements Connect (account.updated, capability, payout)
- Utilisation existante de application_fee_amount

Si les signaux de la base de code contredisent la recherche d'entreprise, notez la discordance et demandez à l'utilisateur de clarifier.

Présentez les résultats brièvement (ne répétez pas ce que l'Étape 1 a déjà couvert) :

Scan du projet :
- Plan Connect existant : [trouvé au chemin / non trouvé]
- Intégration Connect existante : [patterns trouvés / non trouvés]

Si un plan antérieur a été trouvé, utilisez AskUserQuestion :

J'ai trouvé un plan de recommandation Connect existant à [chemin].

Options :

« L'utiliser comme point de départ » — pré-remplissez toutes les décisions depuis le plan antérieur, puis confirmez chacune avec l'utilisateur à l'Étape 3
« Recommencer à zéro » — ignorez le plan antérieur et exécutez la découverte complète

Mettez à jour la liste de contrôle :

  [x] En savoir plus sur votre activité
  [x] Scanner votre projet
  [ ] Recommander la configuration + le modèle de charge
  [ ] Produire le plan de recommandation

Étape 3 — Posez les questions de découverte restantes

Pour toute dimension non encore remplie avec confiance HIGH de l'Étape 1, posez la question correspondante en utilisant AskUserQuestion. Ignorez les dimensions qui ont été pré-remplies ou explicitement confirmées.

Lisez references/discovery-questions.md pour les scripts de questions complets, les mappages d'options et la logique de cas limites pour l'Étape 3, l'Étape 3b (flux hybrides), l'Étape 3c (détection sales-led/scope) et le checkpoint de structure des frais.

Si l'Étape 1 a été complètement ignorée, posez les six questions de découverte une à la fois :

Q1 : Modèle métier
Q2 : Parties sur la plateforme
Q3 : Flux de paiement
Q4 : Préférence tableau de bord et onboarding
Q5 : Propriété des disputes/remboursements + gestion des risques + responsabilité des pertes
Q6 : Structure des frais + calcul de application_fee_amount

Garde-fous critiques (doivent être appliqués dans tous les chemins de découverte) :

Pour les flux de checkout de marketplace/intermediary, par défaut aux destination charges sauf si le comportement indique clairement que chaque vendeur gère son propre checkout/relation de paiement.
Si l'activité mélange les ventes de sa propre marque avec les flux marketplace/intermediary, déclenchez la gestion du flux hybride de l'Étape 3b et mappez chaque flux à son propre modèle de charge et paramètres de responsabilité.
Si l'utilisateur a besoin d'une synchronisation hold-and-release, recommandez les separate charges et transfers (destination charges ne peuvent pas retenir les fonds et ne sont pas appropriées pour le comportement hold-and-release).
Pour SaaS avec vendeurs indépendants qui possèdent les relations clients, utilisez le tableau de bord complet + direct charges + embedded onboarding.
Si l'utilisateur demande « quel type de compte devrais-je utiliser ? », reformulez pendant la découverte vers les champs explicites d'Accounts v2 (dashboard, defaults.responsibilities, et merchant/recipient par flux de fonds), pas les types de compte hérités.
Quand vous décrivez des scénarios à faible marge, présentez l'avertissement/risque avant les étapes d'atténuation.
Si dashboard: "none" est sélectionné, incluez un avertissement de périmètre complet et concis sur les responsabilités UI personnalisées.
Pour les recommandations destination/separate avec losses_collector: "application", expliquez la chaîne causale : la plateforme possède la responsabilité de solde négatif et les soldes négatifs de comptes connectés permettent les inversions de transfert au moment des disputes.
Gardez la gestion des risques et la responsabilité de solde négatif comme des décisions séparées.
Déclenchez l'Étape 3c quand les signaux enterprise/sales-led apparaissent (on_behalf_of, complexité transfrontalière, produits non-Connect, ou configs gated par ventes).

Checkpoint de structure des frais avant l'Étape 4 :

Confirmez le type de frais et le montant des frais
Confirmez comment application_fee_amount est calculé
Confirmez si un avertissement de marge est requis
Incluez le lien stripe.com/pricing dans le contexte de sortie

Étape 4 — Générez la recommandation

Lisez la matrice de décision à skills/connect-recommend/references/decision-matrix.md et appliquez-la aux réponses de l'utilisateur.

Étape 4a — Validation de compatibilité (OBLIGATOIRE avant de présenter la recommandation)

Lisez skills/connect-recommend/references/compatibility-matrix.md et vérifiez la combinaison proposée (dashboard, fees_collector, losses_collector) + chargePattern par rapport à la matrice de compatibilité.

Combinaison BLOQUÉE ? Ne la présentez PAS. Affichez un avertissement BLOCKED visible avec TOUS les éléments suivants :
- Le tuple de configuration bloquée exact (par ex., losses_collector: "stripe" + destination charges)
- Une explication de 2-3 phrases du MÉCANISME de l'échec (par ex., « Avec les destination charges, quand un client conteste une charge, Stripe inverse le transfert depuis le compte connecté. Si losses_collector est 'stripe', le solde du compte connecté peut devenir négatif — mais la plateforme porte silencieusement cette responsabilité malgré la config disant que Stripe est responsable. »)
- La correction recommandée (l'alternative AUTORISÉE la plus proche — généralement en passant losses_collector à "application" ou en passant aux direct charges) Puis réexécutez la recommandation avec la configuration corrigée.
Combinaison CAUTION ? Présentez la recommandation mais incluez un callout d'avertissement visible expliquant le tradeoff spécifique (par ex., « limitations de visibilité du tableau de bord pour les direct charges lors de l'utilisation de dashboard: \"express\" »).
Vérifications de compatibilité supplémentaires (incluez des avertissements concis quand déclenchés) :
- Si l'utilisateur a mentionné OAuth pour connecter des comptes, incluez un avertissement de 1-2 phrases que les comptes peuvent se déconnecter et recommandez l'embedded onboarding pour un contrôle de plateforme plus fort.
- Si dashboard: "none", incluez un avertissement concis que la plateforme doit posséder l'onboarding/remédiation, les flux de remboursement/dispute, et les surfaces gains/payout ; recommandez le tableau de bord Express avec des composants intégrés comme une alternative à moins de maintenance.
- Si l'utilisateur mentionne Billing, Invoicing, ou Payment Links avec destination charges, incluez un avertissement de compatibilité concis et recommandez le chemin le plus proche supporté.
- Si dashboard: "full" + le modèle de charge est destination ou separate, incluez un avertissement concis que le tableau de bord complet est optimisé pour les direct charges et recommandez de changer le type de tableau de bord ou le modèle de charge.
- Si dashboard: "express" + fees_collector: "stripe", traitez comme BLOCKED et recommandez soit de passer au tableau de bord complet (pricing possédé par Stripe) soit au pricing possédé par la plateforme.
Vérification de cohérence merchant-of-record : Vérifiez que le type de charge recommandé correspond à la relation métier réelle. Direct charges = le compte connecté fournit les biens/services directement. Destination/separate charges et transfers = la plateforme possède la relation client. Stripe ne force PAS le merchant of record au niveau de l'API — le code doit être cohérent.
Brièveté de l'avertissement de compatibilité : Gardez la copie d'avertissement de compatibilité concise (2-3 phrases max), mais incluez un raisonnement conscient du mécanisme et le chemin correctif.

Étape 4b — Recommandez les composants intégrés

Les composants intégrés sont recommandés, car ils permettent aux plateformes de construire leurs propres tableaux de bord complets, notamment quand les comptes sont configurés avec dashboard: "none" et même si les comptes sont configurés avec (dashboard: "full" ou dashboard: "express"). Sélectionnez les composants basés sur les besoins utilisateur :

Baseline (toujours inclure) :

account_onboarding
notification_banner (requis ; maintient les comptes connectés sains/activés à mesure que les exigences évoluent)
account_management

Ajouts courants :

Historique des transactions → payments (utilisez payment_details si vous construisez une liste de paiements personnalisée)
Disputes → incluses avec payments mais pouvez utiliser disputes_list si vous construisez aussi une page de disputes autonome
Opérations de payout/gains → payouts
Rapports/rapprochement → balance_report, payout_reconciliation_report

Mises en garde de compatibilité modèle de charge :

Destination charges (sans on_behalf_of) : les surfaces de paiement/dispute montrent des détails réduits. Le paramètre destination_on_behalf_of_charge_management ne s'applique pas aux destination charges simples.
Destination charges avec on_behalf_of : les surfaces de paiement/dispute montrent des détails réduits sauf si destination_on_behalf_of_charge_management est activé. Ce paramètre s'applique uniquement aux destination charges qui utilisent le paramètre on_behalf_of — pas aux destination charges simples ou aux separate charges.
Separate charges et transfers : les surfaces de paiement/dispute montrent des détails réduits. Il n'y a pas de paramètre de gestion équivalent pour ce modèle de charge.
Direct : les surfaces de paiement/dispute opèrent avec une fidélité complète.

Quand vous recommandez des composants de paiement ou de dispute avec des destination charges qui utilisent on_behalf_of, ajoutez : « Activez destination_on_behalf_of_charge_management uniquement si la plateforme utilise des destination charges avec on_behalf_of et souhaite que ses comptes connectés voient les détails des paiements, gèrent les remboursements ou gèrent les disputes, et l'intégration gère les inversions de transfert requises quand il y a des disputes. Ceci s'applique uniquement aux destination charges avec le paramètre on_behalf_of, pas aux destination charges simples ou aux separate charges. »

Familles de composants hors périmètre :

Ensembles de composants Issuing/Treasury/Capital/Tax (acheminez via la gestion de scope de l'Étape 3c).

Soyez prêt à afficher une liste de composants intégrés à l'étape suivante.

Mettez à jour la liste de contrôle :

  [x] En savoir plus sur votre activité
  [x] Scanner votre projet
  [x] Recommander la configuration + le modèle de charge
  [ ] Produire le plan de recommandation

Étape 5 — Générez le plan de recommandation

Lisez references/recommendation-template.md et suivez sa liste de contrôle « Output requirements » et sa structure de « Canonical recommendation template ». Ce fichier est la source unique de vérité pour les sections requises, la formulation et le formatage. Si une section requise manque de votre sortie, ajoutez-la avant de continuer.

Puis utilisez AskUserQuestion :

Cette recommandation semble-t-elle correcte ?

Options (max 4 — limite stricte d'AskUserQuestion) :

« Cela semble bon » — passez à l'Étape 6
« Changez quelque chose » — demandez quel aspect changer (paramètres tableau de bord/responsabilité, modèle de charge, structure des frais, ou calcul des frais) puis re-posez la question pertinente
« Expliquez plus sur les options » — lisez les docs de référence et expliquez les alternatives

Générez le plan de recommandation final. Si l'utilisateur le demande, écrivez aussi le même markdown vers connect-recommend-plan.md à la racine du projet.

Quand ils acceptent le plan, mettez à jour la liste de contrôle :

  [x] En savoir plus sur votre activité
  [x] Scanner votre projet
  [x] Recommander la configuration + le modèle de charge
  [x] Produire le plan de recommandation

Étape 6 — Expliquez ce qui va dans le code vs Tableau de bord, et prochaines actions

Affichez un résumé compact des décisions et des priorités de mise en œuvre immédiates.

Expliquez brièvement :

Dans votre code : comportement du modèle de charge, math de application_fee_amount, gestion des transferts/inversions, et gestionnaires webhook
Dans le Tableau de bord Stripe : paramètres de profil de plateforme, configuration de l'outil de pricing, visibilité des comptes connectés, paramètres Radar for Platforms, et surveillance opérationnelle
Pendant l'onboarding/runtime : activation des capacités, préparation des payouts, et transitions d'état de compte

IMPORTANT : Terminez toujours par AskUserQuestion. Ne terminez jamais par du texte passif.

Utilisez AskUserQuestion :

Que voulez-vous faire ensuite ?

Options :

« Affiner une décision » — ajustez le tableau de bord, les responsabilités, le modèle de charge, ou le modèle de frais
« Développez les étapes de mise en œuvre » — fournissez une liste de contrôle de déploiement technique plus approfondie
« Générez connect-recommend-plan.md et construisez » — écrivez le plan dans un fichier markdown et transférez à un agent de codage

Recommander Connect

Modèle d'interaction

Règles de terminologie (sortie orientée utilisateur)

Brièveté de la sortie

Instructions

Étape 0 — Montrez la progression

Étape 1 — En savoir plus sur l'activité (TOUJOURS en premier)

Étape 2 — Détection automatique du contexte du projet

Étape 3 — Posez les questions de découverte restantes

Étape 4 — Générez la recommandation

Étape 5 — Générez le plan de recommandation

Étape 6 — Expliquez ce qui va dans le code vs Tableau de bord, et prochaines actions

Skills similaires