Springbrand.ai

npx add-mcp 'https://connector.springbrand.ai/mcp'

Configuration de l'Agent SpringBrand

Installez SpringBrand Production via le guide natif de l'Hôte correspondant : WorkBuddy utilise une version R2 publiée ; Codex, Claude Code et Cursor conservent GitHub main. Les autres Agents utilisent le repli documenté Skill-plus-MCP.

Cette arborescence source contient cinq Skills Canoniques et une entrée MCP par environnement. Le package publié WorkBuddy v1.2.2 inclut les mêmes cinq Skills. L'entrée MCP expose cinq Meta Tools partagés ; les Domain Skills préservent les frontières métier via des contrats d'opérations découverts plutôt que des préfixes de noms d'outils enregistrés :

Skill	Rôle	Utilisation MCP
springbrand-gtm	Entrée métier GTM substantielle ; délègue à un Domain Skill	aucune (n'appelle jamais MCP)
ask-springbrand	Ask SpringBrand — Guide de Capacités non exécutant	aucune (n'appelle jamais MCP)
springbrand-platform	Platform — création/publication d'artefacts, cycle de vie des Plugins	outils partagés de découverte, schéma, exécution et résultats
springbrand-action-api	Action API — exécution dynamique de services API	outils partagés de découverte, schéma, exécution et résultats
springbrand-connector	Connector — systèmes tiers autorisés	outils partagés plus gestion des connexions

Démarrage rapide

SpringBrand dispose de deux environnements. Choisissez celui dont vous avez besoin et collez l'invite correspondante dans votre Agent (Cursor, Claude Code, Codex, Copilot, Devin, Windsurf, WorkBuddy, ou tout Agent compatible).

Production

Installez ou mettez à jour SpringBrand Production en suivant https://plugin.springbrand.ai/INSTALL.md. Identifiez cet Agent, utilisez le guide de l'Hôte correspondant, détectez si SpringBrand est déjà installé, actualisez le Marketplace/Plugin existant en place lors d'une mise à jour, privilégiez l'OAuth natif, préservez la configuration existante, et faites une pause uniquement pour les étapes UI ou OAuth que je dois compléter.

INSTALL.md est le protocole de production universel. Il route WorkBuddy vers la version R2 publiée et les autres Hôtes vers leurs chemins GitHub existants. N'utilisez pas la branche héritée stable et ne devinez pas une version non publiée. L'entrée MCP de production exige l'OAuth natif de l'Hôte — un consentement par Surface (une seule autorisation couvre les trois domaines).

Développement

Suivez le guide d'installation officiel de développement SpringBrand pour terminer la configuration : https://github.com/springbrand-lab/springbrand-agent-setup/blob/v1.2.1-dev.2/INSTALL.dev.md Identifiez d'abord l'environnement cible et l'Hôte. Fournissez la clé API de développement uniquement à l'exécution via le flux d'identification sécurisé de l'Hôte. Configurez exactement une entrée springbrand-dev, préservez la configuration non liée, exécutez la vérification d'identité faisant autorité et la vérification de santé du service MCP configuré, et signalez si un redémarrage ou une nouvelle session est nécessaire. Ne lancez pas OAuth lorsque la clé API est valide ; utilisez les instructions UI manuelles et arrêtez-vous si l'Hôte ne peut pas représenter les identifiants Bearer en toute sécurité.

Le Plugin de développement natif est la préversion immuable v1.2.1-dev.2. Il est identifié comme springbrand-dev, s'affiche comme SpringBrand Dev, et regroupe une seule entrée MCP springbrand-dev à https://devconnector.springbrand.ai/mcp. Le descripteur de développement sélectionné possède son propre transport HTTP natif et sa représentation d'identifiants de clé API à l'exécution.

Gardez les Plugins de production et de développement complets activés ensemble uniquement lorsque l'Hôte peut distinguer leurs entrées et leur routage. Préservez l'entrée de production et toute la configuration non liée pendant l'installation ou la migration de développement. Le repli manuel partage les mêmes cinq Skills Canoniques et ajoute ou met à jour uniquement l'entrée MCP springbrand-dev nommée séparément.

Production vs Développement

	Production	Développement
Guide d'installation	INSTALL.md	INSTALL.dev.md
Nom de l'entrée MCP	springbrand	springbrand-dev
URL MCP	https://connector.springbrand.ai/mcp	https://devconnector.springbrand.ai/mcp
Authentification	OAuth natif de l'Hôte	Clé API à l'exécution via le descripteur sélectionné
Objectif	Usage quotidien	Tests uniquement
Plugins complets peuvent coexister	Dépend de l'Hôte ; le routage doit rester sans ambiguïté	Dépend de l'Hôte ; le routage doit rester sans ambiguïté
Repli manuel Skill-plus-MCP peut coexister	Oui	Oui — il partage les mêmes Skills et utilise un nom d'entrée MCP séparé

La source actuelle et la dernière version de développement incluent springbrand-gtm, ask-springbrand, springbrand-platform, springbrand-action-api et springbrand-connector ; installez une version cohérente plutôt que de mélanger les versions de Skills. Le développement est réservé aux tests uniquement et ne doit pas être utilisé comme configuration de production.

Ce qui est installé

• Plugin Codex — regroupe les cinq Skills Canoniques, la déclaration MCP de production unique et le Hook de pré-vérification statique pour les hôtes macOS Codex pris en charge.
• Plugin Claude Code — regroupe les mêmes cinq Skills, une entrée MCP de production native avec OAuth et le Hook de pré-vérification statique pour Claude Code CLI et l'onglet Code de Claude Desktop ; voir INSTALL.claude.md.
• Plugin Cursor — regroupe des Mirrors de Distribution générés et vérifiés des cinq Skills avec une entrée MCP de production native avec OAuth et une Règle de pré-vérification toujours appliquée pour Cursor desktop ; voir INSTALL.cursor.md.
• Plugin WorkBuddy — un Agent WorkBuddy l'installe via le CLI intégré ; Add Marketplace reste le repli manuel ; voir INSTALL.workbuddy.md.
• Plugin SpringBrand Dev (préversion) — regroupe cinq Skills dont springbrand-gtm et l'entrée MCP unique springbrand-dev pour les tests internes contre https://devconnector.springbrand.ai/mcp ; voir INSTALL.dev.md.
• Repli Skill-plus-MCP — les cinq Skills au niveau utilisateur et l'entrée MCP distante unique pour les hôtes non pris en charge.

La clé API de développement est demandée uniquement à l'exécution et n'est jamais stockée dans les fichiers du dépôt, le texte des Skills, les URL, les journaux, les erreurs ou les rapports. L'authentification de production reste détenue par le contrat de version de production. Aucun Plugin ne contient d'identifiants réutilisables ou d'en-têtes d'autorisation statiques.

Canaux de distribution

Environnement	Canal d'installation
Production — WorkBuddy	Version R2 publiée sélectionnée dans INSTALL.workbuddy.md (actuellement épinglée)
Production — autres Hôtes	https://github.com/springbrand-lab/springbrand-agent-setup (main)
Développement	springbrand-lab/springbrand-agent-setup@v1.2.1-dev.2

WorkBuddy installe un package à balise de production immuable depuis R2, pas un miroir en direct de main ; l'URL actuelle n'avance pas automatiquement. Les autres Hôtes suivent toujours main. La publication de la version vers R2 est actuellement déclenchée manuellement. Les Plugins de développement restent des balises de développement immuables et ne sont jamais fusionnés dans main.

Structure du dépôt

Chaque Skill Canonique déclare la version du package dans le YAML metadata.version. VERSION est la source de vérité : les versions de production n'ont pas de marqueur -dev.N ; les versions de développement l'incluent. Gardez name en minuscules et stable sur les deux canaux. Cela identifie la version du Skill installé, pas la version du serveur MCP.

La synchronisation de production s'exécute automatiquement sur les demandes de tirage du même dépôt ciblant main. Après que l'auteur de la version met à jour VERSION et les manifestes du package, CI estampille les Skills Canoniques, met à jour les Mirrors de Distribution Cursor/WorkBuddy, et valide les modifications générées sur la branche PR. Il déclenche ensuite la validation pour ce nouveau commit. Fusionnez la PR examinée et créez la balise de production à partir du commit synchronisé ; aucune commande de synchronisation de version séparée n'est nécessaire. Le workflow ne pousse jamais directement vers main protégé et ne réécrit pas les balises existantes.

Les versions de développement se synchronisent automatiquement dans build_dev_variant.py --version .... Pour les aperçus locaux ou les contributions de forks (où CI ne peut pas écrire sur la branche source), la même opération est disponible :

python3 scripts/sync_skill_versions.py
python3 scripts/sync_skill_versions.py --check
python3 tests/validate_plugin.py

CI rejette les versions ou miroirs incompatibles sur main, les balises et les déclenchements de validation. La synchronisation automatique des PR utilise des permissions contents: write et actions: write limitées au travail ; les travaux de validation restent en lecture seule. Les métadonnées de version ne vérifient pas elles-mêmes les versions distantes et ne mettent pas à jour un Skill installé ; les mises à niveau utilisent toujours le flux d'installation documenté pour le canal prévu.

springbrand-agent-setup/
├── README.md                          # this file — for humans
├── INSTALL.md                         # the production installation protocol — for Agents
├── INSTALL.dev.md                     # the development installation protocol — for Agents
├── VERSION                            # current release version
└── skills/
    ├── ask-springbrand/SKILL.md       # Ask SpringBrand — non-executing Capability Guide
    ├── springbrand-platform/SKILL.md  # Platform Domain Skill
    ├── springbrand-action-api/SKILL.md # Action API Domain Skill
    ├── springbrand-connector/SKILL.md # Connector Domain Skill
    └── springbrand-gtm/SKILL.md       # GTM Scenario Skill

INSTALL.md et INSTALL.dev.md sont le produit principal. Ils sont écrits pour être lus et exécutés par un Agent. Les sources des Skills vivent dans skills/<machine-name>/SKILL.md et sont récupérées par l'Agent pendant l'installation ; la version sélectionnée détermine l'ensemble complet des Skills Canoniques.

Exigences

Votre Agent doit prendre en charge :

• La lecture d'une URL distante et l'écriture de fichiers dans votre répertoire de Skills au niveau utilisateur.
• Les serveurs MCP Streamable HTTP distants avec le contrat d'identifiants de la version sélectionnée, y compris un mécanisme d'identifiants Bearer sécurisé pour le développement.

Si l'un ou l'autre manque, INSTALL.md indique à l'Agent de s'arrêter et de signaler la limitation. Certains Agents de bureau ne peuvent ajouter des serveurs MCP que via leur interface ; dans ce cas, l'Agent vous donnera les valeurs exactes à saisir manuellement.

Sécurité

• L'installateur ne stocke ni n'imprime jamais de clés API, de jetons OAuth, d'en-têtes d'autorisation, d'identifiants de fournisseur ou de réponses brutes en amont.
• L'URL MCP de production est fixée à https://connector.springbrand.ai/mcp ; l'URL MCP de développement est fixée à https://devconnector.springbrand.ai/mcp.
• La configuration MCP existante est préservée. Le repli manuel de développement fusionne uniquement l'entrée springbrand-dev ; les opérations natives du cycle de vie des Plugins suppriment uniquement leurs propres composants groupés.
• L'installateur n'exécute aucun script tiers externe.
• Aucun identifiant ou jeton n'est placé dans les fichiers de Skills, le contenu du dépôt, les URL, les journaux, les erreurs ou les rapports finaux.

Mise à jour

Utilisez le flux de mise à jour Marketplace natif de chaque hôte pour les Plugins. Pour le repli manuel, envoyez à nouveau la même invite ; INSTALL.md / INSTALL.dev.md met à jour les entrées existantes plutôt que d'ajouter des doublons.

Migration depuis une version de Plugin héritée

Une version de Plugin héritée — une version de Plugin SpringBrand déjà installée qui utilise une seule entrée MCP springbrand à https://connector.springbrand.ai/mcp avec le contrat mixte hérité de la passerelle (noms d'outils sans préfixe) — continue de fonctionner jusqu'à ce que la version de production du propriétaire bascule l'emplacement /mcp vers le point de terminaison unifié (ADR-0014 de la passerelle ; la retraite est le problème 12 de la passerelle, contrôlé par le propriétaire). La mise à niveau vers le Plugin actuel à entrée unique avec des outils à préfixe de domaine est volontaire — il n'y a pas de coucher de soleil automatique.

Futur : installateur déterministe

Un installateur programmatique (npx @springbrand/setup@latest) est prévu comme alternative déterministe pour les environnements où l'installation basée sur des invites n'est pas fiable. Il n'est pas requis pour le flux actuel.