Aller au contenu

Storybook MCP

Deux serveurs dans .cursor/mcp.json — rôles différents, pas interchangeables.

storybook-dev (local) storybook (Chromatic develop)
URL MCP http://localhost:6007/mcp URL Chromatic publiée
Reflète Branche + changements non commités Dernier develop déployé uniquement
get-documentation / get-documentation-for-story Oui Oui (ID composant connu)
list-all-documentation Oui — uniquement ici Non
get-storybook-story-instructions Oui — uniquement ici Non
run-story-tests Oui — uniquement ici Non
preview-stories Oui — uniquement ici Non

Réf upstream : Storybook MCP overview.

Storybook local requis (storybook-dev)

Tout sauf get-documentation / get-documentation-for-story nécessite storybook-dev avec le dev server actif — inventaire (list-all-documentation), instructions stories, tests, previews.

Pre-flight (avant tout tool storybook-dev)

  1. Vérifier les terminaux — un process storybook / pnpm … storybook doit tourner et écouter sur 6007 (pas seulement le MCP configuré dans mcp.json).
  2. Si absent → demander au dev de lancer Storybook avant d'appeler un tool storybook-dev (ne pas lancer soi-même sans accord explicite) :
pnpm --filter @bricks-common/storybook storybook
  1. Si présent mais MCP échoue quand même (story introuvable, import error) → signaler l'erreur au dev ; un restart du dev server peut être nécessaire après ajout de glob / nouveau fichier stories.

Si l'appel MCP échoue

  1. Tool … list-all-documentation was not found → appel sur le mauvais serveur (storybook Chromatic au lieu de storybook-dev) ou dev server arrêté. Toujours cibler le serveur storybook-dev pour cet outil.
  2. Ne pas simuler le résultat ni basculer sur storybook (Chromatic) pour les tools exclusifs storybook-dev — Chromatic n'expose pas list-all-documentation, get-storybook-story-instructions, run-story-tests, preview-stories.
  3. Demander au dev de lancer Storybook en local (commande ci-dessus), puis réessayer.
  4. En attendant : get-documentation / get-documentation-for-story via storybook Chromatic si l'ID composant est déjà connu — jamais pour valider des changements locaux.

Réflexe UI

Avant d'utiliser, créer ou modifier un composant storybook-isé → appeler le MCP Storybook d'abord. Ne jamais inventer une prop uimmo sans preuve dans la doc MCP.

Docs (avant d'écrire du JSX)

Préférer storybook-dev si le server tourne (doc alignée sur le code actuel). Chromatic = fallback lecture seule quand l'ID est déjà connu.

  1. list-all-documentation — storybook-dev only — inventaire + story IDs (withStoryIds: true)
  2. get-documentation — props, exemples (les deux serveurs)
  3. get-documentation-for-story — détail d'une story (les deux serveurs)

Ne pas déduire une prop depuis le nom ou d'autres libs — uniquement doc ou story exemple. Sinon → demander au dev.

Stories (avant d'écrire / modifier un .stories.tsx)

→ get-storybook-story-instructions sur storybook-dev si disponible.

Conventions monorepo : front-conventions.mdc section Storybook.

Tests — boucle TDD (storybook-dev only)

Pre-flight terminaux OK → run-story-tests après chaque changement composant ou story.

  • Itération : stories avec une story (ou le petit lot touché)
  • { storyId: "uimmo-forms-formshowcase--flow-success" } (préféré)
  • ou { absoluteStoryPath, exportName }
  • Handoff : omettre stories pour passe complète
  • Échec → corriger → re-run la même story jusqu'au vert
  • a11y: false OK en itération rapide

Ne pas lancer vitest run sur tout le projet en boucle si le MCP ciblé suffit.

Previews (storybook-dev only)

Pre-flight terminaux OK → preview-stories après changement UI/story + URLs localhost:6007 dans la réponse.

Ordre de priorité contexte UI

  1. Cursor rules front (front-conventions, front-domain-map)
  2. Storybook MCP (props réelles, stories, tests)
  3. Bricks Intel MCP (get-component-usage — deprecated / maturité uimmo)
  4. Grep — dernier recours