bmad-method 4.32.0 → 4.33.0

package/CHANGELOG.md

@@ -1,15 +1,20 @@
-# [4.32.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.31.0...v4.32.0) (2025-07-27)
+# [4.33.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.32.0...v4.33.0) (2025-07-28)
 
 
-### Bug Fixes
+### Features
+
+* version bump ([e9dd4e7](https://github.com/bmadcode/BMAD-METHOD/commit/e9dd4e7beb46d0c80df0cd65ae02d1867a56d7c1))
 
-* Add package-lock.json to fix GitHub Actions dependency resolution ([cce7a75](https://github.com/bmadcode/BMAD-METHOD/commit/cce7a758a632053e26d143b678eb7963599b432d))
-* GHA fix ([62ccccd](https://github.com/bmadcode/BMAD-METHOD/commit/62ccccdc9e85f8621f63f99bd1ce0d14abe09783))
+# [4.32.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.31.0...v4.32.0) (2025-07-27)
+
+### Bug Fixes
 
+- Add package-lock.json to fix GitHub Actions dependency resolution ([cce7a75](https://github.com/bmadcode/BMAD-METHOD/commit/cce7a758a632053e26d143b678eb7963599b432d))
+- GHA fix ([62ccccd](https://github.com/bmadcode/BMAD-METHOD/commit/62ccccdc9e85f8621f63f99bd1ce0d14abe09783))
 
 ### Features
 
-* Overhaul and Enhance 2D Unity Game Dev Expansion Pack ([#350](https://github.com/bmadcode/BMAD-METHOD/issues/350)) ([a7038d4](https://github.com/bmadcode/BMAD-METHOD/commit/a7038d43d18246f6aef175aa89ba059b7c94f61f))
+- Overhaul and Enhance 2D Unity Game Dev Expansion Pack ([#350](https://github.com/bmadcode/BMAD-METHOD/issues/350)) ([a7038d4](https://github.com/bmadcode/BMAD-METHOD/commit/a7038d43d18246f6aef175aa89ba059b7c94f61f))
 
 # [4.31.0](https://github.com/bmadcode/BMAD-METHOD/compare/v4.30.4...v4.31.0) (2025-07-20)
 

package/README.md

@@ -126,11 +126,18 @@ The BMad-Method includes a powerful codebase flattener tool designed to prepare
 
 ```bash
 # Basic usage - creates flattened-codebase.xml in current directory
-npm run flatten
+npx bmad-method flatten
+
+# Specify custom input directory
+npx bmad-method flatten --input /path/to/source/directory
+npx bmad-method flatten -i /path/to/source/directory
 
 # Specify custom output file
-npm run flatten -- --output my-project.xml
-npm run flatten -- -o /path/to/output/codebase.xml
+npx bmad-method flatten --output my-project.xml
+npx bmad-method flatten -o /path/to/output/codebase.xml
+
+# Combine input and output options
+npx bmad-method flatten --input /path/to/source --output /path/to/output/codebase.xml
 ```
 
 ### Example Output

package/bmad-core/checklists/architect-checklist.md

@@ -403,33 +403,28 @@ Ask the user if they want to work through the checklist:
 Now that you've completed the checklist, generate a comprehensive validation report that includes:
 
 1. Executive Summary
-
    - Overall architecture readiness (High/Medium/Low)
    - Critical risks identified
    - Key strengths of the architecture
    - Project type (Full-stack/Frontend/Backend) and sections evaluated
 
 2. Section Analysis
-
    - Pass rate for each major section (percentage of items passed)
    - Most concerning failures or gaps
    - Sections requiring immediate attention
    - Note any sections skipped due to project type
 
 3. Risk Assessment
-
    - Top 5 risks by severity
    - Mitigation recommendations for each
    - Timeline impact of addressing issues
 
 4. Recommendations
-
    - Must-fix items before development
    - Should-fix items for better quality
    - Nice-to-have improvements
 
 5. AI Implementation Readiness
-
    - Specific concerns for AI agent implementation
    - Areas needing additional clarification
    - Complexity hotspots to address

package/bmad-core/checklists/pm-checklist.md

@@ -304,7 +304,6 @@ Ask the user if they want to work through the checklist:
 Create a comprehensive validation report that includes:
 
 1. Executive Summary
-
    - Overall PRD completeness (percentage)
    - MVP scope appropriateness (Too Large/Just Right/Too Small)
    - Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
@@ -312,26 +311,22 @@ Create a comprehensive validation report that includes:
 
 2. Category Analysis Table
    Fill in the actual table with:
-
    - Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
    - Critical Issues: Specific problems that block progress
 
 3. Top Issues by Priority
-
    - BLOCKERS: Must fix before architect can proceed
    - HIGH: Should fix for quality
    - MEDIUM: Would improve clarity
    - LOW: Nice to have
 
 4. MVP Scope Assessment
-
    - Features that might be cut for true MVP
    - Missing features that are essential
    - Complexity concerns
    - Timeline realism
 
 5. Technical Readiness
-
    - Clarity of technical constraints
    - Identified technical risks
    - Areas needing architect investigation

package/bmad-core/checklists/po-master-checklist.md

@@ -8,12 +8,10 @@ PROJECT TYPE DETECTION:
 First, determine the project type by checking:
 
 1. Is this a GREENFIELD project (new from scratch)?
-
    - Look for: New project initialization, no existing codebase references
    - Check for: prd.md, architecture.md, new project setup stories
 
 2. Is this a BROWNFIELD project (enhancing existing system)?
-
    - Look for: References to existing codebase, enhancement/modification language
    - Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
 
@@ -347,7 +345,6 @@ Ask the user if they want to work through the checklist:
 Generate a comprehensive validation report that adapts to project type:
 
 1. Executive Summary
-
    - Project type: [Greenfield/Brownfield] with [UI/No UI]
    - Overall readiness (percentage)
    - Go/No-Go recommendation
@@ -357,42 +354,36 @@ Generate a comprehensive validation report that adapts to project type:
 2. Project-Specific Analysis
 
    FOR GREENFIELD:
-
    - Setup completeness
    - Dependency sequencing
    - MVP scope appropriateness
    - Development timeline feasibility
 
    FOR BROWNFIELD:
-
    - Integration risk level (High/Medium/Low)
    - Existing system impact assessment
    - Rollback readiness
    - User disruption potential
 
 3. Risk Assessment
-
    - Top 5 risks by severity
    - Mitigation recommendations
    - Timeline impact of addressing issues
    - [BROWNFIELD] Specific integration risks
 
 4. MVP Completeness
-
    - Core features coverage
    - Missing essential functionality
    - Scope creep identified
    - True MVP vs over-engineering
 
 5. Implementation Readiness
-
    - Developer clarity score (1-10)
    - Ambiguous requirements count
    - Missing technical details
    - [BROWNFIELD] Integration point clarity
 
 6. Recommendations
-
    - Must-fix before development
    - Should-fix for quality
    - Consider for improvement

package/bmad-core/checklists/story-dod-checklist.md

@@ -25,14 +25,12 @@ The goal is quality delivery, not just checking boxes.]]
 1. **Requirements Met:**
 
    [[LLM: Be specific - list each requirement and whether it's complete]]
-
    - [ ] All functional requirements specified in the story are implemented.
    - [ ] All acceptance criteria defined in the story are met.
 
 2. **Coding Standards & Project Structure:**
 
    [[LLM: Code quality matters for maintainability. Check each item carefully]]
-
    - [ ] All new/modified code strictly adheres to `Operational Guidelines`.
    - [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
    - [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
@@ -44,7 +42,6 @@ The goal is quality delivery, not just checking boxes.]]
 3. **Testing:**
 
    [[LLM: Testing proves your code works. Be honest about test coverage]]
-
    - [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
    - [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
    - [ ] All tests (unit, integration, E2E if applicable) pass successfully.
@@ -53,14 +50,12 @@ The goal is quality delivery, not just checking boxes.]]
 4. **Functionality & Verification:**
 
    [[LLM: Did you actually run and test your code? Be specific about what you tested]]
-
    - [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
    - [ ] Edge cases and potential error conditions considered and handled gracefully.
 
 5. **Story Administration:**
 
    [[LLM: Documentation helps the next developer. What should they know?]]
-
    - [ ] All tasks within the story file are marked as complete.
    - [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
    - [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
@@ -68,7 +63,6 @@ The goal is quality delivery, not just checking boxes.]]
 6. **Dependencies, Build & Configuration:**
 
    [[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
-
    - [ ] Project builds successfully without errors.
    - [ ] Project linting passes
    - [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
@@ -79,7 +73,6 @@ The goal is quality delivery, not just checking boxes.]]
 7. **Documentation (If Applicable):**
 
    [[LLM: Good documentation prevents future confusion. What needs explaining?]]
-
    - [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
    - [ ] User-facing documentation updated, if changes impact users.
    - [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.

package/bmad-core/checklists/story-draft-checklist.md

@@ -117,19 +117,16 @@ Note: We don't need every file listed - just the important ones.]]
 Generate a concise validation report:
 
 1. Quick Summary
-
    - Story readiness: READY / NEEDS REVISION / BLOCKED
    - Clarity score (1-10)
    - Major gaps identified
 
 2. Fill in the validation table with:
-
    - PASS: Requirements clearly met
    - PARTIAL: Some gaps but workable
    - FAIL: Critical information missing
 
 3. Specific Issues (if any)
-
    - List concrete problems to fix
    - Suggest specific improvements
    - Identify any blocking dependencies

package/bmad-core/data/bmad-kb.md

@@ -477,7 +477,6 @@ that can handle [specific requirements]."
 **Prerequisites**: Planning documents must exist in `docs/` folder
 
 1. **Document Sharding** (CRITICAL STEP):
-
    - Documents created by PM/Architect (in Web or IDE) MUST be sharded for development
    - Two methods to shard:
      a) **Manual**: Drag `shard-doc` task + document file into chat
@@ -500,20 +499,17 @@ Resulting Folder Structure:
 1. **Development Cycle** (Sequential, one story at a time):
 
    **CRITICAL CONTEXT MANAGEMENT**:
-
    - **Context windows matter!** Always use fresh, clean context windows
    - **Model selection matters!** Use most powerful thinking model for SM story creation
    - **ALWAYS start new chat between SM, Dev, and QA work**
 
    **Step 1 - Story Creation**:
-
    - **NEW CLEAN CHAT** → Select powerful model → `@sm` → `*create`
    - SM executes create-next-story task
    - Review generated story in `docs/stories/`
    - Update status from "Draft" to "Approved"
 
    **Step 2 - Story Implementation**:
-
    - **NEW CLEAN CHAT** → `@dev`
    - Agent asks which story to implement
    - Include story file content to save dev agent lookup time
@@ -522,7 +518,6 @@ Resulting Folder Structure:
    - Dev marks story as "Review" when complete with all tests passing
 
    **Step 3 - Senior QA Review**:
-
    - **NEW CLEAN CHAT** → `@qa` → execute review-story task
    - QA performs senior developer code review
    - QA can refactor and improve code directly
@@ -574,11 +569,9 @@ Each status change requires user verification and approval before proceeding.
 1. **Upload project to Gemini Web**
 2. **Document everything**: `@analyst` → `*document-project`
 3. **Then create PRD**: `@pm` → `*create-doc brownfield-prd`
-
    - More thorough but can create excessive documentation
 
 4. **Requirements Gathering**:
-
    - **Brownfield PRD**: Use PM agent with `brownfield-prd-tmpl`
    - **Analyzes**: Existing system, constraints, integration points
    - **Defines**: Enhancement scope, compatibility requirements, risk assessment

package/bmad-core/tasks/advanced-elicitation.md

@@ -41,14 +41,12 @@ User can request advanced elicitation on any agent output:
 **Method Selection Strategy**:
 
 1. **Always Include Core Methods** (choose 3-4):
-
    - Expand or Contract for Audience
    - Critique and Refine
    - Identify Potential Risks
    - Assess Alignment with Goals
 
 2. **Context-Specific Methods** (choose 4-5):
-
    - **Technical Content**: Tree of Thoughts, ReWOO, Meta-Prompting
    - **User-Facing Content**: Agile Team Perspective, Stakeholder Roundtable
    - **Creative Content**: Innovation Tournament, Escape Room Challenge

package/bmad-core/tasks/create-brownfield-story.md

@@ -27,20 +27,16 @@ Create detailed, implementation-ready stories for brownfield projects where trad
 Check for available documentation in this order:
 
 1. **Sharded PRD/Architecture** (docs/prd/, docs/architecture/)
-
    - If found, recommend using create-next-story task instead
 
 2. **Brownfield Architecture Document** (docs/brownfield-architecture.md or similar)
-
    - Created by document-project task
    - Contains actual system state, technical debt, workarounds
 
 3. **Brownfield PRD** (docs/prd.md)
-
    - May contain embedded technical details
 
 4. **Epic Files** (docs/epics/ or similar)
-
    - Created by brownfield-create-epic task
 
 5. **User-Provided Documentation**
@@ -179,19 +175,16 @@ Example task structure for brownfield:
 ## Tasks / Subtasks
 
 - [ ] Task 1: Analyze existing {{component/feature}} implementation
-
   - [ ] Review {{specific files}} for current patterns
   - [ ] Document integration points
   - [ ] Identify potential impacts
 
 - [ ] Task 2: Implement {{new functionality}}
-
   - [ ] Follow pattern from {{example file}}
   - [ ] Integrate with {{existing component}}
   - [ ] Maintain compatibility with {{constraint}}
 
 - [ ] Task 3: Verify existing functionality
-
   - [ ] Test {{existing feature 1}} still works
   - [ ] Verify {{integration point}} behavior unchanged
   - [ ] Check performance impact
@@ -234,14 +227,12 @@ Add section for brownfield-specific risks:
 Before finalizing:
 
 1. **Completeness Check**:
-
    - [ ] Story has clear scope and acceptance criteria
    - [ ] Technical context is sufficient for implementation
    - [ ] Integration approach is defined
    - [ ] Risks are identified with mitigation
 
 2. **Safety Check**:
-
    - [ ] Existing functionality protection included
    - [ ] Rollback plan is feasible
    - [ ] Testing covers both new and existing features

package/bmad-core/tasks/create-deep-research-prompt.md

@@ -21,63 +21,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
 Present these numbered options to the user:
 
 1. **Product Validation Research**
-
    - Validate product hypotheses and market fit
    - Test assumptions about user needs and solutions
    - Assess technical and business feasibility
    - Identify risks and mitigation strategies
 
 2. **Market Opportunity Research**
-
    - Analyze market size and growth potential
    - Identify market segments and dynamics
    - Assess market entry strategies
    - Evaluate timing and market readiness
 
 3. **User & Customer Research**
-
    - Deep dive into user personas and behaviors
    - Understand jobs-to-be-done and pain points
    - Map customer journeys and touchpoints
    - Analyze willingness to pay and value perception
 
 4. **Competitive Intelligence Research**
-
    - Detailed competitor analysis and positioning
    - Feature and capability comparisons
    - Business model and strategy analysis
    - Identify competitive advantages and gaps
 
 5. **Technology & Innovation Research**
-
    - Assess technology trends and possibilities
    - Evaluate technical approaches and architectures
    - Identify emerging technologies and disruptions
    - Analyze build vs. buy vs. partner options
 
 6. **Industry & Ecosystem Research**
-
    - Map industry value chains and dynamics
    - Identify key players and relationships
    - Analyze regulatory and compliance factors
    - Understand partnership opportunities
 
 7. **Strategic Options Research**
-
    - Evaluate different strategic directions
    - Assess business model alternatives
    - Analyze go-to-market strategies
    - Consider expansion and scaling paths
 
 8. **Risk & Feasibility Research**
-
    - Identify and assess various risk factors
    - Evaluate implementation challenges
    - Analyze resource requirements
    - Consider regulatory and legal implications
 
 9. **Custom Research Focus**
-
    - User-defined research objectives
    - Specialized domain investigation
    - Cross-functional research needs
@@ -246,13 +237,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
 ### 5. Review and Refinement
 
 1. **Present Complete Prompt**
-
    - Show the full research prompt
    - Explain key elements and rationale
    - Highlight any assumptions made
 
 2. **Gather Feedback**
-
    - Are the objectives clear and correct?
    - Do the questions address all concerns?
    - Is the scope appropriate?

package/bmad-core/tasks/document-project.md

@@ -27,7 +27,6 @@ Ask the user:
 2. **Provide existing requirements** - Do you have a requirements document, epic, or feature description you can share?
 
 3. **Describe the focus** - Can you briefly describe what enhancement or feature you're planning? For example:
-
    - 'Adding payment processing to the user service'
    - 'Refactoring the authentication module'
    - 'Integrating with a new third-party API'
@@ -63,7 +62,6 @@ Ask the user these elicitation questions to better understand their needs:
 CRITICAL: Before generating documentation, conduct extensive analysis of the existing codebase:
 
 1. **Explore Key Areas**:
-
    - Entry points (main files, index files, app initializers)
    - Configuration files and environment setup
    - Package dependencies and versions
@@ -71,7 +69,6 @@ CRITICAL: Before generating documentation, conduct extensive analysis of the exi
    - Test suites and coverage
 
 2. **Ask Clarifying Questions**:
-
    - "I see you're using [technology X]. Are there any custom patterns or conventions I should document?"
    - "What are the most critical/complex parts of this system that developers struggle with?"
    - "Are there any undocumented 'tribal knowledge' areas I should capture?"
@@ -298,7 +295,6 @@ npm run seed        # Seed test data
 ### 4. Document Delivery
 
 1. **In Web UI (Gemini, ChatGPT, Claude)**:
-
    - Present the entire document in one response (or multiple if too long)
    - Tell user to copy and save as `docs/brownfield-architecture.md` or `docs/project-architecture.md`
    - Mention it can be sharded later in IDE if needed

package/bmad-core/tasks/index-docs.md

@@ -11,14 +11,12 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
 ### Required Steps
 
 1. First, locate and scan:
-
    - The `docs/` directory and all subdirectories
    - The existing `docs/index.md` file (create if absent)
    - All markdown (`.md`) and text (`.txt`) files in the documentation structure
    - Note the folder structure for hierarchical organization
 
 2. For the existing `docs/index.md`:
-
    - Parse current entries
    - Note existing file references and descriptions
    - Identify any broken links or missing files
@@ -26,7 +24,6 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
    - Preserve existing folder sections
 
 3. For each documentation file found:
-
    - Extract the title (from first heading or filename)
    - Generate a brief description by analyzing the content
    - Create a relative markdown link to the file
@@ -35,7 +32,6 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
    - If missing or outdated, prepare an update
 
 4. For any missing or non-existent files found in index:
-
    - Present a list of all entries that reference non-existent files
    - For each entry:
      - Show the full entry details (title, path, description)
@@ -156,7 +152,6 @@ For each file referenced in the index but not found in the filesystem:
 ### Special Cases
 
 1. **Sharded Documents**: If a folder contains an `index.md` file, treat it as a sharded document:
-
    - Use the folder's `index.md` title as the section title
    - List the folder's documents as subsections
    - Note in the description that this is a multi-part document

package/bmad-core/tasks/review-story.md

@@ -11,13 +11,11 @@ When a developer agent marks a story as "Ready for Review", perform a comprehens
 ## Review Process
 
 1. **Read the Complete Story**
-
    - Review all acceptance criteria
    - Understand the dev notes and requirements
    - Note any completion notes from the developer
 
 2. **Verify Implementation Against Dev Notes Guidance**
-
    - Review the "Dev Notes" section for specific technical guidance provided to the developer
    - Verify the developer's implementation follows the architectural patterns specified in Dev Notes
    - Check that file locations match the project structure guidance in Dev Notes
@@ -25,13 +23,11 @@ When a developer agent marks a story as "Ready for Review", perform a comprehens
    - Validate that security considerations mentioned in Dev Notes were implemented
 
 3. **Focus on the File List**
-
    - Verify all files listed were actually created/modified
    - Check for any missing files that should have been updated
    - Ensure file locations align with the project structure guidance from Dev Notes
 
 4. **Senior Developer Code Review**
-
    - Review code with the eye of a senior developer
    - If changes form a cohesive whole, review them together
    - If changes are independent, review incrementally file by file
@@ -44,7 +40,6 @@ When a developer agent marks a story as "Ready for Review", perform a comprehens
      - Best practices and patterns
 
 5. **Active Refactoring**
-
    - As a senior developer, you CAN and SHOULD refactor code where improvements are needed
    - When refactoring:
      - Make the changes directly in the files
@@ -54,20 +49,17 @@ When a developer agent marks a story as "Ready for Review", perform a comprehens
      - Update the File List if you modify additional files
 
 6. **Standards Compliance Check**
-
    - Verify adherence to `docs/coding-standards.md`
    - Check compliance with `docs/unified-project-structure.md`
    - Validate testing approach against `docs/testing-strategy.md`
    - Ensure all guidelines mentioned in the story are followed
 
 7. **Acceptance Criteria Validation**
-
    - Verify each AC is fully implemented
    - Check for any missing functionality
    - Validate edge cases are handled
 
 8. **Test Coverage Review**
-
    - Ensure unit tests cover edge cases
    - Add missing tests if critical coverage is lacking
    - Verify integration tests (if required) are comprehensive

package/bmad-core/tasks/shard-doc.md

@@ -91,13 +91,11 @@ CRITICAL: Use proper parsing that understands markdown context. A ## inside a co
 For each extracted section:
 
 1. **Generate filename**: Convert the section heading to lowercase-dash-case
-
    - Remove special characters
    - Replace spaces with dashes
    - Example: "## Tech Stack" → `tech-stack.md`
 
 2. **Adjust heading levels**:
-
    - The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
    - All subsection levels decrease by 1:
 

package/bmad-core/working-in-the-brownfield.md

@@ -5,7 +5,7 @@
 > Gemini Web's 1M+ token context window or Gemini CLI (when it's working) can analyze your ENTIRE codebase, or critical sections of it, all at once (obviously within reason):
 >
 > - Upload via GitHub URL or use gemini cli in the project folder
-> - If working in the web: use the flattener-tool to flatten your project into a single file, then upload that file to your web agent.
+> - If working in the web: use `npx bmad-method flatten` to flatten your project into a single file, then upload that file to your web agent.
 
 ## What is Brownfield Development?
 
@@ -27,7 +27,7 @@ If you have just completed an MVP with BMad, and you want to continue with post-
 ## The Complete Brownfield Workflow
 
 1. **Follow the [<ins>User Guide - Installation</ins>](user-guide.md#installation) steps to setup your agent in the web.**
-2. **Generate a 'flattened' single file of your entire codebase** run: `npm run flatten`
+2. **Generate a 'flattened' single file of your entire codebase** run: `npx bmad-method flatten`
 
 ### Choose Your Approach
 

package/common/tasks/execute-checklist.md

@@ -9,7 +9,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 ## Instructions
 
 1. **Initial Assessment**
-
    - If user or the task being run provides a checklist name:
      - Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
      - If multiple matches found, ask user to clarify
@@ -22,14 +21,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
      - All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
 
 2. **Document and Artifact Gathering**
-
    - Each checklist will specify its required documents/artifacts at the beginning
    - Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
 
 3. **Checklist Processing**
 
    If in interactive mode:
-
    - Work through each section of the checklist one at a time
    - For each section:
      - Review all items in the section following instructions for that section embedded in the checklist
@@ -38,7 +35,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
      - Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
 
    If in YOLO mode:
-
    - Process all sections at once
    - Create a comprehensive report of all findings
    - Present the complete analysis to the user
@@ -46,7 +42,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 4. **Validation Approach**
 
    For each checklist item:
-
    - Read and understand the requirement
    - Look for evidence in the documentation that satisfies the requirement
    - Consider both explicit mentions and implicit coverage
@@ -60,7 +55,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 5. **Section Analysis**
 
    For each section:
-
    - think step by step to calculate pass rate
    - Identify common themes in failed items
    - Provide specific recommendations for improvement
@@ -70,7 +64,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 6. **Final Report**
 
    Prepare a summary that includes:
-
    - Overall checklist completion status
    - Pass rates by section
    - List of failed items with context