Merge branch 'main' into claude/read-claude-docs-tNzL8
This commit is contained in:
Theophilus Chinomona
GitHub
commit
ea68a5b649
|
|
@ -1,6 +1,7 @@
|
||||||
# Augment Code Review Guidelines for BMAD-METHOD
|
# Augment Code Review Guidelines for BMAD-METHOD
|
||||||
# https://docs.augmentcode.com/codereview/overview
|
# https://docs.augmentcode.com/codereview/overview
|
||||||
# Focus: Workflow validation and quality
|
# Focus: Skill validation and quality
|
||||||
|
# Canonical rules: tools/skill-validator.md (single source of truth)
|
||||||
|
|
||||||
file_paths_to_ignore:
|
file_paths_to_ignore:
|
||||||
# --- Shared baseline: tool configs ---
|
# --- Shared baseline: tool configs ---
|
||||||
|
|
@ -48,123 +49,17 @@ file_paths_to_ignore:
|
||||||
|
|
||||||
areas:
|
areas:
|
||||||
# ============================================
|
# ============================================
|
||||||
# WORKFLOW STRUCTURE RULES
|
# SKILL FILES
|
||||||
# ============================================
|
# ============================================
|
||||||
workflow_structure:
|
skill_files:
|
||||||
description: "Workflow folder organization and required components"
|
description: "All skill content — SKILL.md, workflow.md, step files, data files, and templates within skill directories"
|
||||||
globs:
|
globs:
|
||||||
|
- "src/**/skills/**"
|
||||||
- "src/**/workflows/**"
|
- "src/**/workflows/**"
|
||||||
|
- "src/**/tasks/**"
|
||||||
rules:
|
rules:
|
||||||
- id: "workflow_entry_point_required"
|
- id: "skill_validation"
|
||||||
description: "Every workflow folder must have workflow.md as entry point"
|
description: "Apply the full rule catalog defined in tools/skill-validator.md. That file is the single source of truth for all skill validation rules covering SKILL.md metadata, workflow.md constraints, step file structure, path references, variable resolution, sequential execution, and skill invocation syntax."
|
||||||
severity: "high"
|
|
||||||
|
|
||||||
- id: "sharded_workflow_steps_folder"
|
|
||||||
description: "Sharded workflows (using workflow.md) must have steps/ folder with numbered files (step-01-*.md, step-02-*.md)"
|
|
||||||
severity: "high"
|
|
||||||
|
|
||||||
- id: "workflow_step_limit"
|
|
||||||
description: "Workflows should have 5-10 steps maximum to prevent context loss in LLM execution"
|
|
||||||
severity: "medium"
|
|
||||||
|
|
||||||
# ============================================
|
|
||||||
# WORKFLOW ENTRY FILE RULES
|
|
||||||
# ============================================
|
|
||||||
workflow_definitions:
|
|
||||||
description: "Workflow entry files (workflow.md)"
|
|
||||||
globs:
|
|
||||||
- "src/**/workflows/**/workflow.md"
|
|
||||||
rules:
|
|
||||||
- id: "workflow_name_required"
|
|
||||||
description: "Workflow entry files must define 'name' field in frontmatter or root element"
|
|
||||||
severity: "high"
|
|
||||||
|
|
||||||
- id: "workflow_description_required"
|
|
||||||
description: "Workflow entry files must include 'description' explaining the workflow's purpose"
|
|
||||||
severity: "high"
|
|
||||||
|
|
||||||
- id: "workflow_installed_path"
|
|
||||||
description: "Workflows should define installed_path for relative file references within the workflow"
|
|
||||||
severity: "medium"
|
|
||||||
|
|
||||||
- id: "valid_step_references"
|
|
||||||
description: "Step file references in workflow entry must point to existing files"
|
|
||||||
severity: "high"
|
|
||||||
|
|
||||||
# ============================================
|
|
||||||
# SHARDED WORKFLOW STEP RULES
|
|
||||||
# ============================================
|
|
||||||
workflow_steps:
|
|
||||||
description: "Individual step files in sharded workflows"
|
|
||||||
globs:
|
|
||||||
- "src/**/workflows/**/steps/step-*.md"
|
|
||||||
rules:
|
|
||||||
- id: "step_goal_required"
|
|
||||||
description: "Each step must clearly state its goal (## STEP GOAL, ## YOUR TASK, or step n='X' goal='...')"
|
|
||||||
severity: "high"
|
|
||||||
|
|
||||||
- id: "step_mandatory_rules"
|
|
||||||
description: "Step files should include MANDATORY EXECUTION RULES section with universal agent behavior rules"
|
|
||||||
severity: "medium"
|
|
||||||
|
|
||||||
- id: "step_context_boundaries"
|
|
||||||
description: "Step files should define CONTEXT BOUNDARIES explaining available context and limits"
|
|
||||||
severity: "medium"
|
|
||||||
|
|
||||||
- id: "step_success_metrics"
|
|
||||||
description: "Step files should include SUCCESS METRICS section with ✅ checkmarks for validation criteria"
|
|
||||||
severity: "medium"
|
|
||||||
|
|
||||||
- id: "step_failure_modes"
|
|
||||||
description: "Step files should include FAILURE MODES section with ❌ marks for anti-patterns to avoid"
|
|
||||||
severity: "medium"
|
|
||||||
|
|
||||||
- id: "step_next_step_reference"
|
|
||||||
description: "Step files should reference the next step file path for sequential execution"
|
|
||||||
severity: "medium"
|
|
||||||
|
|
||||||
- id: "step_no_forward_loading"
|
|
||||||
description: "Steps must NOT load future step files until current step completes - just-in-time loading only"
|
|
||||||
severity: "high"
|
|
||||||
|
|
||||||
- id: "valid_file_references"
|
|
||||||
description: "File path references using {variable}/filename.md must point to existing files"
|
|
||||||
severity: "high"
|
|
||||||
|
|
||||||
- id: "step_naming"
|
|
||||||
description: "Step files must be named step-NN-description.md (e.g., step-01-init.md, step-02-context.md)"
|
|
||||||
severity: "medium"
|
|
||||||
|
|
||||||
- id: "halt_before_menu"
|
|
||||||
description: "Steps presenting user menus ([C] Continue, [a] Advanced, etc.) must HALT and wait for response"
|
|
||||||
severity: "high"
|
|
||||||
|
|
||||||
# ============================================
|
|
||||||
# WORKFLOW CONTENT QUALITY
|
|
||||||
# ============================================
|
|
||||||
workflow_content:
|
|
||||||
description: "Content quality and consistency rules for all workflow files"
|
|
||||||
globs:
|
|
||||||
- "src/**/workflows/**/*.md"
|
|
||||||
rules:
|
|
||||||
- id: "communication_language_variable"
|
|
||||||
description: "Workflows should use {communication_language} variable for agent output language consistency"
|
|
||||||
severity: "low"
|
|
||||||
|
|
||||||
- id: "path_placeholders_required"
|
|
||||||
description: "Use path placeholders (e.g. {project-root}, {installed_path}, {output_folder}) instead of hardcoded paths"
|
|
||||||
severity: "medium"
|
|
||||||
|
|
||||||
- id: "no_time_estimates"
|
|
||||||
description: "Workflows should NOT include time estimates - AI development speed varies significantly"
|
|
||||||
severity: "low"
|
|
||||||
|
|
||||||
- id: "facilitator_not_generator"
|
|
||||||
description: "Workflow agents should act as facilitators (guide user input) not content generators (create without input)"
|
|
||||||
severity: "medium"
|
|
||||||
|
|
||||||
- id: "no_skip_optimization"
|
|
||||||
description: "Workflows must execute steps sequentially - no skipping or 'optimizing' step order"
|
|
||||||
severity: "high"
|
severity: "high"
|
||||||
|
|
||||||
# ============================================
|
# ============================================
|
||||||
|
|
@ -183,27 +78,10 @@ areas:
|
||||||
description: "Agent files must define persona with role, identity, communication_style, and principles"
|
description: "Agent files must define persona with role, identity, communication_style, and principles"
|
||||||
severity: "high"
|
severity: "high"
|
||||||
|
|
||||||
- id: "agent_menu_valid_workflows"
|
- id: "agent_menu_valid_skills"
|
||||||
description: "Menu triggers must reference valid workflow paths that exist"
|
description: "Menu triggers must reference valid skill names that exist"
|
||||||
severity: "high"
|
severity: "high"
|
||||||
|
|
||||||
# ============================================
|
|
||||||
# TEMPLATES
|
|
||||||
# ============================================
|
|
||||||
templates:
|
|
||||||
description: "Template files for workflow outputs"
|
|
||||||
globs:
|
|
||||||
- "src/**/template*.md"
|
|
||||||
- "src/**/templates/**/*.md"
|
|
||||||
rules:
|
|
||||||
- id: "placeholder_syntax"
|
|
||||||
description: "Use {variable_name} or {{variable_name}} syntax consistently for placeholders"
|
|
||||||
severity: "medium"
|
|
||||||
|
|
||||||
- id: "template_sections_marked"
|
|
||||||
description: "Template sections that need generation should be clearly marked (e.g., <!-- GENERATE: section_name -->)"
|
|
||||||
severity: "low"
|
|
||||||
|
|
||||||
# ============================================
|
# ============================================
|
||||||
# DOCUMENTATION
|
# DOCUMENTATION
|
||||||
# ============================================
|
# ============================================
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,74 @@
|
||||||
|
{
|
||||||
|
"name": "bmad-method",
|
||||||
|
"owner": {
|
||||||
|
"name": "Brian (BMad) Madison"
|
||||||
|
},
|
||||||
|
"description": "Breakthrough Method of Agile AI-driven Development — a full-lifecycle framework with agents and workflows for analysis, planning, architecture, and implementation.",
|
||||||
|
"license": "MIT",
|
||||||
|
"homepage": "https://github.com/bmad-code-org/BMAD-METHOD",
|
||||||
|
"repository": "https://github.com/bmad-code-org/BMAD-METHOD",
|
||||||
|
"keywords": ["bmad", "agile", "ai", "orchestrator", "development", "methodology", "agents"],
|
||||||
|
"plugins": [
|
||||||
|
{
|
||||||
|
"name": "bmad-pro-skills",
|
||||||
|
"source": "./",
|
||||||
|
"description": "Next level skills for power users — advanced prompting techniques, agent management, and more.",
|
||||||
|
"version": "6.3.0",
|
||||||
|
"author": {
|
||||||
|
"name": "Brian (BMad) Madison"
|
||||||
|
},
|
||||||
|
"skills": [
|
||||||
|
"./src/core-skills/bmad-help",
|
||||||
|
"./src/core-skills/bmad-brainstorming",
|
||||||
|
"./src/core-skills/bmad-distillator",
|
||||||
|
"./src/core-skills/bmad-party-mode",
|
||||||
|
"./src/core-skills/bmad-shard-doc",
|
||||||
|
"./src/core-skills/bmad-advanced-elicitation",
|
||||||
|
"./src/core-skills/bmad-editorial-review-prose",
|
||||||
|
"./src/core-skills/bmad-editorial-review-structure",
|
||||||
|
"./src/core-skills/bmad-index-docs",
|
||||||
|
"./src/core-skills/bmad-review-adversarial-general",
|
||||||
|
"./src/core-skills/bmad-review-edge-case-hunter"
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"name": "bmad-method-lifecycle",
|
||||||
|
"source": "./",
|
||||||
|
"description": "Full-lifecycle AI development framework — agents and workflows for product analysis, planning, architecture, and implementation.",
|
||||||
|
"version": "6.3.0",
|
||||||
|
"author": {
|
||||||
|
"name": "Brian (BMad) Madison"
|
||||||
|
},
|
||||||
|
"skills": [
|
||||||
|
"./src/bmm-skills/1-analysis/bmad-product-brief",
|
||||||
|
"./src/bmm-skills/1-analysis/bmad-agent-analyst",
|
||||||
|
"./src/bmm-skills/1-analysis/bmad-agent-tech-writer",
|
||||||
|
"./src/bmm-skills/1-analysis/bmad-document-project",
|
||||||
|
"./src/bmm-skills/1-analysis/research/bmad-domain-research",
|
||||||
|
"./src/bmm-skills/1-analysis/research/bmad-market-research",
|
||||||
|
"./src/bmm-skills/1-analysis/research/bmad-technical-research",
|
||||||
|
"./src/bmm-skills/2-plan-workflows/bmad-agent-pm",
|
||||||
|
"./src/bmm-skills/2-plan-workflows/bmad-agent-ux-designer",
|
||||||
|
"./src/bmm-skills/2-plan-workflows/bmad-create-prd",
|
||||||
|
"./src/bmm-skills/2-plan-workflows/bmad-edit-prd",
|
||||||
|
"./src/bmm-skills/2-plan-workflows/bmad-validate-prd",
|
||||||
|
"./src/bmm-skills/2-plan-workflows/bmad-create-ux-design",
|
||||||
|
"./src/bmm-skills/3-solutioning/bmad-agent-architect",
|
||||||
|
"./src/bmm-skills/3-solutioning/bmad-create-architecture",
|
||||||
|
"./src/bmm-skills/3-solutioning/bmad-check-implementation-readiness",
|
||||||
|
"./src/bmm-skills/3-solutioning/bmad-create-epics-and-stories",
|
||||||
|
"./src/bmm-skills/3-solutioning/bmad-generate-project-context",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-agent-dev",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-dev-story",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-quick-dev",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-sprint-planning",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-sprint-status",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-code-review",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-create-story",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-correct-course",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-retrospective",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests"
|
||||||
|
]
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
|
@ -60,23 +60,40 @@ reviews:
|
||||||
- "!**/validation-report-*.md"
|
- "!**/validation-report-*.md"
|
||||||
- "!CHANGELOG.md"
|
- "!CHANGELOG.md"
|
||||||
path_instructions:
|
path_instructions:
|
||||||
- path: "**/*"
|
- path: "src/**"
|
||||||
instructions: |
|
instructions: |
|
||||||
You are a cynical, jaded reviewer with zero patience for sloppy work.
|
Source file changed. Check whether documentation under docs/ needs
|
||||||
This PR was submitted by a clueless weasel and you expect to find problems.
|
a corresponding update — new features, changed behavior, renamed
|
||||||
Be skeptical of everything.
|
concepts, altered CLI flags, or modified configuration options should
|
||||||
Look for what's missing, not just what's wrong.
|
all be reflected in the relevant doc pages. Flag missing or outdated
|
||||||
Use a precise, professional tone — no profanity or personal attacks.
|
docs as a review comment.
|
||||||
|
- path: "src/**/skills/**"
|
||||||
Review with extreme skepticism — assume problems exist.
|
instructions: |
|
||||||
Find at least 10 issues to fix or improve.
|
Skill file. Apply the full rule catalog defined in tools/skill-validator.md.
|
||||||
|
That document is the single source of truth for all skill validation rules
|
||||||
Do NOT:
|
covering SKILL.md metadata, workflow.md constraints, step file structure,
|
||||||
- Comment on formatting, linting, or style
|
path references, variable resolution, sequential execution, and skill
|
||||||
- Give "looks good" passes
|
invocation syntax.
|
||||||
- Anchor on any specific ruleset — reason freely
|
- path: "src/**/workflows/**"
|
||||||
|
instructions: |
|
||||||
If you find zero issues, re-analyze — this is suspicious.
|
Legacy workflow file (pre-skill conversion). Apply the full rule catalog
|
||||||
|
defined in tools/skill-validator.md — the same rules apply to workflows
|
||||||
|
that are being converted to skills.
|
||||||
|
- path: "src/**/tasks/**"
|
||||||
|
instructions: |
|
||||||
|
Task file. Apply the full rule catalog defined in tools/skill-validator.md.
|
||||||
|
- path: "src/**/*.agent.yaml"
|
||||||
|
instructions: |
|
||||||
|
Agent definition file. Check:
|
||||||
|
- Has metadata section with id, name, title, icon, and module
|
||||||
|
- Defines persona with role, identity, communication_style, and principles
|
||||||
|
- Menu triggers reference valid skill names that exist
|
||||||
|
- path: "docs/**/*.md"
|
||||||
|
instructions: |
|
||||||
|
Documentation file. Check internal markdown links point to existing files.
|
||||||
|
- path: "tools/**"
|
||||||
|
instructions: |
|
||||||
|
Build script/tooling. Check error handling and proper exit codes.
|
||||||
chat:
|
chat:
|
||||||
auto_reply: true # Response to mentions in comments, a la @coderabbit review
|
auto_reply: true # Response to mentions in comments, a la @coderabbit review
|
||||||
issue_enrichment:
|
issue_enrichment:
|
||||||
|
|
|
||||||
|
|
@ -5,7 +5,7 @@ on:
|
||||||
branches: [main]
|
branches: [main]
|
||||||
paths:
|
paths:
|
||||||
- "src/**"
|
- "src/**"
|
||||||
- "tools/cli/**"
|
- "tools/installer/**"
|
||||||
- "package.json"
|
- "package.json"
|
||||||
workflow_dispatch:
|
workflow_dispatch:
|
||||||
inputs:
|
inputs:
|
||||||
|
|
@ -120,7 +120,18 @@ jobs:
|
||||||
if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
|
if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
|
||||||
run: |
|
run: |
|
||||||
TAG="v$(node -p 'require("./package.json").version')"
|
TAG="v$(node -p 'require("./package.json").version')"
|
||||||
gh release create "$TAG" --generate-notes
|
VERSION="${TAG#v}"
|
||||||
|
# Extract the current version's section from CHANGELOG.md
|
||||||
|
BODY=$(awk -v ver="$VERSION" '
|
||||||
|
/^## v/ { if (found) exit; if (index($0, "## v" ver)) found=1; next }
|
||||||
|
found { print }
|
||||||
|
' CHANGELOG.md)
|
||||||
|
if [ -z "$BODY" ]; then
|
||||||
|
echo "::warning::No CHANGELOG.md entry for $TAG — falling back to auto-generated notes"
|
||||||
|
gh release create "$TAG" --generate-notes
|
||||||
|
else
|
||||||
|
gh release create "$TAG" --notes "$BODY"
|
||||||
|
fi
|
||||||
env:
|
env:
|
||||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,15 +1,15 @@
|
||||||
name: Quality & Validation
|
name: Quality & Validation
|
||||||
|
|
||||||
# Runs comprehensive quality checks on all PRs:
|
# Runs comprehensive quality checks on all PRs and pushes to main:
|
||||||
# - Prettier (formatting)
|
# - Prettier (formatting)
|
||||||
# - ESLint (linting)
|
# - ESLint (linting)
|
||||||
# - markdownlint (markdown quality)
|
# - markdownlint (markdown quality)
|
||||||
# - Schema validation (YAML structure)
|
|
||||||
# - Agent schema tests (fixture-based validation)
|
|
||||||
# - Installation component tests (compilation)
|
# - Installation component tests (compilation)
|
||||||
# - Bundle validation (web bundle integrity)
|
# Keep this workflow aligned with `npm run quality` in `package.json`.
|
||||||
|
|
||||||
"on":
|
"on":
|
||||||
|
push:
|
||||||
|
branches: [main]
|
||||||
pull_request:
|
pull_request:
|
||||||
branches: ["**"]
|
branches: ["**"]
|
||||||
workflow_dispatch:
|
workflow_dispatch:
|
||||||
|
|
@ -103,14 +103,11 @@ jobs:
|
||||||
- name: Install dependencies
|
- name: Install dependencies
|
||||||
run: npm ci
|
run: npm ci
|
||||||
|
|
||||||
- name: Validate YAML schemas
|
|
||||||
run: npm run validate:schemas
|
|
||||||
|
|
||||||
- name: Run agent schema validation tests
|
|
||||||
run: npm run test:schemas
|
|
||||||
|
|
||||||
- name: Test agent compilation components
|
- name: Test agent compilation components
|
||||||
run: npm run test:install
|
run: npm run test:install
|
||||||
|
|
||||||
- name: Validate file references
|
- name: Validate file references
|
||||||
run: npm run validate:refs
|
run: npm run validate:refs
|
||||||
|
|
||||||
|
- name: Validate skills
|
||||||
|
run: npm run validate:skills
|
||||||
|
|
|
||||||
|
|
@ -17,6 +17,8 @@ npm-debug.log*
|
||||||
# Build output
|
# Build output
|
||||||
build/*.txt
|
build/*.txt
|
||||||
|
|
||||||
|
design-artifacts/
|
||||||
|
|
||||||
# Environment variables
|
# Environment variables
|
||||||
.env
|
.env
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -24,7 +24,6 @@ tools/build-docs.mjs
|
||||||
tools/fix-doc-links.js
|
tools/fix-doc-links.js
|
||||||
tools/validate-doc-links.js
|
tools/validate-doc-links.js
|
||||||
tools/validate-file-refs.js
|
tools/validate-file-refs.js
|
||||||
tools/validate-agent-schema.js
|
|
||||||
|
|
||||||
# Images (branding/marketing only)
|
# Images (branding/marketing only)
|
||||||
banner-bmad-method.png
|
banner-bmad-method.png
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,12 @@
|
||||||
|
# BMAD-METHOD
|
||||||
|
|
||||||
|
Open source framework for structured, agent-assisted software delivery.
|
||||||
|
|
||||||
|
## Rules
|
||||||
|
|
||||||
|
- Use Conventional Commits for every commit.
|
||||||
|
- Before pushing, run `npm ci && npm run quality` on `HEAD` in the exact checkout you are about to push.
|
||||||
|
`quality` mirrors the checks in `.github/workflows/quality.yaml`.
|
||||||
|
|
||||||
|
- Skill validation rules are in `tools/skill-validator.md`.
|
||||||
|
- Deterministic skill checks run via `npm run validate:skills` (included in `quality`).
|
||||||
67
CHANGELOG.md
67
CHANGELOG.md
|
|
@ -1,5 +1,72 @@
|
||||||
# Changelog
|
# Changelog
|
||||||
|
|
||||||
|
## v6.2.2 - 2026-03-25
|
||||||
|
|
||||||
|
### ♻️ Refactoring
|
||||||
|
|
||||||
|
* Modernize module-help CSV to 13-column format with `after`/`before` dependency graph replacing sequence numbers (#2120)
|
||||||
|
* Rewrite bmad-help from procedural 8-step execution to outcome-based skill design (~50% shorter) (#2120)
|
||||||
|
|
||||||
|
### 🐛 Bug Fixes
|
||||||
|
|
||||||
|
* Update bmad-builder module-definition path from `src/module.yaml` to `skills/module.yaml` for bmad-builder v1.2.0 compatibility (#2126)
|
||||||
|
* Fix eslint config to ignore gitignored lock files (#2120)
|
||||||
|
|
||||||
|
### 📚 Documentation
|
||||||
|
|
||||||
|
* Close Epic 4.5 explanation gaps in Chinese (zh-CN): normalize command naming to current `bmad-*` convention and add cross-links across 9 explanation pages (#2102)
|
||||||
|
|
||||||
|
## v6.2.1 - 2026-03-24
|
||||||
|
|
||||||
|
### 🎁 Highlights
|
||||||
|
|
||||||
|
* Full rewrite of code-review skill with sharded step-file architecture, three parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor), and interactive post-review triage (#2007, #2013, #2055)
|
||||||
|
* Quick Dev workflow overhaul: smart intent cascade, self-check gate, VS Code integration, clickable spec links, and spec rename (#2105, #2104, #2039, #2085, #2109)
|
||||||
|
* Add review trail generation with clickable `path:line` stops in spec file (#2033)
|
||||||
|
* Add clickable spec links using spec-file-relative markdown format (#2085, #2049)
|
||||||
|
* Preserve tracking identifiers in spec slug derivation (#2108)
|
||||||
|
* Deterministic skill validator with 19 rules across 6 categories, integrated into CI (#1981, #1982, #2004, #2002, #2051)
|
||||||
|
* Complete French (fr-FR) documentation translation (#2073)
|
||||||
|
* Add Ona platform support (#1968)
|
||||||
|
* Rename tech-spec → spec across templates and all documentation (#2109)
|
||||||
|
|
||||||
|
### 📚 Documentation
|
||||||
|
|
||||||
|
* Complete French (fr-FR) translation of all documentation with workflow diagrams (#2073)
|
||||||
|
* Refine Chinese (zh-CN) documentation: epic stories, how-to guides, getting-started, entry copy, help, anchor links (#2092–#2099, #2072)
|
||||||
|
* Add Chinese translation for core-tools reference (#2002)
|
||||||
|
|
||||||
|
## v6.2.0 - 2026-03-15
|
||||||
|
|
||||||
|
### 🎁 Highlights
|
||||||
|
|
||||||
|
* Fix manifest generation so BMad Builder installs correctly when a module has no agents (#1998)
|
||||||
|
* Prototype preview of bmad-product-brief-preview skill — try `/bmad-product-brief-preview` and share feedback! (#1959)
|
||||||
|
* All skills now use native skill directory format for improved modularity and maintainability (#1931, #1945, #1946, #1949, #1950, #1984, #1985, #1988, #1994)
|
||||||
|
|
||||||
|
### 🎁 Features
|
||||||
|
|
||||||
|
* Rewrite code-review skill with sharded step-file architecture and auto-detect review intent from invocation args (#2007, #2013)
|
||||||
|
* Add inference-based skill validator with comprehensive rules for naming, variables, paths, and invocation syntax (#1981)
|
||||||
|
* Add REF-03 skill invocation language rule and PATH-05 skill encapsulation rule to validator (#2004)
|
||||||
|
|
||||||
|
### 🐛 Bug Fixes
|
||||||
|
|
||||||
|
* Validation pass 2 — fix path, variable, and sequence issues across 32 files (#2008)
|
||||||
|
* Replace broken party-mode workflow refs with skill syntax (#2000)
|
||||||
|
* Improve bmad-help description for accurate trigger matching (#2012)
|
||||||
|
* Point zh-cn doc links to Chinese pages instead of English (#2010)
|
||||||
|
* Validation cleanup for bmad-quick-flow (#1997), 6 skills batch (#1996), bmad-sprint-planning (#1995), bmad-retrospective (#1993), bmad-dev-story (#1992), bmad-create-story (#1991), bmad-code-review (#1990), bmad-create-epics-and-stories (#1989), bmad-create-architecture (#1987), bmad-check-implementation-readiness (#1986), bmad-create-ux-design (#1983), bmad-create-product-brief (#1982)
|
||||||
|
|
||||||
|
### 🔧 Maintenance
|
||||||
|
|
||||||
|
* Normalize skill invocation syntax to `Invoke the skill` pattern repo-wide (#2004)
|
||||||
|
|
||||||
|
### 📚 Documentation
|
||||||
|
|
||||||
|
* Add Chinese translation for core-tools reference (#2002)
|
||||||
|
* Update version hint, TEA module link, and HTTP→HTTPS links in Chinese README (#1922, #1921)
|
||||||
|
|
||||||
## [6.1.0] - 2026-03-12
|
## [6.1.0] - 2026-03-12
|
||||||
|
|
||||||
### Highlights
|
### Highlights
|
||||||
|
|
|
||||||
|
|
@ -6,6 +6,12 @@ Thank you for considering contributing! We believe in **Human Amplification, Not
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
> **Before you write code: talk to us on [Discord](https://discord.gg/gk8jAdXWmj).**
|
||||||
|
>
|
||||||
|
> If your change adds features, restructures code, or touches more than a couple of files, **confirm with a maintainer that it fits**. A large PR out of the blue has a high chance of being closed — regardless of effort invested. A five-minute conversation can save you hours.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## Our Philosophy
|
## Our Philosophy
|
||||||
|
|
||||||
BMad strengthens human-AI collaboration through specialized agents and guided workflows. Every contribution should answer: **"Does this make humans and AI better together?"**
|
BMad strengthens human-AI collaboration through specialized agents and guided workflows. Every contribution should answer: **"Does this make humans and AI better together?"**
|
||||||
|
|
@ -57,15 +63,10 @@ After searching, use the [feature request template](https://github.com/bmad-code
|
||||||
|
|
||||||
## Before Starting Work
|
## Before Starting Work
|
||||||
|
|
||||||
⚠️ **Required before submitting PRs:**
|
| Work Type | Requirement |
|
||||||
|
| ----------------------- | -------------------------------------------------------- |
|
||||||
| Work Type | Requirement |
|
| Typo / small bug fix | Just open the PR |
|
||||||
| ------------- | ---------------------------------------------- |
|
| Feature or large change | Confirm with a maintainer on Discord **before** you start |
|
||||||
| Bug fix | An open issue (create one if it doesn't exist) |
|
|
||||||
| Feature | An open feature request issue |
|
|
||||||
| Large changes | Discussion via issue first |
|
|
||||||
|
|
||||||
**Why?** This prevents wasted effort on work that may not align with project direction.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -83,6 +84,12 @@ Submit PRs to the `main` branch. We use trunk-based development. Every push to `
|
||||||
|
|
||||||
If your change exceeds 800 lines, break it into smaller PRs that can be reviewed independently.
|
If your change exceeds 800 lines, break it into smaller PRs that can be reviewed independently.
|
||||||
|
|
||||||
|
### AI-Generated Code
|
||||||
|
|
||||||
|
Given the nature of this project, we expect most contributions involve AI assistance — that's fine. What we require is **heavy human curation**. You must understand every line you're submitting, have made deliberate choices about what to include, and be able to explain your reasoning.
|
||||||
|
|
||||||
|
We will reject PRs that read like raw LLM output: bulk refactors nobody asked for, unsolicited "improvements" across many files, or changes where the submitter clearly hasn't read the existing code. Using AI to write code is normal here; using AI as a substitute for thinking is not.
|
||||||
|
|
||||||
### New to Pull Requests?
|
### New to Pull Requests?
|
||||||
|
|
||||||
1. **Fork** the repository
|
1. **Fork** the repository
|
||||||
|
|
@ -146,7 +153,6 @@ Keep messages under 72 characters. Each commit = one logical change.
|
||||||
- Web/planning agents can be larger with complex tasks
|
- Web/planning agents can be larger with complex tasks
|
||||||
- Everything is natural language (markdown) — no code in core framework
|
- Everything is natural language (markdown) — no code in core framework
|
||||||
- Use BMad modules for domain-specific features
|
- Use BMad modules for domain-specific features
|
||||||
- Validate YAML schemas: `npm run validate:schemas`
|
|
||||||
- Validate file references: `npm run validate:refs`
|
- Validate file references: `npm run validate:refs`
|
||||||
|
|
||||||
### File-Pattern-to-Validator Mapping
|
### File-Pattern-to-Validator Mapping
|
||||||
|
|
|
||||||
13
README.md
13
README.md
|
|
@ -16,7 +16,7 @@ Traditional AI tools do the thinking for you, producing average results. BMad ag
|
||||||
- **AI Intelligent Help** — Invoke the `bmad-help` skill anytime for guidance on what's next
|
- **AI Intelligent Help** — Invoke the `bmad-help` skill anytime for guidance on what's next
|
||||||
- **Scale-Domain-Adaptive** — Automatically adjusts planning depth based on project complexity
|
- **Scale-Domain-Adaptive** — Automatically adjusts planning depth based on project complexity
|
||||||
- **Structured Workflows** — Grounded in agile best practices across analysis, planning, architecture, and implementation
|
- **Structured Workflows** — Grounded in agile best practices across analysis, planning, architecture, and implementation
|
||||||
- **Specialized Agents** — 12+ domain experts (PM, Architect, Developer, UX, Scrum Master, and more)
|
- **Specialized Agents** — 12+ domain experts (PM, Architect, Developer, UX, and more)
|
||||||
- **Party Mode** — Bring multiple agent personas into one session to collaborate and discuss
|
- **Party Mode** — Bring multiple agent personas into one session to collaborate and discuss
|
||||||
- **Complete Lifecycle** — From brainstorming to deployment
|
- **Complete Lifecycle** — From brainstorming to deployment
|
||||||
|
|
||||||
|
|
@ -79,18 +79,15 @@ BMad Method extends with official modules for specialized domains. Available dur
|
||||||
## Community
|
## Community
|
||||||
|
|
||||||
- [Discord](https://discord.gg/gk8jAdXWmj) — Get help, share ideas, collaborate
|
- [Discord](https://discord.gg/gk8jAdXWmj) — Get help, share ideas, collaborate
|
||||||
- [Subscribe on YouTube](https://www.youtube.com/@BMadCode) — Tutorials, master class, and podcast (launching Feb 2025)
|
- [YouTube](https://youtube.com/@BMadCode) — Tutorials, master class, and more
|
||||||
|
- [X / Twitter](https://x.com/BMadCode)
|
||||||
|
- [Website](https://bmadcode.com)
|
||||||
- [GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) — Bug reports and feature requests
|
- [GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) — Bug reports and feature requests
|
||||||
- [Discussions](https://github.com/bmad-code-org/BMAD-METHOD/discussions) — Community conversations
|
- [Discussions](https://github.com/bmad-code-org/BMAD-METHOD/discussions) — Community conversations
|
||||||
|
|
||||||
## Support BMad
|
## Support BMad
|
||||||
|
|
||||||
BMad is free for everyone — and always will be. If you'd like to support development:
|
BMad is free for everyone and always will be. Star this repo, [buy me a coffee](https://buymeacoffee.com/bmad), or email <contact@bmadcode.com> for corporate sponsorship.
|
||||||
|
|
||||||
- ⭐ Please click the star project icon near the top right of this page
|
|
||||||
- ☕ [Buy Me a Coffee](https://buymeacoffee.com/bmad) — Fuel the development
|
|
||||||
- 🏢 Corporate sponsorship — DM on Discord
|
|
||||||
- 🎤 Speaking & Media — Available for conferences, podcasts, interviews (BM on Discord)
|
|
||||||
|
|
||||||
## Contributing
|
## Contributing
|
||||||
|
|
||||||
|
|
|
||||||
71
README_CN.md
71
README_CN.md
|
|
@ -5,30 +5,30 @@
|
||||||
[](https://nodejs.org)
|
[](https://nodejs.org)
|
||||||
[](https://discord.gg/gk8jAdXWmj)
|
[](https://discord.gg/gk8jAdXWmj)
|
||||||
|
|
||||||
**突破性敏捷 AI 驱动开发方法** — 简称 “BMAD 方法论” ，BMAD方法论是由多个模块生态构成的AI驱动敏捷开发模块系统，这是最佳且最全面的敏捷 AI 驱动开发框架，具备真正的规模自适应人工智能，可适应快速开发，适应企业规模化开发。
|
**筑梦架构（Build More Architect Dreams）** —— 简称 “BMAD 方法”，面向 BMad 模块生态的 AI 驱动敏捷开发方法。它会随项目复杂度调整工作深度，从日常 bug 修复到企业级系统建设都能适配。
|
||||||
|
|
||||||
**100% 免费且开源。** 无付费。无内容门槛。无封闭 Discord。我们赋能每个人，我们将为全球现在在人工智能领域发展的普通人提供公平的学习机会。
|
**100% 免费且开源。** 没有付费墙，没有封闭内容，也没有封闭 Discord。我们希望每个人都能平等获得高质量的人机协作开发方法。
|
||||||
|
|
||||||
## 为什么选择 BMad 方法？
|
## 为什么选择 BMad 方法？
|
||||||
|
|
||||||
传统 AI 工具替你思考，产生平庸的结果。BMad 智能体和辅助工作流充当专家协作者，引导你通过结构化流程，与 AI 的合作发挥最佳思维，产出最有效优秀的结果。
|
传统 AI 工具常常替你思考，结果往往止于“能用”。BMad 通过专业智能体和引导式工作流，让 AI 成为协作者：流程有结构，决策有依据，产出更稳定。
|
||||||
|
|
||||||
- **AI 智能帮助** — 随时使用 `bmad-help` 获取下一步指导
|
- **AI 智能引导** —— 随时调用 `bmad-help` 获取下一步建议
|
||||||
- **规模-领域自适应** — 根据项目复杂度自动调整规划深度
|
- **规模与领域自适应** —— 按项目复杂度自动调整规划深度
|
||||||
- **结构化工作流** — 基于分析、规划、架构和实施的敏捷最佳实践
|
- **结构化工作流** —— 覆盖分析、规划、架构、实施全流程
|
||||||
- **专业智能体** — 12+ 领域专家（PM、架构师、开发者、UX、Scrum Master 等）
|
- **专业角色智能体** —— 提供 PM、架构师、开发者、UX 等 12+ 角色
|
||||||
- **派对模式** — 将多个智能体角色带入一个会话进行协作和讨论
|
- **派对模式** —— 多个智能体可在同一会话协作讨论
|
||||||
- **完整生命周期** — 从想法开始（头脑风暴）到部署发布
|
- **完整生命周期** —— 从头脑风暴一路到交付上线
|
||||||
|
|
||||||
[在 **docs.bmad-method.org** 了解更多](http://docs.bmad-method.org)
|
[在 **docs.bmad-method.org** 了解更多](https://docs.bmad-method.org/zh-cn/)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 🚀 BMad 的下一步是什么？
|
## 🚀 BMad 的下一步是什么？
|
||||||
|
|
||||||
**V6 已到来，我们才刚刚开始！** BMad 方法正在快速发展，包括跨平台智能体团队和子智能体集成、技能架构、BMad Builder v1、开发循环自动化等优化，以及更多正在开发中的功能。
|
**V6 已经上线，而这只是开始。** BMad 仍在快速演进：跨平台智能体团队与子智能体集成、Skills 架构、BMad Builder v1、Dev Loop 自动化等能力都在持续推进。
|
||||||
|
|
||||||
**[📍 查看完整路线图 →](http://docs.bmad-method.org/roadmap/)**
|
**[📍 查看完整路线图 →](https://docs.bmad-method.org/zh-cn/roadmap/)**
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -40,7 +40,7 @@
|
||||||
npx bmad-method install
|
npx bmad-method install
|
||||||
```
|
```
|
||||||
|
|
||||||
> 如果你获得的是过时的测试版，请使用：`npx bmad-method@6.0.1 install`
|
> 想体验最新预发布版本？可使用 `npx bmad-method@next install`。它比默认版本更新更快，也可能更容易发生变化。
|
||||||
|
|
||||||
按照安装程序提示操作，然后在项目文件夹中打开你的 AI IDE（Claude Code、Cursor 等）。
|
按照安装程序提示操作，然后在项目文件夹中打开你的 AI IDE（Claude Code、Cursor 等）。
|
||||||
|
|
||||||
|
|
@ -50,31 +50,30 @@ npx bmad-method install
|
||||||
npx bmad-method install --directory /path/to/project --modules bmm --tools claude-code --yes
|
npx bmad-method install --directory /path/to/project --modules bmm --tools claude-code --yes
|
||||||
```
|
```
|
||||||
|
|
||||||
[查看所有安装选项](http://docs.bmad-method.org/how-to/non-interactive-installation/)
|
[查看非交互式安装选项](https://docs.bmad-method.org/zh-cn/how-to/non-interactive-installation/)
|
||||||
|
|
||||||
> **不确定该做什么？** 运行 `bmad-help` — 它会准确告诉你下一步做什么以及什么是可选的。你也可以问诸如 `bmad-help 我刚刚完成了架构设计，接下来该做什么？` 之类的问题。
|
> **不确定下一步？** 直接问 `bmad-help`。它会告诉你“必做什么、可选什么”，例如：`bmad-help 我刚完成架构设计，接下来做什么？`
|
||||||
|
|
||||||
## 模块
|
## 模块
|
||||||
|
|
||||||
BMad 方法通过官方模块扩展到专业领域。可在安装期间或之后的任何时间使用。
|
BMad 可通过官方模块扩展到不同专业场景。你可以在安装时选择，也可以后续随时补装。
|
||||||
|
|
||||||
| Module | Purpose |
|
| 模块 | 用途 |
|
||||||
| ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
|
| ----------------------------------------------------------------------------------------------------------------- | ---------------------------- |
|
||||||
| **[BMad Method (BMM)](https://github.com/bmad-code-org/BMAD-METHOD)** | 包含 34+ 工作流的核心框架 |
|
| **[BMad Method (BMM)](https://github.com/bmad-code-org/BMAD-METHOD)** | 核心框架，内含 34+ 工作流 |
|
||||||
| **[BMad Builder (BMB)](https://github.com/bmad-code-org/bmad-builder)** | 创建自定义 BMad 智能体和工作流 |
|
| **[BMad Builder (BMB)](https://github.com/bmad-code-org/bmad-builder)** | 创建自定义 BMad 智能体与工作流 |
|
||||||
| **[Test Architect (TEA)](https://github.com/bmad-code-org/tea)** | 基于风险的测试策略和自动化 |
|
| **[Test Architect (TEA)](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)** | 基于风险的测试策略与自动化 |
|
||||||
| **[Game Dev Studio (BMGD)](https://github.com/bmad-code-org/bmad-module-game-dev-studio)** | 游戏开发工作流（Unity、Unreal、Godot） |
|
| **[Game Dev Studio (BMGD)](https://github.com/bmad-code-org/bmad-module-game-dev-studio)** | 游戏开发工作流（Unity/Unreal/Godot） |
|
||||||
| **[Creative Intelligence Suite (CIS)](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)** | 创新、头脑风暴、设计思维 |
|
| **[Creative Intelligence Suite (CIS)](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)** | 创新、头脑风暴、设计思维 |
|
||||||
|
|
||||||
## 文档
|
## 文档
|
||||||
|
|
||||||
[BMad 方法文档站点](http://docs.bmad-method.org) — 教程、指南、概念和参考
|
[BMad 方法文档站点](https://docs.bmad-method.org/zh-cn/) — 教程、指南、概念和参考
|
||||||
|
|
||||||
**快速链接：**
|
**快速链接：**
|
||||||
- [入门教程](http://docs.bmad-method.org/tutorials/getting-started/)
|
- [入门教程](https://docs.bmad-method.org/zh-cn/tutorials/getting-started/)
|
||||||
- [从先前版本升级](http://docs.bmad-method.org/how-to/upgrade-to-v6/)
|
- [从旧版本升级](https://docs.bmad-method.org/zh-cn/how-to/upgrade-to-v6/)
|
||||||
- [测试架构师文档](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
- [测试架构师文档（英文）](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
||||||
|
|
||||||
|
|
||||||
## 社区
|
## 社区
|
||||||
|
|
||||||
|
|
@ -85,9 +84,9 @@ BMad 方法通过官方模块扩展到专业领域。可在安装期间或之后
|
||||||
|
|
||||||
## 支持 BMad
|
## 支持 BMad
|
||||||
|
|
||||||
BMad 对每个人都是免费的 — 并且永远如此。如果你想支持开发：
|
BMad 对所有人免费，而且会一直免费。如果你愿意支持项目发展：
|
||||||
|
|
||||||
- ⭐ 请点击此页面右上角附近的项目星标图标
|
- ⭐ 给仓库点个 Star
|
||||||
- ☕ [请我喝咖啡](https://buymeacoffee.com/bmad) — 为开发提供动力
|
- ☕ [请我喝咖啡](https://buymeacoffee.com/bmad) — 为开发提供动力
|
||||||
- 🏢 企业赞助 — 在 Discord 上私信
|
- 🏢 企业赞助 — 在 Discord 上私信
|
||||||
- 🎤 演讲与媒体 — 可参加会议、播客、采访（在 Discord 上联系 BM）
|
- 🎤 演讲与媒体 — 可参加会议、播客、采访（在 Discord 上联系 BM）
|
||||||
|
|
@ -107,15 +106,3 @@ MIT 许可证 — 详见 [LICENSE](LICENSE)。
|
||||||
[](https://github.com/bmad-code-org/BMAD-METHOD/graphs/contributors)
|
[](https://github.com/bmad-code-org/BMAD-METHOD/graphs/contributors)
|
||||||
|
|
||||||
请参阅 [CONTRIBUTORS.md](CONTRIBUTORS.md) 了解贡献者信息。
|
请参阅 [CONTRIBUTORS.md](CONTRIBUTORS.md) 了解贡献者信息。
|
||||||
|
|
||||||
---
|
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
|
||||||
- **workflow**：工作流。指一系列有序的任务或步骤，用于完成特定目标。
|
|
||||||
- **CI/CD**：持续集成/持续部署。一种自动化软件开发实践，用于频繁集成代码更改并自动部署。
|
|
||||||
- **IDE**：集成开发环境。提供代码编辑、调试、构建等功能的软件开发工具。
|
|
||||||
- **PM**：产品经理。负责产品规划、需求管理和团队协调的角色。
|
|
||||||
- **UX**：用户体验。指用户在使用产品或服务过程中的整体感受和交互体验。
|
|
||||||
- **Scrum Master**：Scrum 主管。敏捷开发 Scrum 框架中的角色，负责促进团队遵循 Scrum 流程。
|
|
||||||
- **PRD**：产品需求文档。详细描述产品功能、需求和规格的文档。
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,110 @@
|
||||||
|
|
||||||
|
|
||||||
|
[](https://www.npmjs.com/package/bmad-method)
|
||||||
|
[](LICENSE)
|
||||||
|
[](https://nodejs.org)
|
||||||
|
[](https://discord.gg/gk8jAdXWmj)
|
||||||
|
|
||||||
|
[English](README.md) | [简体中文](README_CN.md) | Tiếng Việt
|
||||||
|
|
||||||
|
**Build More Architect Dreams** - một mô-đun khung phát triển hướng AI trong hệ sinh thái BMad, có khả năng thích ứng theo quy mô từ sửa lỗi nhỏ đến các hệ thống doanh nghiệp.
|
||||||
|
|
||||||
|
**100% miễn phí và mã nguồn mở.** Không có tường phí. Không có nội dung bị khóa. Không có Discord giới hạn quyền truy cập. Chúng tôi tin vào việc trao quyền cho mọi người, không chỉ cho những ai có thể trả tiền để vào một cộng đồng hay khóa học khép kín.
|
||||||
|
|
||||||
|
## Vì sao chọn BMad Method?
|
||||||
|
|
||||||
|
Các công cụ AI truyền thống thường làm thay phần suy nghĩ của bạn và tạo ra kết quả ở mức trung bình. Các agent chuyên biệt và quy trình làm việc có hướng dẫn của BMad hoạt động như những cộng tác viên chuyên gia, dẫn dắt bạn qua một quy trình có cấu trúc để khai mở tư duy tốt nhất của bạn cùng với AI.
|
||||||
|
|
||||||
|
- **Trợ giúp AI thông minh** - Gọi skill `bmad-help` bất kỳ lúc nào để biết bước tiếp theo
|
||||||
|
- **Thích ứng theo quy mô và miền bài toán** - Tự động điều chỉnh độ sâu lập kế hoạch theo độ phức tạp của dự án
|
||||||
|
- **Quy trình có cấu trúc** - Dựa trên các thực hành tốt nhất của agile xuyên suốt phân tích, lập kế hoạch, kiến trúc và triển khai
|
||||||
|
- **Agent chuyên biệt** - Hơn 12 chuyên gia theo vai trò như PM, Architect, Developer, UX, Scrum Master và nhiều vai trò khác
|
||||||
|
- **Party Mode** - Đưa nhiều persona agent vào cùng một phiên để cộng tác và thảo luận
|
||||||
|
- **Vòng đời hoàn chỉnh** - Từ động não ý tưởng cho đến triển khai
|
||||||
|
|
||||||
|
[Tìm hiểu thêm tại **docs.bmad-method.org**](https://docs.bmad-method.org/vi-vn/)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🚀 Điều gì tiếp theo cho BMad?
|
||||||
|
|
||||||
|
**V6 đã có mặt và đây mới chỉ là khởi đầu!** BMad Method đang phát triển rất nhanh với các cải tiến như đội agent đa nền tảng và tích hợp sub-agent, kiến trúc Skills, BMad Builder v1, tự động hóa vòng lặp phát triển và nhiều thứ khác vẫn đang được xây dựng.
|
||||||
|
|
||||||
|
**[📍 Xem lộ trình đầy đủ →](https://docs.bmad-method.org/vi-vn/roadmap/)**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Bắt đầu nhanh
|
||||||
|
|
||||||
|
**Điều kiện tiên quyết**: [Node.js](https://nodejs.org) v20+
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install
|
||||||
|
```
|
||||||
|
|
||||||
|
> Muốn dùng bản prerelease mới nhất? Hãy dùng `npx bmad-method@next install`. Hãy kỳ vọng mức độ biến động cao hơn bản cài đặt mặc định.
|
||||||
|
|
||||||
|
Làm theo các lời nhắc của trình cài đặt, sau đó mở AI IDE của bạn như Claude Code hoặc Cursor trong thư mục dự án.
|
||||||
|
|
||||||
|
**Cài đặt không tương tác** (cho CI/CD):
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install --directory /path/to/project --modules bmm --tools claude-code --yes
|
||||||
|
```
|
||||||
|
|
||||||
|
[Xem toàn bộ tùy chọn cài đặt](https://docs.bmad-method.org/vi-vn/how-to/non-interactive-installation/)
|
||||||
|
|
||||||
|
> **Chưa chắc nên làm gì?** Hãy hỏi `bmad-help` - nó sẽ cho bạn biết chính xác bước nào tiếp theo và bước nào là tùy chọn. Bạn cũng có thể hỏi kiểu như `bmad-help Tôi vừa hoàn thành phần kiến trúc, tiếp theo tôi cần làm gì?`
|
||||||
|
|
||||||
|
## Mô-đun
|
||||||
|
|
||||||
|
BMad Method có thể được mở rộng bằng các mô-đun chính thức cho những miền chuyên biệt. Chúng có sẵn trong lúc cài đặt hoặc bất kỳ lúc nào sau đó.
|
||||||
|
|
||||||
|
| Module | Mục đích |
|
||||||
|
| ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
|
||||||
|
| **[BMad Method (BMM)](https://github.com/bmad-code-org/BMAD-METHOD)** | Khung lõi với hơn 34 quy trình |
|
||||||
|
| **[BMad Builder (BMB)](https://github.com/bmad-code-org/bmad-builder)** | Tạo agent và quy trình BMad tùy chỉnh |
|
||||||
|
| **[Test Architect (TEA)](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)** | Chiến lược kiểm thử và tự động hóa dựa trên rủi ro |
|
||||||
|
| **[Game Dev Studio (BMGD)](https://github.com/bmad-code-org/bmad-module-game-dev-studio)** | Quy trình phát triển game (Unity, Unreal, Godot) |
|
||||||
|
| **[Creative Intelligence Suite (CIS)](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)** | Đổi mới, động não ý tưởng, tư duy thiết kế |
|
||||||
|
|
||||||
|
## Tài liệu
|
||||||
|
|
||||||
|
[Trang tài liệu BMad Method](https://docs.bmad-method.org/vi-vn/) - bài hướng dẫn, hướng dẫn tác vụ, giải thích khái niệm và tài liệu tham chiếu
|
||||||
|
|
||||||
|
**Liên kết nhanh:**
|
||||||
|
- [Hướng dẫn bắt đầu](https://docs.bmad-method.org/vi-vn/tutorials/getting-started/)
|
||||||
|
- [Nâng cấp từ các phiên bản trước](https://docs.bmad-method.org/vi-vn/how-to/upgrade-to-v6/)
|
||||||
|
- [Tài liệu Test Architect](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
||||||
|
|
||||||
|
## Cộng đồng
|
||||||
|
|
||||||
|
- [Discord](https://discord.gg/gk8jAdXWmj) - Nhận trợ giúp, chia sẻ ý tưởng, cộng tác
|
||||||
|
- [Đăng ký trên YouTube](https://www.youtube.com/@BMadCode) - video hướng dẫn, lớp chuyên sâu và podcast (ra mắt tháng 2 năm 2025)
|
||||||
|
- [GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) - Báo lỗi và yêu cầu tính năng
|
||||||
|
- [Discussions](https://github.com/bmad-code-org/BMAD-METHOD/discussions) - Trao đổi cộng đồng
|
||||||
|
|
||||||
|
## Hỗ trợ BMad
|
||||||
|
|
||||||
|
BMad miễn phí cho tất cả mọi người - và sẽ luôn như vậy. Nếu bạn muốn hỗ trợ quá trình phát triển:
|
||||||
|
|
||||||
|
- ⭐ Hãy nhấn sao cho dự án ở góc trên bên phải của trang này
|
||||||
|
- ☕ [Buy Me a Coffee](https://buymeacoffee.com/bmad) - Tiếp thêm năng lượng cho quá trình phát triển
|
||||||
|
- 🏢 Tài trợ doanh nghiệp - Nhắn riêng trên Discord
|
||||||
|
- 🎤 Diễn thuyết và truyền thông - Sẵn sàng cho hội nghị, podcast, phỏng vấn (BM trên Discord)
|
||||||
|
|
||||||
|
## Đóng góp
|
||||||
|
|
||||||
|
Chúng tôi luôn chào đón đóng góp. Xem [CONTRIBUTING.md](CONTRIBUTING.md) để biết hướng dẫn.
|
||||||
|
|
||||||
|
## Giấy phép
|
||||||
|
|
||||||
|
Giấy phép MIT - xem [LICENSE](LICENSE) để biết chi tiết.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**BMad** và **BMAD-METHOD** là các nhãn hiệu của BMad Code, LLC. Xem [TRADEMARK.md](TRADEMARK.md) để biết chi tiết.
|
||||||
|
|
||||||
|
[](https://github.com/bmad-code-org/BMAD-METHOD/graphs/contributors)
|
||||||
|
|
||||||
|
Xem [CONTRIBUTORS.md](CONTRIBUTORS.md) để biết thông tin về những người đóng góp.
|
||||||
|
|
@ -56,7 +56,7 @@ Critical warnings only — data loss, security issues
|
||||||
| Phase | Name | What Happens |
|
| Phase | Name | What Happens |
|
||||||
| ----- | -------- | -------------------------------------------- |
|
| ----- | -------- | -------------------------------------------- |
|
||||||
| 1 | Analysis | Brainstorm, research *(optional)* |
|
| 1 | Analysis | Brainstorm, research *(optional)* |
|
||||||
| 2 | Planning | Requirements — PRD or tech-spec *(required)* |
|
| 2 | Planning | Requirements — PRD or spec *(required)* |
|
||||||
```
|
```
|
||||||
|
|
||||||
**Skills:**
|
**Skills:**
|
||||||
|
|
@ -148,7 +148,7 @@ your-project/
|
||||||
| ----------------- | ----------------------------- |
|
| ----------------- | ----------------------------- |
|
||||||
| **Index/Landing** | `core-concepts/index.md` |
|
| **Index/Landing** | `core-concepts/index.md` |
|
||||||
| **Concept** | `what-are-agents.md` |
|
| **Concept** | `what-are-agents.md` |
|
||||||
| **Feature** | `quick-flow.md` |
|
| **Feature** | `quick-dev.md` |
|
||||||
| **Philosophy** | `why-solutioning-matters.md` |
|
| **Philosophy** | `why-solutioning-matters.md` |
|
||||||
| **FAQ** | `established-projects-faq.md` |
|
| **FAQ** | `established-projects-faq.md` |
|
||||||
|
|
||||||
|
|
@ -353,7 +353,7 @@ Only for BMad Method and Enterprise tracks. Quick Flow skips to implementation.
|
||||||
|
|
||||||
### Can I change my plan later?
|
### Can I change my plan later?
|
||||||
|
|
||||||
Yes. The SM agent has a `bmad-correct-course` workflow for handling scope changes.
|
Yes. The `bmad-correct-course` workflow handles scope changes mid-implementation.
|
||||||
|
|
||||||
**Have a question not answered here?** [Open an issue](...) or ask in [Discord](...).
|
**Have a question not answered here?** [Open an issue](...) or ask in [Discord](...).
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
---
|
||||||
|
title: Stránka nenalezena
|
||||||
|
template: splash
|
||||||
|
---
|
||||||
|
|
||||||
|
Stránka, kterou hledáte, neexistuje nebo byla přesunuta.
|
||||||
|
|
||||||
|
[Zpět na úvodní stránku](/cs/index.md)
|
||||||
|
|
@ -0,0 +1,370 @@
|
||||||
|
---
|
||||||
|
title: "Průvodce stylem dokumentace"
|
||||||
|
description: Projektově specifické konvence dokumentace založené na stylu Google a struktuře Diataxis
|
||||||
|
---
|
||||||
|
|
||||||
|
Tento projekt se řídí [Google Developer Documentation Style Guide](https://developers.google.com/style) a používá [Diataxis](https://diataxis.fr/) pro strukturování obsahu. Následují pouze projektově specifické konvence.
|
||||||
|
|
||||||
|
## Projektově specifická pravidla
|
||||||
|
|
||||||
|
| Pravidlo | Specifikace |
|
||||||
|
| -------------------------------------- | ---------------------------------------- |
|
||||||
|
| Žádné horizontální čáry (`---`) | Narušují plynulost čtení |
|
||||||
|
| Žádné nadpisy `####` | Místo toho použijte tučný text nebo admonitions |
|
||||||
|
| Žádné sekce „Souvisejí“ nebo „Další:“ | Navigaci zajišťuje postranní panel |
|
||||||
|
| Žádné hluboce vnořené seznamy | Místo toho rozdělejte do sekcí |
|
||||||
|
| Žádné bloky kódu pro nekód | Pro příklady dialogů použijte admonitions |
|
||||||
|
| Žádné tučné odstavce pro upozornění | Místo toho použijte admonitions |
|
||||||
|
| Max 1–2 admonitions na sekci | Tutoriály povolují 3–4 na hlavní sekci |
|
||||||
|
| Buňky tabulek / položky seznamů | Max 1–2 věty |
|
||||||
|
| Rozpočet nadpisů | 8–12 `##` na dokument; 2–3 `###` na sekci |
|
||||||
|
|
||||||
|
## Admonitions (syntaxe Starlight)
|
||||||
|
|
||||||
|
```md
|
||||||
|
:::tip[Název]
|
||||||
|
Zkratky, osvědčené postupy
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::note[Název]
|
||||||
|
Kontext, definice, příklady, předpoklady
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::caution[Název]
|
||||||
|
Upozornění, potenciální problémy
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::danger[Název]
|
||||||
|
Pouze kritická varování — ztráta dat, bezpečnostní problémy
|
||||||
|
:::
|
||||||
|
```
|
||||||
|
|
||||||
|
### Standardní použití
|
||||||
|
|
||||||
|
| Admonition | Použití pro |
|
||||||
|
| ------------------------ | ----------------------------- |
|
||||||
|
| `:::note[Předpoklady]` | Závislosti před začátkem |
|
||||||
|
| `:::tip[Rychlá cesta]` | TL;DR shrnutí na začátku dokumentu |
|
||||||
|
| `:::caution[Důležité]` | Kritická upozornění |
|
||||||
|
| `:::note[Příklad]` | Příklady příkazů/odpovědí |
|
||||||
|
|
||||||
|
## Standardní formáty tabulek
|
||||||
|
|
||||||
|
**Fáze:**
|
||||||
|
|
||||||
|
```md
|
||||||
|
| Fáze | Název | Co se děje |
|
||||||
|
| ---- | -------- | -------------------------------------------- |
|
||||||
|
| 1 | Analýza | Brainstorming, průzkum *(volitelné)* |
|
||||||
|
| 2 | Plánování | Požadavky — PRD nebo specifikace *(povinné)* |
|
||||||
|
```
|
||||||
|
|
||||||
|
**Skills:**
|
||||||
|
|
||||||
|
```md
|
||||||
|
| Skill | Agent | Účel |
|
||||||
|
| -------------------- | ------- | ------------------------------------ |
|
||||||
|
| `bmad-brainstorming` | Analytik | Brainstorming nového projektu |
|
||||||
|
| `bmad-create-prd` | PM | Vytvoření dokumentu požadavků (PRD) |
|
||||||
|
```
|
||||||
|
|
||||||
|
## Bloky struktury složek
|
||||||
|
|
||||||
|
Zobrazujte v sekcích „Co jste dosáhli“:
|
||||||
|
|
||||||
|
````md
|
||||||
|
```
|
||||||
|
váš-projekt/
|
||||||
|
├── _bmad/ # Konfigurace BMad
|
||||||
|
├── _bmad-output/
|
||||||
|
│ ├── planning-artifacts/
|
||||||
|
│ │ └── PRD.md # Váš dokument požadavků
|
||||||
|
│ ├── implementation-artifacts/
|
||||||
|
│ └── project-context.md # Pravidla implementace (volitelné)
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
````
|
||||||
|
|
||||||
|
## Struktura tutoriálu
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Název + Háček (1–2 věty popisující výsledek)
|
||||||
|
2. Upozornění na verzi/modul (info nebo warning admonition) (volitelné)
|
||||||
|
3. Co se naučíte (odrážkový seznam výsledků)
|
||||||
|
4. Předpoklady (info admonition)
|
||||||
|
5. Rychlá cesta (tip admonition – TL;DR shrnutí)
|
||||||
|
6. Pochopení [Tématu] (kontext před kroky – tabulky pro fáze/agenty)
|
||||||
|
7. Instalace (volitelné)
|
||||||
|
8. Krok 1: [První hlavní úkol]
|
||||||
|
9. Krok 2: [Druhý hlavní úkol]
|
||||||
|
10. Krok 3: [Třetí hlavní úkol]
|
||||||
|
11. Co jste dosáhli (shrnutí + struktura složek)
|
||||||
|
12. Rychlý přehled (tabulka skills)
|
||||||
|
13. Časté otázky (formát FAQ)
|
||||||
|
14. Získání pomoci (komunitní odkazy)
|
||||||
|
15. Klíčové poznatky (tip admonition)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Kontrolní seznam tutoriálu
|
||||||
|
|
||||||
|
- [ ] Háček popisuje výsledek v 1–2 větách
|
||||||
|
- [ ] Sekce „Co se naučíte“ je přítomna
|
||||||
|
- [ ] Předpoklady v admonition
|
||||||
|
- [ ] Rychlá cesta TL;DR admonition nahoře
|
||||||
|
- [ ] Tabulky pro fáze, skills, agenty
|
||||||
|
- [ ] Sekce „Co jste dosáhli“ je přítomna
|
||||||
|
- [ ] Tabulka rychlého přehledu je přítomna
|
||||||
|
- [ ] Sekce častých otázek je přítomna
|
||||||
|
- [ ] Sekce získání pomoci je přítomna
|
||||||
|
- [ ] Klíčové poznatky admonition na konci
|
||||||
|
|
||||||
|
## Struktura praktického návodu
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Název + Háček (jedna věta: „Použijte workflow `X` k...“)
|
||||||
|
2. Kdy to použít (odrážkový seznam scénářů)
|
||||||
|
3. Kdy to přeskočit (volitelné)
|
||||||
|
4. Předpoklady (note admonition)
|
||||||
|
5. Kroky (číslované ### podsekce)
|
||||||
|
6. Co získáte (výstup/vytvořené artefakty)
|
||||||
|
7. Příklad (volitelné)
|
||||||
|
8. Tipy (volitelné)
|
||||||
|
9. Další kroky (volitelné)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Kontrolní seznam praktického návodu
|
||||||
|
|
||||||
|
- [ ] Háček začíná „Použijte workflow `X` k...“
|
||||||
|
- [ ] „Kdy to použít“ má 3–5 odrážek
|
||||||
|
- [ ] Předpoklady jsou uvedeny
|
||||||
|
- [ ] Kroky jsou číslované `###` podsekce s akčními slovesy
|
||||||
|
- [ ] „Co získáte“ popisuje výstupní artefakty
|
||||||
|
|
||||||
|
## Struktura vysvětlení
|
||||||
|
|
||||||
|
### Typy
|
||||||
|
|
||||||
|
| Typ | Příklad |
|
||||||
|
| ----------------- | ----------------------------- |
|
||||||
|
| **Úvodní stránka** | `core-concepts/index.md` |
|
||||||
|
| **Koncept** | `what-are-agents.md` |
|
||||||
|
| **Funkce** | `quick-dev.md` |
|
||||||
|
| **Filosofie** | `why-solutioning-matters.md` |
|
||||||
|
| **FAQ** | `established-projects-faq.md` |
|
||||||
|
|
||||||
|
### Obecná šablona
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Název + Háček (1–2 věty)
|
||||||
|
2. Přehled/Definice (co to je, proč je to důležité)
|
||||||
|
3. Klíčové koncepty (### podsekce)
|
||||||
|
4. Srovnávací tabulka (volitelné)
|
||||||
|
5. Kdy použít / Kdy nepoužít (volitelné)
|
||||||
|
6. Diagram (volitelné – mermaid, max 1 na dokument)
|
||||||
|
7. Další kroky (volitelné)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Úvodní/Vstupní stránky
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Název + Háček (jedna věta)
|
||||||
|
2. Tabulka obsahu (odkazy s popisy)
|
||||||
|
3. Jak začít (číslovaný seznam)
|
||||||
|
4. Vyberte si svou cestu (volitelné – rozhodovací strom)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Vysvětlení konceptů
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Název + Háček (co to je)
|
||||||
|
2. Typy/Kategorie (### podsekce) (volitelné)
|
||||||
|
3. Tabulka klíčových rozdílů
|
||||||
|
4. Komponenty/Části
|
||||||
|
5. Co byste měli použít?
|
||||||
|
6. Vytváření/Přizpůsobení (odkaz na praktické návody)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Vysvětlení funkcí
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Název + Háček (co to dělá)
|
||||||
|
2. Rychlá fakta (volitelné – „Ideální pro:“, „Čas:“)
|
||||||
|
3. Kdy použít / Kdy nepoužít
|
||||||
|
4. Jak to funguje (mermaid diagram volitelné)
|
||||||
|
5. Klíčové výhody
|
||||||
|
6. Srovnávací tabulka (volitelné)
|
||||||
|
7. Kdy přejít na vyšší úroveň (volitelné)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Dokumenty filosofie/zdůvodnění
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Název + Háček (princip)
|
||||||
|
2. Problém
|
||||||
|
3. Řešení
|
||||||
|
4. Klíčové principy (### podsekce)
|
||||||
|
5. Výhody
|
||||||
|
6. Kdy to platí
|
||||||
|
```
|
||||||
|
|
||||||
|
### Kontrolní seznam vysvětlení
|
||||||
|
|
||||||
|
- [ ] Háček uvádí, co dokument vysvětluje
|
||||||
|
- [ ] Obsah v přehledných `##` sekcích
|
||||||
|
- [ ] Srovnávací tabulky pro 3+ možností
|
||||||
|
- [ ] Diagramy mají jasné popisky
|
||||||
|
- [ ] Odkazy na praktické návody pro procedurální otázky
|
||||||
|
- [ ] Max 2–3 admonitions na dokument
|
||||||
|
|
||||||
|
## Struktura reference
|
||||||
|
|
||||||
|
### Typy
|
||||||
|
|
||||||
|
| Typ | Příklad |
|
||||||
|
| ----------------- | --------------------- |
|
||||||
|
| **Úvodní stránka** | `workflows/index.md` |
|
||||||
|
| **Katalog** | `agents/index.md` |
|
||||||
|
| **Hloubkový pohled** | `document-project.md` |
|
||||||
|
| **Konfigurace** | `core-tasks.md` |
|
||||||
|
| **Slovníček** | `glossary/index.md` |
|
||||||
|
| **Komplexní** | `bmgd-workflows.md` |
|
||||||
|
|
||||||
|
### Úvodní stránky reference
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Název + Háček (jedna věta)
|
||||||
|
2. Sekce obsahu (## pro každou kategorii)
|
||||||
|
- Odrážkový seznam s odkazy a popisy
|
||||||
|
```
|
||||||
|
|
||||||
|
### Katalogová reference
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Název + Háček
|
||||||
|
2. Položky (## pro každou položku)
|
||||||
|
- Stručný popis (jedna věta)
|
||||||
|
- **Skills:** nebo **Klíčové info:** jako plochý seznam
|
||||||
|
3. Univerzální/Sdílené (## sekce) (volitelné)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Hloubková reference položky
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Název + Háček (jedna věta účel)
|
||||||
|
2. Rychlá fakta (volitelné note admonition)
|
||||||
|
- Modul, Skill, Vstup, Výstup jako seznam
|
||||||
|
3. Účel/Přehled (## sekce)
|
||||||
|
4. Jak vyvolat (blok kódu)
|
||||||
|
5. Klíčové sekce (## pro každý aspekt)
|
||||||
|
- Použijte ### pro pod-možnosti
|
||||||
|
6. Poznámky/Upozornění (tip nebo caution admonition)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Konfigurační reference
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Název + Háček
|
||||||
|
2. Obsah (odkazy pro skok, pokud 4+ položek)
|
||||||
|
3. Položky (## pro každou konfiguraci/úkol)
|
||||||
|
- **Tučné shrnutí** — jedna věta
|
||||||
|
- **Použijte když:** odrážkový seznam
|
||||||
|
- **Jak to funguje:** číslované kroky (max 3–5)
|
||||||
|
- **Výstup:** očekávaný výsledek (volitelné)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Komplexní referenční průvodce
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Název + Háček
|
||||||
|
2. Přehled (## sekce)
|
||||||
|
- Diagram nebo tabulka zobrazující organizaci
|
||||||
|
3. Hlavní sekce (## pro každou fázi/kategorii)
|
||||||
|
- Položky (### pro každou položku)
|
||||||
|
- Standardizovaná pole: Skill, Agent, Vstup, Výstup, Popis
|
||||||
|
4. Další kroky (volitelné)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Kontrolní seznam reference
|
||||||
|
|
||||||
|
- [ ] Háček uvádí, co dokument referuje
|
||||||
|
- [ ] Struktura odpovídá typu reference
|
||||||
|
- [ ] Položky používají konzistentní strukturu
|
||||||
|
- [ ] Tabulky pro strukturovaná/srovnávací data
|
||||||
|
- [ ] Odkazy na dokumenty vysvětlení pro koncepční hloubku
|
||||||
|
- [ ] Max 1–2 admonitions
|
||||||
|
|
||||||
|
## Struktura slovníčku
|
||||||
|
|
||||||
|
Starlight generuje navigaci „Na této stránce“ z nadpisů na pravé straně:
|
||||||
|
|
||||||
|
- Kategorie jako `##` nadpisy — zobrazují se v pravé navigaci
|
||||||
|
- Termíny v tabulkách — kompaktní řádky, ne jednotlivé nadpisy
|
||||||
|
- Žádný inline TOC — pravý panel zajišťuje navigaci
|
||||||
|
|
||||||
|
### Formát tabulky
|
||||||
|
|
||||||
|
```md
|
||||||
|
## Název kategorie
|
||||||
|
|
||||||
|
| Termín | Definice |
|
||||||
|
| ------------ | ------------------------------------------------------------------------------------------- |
|
||||||
|
| **Agent** | Specializovaná AI persona s konkrétní odborností, která provází uživatele pracovními postupy. |
|
||||||
|
| **Workflow** | Vícekrokový řízený proces, který orchestruje aktivity AI agentů k vytvoření výstupů. |
|
||||||
|
```
|
||||||
|
|
||||||
|
### Pravidla definic
|
||||||
|
|
||||||
|
| Správně | Špatně |
|
||||||
|
| ------------------------------ | -------------------------------------------- |
|
||||||
|
| Začněte tím, co to JE nebo DĚLÁ | Nezačínejte „Toto je...“ nebo „[Termín] je...“ |
|
||||||
|
| Držte se 1–2 vět | Nepište víceodstavcová vysvětlení |
|
||||||
|
| Tučný název termínu v buňce | Nepoužívejte prostý text pro termíny |
|
||||||
|
|
||||||
|
### Kontextové značky
|
||||||
|
|
||||||
|
Přidejte kurzívní kontext na začátek definice pro termíny s omezeným rozsahem:
|
||||||
|
|
||||||
|
- `*Pouze Quick Flow.*`
|
||||||
|
- `*BMad Method/Enterprise.*`
|
||||||
|
- `*Fáze N.*`
|
||||||
|
- `*BMGD.*`
|
||||||
|
- `*Existující projekty.*`
|
||||||
|
|
||||||
|
### Kontrolní seznam slovníčku
|
||||||
|
|
||||||
|
- [ ] Termíny v tabulkách, ne jako jednotlivé nadpisy
|
||||||
|
- [ ] Termíny abecedně seřazeny v kategoriích
|
||||||
|
- [ ] Definice 1–2 věty
|
||||||
|
- [ ] Kontextové značky kurzívou
|
||||||
|
- [ ] Názvy termínů tučně v buňkách
|
||||||
|
- [ ] Žádné definice „[Termín] je...“
|
||||||
|
|
||||||
|
## Sekce FAQ
|
||||||
|
|
||||||
|
```md
|
||||||
|
## Otázky
|
||||||
|
|
||||||
|
- [Potřebuji vždy architekturu?](#potřebuji-vždy-architekturu)
|
||||||
|
- [Mohu později změnit svůj plán?](#mohu-později-změnit-svůj-plán)
|
||||||
|
|
||||||
|
### Potřebuji vždy architekturu?
|
||||||
|
|
||||||
|
Pouze pro BMad Method a Enterprise. Quick Flow přeskakuje rovnou k implementaci.
|
||||||
|
|
||||||
|
### Mohu později změnit svůj plán?
|
||||||
|
|
||||||
|
Ano. SM agent má workflow `bmad-correct-course` pro řešení změn rozsahu.
|
||||||
|
|
||||||
|
**Máte otázku, na kterou jste zde nenašli odpověď?** [Vytvořte issue](...) nebo se zeptejte na [Discordu](...).
|
||||||
|
```
|
||||||
|
|
||||||
|
## Validační příkazy
|
||||||
|
|
||||||
|
Před odesláním změn dokumentace:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npm run docs:fix-links # Náhled oprav formátu odkazů
|
||||||
|
npm run docs:fix-links -- --write # Aplikovat opravy
|
||||||
|
npm run docs:validate-links # Kontrola existence odkazů
|
||||||
|
npm run docs:build # Ověření bez chyb při sestavení
|
||||||
|
```
|
||||||
|
|
@ -0,0 +1,49 @@
|
||||||
|
---
|
||||||
|
title: "Pokročilá elicitace"
|
||||||
|
description: Přimějte LLM přehodnotit svou práci pomocí strukturovaných metod uvažování
|
||||||
|
sidebar:
|
||||||
|
order: 6
|
||||||
|
---
|
||||||
|
|
||||||
|
Přimějte LLM přehodnotit, co právě vygeneroval. Vyberete metodu uvažování, LLM ji aplikuje na svůj vlastní výstup, a vy rozhodnete, zda si vylepšení ponecháte.
|
||||||
|
|
||||||
|
## Co je pokročilá elicitace?
|
||||||
|
|
||||||
|
Strukturovaný druhý průchod. Místo žádání AI, aby „to zkusila znovu“ nebo „to zlepšila“, vyberete specifickou metodu uvažování a AI přezkoumá svůj vlastní výstup přes tento objektiv.
|
||||||
|
|
||||||
|
Rozdíl je podstatný. Vágní požadavky produkují vágní revize. Pojmenovaná metoda vynucuje konkrétní úhel útoku, odhaluje postřehy, které by generický pokus přehlédl.
|
||||||
|
|
||||||
|
## Kdy ji použít
|
||||||
|
|
||||||
|
- Poté, co workflow vygeneruje obsah a chcete alternativy
|
||||||
|
- Když výstup vypadá v pořádku, ale tušíte, že je v něm víc hloubky
|
||||||
|
- K zátěžovému testování předpokladů nebo nalezení slabých míst
|
||||||
|
- Pro důležitý obsah, kde přehodnocení pomáhá
|
||||||
|
|
||||||
|
Workflow nabízejí pokročilou elicitaci v rozhodovacích bodech — poté, co LLM něco vygeneruje, budete dotázáni, zda ji chcete spustit.
|
||||||
|
|
||||||
|
## Jak to funguje
|
||||||
|
|
||||||
|
1. LLM navrhne 5 relevantních metod pro váš obsah
|
||||||
|
2. Vyberete jednu (nebo zamícháte pro jiné možnosti)
|
||||||
|
3. Metoda je aplikována, vylepšení zobrazena
|
||||||
|
4. Přijměte nebo zahoďte, opakujte nebo pokračujte
|
||||||
|
|
||||||
|
## Vestavěné metody
|
||||||
|
|
||||||
|
K dispozici jsou desítky metod uvažování. Několik příkladů:
|
||||||
|
|
||||||
|
- **Pre-mortem analýza** — Předpokládejte, že projekt už selhal, a zpětně hledejte proč
|
||||||
|
- **Myšlení z prvních principů** — Odstraňte předpoklady, znovu postavte od základní pravdy
|
||||||
|
- **Inverze** — Zeptejte se, jak zaručit selhání, a poté se tomu vyhněte
|
||||||
|
- **Red Team vs Blue Team** — Napadněte vlastní práci, pak ji braňte
|
||||||
|
- **Sokratovské dotazování** — Zpochybněte každé tvrzení otázkou „proč?“ a „jak víte?“
|
||||||
|
- **Odstranění omezení** — Odstraňte všechna omezení, podívejte se, co se změní, selektivně je přidejte zpět
|
||||||
|
- **Mapování zainteresovaných stran** — Přehodnoťte z perspektivy každé zainteresované strany
|
||||||
|
- **Analogické uvažování** — Najděte paralely v jiných oblastech a aplikujte jejich lekce
|
||||||
|
|
||||||
|
A mnoho dalších. AI vybírá nejrelevantnější možnosti pro váš obsah — vy si vyberete, kterou spustit.
|
||||||
|
|
||||||
|
:::tip[Začněte zde]
|
||||||
|
Pre-mortem analýza je dobrá první volba pro jakoukoli specifikaci nebo plán. Konzistentně nachází mezery, které standardní revize přehlédne.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,59 @@
|
||||||
|
---
|
||||||
|
title: "Adversariální revize"
|
||||||
|
description: Technika vynuceného uvažování, která zabraňuje líným „vypadá dobře“ revizím
|
||||||
|
sidebar:
|
||||||
|
order: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
Vynuťte hlubší analýzu tím, že budete vyžadovat nalezení problémů.
|
||||||
|
|
||||||
|
## Co je adversariální revize?
|
||||||
|
|
||||||
|
Technika revize, kde recenzent *musí* najít problémy. Žádné „vypadá dobře“ není povoleno. Recenzent zaujme cynický postoj — předpokládá, že problémy existují, a hledá je.
|
||||||
|
|
||||||
|
Nejde o negativismus. Jde o vynucení skutečné analýzy místo povrchního pohledu, který automaticky schválí cokoli, co bylo předloženo.
|
||||||
|
|
||||||
|
**Základní pravidlo:** Musíte najít problémy. Nulové nálezy spouštějí zastavení — analyzujte znovu nebo vysvětlete proč.
|
||||||
|
|
||||||
|
## Proč to funguje
|
||||||
|
|
||||||
|
Běžné revize trpí konfirmačním zkreslením. Proletíte práci, nic nevyskočí, schválíte to. Mandát „najít problémy“ tento vzor rozbíjí:
|
||||||
|
|
||||||
|
- **Vynucuje důkladnost** — Nemůžete schválit, dokud jste nehledali dostatečně pečlivě
|
||||||
|
- **Zachytí chybějící věci** — „Co zde není?“ se stává přirozenou otázkou
|
||||||
|
- **Zlepšuje kvalitu signálu** — Nálezy jsou konkrétní a akční, ne vágní obavy
|
||||||
|
- **Informační asymetrie** — Provádějte revize s čerstvým kontextem (bez přístupu k původnímu uvažování), abyste hodnotili artefakt, ne záměr
|
||||||
|
|
||||||
|
## Kde se používá
|
||||||
|
|
||||||
|
Adversariální revize se objevuje v celém BMad workflow — revize kódu, kontroly připravenosti implementace, validace specifikací a další. Někdy je to povinný krok, někdy volitelný (jako pokročilá elicitace nebo party mode). Vzor se přizpůsobí jakémukoli artefaktu, který potřebuje kontrolu.
|
||||||
|
|
||||||
|
## Vyžadováno lidské filtrování
|
||||||
|
|
||||||
|
Protože AI je *instruována* najít problémy, najde problémy — i když neexistují. Očekávejte falešné pozitivy: malichernosti převlečené za problémy, nepochopení záměru nebo přímo vymyšlené obavy.
|
||||||
|
|
||||||
|
**Vy rozhodujete, co je skutečné.** Zkontrolujte každý nález, odmítněte šum, opravte to, na čem záleží.
|
||||||
|
|
||||||
|
## Příklad
|
||||||
|
|
||||||
|
Místo:
|
||||||
|
|
||||||
|
> „Implementace autentizace vypadá rozumně. Schváleno.“
|
||||||
|
|
||||||
|
Adversariální revize produkuje:
|
||||||
|
|
||||||
|
> 1. **VYSOKÁ** — `login.ts:47` — Žádné omezení rychlosti neúspěšných pokusů
|
||||||
|
> 2. **VYSOKÁ** — Session token uložen v localStorage (zranitelný vůči XSS)
|
||||||
|
> 3. **STŘEDNÍ** — Validace hesla probíhá pouze na straně klienta
|
||||||
|
> 4. **STŘEDNÍ** — Žádné auditní logování neúspěšných pokusů o přihlášení
|
||||||
|
> 5. **NÍZKÁ** — Magické číslo `3600` by mělo být `SESSION_TIMEOUT_SECONDS`
|
||||||
|
|
||||||
|
První revize mohla přehlédnout bezpečnostní zranitelnost. Druhá zachytila čtyři.
|
||||||
|
|
||||||
|
## Iterace a klesající výnosy
|
||||||
|
|
||||||
|
Po řešení nálezů zvažte opětovné spuštění. Druhý průchod obvykle zachytí více. Třetí také není vždy zbytečný. Ale každý průchod zabere čas a nakonec dosáhnete klesajících výnosů — jen malichernosti a falešné nálezy.
|
||||||
|
|
||||||
|
:::tip[Lepší revize]
|
||||||
|
Předpokládejte, že problémy existují. Hledejte, co chybí, ne jen co je špatně.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,33 @@
|
||||||
|
---
|
||||||
|
title: "Brainstorming"
|
||||||
|
description: Interaktivní kreativní sezení s využitím 60+ osvědčených technik ideace
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Uvolněte svou kreativitu prostřednictvím řízeného průzkumu.
|
||||||
|
|
||||||
|
## Co je brainstorming?
|
||||||
|
|
||||||
|
Spusťte `bmad-brainstorming` a máte kreativního facilitátora, který z vás táhne nápady — ne který je generuje za vás. AI působí jako kouč a průvodce, používá osvědčené techniky k vytvoření podmínek, ve kterých se projeví vaše nejlepší myšlení.
|
||||||
|
|
||||||
|
**Ideální pro:**
|
||||||
|
|
||||||
|
- Překonání kreativních bloků
|
||||||
|
- Generování nápadů na produkty nebo funkce
|
||||||
|
- Zkoumání problémů z nových úhlů
|
||||||
|
- Rozvíjení surových konceptů do akčních plánů
|
||||||
|
|
||||||
|
## Jak to funguje
|
||||||
|
|
||||||
|
1. **Příprava** — Definujte téma, cíle, omezení
|
||||||
|
2. **Volba přístupu** — Vyberte techniky sami, nechte si doporučit od AI, zvolte náhodně, nebo postupujte progresivním tokem
|
||||||
|
3. **Facilitace** — Projděte techniky s podněcujícími otázkami a kolaborativním koučováním
|
||||||
|
4. **Organizace** — Nápady seskupeny do témat a prioritizovány
|
||||||
|
5. **Akce** — Nejlepší nápady dostanou další kroky a metriky úspěchu
|
||||||
|
|
||||||
|
Vše je zachyceno v dokumentu sezení, na který se můžete později odkazovat nebo ho sdílet se zúčastněnými stranami.
|
||||||
|
|
||||||
|
:::note[Vaše nápady]
|
||||||
|
Každý nápad pochází od vás. Workflow vytváří podmínky pro vhled — vy jste zdrojem.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,50 @@
|
||||||
|
---
|
||||||
|
title: "FAQ pro existující projekty"
|
||||||
|
description: Časté otázky o používání BMad Method na existujících projektech
|
||||||
|
sidebar:
|
||||||
|
order: 8
|
||||||
|
---
|
||||||
|
Rychlé odpovědi na časté otázky o práci na existujících projektech s BMad Method (BMM).
|
||||||
|
|
||||||
|
## Otázky
|
||||||
|
|
||||||
|
- [Musím nejdřív spustit document-project?](#musím-nejdřív-spustit-document-project)
|
||||||
|
- [Co když zapomenu spustit document-project?](#co-když-zapomenu-spustit-document-project)
|
||||||
|
- [Mohu použít Quick Flow pro existující projekty?](#mohu-použít-quick-flow-pro-existující-projekty)
|
||||||
|
- [Co když můj existující kód nedodržuje osvědčené postupy?](#co-když-můj-existující-kód-nedodržuje-osvědčené-postupy)
|
||||||
|
|
||||||
|
### Musím nejdřív spustit document-project?
|
||||||
|
|
||||||
|
Vysoce doporučeno, zejména pokud:
|
||||||
|
|
||||||
|
- Neexistuje žádná dokumentace
|
||||||
|
- Dokumentace je zastaralá
|
||||||
|
- AI agenti potřebují kontext o existujícím kódu
|
||||||
|
|
||||||
|
Můžete to přeskočit, pokud máte komplexní, aktuální dokumentaci včetně `docs/index.md` nebo budete používat jiné nástroje nebo techniky k usnadnění discovery pro agenta stavějícího na existujícím systému.
|
||||||
|
|
||||||
|
### Co když zapomenu spustit document-project?
|
||||||
|
|
||||||
|
Nedělejte si starosti — můžete to udělat kdykoli. Můžete to udělat i během nebo po projektu, aby pomohl udržet dokumentaci aktuální.
|
||||||
|
|
||||||
|
### Mohu použít Quick Flow pro existující projekty?
|
||||||
|
|
||||||
|
Ano! Quick Flow funguje skvěle pro existující projekty. Umí:
|
||||||
|
|
||||||
|
- Automaticky detekovat váš existující stack
|
||||||
|
- Analyzovat existující vzory kódu
|
||||||
|
- Detekovat konvence a požádat o potvrzení
|
||||||
|
- Generovat kontextově bohatou specifikaci, která respektuje existující kód
|
||||||
|
|
||||||
|
Ideální pro opravy chyb a malé funkce v existujících kódových bázích.
|
||||||
|
|
||||||
|
### Co když můj existující kód nedodržuje osvědčené postupy?
|
||||||
|
|
||||||
|
Quick Flow detekuje vaše konvence a zeptá se: „Mám dodržovat tyto existující konvence?“ Rozhodujete vy:
|
||||||
|
|
||||||
|
- **Ano** → Zachovat konzistenci se současnou kódovou bází
|
||||||
|
- **Ne** → Zavést nové standardy (zdokumentujte proč ve specifikaci)
|
||||||
|
|
||||||
|
BMM respektuje vaši volbu — nevynucuje modernizaci, ale nabídne ji.
|
||||||
|
|
||||||
|
**Máte otázku, na kterou jste zde nenašli odpověď?** Prosím [vytvořte issue](https://github.com/bmad-code-org/BMAD-METHOD/issues) nebo se zeptejte na [Discordu](https://discord.gg/gk8jAdXWmj), abychom ji mohli přidat!
|
||||||
|
|
@ -0,0 +1,59 @@
|
||||||
|
---
|
||||||
|
title: "Party Mode"
|
||||||
|
description: Spolupráce více agentů — všichni vaši AI agenti v jedné konverzaci
|
||||||
|
sidebar:
|
||||||
|
order: 7
|
||||||
|
---
|
||||||
|
|
||||||
|
Všichni vaši AI agenti v jedné konverzaci.
|
||||||
|
|
||||||
|
## Co je Party Mode?
|
||||||
|
|
||||||
|
Spusťte `bmad-party-mode` a máte celý svůj AI tým v jedné místnosti — PM, Architect, Dev, UX Designer, kohokoli potřebujete. BMad Master orchestruje, vybírá relevantní agenty pro každou zprávu. Agenti odpovídají v charakteru, souhlasí, nesouhlasí a staví na nápadech ostatních.
|
||||||
|
|
||||||
|
Konverzace pokračuje tak dlouho, jak chcete. Ptejte se na doplňující otázky, oponujte odpovědím, přesměrujte diskuzi — je to skutečná výměna s vašimi agenty, dokud neskončíte.
|
||||||
|
|
||||||
|
**Ideální pro:**
|
||||||
|
|
||||||
|
- Velká rozhodnutí s kompromisy
|
||||||
|
- Brainstormingová sezení
|
||||||
|
- Post-mortemy, když se něco pokazí
|
||||||
|
- Retrospektivy a plánování sprintů
|
||||||
|
|
||||||
|
## Příklady
|
||||||
|
|
||||||
|
### Kritika špatné architektury
|
||||||
|
|
||||||
|
**Vy:** „Dobře, týme, náš poslední sprint byl katastrofa. Autentizační služba spadla třikrát. Kdo to pokazil?“
|
||||||
|
|
||||||
|
**Architect:** „Design byl v pořádku — distribuovaná autentizace se správnými záložními řešeními. Pokud se implementace odchýlila od specifikace...“
|
||||||
|
|
||||||
|
**Dev:** „Následoval jsem architektonický dokument přesně. Specifikace nepočítala s race conditions při souběžné invalidaci relací.“
|
||||||
|
|
||||||
|
**PM:** „Oba jste přehlédli větší problém — nevalidovali jsme požadavky na správu relací v PRD. Tohle je na mně, že jsem to nezachytil.“
|
||||||
|
|
||||||
|
**TEA:** „A já to měl zachytit v integračních testech. Testovací scénáře nepokrývaly souběžnou invalidaci.“
|
||||||
|
|
||||||
|
### Kreativní brainstorming
|
||||||
|
|
||||||
|
**Vy:** „Jak udělat onboarding magický místo nudného?“
|
||||||
|
|
||||||
|
**UX Designer:** „Začněte s progresivním odhalováním — odhalujte funkce, jak je uživatelé potřebují, ne všechny najednou v tutoriálu.“
|
||||||
|
|
||||||
|
**Storyteller:** „Co kdyby onboarding byl příběh? Každý krok odhaluje cestu postavy — uživatel JE hrdina.“
|
||||||
|
|
||||||
|
**Game Designer:** „Navazuji na to — co kdyby první ‚quest' vlastně řešil skutečný problém uživatele? Učí se tím, že dělají něco hodnotného.“
|
||||||
|
|
||||||
|
### Technické rozhodnutí
|
||||||
|
|
||||||
|
**Vy:** „Monolit nebo mikroslužby pro MVP?“
|
||||||
|
|
||||||
|
**Architect:** „Začněte monolitem. Mikroslužby přidávají složitost, kterou při 1000 uživatelích nepotřebujete.“
|
||||||
|
|
||||||
|
**PM:** „Souhlasím. Čas na trh je důležitější než teoretická škálovatelnost.“
|
||||||
|
|
||||||
|
**Dev:** „Monolit s jasnými hranicemi modulů. Služby můžeme extrahovat později, pokud bude potřeba.“
|
||||||
|
|
||||||
|
:::tip[Lepší rozhodnutí]
|
||||||
|
Lepší rozhodnutí prostřednictvím různorodých perspektiv. Vítejte v party mode.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,112 @@
|
||||||
|
---
|
||||||
|
title: "Předcházení konfliktům agentů"
|
||||||
|
description: Jak architektura zabraňuje konfliktům, když více agentů implementuje systém
|
||||||
|
sidebar:
|
||||||
|
order: 4
|
||||||
|
---
|
||||||
|
|
||||||
|
Když více AI agentů implementuje různé části systému, mohou dělat protichůdná technická rozhodnutí. Dokumentace architektury tomu zabraňuje stanovením sdílených standardů.
|
||||||
|
|
||||||
|
## Běžné typy konfliktů
|
||||||
|
|
||||||
|
### Konflikty stylu API
|
||||||
|
|
||||||
|
Bez architektury:
|
||||||
|
- Agent A používá REST s `/users/{id}`
|
||||||
|
- Agent B používá GraphQL mutations
|
||||||
|
- Výsledek: Nekonzistentní vzory API, zmatení konzumenti
|
||||||
|
|
||||||
|
S architekturou:
|
||||||
|
- ADR specifikuje: „Použít GraphQL pro veškerou komunikaci klient-server“
|
||||||
|
- Všichni agenti dodržují stejný vzor
|
||||||
|
|
||||||
|
### Konflikty návrhu databáze
|
||||||
|
|
||||||
|
Bez architektury:
|
||||||
|
- Agent A používá snake_case pro názvy sloupců
|
||||||
|
- Agent B používá camelCase pro názvy sloupců
|
||||||
|
- Výsledek: Nekonzistentní schéma, matoucí dotazy
|
||||||
|
|
||||||
|
S architekturou:
|
||||||
|
- Dokument standardů specifikuje konvence pojmenování
|
||||||
|
- Všichni agenti dodržují stejné vzory
|
||||||
|
|
||||||
|
### Konflikty řízení stavu
|
||||||
|
|
||||||
|
Bez architektury:
|
||||||
|
- Agent A používá Redux pro globální stav
|
||||||
|
- Agent B používá React Context
|
||||||
|
- Výsledek: Více přístupů k řízení stavu, složitost
|
||||||
|
|
||||||
|
S architekturou:
|
||||||
|
- ADR specifikuje přístup k řízení stavu
|
||||||
|
- Všichni agenti implementují konzistentně
|
||||||
|
|
||||||
|
## Jak architektura zabraňuje konfliktům
|
||||||
|
|
||||||
|
### 1. Explicitní rozhodnutí skrze ADR
|
||||||
|
|
||||||
|
Každé významné technologické rozhodnutí je zdokumentováno s:
|
||||||
|
- Kontext (proč toto rozhodnutí záleží)
|
||||||
|
- Zvažované možnosti (jaké alternativy existují)
|
||||||
|
- Rozhodnutí (co jsme zvolili)
|
||||||
|
- Zdůvodnění (proč jsme to zvolili)
|
||||||
|
- Důsledky (přijaté kompromisy)
|
||||||
|
|
||||||
|
### 2. Specifické pokyny pro FR/NFR
|
||||||
|
|
||||||
|
Architektura mapuje každý funkční požadavek na technický přístup:
|
||||||
|
- FR-001: Správa uživatelů → GraphQL mutations
|
||||||
|
- FR-002: Mobilní aplikace → Optimalizované dotazy
|
||||||
|
|
||||||
|
### 3. Standardy a konvence
|
||||||
|
|
||||||
|
Explicitní dokumentace:
|
||||||
|
- Struktura adresářů
|
||||||
|
- Konvence pojmenování
|
||||||
|
- Organizace kódu
|
||||||
|
- Vzory testování
|
||||||
|
|
||||||
|
## Architektura jako sdílený kontext
|
||||||
|
|
||||||
|
Představte si architekturu jako sdílený kontext, který všichni agenti čtou před implementací:
|
||||||
|
|
||||||
|
```text
|
||||||
|
PRD: "Co budovat"
|
||||||
|
↓
|
||||||
|
Architektura: "Jak to budovat"
|
||||||
|
↓
|
||||||
|
Agent A čte architekturu → implementuje Epic 1
|
||||||
|
Agent B čte architekturu → implementuje Epic 2
|
||||||
|
Agent C čte architekturu → implementuje Epic 3
|
||||||
|
↓
|
||||||
|
Výsledek: Konzistentní implementace
|
||||||
|
```
|
||||||
|
|
||||||
|
## Klíčová témata ADR
|
||||||
|
|
||||||
|
Běžná rozhodnutí, která zabraňují konfliktům:
|
||||||
|
|
||||||
|
| Téma | Příklad rozhodnutí |
|
||||||
|
| ---------------- | -------------------------------------------- |
|
||||||
|
| Styl API | GraphQL vs REST vs gRPC |
|
||||||
|
| Databáze | PostgreSQL vs MongoDB |
|
||||||
|
| Autentizace | JWT vs Sessions |
|
||||||
|
| Řízení stavu | Redux vs Context vs Zustand |
|
||||||
|
| Stylování | CSS Modules vs Tailwind vs Styled Components |
|
||||||
|
| Testování | Jest + Playwright vs Vitest + Cypress |
|
||||||
|
|
||||||
|
## Anti-vzory, kterým se vyhnout
|
||||||
|
|
||||||
|
:::caution[Běžné chyby]
|
||||||
|
- **Implicitní rozhodnutí** — „Styl API vyřešíme průběžně“ vede k nekonzistenci
|
||||||
|
- **Nadměrná dokumentace** — Dokumentování každého drobného rozhodnutí způsobuje paralýzu analýzou
|
||||||
|
- **Zastaralá architektura** — Dokumenty napsané jednou a nikdy neaktualizované způsobují, že agenti následují zastaralé vzory
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::tip[Správný přístup]
|
||||||
|
- Dokumentujte rozhodnutí, která přesahují hranice epiců
|
||||||
|
- Zaměřte se na oblasti náchylné ke konfliktům
|
||||||
|
- Aktualizujte architekturu, jak se učíte
|
||||||
|
- Použijte `bmad-correct-course` pro významné změny
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,157 @@
|
||||||
|
---
|
||||||
|
title: "Kontext projektu"
|
||||||
|
description: Jak project-context.md vede AI agenty s pravidly a preferencemi vašeho projektu
|
||||||
|
sidebar:
|
||||||
|
order: 7
|
||||||
|
---
|
||||||
|
|
||||||
|
Soubor `project-context.md` je implementační průvodce vašeho projektu pro AI agenty. Podobně jako „ústava“ v jiných vývojových systémech zachycuje pravidla, vzory a preference, které zajišťují konzistentní generování kódu napříč všemi workflow.
|
||||||
|
|
||||||
|
## Co dělá
|
||||||
|
|
||||||
|
AI agenti neustále dělají implementační rozhodnutí — jaké vzory následovat, jak strukturovat kód, jaké konvence používat. Bez jasného vedení mohou:
|
||||||
|
- Následovat generické osvědčené postupy, které neodpovídají vaší kódové bázi
|
||||||
|
- Dělat nekonzistentní rozhodnutí napříč různými stories
|
||||||
|
- Přehlédnout požadavky nebo omezení specifická pro projekt
|
||||||
|
|
||||||
|
Soubor `project-context.md` toto řeší dokumentací toho, co agenti potřebují vědět, ve stručném formátu optimalizovaném pro LLM.
|
||||||
|
|
||||||
|
## Jak to funguje
|
||||||
|
|
||||||
|
Každý implementační workflow automaticky načítá `project-context.md`, pokud existuje. Architektonický workflow ho také načítá, aby respektoval vaše technické preference při navrhování architektury.
|
||||||
|
|
||||||
|
**Načítán těmito workflow:**
|
||||||
|
- `bmad-create-architecture` — respektuje technické preference během solutioningu
|
||||||
|
- `bmad-create-story` — informuje tvorbu stories vzory projektu
|
||||||
|
- `bmad-dev-story` — vede implementační rozhodnutí
|
||||||
|
- `bmad-code-review` — validuje proti standardům projektu
|
||||||
|
- `bmad-quick-dev` — aplikuje vzory při implementaci specifikací
|
||||||
|
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — poskytuje celkový kontext projektu
|
||||||
|
|
||||||
|
## Kdy ho vytvořit
|
||||||
|
|
||||||
|
Soubor `project-context.md` je užitečný v jakékoli fázi projektu:
|
||||||
|
|
||||||
|
| Scénář | Kdy vytvořit | Účel |
|
||||||
|
| ------------------------------------ | ----------------------------------------------- | -------------------------------------------------------------------- |
|
||||||
|
| **Nový projekt, před architekturou** | Ručně, před `bmad-create-architecture` | Dokumentujte vaše technické preference, aby je architekt respektoval |
|
||||||
|
| **Nový projekt, po architektuře** | Přes `bmad-generate-project-context` nebo ručně | Zachyťte architektonická rozhodnutí pro implementační agenty |
|
||||||
|
| **Existující projekt** | Přes `bmad-generate-project-context` | Objevte existující vzory, aby agenti dodržovali zavedené konvence |
|
||||||
|
| **Quick Flow projekt** | Před nebo během `bmad-quick-dev` | Zajistěte, aby rychlá implementace respektovala vaše vzory |
|
||||||
|
|
||||||
|
:::tip[Doporučeno]
|
||||||
|
Pro nové projekty ho vytvořte ručně před architekturou, pokud máte silné technické preference. Jinak ho vygenerujte po architektuře pro zachycení těchto rozhodnutí.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Co do něj patří
|
||||||
|
|
||||||
|
Soubor má dvě hlavní sekce:
|
||||||
|
|
||||||
|
### Technologický stack a verze
|
||||||
|
|
||||||
|
Dokumentuje frameworky, jazyky a nástroje, které váš projekt používá se specifickými verzemi:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Technology Stack & Versions
|
||||||
|
|
||||||
|
- Node.js 20.x, TypeScript 5.3, React 18.2
|
||||||
|
- State: Zustand (not Redux)
|
||||||
|
- Testing: Vitest, Playwright, MSW
|
||||||
|
- Styling: Tailwind CSS with custom design tokens
|
||||||
|
```
|
||||||
|
|
||||||
|
### Kritická pravidla implementace
|
||||||
|
|
||||||
|
Dokumentuje vzory a konvence, které by agenti jinak mohli přehlédnout:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Critical Implementation Rules
|
||||||
|
|
||||||
|
**TypeScript Configuration:**
|
||||||
|
- Strict mode enabled — no `any` types without explicit approval
|
||||||
|
- Use `interface` for public APIs, `type` for unions/intersections
|
||||||
|
|
||||||
|
**Code Organization:**
|
||||||
|
- Components in `/src/components/` with co-located `.test.tsx`
|
||||||
|
- Utilities in `/src/lib/` for reusable pure functions
|
||||||
|
- API calls use the `apiClient` singleton — never fetch directly
|
||||||
|
|
||||||
|
**Testing Patterns:**
|
||||||
|
- Unit tests focus on business logic, not implementation details
|
||||||
|
- Integration tests use MSW to mock API responses
|
||||||
|
- E2E tests cover critical user journeys only
|
||||||
|
|
||||||
|
**Framework-Specific:**
|
||||||
|
- All async operations use the `handleError` wrapper for consistent error handling
|
||||||
|
- Feature flags accessed via `featureFlag()` from `@/lib/flags`
|
||||||
|
- New routes follow the file-based routing pattern in `/src/app/`
|
||||||
|
```
|
||||||
|
|
||||||
|
Zaměřte se na to, co je **neočividné** — věci, které agenti nemusí odvodit z čtení úryvků kódu. Nedokumentujte standardní postupy, které platí univerzálně.
|
||||||
|
|
||||||
|
## Vytvoření souboru
|
||||||
|
|
||||||
|
Máte tři možnosti:
|
||||||
|
|
||||||
|
### Ruční vytvoření
|
||||||
|
|
||||||
|
Vytvořte soubor na `_bmad-output/project-context.md` a přidejte svá pravidla:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# V kořeni projektu
|
||||||
|
mkdir -p _bmad-output
|
||||||
|
touch _bmad-output/project-context.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Upravte ho s vaším technologickým stackem a pravidly implementace. Architektonický a implementační workflow ho automaticky najdou a načtou.
|
||||||
|
|
||||||
|
### Generování po architektuře
|
||||||
|
|
||||||
|
Spusťte workflow `bmad-generate-project-context` po dokončení architektury:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Toto skenuje váš dokument architektury a soubory projektu a generuje kontextový soubor zachycující učiněná rozhodnutí.
|
||||||
|
|
||||||
|
### Generování pro existující projekty
|
||||||
|
|
||||||
|
Pro existující projekty spusťte `bmad-generate-project-context` pro objevení existujících vzorů:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Workflow analyzuje vaši kódovou bázi, identifikuje konvence a vygeneruje kontextový soubor, který můžete zkontrolovat a upřesnit.
|
||||||
|
|
||||||
|
## Proč na tom záleží
|
||||||
|
|
||||||
|
Bez `project-context.md` agenti dělají předpoklady, které nemusí odpovídat vašemu projektu:
|
||||||
|
|
||||||
|
| Bez kontextu | S kontextem |
|
||||||
|
| ----------------------------------------------- | ---------------------------------------- |
|
||||||
|
| Používá generické vzory | Dodržuje vaše zavedené konvence |
|
||||||
|
| Nekonzistentní styl napříč stories | Konzistentní implementace |
|
||||||
|
| Může přehlédnout omezení specifická pro projekt | Respektuje všechny technické požadavky |
|
||||||
|
| Každý agent rozhoduje nezávisle | Všichni agenti se řídí stejnými pravidly |
|
||||||
|
|
||||||
|
To je zvláště důležité pro:
|
||||||
|
- **Quick Flow** — přeskakuje PRD a architekturu, takže kontextový soubor vyplní mezeru
|
||||||
|
- **Týmové projekty** — zajistí, že všichni agenti dodržují stejné standardy
|
||||||
|
- **Existující projekty** — zabrání porušení zavedených vzorů
|
||||||
|
|
||||||
|
## Editace a aktualizace
|
||||||
|
|
||||||
|
Soubor `project-context.md` je živý dokument. Aktualizujte ho, když:
|
||||||
|
|
||||||
|
- Se změní architektonická rozhodnutí
|
||||||
|
- Jsou zavedeny nové konvence
|
||||||
|
- Vzory se vyvíjejí během implementace
|
||||||
|
- Identifikujete mezery z chování agentů
|
||||||
|
|
||||||
|
Můžete ho kdykoli ručně upravit, nebo přegenerovat `bmad-generate-project-context` po významných změnách.
|
||||||
|
|
||||||
|
:::note[Umístění souboru]
|
||||||
|
Výchozí umístění je `_bmad-output/project-context.md`. Workflow ho tam hledají a také kontrolují `**/project-context.md` kdekoli ve vašem projektu.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,73 @@
|
||||||
|
---
|
||||||
|
title: "Quick Dev"
|
||||||
|
description: Snižte tření human-in-the-loop bez ztráty kontrolních bodů chránících kvalitu výstupu
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Záměr na vstupu, změny kódu na výstupu, s co nejmenším počtem human-in-the-loop kroků — bez obětování kvality.
|
||||||
|
|
||||||
|
Umožňuje modelu běžet déle mezi kontrolními body a poté přivede člověka zpět pouze tehdy, když úkol nemůže bezpečně pokračovat bez lidského úsudku nebo když je čas zkontrolovat konečný výsledek.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Proč to existuje
|
||||||
|
|
||||||
|
Human-in-the-loop kroky jsou nutné a nákladné.
|
||||||
|
|
||||||
|
Současné LLM stále selhávají předvídatelnými způsoby: chybně čtou záměr, vyplňují mezery sebevědomými odhady, odchylují se k nesouvisející práci a generují šumový výstup revize. Současně neustálá lidská intervence limituje rychlost vývoje. Lidská pozornost je úzké hrdlo.
|
||||||
|
|
||||||
|
`bmad-quick-dev` přenastavuje tento kompromis. Důvěřuje modelu, aby běžel bez dozoru delší úseky, ale pouze poté, co workflow vytvořil dostatečně silnou hranici, aby to bylo bezpečné.
|
||||||
|
|
||||||
|
## Základní design
|
||||||
|
|
||||||
|
### 1. Nejprve komprimujte záměr
|
||||||
|
|
||||||
|
Workflow začíná tím, že člověk a model zkomprimují požadavek do jednoho koherentního cíle. Vstup může začínat jako hrubé vyjádření záměru, ale předtím, než workflow poběží autonomně, musí být dostatečně malý, jasný a bez protimluvů pro provedení.
|
||||||
|
|
||||||
|
Záměr může přijít v mnoha formách: pár frází, odkaz na bug tracker, výstup z plan mode, text zkopírovaný z chatové relace, nebo dokonce číslo story z BMAD vlastního `epics.md`. V posledním případě workflow nepochopí sémantiku sledování stories BMAD, ale stále může vzít samotnou story a pracovat s ní.
|
||||||
|
|
||||||
|
Tento workflow neodstraňuje lidskou kontrolu. Přemisťuje ji na malý počet vysoce hodnotných momentů:
|
||||||
|
|
||||||
|
- **Vyjasnění záměru** — přeměna nepřehledného požadavku na jeden koherentní cíl bez skrytých protimluvů
|
||||||
|
- **Schválení specifikace** — potvrzení, že zmrazené porozumění je správná věc k budování
|
||||||
|
- **Revize konečného produktu** — primární kontrolní bod, kde člověk rozhoduje, zda je výsledek přijatelný
|
||||||
|
|
||||||
|
### 2. Nasměrujte na nejmenší bezpečnou cestu
|
||||||
|
|
||||||
|
Jakmile je cíl jasný, workflow rozhodne, zda jde o skutečnou jednorázovou změnu nebo zda potřebuje plnější cestu. Malé změny s nulovým blast-radius mohou jít přímo k implementaci. Vše ostatní prochází plánováním, aby model měl silnější hranici před tím, než poběží déle samostatně.
|
||||||
|
|
||||||
|
### 3. Běžte déle s menším dozorem
|
||||||
|
|
||||||
|
Po tomto rozhodnutí o směrování může model nést více práce samostatně. Na plnější cestě se schválená specifikace stává hranicí, proti které model provádí s menším dozorem, což je celý smysl designu.
|
||||||
|
|
||||||
|
### 4. Diagnostikujte selhání na správné vrstvě
|
||||||
|
|
||||||
|
Pokud je implementace špatná, protože byl špatný záměr, oprava kódu je špatná oprava. Pokud je kód špatný, protože specifikace byla slabá, oprava diffu je také špatná oprava. Workflow je navržen tak, aby diagnostikoval, kde selhání vstoupilo do systému, vrátil se na tu vrstvu a přegeneroval odtamtud.
|
||||||
|
|
||||||
|
Nálezy revize se používají k rozhodnutí, zda problém pochází ze záměru, generování specifikace nebo lokální implementace. Pouze skutečně lokální problémy se opravují lokálně.
|
||||||
|
|
||||||
|
### 5. Přiveďte člověka zpět pouze když je potřeba
|
||||||
|
|
||||||
|
Interview o záměru je human-in-the-loop, ale není to stejný druh přerušení jako opakující se kontrolní bod. Workflow se snaží udržet tyto opakující se kontrolní body na minimu. Po úvodním formování záměru se člověk vrací hlavně tehdy, když workflow nemůže bezpečně pokračovat bez úsudku a na konci, když je čas zkontrolovat výsledek.
|
||||||
|
|
||||||
|
- **Řešení mezer v záměru** — vstoupení zpět, když revize prokáže, že workflow nemohl bezpečně odvodit, co bylo myšleno
|
||||||
|
|
||||||
|
Vše ostatní je kandidátem na delší autonomní provádění. Tento kompromis je záměrný. Starší vzory věnují více lidské pozornosti nepřetržitému dozoru. Quick Dev věnuje více důvěry modelu, ale šetří lidskou pozornost pro momenty, kde má lidské uvažování nejvyšší páku.
|
||||||
|
|
||||||
|
## Proč systém revize záleží
|
||||||
|
|
||||||
|
Fáze revize není jen pro hledání chyb. Je tu pro směrování korekce bez ničení momentum.
|
||||||
|
|
||||||
|
Tento workflow funguje nejlépe na platformě, která může spouštět sub-agenty, nebo alespoň vyvolat jiné LLM přes příkazovou řádku a čekat na výsledek. Pokud to vaše platforma nativně nepodporuje, můžete přidat skill, který to udělá. Bezcontextové sub-agenty jsou základním kamenem designu revize.
|
||||||
|
|
||||||
|
Agentní revize často selhávají dvěma způsoby:
|
||||||
|
|
||||||
|
- Generují příliš mnoho nálezů, čímž nutí člověka prosévat šum.
|
||||||
|
- Vychýlí aktuální změnu odhalením nesouvisejících problémů a přemění každý běh na ad-hoc úklidový projekt.
|
||||||
|
|
||||||
|
Quick Dev řeší obojí tím, že s revizí zachází jako s triáží.
|
||||||
|
|
||||||
|
Některé nálezy patří k aktuální změně. Některé ne. Pokud je nález náhodný spíše než kauzálně vázaný na aktuální práci, workflow ho může odložit místo nucení člověka ho okamžitě řešit. To udržuje běh zaměřený a zabraňuje náhodným tangentám ve spotřebování rozpočtu pozornosti.
|
||||||
|
|
||||||
|
Ta triáž bude někdy nedokonalá. To je přijatelné. Obvykle je lepší špatně posoudit některé nálezy než zaplavit člověka tisíci nízkohodnotných revizních komentářů. Systém optimalizuje pro kvalitu signálu, ne vyčerpávající recall.
|
||||||
|
|
@ -0,0 +1,76 @@
|
||||||
|
---
|
||||||
|
title: "Proč je solutioning důležitý"
|
||||||
|
description: Pochopení toho, proč je fáze solutioningu klíčová pro projekty s více epicy
|
||||||
|
sidebar:
|
||||||
|
order: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
Fáze 3 (Solutioning) překládá **co** budovat (z plánování) na **jak** to budovat (technický návrh). Tato fáze zabraňuje konfliktům agentů v projektech s více epicy tím, že dokumentuje architektonická rozhodnutí před zahájením implementace.
|
||||||
|
|
||||||
|
## Problém bez solutioningu
|
||||||
|
|
||||||
|
```text
|
||||||
|
Agent 1 implementuje Epic 1 pomocí REST API
|
||||||
|
Agent 2 implementuje Epic 2 pomocí GraphQL
|
||||||
|
Výsledek: Nekonzistentní design API, integrační noční můra
|
||||||
|
```
|
||||||
|
|
||||||
|
Když více agentů implementuje různé části systému bez sdíleného architektonického vedení, dělají nezávislá technická rozhodnutí, která si mohou odporovat.
|
||||||
|
|
||||||
|
## Řešení se solutioningem
|
||||||
|
|
||||||
|
```text
|
||||||
|
Architektonický workflow rozhodne: "Použít GraphQL pro všechna API"
|
||||||
|
Všichni agenti dodržují architektonická rozhodnutí
|
||||||
|
Výsledek: Konzistentní implementace, žádné konflikty
|
||||||
|
```
|
||||||
|
|
||||||
|
Explicitní dokumentací technických rozhodnutí všichni agenti implementují konzistentně a integrace se stává přímočarou.
|
||||||
|
|
||||||
|
## Solutioning vs. plánování
|
||||||
|
|
||||||
|
| Aspekt | Plánování (Fáze 2) | Solutioning (Fáze 3) |
|
||||||
|
| -------- | ----------------------- | --------------------------------- |
|
||||||
|
| Otázka | Co a proč? | Jak? Pak jaké jednotky práce? |
|
||||||
|
| Výstup | FR/NFR (požadavky) | Architektura + epicy/stories |
|
||||||
|
| Agent | PM | Architect → PM |
|
||||||
|
| Publikum | Zainteresované strany | Vývojáři |
|
||||||
|
| Dokument | PRD (FR/NFR) | Architektura + soubory epiců |
|
||||||
|
| Úroveň | Obchodní logika | Technický design + rozklad práce |
|
||||||
|
|
||||||
|
## Klíčový princip
|
||||||
|
|
||||||
|
**Učiňte technická rozhodnutí explicitní a zdokumentovaná**, aby všichni agenti implementovali konzistentně.
|
||||||
|
|
||||||
|
Toto zabraňuje:
|
||||||
|
- Konfliktům stylu API (REST vs GraphQL)
|
||||||
|
- Nekonzistencím v návrhu databáze
|
||||||
|
- Neshodám v řízení stavu
|
||||||
|
- Nesouladu konvencí pojmenování
|
||||||
|
- Variacím v bezpečnostním přístupu
|
||||||
|
|
||||||
|
## Kdy je solutioning vyžadován
|
||||||
|
|
||||||
|
| Cesta | Solutioning vyžadován? |
|
||||||
|
|-------|----------------------|
|
||||||
|
| Quick Flow | Ne — přeskočte úplně |
|
||||||
|
| BMad Method Simple | Volitelný |
|
||||||
|
| BMad Method Complex | Ano |
|
||||||
|
| Enterprise | Ano |
|
||||||
|
|
||||||
|
:::tip[Pravidlo palce]
|
||||||
|
Pokud máte více epiců, které by mohly být implementovány různými agenty, potřebujete solutioning.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Cena přeskočení
|
||||||
|
|
||||||
|
Přeskočení solutioningu u složitých projektů vede k:
|
||||||
|
|
||||||
|
- **Integračním problémům** objeveným uprostřed sprintu
|
||||||
|
- **Přepracování** kvůli konfliktním implementacím
|
||||||
|
- **Delšímu celkovému času vývoje**
|
||||||
|
- **Technickému dluhu** z nekonzistentních vzorů
|
||||||
|
|
||||||
|
:::caution[Multiplikátor nákladů]
|
||||||
|
Zachycení problémů se zarovnáním v solutioningu je 10× rychlejší než jejich objevení během implementace.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,171 @@
|
||||||
|
---
|
||||||
|
title: "Jak přizpůsobit BMad"
|
||||||
|
description: Přizpůsobení agentů, workflow a modulů se zachováním kompatibility s aktualizacemi
|
||||||
|
sidebar:
|
||||||
|
order: 7
|
||||||
|
---
|
||||||
|
|
||||||
|
Použijte soubory `.customize.yaml` k přizpůsobení chování agentů, person a nabídek při zachování vašich změn napříč aktualizacemi.
|
||||||
|
|
||||||
|
## Kdy to použít
|
||||||
|
|
||||||
|
- Chcete změnit jméno, osobnost nebo komunikační styl agenta
|
||||||
|
- Potřebujete, aby si agenti pamatovali kontextově specifické informace projektu
|
||||||
|
- Chcete přidat vlastní položky nabídky, které spouštějí vaše vlastní workflow nebo prompty
|
||||||
|
- Chcete, aby agenti prováděli specifické akce při každém spuštění
|
||||||
|
|
||||||
|
:::note[Předpoklady]
|
||||||
|
- BMad nainstalován ve vašem projektu (viz [Jak nainstalovat BMad](./install-bmad.md))
|
||||||
|
- Textový editor pro YAML soubory
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::caution[Chraňte svá přizpůsobení]
|
||||||
|
Vždy používejte soubory `.customize.yaml` popsané zde místo přímé editace souborů agentů. Instalátor přepíše soubory agentů během aktualizací, ale zachová vaše změny v `.customize.yaml`.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Kroky
|
||||||
|
|
||||||
|
### 1. Najděte soubory přizpůsobení
|
||||||
|
|
||||||
|
Po instalaci najdete jeden soubor `.customize.yaml` na agenta v:
|
||||||
|
|
||||||
|
```text
|
||||||
|
_bmad/_config/agents/
|
||||||
|
├── core-bmad-master.customize.yaml
|
||||||
|
├── bmm-dev.customize.yaml
|
||||||
|
├── bmm-pm.customize.yaml
|
||||||
|
└── ... (jeden soubor na instalovaného agenta)
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Upravte soubor přizpůsobení
|
||||||
|
|
||||||
|
Otevřete soubor `.customize.yaml` pro agenta, kterého chcete upravit. Každá sekce je volitelná — přizpůsobte pouze to, co potřebujete.
|
||||||
|
|
||||||
|
| Sekce | Chování | Účel |
|
||||||
|
| ------------------ | --------- | -------------------------------------------------------- |
|
||||||
|
| `agent.metadata` | Nahrazuje | Přepsat zobrazované jméno agenta |
|
||||||
|
| `persona` | Nahrazuje | Nastavit roli, identitu, styl a principy |
|
||||||
|
| `memories` | Přidává | Přidat trvalý kontext, který si agent vždy pamatuje |
|
||||||
|
| `menu` | Přidává | Přidat vlastní položky nabídky pro workflow nebo prompty |
|
||||||
|
| `critical_actions` | Přidává | Definovat instrukce při spuštění agenta |
|
||||||
|
| `prompts` | Přidává | Vytvořit znovupoužitelné prompty pro akce nabídky |
|
||||||
|
|
||||||
|
Sekce označené **Nahrazuje** zcela přepíší výchozí hodnoty agenta. Sekce označené **Přidává** doplní existující konfiguraci.
|
||||||
|
|
||||||
|
**Jméno agenta**
|
||||||
|
|
||||||
|
Změňte, jak se agent představí:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
agent:
|
||||||
|
metadata:
|
||||||
|
name: 'Spongebob' # Výchozí: "Amelia"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Persona**
|
||||||
|
|
||||||
|
Nahraďte osobnost, roli a komunikační styl agenta:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
persona:
|
||||||
|
role: 'Senior Full-Stack Engineer'
|
||||||
|
identity: 'Lives in a pineapple (under the sea)'
|
||||||
|
communication_style: 'Spongebob annoying'
|
||||||
|
principles:
|
||||||
|
- 'Never Nester, Spongebob Devs hate nesting more than 2 levels deep'
|
||||||
|
- 'Favor composition over inheritance'
|
||||||
|
```
|
||||||
|
|
||||||
|
Sekce `persona` nahrazuje celou výchozí personu, takže nastavte všechna čtyři pole.
|
||||||
|
|
||||||
|
**Memories**
|
||||||
|
|
||||||
|
Přidejte trvalý kontext, který si agent bude vždy pamatovat:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
memories:
|
||||||
|
- 'Works at Krusty Krab'
|
||||||
|
- 'Favorite Celebrity: David Hasselhoff'
|
||||||
|
- 'Learned in Epic 1 that it is not cool to just pretend that tests have passed'
|
||||||
|
```
|
||||||
|
|
||||||
|
**Položky nabídky**
|
||||||
|
|
||||||
|
Přidejte vlastní záznamy do nabídky agenta. Každá položka potřebuje `trigger`, cíl (`workflow` cestu nebo `action` referenci) a `description`:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
menu:
|
||||||
|
- trigger: my-workflow
|
||||||
|
workflow: 'my-custom/workflows/my-workflow.yaml'
|
||||||
|
description: My custom workflow
|
||||||
|
- trigger: deploy
|
||||||
|
action: '#deploy-prompt'
|
||||||
|
description: Deploy to production
|
||||||
|
```
|
||||||
|
|
||||||
|
**Kritické akce**
|
||||||
|
|
||||||
|
Definujte instrukce, které se spustí při startu agenta:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
critical_actions:
|
||||||
|
- 'Check the CI Pipelines with the XYZ Skill and alert user on wake if anything is urgently needing attention'
|
||||||
|
```
|
||||||
|
|
||||||
|
**Vlastní prompty**
|
||||||
|
|
||||||
|
Vytvořte znovupoužitelné prompty, na které mohou položky nabídky odkazovat s `action="#id"`:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
prompts:
|
||||||
|
- id: deploy-prompt
|
||||||
|
content: |
|
||||||
|
Deploy the current branch to production:
|
||||||
|
1. Run all tests
|
||||||
|
2. Build the project
|
||||||
|
3. Execute deployment script
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. Aplikujte změny
|
||||||
|
|
||||||
|
Po editaci přeinstalujte pro aplikaci změn:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install
|
||||||
|
```
|
||||||
|
|
||||||
|
Instalátor detekuje existující instalaci a nabídne tyto možnosti:
|
||||||
|
|
||||||
|
| Možnost | Co udělá |
|
||||||
|
| ---------------------------- | ---------------------------------------------------------------------- |
|
||||||
|
| **Quick Update** | Aktualizuje všechny moduly na nejnovější verzi a aplikuje přizpůsobení |
|
||||||
|
| **Modify BMad Installation** | Plný instalační postup pro přidání nebo odebrání modulů |
|
||||||
|
|
||||||
|
Pro změny pouze přizpůsobení je **Quick Update** nejrychlejší možnost.
|
||||||
|
|
||||||
|
## Řešení problémů
|
||||||
|
|
||||||
|
**Změny se nezobrazují?**
|
||||||
|
|
||||||
|
- Spusťte `npx bmad-method install` a vyberte **Quick Update** pro aplikaci změn
|
||||||
|
- Zkontrolujte, že vaše YAML syntaxe je platná (na odsazení záleží)
|
||||||
|
- Ověřte, že jste upravili správný soubor `.customize.yaml` pro daného agenta
|
||||||
|
|
||||||
|
**Agent se nenačítá?**
|
||||||
|
|
||||||
|
- Zkontrolujte YAML syntaxi pomocí online YAML validátoru
|
||||||
|
- Ujistěte se, že jste nenechali pole prázdná po odkomentování
|
||||||
|
- Zkuste se vrátit k původní šabloně a znovu sestavit
|
||||||
|
|
||||||
|
**Potřebujete resetovat agenta?**
|
||||||
|
|
||||||
|
- Vymažte nebo smažte soubor `.customize.yaml` agenta
|
||||||
|
- Spusťte `npx bmad-method install` a vyberte **Quick Update** pro obnovení výchozích hodnot
|
||||||
|
|
||||||
|
## Přizpůsobení workflow
|
||||||
|
|
||||||
|
Přizpůsobení existujících BMad Method workflow a skills přijde brzy.
|
||||||
|
|
||||||
|
## Přizpůsobení modulů
|
||||||
|
|
||||||
|
Návod na tvorbu rozšiřujících modulů a přizpůsobení existujících modulů přijde brzy.
|
||||||
|
|
@ -0,0 +1,117 @@
|
||||||
|
---
|
||||||
|
title: "Existující projekty"
|
||||||
|
description: Jak používat BMad Method na existujících kódových bázích
|
||||||
|
sidebar:
|
||||||
|
order: 6
|
||||||
|
---
|
||||||
|
|
||||||
|
Používejte BMad Method efektivně při práci na existujících projektech a starších kódových bázích.
|
||||||
|
|
||||||
|
Tento návod pokrývá základní workflow pro zapojení se do existujících projektů s BMad Method.
|
||||||
|
|
||||||
|
:::note[Předpoklady]
|
||||||
|
- BMad Method nainstalován (`npx bmad-method install`)
|
||||||
|
- Existující kódová báze, na které chcete pracovat
|
||||||
|
- Přístup k AI-powered IDE (Claude Code nebo Cursor)
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Krok 1: Vyčistěte dokončené plánovací artefakty
|
||||||
|
|
||||||
|
Pokud jste dokončili všechny PRD epicy a stories procesem BMad, vyčistěte tyto soubory. Archivujte je, smažte nebo se spoléhejte na historii verzí. Nenechávejte tyto soubory v:
|
||||||
|
|
||||||
|
- `docs/`
|
||||||
|
- `_bmad-output/planning-artifacts/`
|
||||||
|
- `_bmad-output/implementation-artifacts/`
|
||||||
|
|
||||||
|
## Krok 2: Vytvořte kontext projektu
|
||||||
|
|
||||||
|
:::tip[Doporučeno pro existující projekty]
|
||||||
|
Vygenerujte `project-context.md` pro zachycení vzorů a konvencí vaší existující kódové báze. Tím zajistíte, že AI agenti budou při implementaci změn dodržovat vaše zavedené postupy.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Spusťte workflow pro generování kontextu projektu:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Toto skenuje vaši kódovou bázi a identifikuje:
|
||||||
|
- Technologický stack a verze
|
||||||
|
- Vzory organizace kódu
|
||||||
|
- Konvence pojmenování
|
||||||
|
- Přístupy k testování
|
||||||
|
- Vzory specifické pro framework
|
||||||
|
|
||||||
|
Vygenerovaný soubor můžete zkontrolovat a upravit, nebo ho vytvořit ručně na `_bmad-output/project-context.md`.
|
||||||
|
|
||||||
|
[Zjistit více o kontextu projektu](../explanation/project-context.md)
|
||||||
|
|
||||||
|
## Krok 3: Udržujte kvalitní projektovou dokumentaci
|
||||||
|
|
||||||
|
Vaše složka `docs/` by měla obsahovat stručnou, dobře organizovanou dokumentaci, která přesně reprezentuje váš projekt:
|
||||||
|
|
||||||
|
- Záměr a obchodní zdůvodnění
|
||||||
|
- Obchodní pravidla
|
||||||
|
- Architektura
|
||||||
|
- Jakékoli další relevantní informace o projektu
|
||||||
|
|
||||||
|
Pro složité projekty zvažte použití workflow `bmad-document-project`. Nabízí varianty, které proskenují celý váš projekt a zdokumentují jeho aktuální stav.
|
||||||
|
|
||||||
|
## Krok 3: Získejte pomoc
|
||||||
|
|
||||||
|
### BMad-Help: Váš výchozí bod
|
||||||
|
|
||||||
|
**Spusťte `bmad-help` kdykoli si nejste jisti, co dělat dál.** Tento inteligentní průvodce:
|
||||||
|
|
||||||
|
- Prozkoumá váš projekt a zjistí, co už bylo uděláno
|
||||||
|
- Ukáže možnosti na základě nainstalovaných modulů
|
||||||
|
- Rozumí dotazům v přirozeném jazyce
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help I have an existing Rails app, where should I start?
|
||||||
|
bmad-help What's the difference between quick-flow and full method?
|
||||||
|
bmad-help Show me what workflows are available
|
||||||
|
```
|
||||||
|
|
||||||
|
BMad-Help se také **automaticky spouští na konci každého workflow** a poskytuje jasné pokyny, co přesně dělat dál.
|
||||||
|
|
||||||
|
### Volba přístupu
|
||||||
|
|
||||||
|
Máte dvě hlavní možnosti v závislosti na rozsahu změn:
|
||||||
|
|
||||||
|
| Rozsah | Doporučený přístup |
|
||||||
|
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||||
|
| **Malé aktualizace či doplnění** | Spusťte `bmad-quick-dev` pro vyjasnění záměru, plánování, implementaci a revizi v jednom workflow. Plná čtyřfázová metoda BMad je pravděpodobně přehnaná. |
|
||||||
|
| **Velké změny či doplnění** | Začněte s metodou BMad a aplikujte tolik nebo tak málo důkladnosti, kolik potřebujete. |
|
||||||
|
|
||||||
|
### Během tvorby PRD
|
||||||
|
|
||||||
|
Při vytváření briefu nebo přímém přechodu na PRD zajistěte, aby agent:
|
||||||
|
|
||||||
|
- Našel a analyzoval vaši existující projektovou dokumentaci
|
||||||
|
- Přečetl si správný kontext o vašem aktuálním systému
|
||||||
|
|
||||||
|
Agenta můžete navést explicitně, ale cílem je zajistit, aby se nová funkce dobře integrovala s vaším existujícím systémem.
|
||||||
|
|
||||||
|
### Úvahy o UX
|
||||||
|
|
||||||
|
Práce na UX je volitelná. Rozhodnutí nezávisí na tom, zda váš projekt má UX, ale na:
|
||||||
|
|
||||||
|
- Zda budete pracovat na změnách UX
|
||||||
|
- Zda jsou potřeba významné nové UX návrhy nebo vzory
|
||||||
|
|
||||||
|
Pokud vaše změny představují jednoduché aktualizace existujících obrazovek, se kterými jste spokojeni, plný UX proces je zbytečný.
|
||||||
|
|
||||||
|
### Úvahy o architektuře
|
||||||
|
|
||||||
|
Při práci na architektuře zajistěte, aby architekt:
|
||||||
|
|
||||||
|
- Používal správné zdokumentované soubory
|
||||||
|
- Skenoval existující kódovou bázi
|
||||||
|
|
||||||
|
Věnujte zde zvláštní pozornost, abyste předešli znovuvynalézání kola nebo rozhodnutím, která neodpovídají vaší existující architektuře.
|
||||||
|
|
||||||
|
## Další informace
|
||||||
|
|
||||||
|
- **[Rychlé opravy](./quick-fixes.md)** — Opravy chyb a ad-hoc změny
|
||||||
|
- **[FAQ pro existující projekty](../explanation/established-projects-faq.md)** — Časté otázky o práci na existujících projektech
|
||||||
|
|
@ -0,0 +1,110 @@
|
||||||
|
---
|
||||||
|
title: "Jak získat odpovědi o BMad"
|
||||||
|
description: Použijte LLM k rychlému zodpovězení vašich otázek o BMad
|
||||||
|
sidebar:
|
||||||
|
order: 4
|
||||||
|
---
|
||||||
|
|
||||||
|
## Začněte zde: BMad-Help
|
||||||
|
|
||||||
|
**Nejrychlejší způsob, jak získat odpovědi o BMad, je skill `bmad-help`.** Tento inteligentní průvodce zodpoví více než 80 % všech otázek a je vám k dispozici přímo ve vašem IDE při práci.
|
||||||
|
|
||||||
|
BMad-Help je víc než vyhledávací nástroj — umí:
|
||||||
|
- **Prozkoumat váš projekt** a zjistit, co už bylo dokončeno
|
||||||
|
- **Rozumět přirozenému jazyku** — ptejte se běžnou řečí
|
||||||
|
- **Přizpůsobit se nainstalovaným modulům** — zobrazí relevantní možnosti
|
||||||
|
- **Automaticky se spouštět po workflow** — řekne vám přesně, co dělat dál
|
||||||
|
- **Doporučit první povinný úkol** — žádné hádání, kde začít
|
||||||
|
|
||||||
|
### Jak používat BMad-Help
|
||||||
|
|
||||||
|
Zavolejte ho jménem ve vaší AI relaci:
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help
|
||||||
|
```
|
||||||
|
|
||||||
|
:::tip
|
||||||
|
V závislosti na vaší platformě můžete také použít `/bmad-help` nebo `$bmad-help`, ale samotné `bmad-help` by mělo fungovat všude.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Spojte ho s dotazem v přirozeném jazyce:
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help I have a SaaS idea and know all the features. Where do I start?
|
||||||
|
bmad-help What are my options for UX design?
|
||||||
|
bmad-help I'm stuck on the PRD workflow
|
||||||
|
bmad-help Show me what's been done so far
|
||||||
|
```
|
||||||
|
|
||||||
|
BMad-Help odpoví:
|
||||||
|
- Co je doporučeno pro vaši situaci
|
||||||
|
- Jaký je první povinný úkol
|
||||||
|
- Jak vypadá zbytek procesu
|
||||||
|
|
||||||
|
## Kdy použít tohoto průvodce
|
||||||
|
|
||||||
|
Použijte tuto sekci, když:
|
||||||
|
- Chcete pochopit architekturu nebo interní fungování BMad
|
||||||
|
- Potřebujete odpovědi mimo to, co BMad-Help nabízí
|
||||||
|
- Zkoumáte BMad před instalací
|
||||||
|
- Chcete prozkoumat zdrojový kód přímo
|
||||||
|
|
||||||
|
## Kroky
|
||||||
|
|
||||||
|
### 1. Vyberte si zdroj
|
||||||
|
|
||||||
|
| Zdroj | Nejlepší pro | Příklady |
|
||||||
|
| -------------------- | ----------------------------------------- | ---------------------------- |
|
||||||
|
| **Složka `_bmad`** | Jak BMad funguje — agenti, workflow, prompty | „Co dělá PM agent?“ |
|
||||||
|
| **Celý GitHub repo** | Historie, instalátor, architektura | „Co se změnilo ve v6?“ |
|
||||||
|
| **`llms-full.txt`** | Rychlý přehled z dokumentace | „Vysvětli čtyři fáze BMad“ |
|
||||||
|
|
||||||
|
Složka `_bmad` se vytvoří při instalaci BMad. Pokud ji ještě nemáte, naklonujte si repo.
|
||||||
|
|
||||||
|
### 2. Nasměrujte AI na zdroj
|
||||||
|
|
||||||
|
**Pokud vaše AI umí číst soubory (Claude Code, Cursor atd.):**
|
||||||
|
|
||||||
|
- **BMad nainstalován:** Nasměrujte na složku `_bmad` a ptejte se přímo
|
||||||
|
- **Chcete hlubší kontext:** Naklonujte si [celé repo](https://github.com/bmad-code-org/BMAD-METHOD)
|
||||||
|
|
||||||
|
**Pokud používáte ChatGPT nebo Claude.ai:**
|
||||||
|
|
||||||
|
Načtěte `llms-full.txt` do vaší relace:
|
||||||
|
|
||||||
|
```text
|
||||||
|
https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. Položte svou otázku
|
||||||
|
|
||||||
|
:::note[Příklad]
|
||||||
|
**O:** „Řekni mi nejrychlejší způsob, jak něco vytvořit s BMad“
|
||||||
|
|
||||||
|
**A:** Použijte Quick Flow: Spusťte `bmad-quick-dev` — vyjasní váš záměr, naplánuje, implementuje, zreviduje a prezentuje výsledky v jednom workflow, přeskočí celé fáze plánování.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Co získáte
|
||||||
|
|
||||||
|
Přímé odpovědi o BMad — jak agenti fungují, co dělají workflow, proč jsou věci strukturované tak, jak jsou — bez čekání na odpověď od někoho jiného.
|
||||||
|
|
||||||
|
## Tipy
|
||||||
|
|
||||||
|
- **Ověřte překvapivé odpovědi** — LLM se občas mýlí. Zkontrolujte zdrojový soubor nebo se zeptejte na Discordu.
|
||||||
|
- **Buďte konkrétní** — „Co dělá krok 3 PRD workflow?“ je lepší než „Jak funguje PRD?“
|
||||||
|
|
||||||
|
## Stále jste uvízli?
|
||||||
|
|
||||||
|
Zkusili jste přístup přes LLM a stále potřebujete pomoc? Nyní máte mnohem lepší otázku k položení.
|
||||||
|
|
||||||
|
| Kanál | Použijte pro |
|
||||||
|
| ------------------------- | ------------------------------------------- |
|
||||||
|
| `#bmad-method-help` | Rychlé otázky (chat v reálném čase) |
|
||||||
|
| `help-requests` fórum | Detailní otázky (vyhledatelné, trvalé) |
|
||||||
|
| `#suggestions-feedback` | Nápady a požadavky na funkce |
|
||||||
|
| `#report-bugs-and-issues` | Hlášení chyb |
|
||||||
|
|
||||||
|
**Discord:** [discord.gg/gk8jAdXWmj](https://discord.gg/gk8jAdXWmj)
|
||||||
|
|
||||||
|
**GitHub Issues:** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) (pro jasné chyby)
|
||||||
|
|
@ -0,0 +1,116 @@
|
||||||
|
---
|
||||||
|
title: "Jak nainstalovat BMad"
|
||||||
|
description: Průvodce instalací BMad ve vašem projektu krok za krokem
|
||||||
|
sidebar:
|
||||||
|
order: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
Použijte příkaz `npx bmad-method install` k nastavení BMad ve vašem projektu s výběrem modulů a AI nástrojů.
|
||||||
|
|
||||||
|
Pokud chcete použít neinteraktivní instalátor a zadat všechny možnosti na příkazové řádce, podívejte se na [tento návod](./non-interactive-installation.md).
|
||||||
|
|
||||||
|
## Kdy to použít
|
||||||
|
|
||||||
|
- Začínáte nový projekt s BMad
|
||||||
|
- Přidáváte BMad do existující kódové báze
|
||||||
|
- Aktualizujete stávající instalaci BMad
|
||||||
|
|
||||||
|
:::note[Předpoklady]
|
||||||
|
- **Node.js** 20+ (vyžadováno pro instalátor)
|
||||||
|
- **Git** (doporučeno)
|
||||||
|
- **AI nástroj** (Claude Code, Cursor nebo podobný)
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Kroky
|
||||||
|
|
||||||
|
### 1. Spusťte instalátor
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install
|
||||||
|
```
|
||||||
|
|
||||||
|
:::tip[Chcete nejnovější prereleaseový build?]
|
||||||
|
Použijte dist-tag `next`:
|
||||||
|
```bash
|
||||||
|
npx bmad-method@next install
|
||||||
|
```
|
||||||
|
|
||||||
|
Získáte novější změny dříve, s vyšší šancí na nestabilitu oproti výchozí instalaci.
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::tip[Bleeding edge]
|
||||||
|
Pro instalaci nejnovější verze z hlavní větve (může být nestabilní):
|
||||||
|
```bash
|
||||||
|
npx github:bmad-code-org/BMAD-METHOD install
|
||||||
|
```
|
||||||
|
:::
|
||||||
|
|
||||||
|
### 2. Zvolte umístění instalace
|
||||||
|
|
||||||
|
Instalátor se zeptá, kam nainstalovat soubory BMad:
|
||||||
|
|
||||||
|
- Aktuální adresář (doporučeno pro nové projekty, pokud jste adresář vytvořili sami a spouštíte z něj)
|
||||||
|
- Vlastní cesta
|
||||||
|
|
||||||
|
### 3. Vyberte své AI nástroje
|
||||||
|
|
||||||
|
Vyberte, které AI nástroje používáte:
|
||||||
|
|
||||||
|
- Claude Code
|
||||||
|
- Cursor
|
||||||
|
- Ostatní
|
||||||
|
|
||||||
|
Každý nástroj má svůj vlastní způsob integrace skills. Instalátor vytvoří drobné prompt soubory pro aktivaci workflow a agentů — jednoduše je umístí tam, kde je váš nástroj očekává.
|
||||||
|
|
||||||
|
:::note[Povolení skills]
|
||||||
|
Některé platformy vyžadují explicitní povolení skills v nastavení, než se zobrazí. Pokud nainstalujete BMad a nevidíte skills, zkontrolujte nastavení vaší platformy nebo se zeptejte svého AI asistenta, jak skills povolit.
|
||||||
|
:::
|
||||||
|
|
||||||
|
### 4. Zvolte moduly
|
||||||
|
|
||||||
|
Instalátor zobrazí dostupné moduly. Vyberte ty, které potřebujete — většina uživatelů chce pouze **BMad Method** (modul pro vývoj softwaru).
|
||||||
|
|
||||||
|
### 5. Následujte výzvy
|
||||||
|
|
||||||
|
Instalátor vás provede zbytkem — vlastní obsah, nastavení atd.
|
||||||
|
|
||||||
|
## Co získáte
|
||||||
|
|
||||||
|
```text
|
||||||
|
váš-projekt/
|
||||||
|
├── _bmad/
|
||||||
|
│ ├── bmm/ # Vaše vybrané moduly
|
||||||
|
│ │ └── config.yaml # Nastavení modulu (pokud byste ho někdy potřebovali změnit)
|
||||||
|
│ ├── core/ # Povinný základní modul
|
||||||
|
│ └── ...
|
||||||
|
├── _bmad-output/ # Generované artefakty
|
||||||
|
├── .claude/ # Claude Code skills (pokud používáte Claude Code)
|
||||||
|
│ └── skills/
|
||||||
|
│ ├── bmad-help/
|
||||||
|
│ ├── bmad-persona/
|
||||||
|
│ └── ...
|
||||||
|
└── .cursor/ # Cursor skills (pokud používáte Cursor)
|
||||||
|
└── skills/
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
|
||||||
|
## Ověření instalace
|
||||||
|
|
||||||
|
Spusťte `bmad-help` pro ověření, že vše funguje, a zjistěte, co dělat dál.
|
||||||
|
|
||||||
|
**BMad-Help je váš inteligentní průvodce**, který:
|
||||||
|
- Potvrdí, že vaše instalace funguje
|
||||||
|
- Ukáže, co je dostupné na základě nainstalovaných modulů
|
||||||
|
- Doporučí váš první krok
|
||||||
|
|
||||||
|
Můžete mu také klást otázky:
|
||||||
|
```
|
||||||
|
bmad-help I just installed, what should I do first?
|
||||||
|
bmad-help What are my options for a SaaS project?
|
||||||
|
```
|
||||||
|
|
||||||
|
## Řešení problémů
|
||||||
|
|
||||||
|
**Instalátor vyhodí chybu** — Zkopírujte výstup do svého AI asistenta a nechte ho to vyřešit.
|
||||||
|
|
||||||
|
**Instalátor fungoval, ale něco nefunguje později** — Vaše AI potřebuje kontext BMad, aby pomohla. Podívejte se na [Jak získat odpovědi o BMad](./get-answers-about-bmad.md) pro návod, jak nasměrovat AI na správné zdroje.
|
||||||
|
|
@ -0,0 +1,171 @@
|
||||||
|
---
|
||||||
|
title: Neinteraktivní instalace
|
||||||
|
description: Instalace BMad pomocí příznaků příkazové řádky pro CI/CD pipelines a automatizované nasazení
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Použijte příznaky příkazové řádky k neinteraktivní instalaci BMad. To je užitečné pro:
|
||||||
|
|
||||||
|
## Kdy to použít
|
||||||
|
|
||||||
|
- Automatizovaná nasazení a CI/CD pipelines
|
||||||
|
- Skriptované instalace
|
||||||
|
- Hromadné instalace napříč více projekty
|
||||||
|
- Rychlé instalace se známými konfiguracemi
|
||||||
|
|
||||||
|
:::note[Předpoklady]
|
||||||
|
Vyžaduje [Node.js](https://nodejs.org) v20+ a `npx` (součástí npm).
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Dostupné příznaky
|
||||||
|
|
||||||
|
### Možnosti instalace
|
||||||
|
|
||||||
|
| Příznak | Popis | Příklad |
|
||||||
|
|---------|-------|---------|
|
||||||
|
| `--directory <cesta>` | Instalační adresář | `--directory ~/projects/myapp` |
|
||||||
|
| `--modules <moduly>` | Čárkou oddělená ID modulů | `--modules bmm,bmb` |
|
||||||
|
| `--tools <nástroje>` | Čárkou oddělená ID nástrojů/IDE (použijte `none` pro přeskočení) | `--tools claude-code,cursor` nebo `--tools none` |
|
||||||
|
| `--custom-content <cesty>` | Čárkou oddělené cesty k vlastním modulům | `--custom-content ~/my-module,~/another-module` |
|
||||||
|
| `--action <typ>` | Akce pro existující instalace: `install` (výchozí), `update` nebo `quick-update` | `--action quick-update` |
|
||||||
|
|
||||||
|
### Základní konfigurace
|
||||||
|
|
||||||
|
| Příznak | Popis | Výchozí |
|
||||||
|
|---------|-------|---------|
|
||||||
|
| `--user-name <jméno>` | Jméno, které agenti použijí | Systémové uživatelské jméno |
|
||||||
|
| `--communication-language <jazyk>` | Jazyk komunikace agentů | English |
|
||||||
|
| `--document-output-language <jazyk>` | Jazyk výstupních dokumentů | English |
|
||||||
|
| `--output-folder <cesta>` | Cesta k výstupní složce | _bmad-output |
|
||||||
|
|
||||||
|
### Další možnosti
|
||||||
|
|
||||||
|
| Příznak | Popis |
|
||||||
|
|---------|-------|
|
||||||
|
| `-y, --yes` | Přijmout všechna výchozí nastavení a přeskočit výzvy |
|
||||||
|
| `-d, --debug` | Povolit ladící výstup pro generování manifestu |
|
||||||
|
|
||||||
|
## ID modulů
|
||||||
|
|
||||||
|
Dostupná ID modulů pro příznak `--modules`:
|
||||||
|
|
||||||
|
- `bmm` — BMad Method Master
|
||||||
|
- `bmb` — BMad Builder
|
||||||
|
|
||||||
|
Zkontrolujte [registr BMad](https://github.com/bmad-code-org) pro dostupné externí moduly.
|
||||||
|
|
||||||
|
## ID nástrojů/IDE
|
||||||
|
|
||||||
|
Dostupná ID nástrojů pro příznak `--tools`:
|
||||||
|
|
||||||
|
**Preferované:** `claude-code`, `cursor`
|
||||||
|
|
||||||
|
Spusťte `npx bmad-method install` interaktivně jednou pro zobrazení aktuálního seznamu podporovaných nástrojů, nebo zkontrolujte [konfiguraci kódů platforem](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/cli/installers/lib/ide/platform-codes.yaml).
|
||||||
|
|
||||||
|
## Režimy instalace
|
||||||
|
|
||||||
|
| Režim | Popis | Příklad |
|
||||||
|
|-------|-------|---------|
|
||||||
|
| Plně neinteraktivní | Zadejte všechny příznaky pro přeskočení výzev | `npx bmad-method install --directory . --modules bmm --tools claude-code --yes` |
|
||||||
|
| Polo-interaktivní | Zadejte některé příznaky; BMad se zeptá na zbytek | `npx bmad-method install --directory . --modules bmm` |
|
||||||
|
| Pouze výchozí | Přijměte vše výchozí s `-y` | `npx bmad-method install --yes` |
|
||||||
|
| Bez nástrojů | Přeskočte konfiguraci nástrojů/IDE | `npx bmad-method install --modules bmm --tools none` |
|
||||||
|
|
||||||
|
## Příklady
|
||||||
|
|
||||||
|
### Instalace v CI/CD pipeline
|
||||||
|
|
||||||
|
```bash
|
||||||
|
#!/bin/bash
|
||||||
|
# install-bmad.sh
|
||||||
|
|
||||||
|
npx bmad-method install \
|
||||||
|
--directory "${GITHUB_WORKSPACE}" \
|
||||||
|
--modules bmm \
|
||||||
|
--tools claude-code \
|
||||||
|
--user-name "CI Bot" \
|
||||||
|
--communication-language English \
|
||||||
|
--document-output-language English \
|
||||||
|
--output-folder _bmad-output \
|
||||||
|
--yes
|
||||||
|
```
|
||||||
|
|
||||||
|
### Aktualizace existující instalace
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install \
|
||||||
|
--directory ~/projects/myapp \
|
||||||
|
--action update \
|
||||||
|
--modules bmm,bmb,custom-module
|
||||||
|
```
|
||||||
|
|
||||||
|
### Rychlá aktualizace (zachování nastavení)
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install \
|
||||||
|
--directory ~/projects/myapp \
|
||||||
|
--action quick-update
|
||||||
|
```
|
||||||
|
|
||||||
|
### Instalace s vlastním obsahem
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install \
|
||||||
|
--directory ~/projects/myapp \
|
||||||
|
--modules bmm \
|
||||||
|
--custom-content ~/my-custom-module,~/another-module \
|
||||||
|
--tools claude-code
|
||||||
|
```
|
||||||
|
|
||||||
|
## Co získáte
|
||||||
|
|
||||||
|
- Plně nakonfigurovaný adresář `_bmad/` ve vašem projektu
|
||||||
|
- Agenty a workflow nakonfigurované pro vybrané moduly a nástroje
|
||||||
|
- Složku `_bmad-output/` pro generované artefakty
|
||||||
|
|
||||||
|
## Validace a zpracování chyb
|
||||||
|
|
||||||
|
BMad validuje všechny zadané příznaky:
|
||||||
|
|
||||||
|
- **Adresář** — Musí být platná cesta s oprávněním k zápisu
|
||||||
|
- **Moduly** — Upozorní na neplatná ID modulů (ale nespadne)
|
||||||
|
- **Nástroje** — Upozorní na neplatná ID nástrojů (ale nespadne)
|
||||||
|
- **Vlastní obsah** — Každá cesta musí obsahovat platný soubor `module.yaml`
|
||||||
|
- **Akce** — Musí být jedna z: `install`, `update`, `quick-update`
|
||||||
|
|
||||||
|
Neplatné hodnoty buď:
|
||||||
|
1. Zobrazí chybu a ukončí se (pro kritické možnosti jako adresář)
|
||||||
|
2. Zobrazí varování a přeskočí (pro volitelné položky jako vlastní obsah)
|
||||||
|
3. Přepnou na interaktivní výzvy (pro chybějící povinné hodnoty)
|
||||||
|
|
||||||
|
:::tip[Osvědčené postupy]
|
||||||
|
- Používejte absolutní cesty pro `--directory` pro zamezení nejednoznačnosti
|
||||||
|
- Otestujte příznaky lokálně před použitím v CI/CD pipelines
|
||||||
|
- Kombinujte s `-y` pro skutečně bezobslužné instalace
|
||||||
|
- Použijte `--debug` pokud narazíte na problémy během instalace
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Řešení problémů
|
||||||
|
|
||||||
|
### Instalace selže s „Invalid directory“
|
||||||
|
|
||||||
|
- Cesta k adresáři musí existovat (nebo musí existovat jeho nadřazený adresář)
|
||||||
|
- Potřebujete oprávnění k zápisu
|
||||||
|
- Cesta musí být absolutní nebo správně relativní k aktuálnímu adresáři
|
||||||
|
|
||||||
|
### Modul nenalezen
|
||||||
|
|
||||||
|
- Ověřte, že ID modulu je správné
|
||||||
|
- Externí moduly musí být dostupné v registru
|
||||||
|
|
||||||
|
### Neplatná cesta k vlastnímu obsahu
|
||||||
|
|
||||||
|
Ujistěte se, že každá cesta k vlastnímu obsahu:
|
||||||
|
- Ukazuje na adresář
|
||||||
|
- Obsahuje soubor `module.yaml` v kořeni
|
||||||
|
- Má pole `code` v `module.yaml`
|
||||||
|
|
||||||
|
:::note[Stále jste uvízli?]
|
||||||
|
Spusťte s `--debug` pro detailní výstup, zkuste interaktivní režim pro izolaci problému, nebo nahlaste na <https://github.com/bmad-code-org/BMAD-METHOD/issues>.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,127 @@
|
||||||
|
---
|
||||||
|
title: "Správa kontextu projektu"
|
||||||
|
description: Vytvoření a údržba project-context.md pro vedení AI agentů
|
||||||
|
sidebar:
|
||||||
|
order: 8
|
||||||
|
---
|
||||||
|
|
||||||
|
Použijte soubor `project-context.md` k zajištění toho, aby AI agenti dodržovali technické preference a pravidla implementace vašeho projektu ve všech workflow. Aby byl vždy dostupný, můžete také přidat řádek `Important project context and conventions are located in [cesta k project context]/project-context.md` do souboru kontextu nebo pravidel vašeho nástroje (jako je `AGENTS.md`).
|
||||||
|
|
||||||
|
:::note[Předpoklady]
|
||||||
|
- BMad Method nainstalován
|
||||||
|
- Znalost technologického stacku a konvencí vašeho projektu
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Kdy to použít
|
||||||
|
|
||||||
|
- Máte silné technické preference před začátkem architektury
|
||||||
|
- Dokončili jste architekturu a chcete zachytit rozhodnutí pro implementaci
|
||||||
|
- Pracujete na existující kódové bázi se zavedenými vzory
|
||||||
|
- Všimnete si, že agenti dělají nekonzistentní rozhodnutí napříč stories
|
||||||
|
|
||||||
|
## Krok 1: Vyberte přístup
|
||||||
|
|
||||||
|
**Ruční vytvoření** — Nejlepší, když přesně víte, jaká pravidla chcete dokumentovat
|
||||||
|
|
||||||
|
**Generování po architektuře** — Nejlepší pro zachycení rozhodnutí učiněných během solutioningu
|
||||||
|
|
||||||
|
**Generování pro existující projekty** — Nejlepší pro objevení vzorů v existujících kódových bázích
|
||||||
|
|
||||||
|
## Krok 2: Vytvořte soubor
|
||||||
|
|
||||||
|
### Možnost A: Ruční vytvoření
|
||||||
|
|
||||||
|
Vytvořte soubor na `_bmad-output/project-context.md`:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
mkdir -p _bmad-output
|
||||||
|
touch _bmad-output/project-context.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Přidejte váš technologický stack a pravidla implementace:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
project_name: 'MyProject'
|
||||||
|
user_name: 'YourName'
|
||||||
|
date: '2026-02-15'
|
||||||
|
sections_completed: ['technology_stack', 'critical_rules']
|
||||||
|
---
|
||||||
|
|
||||||
|
# Project Context for AI Agents
|
||||||
|
|
||||||
|
## Technology Stack & Versions
|
||||||
|
|
||||||
|
- Node.js 20.x, TypeScript 5.3, React 18.2
|
||||||
|
- State: Zustand
|
||||||
|
- Testing: Vitest, Playwright
|
||||||
|
- Styling: Tailwind CSS
|
||||||
|
|
||||||
|
## Critical Implementation Rules
|
||||||
|
|
||||||
|
**TypeScript:**
|
||||||
|
- Strict mode enabled, no `any` types
|
||||||
|
- Use `interface` for public APIs, `type` for unions
|
||||||
|
|
||||||
|
**Code Organization:**
|
||||||
|
- Components in `/src/components/` with co-located tests
|
||||||
|
- API calls use `apiClient` singleton — never fetch directly
|
||||||
|
|
||||||
|
**Testing:**
|
||||||
|
- Unit tests focus on business logic
|
||||||
|
- Integration tests use MSW for API mocking
|
||||||
|
```
|
||||||
|
|
||||||
|
### Možnost B: Generování po architektuře
|
||||||
|
|
||||||
|
Spusťte workflow v novém chatu:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Workflow skenuje váš dokument architektury a soubory projektu a generuje kontextový soubor zachycující učiněná rozhodnutí.
|
||||||
|
|
||||||
|
### Možnost C: Generování pro existující projekty
|
||||||
|
|
||||||
|
Pro existující projekty spusťte:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Workflow analyzuje vaši kódovou bázi, identifikuje konvence a vygeneruje kontextový soubor, který můžete zkontrolovat a upřesnit.
|
||||||
|
|
||||||
|
## Krok 3: Ověřte obsah
|
||||||
|
|
||||||
|
Zkontrolujte vygenerovaný soubor a ujistěte se, že zachycuje:
|
||||||
|
|
||||||
|
- Správné verze technologií
|
||||||
|
- Vaše skutečné konvence (ne generické osvědčené postupy)
|
||||||
|
- Pravidla, která předcházejí běžným chybám
|
||||||
|
- Vzory specifické pro framework
|
||||||
|
|
||||||
|
Ručně upravte pro doplnění chybějícího nebo odstranění nepřesností.
|
||||||
|
|
||||||
|
## Co získáte
|
||||||
|
|
||||||
|
Soubor `project-context.md`, který:
|
||||||
|
|
||||||
|
- Zajistí, že všichni agenti dodržují stejné konvence
|
||||||
|
- Zabrání nekonzistentním rozhodnutím napříč stories
|
||||||
|
- Zachytí architektonická rozhodnutí pro implementaci
|
||||||
|
- Slouží jako reference pro vzory a pravidla vašeho projektu
|
||||||
|
|
||||||
|
## Tipy
|
||||||
|
|
||||||
|
:::tip[Osvědčené postupy]
|
||||||
|
- **Zaměřte se na neočividné** — Dokumentujte vzory, které agenti mohou přehlédnout (např. „Použijte JSDoc na každé veřejné třídě“), ne univerzální postupy jako „používejte smysluplné názvy proměnných.“
|
||||||
|
- **Udržujte to stručné** — Tento soubor načítá každý implementační workflow. Dlouhé soubory plýtvají kontextem. Vylučte obsah, který platí pouze pro úzký rozsah nebo specifické stories.
|
||||||
|
- **Aktualizujte dle potřeby** — Upravte ručně, když se vzory změní, nebo přegenerujte po významných změnách architektury.
|
||||||
|
- Funguje pro projekty Quick Flow i plné metody BMad.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Další kroky
|
||||||
|
|
||||||
|
- [**Vysvětlení kontextu projektu**](../explanation/project-context.md) — Zjistěte více o tom, jak to funguje
|
||||||
|
- [**Mapa pracovních postupů**](../reference/workflow-map.md) — Podívejte se, které workflow načítají kontext projektu
|
||||||
|
|
@ -0,0 +1,95 @@
|
||||||
|
---
|
||||||
|
title: "Rychlé opravy"
|
||||||
|
description: Jak provádět rychlé opravy a ad-hoc změny
|
||||||
|
sidebar:
|
||||||
|
order: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
Použijte **Quick Dev** pro opravy chyb, refaktoringy nebo malé cílené změny, které nevyžadují plnou metodu BMad.
|
||||||
|
|
||||||
|
## Kdy to použít
|
||||||
|
|
||||||
|
- Opravy chyb s jasnou, známou příčinou
|
||||||
|
- Malé refaktoringy (přejmenování, extrakce, restrukturalizace) omezené na několik souborů
|
||||||
|
- Drobné úpravy funkcí nebo změny konfigurace
|
||||||
|
- Aktualizace závislostí
|
||||||
|
|
||||||
|
:::note[Předpoklady]
|
||||||
|
- BMad Method nainstalován (`npx bmad-method install`)
|
||||||
|
- AI-powered IDE (Claude Code, Cursor nebo podobné)
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Kroky
|
||||||
|
|
||||||
|
### 1. Začněte nový chat
|
||||||
|
|
||||||
|
Otevřete **novou chatovací relaci** ve vašem AI IDE. Opětovné použití relace z předchozího workflow může způsobit konflikty kontextu.
|
||||||
|
|
||||||
|
### 2. Zadejte svůj záměr
|
||||||
|
|
||||||
|
Quick Dev přijímá volně formulovaný záměr — před, s nebo po vyvolání. Příklady:
|
||||||
|
|
||||||
|
```text
|
||||||
|
run quick-dev — Fix the login validation bug that allows empty passwords.
|
||||||
|
```
|
||||||
|
|
||||||
|
```text
|
||||||
|
run quick-dev — fix https://github.com/org/repo/issues/42
|
||||||
|
```
|
||||||
|
|
||||||
|
```text
|
||||||
|
run quick-dev — implement the intent in _bmad-output/implementation-artifacts/my-intent.md
|
||||||
|
```
|
||||||
|
|
||||||
|
```text
|
||||||
|
I think the problem is in the auth middleware, it's not checking token expiry.
|
||||||
|
Let me look at it... yeah, src/auth/middleware.ts line 47 skips
|
||||||
|
the exp check entirely. run quick-dev
|
||||||
|
```
|
||||||
|
|
||||||
|
```text
|
||||||
|
run quick-dev
|
||||||
|
> What would you like to do?
|
||||||
|
Refactor UserService to use async/await instead of callbacks.
|
||||||
|
```
|
||||||
|
|
||||||
|
Prostý text, cesty k souborům, GitHub issue URL, odkazy na bug tracker — cokoli, co LLM dokáže převést na konkrétní záměr.
|
||||||
|
|
||||||
|
### 3. Odpovězte na otázky a schvalte
|
||||||
|
|
||||||
|
Quick Dev se může zeptat na upřesňující otázky nebo prezentovat krátkou specifikaci ke schválení před implementací. Odpovězte na otázky a schvalte, až budete s plánem spokojeni.
|
||||||
|
|
||||||
|
### 4. Zkontrolujte a pushněte
|
||||||
|
|
||||||
|
Quick Dev implementuje změnu, zreviduje svou práci, opraví problémy a commitne lokálně. Když je hotov, otevře dotčené soubory ve vašem editoru.
|
||||||
|
|
||||||
|
- Projděte diff a potvrďte, že změna odpovídá vašemu záměru
|
||||||
|
- Pokud něco nevypadá dobře, řekněte agentovi, co opravit — může iterovat ve stejné relaci
|
||||||
|
|
||||||
|
Až budete spokojeni, pushněte commit. Quick Dev nabídne push a vytvoření PR za vás.
|
||||||
|
|
||||||
|
:::caution[Pokud se něco rozbije]
|
||||||
|
Pokud pushnutá změna způsobí neočekávané problémy, použijte `git revert HEAD` pro čisté vrácení posledního commitu. Poté začněte nový chat a spusťte Quick Dev znovu s jiným přístupem.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Co získáte
|
||||||
|
|
||||||
|
- Upravené zdrojové soubory s aplikovanou opravou nebo refaktoringem
|
||||||
|
- Procházející testy (pokud má váš projekt testovací sadu)
|
||||||
|
- Commit připravený k pushnutí s konvenční commit zprávou
|
||||||
|
|
||||||
|
## Odložená práce
|
||||||
|
|
||||||
|
Quick Dev udržuje každý běh zaměřený na jeden cíl. Pokud váš požadavek obsahuje více nezávislých cílů, nebo pokud revize odhalí předchozí problémy nesouvisející s vaší změnou, Quick Dev je odloží do souboru (`deferred-work.md` ve vašem adresáři implementačních artefaktů) místo toho, aby se pokusil vše řešit najednou.
|
||||||
|
|
||||||
|
Zkontrolujte tento soubor po běhu — je to váš backlog věcí, ke kterým se vrátit. Každou odloženou položku lze zadat do nového běhu Quick Dev později.
|
||||||
|
|
||||||
|
## Kdy přejít na formální plánování
|
||||||
|
|
||||||
|
Zvažte použití plné metody BMad, když:
|
||||||
|
|
||||||
|
- Změna ovlivňuje více systémů nebo vyžaduje koordinované aktualizace napříč mnoha soubory
|
||||||
|
- Nejste si jisti rozsahem a potřebujete nejprve zjišťování požadavků
|
||||||
|
- Potřebujete dokumentaci nebo architektonická rozhodnutí zaznamenaná pro tým
|
||||||
|
|
||||||
|
Podívejte se na [Quick Dev](../explanation/quick-dev.md) pro více informací o tom, jak Quick Dev zapadá do metody BMad.
|
||||||
|
|
@ -0,0 +1,78 @@
|
||||||
|
---
|
||||||
|
title: "Průvodce dělením dokumentů"
|
||||||
|
description: Rozdělení velkých markdown souborů na menší organizované soubory pro lepší správu kontextu
|
||||||
|
sidebar:
|
||||||
|
order: 9
|
||||||
|
---
|
||||||
|
|
||||||
|
Použijte nástroj `bmad-shard-doc`, pokud potřebujete rozdělit velké markdown soubory na menší, organizované soubory pro lepší správu kontextu.
|
||||||
|
|
||||||
|
:::caution[Zastaralé]
|
||||||
|
Toto se již nedoporučuje a brzy s aktualizovanými workflow a většinou hlavních LLM a nástrojů podporujících subprocesy to bude zbytečné.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Kdy to použít
|
||||||
|
|
||||||
|
Použijte pouze pokud si všimnete, že váš zvolený nástroj / model nedokáže načíst a přečíst všechny dokumenty jako vstup, když je to potřeba.
|
||||||
|
|
||||||
|
## Co je dělení dokumentů?
|
||||||
|
|
||||||
|
Dělení dokumentů rozděluje velké markdown soubory na menší, organizované soubory na základě nadpisů úrovně 2 (`## Nadpis`).
|
||||||
|
|
||||||
|
### Architektura
|
||||||
|
|
||||||
|
```text
|
||||||
|
Před dělením:
|
||||||
|
_bmad-output/planning-artifacts/
|
||||||
|
└── PRD.md (velký soubor o 50k tokenech)
|
||||||
|
|
||||||
|
Po dělení:
|
||||||
|
_bmad-output/planning-artifacts/
|
||||||
|
└── prd/
|
||||||
|
├── index.md # Obsah s popisy
|
||||||
|
├── overview.md # Sekce 1
|
||||||
|
├── user-requirements.md # Sekce 2
|
||||||
|
├── technical-requirements.md # Sekce 3
|
||||||
|
└── ... # Další sekce
|
||||||
|
```
|
||||||
|
|
||||||
|
## Kroky
|
||||||
|
|
||||||
|
### 1. Spusťte nástroj Shard-Doc
|
||||||
|
|
||||||
|
```bash
|
||||||
|
/bmad-shard-doc
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Následujte interaktivní proces
|
||||||
|
|
||||||
|
```text
|
||||||
|
Agent: Which document would you like to shard?
|
||||||
|
User: docs/PRD.md
|
||||||
|
|
||||||
|
Agent: Default destination: docs/prd/
|
||||||
|
Accept default? [y/n]
|
||||||
|
User: y
|
||||||
|
|
||||||
|
Agent: Sharding PRD.md...
|
||||||
|
✓ Created 12 section files
|
||||||
|
✓ Generated index.md
|
||||||
|
✓ Complete!
|
||||||
|
```
|
||||||
|
|
||||||
|
## Jak funguje vyhledávání workflow
|
||||||
|
|
||||||
|
BMad workflow používají **duální systém vyhledávání**:
|
||||||
|
|
||||||
|
1. **Nejprve zkusí celý dokument** — Hledá `document-name.md`
|
||||||
|
2. **Zkontroluje rozdělenou verzi** — Hledá `document-name/index.md`
|
||||||
|
3. **Pravidlo priority** — Celý dokument má přednost, pokud existují oba — odstraňte celý dokument, pokud chcete použít rozdělenou verzi
|
||||||
|
|
||||||
|
## Podpora workflow
|
||||||
|
|
||||||
|
Všechny BMM workflow podporují oba formáty:
|
||||||
|
|
||||||
|
- Celé dokumenty
|
||||||
|
- Rozdělené dokumenty
|
||||||
|
- Automatická detekce
|
||||||
|
- Transparentní pro uživatele
|
||||||
|
|
@ -0,0 +1,100 @@
|
||||||
|
---
|
||||||
|
title: "Jak upgradovat na v6"
|
||||||
|
description: Migrace z BMad v4 na v6
|
||||||
|
sidebar:
|
||||||
|
order: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
Použijte instalátor BMad pro upgrade z v4 na v6, který zahrnuje automatickou detekci starších instalací a asistenci při migraci.
|
||||||
|
|
||||||
|
## Kdy to použít
|
||||||
|
|
||||||
|
- Máte nainstalovaný BMad v4 (složka `.bmad-method`)
|
||||||
|
- Chcete migrovat na novou architekturu v6
|
||||||
|
- Máte existující plánovací artefakty k zachování
|
||||||
|
|
||||||
|
:::note[Předpoklady]
|
||||||
|
- Node.js 20+
|
||||||
|
- Existující instalace BMad v4
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Kroky
|
||||||
|
|
||||||
|
### 1. Spusťte instalátor
|
||||||
|
|
||||||
|
Postupujte podle [instrukcí instalátoru](./install-bmad.md).
|
||||||
|
|
||||||
|
### 2. Zpracování starší instalace
|
||||||
|
|
||||||
|
Když je detekována v4, můžete:
|
||||||
|
|
||||||
|
- Nechat instalátor zálohovat a odstranit `.bmad-method`
|
||||||
|
- Ukončit a zpracovat vyčištění ručně
|
||||||
|
|
||||||
|
Pokud jste pojmenovali složku bmad method jinak, musíte ji odstranit ručně.
|
||||||
|
|
||||||
|
### 3. Vyčištění IDE skills
|
||||||
|
|
||||||
|
Ručně odstraňte starší v4 IDE příkazy/skills — například pokud máte Claude Code, hledejte vnořené složky začínající na bmad a odstraňte je:
|
||||||
|
|
||||||
|
- `.claude/commands/`
|
||||||
|
|
||||||
|
Nové v6 skills se instalují do:
|
||||||
|
|
||||||
|
- `.claude/skills/`
|
||||||
|
|
||||||
|
### 4. Migrace plánovacích artefaktů
|
||||||
|
|
||||||
|
**Pokud máte plánovací dokumenty (Brief/PRD/UX/Architektura):**
|
||||||
|
|
||||||
|
Přesuňte je do `_bmad-output/planning-artifacts/` s popisnými názvy:
|
||||||
|
|
||||||
|
- Zahrňte `PRD` v názvu souboru pro PRD dokumenty
|
||||||
|
- Zahrňte `brief`, `architecture` nebo `ux-design` odpovídajícím způsobem
|
||||||
|
- Rozdělené dokumenty mohou být v pojmenovaných podsložkách
|
||||||
|
|
||||||
|
**Pokud jste uprostřed plánování:** Zvažte restart s v6 workflow. Použijte existující dokumenty jako vstupy — nové workflow s progresivním objevováním, webovým vyhledáváním a plan mode IDE produkují lepší výsledky.
|
||||||
|
|
||||||
|
### 5. Migrace probíhajícího vývoje
|
||||||
|
|
||||||
|
Pokud máte vytvořené nebo implementované stories:
|
||||||
|
|
||||||
|
1. Dokončete instalaci v6
|
||||||
|
2. Umístěte `epics.md` nebo `epics/epic*.md` do `_bmad-output/planning-artifacts/`
|
||||||
|
3. Spusťte workflow `bmad-sprint-planning` Scrum Mastera
|
||||||
|
4. Řekněte SM, které epicy/stories jsou již dokončené
|
||||||
|
|
||||||
|
## Co získáte
|
||||||
|
|
||||||
|
**Sjednocená struktura v6:**
|
||||||
|
|
||||||
|
```text
|
||||||
|
váš-projekt/
|
||||||
|
├── _bmad/ # Jedna instalační složka
|
||||||
|
│ ├── _config/ # Vaše přizpůsobení
|
||||||
|
│ │ └── agents/ # Soubory přizpůsobení agentů
|
||||||
|
│ ├── core/ # Univerzální základní framework
|
||||||
|
│ ├── bmm/ # Modul BMad Method
|
||||||
|
│ ├── bmb/ # BMad Builder
|
||||||
|
│ └── cis/ # Creative Intelligence Suite
|
||||||
|
└── _bmad-output/ # Výstupní složka (v4 to byla složka dokumentů)
|
||||||
|
```
|
||||||
|
|
||||||
|
## Migrace modulů
|
||||||
|
|
||||||
|
| Modul v4 | Stav v6 |
|
||||||
|
| ----------------------------- | ---------------------------------- |
|
||||||
|
| `.bmad-2d-phaser-game-dev` | Integrován do modulu BMGD |
|
||||||
|
| `.bmad-2d-unity-game-dev` | Integrován do modulu BMGD |
|
||||||
|
| `.bmad-godot-game-dev` | Integrován do modulu BMGD |
|
||||||
|
| `.bmad-infrastructure-devops` | Zastaralý — nový DevOps agent brzy |
|
||||||
|
| `.bmad-creative-writing` | Neadaptován — nový v6 modul brzy |
|
||||||
|
|
||||||
|
## Klíčové změny
|
||||||
|
|
||||||
|
| Koncept | v4 | v6 |
|
||||||
|
| --------------- | ------------------------------------ | -------------------------------------- |
|
||||||
|
| **Core** | `_bmad-core` byl vlastně BMad Method | `_bmad/core/` je univerzální framework |
|
||||||
|
| **Method** | `_bmad-method` | `_bmad/bmm/` |
|
||||||
|
| **Konfigurace** | Přímá editace souborů | `config.yaml` pro každý modul |
|
||||||
|
| **Dokumenty** | Vyžadované nastavení shardů | Plně flexibilní, auto-skenování |
|
||||||
|
|
@ -0,0 +1,60 @@
|
||||||
|
---
|
||||||
|
title: Vítejte v metodě BMad
|
||||||
|
description: Framework pro vývoj řízený umělou inteligencí se specializovanými agenty, řízenými pracovními postupy a inteligentním plánováním
|
||||||
|
---
|
||||||
|
|
||||||
|
Metoda BMad (**B**uild **M**ore **A**rchitect **D**reams) je framework pro vývoj řízený umělou inteligencí v rámci ekosystému BMad Method, který vám pomáhá vytvářet software celým procesem od nápadu a plánování až po agentní implementaci. Poskytuje specializované AI agenty, řízené pracovní postupy a inteligentní plánování, které se přizpůsobí složitosti vašeho projektu, ať už opravujete chybu nebo budujete podnikovou platformu.
|
||||||
|
|
||||||
|
Pokud jste zvyklí pracovat s AI asistenty pro kódování jako Claude, Cursor nebo GitHub Copilot, jste připraveni začít.
|
||||||
|
|
||||||
|
:::note[🚀 V6 je tady a teprve začínáme!]
|
||||||
|
Architektura Skills, BMad Builder v1, automatizace Dev Loop a mnoho dalšího ve vývoji. **[Podívejte se na Plán rozvoje →](./roadmap)**
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Jste tu nově? Začněte tutoriálem
|
||||||
|
|
||||||
|
Nejrychlejší způsob, jak pochopit BMad, je vyzkoušet si ho.
|
||||||
|
|
||||||
|
- **[Začínáme s BMad](./tutorials/getting-started.md)** — Instalace a pochopení fungování BMad
|
||||||
|
- **[Mapa pracovních postupů](./reference/workflow-map.md)** — Vizuální přehled fází BMM, pracovních postupů a správy kontextu
|
||||||
|
|
||||||
|
:::tip[Chcete se rovnou ponořit?]
|
||||||
|
Nainstalujte BMad a použijte skill `bmad-help` — provede vás vším na základě vašeho projektu a nainstalovaných modulů.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Jak používat tuto dokumentaci
|
||||||
|
|
||||||
|
Tato dokumentace je organizována do čtyř sekcí podle toho, co chcete dělat:
|
||||||
|
|
||||||
|
| Sekce | Účel |
|
||||||
|
| -------------------- | ------------------------------------------------------------------------------------------------------------------ |
|
||||||
|
| **Tutoriály** | Orientované na učení. Průvodci krok za krokem, kteří vás provedou tvorbou něčeho. Začněte zde, pokud jste noví. |
|
||||||
|
| **Praktické návody** | Orientované na úkoly. Praktičtí průvodci pro řešení konkrétních problémů. „Jak přizpůsobím agenta?“ najdete zde. |
|
||||||
|
| **Vysvětlení** | Orientované na pochopení. Hluboké ponory do konceptů a architektury. Čtěte, když chcete vědět *proč*. |
|
||||||
|
| **Reference** | Orientované na informace. Technické specifikace agentů, pracovních postupů a konfigurace. |
|
||||||
|
|
||||||
|
## Rozšíření a přizpůsobení
|
||||||
|
|
||||||
|
Chcete rozšířit BMad o vlastní agenty, pracovní postupy nebo moduly? **[BMad Builder](https://bmad-builder-docs.bmad-method.org/)** poskytuje framework a nástroje pro vytváření vlastních rozšíření, ať už přidáváte nové schopnosti do BMad nebo budujete zcela nové moduly od základů.
|
||||||
|
|
||||||
|
## Co budete potřebovat
|
||||||
|
|
||||||
|
BMad funguje s jakýmkoli AI asistentem pro kódování, který podporuje vlastní systémové prompty nebo kontextové soubory projektu. Oblíbené možnosti zahrnují:
|
||||||
|
|
||||||
|
- **[Claude Code](https://code.claude.com)** — CLI nástroj od Anthropic (doporučený)
|
||||||
|
- **[Cursor](https://cursor.sh)** — AI-first editor kódu
|
||||||
|
- **[Codex CLI](https://github.com/openai/codex)** — Terminálový kódovací agent od OpenAI
|
||||||
|
|
||||||
|
Měli byste být obeznámeni se základními koncepty vývoje softwaru jako správa verzí, struktura projektu a agilní pracovní postupy. Žádná předchozí zkušenost se systémy agentů ve stylu BMad není vyžadována — právě od toho je tato dokumentace.
|
||||||
|
|
||||||
|
## Připojte se ke komunitě
|
||||||
|
|
||||||
|
Získejte pomoc, sdílejte co budujete, nebo přispějte do BMad:
|
||||||
|
|
||||||
|
- **[Discord](https://discord.gg/gk8jAdXWmj)** — Chatujte s ostatními uživateli BMad, pokládejte otázky, sdílejte nápady
|
||||||
|
- **[GitHub](https://github.com/bmad-code-org/BMAD-METHOD)** — Zdrojový kód, issues a příspěvky
|
||||||
|
- **[YouTube](https://www.youtube.com/@BMadCode)** — Video tutoriály a návody
|
||||||
|
|
||||||
|
## Další krok
|
||||||
|
|
||||||
|
Jste připraveni se ponořit? **[Začněte s BMad](./tutorials/getting-started.md)** a vytvořte svůj první projekt.
|
||||||
|
|
@ -0,0 +1,55 @@
|
||||||
|
---
|
||||||
|
title: Agenti
|
||||||
|
description: Výchozí BMM agenti s jejich skill ID, spouštěči nabídky a primárními workflow
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
## Výchozí agenti
|
||||||
|
|
||||||
|
Tato stránka uvádí výchozí BMM (Agile suite) agenty, kteří se instalují s BMad Method, společně s jejich skill ID, spouštěči nabídky a primárními workflow. Každý agent se vyvolává jako skill.
|
||||||
|
|
||||||
|
## Poznámky
|
||||||
|
|
||||||
|
- Každý agent je dostupný jako skill, generovaný instalátorem. Skill ID (např. `bmad-dev`) se používá k vyvolání agenta.
|
||||||
|
- Spouštěče jsou krátké kódy nabídky (např. `CP`) a fuzzy shody zobrazené v nabídce každého agenta.
|
||||||
|
- Generování QA testů zajišťuje workflow skill `bmad-qa-generate-e2e-tests`, dostupný přes Developer agenta. Plný Test Architect (TEA) žije ve vlastním modulu.
|
||||||
|
|
||||||
|
| Agent | Skill ID | Spouštěče | Primární workflow |
|
||||||
|
| --------------------------- | -------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------- |
|
||||||
|
| Analyst (Mary) | `bmad-analyst` | `BP`, `RS`, `CB`, `WB`, `DP` | Brainstorm projektu, výzkum, tvorba briefu, PRFAQ výzva, dokumentace projektu |
|
||||||
|
| Product Manager (John) | `bmad-pm` | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | Tvorba/validace/editace PRD, tvorba epiců a stories, připravenost implementace, korekce kurzu |
|
||||||
|
| Architect (Winston) | `bmad-architect` | `CA`, `IR` | Tvorba architektury, připravenost implementace |
|
||||||
|
| Developer (Amelia) | `bmad-agent-dev` | `DS`, `QD`, `QA`, `CR`, `SP`, `CS`, `ER` | Dev story, Quick Dev, generování QA testů, revize kódu, plánování sprintu, tvorba story, retrospektiva epicu |
|
||||||
|
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Tvorba UX designu |
|
||||||
|
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Dokumentace projektu, psaní dokumentu, aktualizace standardů, generování Mermaid, validace dok., vysvětlení konceptu |
|
||||||
|
|
||||||
|
## Typy spouštěčů
|
||||||
|
|
||||||
|
Spouštěče nabídky agentů používají dva různé typy vyvolání. Znalost typu spouštěče vám pomůže poskytnout správný vstup.
|
||||||
|
|
||||||
|
### Workflow spouštěče (bez argumentů)
|
||||||
|
|
||||||
|
Většina spouštěčů načítá strukturovaný soubor workflow. Zadejte kód spouštěče a agent zahájí workflow a vyzve vás k zadání vstupu v každém kroku.
|
||||||
|
|
||||||
|
Příklady: `CP` (tvorba PRD), `DS` (Dev story), `CA` (tvorba architektury), `QD` (Quick Dev)
|
||||||
|
|
||||||
|
### Konverzační spouštěče (vyžadují argumenty)
|
||||||
|
|
||||||
|
Některé spouštěče zahajují volnou konverzaci místo strukturovaného workflow. Tyto očekávají, že popíšete, co potřebujete, společně s kódem spouštěče.
|
||||||
|
|
||||||
|
| Agent | Spouštěč | Co poskytnout |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| Technical Writer (Paige) | `WD` | Popis dokumentu k napsání |
|
||||||
|
| Technical Writer (Paige) | `US` | Preference nebo konvence k přidání do standardů |
|
||||||
|
| Technical Writer (Paige) | `MG` | Popis diagramu a typ (sekvence, vývojový diagram atd.) |
|
||||||
|
| Technical Writer (Paige) | `VD` | Dokument k validaci a oblasti zaměření |
|
||||||
|
| Technical Writer (Paige) | `EC` | Název konceptu k vysvětlení |
|
||||||
|
|
||||||
|
**Příklad:**
|
||||||
|
|
||||||
|
```text
|
||||||
|
WD Write a deployment guide for our Docker setup
|
||||||
|
MG Create a sequence diagram showing the auth flow
|
||||||
|
EC Explain how the module system works
|
||||||
|
```
|
||||||
|
|
@ -0,0 +1,135 @@
|
||||||
|
---
|
||||||
|
title: Skills
|
||||||
|
description: Reference BMad skills — co to je, jak fungují a kde je najít.
|
||||||
|
sidebar:
|
||||||
|
order: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
Skills jsou předpřipravené prompty, které načítají agenty, spouštějí workflow nebo provádějí úkoly ve vašem IDE. Instalátor BMad je generuje z vašich nainstalovaných modulů při instalaci. Pokud později přidáte, odeberete nebo změníte moduly, přeinstalujte pro synchronizaci skills (viz [Řešení problémů](#řešení-problémů)).
|
||||||
|
|
||||||
|
## Skills vs. spouštěče nabídky agentů
|
||||||
|
|
||||||
|
BMad nabízí dva způsoby zahájení práce a slouží k různým účelům.
|
||||||
|
|
||||||
|
| Mechanismus | Jak se vyvolává | Co se stane |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| **Skill** | Zadejte název skillu (např. `bmad-help`) ve vašem IDE | Přímo načte agenta, spustí workflow nebo provede úkol |
|
||||||
|
| **Spouštěč nabídky agenta** | Nejprve načtěte agenta, pak zadejte krátký kód (např. `DS`) | Agent interpretuje kód a spustí odpovídající workflow, přičemž zůstává v charakteru |
|
||||||
|
|
||||||
|
Spouštěče nabídky agentů vyžadují aktivní relaci agenta. Používejte skills, když víte, který workflow chcete. Používejte spouštěče, když již pracujete s agentem a chcete přepnout úkol bez opuštění konverzace.
|
||||||
|
|
||||||
|
## Jak se skills generují
|
||||||
|
|
||||||
|
Když spustíte `npx bmad-method install`, instalátor čte manifesty každého vybraného modulu a zapíše jeden skill na agenta, workflow, úkol a nástroj. Každý skill je adresář obsahující soubor `SKILL.md`, který instruuje AI k načtení odpovídajícího zdrojového souboru a následování jeho instrukcí.
|
||||||
|
|
||||||
|
Instalátor používá šablony pro každý typ skillu:
|
||||||
|
|
||||||
|
| Typ skillu | Co generovaný soubor dělá |
|
||||||
|
| --- | --- |
|
||||||
|
| **Spouštěč agenta** | Načte soubor persony agenta, aktivuje jeho nabídku a zůstává v charakteru |
|
||||||
|
| **Workflow skill** | Načte konfiguraci workflow a následuje jeho kroky |
|
||||||
|
| **Task skill** | Načte samostatný soubor úkolu a následuje jeho instrukce |
|
||||||
|
| **Tool skill** | Načte samostatný soubor nástroje a následuje jeho instrukce |
|
||||||
|
|
||||||
|
:::note[Opětovné spuštění instalátoru]
|
||||||
|
Pokud přidáte nebo odeberete moduly, spusťte instalátor znovu. Přegeneruje všechny soubory skills tak, aby odpovídaly vašemu aktuálnímu výběru modulů.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Kde žijí soubory skills
|
||||||
|
|
||||||
|
Instalátor zapisuje soubory skills do adresáře specifického pro IDE uvnitř vašeho projektu. Přesná cesta závisí na IDE, které jste vybrali během instalace.
|
||||||
|
|
||||||
|
| IDE / CLI | Adresář skills |
|
||||||
|
| --- | --- |
|
||||||
|
| Claude Code | `.claude/skills/` |
|
||||||
|
| Cursor | `.cursor/skills/` |
|
||||||
|
| Windsurf | `.windsurf/skills/` |
|
||||||
|
| Další IDE | Viz výstup instalátoru pro cílovou cestu |
|
||||||
|
|
||||||
|
Každý skill je adresář obsahující soubor `SKILL.md`. Například instalace Claude Code vypadá takto:
|
||||||
|
|
||||||
|
```text
|
||||||
|
.claude/skills/
|
||||||
|
├── bmad-help/
|
||||||
|
│ └── SKILL.md
|
||||||
|
├── bmad-create-prd/
|
||||||
|
│ └── SKILL.md
|
||||||
|
├── bmad-agent-dev/
|
||||||
|
│ └── SKILL.md
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
|
||||||
|
Název adresáře určuje název skillu ve vašem IDE. Například adresář `bmad-agent-dev/` registruje skill `bmad-agent-dev`.
|
||||||
|
|
||||||
|
## Jak objevit vaše skills
|
||||||
|
|
||||||
|
Zadejte název skillu ve vašem IDE pro jeho vyvolání. Některé platformy vyžadují povolení skills v nastavení, než se zobrazí.
|
||||||
|
|
||||||
|
Spusťte `bmad-help` pro kontextové poradenství k dalšímu kroku.
|
||||||
|
|
||||||
|
:::tip[Rychlé objevování]
|
||||||
|
Generované adresáře skills ve vašem projektu jsou kanonický seznam. Otevřete je v prohlížeči souborů, abyste viděli každý skill s jeho popisem.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Kategorie skills
|
||||||
|
|
||||||
|
### Agentní skills
|
||||||
|
|
||||||
|
Agentní skills načítají specializovanou AI personu s definovanou rolí, komunikačním stylem a nabídkou workflow. Po načtení agent zůstává v charakteru a reaguje na spouštěče nabídky.
|
||||||
|
|
||||||
|
| Příklad skillu | Agent | Role |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| `bmad-agent-dev` | Amelia (Developer) | Implementuje stories s přísným dodržováním specifikací |
|
||||||
|
| `bmad-pm` | John (Product Manager) | Vytváří a validuje PRD |
|
||||||
|
| `bmad-architect` | Winston (Architect) | Navrhuje systémovou architekturu |
|
||||||
|
|
||||||
|
Viz [Agenti](./agents.md) pro úplný seznam výchozích agentů a jejich spouštěčů.
|
||||||
|
|
||||||
|
### Workflow skills
|
||||||
|
|
||||||
|
Workflow skills spouštějí strukturovaný, vícekrokový proces bez předchozího načtení persony agenta. Načtou konfiguraci workflow a následují jeho kroky.
|
||||||
|
|
||||||
|
| Příklad skillu | Účel |
|
||||||
|
| --- | --- |
|
||||||
|
| `bmad-product-brief` | Vytvoření product briefu — řízené discovery, když je váš koncept jasný |
|
||||||
|
| `bmad-prfaq` | Working Backwards PRFAQ výzva pro zátěžový test vašeho produktového konceptu |
|
||||||
|
| `bmad-create-prd` | Vytvoření dokumentu požadavků (PRD) |
|
||||||
|
| `bmad-create-architecture` | Návrh systémové architektury |
|
||||||
|
| `bmad-create-epics-and-stories` | Vytvoření epiců a stories |
|
||||||
|
| `bmad-dev-story` | Implementace story |
|
||||||
|
| `bmad-code-review` | Spuštění revize kódu |
|
||||||
|
| `bmad-quick-dev` | Sjednocený quick flow — vyjasnění záměru, plán, implementace, revize, prezentace |
|
||||||
|
|
||||||
|
Viz [Mapa pracovních postupů](./workflow-map.md) pro kompletní referenci workflow organizovanou podle fází.
|
||||||
|
|
||||||
|
### Task a tool skills
|
||||||
|
|
||||||
|
Tasks a tools jsou samostatné operace, které nevyžadují kontext agenta nebo workflow.
|
||||||
|
|
||||||
|
**BMad-Help: Váš inteligentní průvodce**
|
||||||
|
|
||||||
|
`bmad-help` je vaše primární rozhraní pro objevení, co dělat dál. Zkoumá váš projekt, rozumí dotazům v přirozeném jazyce a doporučuje další povinný nebo volitelný krok na základě nainstalovaných modulů.
|
||||||
|
|
||||||
|
:::note[Příklad]
|
||||||
|
```
|
||||||
|
bmad-help
|
||||||
|
bmad-help I have a SaaS idea and know all the features. Where do I start?
|
||||||
|
bmad-help What are my options for UX design?
|
||||||
|
```
|
||||||
|
:::
|
||||||
|
|
||||||
|
**Další základní tasks a tools**
|
||||||
|
|
||||||
|
Základní modul zahrnuje 11 vestavěných nástrojů — revize, komprese, brainstorming, správa dokumentů a další. Viz [Základní nástroje](./core-tools.md) pro kompletní referenci.
|
||||||
|
|
||||||
|
## Konvence pojmenování
|
||||||
|
|
||||||
|
Všechny skills používají prefix `bmad-` následovaný popisným názvem (např. `bmad-dev`, `bmad-create-prd`, `bmad-help`). Viz [Moduly](./modules.md) pro dostupné moduly.
|
||||||
|
|
||||||
|
## Řešení problémů
|
||||||
|
|
||||||
|
**Skills se nezobrazují po instalaci.** Některé platformy vyžadují explicitní povolení skills v nastavení. Zkontrolujte dokumentaci vašeho IDE nebo se zeptejte AI asistenta, jak skills povolit. Může být také nutné restartovat IDE nebo znovu načíst okno.
|
||||||
|
|
||||||
|
**Očekávané skills chybí.** Instalátor generuje skills pouze pro moduly, které jste vybrali. Spusťte `npx bmad-method install` znovu a ověřte výběr modulů. Zkontrolujte, že soubory skills existují v očekávaném adresáři.
|
||||||
|
|
||||||
|
**Skills z odebraného modulu se stále zobrazují.** Instalátor automaticky nemaže staré soubory skills. Odstraňte zastaralé adresáře z adresáře skills vašeho IDE, nebo smažte celý adresář skills a přeinstalujte pro čistou sadu.
|
||||||
|
|
@ -0,0 +1,292 @@
|
||||||
|
---
|
||||||
|
title: Základní nástroje
|
||||||
|
description: Reference všech vestavěných úkolů a workflow dostupných v každé instalaci BMad bez dalších modulů.
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Každá instalace BMad zahrnuje sadu základních skills, které lze použít v kombinaci s čímkoli — samostatné úkoly a workflow, které fungují napříč všemi projekty, všemi moduly a všemi fázemi. Ty jsou vždy dostupné bez ohledu na to, které volitelné moduly nainstalujete.
|
||||||
|
|
||||||
|
:::tip[Rychlá cesta]
|
||||||
|
Spusťte jakýkoli základní nástroj zadáním jeho názvu skillu (např. `bmad-help`) ve vašem IDE. Nevyžaduje relaci agenta.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Přehled
|
||||||
|
|
||||||
|
| Nástroj | Typ | Účel |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| [`bmad-help`](#bmad-help) | Task | Kontextové poradenství, co dělat dál |
|
||||||
|
| [`bmad-brainstorming`](#bmad-brainstorming) | Workflow | Facilitace interaktivních brainstormingových sezení |
|
||||||
|
| [`bmad-party-mode`](#bmad-party-mode) | Workflow | Orchestrace skupinových diskuzí více agentů |
|
||||||
|
| [`bmad-distillator`](#bmad-distillator) | Task | Bezeztrátová LLM-optimalizovaná komprese dokumentů |
|
||||||
|
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Task | Iterativní zdokonalování LLM výstupu |
|
||||||
|
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | Task | Cynická revize hledající chybějící a chybné |
|
||||||
|
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | Task | Vyčerpávající analýza větvících cest pro neošetřené hraniční případy |
|
||||||
|
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | Task | Klinická jazyková korektura pro komunikační srozumitelnost |
|
||||||
|
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | Task | Strukturální editace — škrty, sloučení a reorganizace |
|
||||||
|
| [`bmad-shard-doc`](#bmad-shard-doc) | Task | Rozdělení velkých markdown souborů do organizovaných sekcí |
|
||||||
|
| [`bmad-index-docs`](#bmad-index-docs) | Task | Generování nebo aktualizace indexu dokumentů ve složce |
|
||||||
|
|
||||||
|
## bmad-help
|
||||||
|
|
||||||
|
**Váš inteligentní průvodce tím, co přijde dál.** — Zkoumá stav vašeho projektu, detekuje, co bylo uděláno, a doporučuje další povinný nebo volitelný krok.
|
||||||
|
|
||||||
|
**Použijte když:**
|
||||||
|
|
||||||
|
- Dokončili jste workflow a chcete vědět, co dál
|
||||||
|
- Jste noví v BMad a potřebujete orientaci
|
||||||
|
- Jste uvízlí a chcete kontextovou radu
|
||||||
|
- Nainstalovali jste nové moduly a chcete vidět, co je dostupné
|
||||||
|
|
||||||
|
**Jak to funguje:**
|
||||||
|
|
||||||
|
1. Skenuje projekt pro existující artefakty (PRD, architektura, stories atd.)
|
||||||
|
2. Detekuje nainstalované moduly a dostupné workflow
|
||||||
|
3. Doporučuje další kroky v pořadí priority — nejprve povinné, pak volitelné
|
||||||
|
4. Prezentuje každé doporučení s příkazem skillu a stručným popisem
|
||||||
|
|
||||||
|
**Vstup:** Volitelný dotaz v přirozeném jazyce (např. `bmad-help I have a SaaS idea, where do I start?`)
|
||||||
|
|
||||||
|
**Výstup:** Prioritizovaný seznam doporučených dalších kroků s příkazy skills
|
||||||
|
|
||||||
|
## bmad-brainstorming
|
||||||
|
|
||||||
|
**Generování různorodých nápadů prostřednictvím interaktivních kreativních technik.** — Facilitované brainstormingové sezení, které načítá osvědčené ideační metody z knihovny technik a vede vás k 100+ nápadům před organizací.
|
||||||
|
|
||||||
|
**Použijte když:**
|
||||||
|
|
||||||
|
- Začínáte nový projekt a potřebujete prozkoumat problémový prostor
|
||||||
|
- Jste uvízlí s generováním nápadů a potřebujete strukturovanou kreativitu
|
||||||
|
- Chcete použít osvědčené ideační frameworky (SCAMPER, reverzní brainstorming atd.)
|
||||||
|
|
||||||
|
**Jak to funguje:**
|
||||||
|
|
||||||
|
1. Nastaví brainstormingové sezení s vaším tématem
|
||||||
|
2. Načte kreativní techniky z knihovny metod
|
||||||
|
3. Provede vás technikou za technikou, generuje nápady
|
||||||
|
4. Aplikuje anti-bias protokol — mění kreativní doménu každých 10 nápadů
|
||||||
|
5. Produkuje append-only dokument sezení se všemi nápady organizovanými podle techniky
|
||||||
|
|
||||||
|
**Vstup:** Téma brainstormingu nebo formulace problému, volitelný kontextový soubor
|
||||||
|
|
||||||
|
**Výstup:** `brainstorming-session-{date}.md` se všemi generovanými nápady
|
||||||
|
|
||||||
|
:::note[Cíl množství]
|
||||||
|
Kouzlo se děje v nápadech 50–100. Workflow povzbuzuje generování 100+ nápadů před organizací.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## bmad-party-mode
|
||||||
|
|
||||||
|
**Orchestrace skupinových diskuzí více agentů.** — Načte všechny nainstalované BMad agenty a facilituje přirozenou konverzaci, kde každý agent přispívá svou unikátní odborností a osobností.
|
||||||
|
|
||||||
|
**Použijte když:**
|
||||||
|
|
||||||
|
- Potřebujete více expertních perspektiv na rozhodnutí
|
||||||
|
- Chcete, aby agenti zpochybňovali předpoklady ostatních
|
||||||
|
- Zkoumáte složité téma překračující více domén
|
||||||
|
|
||||||
|
**Jak to funguje:**
|
||||||
|
|
||||||
|
1. Načte manifest agentů se všemi nainstalovanými osobnostmi
|
||||||
|
2. Analyzuje vaše téma a vybere 2–3 nejrelevantnější agenty
|
||||||
|
3. Agenti se střídají v přispívání, s přirozenou kříženou diskuzí a nesouhlasy
|
||||||
|
4. Rotuje účast agentů pro zajištění různorodých perspektiv
|
||||||
|
5. Ukončete pomocí `goodbye`, `end party` nebo `quit`
|
||||||
|
|
||||||
|
**Vstup:** Diskuzní téma nebo otázka, s volitelnou specifikací person
|
||||||
|
|
||||||
|
**Výstup:** Real-time multi-agentní konverzace s udržovanými osobnostmi agentů
|
||||||
|
|
||||||
|
## bmad-distillator
|
||||||
|
|
||||||
|
**Bezeztrátová LLM-optimalizovaná komprese zdrojových dokumentů.** — Produkuje husté, tokenově efektivní destiláty, které zachovávají všechny informace pro následné LLM zpracování. Ověřitelné prostřednictvím round-trip rekonstrukce.
|
||||||
|
|
||||||
|
**Použijte když:**
|
||||||
|
|
||||||
|
- Dokument je příliš velký pro kontextové okno LLM
|
||||||
|
- Potřebujete tokenově efektivní verze výzkumů, specifikací nebo plánovacích artefaktů
|
||||||
|
- Chcete ověřit, že během komprese nebyly ztraceny žádné informace
|
||||||
|
|
||||||
|
**Jak to funguje:**
|
||||||
|
|
||||||
|
1. **Analýza** — Čte zdrojové dokumenty, identifikuje hustotu informací a strukturu
|
||||||
|
2. **Komprese** — Převádí prózu na hustý odrážkový formát, odstraňuje dekorativní formátování
|
||||||
|
3. **Ověření** — Kontroluje úplnost pro zajištění zachování všech informací
|
||||||
|
4. **Validace** (volitelné) — Round-trip rekonstrukční test dokazuje bezeztrátovou kompresi
|
||||||
|
|
||||||
|
**Vstup:**
|
||||||
|
|
||||||
|
- `source_documents` (povinné) — Cesty k souborům, složkám nebo glob vzory
|
||||||
|
- `downstream_consumer` (volitelné) — Co to konzumuje (např. „tvorba PRD“)
|
||||||
|
- `token_budget` (volitelné) — Přibližná cílová velikost
|
||||||
|
- `--validate` (příznak) — Spuštění round-trip rekonstrukčního testu
|
||||||
|
|
||||||
|
**Výstup:** Destilátové markdown soubory s reportem kompresního poměru (např. „3.2:1“)
|
||||||
|
|
||||||
|
## bmad-advanced-elicitation
|
||||||
|
|
||||||
|
**Iterativní zdokonalování LLM výstupu metodami elicitace.** — Vybírá z knihovny elicitačních technik pro systematické zlepšování obsahu více průchody.
|
||||||
|
|
||||||
|
**Použijte když:**
|
||||||
|
|
||||||
|
- LLM výstup působí povrchně nebo genericky
|
||||||
|
- Chcete prozkoumat téma z více analytických úhlů
|
||||||
|
- Zdokonalujete kritický dokument a chcete hlubší myšlení
|
||||||
|
|
||||||
|
**Jak to funguje:**
|
||||||
|
|
||||||
|
1. Načte registr metod s 5+ elicitačními technikami
|
||||||
|
2. Vybere 5 nejlépe odpovídajících metod podle typu a složitosti obsahu
|
||||||
|
3. Prezentuje interaktivní nabídku — vyberte metodu, zamíchejte nebo zobrazte vše
|
||||||
|
4. Aplikuje vybranou metodu k vylepšení obsahu
|
||||||
|
5. Znovu prezentuje možnosti pro iterativní zlepšení, dokud nevyberete „Pokračovat“
|
||||||
|
|
||||||
|
**Vstup:** Sekce obsahu k vylepšení
|
||||||
|
|
||||||
|
**Výstup:** Vylepšená verze obsahu s aplikovanými zlepšeními
|
||||||
|
|
||||||
|
## bmad-review-adversarial-general
|
||||||
|
|
||||||
|
**Cynická revize, která předpokládá existenci problémů a hledá je.** — Zaujme perspektivu skeptického, otráveného recenzenta s nulovou tolerancí pro nedbalou práci. Hledá, co chybí, ne jen co je špatně.
|
||||||
|
|
||||||
|
**Použijte když:**
|
||||||
|
|
||||||
|
- Potřebujete zajištění kvality před finalizací výstupu
|
||||||
|
- Chcete zátěžově otestovat specifikaci, story nebo dokument
|
||||||
|
- Chcete najít mezery v pokrytí, které optimistické revize přehlédnou
|
||||||
|
|
||||||
|
**Jak to funguje:**
|
||||||
|
|
||||||
|
1. Čte obsah s cynickou, kritickou perspektivou
|
||||||
|
2. Identifikuje problémy v úplnosti, správnosti a kvalitě
|
||||||
|
3. Specificky hledá, co chybí — ne jen co je přítomné a špatné
|
||||||
|
4. Musí najít minimálně 10 problémů nebo analyzuje hlouběji
|
||||||
|
|
||||||
|
**Vstup:**
|
||||||
|
|
||||||
|
- `content` (povinné) — Diff, specifikace, story, dokument nebo jakýkoli artefakt
|
||||||
|
- `also_consider` (volitelné) — Další oblasti k zvážení
|
||||||
|
|
||||||
|
**Výstup:** Markdown seznam 10+ nálezů s popisy
|
||||||
|
|
||||||
|
## bmad-review-edge-case-hunter
|
||||||
|
|
||||||
|
**Procházení každé větvící cesty a hraničních podmínek, hlášení pouze neošetřených případů.** — Čistě metodologický přístup trasování cest, který mechanicky odvozuje třídy hraničních případů.
|
||||||
|
|
||||||
|
**Použijte když:**
|
||||||
|
|
||||||
|
- Chcete vyčerpávající pokrytí hraničních případů pro kód nebo logiku
|
||||||
|
- Potřebujete doplněk k adversariální revizi (jiná metodologie, jiné nálezy)
|
||||||
|
- Revidujete diff nebo funkci pro hraniční podmínky
|
||||||
|
|
||||||
|
**Jak to funguje:**
|
||||||
|
|
||||||
|
1. Enumeruje všechny větvící cesty v obsahu
|
||||||
|
2. Mechanicky odvozuje třídy případů: chybějící else/default, nestřežené vstupy, off-by-one, přetečení aritmetiky, implicitní typová koerce, race conditions, mezery v timeoutech
|
||||||
|
3. Testuje každou cestu proti existujícím ochranám
|
||||||
|
4. Hlásí pouze neošetřené cesty — tiše zahazuje ošetřené
|
||||||
|
|
||||||
|
**Vstup:**
|
||||||
|
|
||||||
|
- `content` (povinné) — Diff, celý soubor nebo funkce
|
||||||
|
- `also_consider` (volitelné) — Další oblasti k zvážení
|
||||||
|
|
||||||
|
**Výstup:** JSON pole nálezů, každý s `location`, `trigger_condition`, `guard_snippet` a `potential_consequence`
|
||||||
|
|
||||||
|
:::note[Komplementární revize]
|
||||||
|
Spusťte obě `bmad-review-adversarial-general` a `bmad-review-edge-case-hunter` společně pro ortogonální pokrytí. Adversariální revize zachytí problémy kvality a úplnosti; hunter hraničních případů zachytí neošetřené cesty.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## bmad-editorial-review-prose
|
||||||
|
|
||||||
|
**Klinická jazyková korektura zaměřená na srozumitelnost komunikace.** — Reviduje text pro problémy bránící porozumění. Aplikuje baseline Microsoft Writing Style Guide. Zachovává autorský hlas.
|
||||||
|
|
||||||
|
**Použijte když:**
|
||||||
|
|
||||||
|
- Napsali jste dokument a chcete vylepšit psaní
|
||||||
|
- Potřebujete zajistit srozumitelnost pro konkrétní publikum
|
||||||
|
- Chcete komunikační opravy bez změn stylistických preferencí
|
||||||
|
|
||||||
|
**Jak to funguje:**
|
||||||
|
|
||||||
|
1. Čte obsah, přeskakuje bloky kódu a frontmatter
|
||||||
|
2. Identifikuje komunikační problémy (ne stylistické preference)
|
||||||
|
3. Deduplikuje stejné problémy napříč více lokacemi
|
||||||
|
4. Produkuje třísloupcovou tabulku oprav
|
||||||
|
|
||||||
|
**Vstup:**
|
||||||
|
|
||||||
|
- `content` (povinné) — Markdown, prostý text nebo XML
|
||||||
|
- `style_guide` (volitelné) — Projektově specifický průvodce stylem
|
||||||
|
- `reader_type` (volitelné) — `humans` (výchozí) pro srozumitelnost/plynulost, nebo `llm` pro přesnost/konzistenci
|
||||||
|
|
||||||
|
**Výstup:** Třísloupcová markdown tabulka: Původní text | Revidovaný text | Změny
|
||||||
|
|
||||||
|
## bmad-editorial-review-structure
|
||||||
|
|
||||||
|
**Strukturální editace — navrhuje škrty, sloučení, přesuny a zhuštění.** — Reviduje organizaci dokumentu a navrhuje substantivní změny pro zlepšení srozumitelnosti a toku před jazykovou korekcí.
|
||||||
|
|
||||||
|
**Použijte když:**
|
||||||
|
|
||||||
|
- Dokument byl vytvořen z více subprocesů a potřebuje strukturální koherenci
|
||||||
|
- Chcete zkrátit dokument při zachování porozumění
|
||||||
|
- Potřebujete identifikovat porušení rozsahu nebo pohřbené kritické informace
|
||||||
|
|
||||||
|
**Jak to funguje:**
|
||||||
|
|
||||||
|
1. Analyzuje dokument proti 5 strukturním modelům (Tutorial, Reference, Explanation, Prompt, Strategic)
|
||||||
|
2. Identifikuje redundance, porušení rozsahu a pohřbené informace
|
||||||
|
3. Produkuje prioritizovaná doporučení: CUT, MERGE, MOVE, CONDENSE, QUESTION, PRESERVE
|
||||||
|
4. Odhaduje celkovou redukci ve slovech a procentech
|
||||||
|
|
||||||
|
**Vstup:**
|
||||||
|
|
||||||
|
- `content` (povinné) — Dokument k revizi
|
||||||
|
- `purpose` (volitelné) — Zamýšlený účel (např. „quickstart tutoriál“)
|
||||||
|
- `target_audience` (volitelné) — Kdo to čte
|
||||||
|
- `reader_type` (volitelné) — `humans` nebo `llm`
|
||||||
|
- `length_target` (volitelné) — Cílová redukce (např. „o 30 % kratší“)
|
||||||
|
|
||||||
|
**Výstup:** Shrnutí dokumentu, prioritizovaný seznam doporučení a odhadovaná redukce
|
||||||
|
|
||||||
|
## bmad-shard-doc
|
||||||
|
|
||||||
|
**Rozdělení velkých markdown souborů do organizovaných souborů sekcí.** — Používá nadpisy úrovně 2 jako body dělení k vytvoření složky samostatných souborů sekcí s indexem.
|
||||||
|
|
||||||
|
**Použijte když:**
|
||||||
|
|
||||||
|
- Markdown dokument narostl na nezvládnutelnou velikost (500+ řádků)
|
||||||
|
- Chcete rozložit monolitický dokument na navigovatelné sekce
|
||||||
|
- Potřebujete samostatné soubory pro paralelní editaci nebo správu LLM kontextu
|
||||||
|
|
||||||
|
**Jak to funguje:**
|
||||||
|
|
||||||
|
1. Validuje, že zdrojový soubor existuje a je markdown
|
||||||
|
2. Dělí na nadpisech úrovně 2 (`##`) do číslovaných souborů sekcí
|
||||||
|
3. Vytváří `index.md` s manifestem sekcí a odkazy
|
||||||
|
4. Vyzve vás ke smazání, archivaci nebo zachování originálu
|
||||||
|
|
||||||
|
**Vstup:** Cesta ke zdrojovému markdown souboru, volitelná cílová složka
|
||||||
|
|
||||||
|
**Výstup:** Složka s `index.md` a `01-{sekce}.md`, `02-{sekce}.md` atd.
|
||||||
|
|
||||||
|
## bmad-index-docs
|
||||||
|
|
||||||
|
**Generování nebo aktualizace indexu všech dokumentů ve složce.** — Skenuje adresář, čte každý soubor pro pochopení jeho účelu a produkuje organizovaný `index.md` s odkazy a popisy.
|
||||||
|
|
||||||
|
**Použijte když:**
|
||||||
|
|
||||||
|
- Potřebujete lehký index pro rychlé LLM skenování dostupných dokumentů
|
||||||
|
- Složka dokumentace narostla a potřebuje organizovaný obsah
|
||||||
|
- Chcete automaticky generovaný přehled, který zůstává aktuální
|
||||||
|
|
||||||
|
**Jak to funguje:**
|
||||||
|
|
||||||
|
1. Skenuje cílový adresář pro všechny neskryté soubory
|
||||||
|
2. Čte každý soubor pro pochopení jeho skutečného účelu
|
||||||
|
3. Seskupuje soubory podle typu, účelu nebo podadresáře
|
||||||
|
4. Generuje stručné popisy (3–10 slov každý)
|
||||||
|
|
||||||
|
**Vstup:** Cesta k cílové složce
|
||||||
|
|
||||||
|
**Výstup:** `index.md` s organizovanými výpisy souborů, relativními odkazy a stručnými popisy
|
||||||
|
|
@ -0,0 +1,76 @@
|
||||||
|
---
|
||||||
|
title: Oficiální moduly
|
||||||
|
description: Doplňkové moduly pro tvorbu vlastních agentů, kreativní inteligenci, vývoj her a testování
|
||||||
|
sidebar:
|
||||||
|
order: 4
|
||||||
|
---
|
||||||
|
|
||||||
|
BMad se rozšiřuje prostřednictvím oficiálních modulů, které vyberete během instalace. Tyto doplňkové moduly poskytují specializované agenty, workflow a úkoly pro specifické domény nad rámec vestavěného jádra a BMM (Agile suite).
|
||||||
|
|
||||||
|
:::tip[Instalace modulů]
|
||||||
|
Spusťte `npx bmad-method install` a vyberte požadované moduly. Instalátor se postará o stažení, konfiguraci a integraci s IDE automaticky.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## BMad Builder
|
||||||
|
|
||||||
|
Vytvářejte vlastní agenty, workflow a doménově specifické moduly s řízenou asistencí. BMad Builder je meta-modul pro rozšiřování samotného frameworku.
|
||||||
|
|
||||||
|
- **Kód:** `bmb`
|
||||||
|
- **npm:** [`bmad-builder`](https://www.npmjs.com/package/bmad-builder)
|
||||||
|
- **GitHub:** [bmad-code-org/bmad-builder](https://github.com/bmad-code-org/bmad-builder)
|
||||||
|
|
||||||
|
**Poskytuje:**
|
||||||
|
|
||||||
|
- Agent Builder — tvorba specializovaných AI agentů s vlastní odborností a přístupem k nástrojům
|
||||||
|
- Workflow Builder — návrh strukturovaných procesů s kroky a rozhodovacími body
|
||||||
|
- Module Builder — balíčkování agentů a workflow do sdílitelných, publikovatelných modulů
|
||||||
|
- Interaktivní nastavení s YAML konfigurací a podporou npm publikování
|
||||||
|
|
||||||
|
## Creative Intelligence Suite
|
||||||
|
|
||||||
|
AI nástroje pro strukturovanou kreativitu, ideaci a inovace v rané fázi vývoje. Suite poskytuje více agentů, kteří facilitují brainstorming, design thinking a řešení problémů pomocí osvědčených frameworků.
|
||||||
|
|
||||||
|
- **Kód:** `cis`
|
||||||
|
- **npm:** [`bmad-creative-intelligence-suite`](https://www.npmjs.com/package/bmad-creative-intelligence-suite)
|
||||||
|
- **GitHub:** [bmad-code-org/bmad-module-creative-intelligence-suite](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)
|
||||||
|
|
||||||
|
**Poskytuje:**
|
||||||
|
|
||||||
|
- Agenty Innovation Strategist, Design Thinking Coach a Brainstorming Coach
|
||||||
|
- Problem Solver a Creative Problem Solver pro systematické a laterální myšlení
|
||||||
|
- Storyteller a Presentation Master pro narativy a prezentace
|
||||||
|
- Ideační frameworky včetně SCAMPER, reverzního brainstormingu a přeformulování problémů
|
||||||
|
|
||||||
|
## Game Dev Studio
|
||||||
|
|
||||||
|
Strukturované workflow pro vývoj her adaptované pro Unity, Unreal, Godot a vlastní enginy. Podporuje rychlé prototypování přes Quick Flow a plnoscálovou produkci s epicky řízenými sprinty.
|
||||||
|
|
||||||
|
- **Kód:** `gds`
|
||||||
|
- **npm:** [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
|
||||||
|
- **GitHub:** [bmad-code-org/bmad-module-game-dev-studio](https://github.com/bmad-code-org/bmad-module-game-dev-studio)
|
||||||
|
|
||||||
|
**Poskytuje:**
|
||||||
|
|
||||||
|
- Workflow pro generování Game Design Document (GDD)
|
||||||
|
- Režim Quick Dev pro rychlé prototypování
|
||||||
|
- Podporu narativního designu pro postavy, dialogy a budování světa
|
||||||
|
- Pokrytí 21+ typů her s architektonickým vedením specifickým pro engine
|
||||||
|
|
||||||
|
## Test Architect (TEA)
|
||||||
|
|
||||||
|
Podniková testovací strategie, vedení automatizace a rozhodování o release gate prostřednictvím expertního agenta a devíti strukturovaných workflow. TEA jde daleko za vestavěného QA agenta s prioritizací založenou na riziku a trasovatelností požadavků.
|
||||||
|
|
||||||
|
- **Kód:** `tea`
|
||||||
|
- **npm:** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||||
|
- **GitHub:** [bmad-code-org/bmad-method-test-architecture-enterprise](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)
|
||||||
|
|
||||||
|
**Poskytuje:**
|
||||||
|
|
||||||
|
- Agenta Murat (Master Test Architect a Quality Advisor)
|
||||||
|
- Workflow pro testovací design, ATDD, automatizaci, revizi testů a trasovatelnost
|
||||||
|
- Hodnocení NFR, nastavení CI a scaffolding frameworku
|
||||||
|
- Prioritizaci P0-P3 s volitelnými integracemi Playwright Utils a MCP
|
||||||
|
|
||||||
|
## Komunitní moduly
|
||||||
|
|
||||||
|
Komunitní moduly a marketplace modulů přicházejí. Sledujte [organizaci BMad na GitHubu](https://github.com/bmad-code-org) pro aktualizace.
|
||||||
|
|
@ -0,0 +1,106 @@
|
||||||
|
---
|
||||||
|
title: Možnosti testování
|
||||||
|
description: Srovnání vestavěného QA agenta (Quinn) s modulem Test Architect (TEA) pro automatizaci testů.
|
||||||
|
sidebar:
|
||||||
|
order: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
BMad poskytuje dvě testovací cesty: vestavěného QA agenta pro rychlé generování testů a instalovatelný modul Test Architect pro podnikovou testovací strategii.
|
||||||
|
|
||||||
|
## Který byste měli použít?
|
||||||
|
|
||||||
|
| Faktor | Quinn (vestavěný QA) | Modul TEA |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| **Nejlepší pro** | Malé až střední projekty, rychlé pokrytí | Velké projekty, regulované nebo složité domény |
|
||||||
|
| **Nastavení** | Nic k instalaci — součástí BMM | Instalace zvlášť přes `npx bmad-method install` |
|
||||||
|
| **Přístup** | Generujte testy rychle, iterujte později | Nejprve plánujte, pak generujte s trasovatelností |
|
||||||
|
| **Typy testů** | API a E2E testy | API, E2E, ATDD, NFR a další |
|
||||||
|
| **Strategie** | Happy path + kritické hraniční případy | Prioritizace založená na riziku (P0–P3) |
|
||||||
|
| **Počet workflow** | 1 (Automate) | 9 (design, ATDD, automate, review, trace a další) |
|
||||||
|
|
||||||
|
:::tip[Začněte s Quinnem]
|
||||||
|
Většina projektů by měla začít s Quinnem. Pokud později budete potřebovat testovací strategii, quality gates nebo trasovatelnost požadavků, nainstalujte TEA vedle něj.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Vestavěný QA agent (Quinn)
|
||||||
|
|
||||||
|
Quinn je vestavěný QA agent v modulu BMM (Agile suite). Rychle generuje funkční testy pomocí existujícího testovacího frameworku vašeho projektu — bez konfigurace nebo další instalace.
|
||||||
|
|
||||||
|
**Spouštěč:** `QA` nebo `bmad-qa-generate-e2e-tests`
|
||||||
|
|
||||||
|
### Co Quinn dělá
|
||||||
|
|
||||||
|
Quinn spouští jeden workflow (Automate), který projde pěti kroky:
|
||||||
|
|
||||||
|
1. **Detekce testovacího frameworku** — skenuje `package.json` a existující testovací soubory pro váš framework (Jest, Vitest, Playwright, Cypress nebo jakýkoli standardní runner). Pokud neexistuje, analyzuje stack projektu a navrhne jeden.
|
||||||
|
2. **Identifikace funkcí** — zeptá se, co testovat, nebo automaticky objeví funkce v kódové bázi.
|
||||||
|
3. **Generování API testů** — pokrývá stavové kódy, strukturu odpovědí, happy path a 1–2 chybové případy.
|
||||||
|
4. **Generování E2E testů** — pokrývá uživatelské workflow se sémantickými lokátory a asercemi viditelných výsledků.
|
||||||
|
5. **Spuštění a ověření** — provede generované testy a okamžitě opraví selhání.
|
||||||
|
|
||||||
|
Quinn produkuje shrnutí testů uložené do složky implementačních artefaktů vašeho projektu.
|
||||||
|
|
||||||
|
### Vzory testů
|
||||||
|
|
||||||
|
Generované testy sledují filozofii „jednoduché a udržovatelné“:
|
||||||
|
|
||||||
|
- **Pouze standardní API frameworku** — žádné externí utility nebo vlastní abstrakce
|
||||||
|
- **Sémantické lokátory** pro UI testy (role, popisky, text místo CSS selektorů)
|
||||||
|
- **Nezávislé testy** bez závislostí na pořadí
|
||||||
|
- **Žádné hardcoded waity nebo sleep**
|
||||||
|
- **Jasné popisy**, které se čtou jako dokumentace funkcí
|
||||||
|
|
||||||
|
:::note[Rozsah]
|
||||||
|
Quinn generuje pouze testy. Pro revizi kódu a validaci stories použijte workflow Code Review (`CR`).
|
||||||
|
:::
|
||||||
|
|
||||||
|
### Kdy použít Quinna
|
||||||
|
|
||||||
|
- Rychlé pokrytí testy pro novou nebo existující funkci
|
||||||
|
- Automatizace testů přátelská k začátečníkům bez pokročilého nastavení
|
||||||
|
- Standardní vzory testů, které může číst a udržovat jakýkoli vývojář
|
||||||
|
- Malé až střední projekty, kde komplexní testovací strategie není potřeba
|
||||||
|
|
||||||
|
## Modul Test Architect (TEA)
|
||||||
|
|
||||||
|
TEA je samostatný modul, který poskytuje expertního agenta (Murat) a devět strukturovaných workflow pro podnikové testování. Jde za rámec generování testů do testovací strategie, plánování založeného na riziku, quality gates a trasovatelnosti požadavků.
|
||||||
|
|
||||||
|
- **Dokumentace:** [Dokumentace modulu TEA](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
||||||
|
- **Instalace:** `npx bmad-method install` a výběr modulu TEA
|
||||||
|
- **npm:** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||||
|
|
||||||
|
### Co TEA poskytuje
|
||||||
|
|
||||||
|
| Workflow | Účel |
|
||||||
|
| --- | --- |
|
||||||
|
| Test Design | Vytvoření komplexní testovací strategie vázané na požadavky |
|
||||||
|
| ATDD | Acceptance-test-driven development s kritérii stakeholderů |
|
||||||
|
| Automate | Generování testů s pokročilými vzory a utilitami |
|
||||||
|
| Test Review | Validace kvality a pokrytí testů proti strategii |
|
||||||
|
| Traceability | Mapování testů zpět na požadavky pro audit a compliance |
|
||||||
|
| NFR Assessment | Hodnocení nefunkčních požadavků (výkon, bezpečnost) |
|
||||||
|
| CI Setup | Konfigurace provádění testů v CI pipelines |
|
||||||
|
| Framework Scaffolding | Nastavení testovací infrastruktury a struktury projektu |
|
||||||
|
| Release Gate | Datově založená rozhodnutí go/no-go pro release |
|
||||||
|
|
||||||
|
TEA také podporuje prioritizaci P0–P3 založenou na riziku a volitelné integrace s Playwright Utils a MCP nástroji.
|
||||||
|
|
||||||
|
### Kdy použít TEA
|
||||||
|
|
||||||
|
- Projekty vyžadující trasovatelnost požadavků nebo compliance dokumentaci
|
||||||
|
- Týmy potřebující prioritizaci testů založenou na riziku napříč mnoha funkcemi
|
||||||
|
- Podniková prostředí s formálními quality gates před releasem
|
||||||
|
- Složité domény, kde musí být testovací strategie naplánována před psaním testů
|
||||||
|
- Projekty, které přerostly jednoduchý workflow Quinna
|
||||||
|
|
||||||
|
## Jak testování zapadá do workflow
|
||||||
|
|
||||||
|
Quinn workflow Automate se objevuje ve Fázi 4 (Implementace) mapy workflow BMad Method. Je navržen ke spuštění **po dokončení celého epicu** — jakmile jsou všechny stories v epicu implementovány a zrevidovány. Typická sekvence:
|
||||||
|
|
||||||
|
1. Pro každou story v epicu: implementace s Dev (`DS`), pak validace pomocí Code Review (`CR`)
|
||||||
|
2. Po dokončení epicu: generování testů s Quinnem (`QA`) nebo TEA workflow Automate
|
||||||
|
3. Spuštění retrospektivy (`bmad-retrospective`) pro zachycení získaných zkušeností
|
||||||
|
|
||||||
|
Quinn pracuje přímo ze zdrojového kódu bez načítání plánovacích dokumentů (PRD, architektura). TEA workflow mohou integrovat s upstream plánovacími artefakty pro trasovatelnost.
|
||||||
|
|
||||||
|
Pro více o tom, kde testování zapadá do celkového procesu, viz [Mapa pracovních postupů](./workflow-map.md).
|
||||||
|
|
@ -0,0 +1,89 @@
|
||||||
|
---
|
||||||
|
title: "Mapa pracovních postupů"
|
||||||
|
description: Vizuální reference fází workflow BMad Method a jejich výstupů
|
||||||
|
sidebar:
|
||||||
|
order: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
BMad Method (BMM) je modul v ekosystému BMad, zaměřený na dodržování osvědčených postupů context engineeringu a plánování. AI agenti fungují nejlépe s jasným, strukturovaným kontextem. Systém BMM buduje tento kontext progresivně napříč 4 odlišnými fázemi — každá fáze a volitelně více workflow v každé fázi produkují dokumenty, které informují další, takže agenti vždy vědí, co budovat a proč.
|
||||||
|
|
||||||
|
Zdůvodnění a koncepty vycházejí z agilních metodik, které byly v průmyslu úspěšně používány jako mentální framework.
|
||||||
|
|
||||||
|
Pokud si kdykoli nejste jisti, co dělat, skill `bmad-help` vám pomůže zůstat na cestě nebo vědět, co dělat dál. Vždy se můžete odkázat sem — ale `bmad-help` je plně interaktivní a mnohem rychlejší, pokud již máte nainstalovaný BMad Method. Navíc, pokud používáte různé moduly, které rozšířily BMad Method nebo přidaly další komplementární moduly — `bmad-help` se vyvíjí a zná vše, co je dostupné, aby vám dal nejlepší radu v daném okamžiku.
|
||||||
|
|
||||||
|
Důležitá poznámka: Každý workflow níže lze spustit přímo vaším nástrojem přes skill nebo načtením agenta a použitím záznamu z nabídky agenta.
|
||||||
|
|
||||||
|
<iframe src="/workflow-map-diagram.html" title="Diagram mapy workflow BMad Method" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
|
||||||
|
|
||||||
|
<p style="font-size: 0.8rem; text-align: right; margin-top: -0.5rem; margin-bottom: 1rem;">
|
||||||
|
<a href="/workflow-map-diagram.html" target="_blank" rel="noopener noreferrer">Otevřít diagram v novém panelu ↗</a>
|
||||||
|
</p>
|
||||||
|
|
||||||
|
## Fáze 1: Analýza (volitelná)
|
||||||
|
|
||||||
|
Prozkoumejte problémový prostor a validujte nápady před závazkem k plánování.
|
||||||
|
|
||||||
|
| Workflow | Účel | Produkuje |
|
||||||
|
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
|
||||||
|
| `bmad-brainstorming` | Brainstorming nápadů na projekt s řízenou facilitací brainstormingového kouče | `brainstorming-report.md` |
|
||||||
|
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validace tržních, technických nebo doménových předpokladů | Výzkumné nálezy |
|
||||||
|
| `bmad-product-brief` | Zachycení strategické vize — nejlepší, když je váš koncept jasný | `product-brief.md` |
|
||||||
|
| `bmad-prfaq` | Working Backwards — zátěžový test a zformování vašeho produktového konceptu | `prfaq-{project}.md` |
|
||||||
|
|
||||||
|
## Fáze 2: Plánování
|
||||||
|
|
||||||
|
Definujte, co budovat a pro koho.
|
||||||
|
|
||||||
|
| Workflow | Účel | Produkuje |
|
||||||
|
| --------------------------- | ---------------------------------------- | ------------ |
|
||||||
|
| `bmad-create-prd` | Definice požadavků (FR/NFR) | `PRD.md` |
|
||||||
|
| `bmad-create-ux-design` | Návrh uživatelského zážitku (když záleží na UX) | `ux-spec.md` |
|
||||||
|
|
||||||
|
## Fáze 3: Solutioning
|
||||||
|
|
||||||
|
Rozhodněte, jak to budovat, a rozložte práci na stories.
|
||||||
|
|
||||||
|
| Workflow | Účel | Produkuje |
|
||||||
|
| ----------------------------------------- | ------------------------------------------ | --------------------------- |
|
||||||
|
| `bmad-create-architecture` | Explicitní technická rozhodnutí | `architecture.md` s ADR |
|
||||||
|
| `bmad-create-epics-and-stories` | Rozložení požadavků na implementovatelnou práci | Soubory epiců se stories |
|
||||||
|
| `bmad-check-implementation-readiness` | Kontrola brány před implementací | Rozhodnutí PASS/CONCERNS/FAIL |
|
||||||
|
|
||||||
|
## Fáze 4: Implementace
|
||||||
|
|
||||||
|
Budujte to, jednu story po druhé. Brzy plná automatizace fáze 4!
|
||||||
|
|
||||||
|
| Workflow | Účel | Produkuje |
|
||||||
|
| -------------------------- | ------------------------------------------------------------------------ | -------------------------------- |
|
||||||
|
| `bmad-sprint-planning` | Inicializace sledování (jednou na projekt pro sekvencování dev cyklu) | `sprint-status.yaml` |
|
||||||
|
| `bmad-create-story` | Příprava další story pro implementaci | `story-[slug].md` |
|
||||||
|
| `bmad-dev-story` | Implementace story | Fungující kód + testy |
|
||||||
|
| `bmad-code-review` | Validace kvality implementace | Schváleno nebo požadovány změny |
|
||||||
|
| `bmad-correct-course` | Řešení významných změn uprostřed sprintu | Aktualizovaný plán nebo přesměrování |
|
||||||
|
| `bmad-sprint-status` | Sledování průběhu sprintu a stavu stories | Aktualizace stavu sprintu |
|
||||||
|
| `bmad-retrospective` | Revize po dokončení epicu | Poučení |
|
||||||
|
|
||||||
|
## Quick Flow (paralelní cesta)
|
||||||
|
|
||||||
|
Přeskočte fáze 1–3 pro malou, dobře pochopenou práci.
|
||||||
|
|
||||||
|
| Workflow | Účel | Produkuje |
|
||||||
|
| ------------------ | --------------------------------------------------------------------------- | -------------------- |
|
||||||
|
| `bmad-quick-dev` | Sjednocený quick flow — vyjasněte záměr, plánujte, implementujte, revidujte a prezentujte | `spec-*.md` + kód |
|
||||||
|
|
||||||
|
## Správa kontextu
|
||||||
|
|
||||||
|
Každý dokument se stává kontextem pro další fázi. PRD říká architektovi, jaká omezení záleží. Architektura říká dev agentovi, jaké vzory následovat. Soubory stories poskytují zaměřený, kompletní kontext pro implementaci. Bez této struktury agenti dělají nekonzistentní rozhodnutí.
|
||||||
|
|
||||||
|
### Kontext projektu
|
||||||
|
|
||||||
|
:::tip[Doporučeno]
|
||||||
|
Vytvořte `project-context.md` pro zajištění toho, aby AI agenti dodržovali pravidla a preference vašeho projektu. Tento soubor funguje jako ústava vašeho projektu — vede implementační rozhodnutí napříč všemi workflow. Tento volitelný soubor lze vygenerovat na konci tvorby architektury, nebo u existujícího projektu ho lze také vygenerovat pro zachycení toho, co je důležité pro zachování souladu se současnými konvencemi.
|
||||||
|
:::
|
||||||
|
|
||||||
|
**Jak ho vytvořit:**
|
||||||
|
|
||||||
|
- **Ručně** — Vytvořte `_bmad-output/project-context.md` s vaším technologickým stackem a pravidly implementace
|
||||||
|
- **Vygenerujte ho** — Spusťte `bmad-generate-project-context` pro automatické generování z vaší architektury nebo kódové báze
|
||||||
|
|
||||||
|
[**Zjistit více o project-context.md**](../explanation/project-context.md)
|
||||||
|
|
@ -0,0 +1,136 @@
|
||||||
|
---
|
||||||
|
title: Plán rozvoje
|
||||||
|
description: Co chystáme pro BMad – funkce, vylepšení a komunitní příspěvky
|
||||||
|
---
|
||||||
|
|
||||||
|
# Metoda BMad: Veřejný plán rozvoje
|
||||||
|
|
||||||
|
Metoda BMad, modul BMad Method (BMM) a BMad Builder (BMB) se neustále vyvíjejí. Zde je přehled toho, na čem pracujeme a co přijde dál.
|
||||||
|
|
||||||
|
<div class="roadmap-container">
|
||||||
|
|
||||||
|
<h2 class="roadmap-section-title">Probíhá</h2>
|
||||||
|
|
||||||
|
<div class="roadmap-future">
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🧩</span>
|
||||||
|
<h4>Univerzální architektura Skills</h4>
|
||||||
|
<p>Jeden skill, jakákoli platforma. Napište jednou, spusťte kdekoli.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🏗️</span>
|
||||||
|
<h4>BMad Builder v1</h4>
|
||||||
|
<p>Vytvářejte produkční AI agenty a pracovní postupy s vestavěnými eval testy, týmy a elegantní degradací.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🧠</span>
|
||||||
|
<h4>Systém kontextu projektu</h4>
|
||||||
|
<p>Vaše AI skutečně rozumí vašemu projektu. Kontextový systém reagující na framework, který se vyvíjí s vaším kódem.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">📦</span>
|
||||||
|
<h4>Centralizované Skills</h4>
|
||||||
|
<p>Nainstalujte jednou, používejte všude. Sdílejte skills mezi projekty bez zbytečných souborů.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🔄</span>
|
||||||
|
<h4>Adaptivní Skills</h4>
|
||||||
|
<p>Skills, které znají váš nástroj. Optimalizované varianty pro Claude, Codex, Kimi, OpenCode a mnoho dalších.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">📝</span>
|
||||||
|
<h4>Blog BMad Team Pros</h4>
|
||||||
|
<p>Návody, články a postřehy od týmu. Brzy spouštíme.</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<h2 class="roadmap-section-title">Na startu</h2>
|
||||||
|
|
||||||
|
<div class="roadmap-future">
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🏪</span>
|
||||||
|
<h4>Skill Marketplace</h4>
|
||||||
|
<p>Objevujte, instalujte a aktualizujte komunitní skills. Jeden curl příkaz od superschopností.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🎨</span>
|
||||||
|
<h4>Přizpůsobení pracovních postupů</h4>
|
||||||
|
<p>Přizpůsobte si to. Integrujte Jira, Linear, vlastní výstupy — váš workflow, vaše pravidla.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🚀</span>
|
||||||
|
<h4>Optimalizace fází 1–3</h4>
|
||||||
|
<p>Bleskurychlé plánování s kontextovým sběrem sub-agentů. Režim YOLO kombinovaný s řízenou kvalitou.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🌐</span>
|
||||||
|
<h4>Připraveno pro podniky</h4>
|
||||||
|
<p>SSO, auditní logy, týmové pracovní prostory. Všechny ty nudné věci, díky kterým firmy řeknou ano.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">💎</span>
|
||||||
|
<h4>Exploze komunitních modulů</h4>
|
||||||
|
<p>Zábava, bezpečnost, terapie, roleplay a mnohem víc. Rozšiřte platformu BMad Method.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">⚡</span>
|
||||||
|
<h4>Automatizace Dev Loop</h4>
|
||||||
|
<p>Volitelný autopilot pro vývoj. Nechte AI řídit tok práce a přitom udržujte vysokou kvalitu.</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<h2 class="roadmap-section-title">Komunita a tým</h2>
|
||||||
|
|
||||||
|
<div class="roadmap-future">
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🎙️</span>
|
||||||
|
<h4>Podcast metody BMad</h4>
|
||||||
|
<p>Rozhovory o AI-nativním vývoji. Spouštíme 1. března 2026!</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🎓</span>
|
||||||
|
<h4>Master Class metody BMad</h4>
|
||||||
|
<p>Od uživatele k expertovi. Hluboké ponory do každé fáze, každého workflow, každého tajemství.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🏗️</span>
|
||||||
|
<h4>Master Class BMad Builder</h4>
|
||||||
|
<p>Vytvářejte vlastní agenty. Pokročilé techniky pro chvíle, kdy jste připraveni tvořit, ne jen používat.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">⚡</span>
|
||||||
|
<h4>BMad Prototype First</h4>
|
||||||
|
<p>Od nápadu k fungujícímu prototypu v jedné relaci. Vytvořte svou vysněnou aplikaci jako umělecké dílo.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🌴</span>
|
||||||
|
<h4>BMad BALM!</h4>
|
||||||
|
<p>Správa života pro AI-nativní uživatele. Úkoly, návyky, cíle — váš AI kopilot pro všechno.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🖥️</span>
|
||||||
|
<h4>Oficiální UI</h4>
|
||||||
|
<p>Krásné rozhraní pro celý ekosystém BMad. Síla CLI, lesk GUI.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🔒</span>
|
||||||
|
<h4>BMad in a Box</h4>
|
||||||
|
<p>Self-hosted, bez připojení, podnikové kvality. Váš AI asistent, vaše infrastruktura, vaše kontrola.</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<div style="text-align: center; margin-top: 3rem; padding: 2rem; background: var(--color-bg-card); border-radius: 12px; border: 1px solid var(--color-border);">
|
||||||
|
<h3 style="margin: 0 0 1rem;">Chcete přispět?</h3>
|
||||||
|
<p style="color: var(--slate-color-400); margin: 0;">
|
||||||
|
Toto je pouze částečný seznam toho, co je plánováno. Open source tým BMad vítá přispěvatele!{" "}<br />
|
||||||
|
<a href="https://github.com/bmad-code-org/BMAD-METHOD" style="color: var(--color-in-progress);">Přidejte se k nám na GitHubu</a> a pomozte formovat budoucnost vývoje řízeného AI.
|
||||||
|
</p>
|
||||||
|
<p style="color: var(--slate-color-400); margin: 1.5rem 0 0;">
|
||||||
|
Líbí se vám, co budujeme? Oceníme jak jednorázovou, tak měsíční{" "}<a href="https://buymeacoffee.com/bmad" style="color: var(--color-in-progress);">podporu</a>.
|
||||||
|
</p>
|
||||||
|
<p style="color: var(--slate-color-400); margin: 1rem 0 0;">
|
||||||
|
Pro firemní sponzoring, partnerské dotazy, přednášky, školení nebo mediální dotazy:{" "}
|
||||||
|
<a href="mailto:contact@bmadcode.com" style="color: var(--color-in-progress);">contact@bmadcode.com</a>
|
||||||
|
</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
@ -0,0 +1,276 @@
|
||||||
|
---
|
||||||
|
title: "Začínáme"
|
||||||
|
description: Nainstalujte BMad a vytvořte svůj první projekt
|
||||||
|
---
|
||||||
|
|
||||||
|
Vytvářejte software rychleji pomocí pracovních postupů řízených AI se specializovanými agenty, kteří vás provedou plánováním, architekturou a implementací.
|
||||||
|
|
||||||
|
## Co se naučíte
|
||||||
|
|
||||||
|
- Nainstalovat a inicializovat BMad Method pro nový projekt
|
||||||
|
- Používat **BMad-Help** — vašeho inteligentního průvodce, který ví, co dělat dál
|
||||||
|
- Vybrat správnou plánovací cestu pro velikost vašeho projektu
|
||||||
|
- Postupovat fázemi od požadavků k fungujícímu kódu
|
||||||
|
- Efektivně používat agenty a pracovní postupy
|
||||||
|
|
||||||
|
:::note[Předpoklady]
|
||||||
|
- **Node.js 20+** — Vyžadováno pro instalátor
|
||||||
|
- **Git** — Doporučeno pro správu verzí
|
||||||
|
- **AI-powered IDE** — Claude Code, Cursor nebo podobné
|
||||||
|
- **Nápad na projekt** — I jednoduchý stačí pro učení
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::tip[Nejsnadnější cesta]
|
||||||
|
**Instalace** → `npx bmad-method install`
|
||||||
|
**Zeptejte se** → `bmad-help what should I do first?`
|
||||||
|
**Tvořte** → Nechte BMad-Help vás provést workflow po workflow
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Seznamte se s BMad-Help: Váš inteligentní průvodce
|
||||||
|
|
||||||
|
**BMad-Help je nejrychlejší způsob, jak začít s BMad.** Nemusíte si pamatovat workflow nebo fáze — prostě se zeptejte a BMad-Help:
|
||||||
|
|
||||||
|
- **Prozkoumá váš projekt** a zjistí, co už bylo uděláno
|
||||||
|
- **Ukáže vaše možnosti** na základě nainstalovaných modulů
|
||||||
|
- **Doporučí, co dál** — včetně prvního povinného úkolu
|
||||||
|
- **Odpoví na otázky** jako „Mám nápad na SaaS, kde začít?“
|
||||||
|
|
||||||
|
### Jak používat BMad-Help
|
||||||
|
|
||||||
|
Spusťte ho ve vašem AI IDE vyvoláním skillu:
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help
|
||||||
|
```
|
||||||
|
|
||||||
|
Nebo ho spojte s otázkou pro kontextové poradenství:
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help I have an idea for a SaaS product, I already know all the features I want. where do I get started?
|
||||||
|
```
|
||||||
|
|
||||||
|
BMad-Help odpoví s:
|
||||||
|
- Co je doporučeno pro vaši situaci
|
||||||
|
- Jaký je první povinný úkol
|
||||||
|
- Jak vypadá zbytek procesu
|
||||||
|
|
||||||
|
### Řídí i pracovní postupy
|
||||||
|
|
||||||
|
BMad-Help nejen odpovídá na otázky — **automaticky se spouští na konci každého workflow** a řekne vám přesně, co dělat dál. Žádné hádání, žádné prohledávání dokumentace — jen jasné pokyny k dalšímu povinnému workflow.
|
||||||
|
|
||||||
|
:::tip[Začněte zde]
|
||||||
|
Po instalaci BMad okamžitě vyvolejte skill `bmad-help`. Detekuje, jaké moduly máte nainstalované, a navede vás ke správnému výchozímu bodu pro váš projekt.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Pochopení BMad
|
||||||
|
|
||||||
|
BMad vám pomáhá vytvářet software prostřednictvím řízených pracovních postupů se specializovanými AI agenty. Proces probíhá ve čtyřech fázích:
|
||||||
|
|
||||||
|
| Fáze | Název | Co se děje |
|
||||||
|
| ---- | -------------- | ------------------------------------------------------- |
|
||||||
|
| 1 | Analýza | Brainstorming, průzkum, product brief nebo PRFAQ *(volitelné)* |
|
||||||
|
| 2 | Plánování | Vytvoření požadavků (PRD nebo specifikace) |
|
||||||
|
| 3 | Solutioning | Návrh architektury *(pouze BMad Method/Enterprise)* |
|
||||||
|
| 4 | Implementace | Budování epic po epicu, story po story |
|
||||||
|
|
||||||
|
**[Otevřete Mapu pracovních postupů](../reference/workflow-map.md)** pro prozkoumání fází, workflow a správy kontextu.
|
||||||
|
|
||||||
|
Na základě složitosti vašeho projektu nabízí BMad tři plánovací cesty:
|
||||||
|
|
||||||
|
| Cesta | Nejlepší pro | Vytvořené dokumenty |
|
||||||
|
| --------------- | -------------------------------------------------------------- | -------------------------------------- |
|
||||||
|
| **Quick Flow** | Opravy chyb, jednoduché funkce, jasný rozsah (1–15 stories) | Pouze tech-spec |
|
||||||
|
| **BMad Method** | Produkty, platformy, složité funkce (10–50+ stories) | PRD + architektura + UX |
|
||||||
|
| **Enterprise** | Compliance, multi-tenant systémy (30+ stories) | PRD + architektura + bezpečnost + DevOps |
|
||||||
|
|
||||||
|
:::note
|
||||||
|
Počty stories jsou orientační, ne definitivní. Vyberte si cestu podle potřeb plánování, ne podle počtu stories.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Instalace
|
||||||
|
|
||||||
|
Otevřete terminál v adresáři vašeho projektu a spusťte:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install
|
||||||
|
```
|
||||||
|
|
||||||
|
Pokud chcete nejnovější prereleaseový build místo výchozího release kanálu, použijte `npx bmad-method@next install`.
|
||||||
|
|
||||||
|
Při výzvě k výběru modulů zvolte **BMad Method**.
|
||||||
|
|
||||||
|
Instalátor vytvoří dvě složky:
|
||||||
|
- `_bmad/` — agenti, workflow, úkoly a konfigurace
|
||||||
|
- `_bmad-output/` — prozatím prázdná, ale zde se budou ukládat vaše artefakty
|
||||||
|
|
||||||
|
:::tip[Váš další krok]
|
||||||
|
Otevřete vaše AI IDE ve složce projektu a spusťte:
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help
|
||||||
|
```
|
||||||
|
|
||||||
|
BMad-Help detekuje, co jste dokončili, a doporučí přesně, co dělat dál. Můžete mu také klást otázky jako „Jaké mám možnosti?“ nebo „Mám nápad na SaaS, kde začít?“
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::note[Jak načítat agenty a spouštět workflow]
|
||||||
|
Každý workflow má **skill**, který vyvoláte jménem ve vašem IDE (např. `bmad-create-prd`). Váš AI nástroj rozpozná název `bmad-*` a spustí ho — nemusíte načítat agenty zvlášť. Můžete také vyvolat agentní skill přímo pro obecnou konverzaci (např. `bmad-agent-pm` pro PM agenta).
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::caution[Nové chaty]
|
||||||
|
Vždy začněte nový chat pro každý workflow. Tím předejdete problémům s kontextovými omezeními.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Krok 1: Vytvořte svůj plán
|
||||||
|
|
||||||
|
Projděte fázemi 1–3. **Pro každý workflow používejte nové chaty.**
|
||||||
|
|
||||||
|
:::tip[Kontext projektu (volitelné)]
|
||||||
|
Před začátkem zvažte vytvoření `project-context.md` pro dokumentaci vašich technických preferencí a pravidel implementace. Tím zajistíte, že všichni AI agenti budou dodržovat vaše konvence v průběhu celého projektu.
|
||||||
|
|
||||||
|
Vytvořte ho ručně na `_bmad-output/project-context.md` nebo ho vygenerujte po architektuře pomocí `bmad-generate-project-context`. [Zjistit více](../explanation/project-context.md).
|
||||||
|
:::
|
||||||
|
|
||||||
|
### Fáze 1: Analýza (volitelná)
|
||||||
|
|
||||||
|
Všechny workflow v této fázi jsou volitelné:
|
||||||
|
- **brainstorming** (`bmad-brainstorming`) — Řízená ideace
|
||||||
|
- **průzkum** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Tržní, doménový a technický průzkum
|
||||||
|
- **product-brief** (`bmad-product-brief`) — Doporučený základní dokument, když je váš koncept jasný
|
||||||
|
- **prfaq** (`bmad-prfaq`) — Working Backwards výzva pro zátěžový test a zformování vašeho produktového konceptu
|
||||||
|
|
||||||
|
### Fáze 2: Plánování (povinná)
|
||||||
|
|
||||||
|
**Pro BMad Method a Enterprise cesty:**
|
||||||
|
1. Vyvolejte **PM agenta** (`bmad-agent-pm`) v novém chatu
|
||||||
|
2. Spusťte workflow `bmad-create-prd` (`bmad-create-prd`)
|
||||||
|
3. Výstup: `PRD.md`
|
||||||
|
|
||||||
|
**Pro Quick Flow cestu:**
|
||||||
|
- Spusťte `bmad-quick-dev` — zvládne plánování i implementaci v jednom workflow, přeskočte k implementaci
|
||||||
|
|
||||||
|
:::note[UX Design (volitelné)]
|
||||||
|
Pokud má váš projekt uživatelské rozhraní, vyvolejte **UX-Designer agenta** (`bmad-agent-ux-designer`) a spusťte UX design workflow (`bmad-create-ux-design`) po vytvoření PRD.
|
||||||
|
:::
|
||||||
|
|
||||||
|
### Fáze 3: Solutioning (BMad Method/Enterprise)
|
||||||
|
|
||||||
|
**Vytvoření architektury**
|
||||||
|
1. Vyvolejte **Architect agenta** (`bmad-agent-architect`) v novém chatu
|
||||||
|
2. Spusťte `bmad-create-architecture` (`bmad-create-architecture`)
|
||||||
|
3. Výstup: Dokument architektury s technickými rozhodnutími
|
||||||
|
|
||||||
|
**Vytvoření epiců a stories**
|
||||||
|
|
||||||
|
:::tip[Vylepšení ve V6]
|
||||||
|
Epicy a stories se nyní vytvářejí *po* architektuře. Tím vznikají kvalitnější stories, protože architektonická rozhodnutí (databáze, API vzory, tech stack) přímo ovlivňují rozklad práce.
|
||||||
|
:::
|
||||||
|
|
||||||
|
1. Vyvolejte **PM agenta** (`bmad-agent-pm`) v novém chatu
|
||||||
|
2. Spusťte `bmad-create-epics-and-stories` (`bmad-create-epics-and-stories`)
|
||||||
|
3. Workflow využívá jak PRD, tak architekturu k vytvoření technicky informovaných stories
|
||||||
|
|
||||||
|
**Kontrola připravenosti k implementaci** *(vysoce doporučeno)*
|
||||||
|
1. Vyvolejte **Architect agenta** (`bmad-agent-architect`) v novém chatu
|
||||||
|
2. Spusťte `bmad-check-implementation-readiness` (`bmad-check-implementation-readiness`)
|
||||||
|
3. Validuje soudržnost všech plánovacích dokumentů
|
||||||
|
|
||||||
|
## Krok 2: Sestavte svůj projekt
|
||||||
|
|
||||||
|
Jakmile je plánování dokončeno, přejděte k implementaci. **Každý workflow by měl běžet v novém chatu.**
|
||||||
|
|
||||||
|
### Inicializace plánování sprintu
|
||||||
|
|
||||||
|
Vyvolejte **Developer agenta** (`bmad-agent-dev`) a spusťte `bmad-sprint-planning` (`bmad-sprint-planning`). Tím se vytvoří `sprint-status.yaml` pro sledování všech epiců a stories.
|
||||||
|
|
||||||
|
### Cyklus vývoje
|
||||||
|
|
||||||
|
Pro každou story opakujte tento cyklus s novými chaty:
|
||||||
|
|
||||||
|
| Krok | Agent | Workflow | Příkaz | Účel |
|
||||||
|
| ---- | ----- | -------------------- | -------------------------- | ---------------------------------- |
|
||||||
|
| 1 | DEV | `bmad-create-story` | `bmad-create-story` | Vytvoření story souboru z epicu |
|
||||||
|
| 2 | DEV | `bmad-dev-story` | `bmad-dev-story` | Implementace story |
|
||||||
|
| 3 | DEV | `bmad-code-review` | `bmad-code-review` | Validace kvality *(doporučeno)* |
|
||||||
|
|
||||||
|
Po dokončení všech stories v epicu vyvolejte **Developer agenta** (`bmad-agent-dev`) a spusťte `bmad-retrospective` (`bmad-retrospective`).
|
||||||
|
|
||||||
|
## Co jste dosáhli
|
||||||
|
|
||||||
|
Naučili jste se základy budování s BMad:
|
||||||
|
|
||||||
|
- Nainstalovali BMad a nakonfigurovali ho pro vaše IDE
|
||||||
|
- Inicializovali projekt s vybranou plánovací cestou
|
||||||
|
- Vytvořili plánovací dokumenty (PRD, architektura, epicy a stories)
|
||||||
|
- Pochopili cyklus vývoje pro implementaci
|
||||||
|
|
||||||
|
Váš projekt nyní obsahuje:
|
||||||
|
|
||||||
|
```text
|
||||||
|
váš-projekt/
|
||||||
|
├── _bmad/ # Konfigurace BMad
|
||||||
|
├── _bmad-output/
|
||||||
|
│ ├── planning-artifacts/
|
||||||
|
│ │ ├── PRD.md # Váš dokument požadavků
|
||||||
|
│ │ ├── architecture.md # Technická rozhodnutí
|
||||||
|
│ │ └── epics/ # Soubory epiců a stories
|
||||||
|
│ ├── implementation-artifacts/
|
||||||
|
│ │ └── sprint-status.yaml # Sledování sprintu
|
||||||
|
│ └── project-context.md # Pravidla implementace (volitelné)
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
|
||||||
|
## Rychlý přehled
|
||||||
|
|
||||||
|
| Workflow | Příkaz | Agent | Účel |
|
||||||
|
| ------------------------------------- | ------------------------------------------ | --------- | ----------------------------------------------- |
|
||||||
|
| **`bmad-help`** ⭐ | `bmad-help` | Jakýkoli | **Váš inteligentní průvodce — ptejte se na cokoli!** |
|
||||||
|
| `bmad-create-prd` | `bmad-create-prd` | PM | Vytvoření dokumentu požadavků (PRD) |
|
||||||
|
| `bmad-create-architecture` | `bmad-create-architecture` | Architect | Vytvoření dokumentu architektury |
|
||||||
|
| `bmad-generate-project-context` | `bmad-generate-project-context` | Analyst | Vytvoření souboru kontextu projektu |
|
||||||
|
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | Rozklad PRD na epicy |
|
||||||
|
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | Validace soudržnosti plánování |
|
||||||
|
| `bmad-sprint-planning` | `bmad-sprint-planning` | DEV | Inicializace sledování sprintu |
|
||||||
|
| `bmad-create-story` | `bmad-create-story` | DEV | Vytvoření souboru story |
|
||||||
|
| `bmad-dev-story` | `bmad-dev-story` | DEV | Implementace story |
|
||||||
|
| `bmad-code-review` | `bmad-code-review` | DEV | Revize implementovaného kódu |
|
||||||
|
|
||||||
|
## Časté otázky
|
||||||
|
|
||||||
|
**Potřebuji vždy architekturu?**
|
||||||
|
Pouze pro BMad Method a Enterprise cesty. Quick Flow přeskakuje ze specifikace rovnou k implementaci.
|
||||||
|
|
||||||
|
**Mohu později změnit svůj plán?**
|
||||||
|
Ano. Workflow `bmad-correct-course` (`bmad-correct-course`) řeší změny rozsahu během implementace.
|
||||||
|
|
||||||
|
**Co když chci nejdřív brainstormovat?**
|
||||||
|
Vyvolejte Analyst agenta (`bmad-agent-analyst`) a spusťte `bmad-brainstorming` (`bmad-brainstorming`) před zahájením PRD.
|
||||||
|
|
||||||
|
**Musím dodržovat striktní pořadí?**
|
||||||
|
Ne striktně. Jakmile se naučíte postup, můžete spouštět workflow přímo pomocí Rychlého přehledu výše.
|
||||||
|
|
||||||
|
## Získání pomoci
|
||||||
|
|
||||||
|
:::tip[První zastávka: BMad-Help]
|
||||||
|
**Vyvolejte `bmad-help` kdykoli** — je to nejrychlejší způsob, jak se odpoutat. Zeptejte se na cokoli:
|
||||||
|
- „Co mám dělat po instalaci?“
|
||||||
|
- „Zasekl jsem se na workflow X“
|
||||||
|
- „Jaké mám možnosti pro Y?“
|
||||||
|
- „Ukaž mi, co bylo dosud uděláno“
|
||||||
|
|
||||||
|
BMad-Help prozkoumá váš projekt, detekuje, co jste dokončili, a řekne vám přesně, co dělat dál.
|
||||||
|
:::
|
||||||
|
|
||||||
|
- **Během workflow** — Agenti vás provázejí otázkami a vysvětleními
|
||||||
|
- **Komunita** — [Discord](https://discord.gg/gk8jAdXWmj) (#bmad-method-help, #report-bugs-and-issues)
|
||||||
|
|
||||||
|
## Klíčové poznatky
|
||||||
|
|
||||||
|
:::tip[Zapamatujte si]
|
||||||
|
- **Začněte s `bmad-help`** — Váš inteligentní průvodce, který zná váš projekt a možnosti
|
||||||
|
- **Vždy používejte nové chaty** — Začněte nový chat pro každý workflow
|
||||||
|
- **Cesta záleží** — Quick Flow používá `bmad-quick-dev`; Method/Enterprise vyžadují PRD a architekturu
|
||||||
|
- **BMad-Help se spouští automaticky** — Každý workflow končí pokyny, co dělat dál
|
||||||
|
:::
|
||||||
|
|
||||||
|
Jste připraveni začít? Nainstalujte BMad, vyvolejte `bmad-help` a nechte svého inteligentního průvodce ukázat cestu.
|
||||||
|
|
@ -0,0 +1,70 @@
|
||||||
|
---
|
||||||
|
title: "Analysis Phase: From Idea to Foundation"
|
||||||
|
description: What brainstorming, research, product briefs, and PRFAQs are — and when to use each
|
||||||
|
sidebar:
|
||||||
|
order: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
The Analysis phase (Phase 1) helps you think clearly about your product before committing to building it. Every tool in this phase is optional, but skipping analysis entirely means your PRD is built on assumptions instead of insight.
|
||||||
|
|
||||||
|
## Why Analysis Before Planning?
|
||||||
|
|
||||||
|
A PRD answers "what should we build and why?" If you feed it vague thinking, you get a vague PRD — and every downstream document inherits that vagueness. Architecture built on a weak PRD makes wrong technical bets. Stories derived from weak architecture miss edge cases. The cost compounds.
|
||||||
|
|
||||||
|
Analysis tools exist to make your PRD sharp. They attack the problem from different angles — creative exploration, market reality, customer clarity, feasibility — so that by the time you sit down with the PM agent, you know what you're building and for whom.
|
||||||
|
|
||||||
|
## The Tools
|
||||||
|
|
||||||
|
### Brainstorming
|
||||||
|
|
||||||
|
**What it is.** A facilitated creative session using proven ideation techniques. The AI acts as coach, pulling ideas out of you through structured exercises — not generating ideas for you.
|
||||||
|
|
||||||
|
**Why it's here.** Raw ideas need space to develop before they get locked into requirements. Brainstorming creates that space. It's especially valuable when you have a problem domain but no clear solution, or when you want to explore multiple directions before committing.
|
||||||
|
|
||||||
|
**When to use it.** You have a vague sense of what you want to build but haven't crystallized the concept. Or you have a concept but want to pressure-test it against alternatives.
|
||||||
|
|
||||||
|
See [Brainstorming](./brainstorming.md) for a deeper look at how sessions work.
|
||||||
|
|
||||||
|
### Research (Market, Domain, Technical)
|
||||||
|
|
||||||
|
**What it is.** Three focused research workflows that investigate different dimensions of your idea. Market research examines competitors, trends, and user sentiment. Domain research builds subject-matter expertise and terminology. Technical research evaluates feasibility, architecture options, and implementation approaches.
|
||||||
|
|
||||||
|
**Why it's here.** Building on assumptions is the fastest way to build something nobody needs. Research grounds your concept in reality — what competitors already exist, what users actually struggle with, what's technically feasible, and what industry-specific constraints you'll face.
|
||||||
|
|
||||||
|
**When to use it.** You're entering an unfamiliar domain, you suspect competitors exist but haven't mapped them, or your concept depends on technical capabilities you haven't validated. Run one, two, or all three — each stands alone.
|
||||||
|
|
||||||
|
### Product Brief
|
||||||
|
|
||||||
|
**What it is.** A guided discovery session that produces a 1-2 page executive summary of your product concept. The AI acts as a collaborative Business Analyst, helping you articulate the vision, target audience, value proposition, and scope.
|
||||||
|
|
||||||
|
**Why it's here.** The product brief is the gentler path into planning. It captures your strategic vision in a structured format that feeds directly into PRD creation. It works best when you already have conviction about your concept — you know the customer, the problem, and roughly what you want to build. The brief organizes and sharpens that thinking.
|
||||||
|
|
||||||
|
**When to use it.** Your concept is relatively clear and you want to document it efficiently before creating a PRD. You're confident in the direction and don't need your assumptions aggressively challenged.
|
||||||
|
|
||||||
|
### PRFAQ (Working Backwards)
|
||||||
|
|
||||||
|
**What it is.** Amazon's Working Backwards methodology adapted as an interactive challenge. You write the press release announcing your finished product before a single line of code exists, then answer the hardest questions customers and stakeholders would ask. The AI acts as a relentless but constructive product coach.
|
||||||
|
|
||||||
|
**Why it's here.** The PRFAQ is the rigorous path into planning. It forces customer-first clarity by making you defend every claim. If you can't write a compelling press release, the product isn't ready. If customer FAQ answers reveal gaps, those are gaps you'd discover much later — and more expensively — during implementation. The gauntlet surfaces weak thinking early, when it's cheapest to fix.
|
||||||
|
|
||||||
|
**When to use it.** You want your concept stress-tested before committing resources. You're unsure whether users will actually care. You want to validate that you can articulate a clear, defensible value proposition. Or you simply want the discipline of Working Backwards to sharpen your thinking.
|
||||||
|
|
||||||
|
## Which Should I Use?
|
||||||
|
|
||||||
|
| Situation | Recommended tool |
|
||||||
|
| --------- | ---------------- |
|
||||||
|
| "I have a vague idea, not sure where to start" | Brainstorming |
|
||||||
|
| "I need to understand the market before deciding" | Research |
|
||||||
|
| "I know what I want to build, just need to document it" | Product Brief |
|
||||||
|
| "I want to make sure this idea is actually worth building" | PRFAQ |
|
||||||
|
| "I want to explore, then validate, then document" | Brainstorming → Research → PRFAQ or Brief |
|
||||||
|
|
||||||
|
Product Brief and PRFAQ both produce input for the PRD — choose one based on how much challenge you want. The brief is collaborative discovery. The PRFAQ is a gauntlet. Both get you to the same destination; the PRFAQ tests whether your concept deserves to get there.
|
||||||
|
|
||||||
|
:::tip[Not Sure?]
|
||||||
|
Run `bmad-help` and describe your situation. It will recommend the right starting point based on what you've already done and what you're trying to accomplish.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## What Happens After Analysis?
|
||||||
|
|
||||||
|
Analysis outputs feed directly into Phase 2 (Planning). The PRD workflow accepts product briefs, PRFAQ documents, research findings, and brainstorming reports as input — it synthesizes whatever you've produced into structured requirements. The more analysis you do, the sharper your PRD.
|
||||||
|
|
@ -0,0 +1,92 @@
|
||||||
|
---
|
||||||
|
title: "Checkpoint Preview"
|
||||||
|
description: LLM-assisted human-in-the-loop review that guides you through a change from purpose to details
|
||||||
|
sidebar:
|
||||||
|
order: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
`bmad-checkpoint-preview` is an interactive, LLM-assisted human-in-the-loop review workflow. It walks you through a code change — from purpose and context into details — so you can make an informed decision about whether to ship, rework, or dig deeper.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## The Typical Flow
|
||||||
|
|
||||||
|
You run `bmad-quick-dev`. It clarifies your intent, builds a spec, implements the change, and when it's done it appends a review trail to the spec file and opens it in your editor. You look at the spec and see the change touched 20 files across several modules.
|
||||||
|
|
||||||
|
You could eyeball the diff. But 20 files is where eyeballing starts to fail — you lose the thread, miss a connection between two distant changes, or approve something you didn't fully understand. So instead, you say "checkpoint" and the LLM walks you through it.
|
||||||
|
|
||||||
|
That handoff — from autonomous implementation back to human judgment — is the primary use case. Quick-dev runs long with minimal supervision. Checkpoint Preview is where you take back the wheel.
|
||||||
|
|
||||||
|
## Why It Exists
|
||||||
|
|
||||||
|
Code review has two failure modes. In one, the reviewer skims the diff, nothing jumps out, and they approve. In the other, they methodically read every file but lose the thread — they see the trees and miss the forest. Both result in the same outcome: the review didn't catch the thing that mattered.
|
||||||
|
|
||||||
|
The underlying issue is sequencing. A raw diff presents changes in file order, which is almost never the order that builds understanding. You see a helper function before you know why it exists. You see a schema change before you understand what feature it supports. The reviewer has to reconstruct the author's intent from scattered clues, and that reconstruction is where attention fails.
|
||||||
|
|
||||||
|
Checkpoint Preview solves this by making the LLM do the reconstruction work. It reads the diff, the spec (if one exists), and the surrounding codebase, then presents the change in an order designed for comprehension — not for `git diff`.
|
||||||
|
|
||||||
|
## How It Works
|
||||||
|
|
||||||
|
The workflow has five steps. Each step builds on the previous one, progressively shifting from "what is this?" toward "should we ship it?"
|
||||||
|
|
||||||
|
### 1. Orientation
|
||||||
|
|
||||||
|
The workflow identifies the change (from a PR, commit, branch, spec file, or the current git state) and produces a one-line intent summary plus surface area stats: files changed, modules touched, lines of logic, boundary crossings, and new public interfaces.
|
||||||
|
|
||||||
|
This is the "is this what I think it is?" moment. Before reading any code, the reviewer confirms they're looking at the right thing and calibrates their expectations for scope.
|
||||||
|
|
||||||
|
### 2. Walkthrough
|
||||||
|
|
||||||
|
The change is organized by **concern** — cohesive design intents like "input validation" or "API contract" — not by file. Each concern gets a short explanation of *why* this approach was chosen, followed by clickable `path:line` stops that the reviewer can follow through the code.
|
||||||
|
|
||||||
|
This is the design judgment step. The reviewer evaluates whether the approach is right for the system, not whether the code is correct. Concerns are sequenced top-down: the highest-level intent first, then supporting implementation. The reviewer never encounters a reference to something they haven't seen yet.
|
||||||
|
|
||||||
|
### 3. Detail Pass
|
||||||
|
|
||||||
|
After the reviewer understands the design, the workflow surfaces 2-5 spots where a mistake would have the highest blast radius. These are tagged by risk category — `[auth]`, `[schema]`, `[billing]`, `[public API]`, `[security]`, and others — and ordered by how much breaks if they're wrong.
|
||||||
|
|
||||||
|
This is not a bug hunt. Automated tests and CI handle correctness. The detail pass activates risk awareness: "here are the places where being wrong costs the most." If the reviewer wants to go deeper on a specific area, they can say "dig into [area]" for a targeted correctness-focused re-review.
|
||||||
|
|
||||||
|
If the spec went through adversarial review loops (machine hardening), those findings are surfaced here too — not the bugs that were fixed, but the decisions that the review loop flagged that the reviewer should be aware of.
|
||||||
|
|
||||||
|
### 4. Testing
|
||||||
|
|
||||||
|
Suggests 2-5 ways to manually observe the change working. Not automated test commands — manual observations that build confidence no test suite provides. A UI interaction to try, a CLI command to run, an API request to send, with expected results for each.
|
||||||
|
|
||||||
|
If the change has no user-visible behavior, it says so. No invented busywork.
|
||||||
|
|
||||||
|
### 5. Wrap-Up
|
||||||
|
|
||||||
|
The reviewer makes the call: approve, rework, or keep discussing. If approving a PR, the workflow can help with `gh pr review --approve`. If reworking, it helps diagnose whether the problem was the approach, the spec, or the implementation, and helps draft actionable feedback tied to specific code locations.
|
||||||
|
|
||||||
|
## It's a Conversation, Not a Report
|
||||||
|
|
||||||
|
The workflow presents each step as a starting point, not a final word. Between steps — or in the middle of one — you can talk to the LLM, ask questions, challenge its framing, or pull in other skills to get a different perspective:
|
||||||
|
|
||||||
|
- **"run advanced elicitation on the error handling"** — push the LLM to reconsider and refine its analysis of a specific area
|
||||||
|
- **"party mode on whether this schema migration is safe"** — bring multiple agent perspectives into a focused debate
|
||||||
|
- **"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 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 you.
|
||||||
|
|
||||||
|
## The Review Trail
|
||||||
|
|
||||||
|
The walkthrough step works best when it has a **Suggested Review Order** — a list of stops the spec author wrote to guide reviewers through the change. When a spec includes this, the workflow uses it directly.
|
||||||
|
|
||||||
|
When no author-produced trail exists, the workflow generates one from the diff and codebase context. A generated trail is lower quality than an author-produced one, but far better than reading changes in file order.
|
||||||
|
|
||||||
|
## When to Use It
|
||||||
|
|
||||||
|
The primary scenario is the handoff from `bmad-quick-dev`: the implementation is done, the spec file is open in your editor with a review trail appended, and you need to decide whether to ship. Say "checkpoint" and go.
|
||||||
|
|
||||||
|
It also works standalone:
|
||||||
|
|
||||||
|
- **Reviewing a PR** — especially one with more than a handful of files or cross-cutting changes
|
||||||
|
- **Onboarding to a change** — when you need to understand what happened on a branch you didn't write
|
||||||
|
- **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 in any terminal, but you'll get more out of it inside an IDE — VS Code, Cursor, or similar — because the workflow produces `path:line` references at every step. In an IDE-embedded terminal those are clickable, so you can jump from file to file as you follow the review trail.
|
||||||
|
|
||||||
|
## What It Is Not
|
||||||
|
|
||||||
|
Checkpoint Preview is not a substitute for automated 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.
|
||||||
|
|
@ -34,7 +34,7 @@ Yes! Quick Flow works great for established projects. It will:
|
||||||
- Auto-detect your existing stack
|
- Auto-detect your existing stack
|
||||||
- Analyze existing code patterns
|
- Analyze existing code patterns
|
||||||
- Detect conventions and ask for confirmation
|
- Detect conventions and ask for confirmation
|
||||||
- Generate context-rich tech-spec that respects existing code
|
- Generate context-rich spec that respects existing code
|
||||||
|
|
||||||
Perfect for bug fixes and small features in existing codebases.
|
Perfect for bug fixes and small features in existing codebases.
|
||||||
|
|
||||||
|
|
@ -43,7 +43,7 @@ Perfect for bug fixes and small features in existing codebases.
|
||||||
Quick Flow detects your conventions and asks: "Should I follow these existing conventions?" You decide:
|
Quick Flow detects your conventions and asks: "Should I follow these existing conventions?" You decide:
|
||||||
|
|
||||||
- **Yes** → Maintain consistency with current codebase
|
- **Yes** → Maintain consistency with current codebase
|
||||||
- **No** → Establish new standards (document why in tech-spec)
|
- **No** → Establish new standards (document why in spec)
|
||||||
|
|
||||||
BMM respects your choice — it won't force modernization, but it will offer it.
|
BMM respects your choice — it won't force modernization, but it will offer it.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -25,7 +25,7 @@ Every implementation workflow automatically loads `project-context.md` if it exi
|
||||||
- `bmad-create-story` — informs story creation with project patterns
|
- `bmad-create-story` — informs story creation with project patterns
|
||||||
- `bmad-dev-story` — guides implementation decisions
|
- `bmad-dev-story` — guides implementation decisions
|
||||||
- `bmad-code-review` — validates against project standards
|
- `bmad-code-review` — validates against project standards
|
||||||
- `bmad-quick-dev` — applies patterns when implementing tech-specs
|
- `bmad-quick-dev` — applies patterns when implementing specs
|
||||||
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — provides project-wide context
|
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — provides project-wide context
|
||||||
|
|
||||||
## When to Create It
|
## When to Create It
|
||||||
|
|
|
||||||
|
|
@ -1,15 +1,15 @@
|
||||||
---
|
---
|
||||||
title: "Quick Dev New Preview"
|
title: "Quick Dev"
|
||||||
description: Reduce human-in-the-loop friction without giving up the checkpoints that protect output quality
|
description: Reduce human-in-the-loop friction without giving up the checkpoints that protect output quality
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 2
|
order: 2
|
||||||
---
|
---
|
||||||
|
|
||||||
`bmad-quick-dev-new-preview` is an experimental attempt to radically improve Quick Flow: intent in, code changes out, with lower ceremony and fewer human-in-the-loop turns without sacrificing quality.
|
Intent in, code changes out, with as few human-in-the-loop turns as possible — without sacrificing quality.
|
||||||
|
|
||||||
It lets the model run longer between checkpoints, then brings the human back only when the task cannot safely continue without human judgment or when it is time to review the end result.
|
It lets the model run longer between checkpoints, then brings the human back only when the task cannot safely continue without human judgment or when it is time to review the end result.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Why This Exists
|
## Why This Exists
|
||||||
|
|
||||||
|
|
@ -17,7 +17,7 @@ Human-in-the-loop turns are necessary and expensive.
|
||||||
|
|
||||||
Current LLMs still fail in predictable ways: they misread intent, fill gaps with confident guesses, drift into unrelated work, and generate noisy review output. At the same time, constant human intervention limits development velocity. Human attention is the bottleneck.
|
Current LLMs still fail in predictable ways: they misread intent, fill gaps with confident guesses, drift into unrelated work, and generate noisy review output. At the same time, constant human intervention limits development velocity. Human attention is the bottleneck.
|
||||||
|
|
||||||
This experimental version of Quick Flow is an attempt to rebalance that tradeoff. It trusts the model to run unsupervised for longer stretches, but only after the workflow has created a strong enough boundary to make that safe.
|
`bmad-quick-dev` rebalances that tradeoff. It trusts the model to run unsupervised for longer stretches, but only after the workflow has created a strong enough boundary to make that safe.
|
||||||
|
|
||||||
## The Core Design
|
## The Core Design
|
||||||
|
|
||||||
|
|
@ -39,7 +39,7 @@ Once the goal is clear, the workflow decides whether this is a true one-shot cha
|
||||||
|
|
||||||
### 3. Run longer with less supervision
|
### 3. Run longer with less supervision
|
||||||
|
|
||||||
After that routing decision, the model can carry more of the work on its own. On the fuller path, the approved spec becomes the boundary the model executes against with less supervision, which is the whole point of the experiment.
|
After that routing decision, the model can carry more of the work on its own. On the fuller path, the approved spec becomes the boundary the model executes against with less supervision, which is the whole point of the design.
|
||||||
|
|
||||||
### 4. Diagnose failure at the right layer
|
### 4. Diagnose failure at the right layer
|
||||||
|
|
||||||
|
|
@ -53,7 +53,7 @@ The intent interview is human-in-the-loop, but it is not the same kind of interr
|
||||||
|
|
||||||
- **Intent-gap resolution** - stepping back in when review proves the workflow could not safely infer what was meant
|
- **Intent-gap resolution** - stepping back in when review proves the workflow could not safely infer what was meant
|
||||||
|
|
||||||
Everything else is a candidate for longer autonomous execution. That tradeoff is deliberate. Older patterns spend more human attention on continuous supervision. Quick Dev New Preview spends more trust on the model, but saves human attention for the moments where human reasoning has the highest leverage.
|
Everything else is a candidate for longer autonomous execution. That tradeoff is deliberate. Older patterns spend more human attention on continuous supervision. Quick Dev spends more trust on the model, but saves human attention for the moments where human reasoning has the highest leverage.
|
||||||
|
|
||||||
## Why the Review System Matters
|
## Why the Review System Matters
|
||||||
|
|
||||||
|
|
@ -66,7 +66,7 @@ Agentic reviews often go wrong in two ways:
|
||||||
- They generate too many findings, forcing the human to sift through noise.
|
- They generate too many findings, forcing the human to sift through noise.
|
||||||
- They derail the current change by surfacing unrelated issues and turning every run into an ad hoc cleanup project.
|
- They derail the current change by surfacing unrelated issues and turning every run into an ad hoc cleanup project.
|
||||||
|
|
||||||
Quick Dev New Preview addresses both by treating review as triage.
|
Quick Dev addresses both by treating review as triage.
|
||||||
|
|
||||||
Some findings belong to the current change. Some do not. If a finding is incidental rather than causally tied to the current work, the workflow can defer it instead of forcing the human to handle it immediately. That keeps the run focused and prevents random tangents from consuming the budget of attention.
|
Some findings belong to the current change. Some do not. If a finding is incidental rather than causally tied to the current work, the workflow can defer it instead of forcing the human to handle it immediately. That keeps the run focused and prevents random tangents from consuming the budget of attention.
|
||||||
|
|
||||||
|
|
@ -1,77 +0,0 @@
|
||||||
---
|
|
||||||
title: "Quick Flow"
|
|
||||||
description: Fast-track for small changes - skip the full methodology
|
|
||||||
sidebar:
|
|
||||||
order: 1
|
|
||||||
---
|
|
||||||
|
|
||||||
Skip the ceremony. Quick Flow takes you from idea to working code in two skills - no Product Brief, no PRD, no Architecture doc.
|
|
||||||
|
|
||||||
:::tip[Want a Unified Variant?]
|
|
||||||
If you want one workflow to clarify, plan, implement, review, and present in a single run, see [Quick Dev New Preview](./quick-dev-new-preview.md).
|
|
||||||
:::
|
|
||||||
|
|
||||||
## When to Use It
|
|
||||||
|
|
||||||
- Bug fixes and patches
|
|
||||||
- Refactoring existing code
|
|
||||||
- Small, well-understood features
|
|
||||||
- Prototyping and spikes
|
|
||||||
- Single-agent work where one developer can hold the full scope
|
|
||||||
|
|
||||||
## When NOT to Use It
|
|
||||||
|
|
||||||
- New products or platforms that need stakeholder alignment
|
|
||||||
- Major features spanning multiple components or teams
|
|
||||||
- Work that requires architectural decisions (database schema, API contracts, service boundaries)
|
|
||||||
- Anything where requirements are unclear or contested
|
|
||||||
|
|
||||||
:::caution[Scope Creep]
|
|
||||||
If you start a Quick Flow and realize the scope is bigger than expected, `bmad-quick-dev` will detect this and offer to escalate. You can switch to a full PRD workflow at any point without losing your work.
|
|
||||||
:::
|
|
||||||
|
|
||||||
## How It Works
|
|
||||||
|
|
||||||
Quick Flow has two skills, each backed by a structured workflow. You can run them together or independently.
|
|
||||||
|
|
||||||
### quick-spec: Plan
|
|
||||||
|
|
||||||
Run `bmad-quick-spec` and Barry (the Quick Flow agent) walks you through a conversational discovery process:
|
|
||||||
|
|
||||||
1. **Understand** - You describe what you want to build. Barry scans the codebase to ask informed questions, then captures a problem statement, solution approach, and scope boundaries.
|
|
||||||
2. **Investigate** - Barry reads relevant files, maps code patterns, identifies files to modify, and documents the technical context.
|
|
||||||
3. **Generate** - Produces a complete tech-spec with ordered implementation tasks (specific file paths and actions), acceptance criteria in Given/When/Then format, testing strategy, and dependencies.
|
|
||||||
4. **Review** - Presents the full spec for your sign-off. You can edit, ask questions, run adversarial review, or refine with advanced elicitation before finalizing.
|
|
||||||
|
|
||||||
The output is a `tech-spec-{slug}.md` file saved to your project's implementation artifacts folder. It contains everything a fresh agent needs to implement the feature - no conversation history required.
|
|
||||||
|
|
||||||
### quick-dev: Build
|
|
||||||
|
|
||||||
Run `bmad-quick-dev` and Barry implements the work. It operates in two modes:
|
|
||||||
|
|
||||||
- **Tech-spec mode** - Point it at a spec file (`quick-dev tech-spec-auth.md`) and it executes every task in order, writes tests, and verifies acceptance criteria.
|
|
||||||
- **Direct mode** - Give it instructions directly (`quick-dev "refactor the auth middleware"`) and it gathers context, builds a mental plan, and executes.
|
|
||||||
|
|
||||||
After implementation, `bmad-quick-dev` runs a self-check audit against all tasks and acceptance criteria, then triggers an adversarial code review of the diff. Findings are presented for you to resolve before wrapping up.
|
|
||||||
|
|
||||||
:::tip[Fresh Context]
|
|
||||||
For best results, run `bmad-quick-dev` in a new conversation after finishing `bmad-quick-spec`. This gives the implementation agent clean context focused solely on building.
|
|
||||||
:::
|
|
||||||
|
|
||||||
## What Quick Flow Skips
|
|
||||||
|
|
||||||
The full BMad Method produces a Product Brief, PRD, Architecture doc, and Epic/Story breakdown before any code is written. Quick Flow replaces all of that with a single tech-spec. This works because Quick Flow targets changes where:
|
|
||||||
|
|
||||||
- The product direction is already established
|
|
||||||
- Architecture decisions are already made
|
|
||||||
- A single developer can reason about the full scope
|
|
||||||
- Requirements fit in one conversation
|
|
||||||
|
|
||||||
## Escalating to Full BMad Method
|
|
||||||
|
|
||||||
Quick Flow includes built-in guardrails for scope detection. When you run `bmad-quick-dev` with a direct request, it evaluates signals like multi-component mentions, system-level language, and uncertainty about approach. If it detects the work is bigger than a quick flow:
|
|
||||||
|
|
||||||
- **Light escalation** - Recommends running `bmad-quick-spec` first to create a plan
|
|
||||||
- **Heavy escalation** - Recommends switching to the full BMad Method PRD process
|
|
||||||
|
|
||||||
You can also escalate manually at any time. Your tech-spec work carries forward - it becomes input for the broader planning process rather than being discarded.
|
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
---
|
||||||
|
title: Page introuvable
|
||||||
|
template: splash
|
||||||
|
---
|
||||||
|
|
||||||
|
La page que vous recherchez n'existe pas ou a été déplacée.
|
||||||
|
|
||||||
|
[Retour à l'accueil](/fr/index.md)
|
||||||
|
|
@ -0,0 +1,370 @@
|
||||||
|
---
|
||||||
|
title: "Guide de style de la documentation"
|
||||||
|
description: Conventions de documentation spécifiques au projet, basées sur le style Google et la structure Diataxis
|
||||||
|
---
|
||||||
|
|
||||||
|
Ce projet suit le [Guide de style de documentation pour développeurs Google](https://developers.google.com/style) et utilise [Diataxis](https://diataxis.fr/) pour structurer le contenu. Seules les conventions spécifiques au projet sont présentées ci-dessous.
|
||||||
|
|
||||||
|
## Règles spécifiques au projet
|
||||||
|
|
||||||
|
| Règle | Spécification |
|
||||||
|
| --------------------------------------- | ------------------------------------------------------ |
|
||||||
|
| Pas de règles horizontales (`---`) | Perturbe le flux de lecture des fragments |
|
||||||
|
| Pas de titres `####` | Utiliser du texte en gras ou des admonitions |
|
||||||
|
| Pas de sections « Related » ou « Next: » | La barre latérale gère la navigation |
|
||||||
|
| Pas de listes profondément imbriquées | Diviser en sections à la place |
|
||||||
|
| Pas de blocs de code pour non-code | Utiliser des admonitions pour les exemples de dialogue |
|
||||||
|
| Pas de paragraphes en gras pour les appels | Utiliser des admonitions à la place |
|
||||||
|
| 1-2 admonitions max par section | Les tutoriels permettent 3-4 par section majeure |
|
||||||
|
| Cellules de tableau / éléments de liste | 1-2 phrases maximum |
|
||||||
|
| Budget de titres | 8-12 `##` par doc ; 2-3 `###` par section |
|
||||||
|
|
||||||
|
## Admonitions (Syntaxe Starlight)
|
||||||
|
|
||||||
|
```md
|
||||||
|
:::tip[Titre]
|
||||||
|
Raccourcis, bonnes pratiques
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::note[Titre]
|
||||||
|
Contexte, définitions, exemples, prérequis
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::caution[Titre]
|
||||||
|
Mises en garde, problèmes potentiels
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::danger[Titre]
|
||||||
|
Avertissements critiques uniquement — perte de données, problèmes de sécurité
|
||||||
|
:::
|
||||||
|
```
|
||||||
|
|
||||||
|
### Utilisations standards
|
||||||
|
|
||||||
|
| Admonition | Usage |
|
||||||
|
| -------------------------- | ---------------------------------------- |
|
||||||
|
| `:::note[Pré-requis]` | Dépendances avant de commencer |
|
||||||
|
| `:::tip[Chemin rapide]` | Résumé TL;DR en haut du document |
|
||||||
|
| `:::caution[Important]` | Mises en garde critiques |
|
||||||
|
| `:::note[Exemple]` | Exemples de commandes/réponses |
|
||||||
|
|
||||||
|
## Formats de tableau standards
|
||||||
|
|
||||||
|
**Phases :**
|
||||||
|
|
||||||
|
```md
|
||||||
|
| Phase | Nom | Ce qui se passe |
|
||||||
|
| ----- | ---------- | --------------------------------------------------- |
|
||||||
|
| 1 | Analyse | Brainstorm, recherche *(optionnel)* |
|
||||||
|
| 2 | Planification | Exigences — PRD ou spécification technique *(requis)* |
|
||||||
|
```
|
||||||
|
|
||||||
|
**Skills :**
|
||||||
|
|
||||||
|
```md
|
||||||
|
| Skill | Agent | Objectif |
|
||||||
|
| ------------------- | ------- | ----------------------------------------------- |
|
||||||
|
| `bmad-brainstorming` | Analyste | Brainstorming pour un nouveau projet |
|
||||||
|
| `bmad-create-prd` | PM | Créer un document d'exigences produit |
|
||||||
|
```
|
||||||
|
|
||||||
|
## Blocs de structure de dossiers
|
||||||
|
|
||||||
|
À afficher dans les sections "Ce que vous avez accompli" :
|
||||||
|
|
||||||
|
````md
|
||||||
|
```
|
||||||
|
votre-projet/
|
||||||
|
├── _bmad/ # Configuration BMad
|
||||||
|
├── _bmad-output/
|
||||||
|
│ ├── planning-artifacts/
|
||||||
|
│ │ └── PRD.md # Votre document d'exigences
|
||||||
|
│ ├── implementation-artifacts/
|
||||||
|
│ └── project-context.md # Règles d'implémentation (optionnel)
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
````
|
||||||
|
|
||||||
|
## Structure des tutoriels
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (1-2 phrases décrivant le résultat)
|
||||||
|
2. Notice de version/module (admonition info ou avertissement) (optionnel)
|
||||||
|
3. Ce que vous allez apprendre (liste à puces des résultats)
|
||||||
|
4. Prérequis (admonition info)
|
||||||
|
5. Chemin rapide (admonition tip - résumé TL;DR)
|
||||||
|
6. Comprendre [Sujet] (contexte avant les étapes - tableaux pour phases/agents)
|
||||||
|
7. Installation (optionnel)
|
||||||
|
8. Étape 1 : [Première tâche majeure]
|
||||||
|
9. Étape 2 : [Deuxième tâche majeure]
|
||||||
|
10. Étape 3 : [Troisième tâche majeure]
|
||||||
|
11. Ce que vous avez accompli (résumé + structure de dossiers)
|
||||||
|
12. Référence rapide (tableau des compétences)
|
||||||
|
13. Questions courantes (format FAQ)
|
||||||
|
14. Obtenir de l'aide (liens communautaires)
|
||||||
|
15. Points clés à retenir (admonition tip)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Liste de vérification des tutoriels
|
||||||
|
|
||||||
|
- [ ] L'accroche décrit le résultat en 1-2 phrases
|
||||||
|
- [ ] Section "Ce que vous allez apprendre" présente
|
||||||
|
- [ ] Prérequis dans une admonition
|
||||||
|
- [ ] Admonition TL;DR de chemin rapide en haut
|
||||||
|
- [ ] Tableaux pour phases, skills, agents
|
||||||
|
- [ ] Section "Ce que vous avez accompli" présente
|
||||||
|
- [ ] Tableau de référence rapide présent
|
||||||
|
- [ ] Section questions courantes présente
|
||||||
|
- [ ] Section obtenir de l'aide présente
|
||||||
|
- [ ] Admonition points clés à retenir à la fin
|
||||||
|
|
||||||
|
## Structure des guides pratiques (How-To)
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (une phrase : « Utilisez le workflow `X` pour... »)
|
||||||
|
2. Quand utiliser ce guide (liste à puces de scénarios)
|
||||||
|
3. Quand éviter ce guide (optionnel)
|
||||||
|
4. Prérequis (admonition note)
|
||||||
|
5. Étapes (sous-sections ### numérotées)
|
||||||
|
6. Ce que vous obtenez (produits de sortie/artefacts)
|
||||||
|
7. Exemple (optionnel)
|
||||||
|
8. Conseils (optionnel)
|
||||||
|
9. Prochaines étapes (optionnel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Liste de vérification des guides pratiques
|
||||||
|
|
||||||
|
- [ ] L'accroche commence par « Utilisez le workflow `X` pour... »
|
||||||
|
- [ ] "Quand utiliser ce guide" contient 3-5 points
|
||||||
|
- [ ] Prérequis listés
|
||||||
|
- [ ] Les étapes sont des sous-sections `###` numérotées avec des verbes d'action
|
||||||
|
- [ ] "Ce que vous obtenez" décrit les artefacts produits
|
||||||
|
|
||||||
|
## Structure des explications
|
||||||
|
|
||||||
|
### Types
|
||||||
|
|
||||||
|
| Type | Exemple |
|
||||||
|
| ----------------------- | ------------------------------------ |
|
||||||
|
| **Index/Page d'accueil** | `core-concepts/index.md` |
|
||||||
|
| **Concept** | `what-are-agents.md` |
|
||||||
|
| **Fonctionnalité** | `quick-dev.md` |
|
||||||
|
| **Philosophie** | `why-solutioning-matters.md` |
|
||||||
|
| **FAQ** | `established-projects-faq.md` |
|
||||||
|
|
||||||
|
### Modèle général
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (1-2 phrases)
|
||||||
|
2. Vue d'ensemble/Définition (ce que c'est, pourquoi c'est important)
|
||||||
|
3. Concepts clés (sous-sections ###)
|
||||||
|
4. Tableau comparatif (optionnel)
|
||||||
|
5. Quand utiliser / Quand ne pas utiliser (optionnel)
|
||||||
|
6. Diagramme (optionnel - mermaid, 1 max par doc)
|
||||||
|
7. Prochaines étapes (optionnel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Pages d'index/d'accueil
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (une phrase)
|
||||||
|
2. Tableau de contenu (liens avec descriptions)
|
||||||
|
3. Pour commencer (liste numérotée)
|
||||||
|
4. Choisissez votre parcours (optionnel - arbre de décision)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Explications de concepts
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (ce que c'est)
|
||||||
|
2. Types/Catégories (sous-sections ###) (optionnel)
|
||||||
|
3. Tableau des différences clés
|
||||||
|
4. Composants/Parties
|
||||||
|
5. Lequel devriez-vous utiliser ?
|
||||||
|
6. Création/Personnalisation (lien vers les guides pratiques)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Explications de fonctionnalités
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (ce que cela fait)
|
||||||
|
2. Faits rapides (optionnel - "Idéal pour :", "Temps :")
|
||||||
|
3. Quand utiliser / Quand ne pas utiliser
|
||||||
|
4. Comment cela fonctionne (diagramme mermaid optionnel)
|
||||||
|
5. Avantages clés
|
||||||
|
6. Tableau comparatif (optionnel)
|
||||||
|
7. Quand évoluer/mettre à niveau (optionnel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Documents de philosophie/justification
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (le principe)
|
||||||
|
2. Le problème
|
||||||
|
3. La solution
|
||||||
|
4. Principes clés (sous-sections ###)
|
||||||
|
5. Avantages
|
||||||
|
6. Quand cela s'applique
|
||||||
|
```
|
||||||
|
|
||||||
|
### Liste de vérification des explications
|
||||||
|
|
||||||
|
- [ ] L'accroche énonce ce que le document explique
|
||||||
|
- [ ] Contenu dans des sections `##` parcourables
|
||||||
|
- [ ] Tableaux comparatifs pour 3+ options
|
||||||
|
- [ ] Les diagrammes ont des étiquettes claires
|
||||||
|
- [ ] Liens vers les guides pratiques pour les questions procédurales
|
||||||
|
- [ ] 2-3 admonitions max par document
|
||||||
|
|
||||||
|
## Structure des références
|
||||||
|
|
||||||
|
### Types
|
||||||
|
|
||||||
|
| Type | Exemple |
|
||||||
|
| ----------------------- | --------------------- |
|
||||||
|
| **Index/Page d'accueil** | `workflows/index.md` |
|
||||||
|
| **Catalogue** | `agents/index.md` |
|
||||||
|
| **Approfondissement** | `document-project.md` |
|
||||||
|
| **Configuration** | `core-tasks.md` |
|
||||||
|
| **Glossaire** | `glossary/index.md` |
|
||||||
|
| **Complet** | `bmgd-workflows.md` |
|
||||||
|
|
||||||
|
### Pages d'index de référence
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (une phrase)
|
||||||
|
2. Sections de contenu (## pour chaque catégorie)
|
||||||
|
- Liste à puces avec liens et descriptions
|
||||||
|
```
|
||||||
|
|
||||||
|
### Référence de catalogue
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche
|
||||||
|
2. Éléments (## pour chaque élément)
|
||||||
|
- Brève description (une phrase)
|
||||||
|
- **Skills :** ou **Infos clés :** sous forme de liste simple
|
||||||
|
3. Universel/Partagé (## section) (optionnel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Référence d'approfondissement d'élément
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche (objectif en une phrase)
|
||||||
|
2. Faits rapides (admonition note optionnelle)
|
||||||
|
- Module, Skill, Entrée, Sortie sous forme de liste
|
||||||
|
3. Objectif/Vue d'ensemble (## section)
|
||||||
|
4. Comment invoquer (bloc de code)
|
||||||
|
5. Sections clés (## pour chaque aspect)
|
||||||
|
- Utiliser ### pour les sous-options
|
||||||
|
6. Notes/Mises en garde (admonition tip ou caution)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Référence de configuration
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche
|
||||||
|
2. Table des matières (liens de saut si 4+ éléments)
|
||||||
|
3. Éléments (## pour chaque config/tâche)
|
||||||
|
- **Résumé en gras** — une phrase
|
||||||
|
- **Utilisez-le quand :** liste à puces
|
||||||
|
- **Comment cela fonctionne :** étapes numérotées (3-5 max)
|
||||||
|
- **Sortie :** résultat attendu (optionnel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Guide de référence complet
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Titre + Accroche
|
||||||
|
2. Vue d'ensemble (## section)
|
||||||
|
- Diagramme ou tableau montrant l'organisation
|
||||||
|
3. Sections majeures (## pour chaque phase/catégorie)
|
||||||
|
- Éléments (### pour chaque élément)
|
||||||
|
- Champs standardisés : Skill, Agent, Entrée, Sortie, Description
|
||||||
|
4. Prochaines étapes (optionnel)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Liste de vérification des références
|
||||||
|
|
||||||
|
- [ ] L'accroche énonce ce que le document référence
|
||||||
|
- [ ] La structure correspond au type de référence
|
||||||
|
- [ ] Les éléments utilisent une structure cohérente
|
||||||
|
- [ ] Tableaux pour les données structurées/comparatives
|
||||||
|
- [ ] Liens vers les documents d'explication pour la profondeur conceptuelle
|
||||||
|
- [ ] 1-2 admonitions max
|
||||||
|
|
||||||
|
## Structure du glossaire
|
||||||
|
|
||||||
|
Starlight génère la navigation "Sur cette page" à droite à partir des titres :
|
||||||
|
|
||||||
|
- Catégories en tant que titres `##` — apparaissent dans la navigation à droite
|
||||||
|
- Termes dans des tableaux — lignes compactes, pas de titres individuels
|
||||||
|
- Pas de TOC en ligne — la barre latérale à droite gère la navigation
|
||||||
|
|
||||||
|
### Format de tableau
|
||||||
|
|
||||||
|
```md
|
||||||
|
## Nom de catégorie
|
||||||
|
|
||||||
|
| Terme | Définition |
|
||||||
|
| ------------ | --------------------------------------------------------------------------------------------- |
|
||||||
|
| **Agent** | Personnalité IA spécialisée avec une expertise spécifique qui guide les utilisateurs dans les workflows. |
|
||||||
|
| **Workflow** | Processus guidé en plusieurs étapes qui orchestre les activités des agents IA pour produire des livrables. |
|
||||||
|
```
|
||||||
|
|
||||||
|
### Règles de définition
|
||||||
|
|
||||||
|
| À faire | À ne pas faire |
|
||||||
|
| --------------------------------- | --------------------------------------------- |
|
||||||
|
| Commencer par ce que c'est ou ce que cela fait | Commencer par « C'est... » ou « Un [terme] est... » |
|
||||||
|
| Se limiter à 1-2 phrases | Écrire des explications de plusieurs paragraphes |
|
||||||
|
| Mettre le nom du terme en gras dans la cellule | Utiliser du texte simple pour les termes |
|
||||||
|
|
||||||
|
### Marqueurs de contexte
|
||||||
|
|
||||||
|
Ajouter un contexte en italique au début de la définition pour les termes à portée limitée :
|
||||||
|
|
||||||
|
- `*Quick Dev uniquement.*`
|
||||||
|
- `*méthode BMad/Enterprise.*`
|
||||||
|
- `*Phase N.*`
|
||||||
|
- `*BMGD.*`
|
||||||
|
- `*Projets établis.*`
|
||||||
|
|
||||||
|
### Liste de vérification du glossaire
|
||||||
|
|
||||||
|
- [ ] Termes dans des tableaux, pas de titres individuels
|
||||||
|
- [ ] Termes alphabétisés au sein des catégories
|
||||||
|
- [ ] Définitions de 1-2 phrases
|
||||||
|
- [ ] Marqueurs de contexte en italique
|
||||||
|
- [ ] Noms des termes en gras dans les cellules
|
||||||
|
- [ ] Pas de définitions « Un [terme] est... »
|
||||||
|
|
||||||
|
## Sections FAQ
|
||||||
|
|
||||||
|
```md
|
||||||
|
## Questions
|
||||||
|
|
||||||
|
- [Ai-je toujours besoin d'architecture ?](#ai-je-toujours-besoin-darchitecture)
|
||||||
|
- [Puis-je modifier mon plan plus tard ?](#puis-je-modifier-mon-plan-plus-tard)
|
||||||
|
|
||||||
|
### Ai-je toujours besoin d'architecture ?
|
||||||
|
|
||||||
|
Uniquement pour les parcours méthode BMad et Enterprise. Quick Dev passe directement à l'implémentation.
|
||||||
|
|
||||||
|
### Puis-je modifier mon plan plus tard ?
|
||||||
|
|
||||||
|
Oui. Utilisez `bmad-correct-course` pour gérer les changements de portée.
|
||||||
|
|
||||||
|
**Une question sans réponse ici ?** [Ouvrez une issue](...) ou posez votre question sur [Discord](...).
|
||||||
|
```
|
||||||
|
|
||||||
|
## Commandes de validation
|
||||||
|
|
||||||
|
Avant de soumettre des modifications de documentation :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npm run docs:fix-links # Prévisualiser les corrections de format de liens
|
||||||
|
npm run docs:fix-links -- --write # Appliquer les corrections
|
||||||
|
npm run docs:validate-links # Vérifier que les liens existent
|
||||||
|
npm run docs:build # Vérifier l'absence d'erreurs de build
|
||||||
|
```
|
||||||
|
|
@ -0,0 +1,49 @@
|
||||||
|
---
|
||||||
|
title: "Élicitation Avancée"
|
||||||
|
description: Pousser le LLM à repenser son travail en utilisant des méthodes de raisonnement structurées
|
||||||
|
sidebar:
|
||||||
|
order: 6
|
||||||
|
---
|
||||||
|
|
||||||
|
Faites repenser au LLM ce qu'il vient de générer. Vous choisissez une méthode de raisonnement, il l'applique à sa propre sortie, et vous décidez de conserver ou non les améliorations.
|
||||||
|
|
||||||
|
## Qu'est-ce que l’Élicitation Avancée ?
|
||||||
|
|
||||||
|
Un second passage structuré. Au lieu de demander à l'IA de "réessayer" ou de "faire mieux", vous sélectionnez une méthode de raisonnement spécifique et l'IA réexamine sa propre sortie à travers ce prisme.
|
||||||
|
|
||||||
|
La différence est importante. Les demandes vagues produisent des révisions vagues. Une méthode nommée impose un angle d'attaque particulier, mettant en lumière des perspectives qu'un simple réajustement générique aurait manquées.
|
||||||
|
|
||||||
|
## Quand l'utiliser
|
||||||
|
|
||||||
|
- Après qu'un workflow a généré du contenu et vous souhaitez des alternatives
|
||||||
|
- Lorsque la sortie semble correcte mais que vous soupçonnez qu'il y a davantage de profondeur
|
||||||
|
- Pour tester les hypothèses ou trouver des faiblesses
|
||||||
|
- Pour du contenu à enjeux élevés où la réflexion approfondie aide
|
||||||
|
|
||||||
|
Les workflows offrent l'élicitation aux points de décision - après que le LLM ait généré quelque chose, on vous demandera si vous souhaitez l'exécuter.
|
||||||
|
|
||||||
|
## Comment ça fonctionne
|
||||||
|
|
||||||
|
1. Le LLM suggère 5 méthodes pertinentes pour votre contenu
|
||||||
|
2. Vous en choisissez une (ou remélangez pour différentes options)
|
||||||
|
3. La méthode est appliquée, les améliorations sont affichées
|
||||||
|
4. Acceptez ou rejetez, répétez ou continuez
|
||||||
|
|
||||||
|
## Méthodes intégrées
|
||||||
|
|
||||||
|
Des dizaines de méthodes de raisonnement sont disponibles. Quelques exemples :
|
||||||
|
|
||||||
|
- **Analyse Pré-mortem** - Suppose que le projet a déjà échoué, revient en arrière pour trouver pourquoi
|
||||||
|
- **Pensée de Premier Principe** - Élimine les hypothèses, reconstruit à partir de la vérité de terrain
|
||||||
|
- **Inversion** - Demande comment garantir l'échec, puis les évite
|
||||||
|
- **Équipe Rouge vs Équipe Bleue** - Attaque votre propre travail, puis le défend
|
||||||
|
- **Questionnement Socratique** - Conteste chaque affirmation avec "pourquoi ?" et "comment le savez-vous ?"
|
||||||
|
- **Suppression des Contraintes** - Abandonne toutes les contraintes, voit ce qui change, les réajoute sélectivement
|
||||||
|
- **Cartographie des Parties Prenantes** - Réévalue depuis la perspective de chaque partie prenante
|
||||||
|
- **Raisonnement Analogique** - Trouve des parallèles dans d'autres domaines et applique leurs leçons
|
||||||
|
|
||||||
|
Et bien d'autres. L'IA choisit les options les plus pertinentes pour votre contenu - vous choisissez lesquelles exécuter.
|
||||||
|
|
||||||
|
:::tip[Commencez Ici]
|
||||||
|
L'Analyse Pré-mortem est un bon premier choix pour toute spécification ou tout plan. Elle trouve systématiquement des lacunes qu'une révision standard manque.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,66 @@
|
||||||
|
---
|
||||||
|
title: "Revue Contradictoire"
|
||||||
|
description: Technique de raisonnement forcée qui empêche les revues paresseuses du style "ça à l'air bon"
|
||||||
|
sidebar:
|
||||||
|
order: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
Forcez une analyse plus approfondie en exigeant que des problèmes soient trouvés.
|
||||||
|
|
||||||
|
## Qu'est-ce que la Revue Contradictoire ?
|
||||||
|
|
||||||
|
Une technique de revue où le réviseur *doit* trouver des problèmes. Pas de "ça a l'air bon" autorisé. Le réviseur adopte une posture cynique - suppose que des problèmes existent et les trouve.
|
||||||
|
|
||||||
|
Il ne s'agit pas d'être négatif. Il s'agit de forcer une analyse authentique au lieu d'un coup d'œil superficiel qui valide automatiquement ce qui a été soumis.
|
||||||
|
|
||||||
|
**La règle fondamentale :** Il doit trouver des problèmes. Zéro constatation déclenche un arrêt - réanalyse ou explique pourquoi.
|
||||||
|
|
||||||
|
## Pourquoi Cela Fonctionne
|
||||||
|
|
||||||
|
Les revues normales souffrent du biais de confirmation[^1]. Il parcourt le travail rapidement, rien ne lui saute aux yeux, il l'approuve. L'obligation de "trouver des problèmes" brise ce schéma :
|
||||||
|
|
||||||
|
- **Force la rigueur** - Impossible d'approuver tant qu’il n'a pas examiné suffisamment en profondeur pour trouver des problèmes
|
||||||
|
- **Détecte les oublis** - "Qu'est-ce qui manque ici ?" devient une question naturelle
|
||||||
|
- **Améliore la qualité du signal** - Les constatations sont spécifiques et actionnables, pas des préoccupations vagues
|
||||||
|
- **Asymétrie d'information**[^2] - Effectue les revues avec un contexte frais (sans accès au raisonnement original) pour évaluer l'artefact, pas l'intention
|
||||||
|
|
||||||
|
## Où Elle Est Utilisée
|
||||||
|
|
||||||
|
La revue contradictoire apparaît dans tous les workflows BMad - revue de code, vérifications de préparation à l'implémentation, validation de spécifications, et d'autres. Parfois c'est une étape obligatoire, parfois optionnelle (comme l'élicitation avancée ou le mode party). Le pattern s'adapte à n'importe quel artefact nécessitant un examen.
|
||||||
|
|
||||||
|
## Filtrage Humain Requis
|
||||||
|
|
||||||
|
Parce que l'IA est *instruite* de trouver des problèmes, elle trouvera des problèmes - même lorsqu'ils n'existent pas. Attendez-vous à des faux positifs : des détails présentés comme des problèmes, des malentendus sur l'intention, ou des préoccupations purement hallucinées[^3].
|
||||||
|
|
||||||
|
**C'est vous qui décidez ce qui est réel.** Examinez chaque constatation, ignorez le bruit, corrigez ce qui compte.
|
||||||
|
|
||||||
|
## Exemple
|
||||||
|
|
||||||
|
Au lieu de :
|
||||||
|
|
||||||
|
> "L'implémentation de l'authentification semble raisonnable. Approuvé."
|
||||||
|
|
||||||
|
Une revue contradictoire produit :
|
||||||
|
|
||||||
|
> 1. **ÉLEVÉ** - `login.ts:47` - Pas de limitation de débit sur les tentatives échouées
|
||||||
|
> 2. **ÉLEVÉ** - Jeton de session stocké dans localStorage (vulnérable au XSS)
|
||||||
|
> 3. **MOYEN** - La validation du mot de passe se fait côté client uniquement
|
||||||
|
> 4. **MOYEN** - Pas de journalisation d'audit pour les tentatives de connexion échouées
|
||||||
|
> 5. **FAIBLE** - Le nombre magique `3600` devrait être `SESSION_TIMEOUT_SECONDS`
|
||||||
|
|
||||||
|
La première revue pourrait manquer une vulnérabilité de sécurité. La seconde en a attrapé quatre.
|
||||||
|
|
||||||
|
## Itération et Rendements Décroissants
|
||||||
|
|
||||||
|
Après avoir traité les constatations, envisagez de relancer la revue. Une deuxième passe détecte généralement plus de problèmes. Une troisième n'est pas toujours inutile non plus. Mais chaque passe prend du temps, et vous finissez par atteindre des rendements décroissants[^4] - juste des détails et des faux problèmes.
|
||||||
|
|
||||||
|
:::tip[Meilleures Revues]
|
||||||
|
Supposez que des problèmes existent. Cherchez ce qui manque, pas seulement ce qui ne va pas.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: **Biais de confirmation** : tendance cognitive à rechercher, interpréter et favoriser les informations qui confirment nos croyances préexistantes, tout en ignorant ou minimisant celles qui les contredisent.
|
||||||
|
[^2]: **Asymétrie d'information** : situation où une partie dispose de plus ou de meilleures informations qu'une autre, conduisant potentiellement à des décisions ou jugements biaisés.
|
||||||
|
[^3]: **Hallucination (IA)** : phénomène où un modèle d'IA génère des informations plausibles mais factuellement incorrectes ou inventées, présentées avec confiance comme si elles étaient vraies.
|
||||||
|
[^4]: **Rendements décroissants** : principe selon lequel l'augmentation continue d'un investissement (temps, effort, ressources) finit par produire des bénéfices de plus en plus faibles proportionnellement.
|
||||||
|
|
@ -0,0 +1,33 @@
|
||||||
|
---
|
||||||
|
title: "Brainstorming"
|
||||||
|
description: Sessions interactives créatives utilisant plus de 60 techniques d'idéation éprouvées
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Libérez votre créativité grâce à une exploration guidée.
|
||||||
|
|
||||||
|
## Qu'est-ce que le Brainstorming ?
|
||||||
|
|
||||||
|
Lancez `bmad-brainstorming` et vous obtenez un facilitateur créatif qui fait émerger vos idées - pas qui les génère pour vous. L'IA agit comme coach et guide, utilisant des techniques éprouvées pour créer les conditions où votre meilleure réflexion émerge.
|
||||||
|
|
||||||
|
**Idéal pour :**
|
||||||
|
|
||||||
|
- Surmonter les blocages créatifs
|
||||||
|
- Générer des idées de produits ou de fonctionnalités
|
||||||
|
- Explorer des problèmes sous de nouveaux angles
|
||||||
|
- Développer des concepts bruts en plans d'action
|
||||||
|
|
||||||
|
## Comment ça fonctionne
|
||||||
|
|
||||||
|
1. **Configuration** - Définir le sujet, les objectifs, les contraintes
|
||||||
|
2. **Choisir l'approche** - Choisir vous-même les techniques, obtenir des recommandations de l'IA, aller au hasard, ou suivre un flux progressif
|
||||||
|
3. **Facilitation** - Travailler à travers les techniques avec des questions approfondies et un coaching collaboratif
|
||||||
|
4. **Organiser** - Idées regroupées par thèmes et priorisées
|
||||||
|
5. **Action** - Les meilleures idées reçoivent des prochaines étapes et des indicateurs de succès
|
||||||
|
|
||||||
|
Tout est capturé dans un document de session que vous pouvez consulter ultérieurement ou partager avec les parties prenantes.
|
||||||
|
|
||||||
|
:::note[Vos Idées]
|
||||||
|
Chaque idée vient de vous. Le workflow crée les conditions propices à une vision nouvelle - vous en êtes la source.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,50 @@
|
||||||
|
---
|
||||||
|
title: "FAQ Projets Existants"
|
||||||
|
description: Questions courantes sur l'utilisation de la méthode BMad sur des projets existants
|
||||||
|
sidebar:
|
||||||
|
order: 8
|
||||||
|
---
|
||||||
|
Réponses rapides aux questions courantes sur l'utilisation de la méthode BMad (BMM) sur des projets existants.
|
||||||
|
|
||||||
|
## Questions
|
||||||
|
|
||||||
|
- [Dois-je d'abord exécuter document-project ?](#dois-je-dabord-exécuter-document-project)
|
||||||
|
- [Que faire si j'oublie d'exécuter document-project ?](#que-faire-si-joublie-dexécuter-document-project)
|
||||||
|
- [Puis-je utiliser Quick Dev pour les projets existants ?](#puis-je-utiliser-quick-dev-pour-les-projets-existants)
|
||||||
|
- [Que faire si mon code existant ne suit pas les bonnes pratiques ?](#que-faire-si-mon-code-existant-ne-suit-pas-les-bonnes-pratiques)
|
||||||
|
|
||||||
|
### Dois-je d'abord exécuter `document-project` ?
|
||||||
|
|
||||||
|
Hautement recommandé, surtout si :
|
||||||
|
|
||||||
|
- Aucune documentation existante
|
||||||
|
- La documentation est obsolète
|
||||||
|
- Les agents IA ont besoin de contexte sur le code existant
|
||||||
|
|
||||||
|
Vous pouvez l'ignorer si vous disposez d'une documentation complète et à jour incluant `docs/index.md` ou si vous utiliserez d'autres outils ou techniques pour aider à la découverte afin que l'agent puisse construire sur un système existant.
|
||||||
|
|
||||||
|
### Que faire si j'oublie d'exécuter `document-project` ?
|
||||||
|
|
||||||
|
Ne vous inquiétez pas — vous pouvez le faire à tout moment. Vous pouvez même le faire pendant ou après un projet pour aider à maintenir la documentation à jour.
|
||||||
|
|
||||||
|
### Puis-je utiliser Quick Dev pour les projets existants ?
|
||||||
|
|
||||||
|
Oui ! Quick Dev fonctionne très bien pour les projets existants. Il va :
|
||||||
|
|
||||||
|
- Détecter automatiquement votre pile technologique existante
|
||||||
|
- Analyser les patterns de code existants
|
||||||
|
- Détecter les conventions et demander confirmation
|
||||||
|
- Générer une spécification technique riche en contexte qui respecte le code existant
|
||||||
|
|
||||||
|
Parfait pour les corrections de bugs et les petites fonctionnalités dans des bases de code existantes.
|
||||||
|
|
||||||
|
### Que faire si mon code existant ne suit pas les bonnes pratiques ?
|
||||||
|
|
||||||
|
Quick Dev détecte vos conventions et demande : « Dois-je suivre ces conventions existantes ? » Vous décidez :
|
||||||
|
|
||||||
|
- **Oui** → Maintenir la cohérence avec la base de code actuelle
|
||||||
|
- **Non** → Établir de nouvelles normes (documenter pourquoi dans la spécification technique)
|
||||||
|
|
||||||
|
BMM respecte votre choix — il ne forcera pas la modernisation, mais la proposera.
|
||||||
|
|
||||||
|
**Une question sans réponse ici ?** Veuillez [ouvrir un ticket](https://github.com/bmad-code-org/BMAD-METHOD/issues) ou poser votre question sur [Discord](https://discord.gg/gk8jAdXWmj) afin que nous puissions l'ajouter !
|
||||||
|
|
@ -0,0 +1,64 @@
|
||||||
|
---
|
||||||
|
title: "Party Mode"
|
||||||
|
description: Collaboration multi-agents - regroupez tous vos agents IA dans une seule conversation
|
||||||
|
sidebar:
|
||||||
|
order: 7
|
||||||
|
---
|
||||||
|
|
||||||
|
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. BMad Master orchestre, en sélectionnant les agents pertinents à chaque message. 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 MVP[^1] ? »
|
||||||
|
|
||||||
|
**Architecte :** « Commencez en monolithe. Les microservices ajoutent une complexité dont vous n'avez pas besoin à 1000 utilisateurs. »
|
||||||
|
|
||||||
|
**PM :** « D'accord. Le time-to-market[^2] 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
|
||||||
|
|
||||||
|
[^1]: 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.
|
||||||
|
[^2]: 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.
|
||||||
|
|
@ -0,0 +1,117 @@
|
||||||
|
---
|
||||||
|
title: "Prévention des conflits entre agents"
|
||||||
|
description: Comment l'architecture empêche les conflits lorsque plusieurs agents implémentent un système
|
||||||
|
sidebar:
|
||||||
|
order: 4
|
||||||
|
---
|
||||||
|
|
||||||
|
Lorsque plusieurs agents IA implémentent différentes parties d'un système, ils peuvent prendre des décisions techniques contradictoires. La documentation d'architecture prévient cela en établissant des standards partagés.
|
||||||
|
|
||||||
|
## Types de conflits courants
|
||||||
|
|
||||||
|
### Conflits de style d'API
|
||||||
|
|
||||||
|
Sans architecture :
|
||||||
|
- L'agent A utilise REST avec `/users/{id}`
|
||||||
|
- L'agent B utilise des mutations GraphQL
|
||||||
|
- Résultat : Patterns d'API incohérents, consommateurs confus
|
||||||
|
|
||||||
|
Avec architecture :
|
||||||
|
- L'ADR[^1] spécifie : « Utiliser GraphQL pour toute communication client-serveur »
|
||||||
|
- Tous les agents suivent le même pattern
|
||||||
|
|
||||||
|
### Conflits de conception de base de données
|
||||||
|
|
||||||
|
Sans architecture :
|
||||||
|
- L'agent A utilise des noms de colonnes en snake_case
|
||||||
|
- L'agent B utilise des noms de colonnes en camelCase
|
||||||
|
- Résultat : Schéma incohérent, requêtes illisibles
|
||||||
|
|
||||||
|
Avec architecture :
|
||||||
|
- Un document de standards spécifie les conventions de nommage
|
||||||
|
- Tous les agents suivent les mêmes patterns
|
||||||
|
|
||||||
|
### Conflits de gestion d'état
|
||||||
|
|
||||||
|
Sans architecture :
|
||||||
|
- L'agent A utilise Redux pour l'état global
|
||||||
|
- L'agent B utilise React Context
|
||||||
|
- Résultat : Multiples approches de gestion d'état, complexité
|
||||||
|
|
||||||
|
Avec architecture :
|
||||||
|
- L'ADR spécifie l'approche de gestion d'état
|
||||||
|
- Tous les agents implémentent de manière cohérente
|
||||||
|
|
||||||
|
## Comment l'architecture prévient les conflits
|
||||||
|
|
||||||
|
### 1. Décisions explicites via les ADR[^1]
|
||||||
|
|
||||||
|
Chaque choix technologique significatif est documenté avec :
|
||||||
|
- Contexte (pourquoi cette décision est importante)
|
||||||
|
- Options considérées (quelles alternatives existent)
|
||||||
|
- Décision (ce qui a été choisi)
|
||||||
|
- Justification (pourquoi cela a-t-il été choisi)
|
||||||
|
- Conséquences (compromis acceptés)
|
||||||
|
|
||||||
|
### 2. Guidance spécifique aux FR/NFR[^2]
|
||||||
|
|
||||||
|
L'architecture associe chaque exigence fonctionnelle à une approche technique :
|
||||||
|
- FR-001 : Gestion des utilisateurs → Mutations GraphQL
|
||||||
|
- FR-002 : Application mobile → Requêtes optimisées
|
||||||
|
|
||||||
|
### 3. Standards et conventions
|
||||||
|
|
||||||
|
Documentation explicite de :
|
||||||
|
- La structure des répertoires
|
||||||
|
- Les conventions de nommage
|
||||||
|
- L'organisation du code
|
||||||
|
- Les patterns de test
|
||||||
|
|
||||||
|
## L'architecture comme contexte partagé
|
||||||
|
|
||||||
|
Considérez l'architecture comme le contexte partagé que tous les agents lisent avant d'implémenter :
|
||||||
|
|
||||||
|
```text
|
||||||
|
PRD : "Que construire"
|
||||||
|
↓
|
||||||
|
Architecture : "Comment le construire"
|
||||||
|
↓
|
||||||
|
L'agent A lit l'architecture → implémente l'Epic 1
|
||||||
|
L'agent B lit l'architecture → implémente l'Epic 2
|
||||||
|
L'agent C lit l'architecture → implémente l'Epic 3
|
||||||
|
↓
|
||||||
|
Résultat : Implémentation cohérente
|
||||||
|
```
|
||||||
|
|
||||||
|
## Sujets clés des ADR
|
||||||
|
|
||||||
|
Décisions courantes qui préviennent les conflits :
|
||||||
|
|
||||||
|
| Sujet | Exemple de décision |
|
||||||
|
| ---------------- | -------------------------------------------- |
|
||||||
|
| Style d'API | GraphQL vs REST vs gRPC |
|
||||||
|
| Base de données | PostgreSQL vs MongoDB |
|
||||||
|
| Authentification | JWT vs Sessions |
|
||||||
|
| Gestion d'état | Redux vs Context vs Zustand |
|
||||||
|
| Styling | CSS Modules vs Tailwind vs Styled Components |
|
||||||
|
| Tests | Jest + Playwright vs Vitest + Cypress |
|
||||||
|
|
||||||
|
## Anti-patterns à éviter
|
||||||
|
|
||||||
|
:::caution[Erreurs courantes]
|
||||||
|
- **Décisions implicites** — « On décidera du style d'API au fur et à mesure » mène à l'incohérence
|
||||||
|
- **Sur-documentation** — Documenter chaque choix mineur cause une paralysie analytique
|
||||||
|
- **Architecture obsolète** — Les documents écrits une fois et jamais mis à jour poussent les agents à suivre des patterns dépassés
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::tip[Approche correcte]
|
||||||
|
- Documenter les décisions qui traversent les frontières des epics
|
||||||
|
- Se concentrer sur les zones sujettes aux conflits
|
||||||
|
- Mettre à jour l'architecture au fur et à mesure des apprentissages
|
||||||
|
- Utiliser `bmad-correct-course` pour les changements significatifs
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: ADR (Architecture Decision Record) : document qui consigne une décision d’architecture, son contexte, les options envisagées, le choix retenu et ses conséquences, afin d’assurer la traçabilité et la compréhension des décisions techniques dans le temps.
|
||||||
|
[^2]: FR / NFR (Functional / Non-Functional Requirement) : exigences décrivant respectivement **ce que le système doit faire** (fonctionnalités, comportements attendus) et **comment il doit le faire** (contraintes de performance, sécurité, fiabilité, ergonomie, etc.).
|
||||||
|
|
@ -0,0 +1,158 @@
|
||||||
|
---
|
||||||
|
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: 7
|
||||||
|
---
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
## Ce Qu'il Fait
|
||||||
|
|
||||||
|
Les agents IA prennent constamment des décisions d'implémentation — quels patterns suivre, comment structurer le code, quelles conventions utiliser. Sans guidance claire, ils peuvent :
|
||||||
|
- Suivre des bonnes pratiques génériques qui ne correspondent pas à votre codebase
|
||||||
|
- Prendre des décisions incohérentes selon les différentes stories
|
||||||
|
- Passer à côté d'exigences ou de contraintes spécifiques au projet
|
||||||
|
|
||||||
|
Le fichier `project-context.md` résout ce problème en documentant ce que les agents doivent savoir dans un format concis et optimisé pour les LLM.
|
||||||
|
|
||||||
|
## Comment Ça Fonctionne
|
||||||
|
|
||||||
|
Chaque workflow d'implémentation charge automatiquement `project-context.md` s'il existe. Le workflow architecte le charge également pour respecter vos préférences techniques lors de la conception de l'architecture.
|
||||||
|
|
||||||
|
**Chargé par ces workflows :**
|
||||||
|
- `bmad-create-architecture` — respecte les préférences techniques pendant la phase de solutioning
|
||||||
|
- `bmad-create-story` — informe la création de stories avec les patterns du projet
|
||||||
|
- `bmad-dev-story` — guide les décisions d'implémentation
|
||||||
|
- `bmad-code-review` — valide par rapport aux standards du projet
|
||||||
|
- `bmad-quick-dev` — applique les patterns lors de l'implémentation des spécifications techniques
|
||||||
|
- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — fournit le contexte global du projet
|
||||||
|
|
||||||
|
## Quand Le Créer
|
||||||
|
|
||||||
|
Le fichier `project-context.md` est utile à n'importe quel stade d'un projet :
|
||||||
|
|
||||||
|
| Scénario | Quand Créer | Objectif |
|
||||||
|
|------------------------------------------|-----------------------------------------------------|---------------------------------------------------------------------------------------|
|
||||||
|
| **Nouveau projet, avant l'architecture** | Manuellement, avant `bmad-create-architecture` | Documenter vos préférences techniques pour que l'architecte les respecte |
|
||||||
|
| **Nouveau projet, après l'architecture** | Via `bmad-generate-project-context` ou manuellement | Capturer les décisions d'architecture pour les agents d'implémentation |
|
||||||
|
| **Projet existant** | Via `bmad-generate-project-context` | Découvrir les patterns existants pour que les agents suivent les conventions établies |
|
||||||
|
| **Projet Quick Dev** | Avant ou pendant `bmad-quick-dev` | Garantir que l'implémentation rapide respecte vos patterns |
|
||||||
|
|
||||||
|
:::tip[Recommandé]
|
||||||
|
Pour les nouveaux projets, créez-le manuellement avant l'architecture si vous avez de fortes préférences techniques. Sinon, générez-le après l'architecture pour capturer ces décisions.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Ce Qu'il Contient
|
||||||
|
|
||||||
|
Le fichier a deux sections principales :
|
||||||
|
|
||||||
|
### Pile Technologique & Versions
|
||||||
|
|
||||||
|
Documente les frameworks, langages et outils utilisés par votre projet avec leurs versions spécifiques :
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Pile Technologique & Versions
|
||||||
|
|
||||||
|
- Node.js 20.x, TypeScript 5.3, React 18.2
|
||||||
|
- State: Zustand (pas Redux)
|
||||||
|
- Testing: Vitest, Playwright, MSW
|
||||||
|
- Styling: Tailwind CSS avec design tokens personnalisés
|
||||||
|
```
|
||||||
|
|
||||||
|
### Règles Critiques d’Implémentation
|
||||||
|
|
||||||
|
Documente les patterns et conventions que les agents pourraient autrement manquer :
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
|
||||||
|
## Règles Critiques d’Implémentation
|
||||||
|
|
||||||
|
**Configuration TypeScript :**
|
||||||
|
- Mode strict activé — pas de types `any` sans approbation explicite
|
||||||
|
- Utiliser `interface` pour les APIs publiques, `type` pour les unions/intersections
|
||||||
|
|
||||||
|
**Organisation du Code :**
|
||||||
|
- Composants dans `/src/components/` avec fichiers `.test.tsx` co-localisés
|
||||||
|
- Utilitaires dans `/src/lib/` pour les fonctions pures réutilisables
|
||||||
|
- Les appels API utilisent le singleton `apiClient` — jamais de fetch direct
|
||||||
|
|
||||||
|
**Patterns de Tests :**
|
||||||
|
- Les tests unitaires se concentrent sur la logique métier, pas sur les détails d’implémentation
|
||||||
|
- Les tests d’intégration utilisent MSW pour simuler les réponses API
|
||||||
|
- Les tests E2E couvrent uniquement les parcours utilisateurs critiques
|
||||||
|
|
||||||
|
**Spécifique au Framework :**
|
||||||
|
- Toutes les opérations async utilisent le wrapper `handleError` pour une gestion cohérente des erreurs
|
||||||
|
- Les feature flags sont accessibles via `featureFlag()` de `@/lib/flags`
|
||||||
|
- Les nouvelles routes suivent le modèle de routage basé sur les fichiers dans `/src/app/`
|
||||||
|
```
|
||||||
|
|
||||||
|
Concentrez-vous sur ce qui est **non évident** — des choses que les agents pourraient ne pas déduire en lisant des extraits de code. Ne documentez pas les pratiques standard qui s'appliquent universellement.
|
||||||
|
|
||||||
|
## Création du Fichier
|
||||||
|
|
||||||
|
Vous avez trois options :
|
||||||
|
|
||||||
|
### Création Manuelle
|
||||||
|
|
||||||
|
Créez le fichier `_bmad-output/project-context.md` et ajoutez vos règles :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Depuis la racine du projet
|
||||||
|
mkdir -p _bmad-output
|
||||||
|
touch _bmad-output/project-context.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Éditez-le avec votre pile technologique et vos règles d'implémentation. Les workflows architecture et implémentation le trouveront et le chargeront automatiquement.
|
||||||
|
|
||||||
|
### Générer Après L'Architecture
|
||||||
|
|
||||||
|
Exécutez le workflow `bmad-generate-project-context` après avoir terminé votre architecture :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Cela analyse votre document d'architecture et vos fichiers projet pour générer un fichier de contexte capturant les décisions prises.
|
||||||
|
|
||||||
|
### Générer Pour Les Projets Existants
|
||||||
|
|
||||||
|
Pour les projets existants, exécutez `bmad-generate-project-context` pour découvrir les patterns existants :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Le workflow analyse votre codebase pour identifier les conventions, puis génère un fichier de contexte que vous pouvez examiner et affiner.
|
||||||
|
|
||||||
|
## Pourquoi C'est Important
|
||||||
|
|
||||||
|
Sans `project-context.md`, les agents font des suppositions qui peuvent ne pas correspondre à votre projet :
|
||||||
|
|
||||||
|
| Sans Contexte | Avec Contexte |
|
||||||
|
|----------------------------------------------------|-------------------------------------------------|
|
||||||
|
| Utilise des patterns génériques | Suit vos conventions établies |
|
||||||
|
| Style incohérent selon les stories | Implémentation cohérente |
|
||||||
|
| Peut manquer les contraintes spécifiques au projet | Respecte toutes les exigences techniques |
|
||||||
|
| Chaque agent décide indépendamment | Tous les agents s'alignent sur les mêmes règles |
|
||||||
|
|
||||||
|
C'est particulièrement important pour :
|
||||||
|
- **Quick Dev** — saute le PRD et l'architecture, le fichier de contexte comble le vide
|
||||||
|
- **Projets d'équipe** — garantit que tous les agents suivent les mêmes standards
|
||||||
|
- **Projets existants** — empêche de casser les patterns établis
|
||||||
|
|
||||||
|
## Édition et Mise à Jour
|
||||||
|
|
||||||
|
Le fichier `project-context.md` est un document vivant. Mettez-le à jour quand :
|
||||||
|
|
||||||
|
- Les décisions d'architecture changent
|
||||||
|
- De nouvelles conventions sont établies
|
||||||
|
- Les patterns évoluent pendant l'implémentation
|
||||||
|
- Vous identifiez des lacunes dans le comportement des agents
|
||||||
|
|
||||||
|
Vous pouvez l'éditer manuellement à tout moment, ou réexécuter `bmad-generate-project-context` pour le mettre à jour après des changements significatifs.
|
||||||
|
|
||||||
|
:::note[Emplacement du Fichier]
|
||||||
|
L'emplacement par défaut est `_bmad-output/project-context.md`. Les workflows le recherchent là, et vérifient également `**/project-context.md` n'importe où dans votre projet.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,79 @@
|
||||||
|
---
|
||||||
|
title: "Quick Dev"
|
||||||
|
description: Réduire la friction de l’interaction humaine sans renoncer aux points de contrôle qui protègent la qualité des résultats
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Intention en entrée, modifications de code en sortie, avec aussi peu d'interactions humaines dans la boucle que possible — sans sacrifier la qualité.
|
||||||
|
|
||||||
|
Il permet au modèle de s'exécuter plus longtemps entre les points de contrôle, puis ne vous fait intervenir que lorsque la tâche ne peut pas se poursuivre en toute sécurité sans jugement humain, ou lorsqu'il est temps de revoir le résultat final.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Pourquoi cette fonctionnalité existe
|
||||||
|
|
||||||
|
Les interactions humaines dans la boucle sont nécessaires et coûteuses.
|
||||||
|
|
||||||
|
Les LLM actuels échouent encore de manière prévisible : ils interprètent mal l'intention, comblent les lacunes avec des suppositions assurées, dérivent vers du travail non lié, et génèrent des résultats à réviser bruyants. En même temps, l'intervention humaine constante limite la fluidité du développement. L'attention humaine est le goulot d'étranglement.
|
||||||
|
|
||||||
|
`bmad-quick-dev` rééquilibre ce compromis. Il fait confiance au modèle pour s'exécuter sans surveillance sur de plus longues périodes, mais seulement après que le workflow ait créé une frontière suffisamment solide pour rendre cela sûr.
|
||||||
|
|
||||||
|
## La conception fondamentale
|
||||||
|
|
||||||
|
### 1. Compresser l'intention d'abord
|
||||||
|
|
||||||
|
Le workflow commence par compresser l’interaction de la personne et du modèle à partir de la requête en un objectif cohérent. L'entrée peut commencer sous forme d'une expression grossière de l'intention, mais avant que le workflow ne s'exécute de manière autonome, elle doit devenir suffisamment petite, claire et sans contradiction pour être exécutable.
|
||||||
|
|
||||||
|
L'intention peut prendre plusieurs formes : quelques phrases, un lien vers un outil de suivi de bugs, une sortie du mode planification, du texte copié depuis une session de chat, ou même un numéro de story depuis un fichier `epics.md` de BMAD. Dans ce dernier cas, le workflow ne comprendra pas la sémantique de suivi des stories de BMAD, mais il peut quand même prendre la story elle-même et l'exécuter.
|
||||||
|
|
||||||
|
Ce workflow n'élimine pas le contrôle humain. Il le déplace vers un nombre réduit d’étapes à forte valeur :
|
||||||
|
|
||||||
|
- **Clarification de l'intention** - transformer une demande confuse en un objectif cohérent sans contradictions cachées
|
||||||
|
- **Approbation de la spécification** - confirmer que la compréhension figée correspond bien à ce qu'il faut construire
|
||||||
|
- **Revue du produit final** - le point de contrôle principal, où la personne décide si le résultat est acceptable à la fin
|
||||||
|
|
||||||
|
### 2. Router vers le chemin le plus court et sûr
|
||||||
|
|
||||||
|
Une fois l'objectif clair, le workflow décide s'il s'agit d'un véritable changement en une seule étape ou s'il nécessite le chemin complet. Les petits changements à zéro impact peuvent aller directement à l'implémentation. Tout le reste passe par la planification pour que le modèle dispose d'un cadre plus solide avant de s'exécuter plus longtemps de manière autonome.
|
||||||
|
|
||||||
|
### 3. S'exécuter plus longtemps avec moins de supervision
|
||||||
|
|
||||||
|
Après cette décision de routage, le modèle peut prendre en charge une plus grande partie du travail par lui-même. Sur le chemin complet, la spécification approuvée devient le cadre dans lequel le modèle s'exécute avec moins de supervision, ce qui est tout l'intérêt de la conception.
|
||||||
|
|
||||||
|
### 4. Diagnostiquer les échecs au bon niveau
|
||||||
|
|
||||||
|
Si l'implémentation est incorrecte parce que l'intention était mauvaise, corriger le code n'est pas la bonne solution. Si le code est incorrect parce que la spécification était faible, corriger le diff n'est pas non plus la bonne solution. Le workflow est conçu pour diagnostiquer où l'échec est entré dans le système, revenir à ce niveau, et régénérer à partir de ce point.
|
||||||
|
|
||||||
|
Les résultats de la revue sont utilisés pour décider si le problème provenait de l'intention, de la génération de la spécification, ou de l'implémentation locale. Seuls les véritables problèmes locaux sont corrigés localement.
|
||||||
|
|
||||||
|
### 5. Ne faire intervenir l’humain que si nécessaire
|
||||||
|
|
||||||
|
L'entretien sur l'intention implique la personne dans la boucle, mais ce n'est pas le même type d'interruption qu'un point de contrôle récurrent. Le workflow essaie de garder ces points de contrôle récurrents au minimum. Après la mise en forme initiale de l'intention, la personne revient principalement lorsque le workflow ne peut pas continuer en toute sécurité sans jugement, et à la fin, lorsqu'il est temps de revoir le résultat.
|
||||||
|
|
||||||
|
- **Résolution des lacunes d'intention** - intervenir à nouveau lors de la revue prouve que le workflow n'a pas pu déduire correctement ce qui était voulu
|
||||||
|
|
||||||
|
Tout le reste est candidat à une exécution autonome plus longue. Ce compromis est délibéré. Les anciens patterns dépensent plus d'attention humaine en supervision continue. Quick Dev fait davantage confiance au modèle, mais préserve l'attention humaine pour les moments où le raisonnement humain a le plus d'impact.
|
||||||
|
|
||||||
|
## Pourquoi le système de revue est important
|
||||||
|
|
||||||
|
La phase de revue n'est pas seulement là pour trouver des bugs. Elle est là pour router la correction sans détruire l'élan.
|
||||||
|
|
||||||
|
Ce workflow fonctionne mieux sur une plateforme capable de générer des sous-agents[^1], ou au moins d'invoquer un autre LLM via la ligne de commande et d'attendre un résultat. Si votre plateforme ne supporte pas cela nativement, vous pouvez ajouter un skill pour le faire. Les sous-agents sans contexte sont une pierre angulaire de la conception de la revue.
|
||||||
|
|
||||||
|
Les revues agentiques[^2] échouent souvent de deux manières :
|
||||||
|
|
||||||
|
- Elles génèrent trop d’observations, forçant la personne à trier le bruit.
|
||||||
|
- Elles déraillent des modifications actuelles en remontant des problèmes non liés et en transformant chaque exécution en un projet de nettoyage improvisé.
|
||||||
|
|
||||||
|
Quick Dev aborde ces deux problèmes en traitant la revue comme un triage[^3].
|
||||||
|
|
||||||
|
Lorsqu’une observation est fortuite plutôt que directement liée au travail en cours, le processus peut la mettre de côté au lieu d’obliger la personne à s’en occuper immédiatement. Cela permet de rester concentré sur l’exécution et d’éviter que des digressions aléatoires ne viennent épuiser le capital d’attention.
|
||||||
|
|
||||||
|
Ce triage sera parfois imparfait. C’est acceptable. Il est généralement préférable de mal juger certaines observations plutôt que d’inonder la personne de milliers de commentaires de revue à faible valeur. Le système optimise la qualité du rapport, pas d’être exhaustif.
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: Sous-agent : agent IA secondaire créé temporairement pour effectuer une tâche spécifique (comme une revue de code) de manière isolée, sans hériter du contexte complet de l’agent principal, ce qui permet une analyse plus objective et impartiale.
|
||||||
|
[^2]: Revues agentiques (agentic review) : revue de code effectuée par un agent IA de manière autonome, capable d’analyser, d’identifier des problèmes et de formuler des recommandations sans intervention humaine directe.
|
||||||
|
[^3]: Triage : processus de filtrage et de priorisation des observations issues d’une revue, afin de distinguer les problèmes pertinents à traiter immédiatement de ceux qui peuvent être mis de côté pour plus tard.
|
||||||
|
|
@ -0,0 +1,85 @@
|
||||||
|
---
|
||||||
|
title: "Pourquoi le Solutioning est Important"
|
||||||
|
description: Comprendre pourquoi la phase de solutioning est critique pour les projets multi-epics
|
||||||
|
sidebar:
|
||||||
|
order: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
La Phase 3 (Solutioning) traduit le **quoi** construire (issu de la Planification) en **comment** le construire (conception technique). Cette phase évite les conflits entre agents dans les projets multi-epics en documentant les décisions architecturales avant le début de l'implémentation.
|
||||||
|
|
||||||
|
## Le Problème Sans Solutioning
|
||||||
|
|
||||||
|
```text
|
||||||
|
Agent 1 implémente l'Epic 1 avec une API REST
|
||||||
|
Agent 2 implémente l'Epic 2 avec GraphQL
|
||||||
|
Résultat : Conception d'API incohérente, cauchemar d'intégration
|
||||||
|
```
|
||||||
|
|
||||||
|
Lorsque plusieurs agents implémentent différentes parties d'un système sans orientation architecturale partagée, ils prennent des décisions techniques indépendantes qui peuvent entrer en conflit.
|
||||||
|
|
||||||
|
## La Solution Avec le Solutioning
|
||||||
|
|
||||||
|
```text
|
||||||
|
le workflow architecture décide : "Utiliser GraphQL pour toutes les API"
|
||||||
|
Tous les agents suivent les décisions d'architecture
|
||||||
|
Résultat : Implémentation cohérente, pas de conflits
|
||||||
|
```
|
||||||
|
|
||||||
|
En documentant les décisions techniques de manière explicite, tous les agents implémentent de façon cohérente et l'intégration devient simple.
|
||||||
|
|
||||||
|
## Solutioning vs Planification
|
||||||
|
|
||||||
|
| Aspect | Planification (Phase 2) | Solutioning (Phase 3) |
|
||||||
|
|----------|--------------------------|-------------------------------------------------|
|
||||||
|
| Question | Quoi et Pourquoi ? | Comment ? Puis Quelles unités de travail ? |
|
||||||
|
| Sortie | FRs/NFRs (Exigences)[^1] | Architecture + Epics[^2]/Stories[^3] |
|
||||||
|
| Agent | PM | Architect → PM |
|
||||||
|
| Audience | Parties prenantes | Développeurs |
|
||||||
|
| Document | PRD[^4] (FRs/NFRs) | Architecture + Fichiers Epics |
|
||||||
|
| Niveau | Logique métier | Conception technique + Décomposition du travail |
|
||||||
|
|
||||||
|
## Principe Clé
|
||||||
|
|
||||||
|
**Rendre les décisions techniques explicites et documentées** pour que tous les agents implémentent de manière cohérente.
|
||||||
|
|
||||||
|
Cela évite :
|
||||||
|
- Les conflits de style d'API (REST vs GraphQL)
|
||||||
|
- Les incohérences de conception de base de données
|
||||||
|
- Les désaccords sur la gestion du state
|
||||||
|
- Les inadéquations de conventions de nommage
|
||||||
|
- Les variations d'approche de sécurité
|
||||||
|
|
||||||
|
## Quand le Solutioning est Requis
|
||||||
|
|
||||||
|
| Parcours | Solutioning Requis ? |
|
||||||
|
|-----------------------|-----------------------------|
|
||||||
|
| Quick Dev | Non - l’ignore complètement |
|
||||||
|
| Méthode BMad Simple | Optionnel |
|
||||||
|
| Méthode BMad Complexe | Oui |
|
||||||
|
| Enterprise | Oui |
|
||||||
|
|
||||||
|
:::tip[Règle Générale]
|
||||||
|
Si vous avez plusieurs epics qui pourraient être implémentés par différents agents, vous avez besoin de solutioning.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Conséquences de sauter la phase de Solutioning
|
||||||
|
|
||||||
|
Sauter le solutioning sur des projets complexes entraîne :
|
||||||
|
|
||||||
|
- **Des problèmes d'intégration** découverts en milieu de sprint[^5]
|
||||||
|
- **Du travail répété** dû à des implémentations conflictuelles
|
||||||
|
- **Un temps de développement plus long** globalement
|
||||||
|
- **De la dette technique**[^6] due à des patterns incohérents
|
||||||
|
|
||||||
|
:::caution[Coût Multiplié]
|
||||||
|
Détecter les problèmes d'alignement lors du solutioning est 10× plus rapide que de les découvrir pendant l'implémentation.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: FR / NFR (Functional / Non-Functional Requirement) : exigences décrivant respectivement **ce que le système doit faire** (fonctionnalités, comportements attendus) et **comment il doit le faire** (contraintes de performance, sécurité, fiabilité, ergonomie, etc.).
|
||||||
|
[^2]: Epic : dans les méthodologies agiles, une unité de travail importante qui peut être décomposée en plusieurs stories plus petites. Un epic représente généralement une fonctionnalité majeure ou un objectif métier.
|
||||||
|
[^3]: Story (User Story) : description courte et simple d'une fonctionnalité du point de vue de l'utilisateur, utilisée dans les méthodologies agiles pour planifier et prioriser le travail.
|
||||||
|
[^4]: PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d'aligner les équipes sur ce qui doit être construit et pourquoi.
|
||||||
|
[^5]: Sprint : période de temps fixe (généralement 1 à 4 semaines) dans les méthodologies agiles durant laquelle l'équipe complète un ensemble prédéfini de tâches.
|
||||||
|
[^6]: Dette technique : coût futur supplémentaire de travail résultant de choix de facilité ou de raccourcis pris lors du développement initial, nécessitant souvent une refonte ultérieure.
|
||||||
|
|
@ -0,0 +1,174 @@
|
||||||
|
---
|
||||||
|
title: "Comment personnaliser BMad"
|
||||||
|
description: Personnalisez les agents, les workflows et les modules tout en préservant la compatibilité avec les mises à jour
|
||||||
|
sidebar:
|
||||||
|
order: 7
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez les fichiers `.customize.yaml` pour adapter le comportement, les personas[^1] et les menus des agents tout en préservant vos modifications lors des mises à jour.
|
||||||
|
|
||||||
|
## Quand utiliser cette fonctionnalité
|
||||||
|
|
||||||
|
- Vous souhaitez modifier le nom, la personnalité ou le style de communication d'un agent
|
||||||
|
- Vous avez besoin que les agents se souviennent du contexte spécifique au projet
|
||||||
|
- Vous souhaitez ajouter des éléments de menu personnalisés qui déclenchent vos propres workflows ou prompts
|
||||||
|
- Vous voulez que les agents effectuent des actions spécifiques à chaque démarrage
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- BMad installé dans votre projet (voir [Comment installer BMad](./install-bmad.md))
|
||||||
|
- Un éditeur de texte pour les fichiers YAML
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::caution[Protégez vos personnalisations]
|
||||||
|
Utilisez toujours les fichiers `.customize.yaml` décrits ici plutôt que de modifier directement les fichiers d'agents. L'installateur écrase les fichiers d'agents lors des mises à jour, mais préserve vos modifications dans les fichiers `.customize.yaml`.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Étapes
|
||||||
|
|
||||||
|
### 1. Localiser les fichiers de personnalisation
|
||||||
|
|
||||||
|
Après l'installation, vous trouverez un fichier `.customize.yaml` par agent dans :
|
||||||
|
|
||||||
|
```text
|
||||||
|
_bmad/_config/agents/
|
||||||
|
├── bmm-analyst.customize.yaml
|
||||||
|
├── bmm-architect.customize.yaml
|
||||||
|
└── ... (un fichier par agent installé)
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Modifier le fichier de personnalisation
|
||||||
|
|
||||||
|
Ouvrez le fichier `.customize.yaml` de l'agent que vous souhaitez modifier. Chaque section est facultative — personnalisez uniquement ce dont vous avez besoin.
|
||||||
|
|
||||||
|
| Section | Comportement | Objectif |
|
||||||
|
| ------------------ | ------------ | ------------------------------------------------ |
|
||||||
|
| `agent.metadata` | Remplace | Remplacer le nom d'affichage de l'agent |
|
||||||
|
| `persona` | Remplace | Définir le rôle, l'identité, le style et les principes |
|
||||||
|
| `memories` | Ajoute | Ajouter un contexte persistant que l'agent se rappelle toujours |
|
||||||
|
| `menu` | Ajoute | Ajouter des éléments de menu personnalisés pour les workflows ou prompts |
|
||||||
|
| `critical_actions` | Ajoute | Définir les instructions de démarrage de l'agent |
|
||||||
|
| `prompts` | Ajoute | Créer des prompts réutilisables pour les actions du menu |
|
||||||
|
|
||||||
|
Les sections marquées **Remplace** écrasent entièrement les valeurs par défaut de l'agent. Les sections marquées **Ajoute** s'ajoutent à la configuration existante.
|
||||||
|
|
||||||
|
**Nom de l'agent**
|
||||||
|
|
||||||
|
Modifier la façon dont l'agent se présente :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
agent:
|
||||||
|
metadata:
|
||||||
|
name: 'Bob l’éponge' # Par défaut : "Mary"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Persona**
|
||||||
|
|
||||||
|
Remplacer la personnalité, le rôle et le style de communication de l'agent :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
persona:
|
||||||
|
role: 'Ingénieur Full-Stack Senior'
|
||||||
|
identity: 'Habite dans un ananas (au fond de la mer)'
|
||||||
|
communication_style: 'Style agaçant de Bob l’Éponge'
|
||||||
|
principles:
|
||||||
|
- 'Jamais de nidification, les devs Bob l’Éponge détestent plus de 2 niveaux d’imbrication'
|
||||||
|
- 'Privilégier la composition à l’héritage'
|
||||||
|
```
|
||||||
|
|
||||||
|
La section `persona`[^1] remplace entièrement le persona par défaut, donc incluez les quatre champs si vous la définissez.
|
||||||
|
|
||||||
|
**Souvenirs**
|
||||||
|
|
||||||
|
Ajouter un contexte persistant que l'agent gardera toujours en mémoire :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
memories:
|
||||||
|
- 'Travaille au Krusty Krab'
|
||||||
|
- 'Célébrité préférée : David Hasselhoff'
|
||||||
|
- 'Appris dans l’Epic 1 que ce n’est pas cool de faire semblant que les tests ont passé'
|
||||||
|
```
|
||||||
|
|
||||||
|
**Éléments de menu**
|
||||||
|
|
||||||
|
Ajouter des entrées personnalisées au menu d'affichage de l'agent. Chaque élément nécessite un `trigger`, une cible (chemin `workflow` ou référence `action`), et une `description` :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
menu:
|
||||||
|
- trigger: my-workflow
|
||||||
|
workflow: 'my-custom/workflows/my-workflow.yaml'
|
||||||
|
description: Mon workflow personnalisé
|
||||||
|
- trigger: deploy
|
||||||
|
action: '#deploy-prompt'
|
||||||
|
description: Déployer en production
|
||||||
|
```
|
||||||
|
|
||||||
|
**Actions critiques**
|
||||||
|
|
||||||
|
Définir des instructions qui s'exécutent au démarrage de l'agent :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
critical_actions:
|
||||||
|
- 'Vérifier les pipelines CI avec le Skill XYZ et alerter l’utilisateur au réveil si quelque chose nécessite une attention urgente'
|
||||||
|
```
|
||||||
|
|
||||||
|
**Prompts personnalisés**
|
||||||
|
|
||||||
|
Créer des prompts réutilisables que les éléments de menu peuvent référencer avec `action="#id"` :
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
prompts:
|
||||||
|
- id: deploy-prompt
|
||||||
|
content: |
|
||||||
|
Déployer la branche actuelle en production :
|
||||||
|
1. Exécuter tous les tests
|
||||||
|
2. Build le projet
|
||||||
|
3. Exécuter le script de déploiement
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. Appliquer vos modifications
|
||||||
|
|
||||||
|
Après modification, réinstallez pour appliquer les changements :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install
|
||||||
|
```
|
||||||
|
|
||||||
|
L'installateur détecte l'installation existante et propose ces options :
|
||||||
|
|
||||||
|
| Option | Ce qu'elle fait |
|
||||||
|
| ----------------------------------- | ---------------------------------------------------------------------- |
|
||||||
|
| **Quick Update** | Met à jour tous les modules vers la dernière version et applique les personnalisations |
|
||||||
|
| **Modify BMad Installation** | Flux d'installation complet pour ajouter ou supprimer des modules |
|
||||||
|
|
||||||
|
Pour des modifications de personnalisation uniquement, **Quick Update** est l'option la plus rapide.
|
||||||
|
|
||||||
|
## Résolution des problèmes
|
||||||
|
|
||||||
|
**Les modifications n'apparaissent pas ?**
|
||||||
|
|
||||||
|
- Exécutez `npx bmad-method install` et sélectionnez **Quick Update** pour appliquer les modifications
|
||||||
|
- Vérifiez que votre syntaxe YAML est valide (l'indentation compte)
|
||||||
|
- Assurez-vous d'avoir modifié le bon fichier `.customize.yaml` pour l'agent
|
||||||
|
|
||||||
|
**L'agent ne se charge pas ?**
|
||||||
|
|
||||||
|
- Vérifiez les erreurs de syntaxe YAML à l'aide d'un validateur YAML en ligne
|
||||||
|
- Assurez-vous de ne pas avoir laissé de champs vides après les avoir décommentés
|
||||||
|
- Essayez de revenir au modèle d'origine et de reconstruire
|
||||||
|
|
||||||
|
**Besoin de réinitialiser un agent ?**
|
||||||
|
|
||||||
|
- Effacez ou supprimez le fichier `.customize.yaml` de l'agent
|
||||||
|
- Exécutez `npx bmad-method install` et sélectionnez **Quick Update** pour restaurer les valeurs par défaut
|
||||||
|
|
||||||
|
## Personnalisation des workflows
|
||||||
|
|
||||||
|
La personnalisation des workflows et skills existants de la méthode BMad arrive bientôt.
|
||||||
|
|
||||||
|
## Personnalisation des modules
|
||||||
|
|
||||||
|
Les conseils sur la création de modules d'extension et la personnalisation des modules existants arrivent bientôt.
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: Persona : définition de la personnalité, du rôle et du style de communication d'un agent IA. Permet d'adapter le comportement et les réponses de l'agent selon les besoins du projet.
|
||||||
|
|
@ -0,0 +1,122 @@
|
||||||
|
---
|
||||||
|
title: "Projets existants"
|
||||||
|
description: Comment utiliser la méthode BMad sur des bases de code existantes
|
||||||
|
sidebar:
|
||||||
|
order: 6
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez la méthode BMad efficacement lorsque vous travaillez sur des projets existants et des bases de code legacy.
|
||||||
|
|
||||||
|
Ce guide couvre le flux de travail essentiel pour l'intégration à des projets existants avec la méthode BMad.
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- méthode BMad installée (`npx bmad-method install`)
|
||||||
|
- Une base de code existante sur laquelle vous souhaitez travailler
|
||||||
|
- Accès à un IDE IA (Claude Code ou Cursor)
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Étape 1 : Nettoyer les artefacts de planification terminés
|
||||||
|
|
||||||
|
Si vous avez terminé tous les epics et stories du PRD[^1] via le processus BMad, nettoyez ces fichiers. Archivez-les, supprimez-les, ou appuyez-vous sur l'historique des versions si nécessaire. Ne conservez pas ces fichiers dans :
|
||||||
|
|
||||||
|
- `docs/`
|
||||||
|
- `_bmad-output/planning-artifacts/`
|
||||||
|
- `_bmad-output/implementation-artifacts/`
|
||||||
|
|
||||||
|
## Étape 2 : Créer le contexte du projet
|
||||||
|
|
||||||
|
:::tip[Recommandé pour les projets existants]
|
||||||
|
Générez `project-context.md` pour capturer les patterns et conventions de votre base de code existante. Cela garantit que les agents IA suivent vos pratiques établies lors de l'implémentation des modifications.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Exécutez le workflow de génération de contexte du projet :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Cela analyse votre base de code pour identifier :
|
||||||
|
- La pile technologique et les versions
|
||||||
|
- Les patterns d'organisation du code
|
||||||
|
- Les conventions de nommage
|
||||||
|
- Les approches de test
|
||||||
|
- Les patterns spécifiques aux frameworks
|
||||||
|
|
||||||
|
Vous pouvez examiner et affiner le fichier généré, ou le créer manuellement à `_bmad-output/project-context.md` si vous préférez.
|
||||||
|
|
||||||
|
[En savoir plus sur le contexte du projet](../explanation/project-context.md)
|
||||||
|
|
||||||
|
## Étape 3 : Maintenir une documentation de projet de qualité
|
||||||
|
|
||||||
|
Votre dossier `docs/` doit contenir une documentation succincte et bien organisée qui représente fidèlement votre projet :
|
||||||
|
|
||||||
|
- L'intention et la justification métier
|
||||||
|
- Les règles métier
|
||||||
|
- L'architecture
|
||||||
|
- Toute autre information pertinente sur le projet
|
||||||
|
|
||||||
|
Pour les projets complexes, envisagez d'utiliser le workflow `bmad-document-project`. Il offre des variantes d'exécution qui analyseront l'ensemble de votre projet et documenteront son état actuel réel.
|
||||||
|
|
||||||
|
## Étape 4 : Obtenir de l'aide
|
||||||
|
|
||||||
|
### BMad-Help : Votre point de départ
|
||||||
|
|
||||||
|
**Exécutez `bmad-help` chaque fois que vous n'êtes pas sûr de la prochaine étape.** Ce guide intelligent :
|
||||||
|
|
||||||
|
- Inspecte votre projet pour voir ce qui a déjà été fait
|
||||||
|
- Affiche les options basées sur vos modules installés
|
||||||
|
- Comprend les requêtes en langage naturel
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help J'ai une app Rails existante, par où dois-je commencer ?
|
||||||
|
bmad-help Quelle est la différence entre quick-dev et la méthode complète ?
|
||||||
|
bmad-help Montre-moi quels workflows sont disponibles
|
||||||
|
```
|
||||||
|
|
||||||
|
BMad-Help s'exécute également **automatiquement à la fin de chaque workflow**, fournissant des conseils clairs sur exactement quoi faire ensuite.
|
||||||
|
|
||||||
|
### Choisir votre approche
|
||||||
|
|
||||||
|
Vous avez deux options principales selon l'ampleur des modifications :
|
||||||
|
|
||||||
|
| Portée | Approche recommandée |
|
||||||
|
| ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
|
||||||
|
| **Petites mises à jour ou ajouts** | Exécutez `bmad-quick-dev` pour clarifier l'intention, planifier, implémenter et réviser dans un seul workflow. La méthode BMad complète en quatre phases est probablement excessive. |
|
||||||
|
| **Modifications ou ajouts majeurs** | Commencez avec la méthode BMad, en appliquant autant ou aussi peu de rigueur que nécessaire. |
|
||||||
|
|
||||||
|
### Pendant la création du PRD
|
||||||
|
|
||||||
|
Lors de la création d'un brief ou en passant directement au PRD[^1], assurez-vous que l'agent :
|
||||||
|
|
||||||
|
- Trouve et analyse votre documentation de projet existante
|
||||||
|
- Lit le contexte approprié sur votre système actuel
|
||||||
|
|
||||||
|
Vous pouvez guider l'agent explicitement, mais l'objectif est de garantir que la nouvelle fonctionnalité s'intègre bien à votre système existant.
|
||||||
|
|
||||||
|
### Considérations UX
|
||||||
|
|
||||||
|
Le travail UX[^2] est optionnel. La décision dépend non pas de savoir si votre projet a une UX, mais de :
|
||||||
|
|
||||||
|
- Si vous allez travailler sur des modifications UX
|
||||||
|
- Si des conceptions ou patterns UX significatifs sont nécessaires
|
||||||
|
|
||||||
|
Si vos modifications se résument à de simples mises à jour d'écrans existants qui vous satisfont, un processus UX complet n'est pas nécessaire.
|
||||||
|
|
||||||
|
### Considérations d'architecture
|
||||||
|
|
||||||
|
Lors de la création de l'architecture, assurez-vous que l'architecte :
|
||||||
|
|
||||||
|
- Utilise les fichiers documentés appropriés
|
||||||
|
- Analyse la base de code existante
|
||||||
|
|
||||||
|
Soyez particulièrement attentif ici pour éviter de réinventer la roue ou de prendre des décisions qui ne s'alignent pas avec votre architecture existante.
|
||||||
|
|
||||||
|
## Plus d'informations
|
||||||
|
|
||||||
|
- **[Corrections rapides](./quick-fixes.md)** - Corrections de bugs et modifications ad-hoc
|
||||||
|
- **[FAQ Projets existants](../explanation/established-projects-faq.md)** - Questions courantes sur le travail sur des projets établis
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d'aligner les équipes sur ce qui doit être construit et pourquoi.
|
||||||
|
[^2]: UX (User Experience) : expérience utilisateur, englobant l'ensemble des interactions et perceptions d'un utilisateur face à un produit. Le design UX vise à créer des interfaces intuitives, efficaces et agréables en tenant compte des besoins, comportements et contexte d'utilisation.
|
||||||
|
|
@ -0,0 +1,136 @@
|
||||||
|
---
|
||||||
|
title: "Comment obtenir des réponses à propos de BMad"
|
||||||
|
description: Utiliser un LLM pour répondre rapidement à vos questions sur BMad
|
||||||
|
sidebar:
|
||||||
|
order: 4
|
||||||
|
---
|
||||||
|
|
||||||
|
## Commencez ici : BMad-Help
|
||||||
|
|
||||||
|
**Le moyen le plus rapide d'obtenir des réponses sur BMad est le skill `bmad-help`.** Ce guide intelligent répondra à plus de 80 % de toutes les questions et est disponible directement dans votre IDE pendant que vous travaillez.
|
||||||
|
|
||||||
|
BMad-Help est bien plus qu'un outil de recherche — il :
|
||||||
|
- **Inspecte votre projet** pour voir ce qui a déjà été réalisé
|
||||||
|
- **Comprend le langage naturel** — posez vos questions en français courant
|
||||||
|
- **S'adapte à vos modules installés** — affiche les options pertinentes
|
||||||
|
- **Se lance automatiquement après les workflows** — vous indique exactement quoi faire ensuite
|
||||||
|
- **Recommande la première tâche requise** — plus besoin de deviner par où commencer
|
||||||
|
|
||||||
|
### Comment utiliser BMad-Help
|
||||||
|
|
||||||
|
Appelez-le par son nom dans votre session IA :
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help
|
||||||
|
```
|
||||||
|
|
||||||
|
:::tip
|
||||||
|
Vous pouvez également utiliser `/bmad-help` ou `$bmad-help` selon votre plateforme, mais `bmad-help` tout seul devrait fonctionner partout.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Combinez-le avec une requête en langage naturel :
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help J'ai une idée de SaaS et je connais toutes les fonctionnalités. Par où commencer ?
|
||||||
|
bmad-help Quelles sont mes options pour le design UX ?
|
||||||
|
bmad-help Je suis bloqué sur le workflow PRD
|
||||||
|
bmad-help Montre-moi ce qui a été fait jusqu'à maintenant
|
||||||
|
```
|
||||||
|
|
||||||
|
BMad-Help répond avec :
|
||||||
|
- Ce qui est recommandé pour votre situation
|
||||||
|
- Quelle est la première tâche requise
|
||||||
|
- À quoi ressemble le reste du processus
|
||||||
|
|
||||||
|
## Quand utiliser ce guide
|
||||||
|
|
||||||
|
Utilisez cette section lorsque :
|
||||||
|
- Vous souhaitez comprendre l'architecture ou les éléments internes de BMad
|
||||||
|
- Vous avez besoin de réponses au-delà de ce que BMad-Help fournit
|
||||||
|
- Vous faites des recherches sur BMad avant l'installation
|
||||||
|
- Vous souhaitez explorer le code source directement
|
||||||
|
|
||||||
|
## Étapes
|
||||||
|
|
||||||
|
### 1. Choisissez votre source
|
||||||
|
|
||||||
|
| Source | Idéal pour | Exemples |
|
||||||
|
|-------------------------|------------------------------------------------------|---------------------------------------|
|
||||||
|
| **Dossier `_bmad`** | Comment fonctionne BMad — agents, workflows, prompts | "Que fait l'agent Analyste ?" |
|
||||||
|
| **Repo GitHub complet** | Historique, installateur, architecture | "Qu'est-ce qui a changé dans la v6 ?" |
|
||||||
|
| **`llms-full.txt`** | Aperçu rapide depuis la documentation | "Expliquez les quatre phases de BMad" |
|
||||||
|
|
||||||
|
Le dossier `_bmad` est créé lorsque vous installez BMad. Si vous ne l'avez pas encore, clonez le repo à la place.
|
||||||
|
|
||||||
|
### 2. Pointez votre IA vers la source
|
||||||
|
|
||||||
|
**Si votre IA peut lire des fichiers (Claude Code, Cursor, etc.) :**
|
||||||
|
|
||||||
|
- **BMad installé :** Pointez vers le dossier `_bmad` et posez vos questions directement
|
||||||
|
- **Vous voulez plus de contexte :** Clonez le [repo complet](https://github.com/bmad-code-org/BMAD-METHOD)
|
||||||
|
|
||||||
|
**Si vous utilisez ChatGPT ou Claude.ai (LLM en ligne) :**
|
||||||
|
|
||||||
|
Importez `llms-full.txt` dans votre session :
|
||||||
|
|
||||||
|
```text
|
||||||
|
https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
### 3. Posez votre question
|
||||||
|
|
||||||
|
:::note[Exemple]
|
||||||
|
**Q :** "Quel est le moyen le plus rapide de construire quelque chose avec BMad ?"
|
||||||
|
|
||||||
|
**R :** Utilisez le workflow Quick Dev : Lancez `bmad-quick-dev` — il clarifie votre intention, planifie, implémente, révise et présente les résultats dans un seul workflow, en sautant les phases de planification complètes.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Ce que vous obtenez
|
||||||
|
|
||||||
|
Des réponses directes sur BMad — comment fonctionnent les agents, ce que font les workflows, pourquoi les choses sont structurées ainsi — sans attendre la réponse de quelqu'un.
|
||||||
|
|
||||||
|
## Conseils
|
||||||
|
|
||||||
|
- **Vérifiez les réponses surprenantes** — Les LLM font parfois des erreurs. Consultez le fichier source ou posez la question sur Discord.
|
||||||
|
- **Soyez précis** — "Que fait l'étape 3 du workflow PRD ?" est mieux que "Comment fonctionne le PRD ?"
|
||||||
|
|
||||||
|
## Toujours bloqué ?
|
||||||
|
|
||||||
|
Avez-vous essayé l'approche LLM et avez encore besoin d'aide ? Vous avez maintenant une bien meilleure question à poser.
|
||||||
|
|
||||||
|
| Canal | Utilisé pour |
|
||||||
|
| ------------------------- | ------------------------------------------- |
|
||||||
|
| `#bmad-method-help` | Questions rapides (chat en temps réel) |
|
||||||
|
| Forum `help-requests` | Questions détaillées (recherchables, persistants) |
|
||||||
|
| `#suggestions-feedback` | Idées et demandes de fonctionnalités |
|
||||||
|
| `#report-bugs-and-issues` | Rapports de bugs |
|
||||||
|
|
||||||
|
**Discord :** [discord.gg/gk8jAdXWmj](https://discord.gg/gk8jAdXWmj)
|
||||||
|
|
||||||
|
**GitHub Issues :** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) (pour les bugs clairs)
|
||||||
|
|
||||||
|
*Toi !*
|
||||||
|
*Bloqué*
|
||||||
|
*dans la file d'attente—*
|
||||||
|
*qui*
|
||||||
|
*attends-tu ?*
|
||||||
|
|
||||||
|
*La source*
|
||||||
|
*est là,*
|
||||||
|
*facile à voir !*
|
||||||
|
|
||||||
|
*Pointez*
|
||||||
|
*votre machine.*
|
||||||
|
*Libérez-la.*
|
||||||
|
|
||||||
|
*Elle lit.*
|
||||||
|
*Elle parle.*
|
||||||
|
*Demandez—*
|
||||||
|
|
||||||
|
*Pourquoi attendre*
|
||||||
|
*demain*
|
||||||
|
*quand tu as déjà*
|
||||||
|
*cette journée ?*
|
||||||
|
|
||||||
|
*—Claude*
|
||||||
|
|
@ -0,0 +1,116 @@
|
||||||
|
---
|
||||||
|
title: "Comment installer BMad"
|
||||||
|
description: Guide étape par étape pour installer BMad dans votre projet
|
||||||
|
sidebar:
|
||||||
|
order: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez la commande `npx bmad-method install` pour configurer BMad dans votre projet avec votre choix de modules et d'outils d'IA.
|
||||||
|
|
||||||
|
Si vous souhaitez utiliser un installateur non interactif et fournir toutes les options d'installation en ligne de commande, consultez [ce guide](./non-interactive-installation.md).
|
||||||
|
|
||||||
|
## Quand l'utiliser
|
||||||
|
|
||||||
|
- Démarrer un nouveau projet avec BMad
|
||||||
|
- Ajouter BMad à une base de code existante
|
||||||
|
- Mettre à jour une installation BMad existante
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- **Node.js** 20+ (requis pour l'installateur)
|
||||||
|
- **Git** (recommandé)
|
||||||
|
- **Outil d'IA** (Claude Code, Cursor, ou similaire)
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Étapes
|
||||||
|
|
||||||
|
### 1. Lancer l'installateur
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install
|
||||||
|
```
|
||||||
|
|
||||||
|
:::tip[Vous voulez la dernière version préliminaire ?]
|
||||||
|
Utilisez le dist-tag `next` :
|
||||||
|
```bash
|
||||||
|
npx bmad-method@next install
|
||||||
|
```
|
||||||
|
|
||||||
|
Cela vous permet d'obtenir les nouvelles modifications plus tôt, avec un risque plus élevé de changements que l'installation par défaut.
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::tip[Version de développement]
|
||||||
|
Pour installer la dernière version depuis la branche main (peut être instable) :
|
||||||
|
```bash
|
||||||
|
npx github:bmad-code-org/BMAD-METHOD install
|
||||||
|
```
|
||||||
|
:::
|
||||||
|
|
||||||
|
### 2. Choisir l'emplacement d'installation
|
||||||
|
|
||||||
|
L'installateur vous demandera où installer les fichiers BMad :
|
||||||
|
|
||||||
|
- Répertoire courant (recommandé pour les nouveaux projets si vous avez créé le répertoire vous-même et l'exécutez depuis ce répertoire)
|
||||||
|
- Chemin personnalisé
|
||||||
|
|
||||||
|
### 3. Sélectionner vos outils d'IA
|
||||||
|
|
||||||
|
Choisissez les outils d'IA que vous utilisez :
|
||||||
|
|
||||||
|
- Claude Code
|
||||||
|
- Cursor
|
||||||
|
- Autres
|
||||||
|
|
||||||
|
Chaque outil a sa propre façon d'intégrer les skills. L'installateur crée de petits fichiers de prompt pour activer les workflows et les agents — il les place simplement là où votre outil s'attend à les trouver.
|
||||||
|
|
||||||
|
:::note[Activer les skills]
|
||||||
|
Certaines plateformes nécessitent que les skills soient explicitement activés dans les paramètres avant d'apparaître. Si vous installez BMad et ne voyez pas les skills, vérifiez les paramètres de votre plateforme ou demandez à votre assistant IA comment activer les skills.
|
||||||
|
:::
|
||||||
|
|
||||||
|
### 4. Choisir les modules
|
||||||
|
|
||||||
|
L'installateur affiche les modules disponibles. Sélectionnez ceux dont vous avez besoin — la plupart des utilisateurs veulent simplement **méthode BMad** (le module de développement logiciel).
|
||||||
|
|
||||||
|
### 5. Suivre les instructions
|
||||||
|
|
||||||
|
L'installateur vous guide pour le reste — contenu personnalisé, paramètres, etc.
|
||||||
|
|
||||||
|
## Ce que vous obtenez
|
||||||
|
|
||||||
|
```text
|
||||||
|
votre-projet/
|
||||||
|
├── _bmad/
|
||||||
|
│ ├── bmm/ # Vos modules sélectionnés
|
||||||
|
│ │ └── config.yaml # Paramètres du module (si vous devez les modifier)
|
||||||
|
│ ├── core/ # Module core requis
|
||||||
|
│ └── ...
|
||||||
|
├── _bmad-output/ # Artefacts générés
|
||||||
|
├── .claude/ # Skills Claude Code (si vous utilisez Claude Code)
|
||||||
|
│ └── skills/
|
||||||
|
│ ├── bmad-help/
|
||||||
|
│ ├── bmad-persona/
|
||||||
|
│ └── ...
|
||||||
|
└── .cursor/ # Skills Cursor (si vous utilisez Cursor)
|
||||||
|
└── skills/
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
|
||||||
|
## Vérifier l'installation
|
||||||
|
|
||||||
|
Exécutez `bmad-help` pour vérifier que tout fonctionne et voir quoi faire ensuite.
|
||||||
|
|
||||||
|
**BMad-Help est votre guide intelligent** qui va :
|
||||||
|
- Confirmer que votre installation fonctionne
|
||||||
|
- Afficher ce qui est disponible en fonction de vos modules installés
|
||||||
|
- Recommander votre première étape
|
||||||
|
|
||||||
|
Vous pouvez aussi lui poser des questions :
|
||||||
|
```
|
||||||
|
bmad-help Je viens d'installer, que dois-je faire en premier ?
|
||||||
|
bmad-help Quelles sont mes options pour un projet SaaS ?
|
||||||
|
```
|
||||||
|
|
||||||
|
## Résolution de problèmes
|
||||||
|
|
||||||
|
**L'installateur affiche une erreur** — Copiez-collez la sortie dans votre assistant IA et laissez-le résoudre le problème.
|
||||||
|
|
||||||
|
**L'installateur a fonctionné mais quelque chose ne fonctionne pas plus tard** — Votre IA a besoin du contexte BMad pour vous aider. Consultez [Comment obtenir des réponses à propos de BMad](./get-answers-about-bmad.md) pour savoir comment diriger votre IA vers les bonnes sources.
|
||||||
|
|
@ -0,0 +1,184 @@
|
||||||
|
---
|
||||||
|
title: Installation non-interactive
|
||||||
|
description: Installer BMad en utilisant des options de ligne de commande pour les pipelines CI/CD et les déploiements automatisés
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez les options de ligne de commande pour installer BMad de manière non-interactive. Cela est utile pour :
|
||||||
|
|
||||||
|
## Quand utiliser cette méthode
|
||||||
|
|
||||||
|
- Déploiements automatisés et pipelines CI/CD
|
||||||
|
- Installations scriptées
|
||||||
|
- Installations par lots sur plusieurs projets
|
||||||
|
- Installations rapides avec des configurations connues
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
Nécessite [Node.js](https://nodejs.org) v20+ et `npx` (inclus avec npm).
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Options disponibles
|
||||||
|
|
||||||
|
### Options d'installation
|
||||||
|
|
||||||
|
| Option | Description | Exemple |
|
||||||
|
|------|-------------|---------|
|
||||||
|
| `--directory <chemin>` | Répertoire d'installation | `--directory ~/projects/myapp` |
|
||||||
|
| `--modules <modules>` | IDs de modules séparés par des virgules | `--modules bmm,bmb` |
|
||||||
|
| `--tools <outils>` | IDs d'outils/IDE séparés par des virgules (utilisez `none` pour ignorer) | `--tools claude-code,cursor` ou `--tools none` |
|
||||||
|
| `--custom-content <chemins>` | Chemins vers des modules personnalisés séparés par des virgules | `--custom-content ~/my-module,~/another-module` |
|
||||||
|
| `--action <type>` | Action pour les installations existantes : `install` (par défaut), `update`, ou `quick-update` | `--action quick-update` |
|
||||||
|
|
||||||
|
### Configuration principale
|
||||||
|
|
||||||
|
| Option | Description | Par défaut |
|
||||||
|
|------|-------------|---------|
|
||||||
|
| `--user-name <nom>` | Nom à utiliser par les agents | Nom d'utilisateur système |
|
||||||
|
| `--communication-language <langue>` | Langue de communication des agents | Anglais |
|
||||||
|
| `--document-output-language <langue>` | Langue de sortie des documents | Anglais |
|
||||||
|
| `--output-folder <chemin>` | Chemin du dossier de sortie (voir les règles de résolution ci-dessous) | `_bmad-output` |
|
||||||
|
|
||||||
|
#### Résolution du chemin du dossier de sortie
|
||||||
|
|
||||||
|
La valeur passée à `--output-folder` (ou saisie de manière interactive) est résolue selon ces règles :
|
||||||
|
|
||||||
|
| Type d'entrée | Exemple | Résolu comme |
|
||||||
|
|-------------------------------|----------------------------|--------------------------------------------------------------|
|
||||||
|
| Chemin relatif (par défaut) | `_bmad-output` | `<racine-du-projet>/_bmad-output` |
|
||||||
|
| Chemin relatif avec traversée | `../../shared-outputs` | Chemin absolu normalisé — ex. `/Users/me/shared-outputs` |
|
||||||
|
| Chemin absolu | `/Users/me/shared-outputs` | Utilisé tel quel — la racine du projet n'est **pas** ajoutée |
|
||||||
|
|
||||||
|
Le chemin résolu est ce que les agents et les workflows vont utiliser lors de l'écriture des fichiers de sortie. L'utilisation d'un chemin absolu ou d'un chemin relatif avec traversée vous permet de diriger tous les artefacts générés vers un répertoire en dehors de l'arborescence de votre projet — utile pour les configurations partagées ou les monorepos.
|
||||||
|
|
||||||
|
### Autres options
|
||||||
|
|
||||||
|
| Option | Description |
|
||||||
|
|------|-------------|
|
||||||
|
| `-y, --yes` | Accepter tous les paramètres par défaut et ignorer les invites |
|
||||||
|
| `-d, --debug` | Activer la sortie de débogage pour la génération du manifeste |
|
||||||
|
|
||||||
|
## IDs de modules
|
||||||
|
|
||||||
|
IDs de modules disponibles pour l’option `--modules` :
|
||||||
|
|
||||||
|
- `bmm` — méthode BMad Master
|
||||||
|
- `bmb` — BMad Builder
|
||||||
|
|
||||||
|
Consultez le [registre BMad](https://github.com/bmad-code-org) pour les modules externes disponibles.
|
||||||
|
|
||||||
|
## IDs d'outils/IDE
|
||||||
|
|
||||||
|
IDs d'outils disponibles pour l’option `--tools` :
|
||||||
|
|
||||||
|
**Recommandés :** `claude-code`, `cursor`
|
||||||
|
|
||||||
|
Exécutez `npx bmad-method install` de manière interactive une fois pour voir la liste complète actuelle des outils pris en charge, ou consultez la [configuration des codes de la plateforme](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/installer/ide/platform-codes.yaml).
|
||||||
|
|
||||||
|
## Modes d'installation
|
||||||
|
|
||||||
|
| Mode | Description | Exemple |
|
||||||
|
|------|-------------|---------|
|
||||||
|
| Entièrement non-interactif | Fournir toutes les options pour ignorer toutes les invites | `npx bmad-method install --directory . --modules bmm --tools claude-code --yes` |
|
||||||
|
| Semi-interactif | Fournir certains options ; BMad demande les autres | `npx bmad-method install --directory . --modules bmm` |
|
||||||
|
| Paramètres par défaut uniquement | Accepter tous les paramètres par défaut avec `-y` | `npx bmad-method install --yes` |
|
||||||
|
| Sans outils | Ignorer la configuration des outils/IDE | `npx bmad-method install --modules bmm --tools none` |
|
||||||
|
|
||||||
|
## Exemples
|
||||||
|
|
||||||
|
### Installation dans un pipeline CI/CD
|
||||||
|
|
||||||
|
```bash
|
||||||
|
#!/bin/bash
|
||||||
|
# install-bmad.sh
|
||||||
|
|
||||||
|
npx bmad-method install \
|
||||||
|
--directory "${GITHUB_WORKSPACE}" \
|
||||||
|
--modules bmm \
|
||||||
|
--tools claude-code \
|
||||||
|
--user-name "CI Bot" \
|
||||||
|
--communication-language Français \
|
||||||
|
--document-output-language Français \
|
||||||
|
--output-folder _bmad-output \
|
||||||
|
--yes
|
||||||
|
```
|
||||||
|
|
||||||
|
### Mettre à jour une installation existante
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install \
|
||||||
|
--directory ~/projects/myapp \
|
||||||
|
--action update \
|
||||||
|
--modules bmm,bmb,custom-module
|
||||||
|
```
|
||||||
|
|
||||||
|
### Mise à jour rapide (conserver les paramètres)
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install \
|
||||||
|
--directory ~/projects/myapp \
|
||||||
|
--action quick-update
|
||||||
|
```
|
||||||
|
|
||||||
|
### Installation avec du contenu personnalisé
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install \
|
||||||
|
--directory ~/projects/myapp \
|
||||||
|
--modules bmm \
|
||||||
|
--custom-content ~/my-custom-module,~/another-module \
|
||||||
|
--tools claude-code
|
||||||
|
```
|
||||||
|
|
||||||
|
## Ce que vous obtenez
|
||||||
|
|
||||||
|
- Un répertoire `_bmad/` entièrement configuré dans votre projet
|
||||||
|
- Des agents et des flux de travail configurés pour vos modules et outils sélectionnés
|
||||||
|
- Un dossier `_bmad-output/` pour les artefacts générés
|
||||||
|
|
||||||
|
## Validation et gestion des erreurs
|
||||||
|
|
||||||
|
BMad valide toutes les options fournis :
|
||||||
|
|
||||||
|
- **Directory** — Doit être un chemin valide avec des permissions d'écriture
|
||||||
|
- **Modules** — Avertit des IDs de modules invalides (mais n'échoue pas)
|
||||||
|
- **Tools** — Avertit des IDs d'outils invalides (mais n'échoue pas)
|
||||||
|
- **Custom Content** — Chaque chemin doit contenir un fichier `module.yaml` valide
|
||||||
|
- **Action** — Doit être l'une des suivantes : `install`, `update`, `quick-update`
|
||||||
|
|
||||||
|
Les valeurs invalides entraîneront soit :
|
||||||
|
1. L’affichage d’un message d'erreur suivi d’un exit (pour les options critiques comme le répertoire)
|
||||||
|
2. Un avertissement puis la continuation de l’installation (pour les éléments optionnels comme le contenu personnalisé)
|
||||||
|
3. Un retour aux invites interactives (pour les valeurs requises manquantes)
|
||||||
|
|
||||||
|
:::tip[Bonnes pratiques]
|
||||||
|
- Utilisez des chemins absolus pour `--directory` pour éviter toute ambiguïté
|
||||||
|
- Utilisez un chemin absolu pour `--output-folder` lorsque vous souhaitez que les artefacts soient écrits en dehors de l'arborescence du projet (ex. un répertoire de sorties partagé dans un monorepo)
|
||||||
|
- Testez les options localement avant de les utiliser dans des pipelines CI/CD
|
||||||
|
- Combinez avec `-y` pour des installations vraiment sans surveillance
|
||||||
|
- Utilisez `--debug` si vous rencontrez des problèmes lors de l'installation
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Résolution des problèmes
|
||||||
|
|
||||||
|
### L'installation échoue avec "Invalid directory"
|
||||||
|
|
||||||
|
- Le chemin du répertoire doit exister (ou son parent doit exister)
|
||||||
|
- Vous avez besoin des permissions d'écriture
|
||||||
|
- Le chemin doit être absolu ou correctement relatif au répertoire actuel
|
||||||
|
|
||||||
|
### Module non trouvé
|
||||||
|
|
||||||
|
- Vérifiez que l'ID du module est correct
|
||||||
|
- Les modules externes doivent être disponibles dans le registre
|
||||||
|
|
||||||
|
### Chemin de contenu personnalisé invalide
|
||||||
|
|
||||||
|
Assurez-vous que chaque chemin de contenu personnalisé :
|
||||||
|
- Pointe vers un répertoire
|
||||||
|
- Contient un fichier `module.yaml` à la racine
|
||||||
|
- Possède un champ `code` dans `module.yaml`
|
||||||
|
|
||||||
|
:::note[Toujours bloqué ?]
|
||||||
|
Exécutez avec `--debug` pour une sortie détaillée, essayez le mode interactif pour isoler le problème, ou signalez-le à <https://github.com/bmad-code-org/BMAD-METHOD/issues>.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,127 @@
|
||||||
|
---
|
||||||
|
title: "Gérer le contexte du projet"
|
||||||
|
description: Créer et maintenir project-context.md pour guider les agents IA
|
||||||
|
sidebar:
|
||||||
|
order: 8
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez le fichier `project-context.md` pour garantir que les agents IA respectent les préférences techniques et les règles d'implémentation de votre projet tout au long des workflows. Pour vous assurer qu'il est toujours disponible, vous pouvez également ajouter la ligne `Le contexte et les conventions importantes du projet se trouvent dans [chemin vers le contexte du projet]/project-context.md` à votre fichier de contexte ou de règles permanentes (comme `AGENTS.md`).
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- Méthode BMad installée
|
||||||
|
- Connaissance de la pile technologique et des conventions de votre projet
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Quand utiliser cette fonctionnalité
|
||||||
|
|
||||||
|
- Vous avez des préférences techniques fortes avant de commencer l'architecture
|
||||||
|
- Vous avez terminé l'architecture et souhaitez consigner les décisions pour l'implémentation
|
||||||
|
- Vous travaillez sur une base de code existante avec des patterns établis
|
||||||
|
- Vous remarquez que les agents prennent des décisions incohérentes entre les stories
|
||||||
|
|
||||||
|
## Étape 1 : Choisissez votre approche
|
||||||
|
|
||||||
|
**Création manuelle** — Idéal lorsque vous savez exactement quelles règles vous souhaitez documenter
|
||||||
|
|
||||||
|
**Génération après l'architecture** — Idéal pour capturer les décisions prises lors du solutioning
|
||||||
|
|
||||||
|
**Génération pour les projets existants** — Idéal pour découvrir les patterns dans les bases de code existantes
|
||||||
|
|
||||||
|
## Étape 2 : Créez le fichier
|
||||||
|
|
||||||
|
### Option A : Création manuelle
|
||||||
|
|
||||||
|
Créez le fichier à l'emplacement `_bmad-output/project-context.md` :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
mkdir -p _bmad-output
|
||||||
|
touch _bmad-output/project-context.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Ajoutez votre pile technologique et vos règles d'implémentation :
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
---
|
||||||
|
project_name: 'MonProjet'
|
||||||
|
user_name: 'VotreNom'
|
||||||
|
date: '2026-02-15'
|
||||||
|
sections_completed: ['technology_stack', 'critical_rules']
|
||||||
|
---
|
||||||
|
|
||||||
|
# Contexte de Projet pour Agents IA
|
||||||
|
|
||||||
|
## Pile Technologique & Versions
|
||||||
|
|
||||||
|
- Node.js 20.x, TypeScript 5.3, React 18.2
|
||||||
|
- State : Zustand
|
||||||
|
- Tests : Vitest, Playwright
|
||||||
|
- Styles : Tailwind CSS
|
||||||
|
|
||||||
|
## Règles d'Implémentation Critiques
|
||||||
|
|
||||||
|
**TypeScript :**
|
||||||
|
- Mode strict activé, pas de types `any`
|
||||||
|
- Utiliser `interface` pour les API publiques, `type` pour les unions
|
||||||
|
|
||||||
|
**Organisation du Code :**
|
||||||
|
- Composants dans `/src/components/` avec tests co-localisés
|
||||||
|
- Les appels API utilisent le singleton `apiClient` — jamais de fetch direct
|
||||||
|
|
||||||
|
**Tests :**
|
||||||
|
- Tests unitaires axés sur la logique métier
|
||||||
|
- Tests d'intégration utilisent MSW pour le mock API
|
||||||
|
```
|
||||||
|
|
||||||
|
### Option B : Génération après l'architecture
|
||||||
|
|
||||||
|
Exécutez le workflow dans une nouvelle conversation :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Le workflow analyse votre document d'architecture et vos fichiers projet pour générer un fichier de contexte qui capture les décisions prises.
|
||||||
|
|
||||||
|
### Option C : Génération pour les projets existants
|
||||||
|
|
||||||
|
Pour les projets existants, exécutez :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
bmad-generate-project-context
|
||||||
|
```
|
||||||
|
|
||||||
|
Le workflow analyse votre base de code pour identifier les conventions, puis génère un fichier de contexte que vous pouvez réviser et affiner.
|
||||||
|
|
||||||
|
## Étape 3 : Vérifiez le contenu
|
||||||
|
|
||||||
|
Révisez le fichier généré et assurez-vous qu'il capture :
|
||||||
|
|
||||||
|
- Les versions correctes des technologies
|
||||||
|
- Vos conventions réelles (pas les bonnes pratiques génériques)
|
||||||
|
- Les règles qui évitent les erreurs courantes
|
||||||
|
- Les patterns spécifiques aux frameworks
|
||||||
|
|
||||||
|
Modifiez manuellement pour ajouter les éléments manquants ou supprimer les inexactitudes.
|
||||||
|
|
||||||
|
## Ce que vous obtenez
|
||||||
|
|
||||||
|
Un fichier `project-context.md` qui :
|
||||||
|
|
||||||
|
- Garantit que tous les agents suivent les mêmes conventions
|
||||||
|
- Évite les décisions incohérentes entre les stories
|
||||||
|
- Capture les décisions d'architecture pour l'implémentation
|
||||||
|
- Sert de référence pour les patterns et règles de votre projet
|
||||||
|
|
||||||
|
## Conseils
|
||||||
|
|
||||||
|
:::tip[Bonnes pratiques]
|
||||||
|
- **Concentrez-vous sur ce qui n'est pas évident** — Documentez les patterns que les agents pourraient manquer (par ex. « Utiliser JSDoc sur chaque classe publique »), et non les pratiques universelles comme « utiliser des noms de variables significatifs ».
|
||||||
|
- **Gardez-le concis** — Ce fichier est chargé par chaque workflow d'implémentation. Les fichiers longs gaspillent le contexte. Excluez le contenu qui ne s'applique qu'à un périmètre restreint ou à des stories spécifiques.
|
||||||
|
- **Mettez à jour si nécessaire** — Modifiez manuellement lorsque les patterns changent, ou régénérez après des changements d'architecture significatifs.
|
||||||
|
- Fonctionne aussi bien pour Quick Dev que pour les projets complets méthode BMad.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Prochaines étapes
|
||||||
|
|
||||||
|
- [**Explication du contexte projet**](../explanation/project-context.md) — En savoir plus sur son fonctionnement
|
||||||
|
- [**Carte des workflows**](../reference/workflow-map.md) — Voir quels workflows chargent le contexte projet
|
||||||
|
|
@ -0,0 +1,98 @@
|
||||||
|
---
|
||||||
|
title: "Corrections Rapides"
|
||||||
|
description: Comment effectuer des corrections rapides et des modifications ciblées
|
||||||
|
sidebar:
|
||||||
|
order: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez **Quick Dev** pour les corrections de bugs, les refactorisations ou les petites modifications ciblées qui ne nécessitent pas la méthode BMad complète.
|
||||||
|
|
||||||
|
## Quand Utiliser Cette Approche
|
||||||
|
|
||||||
|
- Corrections de bugs avec une cause claire et connue
|
||||||
|
- Petites refactorisations (renommage, extraction, restructuration) contenues dans quelques fichiers
|
||||||
|
- Ajustements mineurs de fonctionnalités ou modifications de configuration
|
||||||
|
- Mises à jour de dépendances
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- Méthode BMad installée (`npx bmad-method install`)
|
||||||
|
- Un IDE IA (Claude Code, Cursor, ou similaire)
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Étapes
|
||||||
|
|
||||||
|
### 1. Démarrer une Nouvelle Conversation
|
||||||
|
|
||||||
|
Ouvrez une **nouvelle conversation** dans votre IDE IA. Réutiliser une session d'un workflow précédent peut causer des conflits de contexte.
|
||||||
|
|
||||||
|
### 2. Spécifiez Votre Intention
|
||||||
|
|
||||||
|
Quick Dev accepte l'intention en forme libre — avant, avec, ou après l'invocation. Exemples :
|
||||||
|
|
||||||
|
```text
|
||||||
|
quick-dev — Corrige le bug de validation de connexion qui permet les mots de passe vides.
|
||||||
|
```
|
||||||
|
|
||||||
|
```text
|
||||||
|
quick-dev — corrige https://github.com/org/repo/issues/42
|
||||||
|
```
|
||||||
|
|
||||||
|
```text
|
||||||
|
quick-dev — implémente _bmad-output/implementation-artifacts/my-intent.md
|
||||||
|
```
|
||||||
|
|
||||||
|
```text
|
||||||
|
Je pense que le problème est dans le middleware d'auth, il ne vérifie pas l'expiration du token.
|
||||||
|
Regardons... oui, src/auth/middleware.ts ligne 47 saute complètement la vérification exp. lance quick-dev
|
||||||
|
```
|
||||||
|
|
||||||
|
```text
|
||||||
|
quick-dev
|
||||||
|
> Que voulez-vous faire ?
|
||||||
|
Refactoriser UserService pour utiliser async/await au lieu des callbacks.
|
||||||
|
```
|
||||||
|
|
||||||
|
Texte brut, chemins de fichiers, URLs d'issues GitHub, liens de trackers de bugs — tout ce que le LLM peut résoudre en une intention concrète.
|
||||||
|
|
||||||
|
### 3. Répondre aux Questions et Approuver
|
||||||
|
|
||||||
|
Quick Dev peut poser des questions de clarification ou présenter une courte spécification demandant votre approbation avant l'implémentation. Répondez à ses questions et approuvez lorsque vous êtes satisfait du plan.
|
||||||
|
|
||||||
|
### 4. Réviser et Pousser
|
||||||
|
|
||||||
|
Quick Dev implémente la modification, révise son propre travail, corrige les problèmes et effectue un commit local. Lorsqu'il a terminé, il ouvre les fichiers affectés dans votre éditeur.
|
||||||
|
|
||||||
|
- Parcourez le diff pour confirmer que la modification correspond à votre intention
|
||||||
|
- Si quelque chose semble incorrect, dites à l'agent ce qu'il faut corriger — il peut itérer dans la même session
|
||||||
|
|
||||||
|
Une fois satisfait, poussez le commit. Quick Dev vous proposera de pousser et de créer une PR pour vous.
|
||||||
|
|
||||||
|
:::caution[Si Quelque Chose Casse]
|
||||||
|
Si une modification poussée cause des problèmes inattendus, utilisez `git revert HEAD` pour annuler proprement le dernier commit. Ensuite, démarrez une nouvelle conversation et exécutez Quick Dev à nouveau pour essayer une approche différente.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Ce Que Vous Obtenez
|
||||||
|
|
||||||
|
- Fichiers source modifiés avec la correction ou refactorisation appliquée
|
||||||
|
- Tests passants (si votre projet a une suite de tests)
|
||||||
|
- Un commit prêt à pousser avec un message de commit conventionnel
|
||||||
|
|
||||||
|
## Travail Différé
|
||||||
|
|
||||||
|
Quick Dev garde chaque exécution concentrée sur un seul objectif. Si votre demande contient plusieurs objectifs indépendants, ou si la revue remonte des problèmes préexistants non liés à votre modification, Quick Dev les diffère vers un fichier (`deferred-work.md` dans votre répertoire d'artefacts d'implémentation) plutôt que d'essayer de tout régler en même temps.
|
||||||
|
|
||||||
|
Consultez ce fichier après une exécution — c'est votre backlog[^1] de choses sur lesquelles revenir. Chaque élément différé peut être introduit dans une nouvelle exécution Quick Dev ultérieurement.
|
||||||
|
|
||||||
|
## Quand Passer à une Planification Formelle
|
||||||
|
|
||||||
|
Envisagez d'utiliser la méthode BMad complète lorsque :
|
||||||
|
|
||||||
|
- La modification affecte plusieurs systèmes ou nécessite des mises à jour coordonnées dans de nombreux fichiers
|
||||||
|
- Vous n'êtes pas sûr de la portée et avez besoin d'une découverte des exigences d'abord
|
||||||
|
- Vous avez besoin de documentation ou de décisions architecturales enregistrées pour l'équipe
|
||||||
|
|
||||||
|
Voir [Quick Dev](../explanation/quick-dev.md) pour plus d'informations sur la façon dont Quick Dev s'intègre dans la méthode BMad.
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: Backlog : liste priorisée de tâches ou d'éléments de travail à traiter ultérieurement, issue des méthodologies agiles.
|
||||||
|
|
@ -0,0 +1,78 @@
|
||||||
|
---
|
||||||
|
title: "Guide de Division de Documents"
|
||||||
|
description: Diviser les fichiers markdown volumineux en fichiers plus petits et organisés pour une meilleure gestion du contexte
|
||||||
|
sidebar:
|
||||||
|
order: 9
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez l'outil `bmad-shard-doc` si vous avez besoin de diviser des fichiers markdown volumineux en fichiers plus petits et organisés pour une meilleure gestion du contexte.
|
||||||
|
|
||||||
|
:::caution[Déprécié]
|
||||||
|
Ceci n'est plus recommandé, et bientôt avec les workflows mis à jour et la plupart des LLM et outils majeurs supportant les sous-processus, cela deviendra inutile.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Quand l’Utiliser
|
||||||
|
|
||||||
|
Utilisez ceci uniquement si vous remarquez que votre combinaison outil / modèle ne parvient pas à charger et lire tous les documents en entrée lorsque c'est nécessaire.
|
||||||
|
|
||||||
|
## Qu'est-ce que la Division de Documents ?
|
||||||
|
|
||||||
|
La division de documents divise les fichiers markdown volumineux en fichiers plus petits et organisés basés sur les titres de niveau 2 (`## Titre`).
|
||||||
|
|
||||||
|
### Architecture
|
||||||
|
|
||||||
|
```text
|
||||||
|
Avant Division :
|
||||||
|
_bmad-output/planning-artifacts/
|
||||||
|
└── PRD.md (fichier volumineux de 50k tokens)
|
||||||
|
|
||||||
|
Après Division :
|
||||||
|
_bmad-output/planning-artifacts/
|
||||||
|
└── prd/
|
||||||
|
├── index.md # Table des matières avec descriptions
|
||||||
|
├── overview.md # Section 1
|
||||||
|
├── user-requirements.md # Section 2
|
||||||
|
├── technical-requirements.md # Section 3
|
||||||
|
└── ... # Sections supplémentaires
|
||||||
|
```
|
||||||
|
|
||||||
|
## Étapes
|
||||||
|
|
||||||
|
### 1. Exécuter l'Outil Shard-Doc
|
||||||
|
|
||||||
|
```bash
|
||||||
|
/bmad-shard-doc
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Suivre le Processus Interactif
|
||||||
|
|
||||||
|
```text
|
||||||
|
Agent : Quel document souhaitez-vous diviser ?
|
||||||
|
Utilisateur : docs/PRD.md
|
||||||
|
|
||||||
|
Agent : Destination par défaut : docs/prd/
|
||||||
|
Accepter la valeur par défaut ? [y/n]
|
||||||
|
Utilisateur : y
|
||||||
|
|
||||||
|
Agent : Division de PRD.md...
|
||||||
|
✓ 12 fichiers de section créés
|
||||||
|
✓ index.md généré
|
||||||
|
✓ Terminé !
|
||||||
|
```
|
||||||
|
|
||||||
|
## Comment Fonctionne la Découverte de Workflow
|
||||||
|
|
||||||
|
Les workflows BMad utilisent un **système de découverte double** :
|
||||||
|
|
||||||
|
1. **Essaye d'abord le document entier** - Rechercher `document-name.md`
|
||||||
|
2. **Vérifie la version divisée** - Rechercher `document-name/index.md`
|
||||||
|
3. **Règle de priorité** - Le document entier a la priorité si les deux existent - supprimez le document entier si vous souhaitez que la version divisée soit utilisée à la place
|
||||||
|
|
||||||
|
## Support des Workflows
|
||||||
|
|
||||||
|
Tous les workflows BMM prennent en charge les deux formats :
|
||||||
|
|
||||||
|
- Documents entiers
|
||||||
|
- Documents divisés
|
||||||
|
- Détection automatique
|
||||||
|
- Transparent pour l'utilisateur
|
||||||
|
|
@ -0,0 +1,106 @@
|
||||||
|
---
|
||||||
|
title: "Comment passer à la v6"
|
||||||
|
description: Migrer de BMad v4 vers v6
|
||||||
|
sidebar:
|
||||||
|
order: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
Utilisez l'installateur BMad pour passer de la v4 à la v6, qui inclut une détection automatique des installations existantes et une assistance à la migration.
|
||||||
|
|
||||||
|
## Quand utiliser ce guide
|
||||||
|
|
||||||
|
- Vous avez BMad v4 installé (dossier `.bmad-method`)
|
||||||
|
- Vous souhaitez migrer vers la nouvelle architecture v6
|
||||||
|
- Vous avez des artefacts de planification existants à préserver
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- Node.js 20+
|
||||||
|
- Installation BMad v4 existante
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Étapes
|
||||||
|
|
||||||
|
### 1. Lancer l'installateur
|
||||||
|
|
||||||
|
Suivez les [Instructions d'installation](./install-bmad.md).
|
||||||
|
|
||||||
|
### 2. Gérer l'installation existante
|
||||||
|
|
||||||
|
Quand v4 est détecté, vous pouvez :
|
||||||
|
|
||||||
|
- Autoriser l'installateur à sauvegarder et supprimer `.bmad-method`
|
||||||
|
- Quitter et gérer le nettoyage manuellement
|
||||||
|
|
||||||
|
Si vous avez nommé votre dossier de méthode bmad autrement, vous devrez supprimer le dossier vous-même manuellement.
|
||||||
|
|
||||||
|
### 3. Nettoyer les skills IDE
|
||||||
|
|
||||||
|
Supprimez manuellement les commandes/skills IDE v4 existants - par exemple si vous avez Claude Code, recherchez tous les dossiers imbriqués qui commencent par bmad et supprimez-les :
|
||||||
|
|
||||||
|
- `.claude/commands/`
|
||||||
|
|
||||||
|
Les nouveaux skills v6 sont installés dans :
|
||||||
|
|
||||||
|
- `.claude/skills/`
|
||||||
|
|
||||||
|
### 4. Migrer les artefacts de planification
|
||||||
|
|
||||||
|
**Si vous avez des documents de planification (Brief/PRD/UX/Architecture) :**
|
||||||
|
|
||||||
|
Déplacez-les dans `_bmad-output/planning-artifacts/` avec des noms descriptifs :
|
||||||
|
|
||||||
|
- Incluez `PRD` dans le nom de fichier pour les documents PRD[^1]
|
||||||
|
- Incluez `brief`, `architecture`, ou `ux-design` selon le cas
|
||||||
|
- Les documents divisés peuvent être dans des sous-dossiers nommés
|
||||||
|
|
||||||
|
**Si vous êtes en cours de planification :** Envisagez de redémarrer avec les workflows v6. Utilisez vos documents existants comme entrées - les nouveaux workflows de découverte progressive avec recherche web et mode plan IDE produisent de meilleurs résultats.
|
||||||
|
|
||||||
|
### 5. Migrer le développement en cours
|
||||||
|
|
||||||
|
Si vous avez des stories[^3] créées ou implémentées :
|
||||||
|
|
||||||
|
1. Terminez l'installation v6
|
||||||
|
2. Placez `epics.md` ou `epics/epic*.md`[^2] dans `_bmad-output/planning-artifacts/`
|
||||||
|
3. Lancez le workflow `bmad-sprint-planning`[^4]
|
||||||
|
4. Indiquez quels epics/stories sont déjà terminés
|
||||||
|
|
||||||
|
## Ce que vous obtenez
|
||||||
|
|
||||||
|
**Structure unifiée v6 :**
|
||||||
|
|
||||||
|
```text
|
||||||
|
votre-projet/
|
||||||
|
├── _bmad/ # Dossier d'installation unique
|
||||||
|
│ ├── _config/ # Vos personnalisations
|
||||||
|
│ │ └── agents/ # Fichiers de personnalisation des agents
|
||||||
|
│ ├── core/ # Framework core universel
|
||||||
|
│ ├── bmm/ # Module BMad Method
|
||||||
|
│ ├── bmb/ # BMad Builder
|
||||||
|
│ └── cis/ # Creative Intelligence Suite
|
||||||
|
└── _bmad-output/ # Dossier de sortie (était le dossier doc en v4)
|
||||||
|
```
|
||||||
|
|
||||||
|
## Migration des modules
|
||||||
|
|
||||||
|
| Module v4 | Statut v6 |
|
||||||
|
| ----------------------------- | ----------------------------------------- |
|
||||||
|
| `.bmad-2d-phaser-game-dev` | Intégré dans le Module BMGD |
|
||||||
|
| `.bmad-2d-unity-game-dev` | Intégré dans le Module BMGD |
|
||||||
|
| `.bmad-godot-game-dev` | Intégré dans le Module BMGD |
|
||||||
|
| `.bmad-infrastructure-devops` | Déprécié - nouvel agent DevOps bientôt disponible |
|
||||||
|
| `.bmad-creative-writing` | Non adapté - nouveau module v6 bientôt disponible |
|
||||||
|
|
||||||
|
## Changements clés
|
||||||
|
|
||||||
|
| Concept | v4 | v6 |
|
||||||
|
| ------------- | ------------------------------------- | ------------------------------------ |
|
||||||
|
| **Core** | `_bmad-core` était en fait la méthode BMad | `_bmad/core/` est le framework universel |
|
||||||
|
| **Method** | `_bmad-method` | `_bmad/bmm/` |
|
||||||
|
| **Config** | Fichiers modifiés directement | `config.yaml` par module |
|
||||||
|
| **Documents** | Division ou non division requise | Entièrement flexible, scan automatique |
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
[^1]: PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d'aligner les équipes sur ce qui doit être construit et pourquoi.
|
||||||
|
[^2]: Epic : dans les méthodologies agiles, une grande unité de travail qui peut être décomposée en plusieurs stories. Un epic représente généralement une fonctionnalité majeure ou un ensemble de capacités livrable sur plusieurs sprints.
|
||||||
|
[^3]: Story (User Story) : une description courte et simple d'une fonctionnalité du point de vue de l'utilisateur. Les stories sont des unités de travail suffisamment petites pour être complétées en un sprint.
|
||||||
|
[^4]: Sprint : dans Scrum, une période de temps fixe (généralement 1 à 4 semaines) pendant laquelle l'équipe travaille à livrer un incrément de produit potentiellement libérable.
|
||||||
|
|
@ -0,0 +1,69 @@
|
||||||
|
---
|
||||||
|
title: Bienvenue dans la méthode BMad
|
||||||
|
description: Framework de développement propulsé par l'IA avec des agents spécialisés, des workflows guidés et une planification intelligente
|
||||||
|
---
|
||||||
|
|
||||||
|
La méthode BMad (**B**uild **M**ore **A**rchitect **D**reams) est un module[^1] de développement assisté par l'IA au sein de l'écosystème BMad, conçu pour vous faciliter la création de logiciels par un processus complet, de l'idéation et de la planification jusqu'à l'implémentation agentique. Elle fournit des agents[^2] IA spécialisés, des workflows guidés et une planification intelligente qui s'adapte à la complexité de votre projet, que vous corrigiez un bug ou construisiez une plateforme d'entreprise.
|
||||||
|
|
||||||
|
Si vous êtes à l'aise avec les assistants de codage IA comme Claude, Cursor ou GitHub Copilot, vous êtes prêt à commencer.
|
||||||
|
|
||||||
|
:::note[🚀 La V6 est là et ce n'est que le début !]
|
||||||
|
Architecture par Skills, BMad Builder v1, automatisation Dev Loop, et bien plus encore en préparation. **[Consultez la Feuille de route →](./roadmap)**
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Première visite ? Commencez par un tutoriel
|
||||||
|
|
||||||
|
La façon la plus rapide de comprendre BMad est de l'essayer.
|
||||||
|
|
||||||
|
- **[Premiers pas avec BMad](./tutorials/getting-started.md)** — Installez et comprenez comment fonctionne BMad
|
||||||
|
- **[Carte des workflows](./reference/workflow-map.md)** — Vue d'ensemble visuelle des phases BMM, des workflows et de la gestion du contexte
|
||||||
|
|
||||||
|
:::tip[Envie de plonger directement ?]
|
||||||
|
Installez BMad et utilisez le skill[^3] `bmad-help` — il vous guidera entièrement en fonction de votre projet et de vos modules installés.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Comment utiliser cette documentation
|
||||||
|
|
||||||
|
Cette documentation est organisée en quatre sections selon ce que vous essayez de faire :
|
||||||
|
|
||||||
|
| Section | Objectif |
|
||||||
|
| ----------------- | ----------------------------------------------------------------------------------------------------------- |
|
||||||
|
| **Tutoriels** | Orientés apprentissage. Guides étape par étape qui vous accompagnent dans la construction de quelque chose. Commencez ici si vous êtes nouveau. |
|
||||||
|
| **Guides pratiques** | Orientés tâches. Guides pratiques pour résoudre des problèmes spécifiques. « Comment personnaliser un agent ? » se trouve ici. |
|
||||||
|
| **Explication** | Orientés compréhension. Explications en profondeur des concepts et de l'architecture. À lire quand vous voulez savoir *pourquoi*. |
|
||||||
|
| **Référence** | Orientés information. Spécifications techniques pour les agents, workflows et configuration. |
|
||||||
|
|
||||||
|
## Étendre et personnaliser
|
||||||
|
|
||||||
|
Vous souhaitez étendre BMad avec vos propres agents, workflows ou modules ? Le **[BMad Builder](https://bmad-builder-docs.bmad-method.org/)** fournit le framework et les outils pour créer des extensions personnalisées, que vous ajoutiez de nouvelles capacités à BMad ou que vous construisiez des modules entièrement nouveaux à partir de zéro.
|
||||||
|
|
||||||
|
## Ce dont vous aurez besoin
|
||||||
|
|
||||||
|
BMad fonctionne avec tout assistant de codage IA qui prend en charge les prompts système personnalisés ou le contexte de projet. Les options populaires incluent :
|
||||||
|
|
||||||
|
- **[Claude Code](https://code.claude.com)** — Outil CLI d'Anthropic (recommandé)
|
||||||
|
- **[Cursor](https://cursor.sh)** — Éditeur de code propulsé par l'IA
|
||||||
|
- **[Codex CLI](https://github.com/openai/codex)** — Agent de codage terminal d'OpenAI
|
||||||
|
|
||||||
|
Vous devriez être à l'aise avec les concepts de base du développement logiciel comme le contrôle de version, la structure de projet et les workflows agiles. Aucune expérience préalable avec les systèmes d'agent de type BMad n'est requise — c'est justement le but de cette documentation.
|
||||||
|
|
||||||
|
## Rejoindre la communauté
|
||||||
|
|
||||||
|
Obtenez de l'aide, partagez ce que vous construisez ou contribuez à BMad :
|
||||||
|
|
||||||
|
- **[Discord](https://discord.gg/gk8jAdXWmj)** — Discutez avec d'autres utilisateurs de BMad, posez des questions, partagez des idées
|
||||||
|
- **[GitHub](https://github.com/bmad-code-org/BMAD-METHOD)** — Code source, issues et contributions
|
||||||
|
- **[YouTube](https://www.youtube.com/@BMadCode)** — Tutoriels vidéo et démonstrations
|
||||||
|
|
||||||
|
## Prochaine étape
|
||||||
|
|
||||||
|
Prêt à vous lancer ? **[Commencez avec BMad](./tutorials/getting-started.md)** et construisez votre premier projet.
|
||||||
|
|
||||||
|
---
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: **Module** : composant autonome du système BMad qui peut être installé et utilisé indépendamment, offrant des fonctionnalités spécifiques.
|
||||||
|
|
||||||
|
[^2]: **Agent** : assistant IA spécialisé avec une expertise spécifique qui guide les utilisateurs dans les workflows.
|
||||||
|
|
||||||
|
[^3]: **Skill** : capacité ou fonctionnalité invoquable d'un agent pour effectuer une tâche spécifique.
|
||||||
|
|
@ -0,0 +1,59 @@
|
||||||
|
---
|
||||||
|
title: Agents
|
||||||
|
description: Agents BMM par défaut avec leurs identifiants de skill, déclencheurs de menu et workflows principaux (Analyst, Developer, Architect, UX Designer, Technical Writer)
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
## Agents par défaut
|
||||||
|
|
||||||
|
Cette page liste les cinq agents BMM (suite Agile) par défaut installés avec la méthode BMad, ainsi que leurs identifiants de skill, déclencheurs de menu et workflows principaux. Chaque agent est invoqué en tant que skill.
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
|
||||||
|
- Chaque agent est disponible en tant que skill, généré par l’installateur. L’identifiant de skill (par exemple, `bmad-analyst`) est utilisé pour invoquer l’agent.
|
||||||
|
- Les déclencheurs sont les codes courts de menu (par exemple, `BP`) et les correspondances approximatives affichés dans chaque menu d’agent.
|
||||||
|
- La génération de tests QA est gérée par le skill de workflow `bmad-qa-generate-e2e-tests`. L’architecte de tests complet (TEA) se trouve dans son propre module.
|
||||||
|
|
||||||
|
| Agent | Identifiant de skill | Déclencheurs | Workflows principaux |
|
||||||
|
|------------------------|----------------------|------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||||
|
| Analyste (Mary) | `bmad-analyst` | `BP`, `MR`, `DR`, `TR`, `CB`, `DP` | Brainstorming du projet, Recherche marché/domaine/technique, Création du brief[^1], Documentation du projet |
|
||||||
|
| Architecte (Winston) | `bmad-architect` | `CA`, `IR` | Créer l’architecture, Préparation à l’implémentation |
|
||||||
|
| Développeur (Amelia) | `bmad-dev` | `DS`, `QD`, `CR` | Dev Story, Quick Dev, Code Review |
|
||||||
|
| Designer UX (Sally) | `bmad-ux-designer` | `CU` | Création du design UX[^2] |
|
||||||
|
| Rédacteur Technique (Paige) | `bmad-tech-writer` | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Documentation du projet, Rédaction de documents, Mise à jour des standards, Génération de diagrammes Mermaid, Validation de documents, Explication de concepts |
|
||||||
|
|
||||||
|
## Types de déclencheurs
|
||||||
|
|
||||||
|
Les déclencheurs de menu d'agent utilisent deux types d'invocation différents. Connaître le type utilisé par un déclencheur vous aide à fournir la bonne entrée.
|
||||||
|
|
||||||
|
### Déclencheurs de workflow (aucun argument nécessaire)
|
||||||
|
|
||||||
|
La plupart des déclencheurs chargent un fichier de workflow structuré. Tapez le code du déclencheur et l'agent démarre le workflow, vous demandant de saisir les informations à chaque étape.
|
||||||
|
|
||||||
|
Exemples : `BP` (Brainstorm Project), `CA` (Create Architecture), `CU` (Create UX Design)
|
||||||
|
|
||||||
|
### Déclencheurs conversationnels (arguments requis)
|
||||||
|
|
||||||
|
Certains déclencheurs lancent une conversation libre au lieu d'un workflow structuré. Ils s'attendent à ce que vous décriviez ce dont vous avez besoin à côté du code du déclencheur.
|
||||||
|
|
||||||
|
| Agent | Déclencheur | Ce qu'il faut fournir |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| Rédacteur Technique (Paige) | `WD` | Description du document à rédiger |
|
||||||
|
| Rédacteur Technique (Paige) | `US` | Préférences ou conventions à ajouter aux standards |
|
||||||
|
| Rédacteur Technique (Paige) | `MG` | Description et type de diagramme (séquence, organigramme, etc.) |
|
||||||
|
| Rédacteur Technique (Paige) | `VD` | Document à valider et domaines à examiner |
|
||||||
|
| Rédacteur Technique (Paige) | `EC` | Nom du concept à expliquer |
|
||||||
|
|
||||||
|
**Exemple :**
|
||||||
|
|
||||||
|
```text
|
||||||
|
WD Rédige un guide de déploiement pour notre configuration Docker
|
||||||
|
MG Crée un diagramme de séquence montrant le flux d’authentification
|
||||||
|
EC Explique le fonctionnement du système de modules
|
||||||
|
```
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: Brief : document synthétique qui formalise le contexte, les objectifs, le périmètre et les contraintes d’un projet ou d’une demande, afin d’aligner rapidement les parties prenantes avant le travail détaillé.
|
||||||
|
[^2]: UX (User Experience) : expérience utilisateur, englobant l’ensemble des interactions et perceptions d’un utilisateur face à un produit. Le design UX vise à créer des interfaces intuitives, efficaces et agréables en tenant compte des besoins, comportements et contexte d’utilisation.
|
||||||
|
|
@ -0,0 +1,139 @@
|
||||||
|
---
|
||||||
|
title: Skills
|
||||||
|
description: Référence des skills BMad — ce qu'ils sont, comment ils fonctionnent et où les trouver.
|
||||||
|
sidebar:
|
||||||
|
order: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
Les skills sont des prompts pré-construits qui chargent des agents, exécutent des workflows ou lancent des tâches dans votre IDE. L'installateur BMad les génère à partir de vos modules installés au moment de l'installation. Si vous ajoutez, supprimez ou modifiez des modules ultérieurement, relancez l'installateur pour garder les skills synchronisés (voir [Dépannage](#dépannage)).
|
||||||
|
|
||||||
|
## Skills vs. Déclencheurs du menu Agent
|
||||||
|
|
||||||
|
BMad offre deux façons de démarrer un travail, chacune ayant un usage différent.
|
||||||
|
|
||||||
|
| Mécanisme | Comment l'invoquer | Ce qui se passe |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| **Skill** | Tapez le nom du skill (ex. `bmad-help`) dans votre IDE | Charge directement un agent, exécute un workflow ou lance une tâche |
|
||||||
|
| **Déclencheur du menu agent** | Chargez d'abord un agent, puis tapez un code court (ex. `DS`) | L'agent interprète le code et démarre le workflow correspondant tout en préservant son persona |
|
||||||
|
|
||||||
|
Les déclencheurs du menu agent nécessitent une session agent active. Utilisez les skills lorsque vous savez quel workflow vous voulez. Utilisez les déclencheurs lorsque vous travaillez déjà avec un agent et souhaitez changer de tâche sans quitter la conversation.
|
||||||
|
|
||||||
|
## Comment les skills sont générés
|
||||||
|
|
||||||
|
Lorsque vous exécutez `npx bmad-method install`, l'installateur lit les manifests de chaque module sélectionné et écrit un skill par agent, workflow, tâche et outil. Chaque skill est un répertoire contenant un fichier `SKILL.md` qui indique à l'IA de charger le fichier source correspondant et de suivre ses instructions.
|
||||||
|
|
||||||
|
L'installateur utilise des modèles pour chaque type de skill :
|
||||||
|
|
||||||
|
| Type de skill | Ce que fait le fichier généré |
|
||||||
|
| --- | --- |
|
||||||
|
| **Lanceur d'agent** | Charge le fichier de persona de l'agent, active son menu et reste en caractère |
|
||||||
|
| **Skill de workflow** | Charge la configuration du workflow et suit ses étapes |
|
||||||
|
| **Skill de tâche** | Charge un fichier de tâche autonome et suit ses instructions |
|
||||||
|
| **Skill d'outil** | Charge un fichier d'outil autonome et suit ses instructions |
|
||||||
|
|
||||||
|
:::note[Relancer l'installateur]
|
||||||
|
Si vous ajoutez ou supprimez des modules, relancez l'installateur. Il régénère tous les fichiers de skill pour correspondre à votre sélection actuelle de modules.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Emplacement des fichiers de skill
|
||||||
|
|
||||||
|
L'installateur écrit les fichiers de skill dans un répertoire spécifique à l'IDE à l'intérieur de votre projet. Le chemin exact dépend de l'IDE que vous avez sélectionné lors de l'installation.
|
||||||
|
|
||||||
|
| IDE / CLI | Répertoire des skills |
|
||||||
|
| --- | --- |
|
||||||
|
| Claude Code | `.claude/skills/` |
|
||||||
|
| Cursor | `.cursor/skills/` |
|
||||||
|
| Windsurf | `.windsurf/skills/` |
|
||||||
|
| Autres IDE | Consultez la sortie de l'installateur pour le chemin cible |
|
||||||
|
|
||||||
|
Chaque skill est un répertoire contenant un fichier `SKILL.md`. Par exemple, une installation Claude Code ressemble à :
|
||||||
|
|
||||||
|
```text
|
||||||
|
.claude/skills/
|
||||||
|
├── bmad-help/
|
||||||
|
│ └── SKILL.md
|
||||||
|
├── bmad-create-prd/
|
||||||
|
│ └── SKILL.md
|
||||||
|
├── bmad-analyst/
|
||||||
|
│ └── SKILL.md
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
|
||||||
|
Le nom du répertoire détermine le nom du skill dans votre IDE. Par exemple, le répertoire `bmad-analyst/` enregistre le skill `bmad-analyst`.
|
||||||
|
|
||||||
|
## Comment découvrir vos skills
|
||||||
|
|
||||||
|
Tapez le nom du skill dans votre IDE pour l'invoquer. Certaines plateformes nécessitent d'activer les skills dans les paramètres avant qu'ils n'apparaissent.
|
||||||
|
|
||||||
|
Exécutez `bmad-help` pour obtenir des conseils contextuels sur votre prochaine étape.
|
||||||
|
|
||||||
|
:::tip[Découverte rapide]
|
||||||
|
Les répertoires de skills générés dans votre projet sont la liste de référence. Ouvrez-les dans votre explorateur de fichiers pour voir chaque skill avec sa description.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Catégories de skills
|
||||||
|
|
||||||
|
### Skills d'agent
|
||||||
|
|
||||||
|
Les skills d'agent chargent une persona[^2] IA spécialisée avec un rôle défini, un style de communication et un menu de workflows. Une fois chargé, l'agent reste en caractère et répond aux déclencheurs du menu.
|
||||||
|
|
||||||
|
| Exemple de skill | Agent | Rôle |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| `bmad-analyst` | Mary (Analyste) | Brainstorming de projets, recherche, création de briefs |
|
||||||
|
| `bmad-architect` | Winston (Architecte) | Conçoit l'architecture système |
|
||||||
|
| `bmad-ux-designer` | Sally (Designer UX) | Crée les designs UX |
|
||||||
|
| `bmad-tech-writer` | Paige (Rédacteur Technique) | Documente les projets, rédige des guides, génère des diagrammes |
|
||||||
|
|
||||||
|
Consultez [Agents](./agents.md) pour la liste complète des agents par défaut et leurs déclencheurs.
|
||||||
|
|
||||||
|
### Skills de workflow
|
||||||
|
|
||||||
|
Les skills de workflow exécutent un processus structuré en plusieurs étapes sans charger d'abord une persona d'agent. Ils chargent une configuration de workflow et suivent ses étapes.
|
||||||
|
|
||||||
|
| Exemple de skill | Objectif |
|
||||||
|
| --- | --- |
|
||||||
|
| `bmad-create-prd` | Créer un PRD[^1] |
|
||||||
|
| `bmad-create-architecture` | Concevoir l'architecture système |
|
||||||
|
| `bmad-create-epics-and-stories` | Créer des epics et des stories |
|
||||||
|
| `bmad-dev-story` | Implémenter une story |
|
||||||
|
| `bmad-code-review` | Effectuer une revue de code |
|
||||||
|
| `bmad-quick-dev` | Flux rapide unifié — clarifier l'intention, planifier, implémenter, réviser, présenter |
|
||||||
|
|
||||||
|
Consultez la [Carte des workflows](./workflow-map.md) pour la référence complète des workflows organisés par phase.
|
||||||
|
|
||||||
|
### Skills de tâche et d'outil
|
||||||
|
|
||||||
|
Les tâches et outils sont des opérations autonomes qui ne nécessitent pas de contexte d'agent ou de workflow.
|
||||||
|
|
||||||
|
**BMad-Help : Votre guide intelligent**
|
||||||
|
|
||||||
|
`bmad-help` est votre interface principale pour découvrir quoi faire ensuite. Il inspecte votre projet, comprend les requêtes en langage naturel et recommande la prochaine étape requise ou optionnelle en fonction de vos modules installés.
|
||||||
|
|
||||||
|
:::note[Exemple]
|
||||||
|
```
|
||||||
|
bmad-help
|
||||||
|
bmad-help J'ai une idée de SaaS et je connais toutes les fonctionnalités. Par où commencer ?
|
||||||
|
bmad-help Quelles sont mes options pour le design UX ?
|
||||||
|
```
|
||||||
|
:::
|
||||||
|
|
||||||
|
**Autres tâches et outils principaux**
|
||||||
|
|
||||||
|
Le module principal inclut 11 outils intégrés — revues, compression, brainstorming, gestion de documents, et plus. Consultez [Outils principaux](./core-tools.md) pour la référence complète.
|
||||||
|
|
||||||
|
## Convention de nommage
|
||||||
|
|
||||||
|
Tous les skills utilisent le préfixe `bmad-` suivi d'un nom descriptif (ex. `bmad-analyst`, `bmad-create-prd`, `bmad-help`). Consultez [Modules](./modules.md) pour les modules disponibles.
|
||||||
|
|
||||||
|
## Dépannage
|
||||||
|
|
||||||
|
**Les skills n'apparaissent pas après l'installation.** Certaines plateformes nécessitent d'activer explicitement les skills dans les paramètres. Consultez la documentation de votre IDE ou demandez à votre assistant IA comment activer les skills. Vous devrez peut-être aussi redémarrer votre IDE ou recharger la fenêtre.
|
||||||
|
|
||||||
|
**Des skills attendus sont manquants.** L'installateur génère uniquement les skills pour les modules que vous avez sélectionnés. Exécutez à nouveau `npx bmad-method install` et vérifiez votre sélection de modules. Vérifiez que les fichiers de skill existent dans le répertoire attendu.
|
||||||
|
|
||||||
|
**Des skills d'un module supprimé apparaissent encore.** L'installateur ne supprime pas automatiquement les anciens fichiers de skill. Supprimez les répertoires obsolètes du répertoire de skills de votre IDE, ou supprimez tout le répertoire de skills et relancez l'installateur pour obtenir un ensemble propre.
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d’aligner les équipes sur ce qui doit être construit et pourquoi.
|
||||||
|
[^2]: Persona : dans le contexte de BMad, une persona désigne un agent IA avec un rôle défini, un style de communication et une expertise spécifiques (ex. Mary l'analyste, Winston l'architecte). Chaque persona garde son "caractère" pendant les interactions.
|
||||||
|
|
@ -0,0 +1,298 @@
|
||||||
|
---
|
||||||
|
title: Outils Principaux
|
||||||
|
description: Référence pour toutes les tâches et tous les workflows intégrés disponibles dans chaque installation BMad sans modules supplémentaires.
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Chaque installation BMad comprend un ensemble de compétences principales qui peuvent être utilisées conjointement avec tout ce que vous faites — des tâches et des workflows autonomes qui fonctionnent dans tous les projets, tous les modules et toutes les phases. Ceux-ci sont toujours disponibles, quels que soient les modules optionnels que vous installez.
|
||||||
|
|
||||||
|
:::tip[Raccourci Rapide]
|
||||||
|
Exécutez n'importe quel outil principal en tapant son nom de compétence (par ex., `bmad-help`) dans votre IDE. Aucune session d'agent requise.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Vue d'ensemble
|
||||||
|
|
||||||
|
| Outil | Type | Objectif |
|
||||||
|
|-----------------------------------------------------------------------|----------|------------------------------------------------------------------------------|
|
||||||
|
| [`bmad-help`](#bmad-help) | Tâche | Obtenir des conseils contextuels sur la prochaine étape |
|
||||||
|
| [`bmad-brainstorming`](#bmad-brainstorming) | Workflow | Faciliter des sessions de brainstorming interactives |
|
||||||
|
| [`bmad-party-mode`](#bmad-party-mode) | Workflow | Orchestrer des discussions de groupe multi-agents |
|
||||||
|
| [`bmad-distillator`](#bmad-distillator) | Tâche | Compression sans perte optimisée pour LLM de documents |
|
||||||
|
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Tâche | Pousser la sortie LLM à travers des méthodes de raffinement itératives |
|
||||||
|
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | Tâche | Revue cynique qui trouve ce qui manque et ce qui ne va pas |
|
||||||
|
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | Tâche | Analyse exhaustive des chemins de branchement pour les cas limites non gérés |
|
||||||
|
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | Tâche | Révision de copie clinique pour la clarté de communication |
|
||||||
|
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | Tâche | Édition structurelle — coupes, fusions et réorganisation |
|
||||||
|
| [`bmad-shard-doc`](#bmad-shard-doc) | Tâche | Diviser les fichiers markdown volumineux en sections organisées |
|
||||||
|
| [`bmad-index-docs`](#bmad-index-docs) | Tâche | Générer ou mettre à jour un index de tous les documents dans un dossier |
|
||||||
|
|
||||||
|
## bmad-help
|
||||||
|
|
||||||
|
**Votre guide intelligent pour la suite.** — Inspecte l'état de votre projet, détecte ce qui a été fait et recommande la prochaine étape requise ou facultative.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Vous avez terminé un workflow et voulez savoir ce qui suit
|
||||||
|
- Vous êtes nouveau sur BMad et avez besoin d'orientation
|
||||||
|
- Vous êtes bloqué et voulez des conseils contextuels
|
||||||
|
- Vous avez installé de nouveaux modules et voulez voir ce qui est disponible
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Analyse votre projet pour les artefacts existants (PRD, architecture, stories, etc.)
|
||||||
|
2. Détecte quels modules sont installés et leurs workflows disponibles
|
||||||
|
3. Recommande les prochaines étapes par ordre de priorité — étapes requises d'abord, puis facultatives
|
||||||
|
4. Présente chaque recommandation avec la commande de compétence et une brève description
|
||||||
|
|
||||||
|
**Entrée :** Requête optionnelle en langage naturel (par ex., `bmad-help J'ai une idée de SaaS, par où commencer ?`)
|
||||||
|
|
||||||
|
**Sortie :** Liste priorisée des prochaines étapes recommandées avec les commandes de compétence
|
||||||
|
|
||||||
|
## bmad-brainstorming
|
||||||
|
|
||||||
|
**Génère des idées diverses à travers des techniques créatives interactives.** — Une session de brainstorming facilitée qui charge des méthodes d'idéation éprouvées depuis une bibliothèque de techniques et vous guide vers plus de 100 idées avant organisation.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Vous commencez un nouveau projet et devez explorer l’espace problème
|
||||||
|
- Vous êtes bloqué dans la génération d'idées et avez besoin de créativité structurée
|
||||||
|
- Vous voulez utiliser des cadres d'idéation éprouvés (SCAMPER, brainstorming inversé, etc.)
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Configure une session de brainstorming avec votre sujet
|
||||||
|
2. Charge les techniques créatives depuis une bibliothèque de méthodes
|
||||||
|
3. Vous guide à travers technique après technique, générant des idées
|
||||||
|
4. Applique un protocole anti-biais — change de domaine créatif toutes les 10 idées pour éviter le regroupement
|
||||||
|
5. Produit un document de session en mode ajout uniquement avec toutes les idées organisées par technique
|
||||||
|
|
||||||
|
**Entrée :** Sujet de brainstorming ou énoncé de problème, fichier de contexte optionnel
|
||||||
|
|
||||||
|
**Sortie :** `brainstorming-session-{date}.md` avec toutes les idées générées
|
||||||
|
|
||||||
|
:::note[Cible de Quantité]
|
||||||
|
La magie se produit dans les idées 50–100. Le workflow encourage la génération de plus de 100 idées avant organisation.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## bmad-party-mode
|
||||||
|
|
||||||
|
**Orchestre des discussions de groupe multi-agents.** — Charge tous les agents BMad installés et facilite une conversation naturelle où chaque agent contribue depuis son expertise et personnalité uniques.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Vous avez besoin de multiples perspectives d'experts sur une décision
|
||||||
|
- Vous voulez que les agents remettent en question les hypothèses des autres
|
||||||
|
- Vous explorez un sujet complexe qui couvre plusieurs domaines
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Charge le manifeste d'agents avec toutes les personnalités d'agents installées
|
||||||
|
2. Analyse votre sujet pour sélectionner les 2–3 agents les plus pertinents
|
||||||
|
3. Les agents prennent des tours pour contribuer, avec des échanges naturels et des désaccords
|
||||||
|
4. Fait rouler la participation des agents pour assurer des perspectives diverses au fil du temps
|
||||||
|
5. Quittez avec `goodbye`, `end party` ou `quit`
|
||||||
|
|
||||||
|
**Entrée :** Sujet de discussion ou question, ainsi que la spécification des personas que vous souhaitez faire participer (optionnel)
|
||||||
|
|
||||||
|
**Sortie :** Conversation multi-agents en temps réel avec des personnalités d'agents maintenues
|
||||||
|
|
||||||
|
## bmad-distillator
|
||||||
|
|
||||||
|
**Compression sans perte optimisée pour LLM de documents sources.** — Produit des distillats denses et efficaces en tokens qui préservent toute l'information pour la consommation par des LLM en aval. Vérifiable par reconstruction aller-retour.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Un document est trop volumineux pour la fenêtre de contexte d'un LLM
|
||||||
|
- Vous avez besoin de versions économes en tokens de recherches, spécifications ou artefacts de planification
|
||||||
|
- Vous voulez vérifier qu'aucune information n'est perdue pendant la compression
|
||||||
|
- Les agents auront besoin de référencer et de trouver fréquemment des informations dedans
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. **Analyser** — Lit les documents sources, identifie la densité d'information et la structure
|
||||||
|
2. **Compresser** — Convertit la prose en format dense de liste de points, supprime le formatage décoratif
|
||||||
|
3. **Vérifier** — Vérifie l'exhaustivité pour s'assurer que toute l'information originale est préservée
|
||||||
|
4. **Valider** (optionnel) — Le test de reconstruction aller-retour prouve la compression sans perte
|
||||||
|
|
||||||
|
**Entrée :**
|
||||||
|
|
||||||
|
- `source_documents` (requis) — Chemins de fichiers, chemins de dossiers ou motifs glob
|
||||||
|
- `downstream_consumer` (optionnel) — Ce qui va le consommer (par ex., "création de PRD")
|
||||||
|
- `token_budget` (optionnel) — Taille cible approximative
|
||||||
|
- `--validate` (drapeau) — Exécuter le test de reconstruction aller-retour
|
||||||
|
|
||||||
|
**Sortie :** Fichier(s) markdown distillé(s) avec rapport de ratio de compression (par ex., "3.2:1")
|
||||||
|
|
||||||
|
## bmad-advanced-elicitation
|
||||||
|
|
||||||
|
**Passer la sortie du LLM à travers des méthodes de raffinement itératives.** — Sélectionne depuis une bibliothèque de techniques d'élicitation pour améliorer systématiquement le contenu à travers multiples passages.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- La sortie du LLM semble superficielle ou générique
|
||||||
|
- Vous voulez explorer un sujet depuis de multiples angles analytiques
|
||||||
|
- Vous raffinez un document critique et voulez une réflexion plus approfondie
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Charge le registre de méthodes avec plus de 5 techniques d'élicitation
|
||||||
|
2. Sélectionne les 5 méthodes les mieux adaptées selon le type de contenu et la complexité
|
||||||
|
3. Présente un menu interactif — choisissez une méthode, remélangez, ou listez tout
|
||||||
|
4. Applique la méthode sélectionnée pour améliorer le contenu
|
||||||
|
5. Re-présente les options pour l'amélioration itérative jusqu'à ce que vous sélectionniez "Procéder"
|
||||||
|
|
||||||
|
**Entrée :** Section de contenu à améliorer
|
||||||
|
|
||||||
|
**Sortie :** Version améliorée du contenu avec les améliorations appliquées
|
||||||
|
|
||||||
|
## bmad-review-adversarial-general
|
||||||
|
|
||||||
|
**Revue contradictoire qui suppose que des problèmes existent et les recherche.** — Adopte une perspective de réviseur sceptique et blasé avec zéro tolérance pour le travail bâclé. Cherche ce qui manque, pas seulement ce qui ne va pas.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Vous avez besoin d'assurance qualité avant de finaliser un livrable
|
||||||
|
- Vous voulez tester en conditions réelles une spécification, story ou document
|
||||||
|
- Vous voulez trouver des lacunes de couverture que les revues optimistes manquent
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Lit le contenu avec une perspective contradictoire et critique
|
||||||
|
2. Identifie les problèmes à travers l'exhaustivité, la justesse et la qualité
|
||||||
|
3. Recherche spécifiquement ce qui manque — pas seulement ce qui est présent et faux
|
||||||
|
4. Doit trouver un minimum de 10 problèmes ou réanalyse plus profondément
|
||||||
|
|
||||||
|
**Entrée :**
|
||||||
|
|
||||||
|
- `content` (requis) — Diff, spécification, story, document ou tout artefact
|
||||||
|
- `also_consider` (optionnel) — Domaines supplémentaires à garder à l'esprit
|
||||||
|
|
||||||
|
**Sortie :** Liste markdown de plus de 10 constatations avec descriptions
|
||||||
|
|
||||||
|
## bmad-review-edge-case-hunter
|
||||||
|
|
||||||
|
**Parcours tous les chemins de branchement et les conditions limites, ne rapporte que les cas non gérés.** — Méthodologie pure de traçage de chemin[^1] qui dérive mécaniquement les classes de cas limites. Orthogonale à la revue contradictoire — centrée sur la méthode, pas sur l'attitude.
|
||||||
|
|
||||||
|
**À utiliser quand :**
|
||||||
|
|
||||||
|
- Vous souhaitez une couverture exhaustive des cas limites pour le code ou la logique
|
||||||
|
- Vous avez besoin d'un complément à la revue contradictoire (méthodologie différente, résultats différents)
|
||||||
|
- Vous révisez un diff ou une fonction pour des conditions limites
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Énumère tous les chemins de branchement dans le contenu
|
||||||
|
2. Dérive mécaniquement les classes de cas limites : else/default manquants, entrées non vérifiées, décalage d’unité, overflow arithmétique, coercition implicite des types, conditions de concurrence, écarts de timeout
|
||||||
|
3. Teste chaque chemin contre les protections existantes
|
||||||
|
4. Ne rapporte que les chemins non gérés — ignore silencieusement les chemins gérés
|
||||||
|
|
||||||
|
**Entrée :**
|
||||||
|
|
||||||
|
- `content` (obligatoire) — Diff, fichier complet ou fonction
|
||||||
|
- `also_consider` (facultatif) — Zones supplémentaires à garder à l’esprit
|
||||||
|
|
||||||
|
**Sortie :** Tableau JSON des résultats, chacun avec `location`, `trigger_condition`, `guard_snippet` et `potential_consequence`
|
||||||
|
|
||||||
|
:::note[Revue Complémentaire]
|
||||||
|
Exécutez à la fois `bmad-review-adversarial-general` et `bmad-review-edge-case-hunter` pour une couverture orthogonale. La revue contradictoire détecte les problèmes de qualité et de complétude ; le chasseur de cas limites détecte les chemins non gérés.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## bmad-editorial-review-prose
|
||||||
|
|
||||||
|
**Relecture éditoriale clinique centrée sur la clarté de communication.** — Analyse le texte pour détecter les problèmes qui nuisent à la compréhension. Applique le Microsoft Writing Style Guide baseline. Préserve la voix de l’auteur.
|
||||||
|
|
||||||
|
**À utiliser quand :**
|
||||||
|
|
||||||
|
- Vous avez rédigé un document et souhaitez polir le style
|
||||||
|
- Vous devez assurer la clarté pour un public spécifique
|
||||||
|
- Vous voulez des corrections de communication sans modifier les choix stylistiques
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Lit le contenu en ignorant les blocs de code et le frontmatter
|
||||||
|
2. Identifie les problèmes de communication (pas les préférences de style)
|
||||||
|
3. Déduit les doublons du même problème à différents emplacements
|
||||||
|
4. Produit un tableau de corrections en trois colonnes
|
||||||
|
|
||||||
|
**Entrée :**
|
||||||
|
|
||||||
|
- `content` (obligatoire) — Markdown, texte brut ou XML
|
||||||
|
- `style_guide` (facultatif) — Guide de style spécifique au projet
|
||||||
|
- `reader_type` (facultatif) — `humans` (par défaut) pour clarté/fluide, ou `llm` pour précision/consistance
|
||||||
|
|
||||||
|
**Sortie :** Tableau Markdown en trois colonnes : Texte original | Texte révisé | Modifications
|
||||||
|
|
||||||
|
## bmad-editorial-review-structure
|
||||||
|
|
||||||
|
**Édition structurelle — propose des coupes, fusions, déplacements et condensations.** — Révise l'organisation du document et propose des changements substantiels pour améliorer la clarté et le flux avant la révision de copie.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Un document a été produit depuis de multiples sous-processus et a besoin de cohérence structurelle
|
||||||
|
- Vous voulez réduire la longueur du document tout en préservant la compréhension
|
||||||
|
- Vous devez identifier les violations de portée ou les informations critiques enfouies
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Analyse le document contre 5 modèles de structure (Tutoriel, Référence, Explication, Prompt, Stratégique)
|
||||||
|
2. Identifie les redondances, violations de portée et informations enfouies
|
||||||
|
3. Produit des recommandations priorisées : COUPER, FUSIONNER, DÉPLACER, CONDENSER, QUESTIONNER, PRÉSERVER
|
||||||
|
4. Estime la réduction totale en mots et pourcentage
|
||||||
|
|
||||||
|
**Entrée :**
|
||||||
|
|
||||||
|
- `content` (requis) — Document à réviser
|
||||||
|
- `purpose` (optionnel) — Objectif prévu (par ex., "tutoriel de démarrage rapide")
|
||||||
|
- `target_audience` (optionnel) — Qui lit ceci
|
||||||
|
- `reader_type` (optionnel) — `humans` ou `llm`
|
||||||
|
- `length_target` (optionnel) — Réduction cible (par ex., "30% plus court")
|
||||||
|
|
||||||
|
**Sortie :** Résumé du document, liste de recommandations priorisées et réduction estimée
|
||||||
|
|
||||||
|
## bmad-shard-doc
|
||||||
|
|
||||||
|
**Diviser les fichiers markdown volumineux en fichiers de sections organisés.** — Utilise les en-têtes de niveau 2 comme points de division pour créer un dossier de fichiers de sections autonomes avec un index.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Un document markdown est devenu trop volumineux pour être géré efficacement (plus de 500 lignes)
|
||||||
|
- Vous voulez diviser un document monolithique en sections navigables
|
||||||
|
- Vous avez besoin de fichiers séparés pour l'édition parallèle ou la gestion de contexte LLM
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Valide que le fichier source existe et est markdown
|
||||||
|
2. Divise sur les en-têtes de niveau 2 (`##`) en fichiers de sections numérotées
|
||||||
|
3. Crée un `index.md` avec manifeste de sections et liens
|
||||||
|
4. Vous invite à supprimer, archiver ou conserver l'original
|
||||||
|
|
||||||
|
**Entrée :** Chemin du fichier markdown source, dossier de destination optionnel
|
||||||
|
|
||||||
|
**Sortie :** Dossier avec `index.md` et `01-{section}.md`, `02-{section}.md`, etc.
|
||||||
|
|
||||||
|
## bmad-index-docs
|
||||||
|
|
||||||
|
**Générer ou mettre à jour un index de tous les documents dans un dossier.** — Analyse un répertoire, lit chaque fichier pour comprendre son objectif et produit un `index.md` organisé avec liens et descriptions.
|
||||||
|
|
||||||
|
**Utilisez-le quand :**
|
||||||
|
|
||||||
|
- Vous avez besoin d'un index léger pour un scan LLM rapide des documents disponibles
|
||||||
|
- Un dossier de documentation a grandi et a besoin d'une table des matières organisée
|
||||||
|
- Vous voulez un aperçu auto-généré qui reste à jour
|
||||||
|
|
||||||
|
**Fonctionnement :**
|
||||||
|
|
||||||
|
1. Analyse le répertoire cible pour tous les fichiers non cachés
|
||||||
|
2. Lit chaque fichier pour comprendre son objectif réel
|
||||||
|
3. Groupe les fichiers par type, objectif ou sous-répertoire
|
||||||
|
4. Génère des descriptions concises (3–10 mots chacune)
|
||||||
|
|
||||||
|
**Entrée :** Chemin du dossier cible
|
||||||
|
|
||||||
|
**Sortie :** `index.md` avec listes de fichiers organisées, liens relatifs et brèves descriptions
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: Path-tracing : méthode d'analyse qui suit systématiquement tous les chemins d'exécution possibles dans un programme pour identifier les cas non gérés.
|
||||||
|
|
||||||
|
|
@ -0,0 +1,82 @@
|
||||||
|
---
|
||||||
|
title: Modules Officiels
|
||||||
|
description: Modules additionnels pour créer des agents personnalisés, de l'intelligence créative, du développement de jeux et des tests
|
||||||
|
sidebar:
|
||||||
|
order: 4
|
||||||
|
---
|
||||||
|
|
||||||
|
BMad s'étend via des modules officiels que vous sélectionnez lors de l'installation. Ces modules additionnels fournissent des agents, des workflows et des tâches spécialisés pour des domaines spécifiques, au-delà du noyau intégré et de BMM (suite Agile).
|
||||||
|
|
||||||
|
:::tip[Installer des Modules]
|
||||||
|
Exécutez `npx bmad-method install` et sélectionnez les modules souhaités. L'installateur gère automatiquement le téléchargement, la configuration et l'intégration IDE.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## BMad Builder
|
||||||
|
|
||||||
|
Créez des agents personnalisés, des workflows et des modules spécifiques à un domaine avec une assistance guidée. BMad Builder est le méta-module pour étendre le framework lui-même.
|
||||||
|
|
||||||
|
- **Code :** `bmb`
|
||||||
|
- **npm :** [`bmad-builder`](https://www.npmjs.com/package/bmad-builder)
|
||||||
|
- **GitHub :** [bmad-code-org/bmad-builder](https://github.com/bmad-code-org/bmad-builder)
|
||||||
|
|
||||||
|
**Fournit :**
|
||||||
|
|
||||||
|
- Agent Builder — créez des agents IA spécialisés avec une expertise et un accès aux outils personnalisés
|
||||||
|
- Workflow Builder — concevez des processus structurés avec des étapes et des points de décision
|
||||||
|
- Module Builder — empaquetez des agents et des workflows dans des modules partageables et publiables
|
||||||
|
- Configuration interactive avec support de configuration YAML et publication npm
|
||||||
|
|
||||||
|
## Creative Intelligence Suite
|
||||||
|
|
||||||
|
Outils basés sur l'IA pour la créativité structurée, l'idéation et l'innovation pendant le développement en phase amont. La suite fournit plusieurs agents qui facilitent le brainstorming, le design thinking et la résolution de problèmes en utilisant des cadres éprouvés.
|
||||||
|
|
||||||
|
- **Code :** `cis`
|
||||||
|
- **npm :** [`bmad-creative-intelligence-suite`](https://www.npmjs.com/package/bmad-creative-intelligence-suite)
|
||||||
|
- **GitHub :** [bmad-code-org/bmad-module-creative-intelligence-suite](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)
|
||||||
|
|
||||||
|
**Fournit :**
|
||||||
|
|
||||||
|
- Agents Innovation Strategist, Design Thinking Coach et Brainstorming Coach
|
||||||
|
- Problem Solver et Creative Problem Solver pour la pensée systématique et latérale
|
||||||
|
- Storyteller et Presentation Master pour les récits et les présentations
|
||||||
|
- Cadres d'idéation incluant SCAMPER[^1], Brainstorming inversé et reformulation de problèmes
|
||||||
|
|
||||||
|
## Game Dev Studio
|
||||||
|
|
||||||
|
Workflows de développement de jeux structurés adaptés pour Unity, Unreal, Godot et moteurs personnalisés. Supporte le prototypage rapide via Quick Dev et la production à grande échelle avec des sprints propulsés par epics.
|
||||||
|
|
||||||
|
- **Code :** `gds`
|
||||||
|
- **npm :** [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
|
||||||
|
- **GitHub :** [bmad-code-org/bmad-module-game-dev-studio](https://github.com/bmad-code-org/bmad-module-game-dev-studio)
|
||||||
|
|
||||||
|
**Fournit :**
|
||||||
|
|
||||||
|
- Workflow de génération de Document de Design de Jeu (GDD[^3])
|
||||||
|
- Mode Quick Dev pour le prototypage rapide
|
||||||
|
- Support de design narratif pour les personnages, dialogues et construction de monde
|
||||||
|
- Couverture de plus de 21 types de jeux avec des conseils d'architecture spécifiques au moteur
|
||||||
|
|
||||||
|
## Test Architect (TEA)
|
||||||
|
|
||||||
|
Stratégie de test de niveau entreprise, conseils d'automatisation et décisions de porte de release via un agent expert et neuf workflows structurés. TEA va bien au-delà du workflow QA intégré avec une priorisation basée sur les risques et une traçabilité des exigences.
|
||||||
|
|
||||||
|
- **Code :** `tea`
|
||||||
|
- **npm :** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||||
|
- **GitHub :** [bmad-code-org/bmad-method-test-architecture-enterprise](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)
|
||||||
|
|
||||||
|
**Fournit :**
|
||||||
|
|
||||||
|
- Agent Murat (Master Test Architect and Quality Advisor)
|
||||||
|
- Workflows pour la conception de tests, ATDD, l'automatisation, la revue de tests et la traçabilité
|
||||||
|
- Évaluation NFR[^2], configuration CI et scaffolding de framework
|
||||||
|
- Priorisation P0-P3 avec Playwright Utils et intégrations MCP optionnelles
|
||||||
|
|
||||||
|
## Modules Communautaires
|
||||||
|
|
||||||
|
Les modules communautaires et une marketplace de modules sont à venir. Consultez l'[organisation GitHub BMad](https://github.com/bmad-code-org) pour les mises à jour.
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: SCAMPER : acronyme anglais pour une technique de créativité structurée (Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse) qui permet d'explorer systématiquement les modifications possibles d'un produit ou d'une idée pour générer des innovations.
|
||||||
|
[^2]: NFR (Non-Functional Requirement) : exigence décrivant les contraintes de qualité du système (performance, sécurité, fiabilité, ergonomie) plutôt que ses fonctionnalités.
|
||||||
|
[^3]: GDD (Game Design Document) : document de conception de jeu qui décrit en détail les mécaniques, l'univers, les personnages, les niveaux et tous les aspects du jeu à développer.
|
||||||
|
|
@ -0,0 +1,111 @@
|
||||||
|
---
|
||||||
|
title: Options de Testing
|
||||||
|
description: Comparaison du workflow QA intégré avec le module Test Architect (TEA) pour l'automatisation des tests.
|
||||||
|
sidebar:
|
||||||
|
order: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
BMad propose deux approches de test : un workflow QA[^1] intégré pour une génération rapide de tests et un module Test Architect installable pour une stratégie de test de qualité entreprise.
|
||||||
|
|
||||||
|
## Lequel Choisir ?
|
||||||
|
|
||||||
|
| Facteur | QA Intégré | Module TEA |
|
||||||
|
|-------------------------|----------------------------------------------|---------------------------------------------------------------------|
|
||||||
|
| **Idéal pour** | Projets petits et moyens, couverture rapide | Grands projets, domaines réglementés ou complexes |
|
||||||
|
| **Installation** | Rien à installer — inclus dans BMM | Installer séparément via `npx bmad-method install` |
|
||||||
|
| **Approche** | Générer les tests rapidement, itérer ensuite | Planifier d'abord, puis générer avec traçabilité |
|
||||||
|
| **Types de tests** | Tests API et E2E | API, E2E, ATDD[^2], NFR, et plus |
|
||||||
|
| **Stratégie** | Chemin nominal + cas limites critiques | Priorisation basée sur les risques (P0-P3) |
|
||||||
|
| **Nombre de workflows** | 1 (Automate) | 9 (conception, ATDD, automatisation, revue, traçabilité, et autres) |
|
||||||
|
|
||||||
|
:::tip[Commencez avec le QA Intégré]
|
||||||
|
La plupart des projets devraient commencer avec le workflow QA intégré. Si vous avez ensuite besoin d'une stratégie de test, de murs de qualité ou de traçabilité des exigences, installez TEA en complément.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Workflow QA Intégré
|
||||||
|
|
||||||
|
Le workflow QA intégré (`bmad-qa-generate-e2e-tests`) fait partie du module BMM (suite Agile), disponible via l'agent Developer. Il génère rapidement des tests fonctionnels en utilisant le framework de test existant de votre projet — aucune configuration ni installation supplémentaire requise.
|
||||||
|
|
||||||
|
**Déclencheur :** `QA` (via l'agent Developer) ou `bmad-qa-generate-e2e-tests`
|
||||||
|
|
||||||
|
### Ce que le Workflow QA Fait
|
||||||
|
|
||||||
|
Le workflow QA exécute un processus unique (Automate) qui parcourt cinq étapes :
|
||||||
|
|
||||||
|
1. **Détecte le framework de test** — analyse `package.json` et les fichiers de test existants pour identifier votre framework (Jest, Vitest, Playwright, Cypress, ou tout runner standard). Si aucun n'existe, analyse la pile technologique du projet et en suggère un.
|
||||||
|
2. **Identifie les fonctionnalités** — demande ce qu'il faut tester ou découvre automatiquement les fonctionnalités dans le codebase.
|
||||||
|
3. **Génère les tests API** — couvre les codes de statut, la structure des réponses, le chemin nominal, et 1-2 cas d'erreur.
|
||||||
|
4. **Génére les tests E2E** — couvre les parcours utilisateur avec des localisateurs sémantiques et des assertions sur les résultats visibles.
|
||||||
|
5. **Exécute et vérifie** — lance les tests générés et corrige immédiatement les échecs.
|
||||||
|
|
||||||
|
Le workflow QA produit un résumé de test sauvegardé dans le dossier des artefacts d'implémentation de votre projet.
|
||||||
|
|
||||||
|
### Patterns de Test
|
||||||
|
|
||||||
|
Les tests générés suivent une philosophie "simple et maintenable" :
|
||||||
|
|
||||||
|
- **APIs standard du framework uniquement** — pas d'utilitaires externes ni d'abstractions personnalisées
|
||||||
|
- **Localisateurs sémantiques** pour les tests UI (rôles, labels, texte plutôt que sélecteurs CSS)
|
||||||
|
- **Tests indépendants** sans dépendances d'ordre
|
||||||
|
- **Pas d'attentes ou de sleeps codés en dur**
|
||||||
|
- **Descriptions claires** qui se lisent comme de la documentation fonctionnelle
|
||||||
|
|
||||||
|
:::note[Portée]
|
||||||
|
Le workflow QA génère uniquement des tests. Pour la revue de code et la validation des stories, utilisez plutôt le workflow Code Review (`CR`).
|
||||||
|
:::
|
||||||
|
|
||||||
|
### Quand Utiliser le QA Intégré
|
||||||
|
|
||||||
|
- Couverture de test rapide pour une fonctionnalité nouvelle ou existante
|
||||||
|
- Automatisation de tests accessible aux débutants sans configuration avancée
|
||||||
|
- Patterns de test standards que tout développeur peut lire et maintenir
|
||||||
|
- Projets petits et moyens où une stratégie de test complète n'est pas nécessaire
|
||||||
|
|
||||||
|
## Module Test Architect (TEA)
|
||||||
|
|
||||||
|
TEA est un module autonome qui fournit un agent expert (Murat) et neuf workflows structurés pour des tests de qualité entreprise. Il va au-delà de la génération de tests pour inclure la stratégie de test, la planification basée sur les risques, les murs de qualité et la traçabilité des exigences.
|
||||||
|
|
||||||
|
- **Documentation :** [TEA Module Docs](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
||||||
|
- **Installation :** `npx bmad-method install` et sélectionnez le module TEA
|
||||||
|
- **npm :** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||||
|
|
||||||
|
### Ce que TEA Fournit
|
||||||
|
|
||||||
|
| Workflow | Objectif |
|
||||||
|
|-----------------------|--------------------------------------------------------------------------------------|
|
||||||
|
| Test Design | Créer une stratégie de test complète liée aux exigences |
|
||||||
|
| ATDD | Développement piloté par les tests d'acceptation avec critères des parties prenantes |
|
||||||
|
| Automate | Générer des tests avec des patterns et utilitaires avancés |
|
||||||
|
| Test Review | Valider la qualité et la couverture des tests par rapport à la stratégie |
|
||||||
|
| Traceability | Remonter les tests aux exigences pour l'audit et la conformité |
|
||||||
|
| NFR Assessment | Évaluer les exigences non-fonctionnelles (performance, sécurité) |
|
||||||
|
| CI Setup | Configurer l'exécution des tests dans les pipelines d'intégration continue |
|
||||||
|
| Framework Scaffolding | Configurer l'infrastructure de test et la structure du projet |
|
||||||
|
| Release Gate | Prendre des décisions de livraison go/no-go basées sur les données |
|
||||||
|
|
||||||
|
TEA supporte également la priorisation basée sur les risques P0-P3 et des intégrations optionnelles avec Playwright Utils et les outils MCP.
|
||||||
|
|
||||||
|
### Quand Utiliser TEA
|
||||||
|
|
||||||
|
- Projets nécessitant une traçabilité des exigences ou une documentation de conformité
|
||||||
|
- Équipes ayant besoin d'une priorisation des tests basée sur les risques sur plusieurs fonctionnalités
|
||||||
|
- Environnements entreprise avec des murs de qualité formels avant livraison
|
||||||
|
- Domaines complexes où la stratégie de test doit être planifiée avant d'écrire les tests
|
||||||
|
- Projets ayant dépassé l'approche à workflow unique du QA intégré
|
||||||
|
|
||||||
|
## Comment les Tests S'Intègrent dans les Workflows
|
||||||
|
|
||||||
|
Le workflow Automate du QA intégré apparaît dans la Phase 4 (Implémentation) de la carte de workflow méthode BMad. Il est conçu pour s'exécuter **après qu'un epic complet soit terminé** — une fois que toutes les stories d'un epic ont été implémentées et revues. Une séquence typique :
|
||||||
|
|
||||||
|
1. Pour chaque story de l'epic : implémenter avec Dev Story (`DS`), puis valider avec Code Review (`CR`)
|
||||||
|
2. Après la fin de l'epic : générer les tests avec `QA` (via l'agent Developer) ou le workflow Automate de TEA
|
||||||
|
3. Lancer la rétrospective (`bmad-retrospective`) pour capturer les leçons apprises
|
||||||
|
|
||||||
|
Le workflow QA travaille directement à partir du code source sans charger les documents de planification (PRD, architecture). Les workflows TEA peuvent s'intégrer avec les artefacts de planification en amont pour la traçabilité.
|
||||||
|
|
||||||
|
Pour en savoir plus sur la place des tests dans le processus global, consultez la [Carte des Workflows](./workflow-map.md).
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: QA (Quality Assurance) : assurance qualité, ensemble des processus et activités visant à garantir que le produit logiciel répond aux exigences de qualité définies.
|
||||||
|
[^2]: ATDD (Acceptance Test-Driven Development) : méthode de développement où les tests d'acceptation sont écrits avant le code, en collaboration avec les parties prenantes pour définir les critères de réussite.
|
||||||
|
|
@ -0,0 +1,94 @@
|
||||||
|
---
|
||||||
|
title: "Carte des Workflows"
|
||||||
|
description: Référence visuelle des phases et des résultats des workflows de la méthode BMad
|
||||||
|
sidebar:
|
||||||
|
order: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
La méthode BMad (BMM) est un module de l'écosystème BMad, conçu pour suivre les meilleures pratiques de l'ingénierie du contexte et de la planification. Les agents IA fonctionnent de manière optimale avec un contexte clair et structuré. Le système BMM construit ce contexte progressivement à travers 4 phases distinctes — chaque phase, et plusieurs workflows optionnels au sein de chaque phase, produisent des documents qui alimentent la phase suivante, afin que les agents sachent toujours quoi construire et pourquoi.
|
||||||
|
|
||||||
|
La logique et les concepts proviennent des méthodologies agiles qui ont été utilisées avec succès dans l'industrie comme cadre mental de référence.
|
||||||
|
|
||||||
|
Si à tout moment vous ne savez pas quoi faire, le skill `bmad-help` vous aidera à rester sur la bonne voie ou à savoir quoi faire ensuite. Vous pouvez toujours vous référer à cette page également — mais `bmad-help` est entièrement interactif et beaucoup plus rapide si vous avez déjà installé la méthode BMad. De plus, si vous utilisez différents modules qui ont étendu la méthode BMad ou ajouté d'autres modules complémentaires non extensifs — `bmad-help` évolue pour connaître tout ce qui est disponible et vous donner les meilleurs conseils du moment.
|
||||||
|
|
||||||
|
Note finale importante : Chaque workflow ci-dessous peut être exécuté directement avec l'outil de votre choix via un skill ou en chargeant d'abord un agent et en utilisant l'entrée du menu des agents.
|
||||||
|
|
||||||
|
<iframe src="/workflow-map-diagram-fr.html" title="Diagramme de la carte des workflows de la méthode BMad" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
|
||||||
|
|
||||||
|
<p style="font-size: 0.8rem; text-align: right; margin-top: -0.5rem; margin-bottom: 1rem;">
|
||||||
|
<a href="/workflow-map-diagram-fr.html" target="_blank" rel="noopener noreferrer">Ouvrir le diagramme dans un nouvel onglet ↗</a>
|
||||||
|
</p>
|
||||||
|
|
||||||
|
## Phase 1 : Analyse (Optionnelle)
|
||||||
|
|
||||||
|
Explorez l’espace problème et validez les idées avant de vous engager dans la planification.
|
||||||
|
|
||||||
|
| Workflow | Objectif | Produit |
|
||||||
|
|---------------------------------------------------------------------------|------------------------------------------------------------------------------------------|---------------------------|
|
||||||
|
| `bmad-brainstorming` | Brainstormez des idées de projet avec l'accompagnement guidé d'un coach de brainstorming | `brainstorming-report.md` |
|
||||||
|
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validez les hypothèses de marché, techniques ou de domaine | Rapport de recherches |
|
||||||
|
| `bmad-create-product-brief` | Capturez la vision stratégique | `product-brief.md` |
|
||||||
|
|
||||||
|
## Phase 2 : Planification
|
||||||
|
|
||||||
|
Définissez ce qu'il faut construire et pour qui.
|
||||||
|
|
||||||
|
| Workflow | Objectif | Produit |
|
||||||
|
|-------------------------|---------------------------------------------------------|--------------|
|
||||||
|
| `bmad-create-prd` | Définissez les exigences (FRs/NFRs)[^1] | `PRD.md`[^2] |
|
||||||
|
| `bmad-create-ux-design` | Concevez l'expérience utilisateur (lorsque l'UX compte) | `ux-spec.md` |
|
||||||
|
|
||||||
|
## Phase 3 : Solutioning
|
||||||
|
|
||||||
|
Décidez comment le construire et décomposez le travail en stories.
|
||||||
|
|
||||||
|
| Workflow | Objectif | Produit |
|
||||||
|
|---------------------------------------|---------------------------------------------------|------------------------------|
|
||||||
|
| `bmad-create-architecture` | Rendez les décisions techniques explicites | `architecture.md` avec ADRs[^3] |
|
||||||
|
| `bmad-create-epics-and-stories` | Décomposez les exigences en travail implémentable | Fichiers d'epic avec stories |
|
||||||
|
| `bmad-check-implementation-readiness` | Vérification avant implémentation | Décision Passe/Réserves/Échec |
|
||||||
|
|
||||||
|
## Phase 4 : Implémentation
|
||||||
|
|
||||||
|
Construisez, une story à la fois. Bientôt disponible : automatisation complète de la phase 4 !
|
||||||
|
|
||||||
|
| Workflow | Objectif | Produit |
|
||||||
|
|------------------------|-------------------------------------------------------------------------------------|----------------------------------|
|
||||||
|
| `bmad-sprint-planning` | Initialisez le suivi (une fois par projet pour séquencer le cycle de développement) | `sprint-status.yaml` |
|
||||||
|
| `bmad-create-story` | Préparez la story suivante pour implémentation | `story-[slug].md` |
|
||||||
|
| `bmad-dev-story` | Implémentez la story | Code fonctionnel + tests |
|
||||||
|
| `bmad-code-review` | Validez la qualité de l'implémentation | Approuvé ou changements demandés |
|
||||||
|
| `bmad-correct-course` | Gérez les changements significatifs en cours de sprint | Plan mis à jour ou réorientation |
|
||||||
|
| `bmad-sprint-status` | Suivez la progression du sprint et le statut des stories | Mise à jour du statut du sprint |
|
||||||
|
| `bmad-retrospective` | Revue après complétion d'un epic | Leçons apprises |
|
||||||
|
|
||||||
|
## Quick Dev (Parcours Parallèle)
|
||||||
|
|
||||||
|
Sautez les phases 1-3 pour les travaux de faible envergure et bien compris.
|
||||||
|
|
||||||
|
| Workflow | Objectif | Produit |
|
||||||
|
|------------------|-------------------------------------------------------------------------------------|-----------------------|
|
||||||
|
| `bmad-quick-dev` | Flux rapide unifié — clarifie l'intention, planifie, implémente, révise et présente | `spec-*.md` + code |
|
||||||
|
|
||||||
|
## Gestion du Contexte
|
||||||
|
|
||||||
|
Chaque document devient le contexte de la phase suivante. Le PRD[^2] indique à l'architecte quelles contraintes sont importantes. L'architecture indique à l'agent de développement quels modèles suivre. Les fichiers de story fournissent un contexte focalisé et complet pour l'implémentation. Sans cette structure, les agents prennent des décisions incohérentes.
|
||||||
|
|
||||||
|
### Contexte du Projet
|
||||||
|
|
||||||
|
:::tip[Recommandé]
|
||||||
|
Créez `project-context.md` pour vous assurer que les agents IA suivent les règles et préférences de votre projet. Ce fichier fonctionne comme une constitution pour votre projet — il guide les décisions d'implémentation à travers tous les workflows. Ce fichier optionnel peut être généré à la fin de la création de l'architecture, ou dans un projet existant il peut également être généré pour capturer ce qui est important de conserver aligné avec les conventions actuelles.
|
||||||
|
:::
|
||||||
|
|
||||||
|
**Comment le créer :**
|
||||||
|
|
||||||
|
- **Manuellement** — Créez `_bmad-output/project-context.md` avec votre pile technologique et vos règles d'implémentation
|
||||||
|
- **Générez-le** — Exécutez `bmad-generate-project-context` pour l'auto-générer à partir de votre architecture ou de votre codebase
|
||||||
|
|
||||||
|
[**En savoir plus sur project-context.md**](../explanation/project-context.md)
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: FR / NFR (Functional / Non-Functional Requirement) : exigences décrivant respectivement **ce que le système doit faire** (fonctionnalités, comportements attendus) et **comment il doit le faire** (contraintes de performance, sécurité, fiabilité, ergonomie, etc.).
|
||||||
|
[^2]: PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d’aligner les équipes sur ce qui doit être construit et pourquoi.
|
||||||
|
[^3]: ADR (Architecture Decision Record) : document qui consigne une décision d’architecture, son contexte, les options envisagées, le choix retenu et ses conséquences, afin d’assurer la traçabilité et la compréhension des décisions techniques dans le temps.
|
||||||
|
|
@ -0,0 +1,136 @@
|
||||||
|
---
|
||||||
|
title: Feuille de route
|
||||||
|
description: La suite pour BMad - Fonctionnalités, améliorations et contributions de la communauté
|
||||||
|
---
|
||||||
|
|
||||||
|
# La Méthode BMad : Feuille de route publique
|
||||||
|
|
||||||
|
La Méthode BMad, BMad Method Module (BMM) et BMad Builder (BMB) évoluent. Voici ce sur quoi nous travaillons et ce qui arrive prochainement.
|
||||||
|
|
||||||
|
<div class="roadmap-container">
|
||||||
|
|
||||||
|
<h2 class="roadmap-section-title">En cours</h2>
|
||||||
|
|
||||||
|
<div class="roadmap-future">
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🧩</span>
|
||||||
|
<h4>Architecture par Skills Universelle</h4>
|
||||||
|
<p>Un skill, toutes les plateformes. Écrivez une fois, exécutez partout.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🏗️</span>
|
||||||
|
<h4>BMad Builder v1</h4>
|
||||||
|
<p>Créez des agents IA et des workflows prêts pour la production avec des évaluations, des équipes et dégradation gracieuse intégrées.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🧠</span>
|
||||||
|
<h4>Système de Contexte Projet</h4>
|
||||||
|
<p>Votre IA comprend vraiment votre projet. Un contexte adapté au framework qui évolue avec votre base de code.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">📦</span>
|
||||||
|
<h4>Skills Centralisés</h4>
|
||||||
|
<p>Installez une fois, utilisez partout. Partagez des skills entre projets sans l'encombrement de fichiers.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🔄</span>
|
||||||
|
<h4>Skills Adaptatifs</h4>
|
||||||
|
<p>Des skills qui connaissent vos outils. Des variantes optimisées pour Claude, Codex, Kimi et OpenCode, et bien d'autres encore.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">📝</span>
|
||||||
|
<h4>Blog BMad Team Pros</h4>
|
||||||
|
<p>Guides, articles et perspectives de l'équipe. Lancement prochainement.</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<h2 class="roadmap-section-title">Pour bien commencer</h2>
|
||||||
|
|
||||||
|
<div class="roadmap-future">
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🏪</span>
|
||||||
|
<h4>Marketplace de Skills</h4>
|
||||||
|
<p>Découvrez, installez et mettez à jour des skills créés par la communauté. À une commande curl de super-pouvoirs.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🎨</span>
|
||||||
|
<h4>Personnalisation de Workflow</h4>
|
||||||
|
<p>Faites-en le vôtre. Intégrez Jira, Linear, des sorties personnalisées à votre workflow, vos règles.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🚀</span>
|
||||||
|
<h4>Optimisation Phases 1-3</h4>
|
||||||
|
<p>Planification éclair avec collecte de contexte par sous-agents. Le mode YOLO rencontre l'excellence guidée.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🌐</span>
|
||||||
|
<h4>Prêt pour l'Entreprise</h4>
|
||||||
|
<p>SSO, journaux d'audit, espaces de travail d'équipe. Toutes les choses ennuyantes qui feront dire oui aux entreprises.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">💎</span>
|
||||||
|
<h4>Explosion de Modules Communautaires</h4>
|
||||||
|
<p>Divertissement, sécurité, thérapie, jeu de rôle et bien plus encore. Étendez la plateforme de la Méthode BMad.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">⚡</span>
|
||||||
|
<h4>Automatisation de la Boucle de Développement</h4>
|
||||||
|
<p>Pilote automatique optionnel pour le développement. Laissez l'IA gérer le flux tout en maintenant une qualité optimale.</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<h2 class="roadmap-section-title">Communauté et Équipe</h2>
|
||||||
|
|
||||||
|
<div class="roadmap-future">
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🎙️</span>
|
||||||
|
<h4>Le Podcast de la Méthode BMad</h4>
|
||||||
|
<p>Conversations sur le développement natif IA. Lancement le 1er mars 2026 !</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🎓</span>
|
||||||
|
<h4>Le Master Class de la Méthode BMad</h4>
|
||||||
|
<p>Passez d'utilisateur à expert. Approfondissements dans chaque phase, chaque workflow, chaque secret.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🏗️</span>
|
||||||
|
<h4>La Master Class BMad Builder</h4>
|
||||||
|
<p>Construisez vos propres agents. Techniques avancées pour quand vous êtes prêt à créer, pas seulement à utiliser.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">⚡</span>
|
||||||
|
<h4>BMad Prototype First</h4>
|
||||||
|
<p>De l'idée au prototype fonctionnel en une seule session. Créez l'application de vos rêves comme une œuvre d'art.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🌴</span>
|
||||||
|
<h4>BMad BALM !</h4>
|
||||||
|
<p>Gestion de vie native IA. Tâches, habitudes, objectifs : votre copilote IA pour tout.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🖥️</span>
|
||||||
|
<h4>UI Officielle</h4>
|
||||||
|
<p>Une belle interface pour tout l'écosystème BMad. La puissance de la CLI, le polissage de l'interface graphique.</p>
|
||||||
|
</div>
|
||||||
|
<div class="roadmap-future-card">
|
||||||
|
<span class="roadmap-emoji">🔒</span>
|
||||||
|
<h4>BMad in a Box</h4>
|
||||||
|
<p>Auto-hébergé, isolé, niveau entreprise. Votre assistant IA, votre infrastructure, votre contrôle.</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<div style="text-align: center; margin-top: 3rem; padding: 2rem; background: var(--color-bg-card); border-radius: 12px; border: 1px solid var(--color-border);">
|
||||||
|
<h3 style="margin: 0 0 1rem;">Envie de contribuer ?</h3>
|
||||||
|
<p style="color: var(--slate-color-400); margin: 0;">
|
||||||
|
Ce n'est qu'une liste partielle de ce qui est prévu. L'équipe Open Source BMad accueille les contributeurs !{" "}<br />
|
||||||
|
<a href="https://github.com/bmad-code-org/BMAD-METHOD" style="color: var(--color-in-progress);">Rejoignez-nous sur GitHub</a> pour aider à façonner l'avenir du développement propulsé par l'IA.
|
||||||
|
</p>
|
||||||
|
<p style="color: var(--slate-color-400); margin: 1.5rem 0 0;">
|
||||||
|
Vous aimez ce que nous construisons ? Nous apprécions le soutien ponctuel et mensuel sur{" "}<a href="https://buymeacoffee.com/bmad" style="color: var(--color-in-progress);">Buy Me a Coffee</a>.
|
||||||
|
</p>
|
||||||
|
<p style="color: var(--slate-color-400); margin: 1rem 0 0;">
|
||||||
|
Pour les parrainages d'entreprise, les demandes de partenariat, les interventions, les formations ou les demandes médias :{" "}
|
||||||
|
<a href="mailto:contact@bmadcode.com" style="color: var(--color-in-progress);">contact@bmadcode.com</a>
|
||||||
|
</p>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
@ -0,0 +1,279 @@
|
||||||
|
---
|
||||||
|
title: "Premiers pas"
|
||||||
|
description: Installer BMad et construire votre premier projet
|
||||||
|
---
|
||||||
|
|
||||||
|
Construisez des logiciels plus rapidement en utilisant des workflows propulsés par l'IA avec des agents spécialisés qui vous guident à travers la planification, l'architecture et l'implémentation.
|
||||||
|
|
||||||
|
## Ce que vous allez apprendre
|
||||||
|
|
||||||
|
- Installer et initialiser la méthode BMad pour un nouveau projet
|
||||||
|
- Utiliser **BMad-Help** — votre guide intelligent qui sait quoi faire ensuite
|
||||||
|
- Choisir la bonne voie de planification selon la taille de votre projet
|
||||||
|
- Progresser à travers les phases, des exigences au code fonctionnel
|
||||||
|
- Utiliser efficacement les agents et les workflows
|
||||||
|
|
||||||
|
:::note[Prérequis]
|
||||||
|
- **Node.js 20+** — Requis pour l'installateur
|
||||||
|
- **Git** — Recommandé pour le contrôle de version
|
||||||
|
- **IDE IA** — Claude Code, Cursor, ou similaire
|
||||||
|
- **Une idée de projet** — Même simple, elle fonctionne pour apprendre
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::tip[Le chemin le plus simple]
|
||||||
|
**Installer** → `npx bmad-method install`
|
||||||
|
**Demander** → `bmad-help que dois-je faire en premier ?`
|
||||||
|
**Construire** → Laissez BMad-Help vous guider workflow par workflow
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Découvrez BMad-Help : votre guide intelligent
|
||||||
|
|
||||||
|
**BMad-Help est le moyen le plus rapide de démarrer avec BMad.** Vous n'avez pas besoin de mémoriser les workflows ou les phases — posez simplement la question, et BMad-Help va :
|
||||||
|
|
||||||
|
- **Inspecter votre projet** pour voir ce qui a déjà été fait
|
||||||
|
- **Vous montrer vos options** en fonction des modules que vous avez installés
|
||||||
|
- **Recommander la prochaine étape** — y compris la première tâche obligatoire
|
||||||
|
- **Répondre aux questions** comme « J'ai une idée de SaaS, par où commencer ? »
|
||||||
|
|
||||||
|
### Comment utiliser BMad-Help
|
||||||
|
|
||||||
|
Exécutez-le dans votre IDE avec IA en invoquant la skill :
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help
|
||||||
|
```
|
||||||
|
|
||||||
|
Ou combinez-le avec une question pour obtenir des conseils adaptés au contexte :
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help J'ai une idée de produit SaaS, je connais déjà toutes les fonctionnalités que je veux. Par où dois-je commencer ?
|
||||||
|
```
|
||||||
|
|
||||||
|
BMad-Help répondra avec :
|
||||||
|
- Ce qui est recommandé pour votre situation
|
||||||
|
- Quelle est la première tâche obligatoire
|
||||||
|
- À quoi ressemble le reste du processus
|
||||||
|
|
||||||
|
### Il alimente aussi les workflows
|
||||||
|
|
||||||
|
BMad-Help ne se contente pas de répondre aux questions — **il s'exécute automatiquement à la fin de chaque workflow** pour vous dire exactement quoi faire ensuite. Pas de devinettes, pas de recherche dans la documentation — juste des conseils clairs sur le prochain workflow requis.
|
||||||
|
|
||||||
|
:::tip[Commencez ici]
|
||||||
|
Après avoir installé BMad, invoquez immédiatement la skill `bmad-help`. Elle détectera les modules que vous avez installés et vous guidera vers le bon point de départ pour votre projet.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Comprendre BMad
|
||||||
|
|
||||||
|
BMad vous aide à construire des logiciels grâce à des workflows guidés avec des agents IA spécialisés. Le processus suit quatre phases :
|
||||||
|
|
||||||
|
| Phase | Nom | Ce qui se passe |
|
||||||
|
|-------|----------------|----------------------------------------------------------------|
|
||||||
|
| 1 | Analyse | Brainstorming, recherche, product brief *(optionnel)* |
|
||||||
|
| 2 | Planification | Créer les exigences (PRD[^1] ou spécification technique) |
|
||||||
|
| 3 | Solutioning | Concevoir l'architecture *(BMad Method/Enterprise uniquement)* |
|
||||||
|
| 4 | Implémentation | Construire epic[^2] par epic, story[^3] par story |
|
||||||
|
|
||||||
|
**[Ouvrir la carte des workflows](../reference/workflow-map.md)** pour explorer les phases, les workflows et la gestion du contexte.
|
||||||
|
|
||||||
|
Selon la complexité de votre projet, BMad propose trois voies de planification :
|
||||||
|
|
||||||
|
| Voie | Idéal pour | Documents créés |
|
||||||
|
|------------------|------------------------------------------------------------------------------|----------------------------------------|
|
||||||
|
| **Quick Dev** | Corrections de bugs, fonctionnalités simples, périmètre clair (1-15 stories) | Spécification technique uniquement |
|
||||||
|
| **méthode BMad** | Produits, plateformes, fonctionnalités complexes (10-50+ stories) | PRD + Architecture + UX[^4] |
|
||||||
|
| **Enterprise** | Conformité, systèmes multi-tenant[^5] (30+ stories) | PRD + Architecture + Security + DevOps |
|
||||||
|
|
||||||
|
:::note
|
||||||
|
Les comptes de stories sont indicatifs, pas des définitions. Choisissez votre voie en fonction des besoins de planification, pas du calcul des stories.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Installation
|
||||||
|
|
||||||
|
Ouvrez un terminal dans le répertoire de votre projet et exécutez :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npx bmad-method install
|
||||||
|
```
|
||||||
|
|
||||||
|
Si vous souhaitez la version préliminaire la plus récente au lieu du canal de release par défaut, utilisez `npx bmad-method@next install`.
|
||||||
|
|
||||||
|
Lorsque vous êtes invité à sélectionner des modules, choisissez **méthode BMad**.
|
||||||
|
|
||||||
|
L'installateur crée deux dossiers :
|
||||||
|
- `_bmad/` — agents, workflows, tâches et configuration
|
||||||
|
- `_bmad-output/` — vide pour l'instant, mais c'est là que vos artefacts seront enregistrés
|
||||||
|
|
||||||
|
:::tip[Votre prochaine étape]
|
||||||
|
Ouvrez votre IDE avec IA dans le dossier du projet et exécutez :
|
||||||
|
|
||||||
|
```
|
||||||
|
bmad-help
|
||||||
|
```
|
||||||
|
|
||||||
|
BMad-Help détectera ce que vous avez accompli et recommandera exactement quoi faire ensuite. Vous pouvez aussi lui poser des questions comme « Quelles sont mes options ? » ou « J'ai une idée de SaaS, par où devrais-je commencer ? »
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::note[Comment charger les agents et exécuter les workflows]
|
||||||
|
Chaque workflow possède une **skill** que vous invoquez par nom dans votre IDE (par ex., `bmad-create-prd`). Votre outil IA reconnaîtra le nom `bmad-*` et l'exécutera.
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::caution[Nouveaux chats]
|
||||||
|
Démarrez toujours un nouveau chat pour chaque workflow. Cela évite que les limitations de contexte ne causent des problèmes.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Étape 1 : Créer votre plan
|
||||||
|
|
||||||
|
Travaillez à travers les phases 1-3. **Utilisez de nouveaux chats pour chaque workflow.**
|
||||||
|
|
||||||
|
:::tip[Contexte de projet (Optionnel)]
|
||||||
|
Avant de commencer, envisagez de créer `project-context.md` pour documenter vos préférences techniques et règles d'implémentation. Cela garantit que tous les agents IA suivent vos conventions tout au long du projet.
|
||||||
|
|
||||||
|
Créez-le manuellement dans `_bmad-output/project-context.md` ou générez-le après l'architecture en utilisant `bmad-generate-project-context`. [En savoir plus](../explanation/project-context.md).
|
||||||
|
:::
|
||||||
|
|
||||||
|
### Phase 1 : Analyse (Optionnel)
|
||||||
|
|
||||||
|
Tous les workflows de cette phase sont optionnels :
|
||||||
|
- **brainstorming** (`bmad-brainstorming`) — Idéation guidée
|
||||||
|
- **research** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Recherche marché, domaine et technique
|
||||||
|
- **create-product-brief** (`bmad-create-product-brief`) — Document de base recommandé
|
||||||
|
|
||||||
|
### Phase 2 : Planification (Requis)
|
||||||
|
|
||||||
|
**Pour les voies BMad Method et Enterprise :**
|
||||||
|
1. Exécutez `bmad-create-prd` dans un nouveau chat
|
||||||
|
2. Sortie : `PRD.md`
|
||||||
|
|
||||||
|
**Pour la voie Quick Dev :**
|
||||||
|
- Utilisez le workflow `bmad-quick-dev` (`bmad-quick-dev`) à la place du PRD, puis passez à l'implémentation
|
||||||
|
|
||||||
|
:::note[Design UX (Optionnel)]
|
||||||
|
Si votre projet a une interface utilisateur, exécutez le workflow de design UX (`bmad-create-ux-design`) après avoir créé votre PRD.
|
||||||
|
:::
|
||||||
|
|
||||||
|
### Phase 3 : Solutioning (méthode BMad/Enterprise)
|
||||||
|
|
||||||
|
**Créer l'Architecture**
|
||||||
|
1. Exécutez `bmad-create-architecture` dans un nouveau chat
|
||||||
|
2. Sortie : Document d'architecture avec les décisions techniques
|
||||||
|
|
||||||
|
**Créer les Epics et Stories**
|
||||||
|
|
||||||
|
:::tip[Amélioration V6]
|
||||||
|
Les epics et stories sont maintenant créés *après* l'architecture. Cela produit des stories de meilleure qualité car les décisions d'architecture (base de données, patterns d'API, pile technologique) affectent directement la façon dont le travail doit être décomposé.
|
||||||
|
:::
|
||||||
|
|
||||||
|
1. Exécutez `bmad-create-epics-and-stories` dans un nouveau chat
|
||||||
|
2. Le workflow utilise à la fois le PRD et l'Architecture pour créer des stories techniquement éclairées
|
||||||
|
|
||||||
|
**Vérification de préparation à l'implémentation** *(Hautement recommandé)*
|
||||||
|
1. Exécutez `bmad-check-implementation-readiness` dans un nouveau chat
|
||||||
|
2. Valide la cohérence entre tous les documents de planification
|
||||||
|
|
||||||
|
## Étape 2 : Construire votre projet
|
||||||
|
|
||||||
|
Une fois la planification terminée, passez à l'implémentation. **Chaque workflow doit s'exécuter dans un nouveau chat.**
|
||||||
|
|
||||||
|
### Initialiser la planification de sprint
|
||||||
|
|
||||||
|
Exécutez `bmad-sprint-planning` dans un nouveau chat. Cela crée `sprint-status.yaml` pour suivre tous les epics et stories.
|
||||||
|
|
||||||
|
### Le cycle de construction
|
||||||
|
|
||||||
|
Pour chaque story, répétez ce cycle avec de nouveaux chats :
|
||||||
|
|
||||||
|
| Étape | Workflow | Commande | Objectif |
|
||||||
|
| ----- | --------------------- | --------------------- | ----------------------------------- |
|
||||||
|
| 1 | `bmad-create-story` | `bmad-create-story` | Créer le fichier story depuis l'epic |
|
||||||
|
| 2 | `bmad-dev-story` | `bmad-dev-story` | Implémenter la story |
|
||||||
|
| 3 | `bmad-code-review` | `bmad-code-review` | Validation de qualité *(recommandé)* |
|
||||||
|
|
||||||
|
Après avoir terminé toutes les stories d'un epic, exécutez `bmad-retrospective` dans un nouveau chat.
|
||||||
|
|
||||||
|
## Ce que vous avez accompli
|
||||||
|
|
||||||
|
Vous avez appris les fondamentaux de la construction avec BMad :
|
||||||
|
|
||||||
|
- Installé BMad et configuré pour votre IDE
|
||||||
|
- Initialisé un projet avec votre voie de planification choisie
|
||||||
|
- Créé des documents de planification (PRD, Architecture, Epics & Stories)
|
||||||
|
- Compris le cycle de construction pour l'implémentation
|
||||||
|
|
||||||
|
Votre projet contient maintenant :
|
||||||
|
|
||||||
|
```text
|
||||||
|
your-project/
|
||||||
|
├── _bmad/ # Configuration BMad
|
||||||
|
├── _bmad-output/
|
||||||
|
│ ├── planning-artifacts/
|
||||||
|
│ │ ├── PRD.md # Votre document d'exigences
|
||||||
|
│ │ ├── architecture.md # Décisions techniques
|
||||||
|
│ │ └── epics/ # Fichiers epic et story
|
||||||
|
│ ├── implementation-artifacts/
|
||||||
|
│ │ └── sprint-status.yaml # Suivi de sprint
|
||||||
|
│ └── project-context.md # Règles d'implémentation (optionnel)
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
|
||||||
|
## Référence rapide
|
||||||
|
|
||||||
|
| Workflow | Commande | Objectif |
|
||||||
|
| ------------------------------------- | ------------------------------------------- | ------------------------------------------------ |
|
||||||
|
| **`bmad-help`** ⭐ | `bmad-help` | **Votre guide intelligent — posez n'importe quelle question !** |
|
||||||
|
| `bmad-create-prd` | `bmad-create-prd` | Créer le document d'exigences produit |
|
||||||
|
| `bmad-create-architecture` | `bmad-create-architecture` | Créer le document d'architecture |
|
||||||
|
| `bmad-generate-project-context` | `bmad-generate-project-context` | Créer le fichier de contexte projet |
|
||||||
|
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | Décomposer le PRD en epics |
|
||||||
|
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Valider la cohérence de planification |
|
||||||
|
| `bmad-sprint-planning` | `bmad-sprint-planning` | Initialiser le suivi de sprint |
|
||||||
|
| `bmad-create-story` | `bmad-create-story` | Créer un fichier story |
|
||||||
|
| `bmad-dev-story` | `bmad-dev-story` | Implémenter une story |
|
||||||
|
| `bmad-code-review` | `bmad-code-review` | Revoir le code implémenté |
|
||||||
|
|
||||||
|
## Questions fréquentes
|
||||||
|
|
||||||
|
**Ai-je toujours besoin d'une architecture ?**
|
||||||
|
Uniquement pour les voies méthode BMad et Enterprise. Quick Dev passe directement de la spécification technique (spec) à l'implémentation.
|
||||||
|
|
||||||
|
**Puis-je modifier mon plan plus tard ?**
|
||||||
|
Oui. Utilisez `bmad-correct-course` pour gérer les changements de périmètre.
|
||||||
|
|
||||||
|
**Et si je veux d'abord faire du brainstorming ?**
|
||||||
|
Invoquez l'agent Analyst (`bmad-agent-analyst`) et exécutez `bmad-brainstorming` (`bmad-brainstorming`) avant de commencer votre PRD.
|
||||||
|
|
||||||
|
**Dois-je suivre un ordre strict ?**
|
||||||
|
Pas strictement. Une fois que vous maîtrisez le flux, vous pouvez exécuter les workflows directement en utilisant la référence rapide ci-dessus.
|
||||||
|
|
||||||
|
## Obtenir de l'aide
|
||||||
|
|
||||||
|
:::tip[Premier arrêt : BMad-Help]
|
||||||
|
**Invoquez `bmad-help` à tout moment** — c'est le moyen le plus rapide de se débloquer. Posez n'importe quelle question :
|
||||||
|
- « Que dois-je faire après l'installation ? »
|
||||||
|
- « Je suis bloqué sur le workflow X »
|
||||||
|
- « Quelles sont mes options pour Y ? »
|
||||||
|
- « Montre-moi ce qui a été fait jusqu'ici »
|
||||||
|
|
||||||
|
BMad-Help inspecte votre projet, détecte ce que vous avez accompli et vous dit exactement quoi faire ensuite.
|
||||||
|
:::
|
||||||
|
|
||||||
|
- **Pendant les workflows** — Les agents vous guident avec des questions et des explications
|
||||||
|
- **Communauté** — [Discord](https://discord.gg/gk8jAdXWmj) (#bmad-method-help, #report-bugs-and-issues)
|
||||||
|
|
||||||
|
## Points clés à retenir
|
||||||
|
|
||||||
|
:::tip[Retenez ceci]
|
||||||
|
- **Commencez par `bmad-help`** — Votre guide intelligent qui connaît votre projet et vos options
|
||||||
|
- **Utilisez toujours de nouveaux chats** — Démarrez un nouveau chat pour chaque workflow
|
||||||
|
- **La voie compte** — Quick Dev utilise `bmad-quick-dev` ; La méthode BMad/Enterprise nécessitent PRD et architecture
|
||||||
|
- **BMad-Help s'exécute automatiquement** — Chaque workflow se termine par des conseils sur la prochaine étape
|
||||||
|
:::
|
||||||
|
|
||||||
|
Prêt à commencer ? Installez BMad, invoquez `bmad-help`, et laissez votre guide intelligent vous montrer le chemin.
|
||||||
|
|
||||||
|
## Glossaire
|
||||||
|
|
||||||
|
[^1]: PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d'aligner les équipes sur ce qui doit être construit et pourquoi.
|
||||||
|
[^2]: Epic : grand ensemble de fonctionnalités ou de travaux qui peut être décomposé en plusieurs user stories.
|
||||||
|
[^3]: Story (User Story) : description courte et simple d'une fonctionnalité du point de vue de l'utilisateur ou du client. Elle représente une unité de travail implémentable en un court délai.
|
||||||
|
[^4]: UX (User Experience) : expérience utilisateur, englobant l'ensemble des interactions et perceptions d'un utilisateur face à un produit. Le design UX vise à créer des interfaces intuitives, efficaces et agréables en tenant compte des besoins, comportements et contexte d'utilisation.
|
||||||
|
[^5]: Multi-tenant : architecture logicielle où une seule instance de l'application sert plusieurs clients (tenants) tout en maintenant leurs données isolées et sécurisées les unes des autres.
|
||||||
|
|
@ -85,7 +85,7 @@ Add persistent context the agent will always remember:
|
||||||
```yaml
|
```yaml
|
||||||
memories:
|
memories:
|
||||||
- 'Works at Krusty Krab'
|
- 'Works at Krusty Krab'
|
||||||
- 'Favorite Celebrity: David Hasslehoff'
|
- 'Favorite Celebrity: David Hasselhoff'
|
||||||
- 'Learned in Epic 1 that it is not cool to just pretend that tests have passed'
|
- 'Learned in Epic 1 that it is not cool to just pretend that tests have passed'
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
@ -128,7 +128,7 @@ prompts:
|
||||||
|
|
||||||
### 3. Apply Your Changes
|
### 3. Apply Your Changes
|
||||||
|
|
||||||
After editing, recompile the agent to apply changes:
|
After editing, reinstall to apply changes:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
npx bmad-method install
|
npx bmad-method install
|
||||||
|
|
@ -138,17 +138,16 @@ The installer detects the existing installation and offers these options:
|
||||||
|
|
||||||
| Option | What It Does |
|
| Option | What It Does |
|
||||||
| ---------------------------- | ------------------------------------------------------------------- |
|
| ---------------------------- | ------------------------------------------------------------------- |
|
||||||
| **Quick Update** | Updates all modules to the latest version and recompiles all agents |
|
| **Quick Update** | Updates all modules to the latest version and applies customizations |
|
||||||
| **Recompile Agents** | Applies customizations only, without updating module files |
|
|
||||||
| **Modify BMad Installation** | Full installation flow for adding or removing modules |
|
| **Modify BMad Installation** | Full installation flow for adding or removing modules |
|
||||||
|
|
||||||
For customization-only changes, **Recompile Agents** is the fastest option.
|
For customization-only changes, **Quick Update** is the fastest option.
|
||||||
|
|
||||||
## Troubleshooting
|
## Troubleshooting
|
||||||
|
|
||||||
**Changes not appearing?**
|
**Changes not appearing?**
|
||||||
|
|
||||||
- Run `npx bmad-method install` and select **Recompile Agents** to apply changes
|
- Run `npx bmad-method install` and select **Quick Update** to apply changes
|
||||||
- Check that your YAML syntax is valid (indentation matters)
|
- Check that your YAML syntax is valid (indentation matters)
|
||||||
- Verify you edited the correct `.customize.yaml` file for the agent
|
- Verify you edited the correct `.customize.yaml` file for the agent
|
||||||
|
|
||||||
|
|
@ -161,7 +160,7 @@ For customization-only changes, **Recompile Agents** is the fastest option.
|
||||||
**Need to reset an agent?**
|
**Need to reset an agent?**
|
||||||
|
|
||||||
- Clear or delete the agent's `.customize.yaml` file
|
- Clear or delete the agent's `.customize.yaml` file
|
||||||
- Run `npx bmad-method install` and select **Recompile Agents** to restore defaults
|
- Run `npx bmad-method install` and select **Quick Update** to restore defaults
|
||||||
|
|
||||||
## Workflow Customization
|
## Workflow Customization
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -81,7 +81,7 @@ You have two primary options depending on the scope of changes:
|
||||||
|
|
||||||
| Scope | Recommended Approach |
|
| Scope | Recommended Approach |
|
||||||
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
|
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||||
| **Small updates or additions** | Use `bmad-quick-flow-solo-dev` to create a tech-spec and implement the change. The full four-phase BMad Method is likely overkill. |
|
| **Small updates or additions** | Run `bmad-quick-dev` to clarify intent, plan, implement, and review in a single workflow. The full four-phase BMad Method is likely overkill. |
|
||||||
| **Major changes or additions** | Start with the BMad Method, applying as much or as little rigor as needed. |
|
| **Major changes or additions** | Start with the BMad Method, applying as much or as little rigor as needed. |
|
||||||
|
|
||||||
### During PRD Creation
|
### During PRD Creation
|
||||||
|
|
|
||||||
|
|
@ -5,113 +5,55 @@ sidebar:
|
||||||
order: 4
|
order: 4
|
||||||
---
|
---
|
||||||
|
|
||||||
## Start Here: BMad-Help
|
Use BMad's built-in help, source docs, or the community to get answers — from quickest to most thorough.
|
||||||
|
|
||||||
**The fastest way to get answers about BMad is the `bmad-help` skill.** This intelligent guide will answer upwards of 80% of all questions and is available to you directly in your IDE as you work.
|
## 1. Ask BMad-Help
|
||||||
|
|
||||||
BMad-Help is more than a lookup tool — it:
|
The fastest way to get answers. The `bmad-help` skill is available directly in your AI session and handles over 80% of questions — it inspects your project, sees what you've completed, and tells you what to do next.
|
||||||
- **Inspects your project** to see what's already been completed
|
|
||||||
- **Understands natural language** — ask questions in plain English
|
|
||||||
- **Varies based on your installed modules** — shows relevant options
|
|
||||||
- **Auto-runs after workflows** — tells you exactly what to do next
|
|
||||||
- **Recommends the first required task** — no guessing where to start
|
|
||||||
|
|
||||||
### How to Use BMad-Help
|
|
||||||
|
|
||||||
Call it by name in your AI session:
|
|
||||||
|
|
||||||
```
|
```
|
||||||
bmad-help
|
bmad-help I have a SaaS idea and know all the features. Where do I start?
|
||||||
|
bmad-help What are my options for UX design?
|
||||||
|
bmad-help I'm stuck on the PRD workflow
|
||||||
```
|
```
|
||||||
|
|
||||||
:::tip
|
:::tip
|
||||||
You can also use `/bmad-help` or `$bmad-help` depending on your platform, but just `bmad-help` should work everywhere.
|
You can also use `/bmad-help` or `$bmad-help` depending on your platform, but just `bmad-help` should work everywhere.
|
||||||
:::
|
:::
|
||||||
|
|
||||||
Combine it with a natural language query:
|
## 2. Go Deeper with Source
|
||||||
|
|
||||||
```
|
BMad-Help draws on your installed configuration. For questions about BMad's internals, history, or architecture — or if you're researching BMad before installing — point your AI at the source directly.
|
||||||
bmad-help I have a SaaS idea and know all the features. Where do I start?
|
|
||||||
bmad-help What are my options for UX design?
|
|
||||||
bmad-help I'm stuck on the PRD workflow
|
|
||||||
bmad-help Show me what's been done so far
|
|
||||||
```
|
|
||||||
|
|
||||||
BMad-Help responds with:
|
Clone or open the [BMAD-METHOD repo](https://github.com/bmad-code-org/BMAD-METHOD) and ask your AI about it. Any agent-capable tool (Claude Code, Cursor, Windsurf, etc.) can read the source and answer questions directly.
|
||||||
- What's recommended for your situation
|
|
||||||
- What the first required task is
|
|
||||||
- What the rest of the process looks like
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## When to Use This Guide
|
|
||||||
|
|
||||||
Use this section when:
|
|
||||||
- You want to understand BMad's architecture or internals
|
|
||||||
- You need answers outside of what BMad-Help provides
|
|
||||||
- You're researching BMad before installing
|
|
||||||
- You want to explore the source code directly
|
|
||||||
|
|
||||||
## Steps
|
|
||||||
|
|
||||||
### 1. Choose Your Source
|
|
||||||
|
|
||||||
| Source | Best For | Examples |
|
|
||||||
| -------------------- | ----------------------------------------- | ---------------------------- |
|
|
||||||
| **`_bmad` folder** | How BMad works—agents, workflows, prompts | "What does the PM agent do?" |
|
|
||||||
| **Full GitHub repo** | History, installer, architecture | "What changed in v6?" |
|
|
||||||
| **`llms-full.txt`** | Quick overview from docs | "Explain BMad's four phases" |
|
|
||||||
|
|
||||||
The `_bmad` folder is created when you install BMad. If you don't have it yet, clone the repo instead.
|
|
||||||
|
|
||||||
### 2. Point Your AI at the Source
|
|
||||||
|
|
||||||
**If your AI can read files (Claude Code, Cursor, etc.):**
|
|
||||||
|
|
||||||
- **BMad installed:** Point at the `_bmad` folder and ask directly
|
|
||||||
- **Want deeper context:** Clone the [full repo](https://github.com/bmad-code-org/BMAD-METHOD)
|
|
||||||
|
|
||||||
**If you use ChatGPT or Claude.ai:**
|
|
||||||
|
|
||||||
Fetch `llms-full.txt` into your session:
|
|
||||||
|
|
||||||
```text
|
|
||||||
https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
### 3. Ask Your Question
|
|
||||||
|
|
||||||
:::note[Example]
|
:::note[Example]
|
||||||
**Q:** "Tell me the fastest way to build something with BMad"
|
**Q:** "Tell me the fastest way to build something with BMad"
|
||||||
|
|
||||||
**A:** Use Quick Flow: Run `bmad-quick-spec` to write a technical specification, then `bmad-quick-dev` to implement it—skipping the full planning phases.
|
**A:** Use Quick Flow: Run `bmad-quick-dev` — it clarifies your intent, plans, implements, reviews, and presents results in a single workflow, skipping the full planning phases.
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## What You Get
|
**Tips for better answers:**
|
||||||
|
|
||||||
Direct answers about BMad—how agents work, what workflows do, why things are structured the way they are—without waiting for someone else to respond.
|
|
||||||
|
|
||||||
## Tips
|
|
||||||
|
|
||||||
- **Verify surprising answers** — LLMs occasionally get things wrong. Check the source file or ask on Discord.
|
|
||||||
- **Be specific** — "What does step 3 of the PRD workflow do?" beats "How does PRD work?"
|
- **Be specific** — "What does step 3 of the PRD workflow do?" beats "How does PRD work?"
|
||||||
|
- **Verify surprising claims** — LLMs occasionally get things wrong. Check the source file or ask on Discord.
|
||||||
|
|
||||||
## Still Stuck?
|
### Not using an agent? Use the docs site
|
||||||
|
|
||||||
Tried the LLM approach and still need help? You now have a much better question to ask.
|
If your AI can't read local files (ChatGPT, Claude.ai, etc.), fetch [llms-full.txt](https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt) into your session — it's a single-file snapshot of the BMad documentation.
|
||||||
|
|
||||||
|
## 3. Ask Someone
|
||||||
|
|
||||||
|
If neither BMad-Help nor the source answered your question, you now have a much better question to ask.
|
||||||
|
|
||||||
| Channel | Use For |
|
| Channel | Use For |
|
||||||
| ------------------------- | ------------------------------------------- |
|
| ------------------------- | ------------------------------------------- |
|
||||||
| `#bmad-method-help` | Quick questions (real-time chat) |
|
| `help-requests` forum | Questions |
|
||||||
| `help-requests` forum | Detailed questions (searchable, persistent) |
|
|
||||||
| `#suggestions-feedback` | Ideas and feature requests |
|
| `#suggestions-feedback` | Ideas and feature requests |
|
||||||
| `#report-bugs-and-issues` | Bug reports |
|
|
||||||
|
|
||||||
**Discord:** [discord.gg/gk8jAdXWmj](https://discord.gg/gk8jAdXWmj)
|
**Discord:** [discord.gg/gk8jAdXWmj](https://discord.gg/gk8jAdXWmj)
|
||||||
|
|
||||||
**GitHub Issues:** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) (for clear bugs)
|
**GitHub Issues:** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues)
|
||||||
|
|
||||||
*You!*
|
*You!*
|
||||||
*Stuck*
|
*Stuck*
|
||||||
*in the queue—*
|
*in the queue—*
|
||||||
|
|
|
||||||
|
|
@ -28,7 +28,7 @@ Requires [Node.js](https://nodejs.org) v20+ and `npx` (included with npm).
|
||||||
| `--modules <modules>` | Comma-separated module IDs | `--modules bmm,bmb` |
|
| `--modules <modules>` | Comma-separated module IDs | `--modules bmm,bmb` |
|
||||||
| `--tools <tools>` | Comma-separated tool/IDE IDs (use `none` to skip) | `--tools claude-code,cursor` or `--tools none` |
|
| `--tools <tools>` | Comma-separated tool/IDE IDs (use `none` to skip) | `--tools claude-code,cursor` or `--tools none` |
|
||||||
| `--custom-content <paths>` | Comma-separated paths to custom modules | `--custom-content ~/my-module,~/another-module` |
|
| `--custom-content <paths>` | Comma-separated paths to custom modules | `--custom-content ~/my-module,~/another-module` |
|
||||||
| `--action <type>` | Action for existing installations: `install` (default), `update`, `quick-update`, or `compile-agents` | `--action quick-update` |
|
| `--action <type>` | Action for existing installations: `install` (default), `update`, or `quick-update` | `--action quick-update` |
|
||||||
|
|
||||||
### Core Configuration
|
### Core Configuration
|
||||||
|
|
||||||
|
|
@ -37,7 +37,19 @@ Requires [Node.js](https://nodejs.org) v20+ and `npx` (included with npm).
|
||||||
| `--user-name <name>` | Name for agents to use | System username |
|
| `--user-name <name>` | Name for agents to use | System username |
|
||||||
| `--communication-language <lang>` | Agent communication language | English |
|
| `--communication-language <lang>` | Agent communication language | English |
|
||||||
| `--document-output-language <lang>` | Document output language | English |
|
| `--document-output-language <lang>` | Document output language | English |
|
||||||
| `--output-folder <path>` | Output folder path | _bmad-output |
|
| `--output-folder <path>` | Output folder path (see resolution rules below) | `_bmad-output` |
|
||||||
|
|
||||||
|
#### Output Folder Path Resolution
|
||||||
|
|
||||||
|
The value passed to `--output-folder` (or entered interactively) is resolved according to these rules:
|
||||||
|
|
||||||
|
| Input type | Example | Resolved as |
|
||||||
|
|------------|---------|-------------|
|
||||||
|
| Relative path (default) | `_bmad-output` | `<project-root>/_bmad-output` |
|
||||||
|
| Relative path with traversal | `../../shared-outputs` | Normalized absolute path — e.g. `/Users/me/shared-outputs` |
|
||||||
|
| Absolute path | `/Users/me/shared-outputs` | Used as-is — project root is **not** prepended |
|
||||||
|
|
||||||
|
The resolved path is what agents and workflows use at runtime when writing output files. Using an absolute path or a traversal-based relative path lets you direct all generated artifacts to a directory outside your project tree — useful for shared or monorepo setups.
|
||||||
|
|
||||||
### Other Options
|
### Other Options
|
||||||
|
|
||||||
|
|
@ -61,7 +73,7 @@ Available tool IDs for the `--tools` flag:
|
||||||
|
|
||||||
**Preferred:** `claude-code`, `cursor`
|
**Preferred:** `claude-code`, `cursor`
|
||||||
|
|
||||||
Run `npx bmad-method install` interactively once to see the full current list of supported tools, or check the [platform codes configuration](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/cli/installers/lib/ide/platform-codes.yaml).
|
Run `npx bmad-method install` interactively once to see the full current list of supported tools, or check the [platform codes configuration](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/installer/ide/platform-codes.yaml).
|
||||||
|
|
||||||
## Installation Modes
|
## Installation Modes
|
||||||
|
|
||||||
|
|
@ -121,7 +133,7 @@ npx bmad-method install \
|
||||||
## What You Get
|
## What You Get
|
||||||
|
|
||||||
- A fully configured `_bmad/` directory in your project
|
- A fully configured `_bmad/` directory in your project
|
||||||
- Compiled agents and workflows for your selected modules and tools
|
- Agents and workflows configured for your selected modules and tools
|
||||||
- A `_bmad-output/` folder for generated artifacts
|
- A `_bmad-output/` folder for generated artifacts
|
||||||
|
|
||||||
## Validation and Error Handling
|
## Validation and Error Handling
|
||||||
|
|
@ -132,7 +144,7 @@ BMad validates all provided flags:
|
||||||
- **Modules** — Warns about invalid module IDs (but won't fail)
|
- **Modules** — Warns about invalid module IDs (but won't fail)
|
||||||
- **Tools** — Warns about invalid tool IDs (but won't fail)
|
- **Tools** — Warns about invalid tool IDs (but won't fail)
|
||||||
- **Custom Content** — Each path must contain a valid `module.yaml` file
|
- **Custom Content** — Each path must contain a valid `module.yaml` file
|
||||||
- **Action** — Must be one of: `install`, `update`, `quick-update`, `compile-agents`
|
- **Action** — Must be one of: `install`, `update`, `quick-update`
|
||||||
|
|
||||||
Invalid values will either:
|
Invalid values will either:
|
||||||
1. Show an error and exit (for critical options like directory)
|
1. Show an error and exit (for critical options like directory)
|
||||||
|
|
@ -141,6 +153,7 @@ Invalid values will either:
|
||||||
|
|
||||||
:::tip[Best Practices]
|
:::tip[Best Practices]
|
||||||
- Use absolute paths for `--directory` to avoid ambiguity
|
- Use absolute paths for `--directory` to avoid ambiguity
|
||||||
|
- Use an absolute path for `--output-folder` when you want artifacts written outside the project tree (e.g. a shared monorepo outputs directory)
|
||||||
- Test flags locally before using in CI/CD pipelines
|
- Test flags locally before using in CI/CD pipelines
|
||||||
- Combine with `-y` for truly unattended installations
|
- Combine with `-y` for truly unattended installations
|
||||||
- Use `--debug` if you encounter issues during installation
|
- Use `--debug` if you encounter issues during installation
|
||||||
|
|
|
||||||
|
|
@ -2,10 +2,10 @@
|
||||||
title: "Manage Project Context"
|
title: "Manage Project Context"
|
||||||
description: Create and maintain project-context.md to guide AI agents
|
description: Create and maintain project-context.md to guide AI agents
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 7
|
order: 8
|
||||||
---
|
---
|
||||||
|
|
||||||
Use the `project-context.md` file to ensure AI agents follow your project's technical preferences and implementation rules throughout all workflows.
|
Use the `project-context.md` file to ensure AI agents follow your project's technical preferences and implementation rules throughout all workflows. To make sure this is always available, you can also add the line `Important project context and conventions are located in [path to project context]/project-context.md` to your tools context or always rules file (such as `AGENTS.md`)
|
||||||
|
|
||||||
:::note[Prerequisites]
|
:::note[Prerequisites]
|
||||||
- BMad Method installed
|
- BMad Method installed
|
||||||
|
|
@ -114,20 +114,11 @@ A `project-context.md` file that:
|
||||||
|
|
||||||
## Tips
|
## Tips
|
||||||
|
|
||||||
:::tip[Focus on the Unobvious]
|
:::tip[Best Practices]
|
||||||
Document patterns agents might miss such as "Use JSDoc style comments on every public class, function and variable", not universal practices like "use meaningful variable names" which LLMs know at this point.
|
- **Focus on the unobvious** — Document patterns agents might miss (e.g., "Use JSDoc on every public class"), not universal practices like "use meaningful variable names."
|
||||||
:::
|
- **Keep it lean** — This file is loaded by every implementation workflow. Long files waste context. Exclude content that only applies to narrow scope or specific stories.
|
||||||
|
- **Update as needed** — Edit manually when patterns change, or re-generate after significant architecture changes.
|
||||||
:::tip[Keep It Lean]
|
- Works for Quick Flow and full BMad Method projects alike.
|
||||||
This file is loaded by every implementation workflow. Long files waste context. Do not include content that only applies to narrow scope or specific stories or features.
|
|
||||||
:::
|
|
||||||
|
|
||||||
:::tip[Update as Needed]
|
|
||||||
Edit manually when patterns change, or re-generate after significant architecture changes.
|
|
||||||
:::
|
|
||||||
|
|
||||||
:::tip[Works for All Project Types]
|
|
||||||
Just as useful for Quick Flow as for full BMad Method projects.
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## Next Steps
|
## Next Steps
|
||||||
|
|
|
||||||
|
|
@ -5,119 +5,91 @@ sidebar:
|
||||||
order: 5
|
order: 5
|
||||||
---
|
---
|
||||||
|
|
||||||
Use the **DEV agent** directly for bug fixes, refactorings, or small targeted changes that don't require the full BMad Method or Quick Flow.
|
Use **Quick Dev** for bug fixes, refactorings, or small targeted changes that don't require the full BMad Method.
|
||||||
|
|
||||||
## When to Use This
|
## When to Use This
|
||||||
|
|
||||||
- Bug fixes with a clear, known cause
|
- Bug fixes with a clear, known cause
|
||||||
- Small refactorings (rename, extract, restructure) contained within a few files
|
- Small refactorings (rename, extract, restructure) contained within a few files
|
||||||
- Minor feature tweaks or configuration changes
|
- Minor feature tweaks or configuration changes
|
||||||
- Exploratory work to understand an unfamiliar codebase
|
- Dependency updates
|
||||||
|
|
||||||
:::note[Prerequisites]
|
:::note[Prerequisites]
|
||||||
- BMad Method installed (`npx bmad-method install`)
|
- BMad Method installed (`npx bmad-method install`)
|
||||||
- An AI-powered IDE (Claude Code, Cursor, or similar)
|
- An AI-powered IDE (Claude Code, Cursor, or similar)
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## Choose Your Approach
|
|
||||||
|
|
||||||
| Situation | Agent | Why |
|
|
||||||
| --- | --- | --- |
|
|
||||||
| Fix a specific bug or make a small, scoped change | **DEV agent** | Jumps straight into implementation without planning overhead |
|
|
||||||
| Change touches several files or you want a written plan first | **Quick Flow Solo Dev** | Creates a quick-spec before implementation so the agent stays aligned to your standards |
|
|
||||||
|
|
||||||
If you are unsure, start with the DEV agent. You can always escalate to Quick Flow if the change grows.
|
|
||||||
|
|
||||||
## Steps
|
## Steps
|
||||||
|
|
||||||
### 1. Invoke the DEV Agent
|
### 1. Start a Fresh Chat
|
||||||
|
|
||||||
Start a **fresh chat** in your AI IDE and invoke the DEV agent skill:
|
Open a **fresh chat session** in your AI IDE. Reusing a session from a previous workflow can cause context conflicts.
|
||||||
|
|
||||||
|
### 2. Give It Your Intent
|
||||||
|
|
||||||
|
Quick Dev accepts free-form intent — before, with, or after the invocation. Examples:
|
||||||
|
|
||||||
```text
|
```text
|
||||||
bmad-dev
|
run quick-dev — Fix the login validation bug that allows empty passwords.
|
||||||
```
|
```
|
||||||
|
|
||||||
This loads the agent's persona and capabilities into the session. If you decide you need Quick Flow instead, invoke the **Quick Flow Solo Dev** agent skill in a fresh chat:
|
|
||||||
|
|
||||||
```text
|
```text
|
||||||
bmad-quick-flow-solo-dev
|
run quick-dev — fix https://github.com/org/repo/issues/42
|
||||||
```
|
```
|
||||||
|
|
||||||
Once the Solo Dev agent is loaded, describe your change and ask it to create a **quick-spec**. The agent drafts a lightweight spec capturing what you want to change and how. After you approve the quick-spec, tell the agent to start the **Quick Flow dev cycle** -- it will implement the change, run tests, and perform a self-review, all guided by the spec you just approved.
|
```text
|
||||||
|
run quick-dev — implement the intent in _bmad-output/implementation-artifacts/my-intent.md
|
||||||
|
```
|
||||||
|
|
||||||
:::tip[Fresh Chats]
|
```text
|
||||||
Always start a new chat session when loading an agent. Reusing a session from a previous workflow can cause context conflicts.
|
I think the problem is in the auth middleware, it's not checking token expiry.
|
||||||
:::
|
Let me look at it... yeah, src/auth/middleware.ts line 47 skips
|
||||||
|
the exp check entirely. run quick-dev
|
||||||
|
```
|
||||||
|
|
||||||
### 2. Describe the Change
|
```text
|
||||||
|
run quick-dev
|
||||||
|
> What would you like to do?
|
||||||
|
Refactor UserService to use async/await instead of callbacks.
|
||||||
|
```
|
||||||
|
|
||||||
Tell the agent what you need in plain language. Be specific about the problem and, if you know it, where the relevant code lives.
|
Plain text, file paths, GitHub issue URLs, bug tracker links — anything the LLM can resolve to a concrete intent.
|
||||||
|
|
||||||
:::note[Example Prompts]
|
### 3. Answer Questions and Approve
|
||||||
**Bug fix** -- "Fix the login validation bug that allows empty passwords. The validation logic is in `src/auth/validate.ts`."
|
|
||||||
|
|
||||||
**Refactoring** -- "Refactor the UserService to use async/await instead of callbacks."
|
Quick Dev may ask clarifying questions or present a short spec for your approval before implementing. Answer its questions and approve when you're satisfied with the plan.
|
||||||
|
|
||||||
**Configuration change** -- "Update the CI pipeline to cache node_modules between runs."
|
### 4. Review and Push
|
||||||
|
|
||||||
**Dependency update** -- "Upgrade the express dependency to the latest v5 release and fix any breaking changes."
|
Quick Dev implements the change, reviews its own work, patches issues, and commits locally. When it's done, it opens the affected files in your editor.
|
||||||
:::
|
|
||||||
|
|
||||||
You don't need to provide every detail. The agent will read the relevant source files and ask clarifying questions when needed.
|
- 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 same session
|
||||||
|
|
||||||
### 3. Let the Agent Work
|
Once satisfied, push the commit. Quick Dev will offer to push and create a PR for you.
|
||||||
|
|
||||||
The agent will:
|
|
||||||
|
|
||||||
- Read and analyze the relevant source files
|
|
||||||
- Propose a solution and explain its reasoning
|
|
||||||
- Implement the change across the affected files
|
|
||||||
- Run your project's test suite if one exists
|
|
||||||
|
|
||||||
If your project has tests, the agent runs them automatically after making changes and iterates until tests pass. For projects without a test suite, verify the change manually (run the app, hit the endpoint, check the output).
|
|
||||||
|
|
||||||
### 4. Review and Verify
|
|
||||||
|
|
||||||
Before committing, review what changed:
|
|
||||||
|
|
||||||
- Read through the diff to confirm the change matches your intent
|
|
||||||
- Run the application or tests yourself to double-check
|
|
||||||
- If something looks wrong, tell the agent what to fix -- it can iterate in the same session
|
|
||||||
|
|
||||||
Once satisfied, commit the changes with a clear message describing the fix.
|
|
||||||
|
|
||||||
:::caution[If Something Breaks]
|
:::caution[If Something Breaks]
|
||||||
If a committed change causes unexpected issues, use `git revert HEAD` to undo the last commit cleanly. Then start a fresh chat with the DEV agent to try a different approach.
|
If a pushed change causes unexpected issues, use `git revert HEAD` to undo the last commit cleanly. Then start a fresh chat and run Quick Dev again to try a different approach.
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## Learning Your Codebase
|
|
||||||
|
|
||||||
The DEV agent is also useful for exploring unfamiliar code. Load it in a fresh chat and ask questions:
|
|
||||||
|
|
||||||
:::note[Example Prompts]
|
|
||||||
"Explain how the authentication system works in this codebase."
|
|
||||||
|
|
||||||
"Show me where error handling happens in the API layer."
|
|
||||||
|
|
||||||
"What does the `ProcessOrder` function do and what calls it?"
|
|
||||||
:::
|
|
||||||
|
|
||||||
Use the agent to learn about your project, understand how components connect, and explore unfamiliar areas before making changes.
|
|
||||||
|
|
||||||
## What You Get
|
## What You Get
|
||||||
|
|
||||||
- Modified source files with the fix or refactoring applied
|
- Modified source files with the fix or refactoring applied
|
||||||
- Passing tests (if your project has a test suite)
|
- Passing tests (if your project has a test suite)
|
||||||
- A clean commit describing the change
|
- A ready-to-push commit with a conventional commit message
|
||||||
|
|
||||||
No planning artifacts are produced -- that's the point of this approach.
|
## Deferred Work
|
||||||
|
|
||||||
|
Quick Dev keeps each run focused on a single goal. If your request contains multiple independent goals, or if the review surfaces pre-existing issues unrelated to your change, Quick Dev defers them to a file (`deferred-work.md` in your implementation artifacts directory) rather than trying to tackle everything at once.
|
||||||
|
|
||||||
|
Check this file after a run — it's your backlog of things to come back to. Each deferred item can be fed into a fresh Quick Dev run later.
|
||||||
|
|
||||||
## When to Upgrade to Formal Planning
|
## When to Upgrade to Formal Planning
|
||||||
|
|
||||||
Consider using [Quick Flow](../explanation/quick-flow.md) or the full BMad Method when:
|
Consider using the full BMad Method when:
|
||||||
|
|
||||||
- The change affects multiple systems or requires coordinated updates across many files
|
- The change affects multiple systems or requires coordinated updates across many files
|
||||||
- You are unsure about the scope and need a spec to think it through
|
- You are unsure about the scope and need requirements discovery first
|
||||||
- The fix keeps growing in complexity as you work on it
|
|
||||||
- You need documentation or architectural decisions recorded for the team
|
- You need documentation or architectural decisions recorded for the team
|
||||||
|
|
||||||
|
See [Quick Dev](../explanation/quick-dev.md) for more on how Quick Dev fits into the BMad Method.
|
||||||
|
|
|
||||||
|
|
@ -2,7 +2,7 @@
|
||||||
title: "Document Sharding Guide"
|
title: "Document Sharding Guide"
|
||||||
description: Split large markdown files into smaller organized files for better context management
|
description: Split large markdown files into smaller organized files for better context management
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 8
|
order: 9
|
||||||
---
|
---
|
||||||
|
|
||||||
Use the `bmad-shard-doc` tool if you need to split large markdown files into smaller, organized files for better context management.
|
Use the `bmad-shard-doc` tool if you need to split large markdown files into smaller, organized files for better context management.
|
||||||
|
|
|
||||||
|
|
@ -61,8 +61,8 @@ If you have stories created or implemented:
|
||||||
|
|
||||||
1. Complete the v6 installation
|
1. Complete the v6 installation
|
||||||
2. Place `epics.md` or `epics/epic*.md` in `_bmad-output/planning-artifacts/`
|
2. Place `epics.md` or `epics/epic*.md` in `_bmad-output/planning-artifacts/`
|
||||||
3. Run the Scrum Master's `bmad-sprint-planning` workflow
|
3. Run the Developer's `bmad-sprint-planning` workflow
|
||||||
4. Tell the SM which epics/stories are already complete
|
4. Tell the agent which epics/stories are already complete
|
||||||
|
|
||||||
## What You Get
|
## What You Get
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -13,17 +13,14 @@ This page lists the default BMM (Agile suite) agents that install with BMad Meth
|
||||||
|
|
||||||
- Each agent is available as a skill, generated by the installer. The skill ID (e.g., `bmad-dev`) is used to invoke the agent.
|
- Each agent is available as a skill, generated by the installer. The skill ID (e.g., `bmad-dev`) is used to invoke the agent.
|
||||||
- Triggers are the short menu codes (e.g., `CP`) and fuzzy matches shown in each agent menu.
|
- Triggers are the short menu codes (e.g., `CP`) and fuzzy matches shown in each agent menu.
|
||||||
- QA (Quinn) is the lightweight test automation agent in BMM. The full Test Architect (TEA) lives in its own module.
|
- QA test generation is handled by the `bmad-qa-generate-e2e-tests` workflow skill, available through the Developer agent. The full Test Architect (TEA) lives in its own module.
|
||||||
|
|
||||||
| Agent | Skill ID | Triggers | Primary workflows |
|
| Agent | Skill ID | Triggers | Primary workflows |
|
||||||
| --------------------------- | -------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------- |
|
| --------------------------- | -------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------- |
|
||||||
| Analyst (Mary) | `bmad-analyst` | `BP`, `RS`, `CB`, `DP` | Brainstorm Project, Research, Create Brief, Document Project |
|
| Analyst (Mary) | `bmad-analyst` | `BP`, `RS`, `CB`, `WB`, `DP` | Brainstorm Project, Research, Create Brief, PRFAQ Challenge, Document Project |
|
||||||
| Product Manager (John) | `bmad-pm` | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | Create/Validate/Edit PRD, Create Epics and Stories, Implementation Readiness, Correct Course |
|
| Product Manager (John) | `bmad-pm` | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | Create/Validate/Edit PRD, Create Epics and Stories, Implementation Readiness, Correct Course |
|
||||||
| Architect (Winston) | `bmad-architect` | `CA`, `IR` | Create Architecture, Implementation Readiness |
|
| Architect (Winston) | `bmad-architect` | `CA`, `IR` | Create Architecture, Implementation Readiness |
|
||||||
| Scrum Master (Bob) | `bmad-sm` | `SP`, `CS`, `ER`, `CC` | Sprint Planning, Create Story, Epic Retrospective, Correct Course |
|
| Developer (Amelia) | `bmad-agent-dev` | `DS`, `QD`, `QA`, `CR`, `SP`, `CS`, `ER` | Dev Story, Quick Dev, QA Test Generation, Code Review, Sprint Planning, Create Story, Epic Retrospective |
|
||||||
| Developer (Amelia) | `bmad-dev` | `DS`, `CR` | Dev Story, Code Review |
|
|
||||||
| QA Engineer (Quinn) | `bmad-qa` | `QA` | Automate (generate tests for existing features) |
|
|
||||||
| Quick Flow Solo Dev (Barry) | `bmad-master` | `QS`, `QD`, `CR` | Quick Spec, Quick Dev, Code Review |
|
|
||||||
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Create UX Design |
|
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Create UX Design |
|
||||||
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Document Project, Write Document, Update Standards, Mermaid Generate, Validate Doc, Explain Concept |
|
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Document Project, Write Document, Update Standards, Mermaid Generate, Validate Doc, Explain Concept |
|
||||||
|
|
||||||
|
|
@ -35,7 +32,7 @@ Agent menu triggers use two different invocation types. Knowing which type a tri
|
||||||
|
|
||||||
Most triggers load a structured workflow file. Type the trigger code and the agent starts the workflow, prompting you for input at each step.
|
Most triggers load a structured workflow file. Type the trigger code and the agent starts the workflow, prompting you for input at each step.
|
||||||
|
|
||||||
Examples: `CP` (Create PRD), `DS` (Dev Story), `CA` (Create Architecture), `QS` (Quick Spec)
|
Examples: `CP` (Create PRD), `DS` (Dev Story), `CA` (Create Architecture), `QD` (Quick Dev)
|
||||||
|
|
||||||
### Conversational triggers (arguments required)
|
### Conversational triggers (arguments required)
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -54,12 +54,12 @@ Each skill is a directory containing a `SKILL.md` file. For example, a Claude Co
|
||||||
│ └── SKILL.md
|
│ └── SKILL.md
|
||||||
├── bmad-create-prd/
|
├── bmad-create-prd/
|
||||||
│ └── SKILL.md
|
│ └── SKILL.md
|
||||||
├── bmad-dev/
|
├── bmad-agent-dev/
|
||||||
│ └── SKILL.md
|
│ └── SKILL.md
|
||||||
└── ...
|
└── ...
|
||||||
```
|
```
|
||||||
|
|
||||||
The directory name determines the skill name in your IDE. For example, the directory `bmad-dev/` registers the skill `bmad-dev`.
|
The directory name determines the skill name in your IDE. For example, the directory `bmad-agent-dev/` registers the skill `bmad-agent-dev`.
|
||||||
|
|
||||||
## How to Discover Your Skills
|
## How to Discover Your Skills
|
||||||
|
|
||||||
|
|
@ -79,10 +79,9 @@ Agent skills load a specialized AI persona with a defined role, communication st
|
||||||
|
|
||||||
| Example skill | Agent | Role |
|
| Example skill | Agent | Role |
|
||||||
| --- | --- | --- |
|
| --- | --- | --- |
|
||||||
| `bmad-dev` | Amelia (Developer) | Implements stories with strict adherence to specs |
|
| `bmad-agent-dev` | Amelia (Developer) | Implements stories with strict adherence to specs |
|
||||||
| `bmad-pm` | John (Product Manager) | Creates and validates PRDs |
|
| `bmad-pm` | John (Product Manager) | Creates and validates PRDs |
|
||||||
| `bmad-architect` | Winston (Architect) | Designs system architecture |
|
| `bmad-architect` | Winston (Architect) | Designs system architecture |
|
||||||
| `bmad-sm` | Bob (Scrum Master) | Manages sprints and stories |
|
|
||||||
|
|
||||||
See [Agents](./agents.md) for the full list of default agents and their triggers.
|
See [Agents](./agents.md) for the full list of default agents and their triggers.
|
||||||
|
|
||||||
|
|
@ -92,12 +91,14 @@ Workflow skills run a structured, multi-step process without loading an agent pe
|
||||||
|
|
||||||
| Example skill | Purpose |
|
| Example skill | Purpose |
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
|
| `bmad-product-brief` | Create a product brief — guided discovery when your concept is clear |
|
||||||
|
| `bmad-prfaq` | Working Backwards PRFAQ challenge to stress-test your product concept |
|
||||||
| `bmad-create-prd` | Create a Product Requirements Document |
|
| `bmad-create-prd` | Create a Product Requirements Document |
|
||||||
| `bmad-create-architecture` | Design system architecture |
|
| `bmad-create-architecture` | Design system architecture |
|
||||||
| `bmad-create-epics-and-stories` | Create epics and stories |
|
| `bmad-create-epics-and-stories` | Create epics and stories |
|
||||||
| `bmad-dev-story` | Implement a story |
|
| `bmad-dev-story` | Implement a story |
|
||||||
| `bmad-code-review` | Run a code review |
|
| `bmad-code-review` | Run a code review |
|
||||||
| `bmad-quick-spec` | Define an ad-hoc change (Quick Flow) |
|
| `bmad-quick-dev` | Unified quick flow — clarify intent, plan, implement, review, present |
|
||||||
|
|
||||||
See [Workflow Map](./workflow-map.md) for the complete workflow reference organized by phase.
|
See [Workflow Map](./workflow-map.md) for the complete workflow reference organized by phase.
|
||||||
|
|
||||||
|
|
@ -105,36 +106,25 @@ See [Workflow Map](./workflow-map.md) for the complete workflow reference organi
|
||||||
|
|
||||||
Tasks and tools are standalone operations that do not require an agent or workflow context.
|
Tasks and tools are standalone operations that do not require an agent or workflow context.
|
||||||
|
|
||||||
#### BMad-Help: Your Intelligent Guide
|
**BMad-Help: Your Intelligent Guide**
|
||||||
|
|
||||||
**`bmad-help`** is your primary interface for discovering what to do next. It's not just a lookup tool — it's an intelligent assistant that:
|
`bmad-help` is your primary interface for discovering what to do next. It inspects your project, understands natural language queries, and recommends the next required or optional step based on your installed modules.
|
||||||
|
|
||||||
- **Inspects your project** to see what's already been done
|
|
||||||
- **Understands natural language queries** — ask questions in plain English
|
|
||||||
- **Varies by installed modules** — shows options based on what you have
|
|
||||||
- **Auto-invokes after workflows** — every workflow ends with clear next steps
|
|
||||||
- **Recommends the first required task** — no guessing where to start
|
|
||||||
|
|
||||||
**Examples:**
|
|
||||||
|
|
||||||
|
:::note[Example]
|
||||||
```
|
```
|
||||||
bmad-help
|
bmad-help
|
||||||
bmad-help I have a SaaS idea and know all the features. Where do I start?
|
bmad-help I have a SaaS idea and know all the features. Where do I start?
|
||||||
bmad-help What are my options for UX design?
|
bmad-help What are my options for UX design?
|
||||||
bmad-help I'm stuck on the PRD workflow
|
|
||||||
```
|
```
|
||||||
|
:::
|
||||||
|
|
||||||
#### Other Tasks and Tools
|
**Other Core Tasks and Tools**
|
||||||
|
|
||||||
| Example skill | Purpose |
|
The core module includes 11 built-in tools — reviews, compression, brainstorming, document management, and more. See [Core Tools](./core-tools.md) for the complete reference.
|
||||||
| --- | --- |
|
|
||||||
| `bmad-shard-doc` | Split a large markdown file into smaller sections |
|
|
||||||
| `bmad-index-docs` | Index project documentation |
|
|
||||||
| `bmad-editorial-review-prose` | Review document prose quality |
|
|
||||||
|
|
||||||
## Naming Convention
|
## Naming Convention
|
||||||
|
|
||||||
All skills use the `bmad-` prefix followed by a descriptive name (e.g., `bmad-dev`, `bmad-create-prd`, `bmad-help`). See [Modules](./modules.md) for available modules.
|
All skills use the `bmad-` prefix followed by a descriptive name (e.g., `bmad-agent-dev`, `bmad-create-prd`, `bmad-help`). See [Modules](./modules.md) for available modules.
|
||||||
|
|
||||||
## Troubleshooting
|
## Troubleshooting
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,293 @@
|
||||||
|
---
|
||||||
|
title: Core Tools
|
||||||
|
description: Reference for all built-in tasks and workflows available in every BMad installation without additional modules.
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Every BMad installation includes a set of core skills that can be used in conjunction with any anything you are doing — standalone tasks and workflows that work across all projects, all modules, and all phases. These are always available regardless of which optional modules you install.
|
||||||
|
|
||||||
|
:::tip[Quick Path]
|
||||||
|
Run any core tool by typing its skill name (e.g., `bmad-help`) in your IDE. No agent session required.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
| Tool | Type | Purpose |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| [`bmad-help`](#bmad-help) | Task | Get context-aware guidance on what to do next |
|
||||||
|
| [`bmad-brainstorming`](#bmad-brainstorming) | Workflow | Facilitate interactive brainstorming sessions |
|
||||||
|
| [`bmad-party-mode`](#bmad-party-mode) | Workflow | Orchestrate multi-agent group discussions |
|
||||||
|
| [`bmad-distillator`](#bmad-distillator) | Task | Lossless LLM-optimized compression of documents |
|
||||||
|
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Task | Push LLM output through iterative refinement methods |
|
||||||
|
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | Task | Cynical review that finds what's missing and what's wrong |
|
||||||
|
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | Task | Exhaustive branching-path analysis for unhandled edge cases |
|
||||||
|
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | Task | Clinical copy-editing for communication clarity |
|
||||||
|
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | Task | Structural editing — cuts, merges, and reorganization |
|
||||||
|
| [`bmad-shard-doc`](#bmad-shard-doc) | Task | Split large markdown files into organized sections |
|
||||||
|
| [`bmad-index-docs`](#bmad-index-docs) | Task | Generate or update an index of all docs in a folder |
|
||||||
|
|
||||||
|
## bmad-help
|
||||||
|
|
||||||
|
**Your intelligent guide to what comes next.** — Inspects your project state, detects what's been done, and recommends the next required or optional step.
|
||||||
|
|
||||||
|
**Use it when:**
|
||||||
|
|
||||||
|
- You finished a workflow and want to know what's next
|
||||||
|
- You're new to BMad and need orientation
|
||||||
|
- You're stuck and want context-aware advice
|
||||||
|
- You installed new modules and want to see what's available
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
1. Scans your project for existing artifacts (PRD, architecture, stories, etc.)
|
||||||
|
2. Detects which modules are installed and their available workflows
|
||||||
|
3. Recommends next steps in priority order — required steps first, then optional
|
||||||
|
4. Presents each recommendation with the skill command and a brief description
|
||||||
|
|
||||||
|
**Input:** Optional query in natural language (e.g., `bmad-help I have a SaaS idea, where do I start?`)
|
||||||
|
|
||||||
|
**Output:** Prioritized list of recommended next steps with skill commands
|
||||||
|
|
||||||
|
## bmad-brainstorming
|
||||||
|
|
||||||
|
**Generate diverse ideas through interactive creative techniques.** — A facilitated brainstorming session that loads proven ideation methods from a technique library and guides you toward 100+ ideas before organizing.
|
||||||
|
|
||||||
|
**Use it when:**
|
||||||
|
|
||||||
|
- You're starting a new project and need to explore the problem space
|
||||||
|
- You're stuck generating ideas and need structured creativity
|
||||||
|
- You want to use proven ideation frameworks (SCAMPER, reverse brainstorming, etc.)
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
1. Sets up a brainstorming session with your topic
|
||||||
|
2. Loads creative techniques from a method library
|
||||||
|
3. Guides you through technique after technique, generating ideas
|
||||||
|
4. Applies anti-bias protocol — shifts creative domain every 10 ideas to prevent clustering
|
||||||
|
5. Produces an append-only session document with all ideas organized by technique
|
||||||
|
|
||||||
|
**Input:** Brainstorming topic or problem statement, optional context file
|
||||||
|
|
||||||
|
**Output:** `brainstorming-session-{date}.md` with all generated ideas
|
||||||
|
|
||||||
|
:::note[Quantity Target]
|
||||||
|
The magic happens in ideas 50–100. The workflow encourages generating 100+ ideas before organization.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## bmad-party-mode
|
||||||
|
|
||||||
|
**Orchestrate multi-agent group discussions.** — Loads all installed BMad agents and facilitates a natural conversation where each agent contributes from their unique expertise and personality.
|
||||||
|
|
||||||
|
**Use it when:**
|
||||||
|
|
||||||
|
- You need multiple expert perspectives on a decision
|
||||||
|
- You want agents to challenge each other's assumptions
|
||||||
|
- You're exploring a complex topic that spans multiple domains
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
1. Loads the agent manifest with all installed agent personalities
|
||||||
|
2. Analyzes your topic to select 2–3 most relevant agents
|
||||||
|
3. Agents take turns contributing, with natural cross-talk and disagreements
|
||||||
|
4. Rotates agent participation to ensure diverse perspectives over time
|
||||||
|
5. Exit with `goodbye`, `end party`, or `quit`
|
||||||
|
|
||||||
|
**Input:** Discussion topic or question, along with specification of personas you would like to participate (optional)
|
||||||
|
|
||||||
|
**Output:** Real-time multi-agent conversation with maintained agent personalities
|
||||||
|
|
||||||
|
## bmad-distillator
|
||||||
|
|
||||||
|
**Lossless LLM-optimized compression of source documents.** — Produces dense, token-efficient distillates that preserve all information for downstream LLM consumption. Verifiable through round-trip reconstruction.
|
||||||
|
|
||||||
|
**Use it when:**
|
||||||
|
|
||||||
|
- A document is too large for an LLM's context window
|
||||||
|
- You need token-efficient versions of research, specs, or planning artifacts
|
||||||
|
- You want to verify no information is lost during compression
|
||||||
|
- Agents will need to frequently reference and find information in it
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
1. **Analyze** — Reads source documents, identifies information density and structure
|
||||||
|
2. **Compress** — Converts prose to dense bullet-point format, strips decorative formatting
|
||||||
|
3. **Verify** — Checks completeness to ensure all original information is preserved
|
||||||
|
4. **Validate** (optional) — Round-trip reconstruction test proves lossless compression
|
||||||
|
|
||||||
|
**Input:**
|
||||||
|
|
||||||
|
- `source_documents` (required) — File paths, folder paths, or glob patterns
|
||||||
|
- `downstream_consumer` (optional) — What consumes this (e.g., "PRD creation")
|
||||||
|
- `token_budget` (optional) — Approximate target size
|
||||||
|
- `--validate` (flag) — Run round-trip reconstruction test
|
||||||
|
|
||||||
|
**Output:** Distillate markdown file(s) with compression ratio report (e.g., "3.2:1")
|
||||||
|
|
||||||
|
## bmad-advanced-elicitation
|
||||||
|
|
||||||
|
**Push LLM output through iterative refinement methods.** — Selects from a library of elicitation techniques to systematically improve content through multiple passes.
|
||||||
|
|
||||||
|
**Use it when:**
|
||||||
|
|
||||||
|
- LLM output feels shallow or generic
|
||||||
|
- You want to explore a topic from multiple analytical angles
|
||||||
|
- You're refining a critical document and want deeper thinking
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
1. Loads method registry with 5+ elicitation techniques
|
||||||
|
2. Selects 5 best-fit methods based on content type and complexity
|
||||||
|
3. Presents an interactive menu — pick a method, reshuffle, or list all
|
||||||
|
4. Applies the selected method to enhance the content
|
||||||
|
5. Re-presents options for iterative improvement until you select "Proceed"
|
||||||
|
|
||||||
|
**Input:** Content section to enhance
|
||||||
|
|
||||||
|
**Output:** Enhanced version of the content with improvements applied
|
||||||
|
|
||||||
|
## bmad-review-adversarial-general
|
||||||
|
|
||||||
|
**Cynical review that assumes problems exist and searches for them.** — Takes a skeptical, jaded reviewer perspective with zero patience for sloppy work. Looks for what's missing, not just what's wrong.
|
||||||
|
|
||||||
|
**Use it when:**
|
||||||
|
|
||||||
|
- You need quality assurance before finalizing a deliverable
|
||||||
|
- You want to stress-test a spec, story, or document
|
||||||
|
- You want to find gaps in coverage that optimistic reviews miss
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
1. Reads the content with a cynical, critical perspective
|
||||||
|
2. Identifies issues across completeness, correctness, and quality
|
||||||
|
3. Searches specifically for what's missing — not just what's present and wrong
|
||||||
|
4. Must find a minimum of 10 issues or re-analyzes deeper
|
||||||
|
|
||||||
|
**Input:**
|
||||||
|
|
||||||
|
- `content` (required) — Diff, spec, story, doc, or any artifact
|
||||||
|
- `also_consider` (optional) — Additional areas to keep in mind
|
||||||
|
|
||||||
|
**Output:** Markdown list of 10+ findings with descriptions
|
||||||
|
|
||||||
|
## bmad-review-edge-case-hunter
|
||||||
|
|
||||||
|
**Walk every branching path and boundary condition, report only unhandled cases.** — Pure path-tracing methodology that mechanically derives edge classes. Orthogonal to adversarial review — method-driven, not attitude-driven.
|
||||||
|
|
||||||
|
**Use it when:**
|
||||||
|
|
||||||
|
- You want exhaustive edge case coverage for code or logic
|
||||||
|
- You need a complement to adversarial review (different methodology, different findings)
|
||||||
|
- You're reviewing a diff or function for boundary conditions
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
1. Enumerates all branching paths in the content
|
||||||
|
2. Derives edge classes mechanically: missing else/default, unguarded inputs, off-by-one, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
|
||||||
|
3. Tests each path against existing guards
|
||||||
|
4. Reports only unhandled paths — silently discards handled ones
|
||||||
|
|
||||||
|
**Input:**
|
||||||
|
|
||||||
|
- `content` (required) — Diff, full file, or function
|
||||||
|
- `also_consider` (optional) — Additional areas to keep in mind
|
||||||
|
|
||||||
|
**Output:** JSON array of findings, each with `location`, `trigger_condition`, `guard_snippet`, and `potential_consequence`
|
||||||
|
|
||||||
|
:::note[Complementary Reviews]
|
||||||
|
Run both `bmad-review-adversarial-general` and `bmad-review-edge-case-hunter` together for orthogonal coverage. The adversarial review catches quality and completeness issues; the edge case hunter catches unhandled paths.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## bmad-editorial-review-prose
|
||||||
|
|
||||||
|
**Clinical copy-editing focused on communication clarity.** — Reviews text for issues that impede comprehension. Applies Microsoft Writing Style Guide baseline. Preserves author voice.
|
||||||
|
|
||||||
|
**Use it when:**
|
||||||
|
|
||||||
|
- You've drafted a document and want to polish the writing
|
||||||
|
- You need to ensure clarity for a specific audience
|
||||||
|
- You want communication fixes without style opinion changes
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
1. Reads the content, skipping code blocks and frontmatter
|
||||||
|
2. Identifies communication issues (not style preferences)
|
||||||
|
3. Deduplicates same issues across multiple locations
|
||||||
|
4. Produces a three-column fix table
|
||||||
|
|
||||||
|
**Input:**
|
||||||
|
|
||||||
|
- `content` (required) — Markdown, plain text, or XML
|
||||||
|
- `style_guide` (optional) — Project-specific style guide
|
||||||
|
- `reader_type` (optional) — `humans` (default) for clarity/flow, or `llm` for precision/consistency
|
||||||
|
|
||||||
|
**Output:** Three-column markdown table: Original Text | Revised Text | Changes
|
||||||
|
|
||||||
|
## bmad-editorial-review-structure
|
||||||
|
|
||||||
|
**Structural editing — proposes cuts, merges, moves, and condensing.** — Reviews document organization and proposes substantive changes to improve clarity and flow before copy editing.
|
||||||
|
|
||||||
|
**Use it when:**
|
||||||
|
|
||||||
|
- A document was produced from multiple subprocesses and needs structural coherence
|
||||||
|
- You want to reduce document length while preserving comprehension
|
||||||
|
- You need to identify scope violations or buried critical information
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
1. Analyzes document against 5 structure models (Tutorial, Reference, Explanation, Prompt, Strategic)
|
||||||
|
2. Identifies redundancies, scope violations, and buried information
|
||||||
|
3. Produces prioritized recommendations: CUT, MERGE, MOVE, CONDENSE, QUESTION, PRESERVE
|
||||||
|
4. Estimates total reduction in words and percentage
|
||||||
|
|
||||||
|
**Input:**
|
||||||
|
|
||||||
|
- `content` (required) — Document to review
|
||||||
|
- `purpose` (optional) — Intended purpose (e.g., "quickstart tutorial")
|
||||||
|
- `target_audience` (optional) — Who reads this
|
||||||
|
- `reader_type` (optional) — `humans` or `llm`
|
||||||
|
- `length_target` (optional) — Target reduction (e.g., "30% shorter")
|
||||||
|
|
||||||
|
**Output:** Document summary, prioritized recommendation list, and estimated reduction
|
||||||
|
|
||||||
|
## bmad-shard-doc
|
||||||
|
|
||||||
|
**Split large markdown files into organized section files.** — Uses level-2 headers as split points to create a folder of self-contained section files with an index.
|
||||||
|
|
||||||
|
**Use it when:**
|
||||||
|
|
||||||
|
- A markdown document has grown too large to manage effectively (500+ lines)
|
||||||
|
- You want to break a monolithic doc into navigable sections
|
||||||
|
- You need separate files for parallel editing or LLM context management
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
1. Validates the source file exists and is markdown
|
||||||
|
2. Splits on level-2 (`##`) headers into numbered section files
|
||||||
|
3. Creates an `index.md` with section manifest and links
|
||||||
|
4. Prompts you to delete, archive, or keep the original
|
||||||
|
|
||||||
|
**Input:** Source markdown file path, optional destination folder
|
||||||
|
|
||||||
|
**Output:** Folder with `index.md` and `01-{section}.md`, `02-{section}.md`, etc.
|
||||||
|
|
||||||
|
## bmad-index-docs
|
||||||
|
|
||||||
|
**Generate or update an index of all documents in a folder.** — Scans a directory, reads each file to understand its purpose, and produces an organized `index.md` with links and descriptions.
|
||||||
|
|
||||||
|
**Use it when:**
|
||||||
|
|
||||||
|
- You need a lightweight index for quick LLM scanning of available docs
|
||||||
|
- A documentation folder has grown and needs an organized table of contents
|
||||||
|
- You want an auto-generated overview that stays current
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
1. Scans the target directory for all non-hidden files
|
||||||
|
2. Reads each file to understand its actual purpose
|
||||||
|
3. Groups files by type, purpose, or subdirectory
|
||||||
|
4. Generates concise descriptions (3–10 words each)
|
||||||
|
|
||||||
|
**Input:** Target folder path
|
||||||
|
|
||||||
|
**Output:** `index.md` with organized file listings, relative links, and brief descriptions
|
||||||
|
|
@ -1,15 +1,15 @@
|
||||||
---
|
---
|
||||||
title: Testing Options
|
title: Testing Options
|
||||||
description: Comparing the built-in QA agent (Quinn) with the Test Architect (TEA) module for test automation.
|
description: Comparing the built-in QA workflow with the Test Architect (TEA) module for test automation.
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 5
|
order: 5
|
||||||
---
|
---
|
||||||
|
|
||||||
BMad provides two testing paths: a built-in QA agent for fast test generation and an installable Test Architect module for enterprise-grade test strategy.
|
BMad provides two testing paths: a built-in QA workflow for fast test generation and an installable Test Architect module for enterprise-grade test strategy.
|
||||||
|
|
||||||
## Which Should You Use?
|
## Which Should You Use?
|
||||||
|
|
||||||
| Factor | Quinn (Built-in QA) | TEA Module |
|
| Factor | Built-in QA | TEA Module |
|
||||||
| --- | --- | --- |
|
| --- | --- | --- |
|
||||||
| **Best for** | Small-medium projects, quick coverage | Large projects, regulated or complex domains |
|
| **Best for** | Small-medium projects, quick coverage | Large projects, regulated or complex domains |
|
||||||
| **Setup** | Nothing to install -- included in BMM | Install separately via `npx bmad-method install` |
|
| **Setup** | Nothing to install -- included in BMM | Install separately via `npx bmad-method install` |
|
||||||
|
|
@ -18,19 +18,19 @@ BMad provides two testing paths: a built-in QA agent for fast test generation an
|
||||||
| **Strategy** | Happy path + critical edge cases | Risk-based prioritization (P0-P3) |
|
| **Strategy** | Happy path + critical edge cases | Risk-based prioritization (P0-P3) |
|
||||||
| **Workflow count** | 1 (Automate) | 9 (design, ATDD, automate, review, trace, and others) |
|
| **Workflow count** | 1 (Automate) | 9 (design, ATDD, automate, review, trace, and others) |
|
||||||
|
|
||||||
:::tip[Start with Quinn]
|
:::tip[Start with built-in QA]
|
||||||
Most projects should start with Quinn. If you later need test strategy, quality gates, or requirements traceability, install TEA alongside it.
|
Most projects should start with the built-in QA workflow. If you later need test strategy, quality gates, or requirements traceability, install TEA alongside it.
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## Built-in QA Agent (Quinn)
|
## Built-in QA Workflow
|
||||||
|
|
||||||
Quinn is the built-in QA agent in the BMM (Agile suite) module. It generates working tests quickly using your project's existing test framework -- no configuration or additional installation required.
|
The built-in QA workflow (`bmad-qa-generate-e2e-tests`) is part of the BMM (Agile suite) module, available through the Developer agent. It generates working tests quickly using your project's existing test framework -- no configuration or additional installation required.
|
||||||
|
|
||||||
**Trigger:** `QA` or `bmad-qa-generate-e2e-tests`
|
**Trigger:** `QA` (via the Developer agent) or `bmad-qa-generate-e2e-tests`
|
||||||
|
|
||||||
### What Quinn Does
|
### What It Does
|
||||||
|
|
||||||
Quinn runs a single workflow (Automate) that walks through five steps:
|
The QA workflow (Automate) walks through five steps:
|
||||||
|
|
||||||
1. **Detect test framework** -- scans `package.json` and existing test files for your framework (Jest, Vitest, Playwright, Cypress, or any standard runner). If none exists, analyzes the project stack and suggests one.
|
1. **Detect test framework** -- scans `package.json` and existing test files for your framework (Jest, Vitest, Playwright, Cypress, or any standard runner). If none exists, analyzes the project stack and suggests one.
|
||||||
2. **Identify features** -- asks what to test or auto-discovers features in the codebase.
|
2. **Identify features** -- asks what to test or auto-discovers features in the codebase.
|
||||||
|
|
@ -38,7 +38,7 @@ Quinn runs a single workflow (Automate) that walks through five steps:
|
||||||
4. **Generate E2E tests** -- covers user workflows with semantic locators and visible-outcome assertions.
|
4. **Generate E2E tests** -- covers user workflows with semantic locators and visible-outcome assertions.
|
||||||
5. **Run and verify** -- executes the generated tests and fixes failures immediately.
|
5. **Run and verify** -- executes the generated tests and fixes failures immediately.
|
||||||
|
|
||||||
Quinn produces a test summary saved to your project's implementation artifacts folder.
|
The workflow produces a test summary saved to your project's implementation artifacts folder.
|
||||||
|
|
||||||
### Test Patterns
|
### Test Patterns
|
||||||
|
|
||||||
|
|
@ -51,10 +51,10 @@ Generated tests follow a "simple and maintainable" philosophy:
|
||||||
- **Clear descriptions** that read as feature documentation
|
- **Clear descriptions** that read as feature documentation
|
||||||
|
|
||||||
:::note[Scope]
|
:::note[Scope]
|
||||||
Quinn generates tests only. For code review and story validation, use the Code Review workflow (`CR`) instead.
|
The QA workflow generates tests only. For code review and story validation, use the Code Review workflow (`CR`) instead.
|
||||||
:::
|
:::
|
||||||
|
|
||||||
### When to Use Quinn
|
### When to Use Built-in QA
|
||||||
|
|
||||||
- Quick test coverage for a new or existing feature
|
- Quick test coverage for a new or existing feature
|
||||||
- Beginner-friendly test automation without advanced setup
|
- Beginner-friendly test automation without advanced setup
|
||||||
|
|
@ -91,16 +91,16 @@ TEA also supports P0-P3 risk-based prioritization and optional integrations with
|
||||||
- Teams that need risk-based test prioritization across many features
|
- Teams that need risk-based test prioritization across many features
|
||||||
- Enterprise environments with formal quality gates before release
|
- Enterprise environments with formal quality gates before release
|
||||||
- Complex domains where test strategy must be planned before tests are written
|
- Complex domains where test strategy must be planned before tests are written
|
||||||
- Projects that have outgrown Quinn's single-workflow approach
|
- Projects that have outgrown the built-in QA's single-workflow approach
|
||||||
|
|
||||||
## How Testing Fits into Workflows
|
## How Testing Fits into Workflows
|
||||||
|
|
||||||
Quinn's Automate workflow appears in Phase 4 (Implementation) of the BMad Method workflow map. It is designed to run **after a full epic is complete** — once all stories in an epic have been implemented and code-reviewed. A typical sequence:
|
The QA Automate workflow appears in Phase 4 (Implementation) of the BMad Method workflow map. It is designed to run **after a full epic is complete** — once all stories in an epic have been implemented and code-reviewed. A typical sequence:
|
||||||
|
|
||||||
1. For each story in the epic: implement with Dev (`DS`), then validate with Code Review (`CR`)
|
1. For each story in the epic: implement with Dev (`DS`), then validate with Code Review (`CR`)
|
||||||
2. After the epic is complete: generate tests with Quinn (`QA`) or TEA's Automate workflow
|
2. After the epic is complete: generate tests with `QA` (via the Developer agent) or TEA's Automate workflow
|
||||||
3. Run retrospective (`bmad-retrospective`) to capture lessons learned
|
3. Run retrospective (`bmad-retrospective`) to capture lessons learned
|
||||||
|
|
||||||
Quinn works directly from source code without loading planning documents (PRD, architecture). TEA workflows can integrate with upstream planning artifacts for traceability.
|
The built-in QA workflow works directly from source code without loading planning documents (PRD, architecture). TEA workflows can integrate with upstream planning artifacts for traceability.
|
||||||
|
|
||||||
For more on where testing fits in the overall process, see the [Workflow Map](./workflow-map.md).
|
For more on where testing fits in the overall process, see the [Workflow Map](./workflow-map.md).
|
||||||
|
|
|
||||||
|
|
@ -21,13 +21,14 @@ Final important note: Every workflow below can be run directly with your tool of
|
||||||
|
|
||||||
## Phase 1: Analysis (Optional)
|
## Phase 1: Analysis (Optional)
|
||||||
|
|
||||||
Explore the problem space and validate ideas before committing to planning.
|
Explore the problem space and validate ideas before committing to planning. [**Learn what each tool does and when to use it**](../explanation/analysis-phase.md).
|
||||||
|
|
||||||
| Workflow | Purpose | Produces |
|
| Workflow | Purpose | Produces |
|
||||||
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
|
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
|
||||||
| `bmad-brainstorming` | Brainstorm Project Ideas with guided facilitation of a brainstorming coach | `brainstorming-report.md` |
|
| `bmad-brainstorming` | Brainstorm Project Ideas with guided facilitation of a brainstorming coach | `brainstorming-report.md` |
|
||||||
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validate market, technical, or domain assumptions | Research findings |
|
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validate market, technical, or domain assumptions | Research findings |
|
||||||
| `bmad-create-product-brief` | Capture strategic vision | `product-brief.md` |
|
| `bmad-product-brief` | Capture strategic vision — best when your concept is clear | `product-brief.md` |
|
||||||
|
| `bmad-prfaq` | Working Backwards — stress-test and forge your product concept | `prfaq-{project}.md` |
|
||||||
|
|
||||||
## Phase 2: Planning
|
## Phase 2: Planning
|
||||||
|
|
||||||
|
|
@ -66,10 +67,9 @@ Build it, one story at a time. Coming soon, full phase 4 automation!
|
||||||
|
|
||||||
Skip phases 1-3 for small, well-understood work.
|
Skip phases 1-3 for small, well-understood work.
|
||||||
|
|
||||||
| Workflow | Purpose | Produces |
|
| Workflow | Purpose | Produces |
|
||||||
| --------------------- | ------------------------------------------ | --------------------------------------------- |
|
| ------------------ | --------------------------------------------------------------------------- | ---------------------- |
|
||||||
| `bmad-quick-spec` | Define an ad-hoc change | `tech-spec.md` (story file for small changes) |
|
| `bmad-quick-dev` | Unified quick flow — clarify intent, plan, implement, review, and present | `spec-*.md` + code |
|
||||||
| `bmad-quick-dev` | Implement from spec or direct instructions | Working code + tests |
|
|
||||||
|
|
||||||
## Context Management
|
## Context Management
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -68,8 +68,8 @@ BMad helps you build software through guided workflows with specialized AI agent
|
||||||
|
|
||||||
| Phase | Name | What Happens |
|
| Phase | Name | What Happens |
|
||||||
| ----- | -------------- | --------------------------------------------------- |
|
| ----- | -------------- | --------------------------------------------------- |
|
||||||
| 1 | Analysis | Brainstorming, research, product brief *(optional)* |
|
| 1 | Analysis | Brainstorming, research, product brief or PRFAQ *(optional)* |
|
||||||
| 2 | Planning | Create requirements (PRD or tech-spec) |
|
| 2 | Planning | Create requirements (PRD or spec) |
|
||||||
| 3 | Solutioning | Design architecture *(BMad Method/Enterprise only)* |
|
| 3 | Solutioning | Design architecture *(BMad Method/Enterprise only)* |
|
||||||
| 4 | Implementation | Build epic by epic, story by story |
|
| 4 | Implementation | Build epic by epic, story by story |
|
||||||
|
|
||||||
|
|
@ -114,7 +114,7 @@ BMad-Help will detect what you've completed and recommend exactly what to do nex
|
||||||
:::
|
:::
|
||||||
|
|
||||||
:::note[How to Load Agents and Run Workflows]
|
:::note[How to Load Agents and Run Workflows]
|
||||||
Each workflow has a **skill** you invoke by name in your IDE (e.g., `bmad-create-prd`). Your AI tool will recognize the `bmad-*` name and run it — you don't need to load agents separately. You can also invoke an agent skill directly for general conversation (e.g., `bmad-pm` for the PM agent).
|
Each workflow has a **skill** you invoke by name in your IDE (e.g., `bmad-create-prd`). Your AI tool will recognize the `bmad-*` name and run it — you don't need to load agents separately. You can also invoke an agent skill directly for general conversation (e.g., `bmad-agent-pm` for the PM agent).
|
||||||
:::
|
:::
|
||||||
|
|
||||||
:::caution[Fresh Chats]
|
:::caution[Fresh Chats]
|
||||||
|
|
@ -133,29 +133,30 @@ Create it manually at `_bmad-output/project-context.md` or generate it after arc
|
||||||
|
|
||||||
### Phase 1: Analysis (Optional)
|
### Phase 1: Analysis (Optional)
|
||||||
|
|
||||||
All workflows in this phase are optional:
|
All workflows in this phase are optional. [**Not sure which to use?**](../explanation/analysis-phase.md)
|
||||||
- **brainstorming** (`bmad-brainstorming`) — Guided ideation
|
- **brainstorming** (`bmad-brainstorming`) — Guided ideation
|
||||||
- **research** (`bmad-research`) — Market and technical research
|
- **research** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Market, domain, and technical research
|
||||||
- **create-product-brief** (`bmad-create-product-brief`) — Recommended foundation document
|
- **product-brief** (`bmad-product-brief`) — Recommended foundation document when your concept is clear
|
||||||
|
- **prfaq** (`bmad-prfaq`) — Working Backwards challenge to stress-test and forge your product concept
|
||||||
|
|
||||||
### Phase 2: Planning (Required)
|
### Phase 2: Planning (Required)
|
||||||
|
|
||||||
**For BMad Method and Enterprise tracks:**
|
**For BMad Method and Enterprise tracks:**
|
||||||
1. Invoke the **PM agent** (`bmad-pm`) in a new chat
|
1. Invoke the **PM agent** (`bmad-agent-pm`) in a new chat
|
||||||
2. Run the `bmad-create-prd` workflow (`bmad-create-prd`)
|
2. Run the `bmad-create-prd` workflow (`bmad-create-prd`)
|
||||||
3. Output: `PRD.md`
|
3. Output: `PRD.md`
|
||||||
|
|
||||||
**For Quick Flow track:**
|
**For Quick Flow track:**
|
||||||
- Use the `bmad-quick-spec` workflow (`bmad-quick-spec`) instead of PRD, then skip to implementation
|
- Run `bmad-quick-dev` — it handles planning and implementation in a single workflow, skip to implementation
|
||||||
|
|
||||||
:::note[UX Design (Optional)]
|
:::note[UX Design (Optional)]
|
||||||
If your project has a user interface, invoke the **UX-Designer agent** (`bmad-ux-designer`) and run the UX design workflow (`bmad-create-ux-design`) after creating your PRD.
|
If your project has a user interface, invoke the **UX-Designer agent** (`bmad-agent-ux-designer`) and run the UX design workflow (`bmad-create-ux-design`) after creating your PRD.
|
||||||
:::
|
:::
|
||||||
|
|
||||||
### Phase 3: Solutioning (BMad Method/Enterprise)
|
### Phase 3: Solutioning (BMad Method/Enterprise)
|
||||||
|
|
||||||
**Create Architecture**
|
**Create Architecture**
|
||||||
1. Invoke the **Architect agent** (`bmad-architect`) in a new chat
|
1. Invoke the **Architect agent** (`bmad-agent-architect`) in a new chat
|
||||||
2. Run `bmad-create-architecture` (`bmad-create-architecture`)
|
2. Run `bmad-create-architecture` (`bmad-create-architecture`)
|
||||||
3. Output: Architecture document with technical decisions
|
3. Output: Architecture document with technical decisions
|
||||||
|
|
||||||
|
|
@ -165,12 +166,12 @@ If your project has a user interface, invoke the **UX-Designer agent** (`bmad-ux
|
||||||
Epics and stories are now created *after* architecture. This produces better quality stories because architecture decisions (database, API patterns, tech stack) directly affect how work should be broken down.
|
Epics and stories are now created *after* architecture. This produces better quality stories because architecture decisions (database, API patterns, tech stack) directly affect how work should be broken down.
|
||||||
:::
|
:::
|
||||||
|
|
||||||
1. Invoke the **PM agent** (`bmad-pm`) in a new chat
|
1. Invoke the **PM agent** (`bmad-agent-pm`) in a new chat
|
||||||
2. Run `bmad-create-epics-and-stories` (`bmad-create-epics-and-stories`)
|
2. Run `bmad-create-epics-and-stories` (`bmad-create-epics-and-stories`)
|
||||||
3. The workflow uses both PRD and Architecture to create technically-informed stories
|
3. The workflow uses both PRD and Architecture to create technically-informed stories
|
||||||
|
|
||||||
**Implementation Readiness Check** *(Highly Recommended)*
|
**Implementation Readiness Check** *(Highly Recommended)*
|
||||||
1. Invoke the **Architect agent** (`bmad-architect`) in a new chat
|
1. Invoke the **Architect agent** (`bmad-agent-architect`) in a new chat
|
||||||
2. Run `bmad-check-implementation-readiness` (`bmad-check-implementation-readiness`)
|
2. Run `bmad-check-implementation-readiness` (`bmad-check-implementation-readiness`)
|
||||||
3. Validates cohesion across all planning documents
|
3. Validates cohesion across all planning documents
|
||||||
|
|
||||||
|
|
@ -180,7 +181,7 @@ Once planning is complete, move to implementation. **Each workflow should run in
|
||||||
|
|
||||||
### Initialize Sprint Planning
|
### Initialize Sprint Planning
|
||||||
|
|
||||||
Invoke the **SM agent** (`bmad-sm`) and run `bmad-sprint-planning` (`bmad-sprint-planning`). This creates `sprint-status.yaml` to track all epics and stories.
|
Invoke the **Developer agent** (`bmad-agent-dev`) and run `bmad-sprint-planning` (`bmad-sprint-planning`). This creates `sprint-status.yaml` to track all epics and stories.
|
||||||
|
|
||||||
### The Build Cycle
|
### The Build Cycle
|
||||||
|
|
||||||
|
|
@ -188,11 +189,11 @@ For each story, repeat this cycle with fresh chats:
|
||||||
|
|
||||||
| Step | Agent | Workflow | Command | Purpose |
|
| Step | Agent | Workflow | Command | Purpose |
|
||||||
| ---- | ----- | -------------- | -------------------------- | ---------------------------------- |
|
| ---- | ----- | -------------- | -------------------------- | ---------------------------------- |
|
||||||
| 1 | SM | `bmad-create-story` | `bmad-create-story` | Create story file from epic |
|
| 1 | DEV | `bmad-create-story` | `bmad-create-story` | Create story file from epic |
|
||||||
| 2 | DEV | `bmad-dev-story` | `bmad-dev-story` | Implement the story |
|
| 2 | DEV | `bmad-dev-story` | `bmad-dev-story` | Implement the story |
|
||||||
| 3 | DEV | `bmad-code-review` | `bmad-code-review` | Quality validation *(recommended)* |
|
| 3 | DEV | `bmad-code-review` | `bmad-code-review` | Quality validation *(recommended)* |
|
||||||
|
|
||||||
After completing all stories in an epic, invoke the **SM agent** (`bmad-sm`) and run `bmad-retrospective` (`bmad-retrospective`).
|
After completing all stories in an epic, invoke the **Developer agent** (`bmad-agent-dev`) and run `bmad-retrospective` (`bmad-retrospective`).
|
||||||
|
|
||||||
## What You've Accomplished
|
## What You've Accomplished
|
||||||
|
|
||||||
|
|
@ -229,21 +230,21 @@ your-project/
|
||||||
| `bmad-generate-project-context` | `bmad-generate-project-context` | Analyst | Create project context file |
|
| `bmad-generate-project-context` | `bmad-generate-project-context` | Analyst | Create project context file |
|
||||||
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | Break down PRD into epics |
|
| `bmad-create-epics-and-stories` | `bmad-create-epics-and-stories` | PM | Break down PRD into epics |
|
||||||
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | Validate planning cohesion |
|
| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | Validate planning cohesion |
|
||||||
| `bmad-sprint-planning` | `bmad-sprint-planning` | SM | Initialize sprint tracking |
|
| `bmad-sprint-planning` | `bmad-sprint-planning` | DEV | Initialize sprint tracking |
|
||||||
| `bmad-create-story` | `bmad-create-story` | SM | Create a story file |
|
| `bmad-create-story` | `bmad-create-story` | DEV | Create a story file |
|
||||||
| `bmad-dev-story` | `bmad-dev-story` | DEV | Implement a story |
|
| `bmad-dev-story` | `bmad-dev-story` | DEV | Implement a story |
|
||||||
| `bmad-code-review` | `bmad-code-review` | DEV | Review implemented code |
|
| `bmad-code-review` | `bmad-code-review` | DEV | Review implemented code |
|
||||||
|
|
||||||
## Common Questions
|
## Common Questions
|
||||||
|
|
||||||
**Do I always need architecture?**
|
**Do I always need architecture?**
|
||||||
Only for BMad Method and Enterprise tracks. Quick Flow skips from tech-spec to implementation.
|
Only for BMad Method and Enterprise tracks. Quick Flow skips from spec to implementation.
|
||||||
|
|
||||||
**Can I change my plan later?**
|
**Can I change my plan later?**
|
||||||
Yes. The SM agent has a `bmad-correct-course` workflow (`bmad-correct-course`) for handling scope changes.
|
Yes. The `bmad-correct-course` workflow handles scope changes mid-implementation.
|
||||||
|
|
||||||
**What if I want to brainstorm first?**
|
**What if I want to brainstorm first?**
|
||||||
Invoke the Analyst agent (`bmad-analyst`) and run `bmad-brainstorming` (`bmad-brainstorming`) before starting your PRD.
|
Invoke the Analyst agent (`bmad-agent-analyst`) and run `bmad-brainstorming` (`bmad-brainstorming`) before starting your PRD.
|
||||||
|
|
||||||
**Do I need to follow a strict order?**
|
**Do I need to follow a strict order?**
|
||||||
Not strictly. Once you learn the flow, you can run workflows directly using the Quick Reference above.
|
Not strictly. Once you learn the flow, you can run workflows directly using the Quick Reference above.
|
||||||
|
|
@ -268,7 +269,7 @@ BMad-Help inspects your project, detects what you've completed, and tells you ex
|
||||||
:::tip[Remember These]
|
:::tip[Remember These]
|
||||||
- **Start with `bmad-help`** — Your intelligent guide that knows your project and options
|
- **Start with `bmad-help`** — Your intelligent guide that knows your project and options
|
||||||
- **Always use fresh chats** — Start a new chat for each workflow
|
- **Always use fresh chats** — Start a new chat for each workflow
|
||||||
- **Track matters** — Quick Flow uses quick-spec; Method/Enterprise need PRD and architecture
|
- **Track matters** — Quick Flow uses `bmad-quick-dev`; Method/Enterprise need PRD and architecture
|
||||||
- **BMad-Help runs automatically** — Every workflow ends with guidance on what's next
|
- **BMad-Help runs automatically** — Every workflow ends with guidance on what's next
|
||||||
:::
|
:::
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
---
|
||||||
|
title: Không Tìm Thấy Trang
|
||||||
|
template: splash
|
||||||
|
---
|
||||||
|
|
||||||
|
Trang bạn đang tìm không tồn tại hoặc đã được chuyển đi.
|
||||||
|
|
||||||
|
[Quay về trang chủ](./index.md)
|
||||||
|
|
@ -0,0 +1,370 @@
|
||||||
|
---
|
||||||
|
title: "Hướng Dẫn Phong Cách Tài Liệu"
|
||||||
|
description: Các quy ước tài liệu dành riêng cho dự án, dựa trên phong cách tài liệu của Google và cấu trúc Diataxis
|
||||||
|
---
|
||||||
|
|
||||||
|
Dự án này tuân theo [Google Developer Documentation Style Guide](https://developers.google.com/style) và dùng [Diataxis](https://diataxis.fr/) để tổ chức nội dung. Phần dưới đây chỉ nêu các quy ước dành riêng cho dự án.
|
||||||
|
|
||||||
|
## Quy tắc riêng của dự án
|
||||||
|
|
||||||
|
| Quy tắc | Quy định |
|
||||||
|
| --- | --- |
|
||||||
|
| Không dùng đường kẻ ngang (`---`) | Làm gián đoạn dòng đọc |
|
||||||
|
| Không dùng tiêu đề `####` | Dùng chữ in đậm hoặc admonition thay thế |
|
||||||
|
| Không có mục "Related" hoặc "Next:" | Sidebar đã xử lý điều hướng |
|
||||||
|
| Không dùng danh sách lồng quá sâu | Tách thành các mục riêng |
|
||||||
|
| Không dùng code block cho nội dung không phải code | Dùng admonition cho ví dụ hội thoại |
|
||||||
|
| Không dùng cả đoạn in đậm để làm callout | Dùng admonition thay thế |
|
||||||
|
| Mỗi mục tối đa 1-2 admonition | Tutorial có thể dùng 3-4 admonition cho mỗi phần lớn |
|
||||||
|
| Ô bảng / mục danh sách | Tối đa 1-2 câu |
|
||||||
|
| Ngân sách tiêu đề | 8-12 `##` cho mỗi tài liệu; 2-3 `###` cho mỗi phần |
|
||||||
|
|
||||||
|
## Admonition (cú pháp Starlight)
|
||||||
|
|
||||||
|
```md
|
||||||
|
:::tip[Tiêu đề]
|
||||||
|
Lối tắt, best practice
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::note[Tiêu đề]
|
||||||
|
Ngữ cảnh, định nghĩa, ví dụ, điều kiện tiên quyết
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::caution[Tiêu đề]
|
||||||
|
Lưu ý, vấn đề có thể xảy ra
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::danger[Tiêu đề]
|
||||||
|
Chỉ dùng cho cảnh báo nghiêm trọng — mất dữ liệu, vấn đề bảo mật
|
||||||
|
:::
|
||||||
|
```
|
||||||
|
|
||||||
|
### Cách dùng chuẩn
|
||||||
|
|
||||||
|
| Admonition | Dùng cho |
|
||||||
|
| --- | --- |
|
||||||
|
| `:::note[Điều kiện tiên quyết]` | Các phụ thuộc trước khi bắt đầu |
|
||||||
|
| `:::tip[Lối đi nhanh]` | Tóm tắt TL;DR ở đầu tài liệu |
|
||||||
|
| `:::caution[Quan trọng]` | Cảnh báo quan trọng |
|
||||||
|
| `:::note[Ví dụ]` | Ví dụ lệnh / phản hồi |
|
||||||
|
|
||||||
|
## Mẫu bảng chuẩn
|
||||||
|
|
||||||
|
**Phase:**
|
||||||
|
|
||||||
|
```md
|
||||||
|
| Phase | Tên | Điều xảy ra |
|
||||||
|
| ----- | --- | ------------ |
|
||||||
|
| 1 | Analysis | Brainstorm, nghiên cứu *(tùy chọn)* |
|
||||||
|
| 2 | Planning | Yêu cầu — PRD hoặc spec *(bắt buộc)* |
|
||||||
|
```
|
||||||
|
|
||||||
|
**Skill:**
|
||||||
|
|
||||||
|
```md
|
||||||
|
| Skill | Agent | Mục đích |
|
||||||
|
| ----- | ----- | -------- |
|
||||||
|
| `bmad-brainstorming` | Analyst | Brainstorm cho dự án mới |
|
||||||
|
| `bmad-create-prd` | PM | Tạo tài liệu yêu cầu sản phẩm |
|
||||||
|
```
|
||||||
|
|
||||||
|
## Khối cấu trúc thư mục
|
||||||
|
|
||||||
|
Hiển thị trong phần "Bạn đã hoàn thành những gì":
|
||||||
|
|
||||||
|
````md
|
||||||
|
```
|
||||||
|
your-project/
|
||||||
|
├── _bmad/ # Cấu hình BMad
|
||||||
|
├── _bmad-output/
|
||||||
|
│ ├── planning-artifacts/
|
||||||
|
│ │ └── PRD.md # Tài liệu yêu cầu của bạn
|
||||||
|
│ ├── implementation-artifacts/
|
||||||
|
│ └── project-context.md # Quy tắc triển khai (tùy chọn)
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
````
|
||||||
|
|
||||||
|
## Cấu trúc Tutorial
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Tiêu đề + Hook (1-2 câu mô tả kết quả)
|
||||||
|
2. Thông báo phiên bản/module (admonition info hoặc warning) (tùy chọn)
|
||||||
|
3. Bạn sẽ học được gì (danh sách kết quả)
|
||||||
|
4. Điều kiện tiên quyết (admonition info)
|
||||||
|
5. Lối đi nhanh (admonition tip - tóm tắt TL;DR)
|
||||||
|
6. Hiểu về [Chủ đề] (ngữ cảnh trước các bước - bảng cho phase/agent)
|
||||||
|
7. Cài đặt (tùy chọn)
|
||||||
|
8. Bước 1: [Nhiệm vụ lớn đầu tiên]
|
||||||
|
9. Bước 2: [Nhiệm vụ lớn thứ hai]
|
||||||
|
10. Bước 3: [Nhiệm vụ lớn thứ ba]
|
||||||
|
11. Bạn đã hoàn thành những gì (tóm tắt + cấu trúc thư mục)
|
||||||
|
12. Tra cứu nhanh (bảng skill)
|
||||||
|
13. Câu hỏi thường gặp (định dạng FAQ)
|
||||||
|
14. Nhận hỗ trợ (liên kết cộng đồng)
|
||||||
|
15. Điểm chính cần nhớ (admonition tip)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Checklist cho Tutorial
|
||||||
|
|
||||||
|
- [ ] Hook mô tả kết quả trong 1-2 câu
|
||||||
|
- [ ] Có phần "Bạn sẽ học được gì"
|
||||||
|
- [ ] Điều kiện tiên quyết nằm trong admonition
|
||||||
|
- [ ] Có admonition TL;DR ở đầu trang
|
||||||
|
- [ ] Có bảng cho phase, skill, agent
|
||||||
|
- [ ] Có phần "Bạn đã hoàn thành những gì"
|
||||||
|
- [ ] Có bảng tra cứu nhanh
|
||||||
|
- [ ] Có phần câu hỏi thường gặp
|
||||||
|
- [ ] Có phần nhận hỗ trợ
|
||||||
|
- [ ] Có admonition điểm chính ở cuối
|
||||||
|
|
||||||
|
## Cấu trúc How-To
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Tiêu đề + Hook (một câu: "Sử dụng workflow `X` để...")
|
||||||
|
2. Khi nào nên dùng (danh sách kịch bản)
|
||||||
|
3. Khi nào nên bỏ qua (tùy chọn)
|
||||||
|
4. Điều kiện tiên quyết (admonition note)
|
||||||
|
5. Các bước (mục con `###` có đánh số)
|
||||||
|
6. Bạn sẽ nhận được gì (output / artifact)
|
||||||
|
7. Ví dụ (tùy chọn)
|
||||||
|
8. Mẹo (tùy chọn)
|
||||||
|
9. Bước tiếp theo (tùy chọn)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Checklist cho How-To
|
||||||
|
|
||||||
|
- [ ] Hook bắt đầu bằng "Sử dụng workflow `X` để..."
|
||||||
|
- [ ] Phần "Khi nào nên dùng" có 3-5 gạch đầu dòng
|
||||||
|
- [ ] Có liệt kê điều kiện tiên quyết
|
||||||
|
- [ ] Các bước là mục `###` có đánh số và bắt đầu bằng động từ
|
||||||
|
- [ ] Phần "Bạn sẽ nhận được gì" mô tả artifact đầu ra
|
||||||
|
|
||||||
|
## Cấu trúc Explanation
|
||||||
|
|
||||||
|
### Các loại
|
||||||
|
|
||||||
|
| Loại | Ví dụ |
|
||||||
|
| --- | --- |
|
||||||
|
| **Trang chỉ mục / landing** | `core-concepts/index.md` |
|
||||||
|
| **Khái niệm** | `what-are-agents.md` |
|
||||||
|
| **Tính năng** | `quick-dev.md` |
|
||||||
|
| **Triết lý** | `why-solutioning-matters.md` |
|
||||||
|
| **FAQ** | `established-projects-faq.md` |
|
||||||
|
|
||||||
|
### Mẫu tổng quát
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Tiêu đề + Hook (1-2 câu)
|
||||||
|
2. Tổng quan / định nghĩa (nó là gì, vì sao quan trọng)
|
||||||
|
3. Khái niệm chính (các mục `###`)
|
||||||
|
4. Bảng so sánh (tùy chọn)
|
||||||
|
5. Khi nào nên dùng / không nên dùng (tùy chọn)
|
||||||
|
6. Sơ đồ (tùy chọn - mermaid, tối đa 1 sơ đồ mỗi tài liệu)
|
||||||
|
7. Bước tiếp theo (tùy chọn)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Trang chỉ mục / landing
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Tiêu đề + Hook (một câu)
|
||||||
|
2. Bảng nội dung (liên kết kèm mô tả)
|
||||||
|
3. Bắt đầu từ đâu (danh sách có đánh số)
|
||||||
|
4. Chọn hướng đi của bạn (tùy chọn - cây quyết định)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Trang giải thích khái niệm
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Tiêu đề + Hook (nó là gì)
|
||||||
|
2. Loại / nhóm (các mục `###`) (tùy chọn)
|
||||||
|
3. Bảng khác biệt chính
|
||||||
|
4. Thành phần / bộ phận
|
||||||
|
5. Nên chọn cái nào?
|
||||||
|
6. Cách tạo / tùy chỉnh (trỏ sang how-to)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Trang giải thích tính năng
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Tiêu đề + Hook (nó làm gì)
|
||||||
|
2. Thông tin nhanh (tùy chọn - "Phù hợp với:", "Mất bao lâu:")
|
||||||
|
3. Khi nào nên dùng / không nên dùng
|
||||||
|
4. Cách nó hoạt động (mermaid tùy chọn)
|
||||||
|
5. Lợi ích chính
|
||||||
|
6. Bảng so sánh (tùy chọn)
|
||||||
|
7. Khi nào nên nâng cấp / chuyển hướng (tùy chọn)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Tài liệu về triết lý / lý do
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Tiêu đề + Hook (nguyên tắc)
|
||||||
|
2. Vấn đề
|
||||||
|
3. Giải pháp
|
||||||
|
4. Nguyên tắc chính (các mục `###`)
|
||||||
|
5. Lợi ích
|
||||||
|
6. Khi nào áp dụng
|
||||||
|
```
|
||||||
|
|
||||||
|
### Checklist cho Explanation
|
||||||
|
|
||||||
|
- [ ] Hook nêu rõ tài liệu giải thích điều gì
|
||||||
|
- [ ] Nội dung được chia thành các phần `##` dễ quét
|
||||||
|
- [ ] Có bảng so sánh khi có từ 3 lựa chọn trở lên
|
||||||
|
- [ ] Sơ đồ có nhãn rõ ràng
|
||||||
|
- [ ] Có liên kết sang how-to cho câu hỏi mang tính thủ tục
|
||||||
|
- [ ] Mỗi tài liệu tối đa 2-3 admonition
|
||||||
|
|
||||||
|
## Cấu trúc Reference
|
||||||
|
|
||||||
|
### Các loại
|
||||||
|
|
||||||
|
| Loại | Ví dụ |
|
||||||
|
| --- | --- |
|
||||||
|
| **Trang chỉ mục / landing** | `workflows/index.md` |
|
||||||
|
| **Danh mục** | `agents/index.md` |
|
||||||
|
| **Đào sâu** | `document-project.md` |
|
||||||
|
| **Cấu hình** | `core-tasks.md` |
|
||||||
|
| **Bảng thuật ngữ** | `glossary/index.md` |
|
||||||
|
| **Tổng hợp đầy đủ** | `bmgd-workflows.md` |
|
||||||
|
|
||||||
|
### Trang chỉ mục của Reference
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Tiêu đề + Hook (một câu)
|
||||||
|
2. Các phần nội dung (`##` cho từng nhóm)
|
||||||
|
- Danh sách gạch đầu dòng với liên kết và mô tả
|
||||||
|
```
|
||||||
|
|
||||||
|
### Reference dạng danh mục
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Tiêu đề + Hook
|
||||||
|
2. Các mục (`##` cho từng mục)
|
||||||
|
- Mô tả ngắn (một câu)
|
||||||
|
- **Skills:** hoặc **Thông tin chính:** ở dạng danh sách phẳng
|
||||||
|
3. Phần dùng chung / toàn cục (`##`) (tùy chọn)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Reference đào sâu theo mục
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Tiêu đề + Hook (một câu nêu mục đích)
|
||||||
|
2. Thông tin nhanh (admonition note, tùy chọn)
|
||||||
|
- Module, Skill, Input, Output dưới dạng danh sách
|
||||||
|
3. Mục đích / tổng quan (`##`)
|
||||||
|
4. Cách gọi (code block)
|
||||||
|
5. Các phần chính (`##` cho từng khía cạnh)
|
||||||
|
- Dùng `###` cho các tùy chọn con
|
||||||
|
6. Ghi chú / lưu ý (admonition tip hoặc caution)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Reference về cấu hình
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Tiêu đề + Hook
|
||||||
|
2. Mục lục (jump link nếu có từ 4 mục trở lên)
|
||||||
|
3. Các mục (`##` cho từng config / task)
|
||||||
|
- **Tóm tắt in đậm** — một câu
|
||||||
|
- **Dùng khi:** danh sách gạch đầu dòng
|
||||||
|
- **Cách hoạt động:** các bước đánh số (tối đa 3-5 bước)
|
||||||
|
- **Output:** kết quả mong đợi (tùy chọn)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Hướng dẫn reference tổng hợp
|
||||||
|
|
||||||
|
```text
|
||||||
|
1. Tiêu đề + Hook
|
||||||
|
2. Tổng quan (`##`)
|
||||||
|
- Sơ đồ hoặc bảng mô tả cách tổ chức
|
||||||
|
3. Các phần lớn (`##` cho từng phase / nhóm)
|
||||||
|
- Các mục (`###` cho từng mục)
|
||||||
|
- Các trường chuẩn hóa: Skill, Agent, Input, Output, Description
|
||||||
|
4. Bước tiếp theo (tùy chọn)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Checklist cho Reference
|
||||||
|
|
||||||
|
- [ ] Hook nêu rõ tài liệu đang tham chiếu điều gì
|
||||||
|
- [ ] Cấu trúc phù hợp với loại reference
|
||||||
|
- [ ] Các mục dùng cấu trúc nhất quán xuyên suốt
|
||||||
|
- [ ] Có bảng cho dữ liệu có cấu trúc / so sánh
|
||||||
|
- [ ] Có liên kết sang tài liệu explanation cho chiều sâu khái niệm
|
||||||
|
- [ ] Tối đa 1-2 admonition
|
||||||
|
|
||||||
|
## Cấu trúc Glossary
|
||||||
|
|
||||||
|
Starlight tạo phần điều hướng "On this page" từ các tiêu đề:
|
||||||
|
|
||||||
|
- Dùng `##` cho các nhóm — sẽ hiện ở thanh điều hướng bên phải
|
||||||
|
- Đặt thuật ngữ trong bảng — gọn hơn so với tạo tiêu đề riêng cho từng thuật ngữ
|
||||||
|
- Không chèn TOC nội tuyến — sidebar bên phải đã xử lý điều hướng
|
||||||
|
|
||||||
|
### Định dạng bảng
|
||||||
|
|
||||||
|
```md
|
||||||
|
## Tên nhóm
|
||||||
|
|
||||||
|
| Thuật ngữ | Định nghĩa |
|
||||||
|
| --------- | ---------- |
|
||||||
|
| **Agent** | AI persona chuyên biệt với chuyên môn cụ thể để dẫn dắt người dùng qua workflow. |
|
||||||
|
| **Workflow** | Quy trình nhiều bước có hướng dẫn, điều phối hoạt động của agent AI để tạo deliverable. |
|
||||||
|
```
|
||||||
|
|
||||||
|
### Quy tắc viết định nghĩa
|
||||||
|
|
||||||
|
| Nên làm | Không nên làm |
|
||||||
|
| --- | --- |
|
||||||
|
| Bắt đầu bằng việc nó LÀ gì hoặc LÀM gì | Bắt đầu bằng "Đây là..." hoặc "Một [thuật ngữ] là..." |
|
||||||
|
| Giữ trong 1-2 câu | Viết thành nhiều đoạn dài |
|
||||||
|
| Bôi đậm tên thuật ngữ trong ô | Để thuật ngữ ở dạng chữ thường |
|
||||||
|
|
||||||
|
### Dấu hiệu ngữ cảnh
|
||||||
|
|
||||||
|
Thêm ngữ cảnh in nghiêng ở đầu định nghĩa với các thuật ngữ có phạm vi hẹp:
|
||||||
|
|
||||||
|
- `*Chỉ dành cho Quick Flow.*`
|
||||||
|
- `*BMad Method/Enterprise.*`
|
||||||
|
- `*Phase N.*`
|
||||||
|
- `*BMGD.*`
|
||||||
|
- `*Dự án hiện có.*`
|
||||||
|
|
||||||
|
### Checklist cho Glossary
|
||||||
|
|
||||||
|
- [ ] Thuật ngữ nằm trong bảng, không dùng tiêu đề riêng
|
||||||
|
- [ ] Thuật ngữ được sắp theo thứ tự chữ cái trong từng nhóm
|
||||||
|
- [ ] Định nghĩa dài 1-2 câu
|
||||||
|
- [ ] Dấu hiệu ngữ cảnh được in nghiêng
|
||||||
|
- [ ] Tên thuật ngữ được bôi đậm trong ô
|
||||||
|
- [ ] Không dùng kiểu định nghĩa "Một [thuật ngữ] là..."
|
||||||
|
|
||||||
|
## Phần FAQ
|
||||||
|
|
||||||
|
```md
|
||||||
|
## Các câu hỏi
|
||||||
|
|
||||||
|
- [Lúc nào cũng cần kiến trúc à?](#luc-nao-cung-can-kien-truc-a)
|
||||||
|
- [Tôi có thể đổi kế hoạch về sau không?](#toi-co-the-doi-ke-hoach-ve-sau-khong)
|
||||||
|
|
||||||
|
### Lúc nào cũng cần kiến trúc à?
|
||||||
|
|
||||||
|
Chỉ với nhánh BMad Method và Enterprise. Quick Flow bỏ qua để đi thẳng vào triển khai.
|
||||||
|
|
||||||
|
### Tôi có thể đổi kế hoạch về sau không?
|
||||||
|
|
||||||
|
Có. Workflow `bmad-correct-course` xử lý thay đổi phạm vi giữa chừng.
|
||||||
|
|
||||||
|
**Có câu hỏi chưa được trả lời ở đây?** [Mở issue](...) hoặc hỏi trên [Discord](...).
|
||||||
|
```
|
||||||
|
|
||||||
|
## Các Lệnh Kiểm Tra
|
||||||
|
|
||||||
|
Trước khi gửi thay đổi tài liệu:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npm run docs:fix-links # Xem trước các sửa định dạng link
|
||||||
|
npm run docs:fix-links -- --write # Áp dụng các sửa
|
||||||
|
npm run docs:validate-links # Kiểm tra link tồn tại
|
||||||
|
npm run docs:build # Xác minh không có lỗi build
|
||||||
|
```
|
||||||
|
|
@ -0,0 +1,49 @@
|
||||||
|
---
|
||||||
|
title: "Khai thác nâng cao"
|
||||||
|
description: Buộc LLM xem xét lại kết quả của nó bằng các phương pháp lập luận có cấu trúc
|
||||||
|
sidebar:
|
||||||
|
order: 6
|
||||||
|
---
|
||||||
|
|
||||||
|
Buộc LLM xem xét lại những gì nó vừa tạo ra. Bạn chọn một phương pháp lập luận, nó áp dụng phương pháp đó lên chính output của mình, rồi bạn quyết định có giữ các cải tiến hay không.
|
||||||
|
|
||||||
|
## Khai thác nâng cao là gì?
|
||||||
|
|
||||||
|
Đây là một lần xem xét lại có cấu trúc. Thay vì bảo AI "thử lại" hoặc "làm cho nó tốt hơn", bạn chọn một phương pháp lập luận cụ thể và AI sẽ xem lại output của chính nó dưới góc đó.
|
||||||
|
|
||||||
|
Khác biệt này rất quan trọng. Yêu cầu mơ hồ sẽ tạo ra bản sửa đổi mơ hồ. Một phương pháp được gọi tên buộc AI tấn công vấn đề theo một hướng cụ thể, qua đó phát hiện những ý tưởng mà một lần thử lại chung chung sẽ bỏ lỡ.
|
||||||
|
|
||||||
|
## Khi nào nên dùng
|
||||||
|
|
||||||
|
- Sau khi workflow tạo nội dung và bạn muốn có phương án thay thế
|
||||||
|
- Khi output có vẻ ổn nhưng bạn nghi vẫn còn có thể đào sâu hơn
|
||||||
|
- Để stress-test các giả định hoặc tìm điểm yếu
|
||||||
|
- Với nội dung quan trọng, nơi mà việc nghĩ lại sẽ có giá trị
|
||||||
|
|
||||||
|
Các workflow sẽ đưa ra tùy chọn khai thác nâng cao tại các điểm quyết định - sau khi LLM tạo một kết quả, bạn sẽ được hỏi có muốn chạy nó hay không.
|
||||||
|
|
||||||
|
## Nó hoạt động như thế nào
|
||||||
|
|
||||||
|
1. LLM đề xuất 5 phương pháp phù hợp với nội dung của bạn
|
||||||
|
2. Bạn chọn một phương pháp (hoặc đảo lại để xem lựa chọn khác)
|
||||||
|
3. Phương pháp được áp dụng, các cải tiến được hiện ra
|
||||||
|
4. Chấp nhận hoặc bỏ đi, lặp lại hoặc tiếp tục
|
||||||
|
|
||||||
|
## Các phương pháp tích hợp sẵn
|
||||||
|
|
||||||
|
Có hàng chục phương pháp lập luận có sẵn. Một vài ví dụ:
|
||||||
|
|
||||||
|
- **Pre-mortem Analysis** - Giả sử dự án đã thất bại rồi lần ngược lại để tìm lý do
|
||||||
|
- **First Principles Thinking** - Loại bỏ giả định, xây lại từ sự thật nền tảng
|
||||||
|
- **Inversion** - Hỏi cách nào chắc chắn dẫn đến thất bại, rồi tránh những điều đó
|
||||||
|
- **Red Team vs Blue Team** - Tự tấn công công việc của chính mình, rồi tự bảo vệ nó
|
||||||
|
- **Socratic Questioning** - Chất vấn mọi khẳng định bằng "tại sao?" và "làm sao bạn biết?"
|
||||||
|
- **Constraint Removal** - Bỏ hết ràng buộc, xem điều gì thay đổi, rồi thêm lại có chọn lọc
|
||||||
|
- **Stakeholder Mapping** - Đánh giá lại từ góc nhìn của từng bên liên quan
|
||||||
|
- **Analogical Reasoning** - Tìm điểm tương đồng ở lĩnh vực khác và áp dụng bài học của chúng
|
||||||
|
|
||||||
|
Và còn nhiều nữa. AI sẽ chọn những lựa chọn phù hợp nhất với nội dung của bạn - bạn quyết định chạy cái nào.
|
||||||
|
|
||||||
|
:::tip[Bắt đầu từ đây]
|
||||||
|
Pre-mortem Analysis là lựa chọn đầu tiên tốt cho bất kỳ bản spec hoặc kế hoạch nào. Nó thường xuyên tìm ra các lỗ hổng mà một lần review thông thường bỏ qua.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,59 @@
|
||||||
|
---
|
||||||
|
title: "Đánh giá đối kháng"
|
||||||
|
description: Kỹ thuật lập luận ép buộc giúp tránh các bản review lười kiểu "nhìn ổn"
|
||||||
|
sidebar:
|
||||||
|
order: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
Buộc quá trình phân tích đi sâu hơn bằng cách ép phải tìm ra vấn đề.
|
||||||
|
|
||||||
|
## Đánh giá đối kháng là gì?
|
||||||
|
|
||||||
|
Đây là một kỹ thuật review mà người review *bắt buộc* phải tìm thấy vấn đề. Không có chuyện "nhìn ổn". Người review chọn lập trường hoài nghi - giả sử vấn đề có tồn tại và đi tìm chúng.
|
||||||
|
|
||||||
|
Đây không phải là việc cố tình tiêu cực. Đây là cách ép buộc phân tích thật sự, thay vì chỉ liếc qua và đóng dấu chấp nhận những gì vừa được nộp lên.
|
||||||
|
|
||||||
|
**Quy tắc cốt lõi:** Bạn phải tìm ra vấn đề. Nếu không có phát hiện nào, quy trình sẽ dừng lại - cần phân tích lại hoặc giải thích tại sao.
|
||||||
|
|
||||||
|
## Vì sao nó hiệu quả
|
||||||
|
|
||||||
|
Những lần review thông thường dễ bị confirmation bias. Bạn lướt qua công việc, không có gì đập vào mắt, rồi phê duyệt. Yêu cầu "tìm vấn đề" phá vỡ mẫu này:
|
||||||
|
|
||||||
|
- **Ép buộc sự kỹ lưỡng** - Không thể phê duyệt cho đến khi bạn đã đào đủ sâu để tìm thấy vấn đề
|
||||||
|
- **Bắt được những thứ đang thiếu** - "Còn gì chưa có ở đây?" trở thành câu hỏi tự nhiên
|
||||||
|
- **Tăng chất lượng tín hiệu** - Các phát hiện cụ thể và có thể hành động được, không phải các lo ngại mơ hồ
|
||||||
|
- **Bất đối xứng thông tin** - Chạy review với bối cảnh mới (không có lý do gốc) để đánh giá artifact, không phải ý định
|
||||||
|
|
||||||
|
## Nó được dùng ở đâu
|
||||||
|
|
||||||
|
Đánh giá đối kháng xuất hiện xuyên suốt các workflow của BMad - code review, kiểm tra sẵn sàng triển khai, xác thực spec, và nhiều nơi khác. Đôi khi là bước bắt buộc, đôi khi là tùy chọn (như khai thác nâng cao hoặc party mode). Mẫu này được điều chỉnh theo artifact cần bị soi kỹ.
|
||||||
|
|
||||||
|
## Vẫn cần bộ lọc của con người
|
||||||
|
|
||||||
|
Vì AI *được lệnh* phải tìm vấn đề, nó sẽ tìm vấn đề - ngay cả khi chúng không tồn tại. Hãy kỳ vọng false positive: bắt bẻ những lỗi vặt, hiểu sai ý định, hoặc thậm chí tưởng tượng ra vấn đề.
|
||||||
|
|
||||||
|
**Bạn là người quyết định cái nào là thật.** Xem từng phát hiện, bỏ qua nhiễu, sửa những gì quan trọng.
|
||||||
|
|
||||||
|
## Ví dụ
|
||||||
|
|
||||||
|
Thay vì:
|
||||||
|
|
||||||
|
> "Phần triển khai xác thực có vẻ hợp lý. Đã duyệt."
|
||||||
|
|
||||||
|
Một lần đánh giá đối kháng sẽ cho ra:
|
||||||
|
|
||||||
|
> 1. **HIGH** - `login.ts:47` - Không có giới hạn tốc độ cho các lần đăng nhập thất bại
|
||||||
|
> 2. **HIGH** - Session token được lưu trong localStorage (dễ bị XSS)
|
||||||
|
> 3. **MEDIUM** - Kiểm tra mật khẩu chỉ diễn ra ở client
|
||||||
|
> 4. **MEDIUM** - Không có audit log cho các lần đăng nhập thất bại
|
||||||
|
> 5. **LOW** - Số magic `3600` nên được đổi thành `SESSION_TIMEOUT_SECONDS`
|
||||||
|
|
||||||
|
Bản review thứ nhất có thể bỏ sót một lỗi bảo mật. Bản review thứ hai đã bắt được bốn vấn đề.
|
||||||
|
|
||||||
|
## Lặp lại và lợi ích giảm dần
|
||||||
|
|
||||||
|
Sau khi đã xử lý các phát hiện, hãy cân nhắc chạy lại. Lần thứ hai thường sẽ bắt thêm được vấn đề. Lần thứ ba cũng không phải lúc nào cũng vô ích. Nhưng mỗi lần đều tốn thời gian, và đến một mức nào đó bạn sẽ gặp lợi ích giảm dần - chỉ còn các bắt bẻ nhỏ và false positive.
|
||||||
|
|
||||||
|
:::tip[Review tốt hơn]
|
||||||
|
Giả sử vấn đề có tồn tại. Tìm những gì còn thiếu, không chỉ những gì sai.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,70 @@
|
||||||
|
---
|
||||||
|
title: "Giai đoạn Analysis: từ ý tưởng đến nền tảng"
|
||||||
|
description: Brainstorming, research, product brief và PRFAQ là gì, và nên dùng từng công cụ khi nào
|
||||||
|
sidebar:
|
||||||
|
order: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
Giai đoạn Analysis (Phase 1) giúp bạn suy nghĩ rõ ràng về sản phẩm trước khi cam kết bắt tay vào xây dựng. Mọi công cụ trong giai đoạn này đều là tùy chọn, nhưng nếu bỏ qua toàn bộ phần analysis thì PRD của bạn sẽ được dựng trên giả định thay vì insight.
|
||||||
|
|
||||||
|
## Vì sao cần Analysis trước Planning?
|
||||||
|
|
||||||
|
PRD trả lời câu hỏi "chúng ta nên xây gì và vì sao?". Nếu đầu vào của nó là những suy nghĩ mơ hồ, bạn sẽ nhận lại một PRD mơ hồ, và mọi tài liệu phía sau đều kế thừa chính sự mơ hồ đó. Kiến trúc dựng trên một PRD yếu sẽ đặt cược sai về mặt kỹ thuật. Stories sinh ra từ một kiến trúc yếu sẽ bỏ sót edge case. Chi phí sẽ dồn lên theo từng tầng.
|
||||||
|
|
||||||
|
Các công cụ analysis tồn tại để làm PRD của bạn sắc bén hơn. Chúng tiếp cận vấn đề từ nhiều góc độ khác nhau: khám phá sáng tạo, thực tế thị trường, độ rõ ràng về khách hàng, tính khả thi. Nhờ vậy, đến khi bạn ngồi xuống làm việc với PM agent, bạn đã biết mình đang xây cái gì và cho ai.
|
||||||
|
|
||||||
|
## Các công cụ
|
||||||
|
|
||||||
|
### Brainstorming
|
||||||
|
|
||||||
|
**Nó là gì.** Một phiên sáng tạo có điều phối, sử dụng các kỹ thuật ideation đã được kiểm chứng. AI đóng vai trò như người huấn luyện, kéo ý tưởng ra từ bạn thông qua các bài tập có cấu trúc, chứ không nghĩ thay cho bạn.
|
||||||
|
|
||||||
|
**Vì sao nó có mặt ở đây.** Ý tưởng thô cần không gian để phát triển trước khi bị khóa cứng thành requirement. Brainstorming tạo ra khoảng không đó. Nó đặc biệt có giá trị khi bạn có một miền vấn đề nhưng chưa có lời giải rõ ràng, hoặc khi bạn muốn khám phá nhiều hướng trước khi commit.
|
||||||
|
|
||||||
|
**Khi nào nên dùng.** Bạn có một hình dung mơ hồ về thứ mình muốn xây nhưng chưa kết tinh được thành khái niệm rõ ràng. Hoặc bạn đã có concept ban đầu nhưng muốn pressure-test nó với các phương án thay thế.
|
||||||
|
|
||||||
|
Xem [Brainstorming](./brainstorming.md) để hiểu sâu hơn về cách một phiên làm việc diễn ra.
|
||||||
|
|
||||||
|
### Research (Thị trường, miền nghiệp vụ, kỹ thuật)
|
||||||
|
|
||||||
|
**Nó là gì.** Ba workflow nghiên cứu tập trung vào các chiều khác nhau của ý tưởng. Market research xem xét đối thủ, xu hướng và cảm nhận của người dùng. Domain research xây dựng hiểu biết về miền nghiệp vụ và thuật ngữ. Technical research đánh giá tính khả thi, các lựa chọn kiến trúc và hướng triển khai.
|
||||||
|
|
||||||
|
**Vì sao nó có mặt ở đây.** Xây dựng dựa trên giả định là con đường nhanh nhất để tạo ra thứ chẳng ai cần. Research đặt concept của bạn xuống mặt đất: đối thủ nào đã tồn tại, người dùng thực sự đang vật lộn với điều gì, điều gì khả thi về kỹ thuật, và bạn sẽ phải đối mặt với những ràng buộc đặc thù ngành nào.
|
||||||
|
|
||||||
|
**Khi nào nên dùng.** Bạn đang bước vào một miền mới, nghi ngờ có đối thủ nhưng chưa lập bản đồ được, hoặc concept của bạn phụ thuộc vào những năng lực kỹ thuật mà bạn chưa kiểm chứng. Có thể chạy một, hai, hoặc cả ba; mỗi workflow đều đứng độc lập.
|
||||||
|
|
||||||
|
### Product Brief
|
||||||
|
|
||||||
|
**Nó là gì.** Một phiên discovery có hướng dẫn, tạo ra bản tóm tắt điều hành 1-2 trang cho concept sản phẩm của bạn. AI đóng vai trò Business Analyst cộng tác, giúp bạn diễn đạt tầm nhìn, đối tượng mục tiêu, giá trị cốt lõi và phạm vi.
|
||||||
|
|
||||||
|
**Vì sao nó có mặt ở đây.** Product brief là con đường nhẹ nhàng hơn để đi vào planning. Nó ghi lại tầm nhìn chiến lược của bạn theo định dạng có cấu trúc và đưa thẳng vào quá trình tạo PRD. Nó hoạt động tốt nhất khi bạn đã có niềm tin tương đối chắc vào concept của mình: bạn biết khách hàng là ai, vấn đề là gì, và đại khái muốn xây gì. Brief sẽ tổ chức lại và làm sắc nét lối suy nghĩ đó.
|
||||||
|
|
||||||
|
**Khi nào nên dùng.** Concept của bạn đã tương đối rõ và bạn muốn ghi lại nó một cách hiệu quả trước khi tạo PRD. Bạn tin vào hướng đi hiện tại và không cần bị thách thức giả định một cách quá quyết liệt.
|
||||||
|
|
||||||
|
### PRFAQ (Working Backwards)
|
||||||
|
|
||||||
|
**Nó là gì.** Phương pháp Working Backwards của Amazon được chuyển thành một thử thách tương tác. Bạn viết thông cáo báo chí công bố sản phẩm hoàn thiện trước khi tồn tại dù chỉ một dòng code, rồi trả lời những câu hỏi khó nhất mà khách hàng và stakeholder sẽ đặt ra. AI đóng vai trò product coach dai dẳng nhưng mang tính xây dựng.
|
||||||
|
|
||||||
|
**Vì sao nó có mặt ở đây.** PRFAQ là con đường nghiêm ngặt hơn để đi vào planning. Nó buộc bạn đạt đến sự rõ ràng theo hướng customer-first bằng cách bắt bạn bảo vệ từng phát biểu. Nếu bạn không viết nổi một thông cáo báo chí đủ thuyết phục, sản phẩm đó chưa sẵn sàng. Nếu phần FAQ lộ ra những khoảng trống, đó chính là những khoảng trống mà bạn sẽ phát hiện muộn hơn rất nhiều, và với chi phí lớn hơn nhiều, trong lúc triển khai. Bài kiểm tra này bóc tách lối suy nghĩ yếu ngay từ sớm, khi chi phí sửa còn rẻ nhất.
|
||||||
|
|
||||||
|
**Khi nào nên dùng.** Bạn muốn stress-test concept trước khi commit tài nguyên. Bạn chưa chắc người dùng có thực sự quan tâm hay không. Bạn muốn xác nhận rằng mình có thể diễn đạt một value proposition rõ ràng và có thể bảo vệ được. Hoặc đơn giản là bạn muốn dùng sự kỷ luật của Working Backwards để làm suy nghĩ của mình sắc bén hơn.
|
||||||
|
|
||||||
|
## Tôi nên dùng cái nào?
|
||||||
|
|
||||||
|
| Tình huống | Công cụ được khuyến nghị |
|
||||||
|
| --------- | ------------------------ |
|
||||||
|
| "Tôi có một ý tưởng mơ hồ, chưa biết bắt đầu từ đâu" | Brainstorming |
|
||||||
|
| "Tôi cần hiểu thị trường trước khi quyết định" | Research |
|
||||||
|
| "Tôi biết mình muốn xây gì rồi, chỉ cần ghi lại" | Product Brief |
|
||||||
|
| "Tôi muốn chắc rằng ý tưởng này thực sự đáng để xây" | PRFAQ |
|
||||||
|
| "Tôi muốn khám phá, rồi kiểm chứng, rồi ghi lại" | Brainstorming → Research → PRFAQ hoặc Brief |
|
||||||
|
|
||||||
|
Product Brief và PRFAQ đều tạo ra đầu vào cho PRD. Hãy chọn một trong hai tùy vào mức độ thách thức bạn muốn. Brief là discovery mang tính cộng tác. PRFAQ là một bài kiểm tra khắc nghiệt. Cả hai đều đưa bạn tới cùng một đích; PRFAQ chỉ kiểm tra xem concept của bạn có thật sự xứng đáng để đến đó hay không.
|
||||||
|
|
||||||
|
:::tip[Chưa chắc nên bắt đầu ở đâu?]
|
||||||
|
Hãy chạy `bmad-help` và mô tả tình huống của bạn. Nó sẽ gợi ý điểm bắt đầu phù hợp dựa trên những gì bạn đã làm và điều bạn đang muốn đạt được.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## Sau Analysis thì chuyện gì xảy ra?
|
||||||
|
|
||||||
|
Output từ Analysis đi thẳng vào Phase 2 (Planning). Workflow tạo PRD chấp nhận product brief, tài liệu PRFAQ, kết quả research và báo cáo brainstorming làm đầu vào. Nó sẽ tổng hợp bất cứ thứ gì bạn đã tạo thành các requirement có cấu trúc. Bạn làm analysis càng kỹ, PRD của bạn càng sắc.
|
||||||
|
|
@ -0,0 +1,33 @@
|
||||||
|
---
|
||||||
|
title: "Động não ý tưởng"
|
||||||
|
description: Các phiên sáng tạo tương tác sử dụng hơn 60 kỹ thuật khơi ý đã được kiểm chứng
|
||||||
|
sidebar:
|
||||||
|
order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
Mở khóa sự sáng tạo của bạn thông qua quá trình khám phá có hướng dẫn.
|
||||||
|
|
||||||
|
## Động não ý tưởng là gì?
|
||||||
|
|
||||||
|
Chạy `bmad-brainstorming` và bạn sẽ có một người điều phối sáng tạo giúp rút ý tưởng từ chính bạn - không phải phát sinh thay bạn. AI đóng vai trò huấn luyện viên và người dẫn đường, sử dụng các kỹ thuật đã được kiểm chứng để tạo điều kiện cho những ý tưởng tốt nhất của bạn xuất hiện.
|
||||||
|
|
||||||
|
**Phù hợp cho:**
|
||||||
|
|
||||||
|
- Phá vỡ thế bí ý tưởng
|
||||||
|
- Tạo ý tưởng sản phẩm hoặc tính năng
|
||||||
|
- Xem xét vấn đề từ góc nhìn mới
|
||||||
|
- Biến các khái niệm thô thành kế hoạch hành động
|
||||||
|
|
||||||
|
## Nó hoạt động như thế nào
|
||||||
|
|
||||||
|
1. **Thiết lập** - Xác định chủ đề, mục tiêu, ràng buộc
|
||||||
|
2. **Chọn cách tiếp cận** - Tự chọn kỹ thuật, để AI đề xuất, chọn ngẫu nhiên, hoặc đi theo một luồng tiến trình
|
||||||
|
3. **Điều phối** - Làm việc qua từng kỹ thuật bằng các câu hỏi gợi mở và huấn luyện cộng tác
|
||||||
|
4. **Sắp xếp** - Gom ý tưởng theo chủ đề và ưu tiên hóa
|
||||||
|
5. **Hành động** - Các ý tưởng tốt nhất sẽ được gán bước tiếp theo và chỉ số thành công
|
||||||
|
|
||||||
|
Mọi thứ đều được ghi lại trong tài liệu phiên làm việc để bạn có thể xem lại sau này hoặc chia sẻ với stakeholder.
|
||||||
|
|
||||||
|
:::note[Ý tưởng của bạn]
|
||||||
|
Mọi ý tưởng đều đến từ bạn. Workflow chỉ tạo điều kiện cho insight xuất hiện - nguồn gốc vẫn là bạn.
|
||||||
|
:::
|
||||||
|
|
@ -0,0 +1,51 @@
|
||||||
|
---
|
||||||
|
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: 8
|
||||||
|
---
|
||||||
|
|
||||||
|
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).
|
||||||
|
|
||||||
|
## Các câu hỏi
|
||||||
|
|
||||||
|
- [Tôi có phải chạy document-project trước không?](#toi-co-phai-chay-document-project-truoc-khong)
|
||||||
|
- [Nếu tôi quên chạy document-project thì sao?](#neu-toi-quen-chay-document-project-thi-sao)
|
||||||
|
- [Tôi có thể dùng Quick Flow cho dự án đã tồn tại không?](#toi-co-the-dung-quick-flow-cho-du-an-da-ton-tai-khong)
|
||||||
|
- [Nếu code hiện tại của tôi không theo best practices thì sao?](#neu-code-hien-tai-cua-toi-khong-theo-best-practices-thi-sao)
|
||||||
|
|
||||||
|
### Tôi có phải chạy document-project trước không?
|
||||||
|
|
||||||
|
Rất nên chạy, nhất là khi:
|
||||||
|
|
||||||
|
- Không có tài liệu sẵn có
|
||||||
|
- Tài liệu đã lỗi thời
|
||||||
|
- Agent AI cần context về code hiện có
|
||||||
|
|
||||||
|
Bạn có thể bỏ qua nếu đã có tài liệu đầy đủ, mới, bao gồm `docs/index.md`, hoặc bạn sẽ dùng công cụ/kỹ thuật khác để giúp agent khám phá hệ thống hiện có.
|
||||||
|
|
||||||
|
### Nếu tôi quên chạy document-project thì sao?
|
||||||
|
|
||||||
|
Không sao - bạn có thể chạy nó bất cứ lúc nào. Bạn thậm chí có thể chạy trong khi dự án đang diễn ra hoặc sau đó để giữ tài liệu luôn mới.
|
||||||
|
|
||||||
|
### Tôi có thể dùng Quick Flow cho dự án đã tồn tại không?
|
||||||
|
|
||||||
|
Có. Quick Flow hoạt động rất tốt với dự án đã tồn tại. Nó sẽ:
|
||||||
|
|
||||||
|
- Tự động nhận diện stack hiện có
|
||||||
|
- Phân tích pattern code hiện có
|
||||||
|
- Phát hiện quy ước và hỏi bạn để xác nhận
|
||||||
|
- Tạo spec giàu ngữ cảnh, tôn trọng code hiện có
|
||||||
|
|
||||||
|
Rất hợp với sửa lỗi và tính năng nhỏ trong codebase sẵn có.
|
||||||
|
|
||||||
|
### Nếu code hiện tại của tôi không theo best practices thì sao?
|
||||||
|
|
||||||
|
Quick Flow sẽ nhận diện quy ước hiện có và hỏi: "Tôi có nên tuân theo những quy ước hiện tại này không?" Bạn là người quyết định:
|
||||||
|
|
||||||
|
- **Có** → Giữ tính nhất quán với codebase hiện tại
|
||||||
|
- **Không** → Đặt ra chuẩn mới, đồng thời ghi rõ lý do trong spec
|
||||||
|
|
||||||
|
BMM tôn trọng lựa chọn của bạn - nó không ép buộc hiện đại hóa, nhưng sẽ đưa ra lựa chọn đó.
|
||||||
|
|
||||||
|
**Có câu hỏi chưa được trả lời ở đây?** Hãy [mở issue](https://github.com/bmad-code-org/BMAD-METHOD/issues) hoặc hỏi trên [Discord](https://discord.gg/gk8jAdXWmj) để chúng tôi bổ sung!
|
||||||
|
|
@ -0,0 +1,59 @@
|
||||||
|
---
|
||||||
|
title: "Party Mode"
|
||||||
|
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: 7
|
||||||
|
---
|
||||||
|
|
||||||
|
Đưa tất cả agent AI của bạn vào cùng một cuộc trò chuyện.
|
||||||
|
|
||||||
|
## Party Mode là gì?
|
||||||
|
|
||||||
|
Chạy `bmad-party-mode` và bạn sẽ có cả đội AI trong cùng một phòng - PM, Architect, Dev, UX Designer, bất kỳ ai bạn cần. BMad Master điều phối, chọn các agent liên quan cho từng tin nhắn. Các agent trả lời đúng vai, đồng ý, phản biện, và bổ sung ý tưởng cho nhau.
|
||||||
|
|
||||||
|
Cuộc trò chuyện tiếp tục lâu đến mức bạn muốn. Bạn có thể hỏi tiếp, phản biện câu trả lời, đổi hướng thảo luận - đó là một cuộc qua lại thật sự với các agent của bạn cho đến khi xong.
|
||||||
|
|
||||||
|
**Phù hợp cho:**
|
||||||
|
|
||||||
|
- Các quyết định lớn có đánh đổi
|
||||||
|
- Các phiên động não ý tưởng
|
||||||
|
- Post-mortem khi mọi thứ đi sai
|
||||||
|
- Retrospective và lập kế hoạch sprint
|
||||||
|
|
||||||
|
## Ví dụ
|
||||||
|
|
||||||
|
### Gọi tên kiến trúc tệ
|
||||||
|
|
||||||
|
**Bạn:** "Được rồi cả đội, sprint vừa rồi là một thảm họa. Dịch vụ xác thực sập ba lần. Ai đã làm hỏng chuyện này?"
|
||||||
|
|
||||||
|
**Architect:** "Thiết kế vẫn ổn - xác thực phân tán với cơ chế fallback hợp lý. Nếu phần triển khai lệch khỏi spec..."
|
||||||
|
|
||||||
|
**Dev:** "Tôi đã làm đúng theo tài liệu kiến trúc. Spec không tính đến race condition khi vô hiệu hóa session đồng thời."
|
||||||
|
|
||||||
|
**PM:** "Cả hai người đều bỏ sót vấn đề lớn hơn - chúng ta không xác thực đúng yêu cầu quản lý session trong PRD. **Lỗi này là do tôi** không bắt được sớm hơn."
|
||||||
|
|
||||||
|
**TEA:** "Và tôi đáng ra phải bắt được nó trong integration test. Các kịch bản test đã không bao phủ trường hợp vô hiệu hóa đồng thời."
|
||||||
|
|
||||||
|
### Động não sáng tạo
|
||||||
|
|
||||||
|
**Bạn:** "Làm sao để quá trình onboarding có cảm giác kỳ diệu thay vì nhàm chán?"
|
||||||
|
|
||||||
|
**UX Designer:** "Bắt đầu bằng progressive disclosure - hiện tính năng khi người dùng cần, thay vì tung một tutorial dày đặc."
|
||||||
|
|
||||||
|
**Storyteller:** "Nếu onboarding là một câu chuyện thì sao? Mỗi bước mở ra hành trình của một nhân vật - người dùng CHÍNH là người hùng."
|
||||||
|
|
||||||
|
**Game Designer:** "Nối tiếp ý đó - nếu 'nhiệm vụ' đầu tiên thực chất giải quyết một vấn đề thật của người dùng thì sao? Họ học bằng cách làm ra giá trị ngay."
|
||||||
|
|
||||||
|
### Quyết định kỹ thuật
|
||||||
|
|
||||||
|
**Bạn:** "MVP nên dùng monolith hay microservices?"
|
||||||
|
|
||||||
|
**Architect:** "Bắt đầu bằng monolith. Microservices thêm độ phức tạp mà bạn chưa cần ở mức 1000 người dùng."
|
||||||
|
|
||||||
|
**PM:** "Đồng ý. Tốc độ ra thị trường quan trọng hơn khả năng mở rộng lý thuyết."
|
||||||
|
|
||||||
|
**Dev:** "Monolith nhưng có ranh giới module rõ ràng. Nếu cần, mình có thể tách service sau."
|
||||||
|
|
||||||
|
:::tip[Quyết định tốt hơn]
|
||||||
|
Quyết định tốt hơn nhờ nhiều góc nhìn đa dạng. Chào mừng đến với party mode.
|
||||||
|
:::
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue