diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 350a09788..3cf0db7f6 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -34,11 +34,11 @@ "./src/bmm-skills/plan/bmad-sprint-planning", "./src/bmm-skills/plan/bmad-ux", "./src/bmm-skills/ship/bmad-build", - "./src/bmm-skills/ship/bmad-checkpoint-preview", "./src/bmm-skills/ship/bmad-code-review", "./src/bmm-skills/ship/bmad-correct-course", "./src/bmm-skills/ship/bmad-qa-generate-e2e-tests", "./src/bmm-skills/ship/bmad-retrospective", + "./src/bmm-skills/ship/bmad-walkthrough", "./src/core-skills/bmad-advanced-elicitation", "./src/core-skills/bmad-brainstorming", "./src/core-skills/bmad-customize", diff --git a/docs/build/build-a-change.md b/docs/build/build-a-change.md index c493deb2b..e8901dfc4 100644 --- a/docs/build/build-a-change.md +++ b/docs/build/build-a-change.md @@ -101,7 +101,7 @@ patching only the diff. When it finishes, `bmad-build` shows you the completed change and its review notes. This is the main checkpoint. For a guided walkthrough of the finished -work, see [Checkpoint a Change](checkpoint-a-change.md). +work, see [Walk Through a Change](walk-through-a-change.md). - Skim the diff to confirm the change matches your intent - If something looks off, tell the agent what to fix — it can iterate in the diff --git a/docs/build/test-completed-work.md b/docs/build/test-completed-work.md index 39f13a7d7..cfb1a3540 100644 --- a/docs/build/test-completed-work.md +++ b/docs/build/test-completed-work.md @@ -13,7 +13,7 @@ or a release gate, install the Test Architect (TEA) module instead. See [how a run works](#run-bmad-qa-generate-e2e-tests). This is generated coverage of finished work. It is not code review, and it -is not the manual observations in [Checkpoint a Change](checkpoint-a-change.md). +is not the manual observations in [Walk Through a Change](walk-through-a-change.md). ## Which Path? @@ -106,6 +106,6 @@ finished work, or step up to TEA. You can run built-in QA after one change. You do not have to wait for an epic to finish. A typical sequence is implement with `bmad-build`, -optionally [walk through the result](checkpoint-a-change.md), then generate +optionally [walk through the result](walk-through-a-change.md), then generate coverage here. After a whole epic, `bmad-retrospective` is a different check — it judges the epic against its spec, not the test suite. diff --git a/docs/build/checkpoint-a-change.md b/docs/build/walk-through-a-change.md similarity index 81% rename from docs/build/checkpoint-a-change.md rename to docs/build/walk-through-a-change.md index c219a57cd..8dcdc2d74 100644 --- a/docs/build/checkpoint-a-change.md +++ b/docs/build/walk-through-a-change.md @@ -1,14 +1,13 @@ --- -title: 'Checkpoint a Change' -description: Use bmad-checkpoint-preview to walk through a finished change and decide whether to approve, rework, or discuss further. +title: 'Walk Through a Change' +description: Use bmad-walkthrough to walk through a finished change and decide whether to approve, rework, or discuss further. sidebar: order: 2 --- -`bmad-checkpoint-preview` walks you through a finished change — from -purpose and context into details — so you can decide whether to approve, -rework, or discuss further. See -[how a run works](#run-bmad-checkpoint-preview). +`bmad-walkthrough` walks you through a finished change — from purpose and +context into details — so you can decide whether to approve, rework, or +discuss further. See [how a run works](#run-bmad-walkthrough). This is human comprehension, not a substitute for the review `bmad-build` already ran, or for `bmad-code-review`. @@ -17,9 +16,9 @@ already ran, or for `bmad-code-review`. The primary handoff is from [`bmad-build`](build-a-change.md). Implementation is done, the spec file is open with a review trail appended, -and you need to decide whether to ship. Say "checkpoint" and go. +and you need to decide whether to ship. Say "walkthrough" and go. -Build runs long with little supervision. Checkpoint is where you take back +Build runs long with little supervision. Walkthrough is where you take back the wheel. You could eyeball the diff, but once the change spans many files you lose the thread, miss a connection, or approve something you did not fully understand. A raw diff presents files in git order, which is almost @@ -34,25 +33,25 @@ It also works standalone: - **Sprint review** — the workflow can pick up stories marked `review` in your sprint status file -Invoke it by saying "checkpoint" or "walk me through this change." It works +Invoke it by saying "walkthrough" or "walk me through this change." It works in any terminal, but you'll get more out of it inside an IDE — VS Code, Cursor, or similar — because it produces `path:line` references at every step. In an IDE-embedded terminal those are clickable. -## Run `bmad-checkpoint-preview` +## Run `bmad-walkthrough` -![bmad-checkpoint-preview workflow diagram](/diagrams/checkpoint-preview-diagram.png) +![bmad-walkthrough workflow diagram](/diagrams/walkthrough-diagram.png) -After `bmad-build` finishes, you can say "checkpoint" in the same chat. To -review something else, start a fresh chat and run `/bmad-checkpoint-preview` -with a PR, branch, spec path, or the current git state. +After `bmad-build` finishes, you can say "walkthrough" in the same chat. To +review something else, start a fresh chat and run `/bmad-walkthrough` with a +PR, branch, spec path, or the current git state. ```text -checkpoint +walkthrough ``` ```text -/bmad-checkpoint-preview Review https://github.com/org/repo/pull/42 +/bmad-walkthrough Review https://github.com/org/repo/pull/42 ``` The workflow has five steps. Each one builds on the last, shifting from @@ -133,7 +132,7 @@ perspective: - **"run code review"** — generate structured agentic findings with adversarial and edge-case analysis -The checkpoint workflow doesn't lock you into a linear path. It gives you +The walkthrough workflow doesn't lock you into a linear path. It gives you structure when you want it and gets out of the way when you want to explore. The five steps are there to make sure you see the whole picture, but how deep you go at each step — and what tools you bring in — is entirely up to @@ -151,8 +150,8 @@ author-produced one, but far better than reading changes in file order. ## What It Is Not -`bmad-checkpoint-preview` is not the review skill. It does not replace the -review `bmad-build` already ran, a re-invoke of that run on a done story, or +`bmad-walkthrough` is not the review skill. It does not replace the review +`bmad-build` already ran, a re-invoke of that run on a done story, or `bmad-code-review`. It does not run linters, type checkers, or test suites. It does not assign severity scores or produce pass/fail verdicts. It is a reading guide that helps a human apply their judgment where it matters most. diff --git a/docs/fr/explanation/checkpoint-preview.md b/docs/fr/build/walk-through-a-change.md similarity index 77% rename from docs/fr/explanation/checkpoint-preview.md rename to docs/fr/build/walk-through-a-change.md index 6bc2fd501..ea784ada1 100644 --- a/docs/fr/explanation/checkpoint-preview.md +++ b/docs/fr/build/walk-through-a-change.md @@ -1,21 +1,21 @@ --- -title: "Checkpoint Preview" +title: "Parcourir un changement" description: Revue assistée par LLM, avec intervention humaine, qui vous guide à travers une modification, de son objectif jusqu’aux détails sidebar: - order: 8 + order: 1 --- -`bmad-checkpoint-preview` est un workflow de revue interactif, assisté par LLM, avec intervention humaine. Il vous guide à travers une modification de code — de l’intention et du contexte jusqu’aux détails — afin que vous puissiez prendre une décision éclairée sur la mise en production, la refonte ou l’approfondissement. +`bmad-walkthrough` est un workflow de revue interactif, assisté par LLM, avec intervention humaine. Il vous guide à travers une modification de code — de l’intention et du contexte jusqu’aux détails — afin que vous puissiez prendre une décision éclairée sur la mise en production, la refonte ou l’approfondissement. -![Diagramme du workflow Checkpoint Preview](/diagrams/checkpoint-preview-diagram-fr.webp) +![Diagramme du workflow Walkthrough](/diagrams/walkthrough-diagram-fr.webp) ## Le Flux Typique Vous lancez `bmad-build`. Il clarifie votre intention, construit une spécification, implémente la modification, et une fois terminé, il ajoute un historique de revue au fichier de spécification et l’ouvre dans votre éditeur. Vous regardez la spec et constatez que la modification a touché 20 fichiers dans plusieurs modules. -Vous pourriez survoler le diff. Mais 20 fichiers, c’est le moment où le survol commence à échouer — on perd le fil, on rate un lien entre deux modifications éloignées, ou on approuve quelque chose qu’on n’a pas pleinement compris. Alors au lieu de cela, vous dites « checkpoint » et le LLM vous guide à travers la modification. +Vous pourriez survoler le diff. Mais 20 fichiers, c’est le moment où le survol commence à échouer — on perd le fil, on rate un lien entre deux modifications éloignées, ou on approuve quelque chose qu’on n’a pas pleinement compris. Alors au lieu de cela, vous dites « walkthrough » et le LLM vous guide à travers la modification. -Ce passage de relais — de l’implémentation autonome au jugement humain — est le cas d’usage principal. Build s’exécute longtemps avec une supervision minimale. Checkpoint Preview, c’est là où vous reprenez le volant. +Ce passage de relais — de l’implémentation autonome au jugement humain — est le cas d’usage principal. Build s’exécute longtemps avec une supervision minimale. Le Walkthrough, c’est là où vous reprenez le volant. ## Pourquoi @@ -23,7 +23,7 @@ La revue de code a deux modes d’échec. Dans le premier, le réviseur survole Le problème sous-jacent est le séquençage. Un diff brut présente les modifications dans l’ordre des fichiers, ce qui est presque jamais l’ordre qui construit la compréhension. Vous voyez une fonction utilitaire avant de savoir pourquoi elle existe. Vous voyez une modification de schéma avant de comprendre quelle fonctionnalité elle supporte. Le réviseur doit reconstruire l’intention de l’auteur à partir d’indices dispersés, et c’est cette reconstruction qui fait défaut à l’attention. -Checkpoint Preview résout ce problème en confiant le travail de reconstruction au LLM. Il lit le diff, la spécification (si elle existe) et la base de code environnante, puis présente la modification dans un ordre conçu pour la compréhension — et non pour `git diff`. +Le Walkthrough résout ce problème en confiant le travail de reconstruction au LLM. Il lit le diff, la spécification (si elle existe) et la base de code environnante, puis présente la modification dans un ordre conçu pour la compréhension — et non pour `git diff`. ## Comment ça fonctionne @@ -67,7 +67,7 @@ Le workflow présente chaque étape comme un point de départ, pas un mot final. - **« active le party mode sur la sécurité de cette migration de schéma »** — fait intervenir plusieurs perspectives agentiques dans un débat ciblé - **« lance la revue de code »** — génère des résultats structurés avec analyse adversariale et cas limites -Le workflow checkpoint ne vous enferme pas dans un chemin linéaire. Il vous donne de la structure quand vous la souhaitez et s’efface quand vous voulez explorer. Les cinq étapes sont là pour s’assurer que vous voyez le tableau complet, mais la profondeur à laquelle vous allez à chaque étape — et les outils que vous y apportez — est entièrement entre vos mains. +Le workflow Walkthrough ne vous enferme pas dans un chemin linéaire. Il vous donne de la structure quand vous la souhaitez et s’efface quand vous voulez explorer. Les cinq étapes sont là pour s’assurer que vous voyez le tableau complet, mais la profondeur à laquelle vous allez à chaque étape — et les outils que vous y apportez — est entièrement entre vos mains. ## L’historique de revue @@ -77,7 +77,7 @@ Lorsqu’aucun historique produit par l’auteur n’existe, le workflow en gén ## Quand l’utiliser -Le scénario principal est le passage de relais depuis `bmad-build` : l’implémentation est terminée, le fichier de spécification est ouvert dans votre éditeur avec un historique de revue ajouté, et vous devez décider si vous publiez. Dites « checkpoint » et c’est parti. +Le scénario principal est le passage de relais depuis `bmad-build` : l’implémentation est terminée, le fichier de spécification est ouvert dans votre éditeur avec un historique de revue ajouté, et vous devez décider si vous publiez. Dites « walkthrough » et c’est parti. Il fonctionne aussi de manière autonome : @@ -85,8 +85,8 @@ Il fonctionne aussi de manière autonome : - **Prise en main d’une modification** — quand vous devez comprendre ce qui s’est passé sur une branche que vous n’avez pas écrite - **Revue de sprint** — le workflow peut récupérer les stories marquées `review` dans votre fichier de statut de sprint -Invoquez-le en disant « checkpoint » ou « guide-moi à travers cette modification ». Il fonctionne dans n’importe quel terminal, mais vous en tirerez plus de parti dans un IDE — VS Code, Cursor ou similaire — car le workflow produit des références `chemin:ligne` à chaque étape. Dans un terminal intégré à un IDE, celles-ci sont cliquables, ce qui vous permet de sauter de fichier en fichier en suivant l’historique de revue. +Invoquez-le en disant « walkthrough » ou « guide-moi à travers cette modification ». Il fonctionne dans n’importe quel terminal, mais vous en tirerez plus de parti dans un IDE — VS Code, Cursor ou similaire — car le workflow produit des références `chemin:ligne` à chaque étape. Dans un terminal intégré à un IDE, celles-ci sont cliquables, ce qui vous permet de sauter de fichier en fichier en suivant l’historique de revue. ## Ce que ce n’est pas -Checkpoint Preview ne remplace pas la revue automatisée. Il ne lance pas de linters, de vérificateurs de types ou de suites de tests. Il n’attribue pas de scores de sévérité et ne produit pas de verdicts pass/échec. C’est un guide de lecture qui aide un humain à appliquer son jugement là où cela compte le plus. +Le Walkthrough ne remplace pas la revue automatisée. Il ne lance pas de linters, de vérificateurs de types ou de suites de tests. Il n’attribue pas de scores de sévérité et ne produit pas de verdicts pass/échec. C’est un guide de lecture qui aide un humain à appliquer son jugement là où cela compte le plus. diff --git a/docs/fr/explanation/established-projects-faq.md b/docs/fr/explanation/established-projects-faq.md index 7114f3401..4df547175 100644 --- a/docs/fr/explanation/established-projects-faq.md +++ b/docs/fr/explanation/established-projects-faq.md @@ -2,7 +2,7 @@ title: "FAQ Projets Existants" description: Questions courantes sur l’utilisation de la méthode BMad sur des projets existants sidebar: - order: 11 + order: 10 --- Réponses rapides aux questions courantes sur l’utilisation de la méthode BMad (BMM) sur des projets existants. diff --git a/docs/fr/explanation/party-mode.md b/docs/fr/explanation/party-mode.md index 379a42f59..1f5190101 100644 --- a/docs/fr/explanation/party-mode.md +++ b/docs/fr/explanation/party-mode.md @@ -2,7 +2,7 @@ title: "Party Mode" description: Collaboration multi-agents - regroupez tous vos agents IA dans une seule conversation sidebar: - order: 9 + order: 8 --- Regroupez tous vos agents IA dans une seule conversation. diff --git a/docs/fr/explanation/project-context.md b/docs/fr/explanation/project-context.md index 12640fe2a..bf54ec5f3 100644 --- a/docs/fr/explanation/project-context.md +++ b/docs/fr/explanation/project-context.md @@ -2,7 +2,7 @@ title: "Contexte du Projet" description: Comment project-context.md guide les agents IA avec les règles et préférences de votre projet sidebar: - order: 10 + order: 9 --- Le fichier `project-context.md` est le guide d’implémentation de votre projet pour les agents IA. Similaire à une « constitution » dans d’autres systèmes de développement, il capture les règles, les patterns et les préférences qui garantissent une génération de code cohérente à travers tous les workflows. diff --git a/docs/vi-vn/explanation/checkpoint-preview.md b/docs/vi-vn/build/walk-through-a-change.md similarity index 78% rename from docs/vi-vn/explanation/checkpoint-preview.md rename to docs/vi-vn/build/walk-through-a-change.md index 9e454d285..5fe0564a7 100644 --- a/docs/vi-vn/explanation/checkpoint-preview.md +++ b/docs/vi-vn/build/walk-through-a-change.md @@ -1,21 +1,21 @@ --- -title: "Xem trước Checkpoint" +title: "Đi qua một thay đổi" description: Review có người trong vòng lặp với hỗ trợ của LLM, dẫn bạn đi qua thay đổi từ mục đích đến chi tiết sidebar: - order: 8 + order: 1 --- -`bmad-checkpoint-preview` là một workflow review tương tác có người trong vòng lặp với hỗ trợ của LLM. Nó dẫn bạn đi qua một thay đổi mã nguồn, từ mục đích và bối cảnh đến các chi tiết quan trọng, để bạn có thể quyết định có nên phát hành, làm lại, hay đào sâu thêm. +`bmad-walkthrough` là một workflow review tương tác có người trong vòng lặp với hỗ trợ của LLM. Nó dẫn bạn đi qua một thay đổi mã nguồn, từ mục đích và bối cảnh đến các chi tiết quan trọng, để bạn có thể quyết định có nên phát hành, làm lại, hay đào sâu thêm. -![Sơ đồ workflow Checkpoint Preview](/diagrams/checkpoint-preview-diagram.png) +![Sơ đồ workflow Walkthrough](/diagrams/walkthrough-diagram.png) ## Luồng điển hình Bạn chạy `bmad-build`. Nó làm rõ ý định của bạn, dựng spec, triển khai thay đổi, rồi khi xong sẽ nối thêm một review trail vào file spec và mở file đó trong editor. Bạn nhìn vào spec và thấy thay đổi này chạm tới 20 file, trải trên nhiều module. -Bạn có thể tự liếc diff. Nhưng khoảng 20 file là lúc cách đó bắt đầu kém hiệu quả: bạn mất mạch, bỏ sót liên hệ giữa hai thay đổi ở xa nhau, hoặc duyệt một thứ mà bạn chưa thực sự hiểu. Thay vì vậy, bạn nói "checkpoint" và LLM sẽ dẫn bạn đi qua thay đổi. +Bạn có thể tự liếc diff. Nhưng khoảng 20 file là lúc cách đó bắt đầu kém hiệu quả: bạn mất mạch, bỏ sót liên hệ giữa hai thay đổi ở xa nhau, hoặc duyệt một thứ mà bạn chưa thực sự hiểu. Thay vì vậy, bạn nói "walkthrough" và LLM sẽ dẫn bạn đi qua thay đổi. -Điểm bàn giao đó, từ triển khai tự động quay lại phán đoán của con người, chính là tình huống sử dụng chính. Build có thể chạy khá lâu với rất ít giám sát. Checkpoint Preview là nơi bạn cầm lại tay lái. +Điểm bàn giao đó, từ triển khai tự động quay lại phán đoán của con người, chính là tình huống sử dụng chính. Build có thể chạy khá lâu với rất ít giám sát. Walkthrough là nơi bạn cầm lại tay lái. ## Vì sao nó tồn tại @@ -23,7 +23,7 @@ Code review có hai kiểu thất bại. Kiểu đầu là người review lư Vấn đề cốt lõi nằm ở thứ tự tiếp nhận. Một raw diff trình bày thay đổi theo thứ tự file, gần như không bao giờ là thứ tự giúp xây dựng hiểu biết. Bạn thấy một helper function trước khi biết vì sao nó tồn tại. Bạn thấy một schema change trước khi hiểu tính năng nào đang dùng nó. Người review phải tự dựng lại ý đồ của tác giả từ những manh mối rời rạc, và chính ở bước dựng lại đó sự tập trung thường bị đứt. -Checkpoint Preview giải quyết việc này bằng cách để LLM làm phần dựng lại. Nó đọc diff, spec nếu có, và codebase xung quanh, rồi trình bày thay đổi theo một thứ tự phục vụ việc hiểu, chứ không theo `git diff`. +Walkthrough giải quyết việc này bằng cách để LLM làm phần dựng lại. Nó đọc diff, spec nếu có, và codebase xung quanh, rồi trình bày thay đổi theo một thứ tự phục vụ việc hiểu, chứ không theo `git diff`. ## Nó hoạt động như thế nào @@ -67,7 +67,7 @@ Workflow trình bày từng bước như một điểm khởi đầu, không ph - **"party mode on whether this schema migration is safe"** - kéo nhiều góc nhìn agent vào một cuộc tranh luận tập trung - **"run code review"** - tạo ra các phát hiện có cấu trúc với phân tích đối kháng và edge case -Workflow checkpoint không khóa bạn vào một đường đi tuyến tính. Nó cho bạn cấu trúc khi bạn cần, và tránh cản đường khi bạn muốn tự khám phá. Năm bước ở đây để bảo đảm bạn nhìn được toàn cảnh, còn việc đi sâu đến mức nào ở mỗi bước và gọi thêm công cụ nào hoàn toàn là do bạn quyết định. +Workflow Walkthrough không khóa bạn vào một đường đi tuyến tính. Nó cho bạn cấu trúc khi bạn cần, và tránh cản đường khi bạn muốn tự khám phá. Năm bước ở đây để bảo đảm bạn nhìn được toàn cảnh, còn việc đi sâu đến mức nào ở mỗi bước và gọi thêm công cụ nào hoàn toàn là do bạn quyết định. ## Lộ trình review (Review Trail) @@ -77,7 +77,7 @@ Nếu không có review trail do tác giả tạo, workflow sẽ tự sinh một ## Khi nào nên dùng -Tình huống chính là bước bàn giao sau `bmad-build`: phần triển khai đã xong, file spec đang mở trong editor với review trail đã được nối thêm, và bạn cần quyết định có nên phát hành hay không. Lúc đó chỉ cần nói "checkpoint" là bắt đầu. +Tình huống chính là bước bàn giao sau `bmad-build`: phần triển khai đã xong, file spec đang mở trong editor với review trail đã được nối thêm, và bạn cần quyết định có nên phát hành hay không. Lúc đó chỉ cần nói "walkthrough" là bắt đầu. Nó cũng hoạt động độc lập: @@ -85,8 +85,8 @@ Nó cũng hoạt động độc lập: - **Làm quen với một thay đổi (onboard to a change)** - khi bạn cần hiểu chuyện gì đã xảy ra trên một branch mà bạn không phải người viết - **Review sprint (sprint review)** - workflow có thể nhặt các story được đánh dấu `review` trong file trạng thái sprint của bạn -Bạn có thể gọi nó bằng cách nói "checkpoint" hoặc "dẫn tôi đi qua thay đổi này". Nó chạy được trong mọi terminal, nhưng sẽ phát huy tốt nhất trong IDE như VS Code, Cursor hoặc công cụ tương tự, vì workflow tạo tham chiếu `path:line` ở mọi bước. Trong terminal tích hợp của IDE, các tham chiếu đó có thể bấm được, nên bạn có thể nhảy qua lại giữa các file khi đi theo review trail. +Bạn có thể gọi nó bằng cách nói "walkthrough" hoặc "dẫn tôi đi qua thay đổi này". Nó chạy được trong mọi terminal, nhưng sẽ phát huy tốt nhất trong IDE như VS Code, Cursor hoặc công cụ tương tự, vì workflow tạo tham chiếu `path:line` ở mọi bước. Trong terminal tích hợp của IDE, các tham chiếu đó có thể bấm được, nên bạn có thể nhảy qua lại giữa các file khi đi theo review trail. ## Nó không phải là gì -Checkpoint Preview không thay thế review tự động. Nó không chạy linter, type checker, hay test suite. Nó không chấm mức độ nghiêm trọng hay đưa ra kết luận pass/fail. Nó là một bản hướng dẫn đọc để giúp con người áp dụng phán đoán của mình vào đúng những chỗ đáng chú ý nhất. +Walkthrough không thay thế review tự động. Nó không chạy linter, type checker, hay test suite. Nó không chấm mức độ nghiêm trọng hay đưa ra kết luận pass/fail. Nó là một bản hướng dẫn đọc để giúp con người áp dụng phán đoán của mình vào đúng những chỗ đáng chú ý nhất. diff --git a/docs/vi-vn/explanation/established-projects-faq.md b/docs/vi-vn/explanation/established-projects-faq.md index 0750b7e38..7d7e6528e 100644 --- a/docs/vi-vn/explanation/established-projects-faq.md +++ b/docs/vi-vn/explanation/established-projects-faq.md @@ -2,7 +2,7 @@ title: "FAQ cho dự án đã tồn tại" description: Các câu hỏi phổ biến khi dùng BMad Method trên dự án đã tồn tại sidebar: - order: 11 + order: 10 --- Các câu trả lời nhanh cho những câu hỏi thường gặp khi làm việc với dự án đã tồn tại bằng BMad Method (BMM). diff --git a/docs/vi-vn/explanation/party-mode.md b/docs/vi-vn/explanation/party-mode.md index 02f65f719..9c5291372 100644 --- a/docs/vi-vn/explanation/party-mode.md +++ b/docs/vi-vn/explanation/party-mode.md @@ -2,7 +2,7 @@ title: "Chế độ Party" description: Cộng tác đa agent - đưa tất cả agent AI vào cùng một cuộc trò chuyện sidebar: - order: 9 + order: 8 --- Đưa tất cả agent AI của bạn vào cùng một cuộc trò chuyện. diff --git a/docs/vi-vn/explanation/project-context.md b/docs/vi-vn/explanation/project-context.md index 50d7388c5..aaa2bba06 100644 --- a/docs/vi-vn/explanation/project-context.md +++ b/docs/vi-vn/explanation/project-context.md @@ -2,7 +2,7 @@ title: "Bối cảnh dự án" description: Cách project-context.md định hướng các agent AI theo quy tắc và ưu tiên của dự án sidebar: - order: 10 + order: 9 --- Tệp `project-context.md` là kim chỉ nam cho việc triển khai của các agent AI trong dự án của bạn. Tương tự như một "bản hiến pháp" trong các hệ thống phát triển khác, nó ghi lại các quy tắc, pattern và ưu tiên giúp việc sinh mã được nhất quán trong mọi workflow. diff --git a/docs/zh-cn/explanation/checkpoint-preview.md b/docs/zh-cn/build/walk-through-a-change.md similarity index 75% rename from docs/zh-cn/explanation/checkpoint-preview.md rename to docs/zh-cn/build/walk-through-a-change.md index c98bcf611..273966414 100644 --- a/docs/zh-cn/explanation/checkpoint-preview.md +++ b/docs/zh-cn/build/walk-through-a-change.md @@ -1,21 +1,21 @@ --- -title: "检查点预览" +title: "走查一个变更" description: LLM 辅助的人机协作审查，引导你从目的到细节逐步走过一个变更 sidebar: - order: 8 + order: 1 --- -`bmad-checkpoint-preview` 是一个交互式的、LLM 辅助的人机协作审查工作流。它带你逐步走过一个代码变更——从目的和上下文到细节——让你能做出知情决策：是发布、返工，还是深入挖掘。 +`bmad-walkthrough` 是一个交互式的、LLM 辅助的人机协作审查工作流。它带你逐步走过一个代码变更——从目的和上下文到细节——让你能做出知情决策：是发布、返工，还是深入挖掘。 -![检查点预览工作流图](/diagrams/checkpoint-preview-diagram.png) +![Walkthrough 工作流图](/diagrams/walkthrough-diagram.png) ## 典型流程 你运行 `bmad-build`。它澄清你的意图、构建规范、实现变更，完成后将审查线索追加到 spec 文件并在编辑器中打开。你查看 spec，发现这次变更涉及跨多个模块的 20 个文件。 -你可以肉眼扫一遍 diff。但 20 个文件正是肉眼审查开始失效的临界点——你会丢失线索，漏掉两个相距甚远的变更之间的关联，或者批准了自己没有完全理解的东西。所以你改为说 "checkpoint"，让 LLM 带你走一遍。 +你可以肉眼扫一遍 diff。但 20 个文件正是肉眼审查开始失效的临界点——你会丢失线索，漏掉两个相距甚远的变更之间的关联，或者批准了自己没有完全理解的东西。所以你改为说 "walkthrough"，让 LLM 带你走一遍。 -这种交接——从自主实现回到人工判断——就是核心使用场景。Build 以最少的监督长时间运行，检查点预览则是你重新掌舵的地方。 +这种交接——从自主实现回到人工判断——就是核心使用场景。Build 以最少的监督长时间运行，Walkthrough 则是你重新掌舵的地方。 ## 为什么需要它 @@ -23,7 +23,7 @@ sidebar: 根本问题在于顺序。原始 diff 按文件顺序呈现变更，而这几乎从来不是构建理解的顺序。你先看到一个辅助函数，却不知道它存在的原因；先看到一个 schema 变更，却不了解它支撑什么功能。审查者必须从零散的线索中重建作者的意图，而这个重建过程正是注意力失效的地方。 -检查点预览通过让 LLM 完成重建工作来解决这个问题。它读取 diff、spec（如果有的话）和周围的代码库，然后按照有利于理解的顺序——而不是 `git diff` 的顺序——呈现变更。 +Walkthrough 通过让 LLM 完成重建工作来解决这个问题。它读取 diff、spec（如果有的话）和周围的代码库，然后按照有利于理解的顺序——而不是 `git diff` 的顺序——呈现变更。 ## 工作原理 @@ -67,7 +67,7 @@ sidebar: - **"party mode on whether this schema migration is safe"** — 引入多个 agent 视角进行聚焦辩论 - **"run code review"** — 生成包含对抗性和边界场景分析的结构化 agentic 审查报告 -检查点工作流不会把你锁在线性路径上。它在你需要结构时提供结构，在你想探索时让开。五个步骤确保你看到全貌，但每一步深入到什么程度——以及调用什么工具——完全由你决定。 +Walkthrough 工作流不会把你锁在线性路径上。它在你需要结构时提供结构，在你想探索时让开。五个步骤确保你看到全貌，但每一步深入到什么程度——以及调用什么工具——完全由你决定。 ## 审查线索 @@ -77,7 +77,7 @@ sidebar: ## 何时使用 -主要场景是 `bmad-build` 的交接：实现完成，spec 文件在编辑器中打开并追加了审查线索，你需要决定是否发布。说 "checkpoint" 即可开始。 +主要场景是 `bmad-build` 的交接：实现完成，spec 文件在编辑器中打开并追加了审查线索，你需要决定是否发布。说 "walkthrough" 即可开始。 它也可以独立使用： @@ -85,8 +85,8 @@ sidebar: - **了解一个变更** — 当你需要理解一个不是你写的分支上发生了什么 - **Sprint 审查** — 工作流可以提取 sprint 状态文件中标记为 `review` 的 story -通过说 "checkpoint" 或 "walk me through this change" 来调用。它在任何终端中都能工作，但在 IDE 中——VS Code、Cursor 或类似工具——你会获得更多，因为工作流在每一步都生成 `path:line` 引用。在嵌入 IDE 的终端中，这些引用是可点击的，你可以沿着审查线索在文件间跳转。 +通过说 "walkthrough" 或 "walk me through this change" 来调用。它在任何终端中都能工作，但在 IDE 中——VS Code、Cursor 或类似工具——你会获得更多，因为工作流在每一步都生成 `path:line` 引用。在嵌入 IDE 的终端中，这些引用是可点击的，你可以沿着审查线索在文件间跳转。 ## 它不是什么 -检查点预览不是自动化审查的替代品。它不运行 linter、类型检查器或测试套件。它不打分也不给出通过/不通过的判定。它是一份阅读指南，帮助人类在最重要的地方运用自己的判断力。 +Walkthrough 不是自动化审查的替代品。它不运行 linter、类型检查器或测试套件。它不打分也不给出通过/不通过的判定。它是一份阅读指南，帮助人类在最重要的地方运用自己的判断力。 diff --git a/docs/zh-cn/explanation/established-projects-faq.md b/docs/zh-cn/explanation/established-projects-faq.md index f17c91094..fe67a5b0a 100644 --- a/docs/zh-cn/explanation/established-projects-faq.md +++ b/docs/zh-cn/explanation/established-projects-faq.md @@ -2,7 +2,7 @@ title: "既有项目常见问题" description: 关于在既有项目上使用 BMad Method 的常见问题 sidebar: - order: 11 + order: 10 --- 关于在 established projects（既有项目）中使用 BMad Method 的高频问题，快速说明如下。 diff --git a/docs/zh-cn/explanation/forge-idea.md b/docs/zh-cn/explanation/forge-idea.md index 0497c7fb2..d66789de7 100644 --- a/docs/zh-cn/explanation/forge-idea.md +++ b/docs/zh-cn/explanation/forge-idea.md @@ -2,7 +2,7 @@ title: "锻造想法" description: 通过人设驱动的对抗式提问来检验想法，直到它被强化、被验证，或廉价地被淘汰 sidebar: - order: 12 + order: 11 --- 把一个半成型的想法拿出来，趁改主意还不用付出代价，就在对话里把它压测一遍。 diff --git a/docs/zh-cn/explanation/party-mode.md b/docs/zh-cn/explanation/party-mode.md index 5d2e18690..1aafd1f9c 100644 --- a/docs/zh-cn/explanation/party-mode.md +++ b/docs/zh-cn/explanation/party-mode.md @@ -2,7 +2,7 @@ title: "派对模式" description: 多智能体协作——将所有 AI 智能体汇聚到一次对话中 sidebar: - order: 9 + order: 8 --- `bmad-party-mode` 用于多角色协作讨论：把 PM、架构、开发、UX 等视角放到同一轮对话里，快速暴露分歧、对齐取舍。 diff --git a/docs/zh-cn/explanation/project-context.md b/docs/zh-cn/explanation/project-context.md index 77242220f..e3ca01e3a 100644 --- a/docs/zh-cn/explanation/project-context.md +++ b/docs/zh-cn/explanation/project-context.md @@ -2,7 +2,7 @@ title: "项目上下文" description: project-context.md 如何使用项目规则和偏好指导 AI 智能体 sidebar: - order: 10 + order: 9 --- `project-context.md` 是面向 AI 智能体的项目级上下文文件。它的定位不是教程步骤，而是“实现约束说明”：把你的技术偏好、架构边界和工程约定沉淀成可复用规则，让不同工作流、不同智能体在多个 `story` 中做出一致决策。 diff --git a/src/bmm-skills/module-help.csv b/src/bmm-skills/module-help.csv index 47424dcf8..2bce376fb 100644 --- a/src/bmm-skills/module-help.csv +++ b/src/bmm-skills/module-help.csv @@ -14,6 +14,6 @@ BMad Method,bmad-create-epics-and-stories,Create Epics and Stories,CE,Break the BMad Method,bmad-sprint-planning,Sprint Planning,SP,"Checks the planning is complete enough to implement (PASS/CONCERNS/FAIL), then generates the sprint status file that implementation agents follow for every story.",,,plan,,,true,implementation_artifacts,sprint status BMad Method,bmad-sprint-planning,Sprint Status,SS,"Summarize sprint progress at any time: risks, open action items, and the recommended next action. Can also validate or repair the tracking file.",status,,anytime,,,false,,status summary BMad Method,bmad-code-review,Code Review,CR,Ad hoc review of any code change. An optional extra check after Build's built-in review.,,,ship,bmad-build,,false,, -BMad Method,bmad-checkpoint-preview,Checkpoint,CK,"Guided walkthrough of a change, from purpose and context into details. Use for human review of commits, branches, or PRs.",,,ship,,,false,, +BMad Method,bmad-walkthrough,Walkthrough,WT,"Guided walkthrough of a change, from purpose and context into details. Use for human review of commits, branches, or PRs.",,,ship,,,false,, BMad Method,bmad-qa-generate-e2e-tests,QA Automation Test,QA,Generate automated API and end-to-end tests for implemented code. Not for code review or story validation — use Code Review for that.,,,ship,bmad-build,,false,implementation_artifacts,test suite BMad Method,bmad-retrospective,Retrospective,ER,"Optional at the end of an epic: review the completed work and lessons learned, and look ahead to the next epic. If major issues surfaced, consider Correct Course.",,,ship,bmad-code-review,,false,implementation_artifacts,retrospective diff --git a/src/bmm-skills/ship/bmad-checkpoint-preview/SKILL.md b/src/bmm-skills/ship/bmad-walkthrough/SKILL.md similarity index 95% rename from src/bmm-skills/ship/bmad-checkpoint-preview/SKILL.md rename to src/bmm-skills/ship/bmad-walkthrough/SKILL.md index 8135610fc..9e94bd873 100644 --- a/src/bmm-skills/ship/bmad-checkpoint-preview/SKILL.md +++ b/src/bmm-skills/ship/bmad-walkthrough/SKILL.md @@ -1,9 +1,9 @@ --- -name: bmad-checkpoint-preview -description: 'Walk the user through reviewing a change: what it is for, what to look at closely, and how to test it. Use when the user says "checkpoint", "human review", or "walk me through this change"' +name: bmad-walkthrough +description: 'Walk the user through reviewing a change: what it is for, what to look at closely, and how to test it. Use when the user says "walkthrough", "walk me through this change", or "human review"' --- -# Checkpoint Review Workflow +# Walkthrough Workflow **Goal:** Guide a human through reviewing a change — from purpose and context into details. diff --git a/src/bmm-skills/ship/bmad-checkpoint-preview/customize.toml b/src/bmm-skills/ship/bmad-walkthrough/customize.toml similarity index 95% rename from src/bmm-skills/ship/bmad-checkpoint-preview/customize.toml rename to src/bmm-skills/ship/bmad-walkthrough/customize.toml index cef03bfea..e0be6bc6c 100644 --- a/src/bmm-skills/ship/bmad-checkpoint-preview/customize.toml +++ b/src/bmm-skills/ship/bmad-walkthrough/customize.toml @@ -1,6 +1,6 @@ # DO NOT EDIT -- overwritten on every update. # -# Workflow customization surface for bmad-checkpoint-preview. Mirrors the +# Workflow customization surface for bmad-walkthrough. Mirrors the # agent customization shape under the [workflow] namespace. [workflow] diff --git a/src/bmm-skills/ship/bmad-checkpoint-preview/generate-trail.md b/src/bmm-skills/ship/bmad-walkthrough/generate-trail.md similarity index 100% rename from src/bmm-skills/ship/bmad-checkpoint-preview/generate-trail.md rename to src/bmm-skills/ship/bmad-walkthrough/generate-trail.md diff --git a/src/bmm-skills/ship/bmad-checkpoint-preview/step-01-orientation.md b/src/bmm-skills/ship/bmad-walkthrough/step-01-orientation.md similarity index 100% rename from src/bmm-skills/ship/bmad-checkpoint-preview/step-01-orientation.md rename to src/bmm-skills/ship/bmad-walkthrough/step-01-orientation.md diff --git a/src/bmm-skills/ship/bmad-checkpoint-preview/step-02-walkthrough.md b/src/bmm-skills/ship/bmad-walkthrough/step-02-walkthrough.md similarity index 100% rename from src/bmm-skills/ship/bmad-checkpoint-preview/step-02-walkthrough.md rename to src/bmm-skills/ship/bmad-walkthrough/step-02-walkthrough.md diff --git a/src/bmm-skills/ship/bmad-checkpoint-preview/step-03-detail-pass.md b/src/bmm-skills/ship/bmad-walkthrough/step-03-detail-pass.md similarity index 100% rename from src/bmm-skills/ship/bmad-checkpoint-preview/step-03-detail-pass.md rename to src/bmm-skills/ship/bmad-walkthrough/step-03-detail-pass.md diff --git a/src/bmm-skills/ship/bmad-checkpoint-preview/step-04-testing.md b/src/bmm-skills/ship/bmad-walkthrough/step-04-testing.md similarity index 100% rename from src/bmm-skills/ship/bmad-checkpoint-preview/step-04-testing.md rename to src/bmm-skills/ship/bmad-walkthrough/step-04-testing.md diff --git a/src/bmm-skills/ship/bmad-checkpoint-preview/step-05-wrapup.md b/src/bmm-skills/ship/bmad-walkthrough/step-05-wrapup.md similarity index 100% rename from src/bmm-skills/ship/bmad-checkpoint-preview/step-05-wrapup.md rename to src/bmm-skills/ship/bmad-walkthrough/step-05-wrapup.md diff --git a/src/bmm-skills/v6-shims/README.md b/src/bmm-skills/v6-shims/README.md index 781d86e71..3581be4a4 100644 --- a/src/bmm-skills/v6-shims/README.md +++ b/src/bmm-skills/v6-shims/README.md @@ -18,6 +18,7 @@ stated intent and pre-resolved customization fields so the target skips its own | `bmad-domain-research` | `bmad-deep-recon` (domain type) | | `bmad-technical-research` | `bmad-deep-recon` (technical type) | | `bmad-sprint-status` | `bmad-sprint-planning` (status view) | +| `bmad-checkpoint-preview` | `bmad-walkthrough` | Enterprise users may still depend on these IDs, so they ship by default. Removal rides the v7 cut — never a 6.x minor. diff --git a/src/bmm-skills/v6-shims/bmad-checkpoint-preview/SKILL.md b/src/bmm-skills/v6-shims/bmad-checkpoint-preview/SKILL.md new file mode 100644 index 000000000..740f4b1cf --- /dev/null +++ b/src/bmm-skills/v6-shims/bmad-checkpoint-preview/SKILL.md @@ -0,0 +1,21 @@ +--- +name: bmad-checkpoint-preview +description: "Deprecated: forwards to bmad-walkthrough. Do not use unless invoked by name" +metadata: + lifecycle: shim +--- + +# Deprecated Walkthrough Alias + +## On Activation + +1. Check whether either legacy customization file exists: + - `{project-root}/_bmad/custom/bmad-checkpoint-preview.toml` + - `{project-root}/_bmad/custom/bmad-checkpoint-preview.user.toml` +2. If neither legacy file exists, output exactly `bmad-checkpoint-preview is deprecated. Redirecting to bmad-walkthrough. Please use bmad-walkthrough in the future.`, invoke `bmad-walkthrough` exactly once with the user's original input verbatim, then execute no further steps in this shim. +3. For every legacy file that exists, use its matching new filename: + - `{project-root}/_bmad/custom/bmad-checkpoint-preview.toml` becomes `{project-root}/_bmad/custom/bmad-walkthrough.toml`. + - `{project-root}/_bmad/custom/bmad-checkpoint-preview.user.toml` becomes `{project-root}/_bmad/custom/bmad-walkthrough.user.toml`. +4. If the matching new file does not exist, tell the user that the customization file uses the deprecated name and offer to rename it. Rename it only after explicit approval. If approval is declined or unavailable, or the rename fails, HALT and do not invoke any skill. +5. If the matching new file already exists, do not overwrite it. Read both files, explain their differences, and propose the exact content for the new file. Resolve conflicting values with the user. Only after the user explicitly approves that content, save and verify the new file, then remove the legacy file. If approval is declined or unavailable, or any operation fails, HALT and do not invoke any skill. +6. After every detected legacy file has been migrated successfully and no legacy file remains, output exactly `bmad-checkpoint-preview is deprecated. Redirecting to bmad-walkthrough. Please use bmad-walkthrough in the future.`, invoke `bmad-walkthrough` exactly once with the user's original input verbatim, then execute no further steps in this shim. diff --git a/website/astro.config.mjs b/website/astro.config.mjs index 6af244b1e..d1a10e5c2 100644 --- a/website/astro.config.mjs +++ b/website/astro.config.mjs @@ -22,8 +22,12 @@ export default defineConfig({ '/tutorials/getting-started': `${basePath}start/build-your-first-change/`, '/how-to/quick-fixes': `${basePath}build/build-a-change/`, '/explanation/build': `${basePath}build/build-a-change/`, - '/explanation/checkpoint-preview': `${basePath}build/checkpoint-a-change/`, - '/build/review-a-completed-change': `${basePath}build/checkpoint-a-change/`, + '/explanation/checkpoint-preview': `${basePath}build/walk-through-a-change/`, + '/build/review-a-completed-change': `${basePath}build/walk-through-a-change/`, + '/build/checkpoint-a-change': `${basePath}build/walk-through-a-change/`, + '/fr/explanation/checkpoint-preview': `${basePath}fr/build/walk-through-a-change/`, + '/vi-vn/explanation/checkpoint-preview': `${basePath}vi-vn/build/walk-through-a-change/`, + '/zh-cn/explanation/checkpoint-preview': `${basePath}zh-cn/build/walk-through-a-change/`, '/reference/testing': `${basePath}build/test-completed-work/`, '/fr/how-to/non-interactive-installation': `${basePath}fr/how-to/install-bmad/`, '/cs/how-to/non-interactive-installation': `${basePath}cs/how-to/install-bmad/`, @@ -149,14 +153,14 @@ export default defineConfig({ slug: 'build/build-a-change', }, { - label: 'Checkpoint a Change', + label: 'Walk Through a Change', translations: { - 'vi-VN': 'Checkpoint một thay đổi', - 'zh-CN': 'Checkpoint 一个变更', - 'fr-FR': 'Checkpoint d’un changement', - 'cs-CZ': 'Checkpoint změny', + 'vi-VN': 'Đi qua một thay đổi', + 'zh-CN': '走查一个变更', + 'fr-FR': 'Parcourir un changement', + 'cs-CZ': 'Projít změnu', }, - slug: 'build/checkpoint-a-change', + slug: 'build/walk-through-a-change', }, { label: 'Test Completed Work', diff --git a/website/public/diagrams/checkpoint-preview-diagram-fr.webp b/website/public/diagrams/checkpoint-preview-diagram-fr.webp deleted file mode 100644 index caa0ac09b..000000000 Binary files a/website/public/diagrams/checkpoint-preview-diagram-fr.webp and /dev/null differ diff --git a/website/public/diagrams/checkpoint-preview-diagram.png b/website/public/diagrams/checkpoint-preview-diagram.png deleted file mode 100644 index a7e67adda..000000000 Binary files a/website/public/diagrams/checkpoint-preview-diagram.png and /dev/null differ diff --git a/website/public/diagrams/walkthrough-diagram-fr.webp b/website/public/diagrams/walkthrough-diagram-fr.webp new file mode 100644 index 000000000..e0c19b5d6 Binary files /dev/null and b/website/public/diagrams/walkthrough-diagram-fr.webp differ diff --git a/website/public/diagrams/walkthrough-diagram.png b/website/public/diagrams/walkthrough-diagram.png new file mode 100644 index 000000000..d0d01c051 Binary files /dev/null and b/website/public/diagrams/walkthrough-diagram.png differ