bmad-method 6.0.0-alpha.4 → 6.0.0-alpha.5

package/bmad/bmm/tasks/daily-standup.xml

@@ -64,7 +64,7 @@
       <i>Primary: Sarah (PO), Bob (SM), James (Dev)</i>
       <i>Secondary: Murat (TEA)</i>
     </context>
-    <context type="architecture-review">
+    <context type="validate-architecture">
       <i>Primary: Winston (Architect), James (Dev), Murat (TEA)</i>
       <i>Secondary: Sarah (PO)</i>
     </context>

package/bmad/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml.bak

@@ -0,0 +1,60 @@
+# Technical Specification Workflow (Level 0)
+name: tech-spec
+description: "Technical specification workflow for Level 0 projects (single atomic changes). Creates focused tech spec for bug fixes, single endpoint additions, or small isolated changes. Tech-spec only - no PRD needed."
+author: "BMad"
+
+# Critical variables from config
+config_source: "{project-root}/bmad/bmm/config.yaml"
+project_name: "{config_source}:project_name"
+output_folder: "{config_source}:output_folder"
+user_name: "{config_source}:user_name"
+communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
+date: system-generated
+
+# Runtime variables (captured during workflow execution)
+project_level: runtime-captured
+project_type: runtime-captured
+development_context: runtime-captured
+change_type: runtime-captured
+field_type: runtime-captured
+
+# Workflow components
+installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/tech-spec"
+instructions: "{installed_path}/instructions.md"
+template: "{installed_path}/tech-spec-template.md"
+
+# Story generation instructions (invoked based on level)
+instructions_level0_story: "{installed_path}/instructions-level0-story.md"
+instructions_level1_stories: "{installed_path}/instructions-level1-stories.md"
+
+# Templates
+user_story_template: "{installed_path}/user-story-template.md"
+epics_template: "{installed_path}/epics-template.md"
+
+# Output configuration
+default_output_file: "{output_folder}/tech-spec.md"
+user_story_file: "{output_folder}/user-story.md"
+epics_file: "{output_folder}/epics.md"
+
+# Recommended input documents (optional for Level 0)
+recommended_inputs:
+  - bug_report: "Bug description or issue ticket"
+  - feature_request: "Brief feature description"
+
+# Smart input file references - handles both whole docs and sharded docs
+# Priority: Whole document first, then sharded version
+input_file_patterns:
+  product_brief:
+    whole: "{output_folder}/*brief*.md"
+    sharded: "{output_folder}/*brief*/index.md"
+
+  research:
+    whole: "{output_folder}/*research*.md"
+    sharded: "{output_folder}/*research*/index.md"
+
+  document_project:
+    sharded: "{output_folder}/docs/index.md"
+
+standalone: true

package/bmad/bmm/workflows/4-implementation/epic-tech-context/workflow.yaml

@@ -1,4 +1,4 @@
-name: tech-spec
+name: epic-tech-context
 description: "Generate a comprehensive Technical Specification from PRD and Architecture with acceptance criteria and traceability mapping"
 author: "BMAD BMM"
 

package/bmad/bmm/workflows/techdoc/documentation-standards.md

@@ -1,6 +1,6 @@
 # Technical Documentation Standards for BMAD
 
-**For Agent: Paige (Documentation Guide)**
+**For Agent: Technical Writer**
 **Purpose: Concise reference for documentation creation and review**
 
 ---
