Connecter Recommend

Recommander la bonne forme d'intégration Stripe Connect. L'utilisateur ne devrait avoir qu'à fournir l'URL de son entreprise ou décrire son activité — la skill se charge du reste.

Modèle d'interaction

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

Auto-agir sur les actions à faible coût. Ne demande jamais la permission pour :

Générer le plan de recommandation markdown — génère-le simplement
Scanner la base de code — scanne-la simplement
Lire les fichiers de référence — lis-les simplement

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

Règles de terminologie (sortie face à l'utilisateur)

Avant de générer toute sortie face à l'utilisateur, lis references/terminology-rules.md. Applique ces règles à tout le texte de recommandation, avertissements, explications et résumés de décision.

Principe clé : décris les configurations en utilisant les valeurs de champ (tableau de bord + propriété des frais + propriété du passif de solde négatif + modèle de facturation), pas des codes abrégés.

Brièveté de la sortie

Garde les réponses concises. L'utilisateur prend des décisions, pas lit de la documentation.

Commence par la recommandation, suis avec un bref argument
Les détails techniques (chemins API, vérifications 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. Énonce le problème et la correction. Aucun approfondissement du mécanisme sauf si l'utilisateur demande.
Résumé de décision : puces uniquement, une ligne par décision
Ne jamais produire plus de ~40 lignes dans une seule réponse pendant le mode interactif

Surface uniquement les limitations hors du champ d'application lorsqu'elles sont directement pertinentes pour ce que l'utilisateur a demandé. Ne liste pas proactivement les contraintes ou fonctionnalités non supportées (p. ex., OAuth, expansion internationale) quand l'utilisateur ne les a pas demandées. « Hors du champ d'application » signifie ici en dehors de ce que ce guide supporte, pas en dehors de ce que Stripe supporte. Recherche ces sujets dans la documentation publique de Stripe (docs.stripe.com) plutôt que de dire qu'ils sont hors du champ d'application.

Instructions

Étape 0 — Affiche la progression

Affiche la liste de contrôle de progression afin que l'utilisateur sache à quoi s'attendre :

Voici ce que nous allons faire :

  [ ] En savoir plus sur votre entreprise
  [ ] Scanner votre projet
  [ ] Recommander configuration + modèle de facturation
  [ ] Produire le plan de recommandation

C'est parti.

Étape 1 — En savoir plus sur l'entreprise (S'EXÉCUTE TOUJOURS en premier)

C'est l'étape la plus importante. Avant de scanner un code ou de poser des questions techniques, comprends ce qu'est l'entreprise.

1a. Vérifie si l'utilisateur a déjà fourni une URL ou une description d'entreprise dans son message. Cherche :

Une URL (p. ex. https://..., www., .com, .io)
Une description d'entreprise (p. ex. « Je construis un marché pour... », « Nous connectons les freelancers avec... »)
Un nom d'entreprise qui peut être recherché

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

Parlez-moi de votre entreprise. Choisissez ce qui vous est le plus facile :

Options :

« J'ai une URL » — l'utilisateur fournit l'URL, puis recherche-la
« Laissez-moi la décrire » — l'utilisateur fournit une description, puis recherche-la
« Scannez simplement ma base de code » — passe à l'étape 2, base-toi uniquement sur les signaux de base de code
« Ignorer — pose-moi des questions à la place » — passe à l'étape 3 avec un questionnaire complet

1c. Recherche sur l'entreprise — lis et suis les instructions du chercheur d'entreprise :

Lis agents/company-researcher.md et effectue ces étapes de recherche, en utilisant l'URL de l'entreprise (si fournie) et la description d'entreprise (si fournie) comme entrées.

La recherche produit une analyse structurée avec des niveaux de confiance (ÉLEVÉ/MOYEN/FAIBLE) pour chaque dimension de décision.

1d. Analyse la sortie de l'agent — elle retourne un tableau Résultats de recherche avec des niveaux de confiance par dimension. Lis la matrice de décision à references/decision-matrix.md et mappe les résultats à une configuration recommandée. Ensuite, détermine le comportement de pré-remplissage par dimension :

Confiance ÉLEVÉE : Pré-remplir automatiquement — ne pose pas de question sur cette dimension
Confiance MOYENNE : Suggère la valeur déduite et demande une confirmation rapide
Confiance FAIBLE : Pose la question ouverte originale à l'étape 3

1e. Présente ce que tu as appris à l'utilisateur (utilise la deuxième personne, ton de confirmation conversationnel) :

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

Sur la base de cela, je recommande : [description de configuration en langage simple]

Je vais continuer avec ceci à moins que vous ne souhaitiez corriger quelque chose.

Pour les éléments de confiance MOYENNE, ajoute : « Je suppose aussi [X] — ça vous semble correct ? »

Si l'agent signale « not-connect » (l'entreprise n'a peut-être pas besoin de Connect), utilise AskUserQuestion :

Sur la base de ma recherche, votre entreprise n'a peut-être pas besoin de Stripe Connect — une intégration Stripe standard pourrait être plus adaptée.

Options :

« Procéder avec Connect de toute façon » — continuer la découverte
« Explorer une intégration standard à la place » — quitter cette skill, suggérer une intégration Stripe standard

Mets à jour la liste de contrôle :

  [x] En savoir plus sur votre entreprise
  [ ] Scanner votre projet
  [ ] Recommander configuration + modèle de facturation
  [ ] Produire le plan de recommandation

1f. Valide l'économie des frais (S'EXÉCUTE TOUJOURS, même sur les valeurs pré-remplies)

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

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

Alors :

AFFICHE TOUJOURS un avertissement de marge indépendamment de la façon dont les frais ont été obtenus
Avertis : « Vos frais de plateforme peuvent être inférieurs aux frais de traitement de Stripe aux tarifs standard. Puisque la plateforme paie les frais de traitement de Stripe avec les facturations de destination, votre marge nette pourrait être très mince ou négative. Vérifiez stripe.com/pricing pour les tarifs de votre région. »
Recommande fortement : calculer application_fee_amount en tant que frais de plateforme + frais de traitement Stripe estimés (afin que la marge de la plateforme soit préservée) et (si la plateforme possède la tarification) utiliser l'Outil de tarification de plateforme
Recommande 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 une confiance ÉLEVÉE. L'utilisateur doit comprendre l'économie des frais avant de continuer.

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

S'EXÉCUTE APRÈS l'étape 1 (ou en parallèle si l'utilisateur a dit « scanner ma base de code »). Utilise les signaux de base de code pour compléter ou corroborer la recherche d'entreprise. Ne pose pas de question avant de scanner — scanne simplement.

Configuration Connect existante : Vérifie la présence de connect-recommend-plan.md ou de tout fichier à la racine du projet qui ressemble à un plan de recommandation antérieur (p. ex., contient ## Recommended Connect integration plan). S'il est trouvé, lis-le et note la configuration antérieure — utilise-la pour pré-remplir ou valider les décisions dans les étapes suivantes, et présente-la à l'utilisateur avant de poser des questions auxquelles il a déjà répondu.
Modèles d'intégration Stripe existants : Utilise Grep pour rechercher les modèles spécifiques à Connect déjà dans la base de code :
- Création de compte connecté ou références (connected_account, account_id, stripe_account)
- Modèles de facturation en cours d'utilisation (destination, on_behalf_of, transfer_data, separate_charges)
- Logique de transfert ou de 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 base de code contredisent la recherche d'entreprise, note la divergence et demande à l'utilisateur de clarifier.

Présente les résultats brièvement (ne répète 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 : [modèles trouvés / non trouvés]

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

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

Options :

« L'utiliser comme point de départ » — pré-remplir toutes les décisions à partir du plan antérieur, puis confirme chacune avec l'utilisateur à l'étape 3
« Recommencer » — ignorer le plan antérieur et exécuter la découverte complète

Mets à jour la liste de contrôle :

  [x] En savoir plus sur votre entreprise
  [x] Scanner votre projet
  [ ] Recommander configuration + modèle de facturation
  [ ] Produire le plan de recommandation

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

Pour toute dimension non encore remplie avec une confiance ÉLEVÉE à partir de l'étape 1, pose la question correspondante en utilisant AskUserQuestion. Ignore les dimensions qui ont été pré-remplies ou explicitement confirmées.

Lis 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 des ventes pilotées/portée) et le point de contrôle de structure de frais.

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

Q1 : Modèle d'entreprise
Q2 : Parties sur la plateforme
Q3 : Flux de paiement
Q4 : Préférence tableau de bord et intégration
Q5 : Propriété des différends/remboursements + gestion des risques + passif de perte
Q6 : Structure de frais + calcul de application_fee_amount

Garde-fous critiques (doit appliquer dans tous les chemins de découverte) :

Pour les flux de paiement marketplace/intermédiaire, utilise par défaut des facturations de destination sauf si le comportement indique clairement que chaque vendeur exécute son propre paiement/relation de paiement.
Si l'entreprise mélange les ventes de marque propre avec les flux marketplace/intermédiaire, déclenche la gestion de flux hybride de l'étape 3b et mappe chaque flux à son propre modèle de facturation et paramètres de responsabilité.
Si l'utilisateur a besoin d'un timing hold-and-release, recommande les charges séparées et les transferts (les charges de destination ne peuvent pas retenir les fonds et ne conviennent pas au comportement hold-and-release).
Pour SaaS avec vendeurs indépendants qui possèdent les relations clients, utilise le tableau de bord complet + facturations directes + intégration embarquée.
Si l'utilisateur demande « quel type de compte dois-je utiliser ? », reformule pendant la découverte en champs explicites Accounts v2 (dashboard, defaults.responsibilities, et merchant/recipient par flux de fonds), pas les types de compte hérités.
Quand tu décris des scénarios à faible marge, présente l'avertissement/risque avant les étapes d'atténuation.
Si dashboard: "none" est sélectionné, inclus un avertissement complet concis sur les responsabilités d'interface utilisateur personnalisée.
Pour les recommandations destination/separate avec losses_collector: "application", explique la chaîne causale : la plateforme possède le passif de solde négatif et les soldes négatifs de compte connecté permettent les inversions de transfert au moment du différend.
Garde la gestion des risques et le passif de solde négatif comme des décisions séparées.
Déclenche l'étape 3c quand les signaux enterprise/sales-led apparaissent (on_behalf_of, complexité transfrontalière, produits non-Connect ou configurations contrôlées par les ventes).

Point de contrôle de structure de frais avant l'étape 4 :

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

Étape 4 — Génère la recommandation

Lis la matrice de décision à references/decision-matrix.md et applique-la aux réponses de l'utilisateur.

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

Lis references/compatibility-matrix.md et effectue une vérification croisée de la combinaison proposée (dashboard, fees_collector, losses_collector) + chargePattern contre la matrice de compatibilité.

Combinaison BLOQUÉE ? Ne la présente PAS. Produis un avertissement BLOQUÉ visible avec TOUS ceux-ci :
- Le tuple de configuration bloquée exact (p. ex., losses_collector: "stripe" + destination charges)
- Une explication du MÉCANISME d'échec en 2-3 phrases (p. ex., « Avec les charges de destination, quand un client conteste une facturation, Stripe inverse le transfert du compte connecté. Si losses_collector est « stripe », le solde du compte connecté peut devenir négatif — mais la plateforme porte silencieusement ce passif malgré le paramètre disant que Stripe est responsable. »)
- La correction recommandée (alternative AUTORISÉE la plus proche — généralement en changeant losses_collector en "application" ou en passant à des charges directes) Puis réexécute la recommandation avec la configuration corrigée.
Combinaison CAUTION ? Présente la recommandation mais inclus un callout d'avertissement visible expliquant le compromis spécifique (p. ex., « limitations de visibilité du tableau de bord pour les charges directes quand tu utilises dashboard: \"express\" »).
Vérifications de compatibilité supplémentaires (inclus les avertissements concis si déclenchés) :
- Si l'utilisateur a mentionné OAuth pour connecter des comptes, inclus un avertissement de 1-2 phrases que les comptes peuvent se déconnecter et recommande l'intégration embarquée pour un meilleur contrôle de la plateforme.
- Si dashboard: "none", inclus un avertissement concis que la plateforme doit posséder l'intégration/remédiation, les flux de remboursement/différend et les surfaces gains/payout ; recommande le tableau de bord Express avec des composants embarqués comme alternative moins exigeante en maintenance.
- Si l'utilisateur mentionne Billing, Invoicing, ou Payment Links avec des charges de destination, inclus un avertissement de compatibilité concis et recommande le chemin supporté le plus proche.
- Si dashboard: "full" + le modèle de facturation est destination ou separate, inclus un avertissement concis que le tableau de bord complet est optimisé pour les charges directes et recommande de changer le type de tableau de bord ou le modèle de facturation.
- Si dashboard: "express" + fees_collector: "stripe", traite comme BLOQUÉ et recommande soit de basculer vers le tableau de bord complet (tarification détenue par Stripe) soit une tarification détenue par la plateforme.
Vérification de cohérence merchant-of-record : Vérifie que le type de facturation recommandé correspond à la relation commerciale réelle. Charges directes = le compte connecté fournit des biens/services directement. Charges de destination/séparées et transferts = la plateforme possède la relation client. Stripe n'applique PAS le merchant of record au niveau de l'API — le code doit être cohérent.
Brièveté de l'avertissement de compatibilité : Garde la copie d'avertissement de compatibilité concise (2-3 phrases max), mais inclus un raisonnement conscient du mécanisme et le chemin correctif.

Étape 4b — Recommande les composants embarqués

Les composants embarqués sont recommandés, car ils permettent aux plates-formes de construire leurs propres tableaux de bord complets, en particulier 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électionne les composants en fonction des besoins des utilisateurs :

Ligne de base (toujours inclure) :

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

Ajouts courants :

Historique des transactions → payments (utilise payment_details si tu construis une liste de paiements personnalisée)
Différends → inclus avec payments mais peut utiliser disputes_list si tu construis aussi une page de différends autonome
Opérations de payout/gains → payouts
Rapports/rapprochement → balance_report, payout_reconciliation_report

Mises en garde de compatibilité du modèle de facturation :

Charges de destination (sans on_behalf_of) : les surfaces de paiement/différend affichent des détails réduits. Le paramètre destination_on_behalf_of_charge_management ne s'applique pas aux charges de destination simples.
Charges de destination avec on_behalf_of : les surfaces de paiement/différend affichent des détails réduits sauf si destination_on_behalf_of_charge_management est activé. Ce paramètre s'applique uniquement aux charges de destination qui utilisent le paramètre on_behalf_of — pas aux charges de destination simples ou aux charges séparées.
Charges séparées et transferts : les surfaces de paiement/différend affichent des détails réduits. Il n'existe pas de paramètre de gestion équivalent pour ce modèle de facturation.
Direct : les surfaces de paiement/différend fonctionnent avec une fidélité complète.

Quand tu recommandes des composants de paiement ou de différend avec des charges de destination qui utilisent on_behalf_of, ajoute : « Active destination_on_behalf_of_charge_management uniquement si la plateforme utilise des charges de destination avec on_behalf_of et souhaite que ses comptes connectés visualisent les détails de paiement, gèrent les remboursements ou gèrent les différends, et que l'intégration gère les inversions de transfert requises quand il y a des différends. Ceci s'applique uniquement aux charges de destination avec le paramètre on_behalf_of, pas aux charges de destination simples ou aux charges séparées. »

Familles de composants hors du champ d'application :

Ensembles de composants Issuing/Treasury/Capital/Tax (achemine par la gestion de portée de l'étape 3c).

Sois prêt à produire une liste de composants embarqués à l'étape suivante.

Mets à jour la liste de contrôle :

  [x] En savoir plus sur votre entreprise
  [x] Scanner votre projet
  [x] Recommander configuration + modèle de facturation
  [ ] Produire le plan de recommandation

Étape 5 — Génère le plan de recommandation

Lis references/recommendation-template.md et suis sa liste de contrôle « Output requirements » et sa structure « Canonical recommendation template ». Ce fichier est la source unique de vérité pour les sections requises, le libellé et le formatage. Si une section requise manque dans ta sortie, ajoute-la avant de continuer.

Ensuite, utilise AskUserQuestion :

Cette recommandation vous semble-t-elle correcte ?

Options (max 4 — limite stricte AskUserQuestion) :

« Ça me semble bon » — procède à l'étape 6
« Changer quelque chose » — demande quel aspect changer (paramètres tableau de bord/responsabilité, modèle de facturation, structure de frais ou calcul de frais) puis repose la question pertinente
« Explique plus sur les options » — lis les documents de référence et explique les alternatives

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

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

  [x] En savoir plus sur votre entreprise
  [x] Scanner votre projet
  [x] Recommander configuration + modèle de facturation
  [x] Produire le plan de recommandation

Étape 6 — Explique ce qui appartient au code vs Tableau de bord, et actions suivantes

Affiche un résumé compact des décisions et des priorités d'implémentation immédiates.

Explique brièvement :

Dans votre code : comportement du modèle de facturation, mathématiques 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 tarification, visibilité des comptes connectés, paramètres Radar for Platforms et surveillance opérationnelle
Pendant l'intégration/exécution : activation de capacité, préparation des payouts et transitions d'état de compte

IMPORTANT : Termine toujours par AskUserQuestion. Ne termine jamais par du texte passif.

Utilise AskUserQuestion :

Que souhaitez-vous faire ensuite ?

Options :

« Affiner une décision » — ajuste tableau de bord, responsabilités, modèle de facturation ou modèle de frais
« Développer les étapes d'implémentation » — fournir une liste de contrôle technique de déploiement plus approfondie
« Générer connect-recommend-plan.md et construire » — écris le plan dans un fichier markdown et remets-le à un agent de codage

Connecter Recommend

Modèle d'interaction

Règles de terminologie (sortie face à l'utilisateur)

Brièveté de la sortie

Instructions

Étape 0 — Affiche la progression

Étape 1 — En savoir plus sur l'entreprise (S'EXÉCUTE TOUJOURS en premier)

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

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

Étape 4 — Génère la recommandation

Étape 5 — Génère le plan de recommandation

Étape 6 — Explique ce qui appartient au code vs Tableau de bord, et actions suivantes

Skills similaires