Brian
d2b87b849b
* Rename bmad-checkpoint-preview to bmad-walkthrough
"Checkpoint" said nothing about what the skill does and "preview" was wrong: it is a guided human walkthrough of a change, not a preview. Its siblings bmad-code-review and bmad-review already own "review", so the new name leans on what sets this one apart. "Walk me through this change" was already its trigger phrase.
- Skill folder, SKILL.md name/description, module-help.csv (menu code CK -> WT), marketplace.json
- Trigger words are now "walkthrough", "walk me through this change", "human review"; "checkpoint" is dropped
- English how-to page moves to docs/build/walk-through-a-change.md; build-a-change link updated
- fr, vi-vn, zh-cn pages move to docs/<lang>/build/walk-through-a-change.md to mirror the English path; explanation sidebar orders renumbered to close the gap
- Redirects for the old English and localized routes; sidebar label and translations updated
- Diagram assets renamed (image contents unchanged)
* Regenerate walkthrough diagrams with the new title
Title reads Walkthrough and the input box reads bmad-build spec file (was quick-dev, stale since the Build rename). English and French, same layout and style as before.
* Add bmad-checkpoint-preview forwarding shim
Forwards to bmad-walkthrough and offers to migrate legacy _bmad/custom/bmad-checkpoint-preview{,.user}.toml files, same as the other v6 shims.
* Point test-completed-work links at the renamed walkthrough page
3.7 KiB
title, description, sidebar
| title | description | sidebar | ||
|---|---|---|---|---|
| Party Mode | Collaboration multi-agents - regroupez tous vos agents IA dans une seule conversation |
|
Regroupez tous vos agents IA dans une seule conversation.
Qu’est-ce que le Party Mode ?
Lancez bmad-party-mode et vous avez toute votre équipe IA dans une même pièce - PM, Architecte, Développeur, Designer UX, selon vos besoins. Le Party Mode orchestre la discussion en sélectionnant, à chaque message, les agents pertinents parmi ceux installés. Les agents répondent en personnage, sont en accord ou désaccord, et construisent sur les idées des autres.
La conversation continue aussi longtemps que vous le souhaitez. Posez des questions de suivi, remettez en question les réponses, redirigez la discussion - c’est un véritable échange avec vos agents jusqu’à ce que vous ayez terminé.
Idéal pour
- Les grandes décisions avec des compromis
- Les sessions de brainstorming
- Les rétrospectives post-incident quand les choses tournent mal
- Les rétrospectives de sprint et la planification
Exemples
Remettre en question une mauvaise architecture
Vous : « Ok l’équipe, notre dernier sprint a été un désastre. Le service d’authentification est tombé trois fois. Qui a cafouillé ? »
Architecte : « Le design était solide - authentification distribuée avec des fallbacks appropriés. Si l’implémentation a dévié des specs... »
Développeur : « J’ai suivi le document d’architecture à la lettre. Les specs ne prenaient pas en compte les race conditions lors de l’invalidation de sessions concurrentes. »
PM : « Vous avez tous les deux raté le vrai problème - nous n’avons pas validé les exigences de gestion des sessions dans le PRD. C’est de ma faute de ne pas l’avoir repéré. »
TEA : « Et j’aurais dû le repérer dans les tests d’intégration. Les scénarios de test ne couvraient pas l’invalidation concurrente. »
Brainstorming créatif
Vous : « Comment rendre l’onboarding magique au lieu d’ennuyeux ? »
Designer UX : « Commençons par la divulgation progressive - révélons les fonctionnalités au fur et à mesure que les utilisateurs en ont besoin, pas d’un coup dans un tutoriel. »
Storyteller : « Et si l’onboarding était une histoire ? Chaque étape révèle le parcours d’un personnage - l’utilisateur EST le héros. »
Game Designer : « En partant de là - et si la première « quête » consistait à résoudre un vrai problème utilisateur ? Ils apprennent en faisant quelque chose d’utile. »
Décision technique
Vous : « Monolithe ou microservices pour le MVP1 ? »
Architecte : « Commencez en monolithe. Les microservices ajoutent une complexité dont vous n’avez pas besoin à 1 000 utilisateurs. »
PM : « D’accord. Le time-to-market2 compte plus que la scalabilité théorique. »
Développeur : « Monolithe avec des frontières de modules claires. On pourra extraire des services plus tard si nécessaire. »
:::tip[Meilleures décisions] De meilleures décisions grâce à des perspectives diverses. Bienvenue dans le party mode. :::
Glossaire
-
MVP (Minimum Viable Product) : version minimale d’un produit contenant juste assez de fonctionnalités pour être utilisée par des utilisateurs précoces et valider les hypothèses de marché avant d’investir dans un développement plus complet. ↩︎
-
Time-to-market : délai nécessaire pour concevoir, développer et lancer un produit sur le marché. Plus ce délai est court, plus l’entreprise peut prendre de l’avance sur ses concurrents. ↩︎