@@ -122,6 +122,7 @@ Apply in this hierarchy:
 - Alt text for diagrams: Describe what it shows
 - Semantic heading hierarchy (don't skip levels)
 - Tables have headers
+- Emojis are acceptable if user preferences allow (modern accessibility tools support emojis well)
 
 ---
 

package/bmad/bmm/workflows/techdoc/documentation-standards.md.bak

@@ -0,0 +1,238 @@
+# Technical Documentation Standards for BMAD
+
+**For Agent: Paige (Documentation Guide)**
+**Purpose: Concise reference for documentation creation and review**
+
+---
+
+## CRITICAL RULE: CommonMark Strict Compliance
+
+ALL documentation MUST follow CommonMark specification exactly. No exceptions.
+
+### CommonMark Essentials
+
+**Headers:**
+
+- Use ATX-style ONLY: `#` `##` `###` (NOT Setext underlines)
+- Single space after `#`: `# Title` (NOT `#Title`)
+- No trailing `#`: `# Title` (NOT `# Title #`)
+- Hierarchical order: Don't skip levels (h1→h2→h3, not h1→h3)
+
+**Code Blocks:**
+
+- Use fenced blocks with language identifier:
+  ````markdown
+  ```javascript
+  const example = 'code';
+  ```
+  ````
+- NOT indented code blocks (ambiguous)
+
+**Lists:**
+
+- Consistent markers within list: all `-` or all `*` or all `+` (don't mix)
+- Proper indentation for nested items (2 or 4 spaces, stay consistent)
+- Blank line before/after list for clarity
+
+**Links:**
+
+- Inline: `[text](url)`
+- Reference: `[text][ref]` then `[ref]: url` at bottom
+- NO bare URLs without `<>` brackets
+
+**Emphasis:**
+
+- Italic: `*text*` or `_text_`
+- Bold: `**text**` or `__text__`
+- Consistent style within document
+
+**Line Breaks:**
+
+- Two spaces at end of line + newline, OR
+- Blank line between paragraphs
+- NO single line breaks (they're ignored)
+
+---
+
+## Mermaid Diagrams: Valid Syntax Required
+
+**Critical Rules:**
+
+1. Always specify diagram type first line
+2. Use valid Mermaid v10+ syntax
+3. Test syntax before outputting (mental validation)
+4. Keep focused: 5-10 nodes ideal, max 15
+
+**Diagram Type Selection:**
+
+- **flowchart** - Process flows, decision trees, workflows
+- **sequenceDiagram** - API interactions, message flows, time-based processes
+- **classDiagram** - Object models, class relationships, system structure
+- **erDiagram** - Database schemas, entity relationships
+- **stateDiagram-v2** - State machines, lifecycle stages
+- **gitGraph** - Branch strategies, version control flows
+
+**Formatting:**
+
+````markdown
+```mermaid
+flowchart TD
+    Start[Clear Label] --> Decision{Question?}
+    Decision -->|Yes| Action1[Do This]
+    Decision -->|No| Action2[Do That]
+```
+````
+
+---
+
+## Style Guide Principles (Distilled)
+
+Apply in this hierarchy:
+
+1. **Project-specific guide** (if exists) - always ask first
+2. **BMAD conventions** (this document)
+3. **Google Developer Docs style** (defaults below)
+4. **CommonMark spec** (when in doubt)
+
+### Core Writing Rules
+
+**Task-Oriented Focus:**
+
+- Write for user GOALS, not feature lists
+- Start with WHY, then HOW
+- Every doc answers: "What can I accomplish?"
+
+**Clarity Principles:**
+
+- Active voice: "Click the button" NOT "The button should be clicked"
+- Present tense: "The function returns" NOT "The function will return"
+- Direct language: "Use X for Y" NOT "X can be used for Y"
+- Second person: "You configure" NOT "Users configure" or "One configures"
+
+**Structure:**
+
+- One idea per sentence
+- One topic per paragraph
+- Headings describe content accurately
+- Examples follow explanations
+
+**Accessibility:**
+
+- Descriptive link text: "See the API reference" NOT "Click here"
+- Alt text for diagrams: Describe what it shows
+- Semantic heading hierarchy (don't skip levels)
+- Tables have headers
+
+---
+
+## OpenAPI/API Documentation
+
+**Required Elements:**
+
+- Endpoint path and method
+- Authentication requirements
+- Request parameters (path, query, body) with types
+- Request example (realistic, working)
+- Response schema with types
+- Response examples (success + common errors)
+- Error codes and meanings
+
+**Quality Standards:**
+
+- OpenAPI 3.0+ specification compliance
+- Complete schemas (no missing fields)
+- Examples that actually work
+- Clear error messages
+- Security schemes documented
+
+---
+
+## Documentation Types: Quick Reference
+
+**README:**
+
+- What (overview), Why (purpose), How (quick start)
+- Installation, Usage, Contributing, License
+- Under 500 lines (link to detailed docs)
+
+**API Reference:**
+
+- Complete endpoint coverage
+- Request/response examples
+- Authentication details
+- Error handling
+- Rate limits if applicable
+
+**User Guide:**
+
+- Task-based sections (How to...)
+- Step-by-step instructions
+- Screenshots/diagrams where helpful
+- Troubleshooting section
+
+**Architecture Docs:**
+
+- System overview diagram (Mermaid)
+- Component descriptions
+- Data flow
+- Technology decisions (ADRs)
+- Deployment architecture
+
+**Developer Guide:**
+
+- Setup/environment requirements
+- Code organization
+- Development workflow
+- Testing approach
+- Contribution guidelines
+
+---
+
+## Quality Checklist
+
+Before finalizing ANY documentation:
+
+- [ ] CommonMark compliant (no violations)
+- [ ] Headers in proper hierarchy
+- [ ] All code blocks have language tags
+- [ ] Links work and have descriptive text
+- [ ] Mermaid diagrams render correctly
+- [ ] Active voice, present tense
+- [ ] Task-oriented (answers "how do I...")
+- [ ] Examples are concrete and working
+- [ ] Accessibility standards met
+- [ ] Spelling/grammar checked
+- [ ] Reads clearly at target skill level
+
+---
+
+## BMAD-Specific Conventions
+
+**File Organization:**
+
+- `README.md` at root of each major component
+- `docs/` folder for extensive documentation
+- Workflow-specific docs in workflow folder
+- Cross-references use relative paths
+
+**Frontmatter:**
+Use YAML frontmatter when appropriate:
+
+```yaml
+---
+title: Document Title
+description: Brief description
+author: Author name
+date: YYYY-MM-DD
+---
+```
+
+**Metadata:**
+
+- Always include last-updated date
+- Version info for versioned docs
+- Author attribution for accountability
+
+---
+
+**Remember: This is your foundation. Follow these rules consistently, and all documentation will be clear, accessible, and maintainable.**