ros/BMAD-METHOD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: can now select different web bundles from what ide agents are installed

Browse Source
This commit is contained in:
Brian Madison
2025-06-17 10:50:54 -05:00
parent e934769a5e
commit 0c41633b07
82 changed files with 75475 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

92
z1/.bmad-core/tasks/advanced-elicitation.md Normal file
View File

@@ -0,0 +1,92 @@
# Advanced Elicitation Task
## Purpose
- Provide optional reflective and brainstorming actions to enhance content quality
- Enable deeper exploration of ideas through structured elicitation techniques
- Support iterative refinement through multiple analytical perspectives
## Task Instructions
### 1. Section Context and Review
[[LLM: When invoked after outputting a section:
1. First, provide a brief 1-2 sentence summary of what the user should look for in the section just presented (e.g., "Please review the technology choices for completeness and alignment with your project needs. Pay special attention to version numbers and any missing categories.")
2. If the section contains Mermaid diagrams, explain each diagram briefly before offering elicitation options (e.g., "The component diagram shows the main system modules and their interactions. Notice how the API Gateway routes requests to different services.")
3. If the section contains multiple distinct items (like multiple components, multiple patterns, etc.), inform the user they can apply elicitation actions to:
- The entire section as a whole
- Individual items within the section (specify which item when selecting an action)
4. Then present the action list as specified below.]]
### 2. Ask for Review and Present Action List
[[LLM: Ask the user to review the drafted section. In the SAME message, inform them that they can suggest additions, removals, or modifications, OR they can select an action by number from the 'Advanced Reflective, Elicitation & Brainstorming Actions'. If there are multiple items in the section, mention they can specify which item(s) to apply the action to. Then, present ONLY the numbered list (0-9) of these actions. Conclude by stating that selecting 9 will proceed to the next section. Await user selection. If an elicitation action (0-8) is chosen, execute it and then re-offer this combined review/elicitation choice. If option 9 is chosen, or if the user provides direct feedback, proceed accordingly.]]
**Present the numbered list (0-9) with this exact format:**
```text
**Advanced Reflective, Elicitation & Brainstorming Actions**
Choose an action (0-9 - 9 to bypass - HELP for explanation of these options):
0. Expand or Contract for Audience
1. Explain Reasoning (CoT Step-by-Step)
2. Critique and Refine
3. Analyze Logical Flow and Dependencies
4. Assess Alignment with Overall Goals
5. Identify Potential Risks and Unforeseen Issues
6. Challenge from Critical Perspective (Self or Other Persona)
7. Explore Diverse Alternatives (ToT-Inspired)
8. Hindsight is 20/20: The 'If Only...' Reflection
9. Proceed / No Further Actions
```
### 2. Processing Guidelines
**Do NOT show:**
- The full protocol text with `[[LLM: ...]]` instructions
- Detailed explanations of each option unless executing or the user asks, when giving the definition you can modify to tie its relevance
- Any internal template markup
**After user selection from the list:**
- Execute the chosen action according to the protocol instructions below
- Ask if they want to select another action or proceed with option 9 once complete
- Continue until user selects option 9 or indicates completion
## Action Definitions
0. Expand or Contract for Audience
[[LLM: Ask the user whether they want to 'expand' on the content (add more detail, elaborate) or 'contract' it (simplify, clarify, make more concise). Also, ask if there's a specific target audience they have in mind. Once clarified, perform the expansion or contraction from your current role's perspective, tailored to the specified audience if provided.]]
1. Explain Reasoning (CoT Step-by-Step)
[[LLM: Explain the step-by-step thinking process, characteristic of your role, that you used to arrive at the current proposal for this content.]]
2. Critique and Refine
[[LLM: From your current role's perspective, review your last output or the current section for flaws, inconsistencies, or areas for improvement, and then suggest a refined version reflecting your expertise.]]
3. Analyze Logical Flow and Dependencies
[[LLM: From your role's standpoint, examine the content's structure for logical progression, internal consistency, and any relevant dependencies. Confirm if elements are presented in an effective order.]]
4. Assess Alignment with Overall Goals
[[LLM: Evaluate how well the current content contributes to the stated overall goals of the document, interpreting this from your specific role's perspective and identifying any misalignments you perceive.]]
5. Identify Potential Risks and Unforeseen Issues
[[LLM: Based on your role's expertise, brainstorm potential risks, overlooked edge cases, or unintended consequences related to the current content or proposal.]]
6. Challenge from Critical Perspective (Self or Other Persona)
[[LLM: Adopt a critical perspective on the current content. If the user specifies another role or persona (e.g., 'as a customer', 'as [Another Persona Name]'), critique the content or play devil's advocate from that specified viewpoint. If no other role is specified, play devil's advocate from your own current persona's viewpoint, arguing against the proposal or current content and highlighting weaknesses or counterarguments specific to your concerns. This can also randomly include YAGNI when appropriate, such as when trimming the scope of an MVP, the perspective might challenge the need for something to cut MVP scope.]]
7. Explore Diverse Alternatives (ToT-Inspired)
[[LLM: From your role's perspective, first broadly brainstorm a range of diverse approaches or solutions to the current topic. Then, from this wider exploration, select and present 2 distinct alternatives, detailing the pros, cons, and potential implications you foresee for each.]]
8. Hindsight is 20/20: The 'If Only...' Reflection
[[LLM: In your current persona, imagine it's a retrospective for a project based on the current content. What's the one 'if only we had known/done X...' that your role would humorously or dramatically highlight, along with the imagined consequences?]]
9. Proceed / No Further Actions
[[LLM: Acknowledge the user's choice to finalize the current work, accept the AI's last output as is, or move on to the next step without selecting another action from this list. Prepare to proceed accordingly.]]

238
z1/.bmad-core/tasks/brainstorming-techniques.md Normal file
View File

@@ -0,0 +1,238 @@
# Brainstorming Techniques Task
This task provides a comprehensive toolkit of creative brainstorming techniques for ideation and innovative thinking. The analyst can use these techniques to facilitate productive brainstorming sessions with users.
## Process
### 1. Session Setup
[[LLM: Begin by understanding the brainstorming context and goals. Ask clarifying questions if needed to determine the best approach.]]
1. **Establish Context**
- Understand the problem space or opportunity area
- Identify any constraints or parameters
- Determine session goals (divergent exploration vs. focused ideation)
2. **Select Technique Approach**
- Option A: User selects specific techniques
- Option B: Analyst recommends techniques based on context
- Option C: Random technique selection for creative variety
- Option D: Progressive technique flow (start broad, narrow down)
### 2. Core Brainstorming Techniques
#### Creative Expansion Techniques
1. **"What If" Scenarios**
[[LLM: Generate provocative what-if questions that challenge assumptions and expand thinking beyond current limitations.]]
- What if we had unlimited resources?
- What if this problem didn't exist?
- What if we approached this from a child's perspective?
- What if we had to solve this in 24 hours?
2. **Analogical Thinking**
[[LLM: Help user draw parallels between their challenge and other domains, industries, or natural systems.]]
- "How might this work like [X] but for [Y]?"
- Nature-inspired solutions (biomimicry)
- Cross-industry pattern matching
- Historical precedent analysis
3. **Reversal/Inversion**
[[LLM: Flip the problem or approach it from the opposite angle to reveal new insights.]]
- What if we did the exact opposite?
- How could we make this problem worse? (then reverse)
- Start from the end goal and work backward
- Reverse roles or perspectives
4. **First Principles Thinking**
[[LLM: Break down to fundamental truths and rebuild from scratch.]]
- What are the absolute fundamentals here?
- What assumptions can we challenge?
- If we started from zero, what would we build?
- What laws of physics/economics/human nature apply?
#### Structured Ideation Frameworks
1. **SCAMPER Method**
[[LLM: Guide through each SCAMPER prompt systematically.]]
- **S** = Substitute: What can be substituted?
- **C** = Combine: What can be combined or integrated?
- **A** = Adapt: What can be adapted from elsewhere?
- **M** = Modify/Magnify: What can be emphasized or reduced?
- **P** = Put to other uses: What else could this be used for?
- **E** = Eliminate: What can be removed or simplified?
- **R**= Reverse/Rearrange: What can be reversed or reordered?
2. **Six Thinking Hats**
[[LLM: Cycle through different thinking modes, spending focused time in each.]]
- White Hat: Facts and information
- Red Hat: Emotions and intuition
- Black Hat: Caution and critical thinking
- Yellow Hat: Optimism and benefits
- Green Hat: Creativity and alternatives
- Blue Hat: Process and control
3. **Mind Mapping**
[[LLM: Create text-based mind maps with clear hierarchical structure.]]
```plaintext
Central Concept
├── Branch 1
│ ├── Sub-idea 1.1
│ └── Sub-idea 1.2
├── Branch 2
│ ├── Sub-idea 2.1
│ └── Sub-idea 2.2
└── Branch 3
└── Sub-idea 3.1
```
#### Collaborative Techniques
1. **"Yes, And..." Building**
[[LLM: Accept every idea and build upon it without judgment. Encourage wild ideas and defer criticism.]]
- Accept the premise of each idea
- Add to it with "Yes, and..."
- Build chains of connected ideas
- Explore tangents freely
2. **Brainwriting/Round Robin**
[[LLM: Simulate multiple perspectives by generating ideas from different viewpoints.]]
- Generate ideas from stakeholder perspectives
- Build on previous ideas in rounds
- Combine unrelated ideas
- Cross-pollinate concepts
3. **Random Stimulation**
[[LLM: Use random words, images, or concepts as creative triggers.]]
- Random word association
- Picture/metaphor inspiration
- Forced connections between unrelated items
- Constraint-based creativity
#### Deep Exploration Techniques
1. **Five Whys**
[[LLM: Dig deeper into root causes and underlying motivations.]]
- Why does this problem exist? → Answer → Why? (repeat 5 times)
- Uncover hidden assumptions
- Find root causes, not symptoms
- Identify intervention points
2. **Morphological Analysis**
[[LLM: Break down into parameters and systematically explore combinations.]]
- List key parameters/dimensions
- Identify possible values for each
- Create combination matrix
- Explore unusual combinations
3. **Provocation Technique (PO)**
[[LLM: Make deliberately provocative statements to jar thinking.]]
- PO: Cars have square wheels
- PO: Customers pay us to take products
- PO: The problem solves itself
- Extract useful ideas from provocations
### 3. Technique Selection Guide
[[LLM: Help user select appropriate techniques based on their needs.]]
**For Initial Exploration:**
- What If Scenarios
- First Principles
- Mind Mapping
**For Stuck/Blocked Thinking:**
- Random Stimulation
- Reversal/Inversion
- Provocation Technique
**For Systematic Coverage:**
- SCAMPER
- Morphological Analysis
- Six Thinking Hats
**For Deep Understanding:**
- Five Whys
- Analogical Thinking
- First Principles
**For Team/Collaborative Settings:**
- Brainwriting
- "Yes, And..."
- Six Thinking Hats
### 4. Session Flow Management
[[LLM: Guide the brainstorming session with appropriate pacing and technique transitions.]]
1. **Warm-up Phase** (5-10 min)
- Start with accessible techniques
- Build creative confidence
- Establish "no judgment" atmosphere
2. **Divergent Phase** (20-30 min)
- Use expansion techniques
- Generate quantity over quality
- Encourage wild ideas
3. **Convergent Phase** (15-20 min)
- Group and categorize ideas
- Identify patterns and themes
- Select promising directions
4. **Synthesis Phase** (10-15 min)
- Combine complementary ideas
- Refine and develop concepts
- Prepare summary of insights
### 5. Output Format
[[LLM: Present brainstorming results in an organized, actionable format.]]
**Session Summary:**
- Techniques used
- Number of ideas generated
- Key themes identified
**Idea Categories:**
1. **Immediate Opportunities** - Ideas that could be implemented now
2. **Future Innovations** - Ideas requiring more development
3. **Moonshots** - Ambitious, transformative ideas
4. **Insights & Learnings** - Key realizations from the session
**Next Steps:**
- Which ideas to explore further
- Recommended follow-up techniques
- Suggested research areas
## Important Notes
- Maintain energy and momentum throughout the session
- Defer judgment - all ideas are valid during generation
- Quantity leads to quality - aim for many ideas
- Build on ideas collaboratively
- Document everything - even "silly" ideas can spark breakthroughs
- Take breaks if energy flags
- End with clear next actions

160
z1/.bmad-core/tasks/brownfield-create-epic.md Normal file
View File

@@ -0,0 +1,160 @@
# Create Brownfield Epic Task
## Purpose
Create a single epic for smaller brownfield enhancements that don't require the full PRD and Architecture documentation process. This task is for isolated features or modifications that can be completed within a focused scope.
## When to Use This Task
**Use this task when:**
- The enhancement can be completed in 1-3 stories
- No significant architectural changes are required
- The enhancement follows existing project patterns
- Integration complexity is minimal
- Risk to existing system is low
**Use the full brownfield PRD/Architecture process when:**
- The enhancement requires multiple coordinated stories
- Architectural planning is needed
- Significant integration work is required
- Risk assessment and mitigation planning is necessary
## Instructions
### 1. Project Analysis (Required)
Before creating the epic, gather essential information about the existing project:
**Existing Project Context:**
- [ ] Project purpose and current functionality understood
- [ ] Existing technology stack identified
- [ ] Current architecture patterns noted
- [ ] Integration points with existing system identified
**Enhancement Scope:**
- [ ] Enhancement clearly defined and scoped
- [ ] Impact on existing functionality assessed
- [ ] Required integration points identified
- [ ] Success criteria established
### 2. Epic Creation
Create a focused epic following this structure:
#### Epic Title
{{Enhancement Name}} - Brownfield Enhancement
#### Epic Goal
{{1-2 sentences describing what the epic will accomplish and why it adds value}}
#### Epic Description
**Existing System Context:**
- Current relevant functionality: {{brief description}}
- Technology stack: {{relevant existing technologies}}
- Integration points: {{where new work connects to existing system}}
**Enhancement Details:**
- What's being added/changed: {{clear description}}
- How it integrates: {{integration approach}}
- Success criteria: {{measurable outcomes}}
#### Stories
List 1-3 focused stories that complete the epic:
1. **Story 1:** {{Story title and brief description}}
2. **Story 2:** {{Story title and brief description}}
3. **Story 3:** {{Story title and brief description}}
#### Compatibility Requirements
- [ ] Existing APIs remain unchanged
- [ ] Database schema changes are backward compatible
- [ ] UI changes follow existing patterns
- [ ] Performance impact is minimal
#### Risk Mitigation
- **Primary Risk:** {{main risk to existing system}}
- **Mitigation:** {{how risk will be addressed}}
- **Rollback Plan:** {{how to undo changes if needed}}
#### Definition of Done
- [ ] All stories completed with acceptance criteria met
- [ ] Existing functionality verified through testing
- [ ] Integration points working correctly
- [ ] Documentation updated appropriately
- [ ] No regression in existing features
### 3. Validation Checklist
Before finalizing the epic, ensure:
**Scope Validation:**
- [ ] Epic can be completed in 1-3 stories maximum
- [ ] No architectural documentation is required
- [ ] Enhancement follows existing patterns
- [ ] Integration complexity is manageable
**Risk Assessment:**
- [ ] Risk to existing system is low
- [ ] Rollback plan is feasible
- [ ] Testing approach covers existing functionality
- [ ] Team has sufficient knowledge of integration points
**Completeness Check:**
- [ ] Epic goal is clear and achievable
- [ ] Stories are properly scoped
- [ ] Success criteria are measurable
- [ ] Dependencies are identified
### 4. Handoff to Story Manager
Once the epic is validated, provide this handoff to the Story Manager:
---
**Story Manager Handoff:**
"Please develop detailed user stories for this brownfield epic. Key considerations:
- This is an enhancement to an existing system running {{technology stack}}
- Integration points: {{list key integration points}}
- Existing patterns to follow: {{relevant existing patterns}}
- Critical compatibility requirements: {{key requirements}}
- Each story must include verification that existing functionality remains intact
The epic should maintain system integrity while delivering {{epic goal}}."
---
## Success Criteria
The epic creation is successful when:
1. Enhancement scope is clearly defined and appropriately sized
2. Integration approach respects existing system architecture
3. Risk to existing functionality is minimized
4. Stories are logically sequenced for safe implementation
5. Compatibility requirements are clearly specified
6. Rollback plan is feasible and documented
## Important Notes
- This task is specifically for SMALL brownfield enhancements
- If the scope grows beyond 3 stories, consider the full brownfield PRD process
- Always prioritize existing system integrity over new functionality
- When in doubt about scope or complexity, escalate to full brownfield planning

147
z1/.bmad-core/tasks/brownfield-create-story.md Normal file
View File

@@ -0,0 +1,147 @@
# Create Brownfield Story Task
## Purpose
Create a single user story for very small brownfield enhancements that can be completed in one focused development session. This task is for minimal additions or bug fixes that require existing system integration awareness.
## When to Use This Task
**Use this task when:**
- The enhancement can be completed in a single story
- No new architecture or significant design is required
- The change follows existing patterns exactly
- Integration is straightforward with minimal risk
- Change is isolated with clear boundaries
**Use brownfield-create-epic when:**
- The enhancement requires 2-3 coordinated stories
- Some design work is needed
- Multiple integration points are involved
**Use the full brownfield PRD/Architecture process when:**
- The enhancement requires multiple coordinated stories
- Architectural planning is needed
- Significant integration work is required
## Instructions
### 1. Quick Project Assessment
Gather minimal but essential context about the existing project:
**Current System Context:**
- [ ] Relevant existing functionality identified
- [ ] Technology stack for this area noted
- [ ] Integration point(s) clearly understood
- [ ] Existing patterns for similar work identified
**Change Scope:**
- [ ] Specific change clearly defined
- [ ] Impact boundaries identified
- [ ] Success criteria established
### 2. Story Creation
Create a single focused story following this structure:
#### Story Title
{{Specific Enhancement}} - Brownfield Addition
#### User Story
As a {{user type}},
I want {{specific action/capability}},
So that {{clear benefit/value}}.
#### Story Context
**Existing System Integration:**
- Integrates with: {{existing component/system}}
- Technology: {{relevant tech stack}}
- Follows pattern: {{existing pattern to follow}}
- Touch points: {{specific integration points}}
#### Acceptance Criteria
**Functional Requirements:**
1. {{Primary functional requirement}}
2. {{Secondary functional requirement (if any)}}
3. {{Integration requirement}}
**Integration Requirements:** 4. Existing {{relevant functionality}} continues to work unchanged 5. New functionality follows existing {{pattern}} pattern 6. Integration with {{system/component}} maintains current behavior
**Quality Requirements:** 7. Change is covered by appropriate tests 8. Documentation is updated if needed 9. No regression in existing functionality verified
#### Technical Notes
- **Integration Approach:** {{how it connects to existing system}}
- **Existing Pattern Reference:** {{link or description of pattern to follow}}
- **Key Constraints:** {{any important limitations or requirements}}
#### Definition of Done
- [ ] Functional requirements met
- [ ] Integration requirements verified
- [ ] Existing functionality regression tested
- [ ] Code follows existing patterns and standards
- [ ] Tests pass (existing and new)
- [ ] Documentation updated if applicable
### 3. Risk and Compatibility Check
**Minimal Risk Assessment:**
- **Primary Risk:** {{main risk to existing system}}
- **Mitigation:** {{simple mitigation approach}}
- **Rollback:** {{how to undo if needed}}
**Compatibility Verification:**
- [ ] No breaking changes to existing APIs
- [ ] Database changes (if any) are additive only
- [ ] UI changes follow existing design patterns
- [ ] Performance impact is negligible
### 4. Validation Checklist
Before finalizing the story, confirm:
**Scope Validation:**
- [ ] Story can be completed in one development session
- [ ] Integration approach is straightforward
- [ ] Follows existing patterns exactly
- [ ] No design or architecture work required
**Clarity Check:**
- [ ] Story requirements are unambiguous
- [ ] Integration points are clearly specified
- [ ] Success criteria are testable
- [ ] Rollback approach is simple
## Success Criteria
The story creation is successful when:
1. Enhancement is clearly defined and appropriately scoped for single session
2. Integration approach is straightforward and low-risk
3. Existing system patterns are identified and will be followed
4. Rollback plan is simple and feasible
5. Acceptance criteria include existing functionality verification
## Important Notes
- This task is for VERY SMALL brownfield changes only
- If complexity grows during analysis, escalate to brownfield-create-epic
- Always prioritize existing system integrity
- When in doubt about integration complexity, use brownfield-create-epic instead
- Stories should take no more than 4 hours of focused development work

74
z1/.bmad-core/tasks/core-dump.md Normal file
View File

@@ -0,0 +1,74 @@
# Core Dump Task
## Purpose
To create a concise memory recording file (`.ai/core-dump-n.md`) that captures the essential context of the current agent session, enabling seamless continuation of work in future agent sessions. This task ensures persistent context across agent conversations while maintaining minimal token usage for efficient context loading.
## Inputs for this Task
- Current session conversation history and accomplishments
- Files created, modified, or deleted during the session
- Key decisions made and procedures followed
- Current project state and next logical steps
- User requests and agent responses that shaped the session
## Task Execution Instructions
### 0. Check Existing Core Dump
Before proceeding, check if `.ai/core-dump.md` already exists:
- If file exists, ask user: "Core dump file exists. Should I: 1. Overwrite, 2. Update, 3. Append or 4. Create new?"
- **Overwrite**: Replace entire file with new content
- **Update**: Merge new session info with existing content, updating relevant sections
- **Append**: Add new session as a separate entry while preserving existing content
- **Create New**: Create a new file, appending the next possible -# to the file, such as core-dump-3.md if 1 and 2 already exist.
- If file doesn't exist, proceed with creation of `core-dump-1.md`
### 1. Analyze Session Context
- Review the entire conversation to identify key accomplishments
- Note any specific tasks, procedures, or workflows that were executed
- Identify important decisions made or problems solved
- Capture the user's working style and preferences observed during the session
### 2. Document What Was Accomplished
- **Primary Actions**: List the main tasks completed concisely
- **Story Progress**: For story work, use format "Tasks Complete: 1-6, 8. Next Task Pending: 7, 9"
- **Problem Solving**: Document any challenges encountered and how they were resolved
- **User Communications**: Summarize key user requests, preferences, and discussion points
### 3. Record File System Changes (Concise Format)
- **Files Created**: `filename.ext` (brief purpose/size)
- **Files Modified**: `filename.ext` (what changed)
- **Files Deleted**: `filename.ext` (why removed)
- Focus on essential details, avoid verbose descriptions
### 4. Capture Current Project State
- **Project Progress**: Where the project stands after this session
- **Current Issues**: Any blockers or problems that need resolution
- **Next Logical Steps**: What would be the natural next actions to take
### 5. Create/Update Core Dump File
Based on user's choice from step 0, handle the file accordingly:
### 6. Optimize for Minimal Context
- Keep descriptions concise but informative
- Use abbreviated formats where possible (file sizes, task numbers)
- Focus on actionable information rather than detailed explanations
- Avoid redundant information that can be found in project documentation
- Prioritize information that would be lost without this recording
- Ensure the file can be quickly scanned and understood
### 7. Validate Completeness
- Verify all significant session activities are captured
- Ensure a future agent could understand the current state
- Check that file changes are accurately recorded
- Confirm next steps are clear and actionable
- Verify user communication style and preferences are noted

73
z1/.bmad-core/tasks/correct-course.md Normal file
View File

@@ -0,0 +1,73 @@
# Correct Course Task
## Purpose
- Guide a structured response to a change trigger using the `change-checklist`.
- Analyze the impacts of the change on epics, project artifacts, and the MVP, guided by the checklist's structure.
- Explore potential solutions (e.g., adjust scope, rollback elements, rescope features) as prompted by the checklist.
- Draft specific, actionable proposed updates to any affected project artifacts (e.g., epics, user stories, PRD sections, architecture document sections) based on the analysis.
- Produce a consolidated "Sprint Change Proposal" document that contains the impact analysis and the clearly drafted proposed edits for user review and approval.
- Ensure a clear handoff path if the nature of the changes necessitates fundamental replanning by other core agents (like PM or Architect).
## Instructions
### 1. Initial Setup & Mode Selection
- **Acknowledge Task & Inputs:**
- Confirm with the user that the "Correct Course Task" (Change Navigation & Integration) is being initiated.
- Verify the change trigger and ensure you have the user's initial explanation of the issue and its perceived impact.
- Confirm access to all relevant project artifacts (e.g., PRD, Epics/Stories, Architecture Documents, UI/UX Specifications) and, critically, the `change-checklist` (e.g., `change-checklist`).
- **Establish Interaction Mode:**
- Ask the user their preferred interaction mode for this task:
- **"Incrementally (Default & Recommended):** Shall we work through the `change-checklist` section by section, discussing findings and collaboratively drafting proposed changes for each relevant part before moving to the next? This allows for detailed, step-by-step refinement."
- **"YOLO Mode (Batch Processing):** Or, would you prefer I conduct a more batched analysis based on the checklist and then present a consolidated set of findings and proposed changes for a broader review? This can be quicker for initial assessment but might require more extensive review of the combined proposals."
- Request the user to select their preferred mode.
- Once the user chooses, confirm the selected mode (e.g., "Okay, we will proceed in Incremental mode."). This chosen mode will govern how subsequent steps in this task are executed.
- **Explain Process:** Briefly inform the user: "We will now use the `change-checklist` to analyze the change and draft proposed updates. I will guide you through the checklist items based on our chosen interaction mode."
<rule>When asking multiple questions or presenting multiple points for user input at once, number them clearly (e.g., 1., 2a., 2b.) to make it easier for the user to provide specific responses.</rule>
### 2. Execute Checklist Analysis (Iteratively or Batched, per Interaction Mode)
- Systematically work through Sections 1-4 of the `change-checklist` (typically covering Change Context, Epic/Story Impact Analysis, Artifact Conflict Resolution, and Path Evaluation/Recommendation).
- For each checklist item or logical group of items (depending on interaction mode):
- Present the relevant prompt(s) or considerations from the checklist to the user.
- Request necessary information and actively analyze the relevant project artifacts (PRD, epics, architecture documents, story history, etc.) to assess the impact.
- Discuss your findings for each item with the user.
- Record the status of each checklist item (e.g., `[x] Addressed`, `[N/A]`, `[!] Further Action Needed`) and any pertinent notes or decisions.
- Collaboratively agree on the "Recommended Path Forward" as prompted by Section 4 of the checklist.
### 3. Draft Proposed Changes (Iteratively or Batched)
- Based on the completed checklist analysis (Sections 1-4) and the agreed "Recommended Path Forward" (excluding scenarios requiring fundamental replans that would necessitate immediate handoff to PM/Architect):
- Identify the specific project artifacts that require updates (e.g., specific epics, user stories, PRD sections, architecture document components, diagrams).
- **Draft the proposed changes directly and explicitly for each identified artifact.** Examples include:
- Revising user story text, acceptance criteria, or priority.
- Adding, removing, reordering, or splitting user stories within epics.
- Proposing modified architecture diagram snippets (e.g., providing an updated Mermaid diagram block or a clear textual description of the change to an existing diagram).
- Updating technology lists, configuration details, or specific sections within the PRD or architecture documents.
- Drafting new, small supporting artifacts if necessary (e.g., a brief addendum for a specific decision).
- If in "Incremental Mode," discuss and refine these proposed edits for each artifact or small group of related artifacts with the user as they are drafted.
- If in "YOLO Mode," compile all drafted edits for presentation in the next step.
### 4. Generate "Sprint Change Proposal" with Edits
- Synthesize the complete `change-checklist` analysis (covering findings from Sections 1-4) and all the agreed-upon proposed edits (from Instruction 3) into a single document titled "Sprint Change Proposal." This proposal should align with the structure suggested by Section 5 of the `change-checklist` (Proposal Components).
- The proposal must clearly present:
- **Analysis Summary:** A concise overview of the original issue, its analyzed impact (on epics, artifacts, MVP scope), and the rationale for the chosen path forward.
- **Specific Proposed Edits:** For each affected artifact, clearly show or describe the exact changes (e.g., "Change Story X.Y from: [old text] To: [new text]", "Add new Acceptance Criterion to Story A.B: [new AC]", "Update Section 3.2 of Architecture Document as follows: [new/modified text or diagram description]").
- Present the complete draft of the "Sprint Change Proposal" to the user for final review and feedback. Incorporate any final adjustments requested by the user.
### 5. Finalize & Determine Next Steps
- Obtain explicit user approval for the "Sprint Change Proposal," including all the specific edits documented within it.
- Provide the finalized "Sprint Change Proposal" document to the user.
- **Based on the nature of the approved changes:**
- **If the approved edits sufficiently address the change and can be implemented directly or organized by a PO/SM:** State that the "Correct Course Task" is complete regarding analysis and change proposal, and the user can now proceed with implementing or logging these changes (e.g., updating actual project documents, backlog items). Suggest handoff to a PO/SM agent for backlog organization if appropriate.
- **If the analysis and proposed path (as per checklist Section 4 and potentially Section 6) indicate that the change requires a more fundamental replan (e.g., significant scope change, major architectural rework):** Clearly state this conclusion. Advise the user that the next step involves engaging the primary PM or Architect agents, using the "Sprint Change Proposal" as critical input and context for that deeper replanning effort.
## Output Deliverables
- **Primary:** A "Sprint Change Proposal" document (in markdown format). This document will contain:
- A summary of the `change-checklist` analysis (issue, impact, rationale for the chosen path).
- Specific, clearly drafted proposed edits for all affected project artifacts.
- **Implicit:** An annotated `change-checklist` (or the record of its completion) reflecting the discussions, findings, and decisions made during the process.

301
z1/.bmad-core/tasks/create-deep-research-prompt.md Normal file
View File

@@ -0,0 +1,301 @@
# Create Deep Research Prompt Task
This task helps create comprehensive research prompts for various types of deep analysis. It can process inputs from brainstorming sessions, project briefs, market research, or specific research questions to generate targeted prompts for deeper investigation.
## Purpose
Generate well-structured research prompts that:
- Define clear research objectives and scope
- Specify appropriate research methodologies
- Outline expected deliverables and formats
- Guide systematic investigation of complex topics
- Ensure actionable insights are captured
## Research Type Selection
[[LLM: First, help the user select the most appropriate research focus based on their needs and any input documents they've provided.]]
### 1. Research Focus Options
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**
[[LLM: Allow user to define their own specific research focus.]]
- User-defined research objectives
- Specialized domain investigation
- Cross-functional research needs
### 2. Input Processing
[[LLM: Based on the selected research type and any provided inputs (project brief, brainstorming results, etc.), extract relevant context and constraints.]]
**If Project Brief provided:**
- Extract key product concepts and goals
- Identify target users and use cases
- Note technical constraints and preferences
- Highlight uncertainties and assumptions
**If Brainstorming Results provided:**
- Synthesize main ideas and themes
- Identify areas needing validation
- Extract hypotheses to test
- Note creative directions to explore
**If Market Research provided:**
- Build on identified opportunities
- Deepen specific market insights
- Validate initial findings
- Explore adjacent possibilities
**If Starting Fresh:**
- Gather essential context through questions
- Define the problem space
- Clarify research objectives
- Establish success criteria
## Process
### 3. Research Prompt Structure
[[LLM: Based on the selected research type and context, collaboratively develop a comprehensive research prompt with these components.]]
#### A. Research Objectives
[[LLM: Work with the user to articulate clear, specific objectives for the research.]]
- Primary research goal and purpose
- Key decisions the research will inform
- Success criteria for the research
- Constraints and boundaries
#### B. Research Questions
[[LLM: Develop specific, actionable research questions organized by theme.]]
**Core Questions:**
- Central questions that must be answered
- Priority ranking of questions
- Dependencies between questions
**Supporting Questions:**
- Additional context-building questions
- Nice-to-have insights
- Future-looking considerations
#### C. Research Methodology
[[LLM: Specify appropriate research methods based on the type and objectives.]]
**Data Collection Methods:**
- Secondary research sources
- Primary research approaches (if applicable)
- Data quality requirements
- Source credibility criteria
**Analysis Frameworks:**
- Specific frameworks to apply
- Comparison criteria
- Evaluation methodologies
- Synthesis approaches
#### D. Output Requirements
[[LLM: Define how research findings should be structured and presented.]]
**Format Specifications:**
- Executive summary requirements
- Detailed findings structure
- Visual/tabular presentations
- Supporting documentation
**Key Deliverables:**
- Must-have sections and insights
- Decision-support elements
- Action-oriented recommendations
- Risk and uncertainty documentation
### 4. Prompt Generation
[[LLM: Synthesize all elements into a comprehensive, ready-to-use research prompt.]]
**Research Prompt Template:**
```markdown
## Research Objective
[Clear statement of what this research aims to achieve]
## Background Context
[Relevant information from project brief, brainstorming, or other inputs]
## Research Questions
### Primary Questions (Must Answer)
1. [Specific, actionable question]
2. [Specific, actionable question]
...
### Secondary Questions (Nice to Have)
1. [Supporting question]
2. [Supporting question]
...
## Research Methodology
### Information Sources
- [Specific source types and priorities]
### Analysis Frameworks
- [Specific frameworks to apply]
### Data Requirements
- [Quality, recency, credibility needs]
## Expected Deliverables
### Executive Summary
- Key findings and insights
- Critical implications
- Recommended actions
### Detailed Analysis
[Specific sections needed based on research type]
### Supporting Materials
- Data tables
- Comparison matrices
- Source documentation
## Success Criteria
[How to evaluate if research achieved its objectives]
## Timeline and Priority
[If applicable, any time constraints or phasing]
```
### 5. Review and Refinement
[[LLM: Present the draft research prompt for user 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?
- Are output requirements sufficient?
3. **Refine as Needed**
- Incorporate user feedback
- Adjust scope or focus
- Add missing elements
- Clarify ambiguities
### 6. Next Steps Guidance
[[LLM: Provide clear guidance on how to use the research prompt.]]
**Execution Options:**
1. **Use with AI Research Assistant**: Provide this prompt to an AI model with research capabilities
2. **Guide Human Research**: Use as a framework for manual research efforts
3. **Hybrid Approach**: Combine AI and human research using this structure
**Integration Points:**
- How findings will feed into next phases
- Which team members should review results
- How to validate findings
- When to revisit or expand research
## Important Notes
- The quality of the research prompt directly impacts the quality of insights gathered
- Be specific rather than general in research questions
- Consider both current state and future implications
- Balance comprehensiveness with focus
- Document assumptions and limitations clearly
- Plan for iterative refinement based on initial findings

74
z1/.bmad-core/tasks/create-doc.md Normal file
View File

@@ -0,0 +1,74 @@
# Create Document from Template Task
## Purpose
- Generate documents from any specified template following embedded instructions from the perspective of the selected agent persona
## Instructions
### 1. Identify Template and Context
- Determine which template to use (user-provided or list available for selection to user)
- Agent-specific templates are listed in the agent's dependencies under `templates`. For each template listed, consider it a document the agent can create. So if an agent has:
@{example}
dependencies:
templates: - prd-tmpl - architecture-tmpl
@{/example}
You would offer to create "PRD" and "Architecture" documents when the user asks what you can help with.
- Gather all relevant inputs, or ask for them, or else rely on user providing necessary details to complete the document
- Understand the document purpose and target audience
### 2. Determine Interaction Mode
Confirm with the user their preferred interaction style:
- **Incremental:** Work through chunks of the document.
- **YOLO Mode:** Draft complete document making reasonable assumptions in one shot. (Can be entered also after starting incremental by just typing /yolo)
### 3. Execute Template
- Load specified template from `templates#*` or the /templates directory
- Follow ALL embedded LLM instructions within the template
- Process template markup according to `utils#template-format` conventions
### 4. Template Processing Rules
#### CRITICAL: Never display template markup, LLM instructions, or examples to users
- Replace all {{placeholders}} with actual content
- Execute all [[LLM: instructions]] internally
- Process `<<REPEAT>>` sections as needed
- Evaluate ^^CONDITION^^ blocks and include only if applicable
- Use @{examples} for guidance but never output them
### 5. Content Generation
- **Incremental Mode**: Present each major section for review before proceeding
- **YOLO Mode**: Generate all sections, then review complete document with user
- Apply any elicitation protocols specified in template
- Incorporate user feedback and iterate as needed
### 6. Validation
If template specifies a checklist:
- Run the appropriate checklist against completed document
- Document completion status for each item
- Address any deficiencies found
- Present validation summary to user
### 7. Final Presentation
- Present clean, formatted content only
- Ensure all sections are complete
- DO NOT truncate or summarize content
- Begin directly with document content (no preamble)
- Include any handoff prompts specified in template
## Important Notes
- Template markup is for AI processing only - never expose to users

206
z1/.bmad-core/tasks/create-next-story.md Normal file
View File

@@ -0,0 +1,206 @@
# Create Next Story Task
## Purpose
To identify the next logical story based on project progress and epic definitions, and then to prepare a comprehensive, self-contained, and actionable story file using the `Story Template`. This task ensures the story is enriched with all necessary technical context, requirements, and acceptance criteria, making it ready for efficient implementation by a Developer Agent with minimal need for additional research.
## Inputs for this Task
- Access to the project's documentation repository, specifically:
- `docs/index.md` (hereafter "Index Doc")
- All Epic files - located in one of these locations:
- Primary: `docs/prd/epic-{n}-{description}.md` (e.g., `epic-1-foundation-core-infrastructure.md`)
- Secondary: `docs/epics/epic-{n}-{description}.md`
- User-specified location if not found in above paths
- Existing story files in `docs/stories/`
- Main PRD (hereafter "PRD Doc")
- Main Architecture Document (hereafter "Main Arch Doc")
- Frontend Architecture Document (hereafter "Frontend Arch Doc," if relevant)
- Project Structure Guide (`docs/project-structure.md`)
- Operational Guidelines Document (`docs/operational-guidelines.md`)
- Technology Stack Document (`docs/tech-stack.md`)
- Data Models Document (as referenced in Index Doc)
- API Reference Document (as referenced in Index Doc)
- UI/UX Specifications, Style Guides, Component Guides (if relevant, as referenced in Index Doc)
- The `bmad-core/templates/story-tmpl.md` (hereafter "Story Template")
- The `bmad-core/checklists/story-draft-checklist.md` (hereafter "Story Draft Checklist")
- User confirmation to proceed with story identification and, if needed, to override warnings about incomplete prerequisite stories.
## Task Execution Instructions
### 1. Identify Next Story for Preparation
#### 1.1 Locate Epic Files
- First, determine where epic files are located:
- Check `docs/prd/` for files matching pattern `epic-{n}-*.md`
- If not found, check `docs/epics/` for files matching pattern `epic-{n}-*.md`
- If still not found, ask user: "Unable to locate epic files. Please specify the path where epic files are stored."
- Note: Epic files follow naming convention `epic-{n}-{description}.md` (e.g., `epic-1-foundation-core-infrastructure.md`)
#### 1.2 Review Existing Stories
- Review `docs/stories/` to find the highest-numbered story file.
- **If a highest story file exists (`{lastEpicNum}.{lastStoryNum}.story.md`):**
- Verify its `Status` is 'Done' (or equivalent).
- If not 'Done', present an alert to the user:
```plaintext
ALERT: Found incomplete story:
File: {lastEpicNum}.{lastStoryNum}.story.md
Status: [current status]
Would you like to:
1. View the incomplete story details (instructs user to do so, agent does not display)
2. Cancel new story creation at this time
3. Accept risk & Override to create the next story in draft
Please choose an option (1/2/3):
```
- Proceed only if user selects option 3 (Override) or if the last story was 'Done'.
- If proceeding: Look for the Epic File for `{lastEpicNum}` (e.g., `epic-{lastEpicNum}-*.md`) and check for a story numbered `{lastStoryNum + 1}`. If it exists and its prerequisites (per Epic File) are met, this is the next story.
- Else (story not found or prerequisites not met): The next story is the first story in the next Epic File (e.g., look for `epic-{lastEpicNum + 1}-*.md`, then `epic-{lastEpicNum + 2}-*.md`, etc.) whose prerequisites are met.
- **If no story files exist in `docs/stories/`:**
- The next story is the first story in the first epic file (look for `epic-1-*.md`, then `epic-2-*.md`, etc.) whose prerequisites are met.
- If no suitable story with met prerequisites is found, report to the user that story creation is blocked, specifying what prerequisites are pending. HALT task.
- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}".
### 2. Gather Core Story Requirements (from Epic File)
- For the identified story, open its parent Epic File (e.g., `epic-{epicNum}-*.md` from the location identified in step 1.1).
- Extract: Exact Title, full Goal/User Story statement, initial list of Requirements, all Acceptance Criteria (ACs), and any predefined high-level Tasks.
- Keep a record of this original epic-defined scope for later deviation analysis.
### 3. Review Previous Story and Extract Dev Notes
[[LLM: This step is CRITICAL for continuity and learning from implementation experience]]
- If this is not the first story (i.e., previous story exists):
- Read the previous story file: `docs/stories/{prevEpicNum}.{prevStoryNum}.story.md`
- Pay special attention to:
- Dev Agent Record sections (especially Completion Notes and Debug Log References)
- Any deviations from planned implementation
- Technical decisions made during implementation
- Challenges encountered and solutions applied
- Any "lessons learned" or notes for future stories
- Extract relevant insights that might inform the current story's preparation
### 4. Gather & Synthesize Architecture Context from Sharded Docs
[[LLM: CRITICAL - You MUST gather technical details from the sharded architecture documents. NEVER make up technical details not found in these documents.]]
#### 4.1 Start with Architecture Index
- Read `docs/architecture/index.md` to understand the full scope of available documentation
- Identify which sharded documents are most relevant to the current story
#### 4.2 Recommended Reading Order Based on Story Type
[[LLM: Read documents in this order, but ALWAYS verify relevance to the specific story. Skip irrelevant sections but NEVER skip documents that contain information needed for the story.]]
**For ALL Stories:**
1. `docs/architecture/tech-stack.md` - Understand technology constraints and versions
2. `docs/architecture/unified-project-structure.md` - Know where code should be placed
3. `docs/architecture/coding-standards.md` - Ensure dev follows project conventions
4. `docs/architecture/testing-strategy.md` - Include testing requirements in tasks
**For Backend/API Stories, additionally read:** 5. `docs/architecture/data-models.md` - Data structures and validation rules 6. `docs/architecture/database-schema.md` - Database design and relationships 7. `docs/architecture/backend-architecture.md` - Service patterns and structure 8. `docs/architecture/rest-api-spec.md` - API endpoint specifications 9. `docs/architecture/external-apis.md` - Third-party integrations (if relevant)
**For Frontend/UI Stories, additionally read:** 5. `docs/architecture/frontend-architecture.md` - Component structure and patterns 6. `docs/architecture/components.md` - Specific component designs 7. `docs/architecture/core-workflows.md` - User interaction flows 8. `docs/architecture/data-models.md` - Frontend data handling
**For Full-Stack Stories:**
- Read both Backend and Frontend sections above
#### 4.3 Extract Story-Specific Technical Details
[[LLM: As you read each document, extract ONLY the information directly relevant to implementing the current story. Do NOT include general information unless it directly impacts the story implementation.]]
For each relevant document, extract:
- Specific data models, schemas, or structures the story will use
- API endpoints the story must implement or consume
- Component specifications for UI elements in the story
- File paths and naming conventions for new code
- Testing requirements specific to the story's features
- Security or performance considerations affecting the story
#### 4.4 Document Source References
[[LLM: ALWAYS cite the source document and section for each technical detail you include. This helps the dev agent verify information if needed.]]
Format references as: `[Source: architecture/{filename}.md#{section}]`
### 5. Verify Project Structure Alignment
- Cross-reference the story's requirements and anticipated file manipulations with the Project Structure Guide from `docs/architecture/unified-project-structure.md`.
- Ensure any file paths, component locations, or module names implied by the story align with defined structures.
- Document any structural conflicts, necessary clarifications, or undefined components/paths in a "Project Structure Notes" section within the story draft.
### 6. Populate Story Template with Full Context
- Create a new story file: `docs/stories/{epicNum}.{storyNum}.story.md`.
- Use the Story Template to structure the file.
- Fill in:
- Story `{EpicNum}.{StoryNum}: {Short Title Copied from Epic File}`
- `Status: Draft`
- `Story` (User Story statement from Epic)
- `Acceptance Criteria (ACs)` (from Epic, to be refined if needed based on context)
- **`Dev Technical Guidance` section (CRITICAL):**
[[LLM: This section MUST contain ONLY information extracted from the architecture shards. NEVER invent or assume technical details.]]
- Include ALL relevant technical details gathered from Steps 3 and 4, organized by category:
- **Previous Story Insights**: Key learnings or considerations from the previous story
- **Data Models**: Specific schemas, validation rules, relationships [with source references]
- **API Specifications**: Endpoint details, request/response formats, auth requirements [with source references]
- **Component Specifications**: UI component details, props, state management [with source references]
- **File Locations**: Exact paths where new code should be created based on project structure
- **Testing Requirements**: Specific test cases or strategies from testing-strategy.md
- **Technical Constraints**: Version requirements, performance considerations, security rules
- Every technical detail MUST include its source reference: `[Source: architecture/{filename}.md#{section}]`
- If information for a category is not found in the architecture docs, explicitly state: "No specific guidance found in architecture docs"
- **`Tasks / Subtasks` section:**
- Generate a detailed, sequential list of technical tasks based ONLY on:
- Requirements from the Epic
- Technical constraints from architecture shards
- Project structure from unified-project-structure.md
- Testing requirements from testing-strategy.md
- Each task must reference relevant architecture documentation
- Include unit testing as explicit subtasks based on testing-strategy.md
- Link tasks to ACs where applicable (e.g., `Task 1 (AC: 1, 3)`)
- Add notes on project structure alignment or discrepancies found in Step 5.
- Prepare content for the "Deviation Analysis" based on any conflicts between epic requirements and architecture constraints.
### 7. Run Story Draft Checklist
- Execute the Story Draft Checklist against the prepared story
- Document any issues or gaps identified
- Make necessary adjustments to meet quality standards
- Ensure all technical guidance is properly sourced from architecture docs
### 8. Finalize Story File
- Review all sections for completeness and accuracy
- Verify all source references are included for technical details
- Ensure tasks align with both epic requirements and architecture constraints
- Update status to "Draft"
- Save the story file to `docs/stories/{epicNum}.{storyNum}.story.md`
### 9. Report Completion
Provide a summary to the user including:
- Story created: `{epicNum}.{storyNum} - {Story Title}`
- Status: Draft
- Key technical components included from architecture docs
- Any deviations or conflicts noted between epic and architecture
- Recommendations for story review before approval
- Next steps: Story should be reviewed by PO for approval before dev work begins
[[LLM: Remember - The success of this task depends on extracting real, specific technical details from the architecture shards. The dev agent should have everything they need in the story file without having to search through multiple documents.]]

143
z1/.bmad-core/tasks/doc-migration-task.md Normal file
View File

@@ -0,0 +1,143 @@
# Document Migration Task
## Purpose
Simple document migration that cleans up heading formats and adds epic structure for PRDs.
## Task Requirements
1. **Input**: User specifies the document to migrate (e.g., `docs/prd.md`)
2. **Detection**: Automatically determine if it's a PRD or other document type
3. **Migration**: Apply appropriate transformations
4. **Backup**: Create backup with `.bak` extension
## Migration Rules
### For PRDs
- Find all level 3 headings that appear to be epics
- Add a level 2 heading "## Epic #" (incrementing number) before each epic
- Also apply the heading cleanup rules below
### For All Documents
- Find all level 2 headings (`## ...`)
- Remove leading numbers and symbols
- Keep only alphabetic characters and spaces
- **CRITICAL**: Do not lose any information - preserve all content under appropriate headings
- Examples:
- `## 1. Foo & Bar` → `## Foo Bar`
- `## 2.1 Technical Overview` → `## Technical Overview`
- `## 3) User Experience` → `## User Experience`
### For Architecture Documents
- **PRIMARY GOAL**: Align level 2 headings to match template level 2 titles exactly
- **PRESERVE EVERYTHING**: Do not lose any information during migration
- Map existing content to the closest matching template section
- If content doesn't fit template sections, create appropriate level 3 subsections
## Detection Logic
A document is considered a PRD if:
- Filename contains "prd" (case insensitive)
- OR main title contains "Product Requirements" or "PRD"
- OR contains sections like "User Stories", "Functional Requirements", "Acceptance Criteria"
## Implementation Steps
1. **Backup Original**: Copy `filename.md` to `filename.md.bak`
2. **Detect Type**: Check if document is a PRD
3. **Process Headings**:
- Clean all level 2 headings
- If PRD: Add epic structure before level 3 headings that look like epics
4. **Write Result**: Overwrite original file with migrated content
## Epic Detection for PRDs
Level 3 headings are treated as epics if they:
- Describe features or functionality
- Are substantial sections (not just "Overview" or "Notes")
- Common epic patterns: "User Management", "Payment Processing", "Reporting Dashboard"
The epic numbering starts at 1 and increments for each epic found.
## Example
### Before (PRD):
`````markdown
# Product Requirements Document
## 1. Executive Summary
Content here...
## 2.1 Functional Requirements & Specs
Content here...
### User Management System
Epic content...
### Payment Processing
Epic content...
## 3) Success Metrics
Content here...
````text
### After (PRD):
```markdown
# Product Requirements Document
## Executive Summary
Content here...
## Functional Requirements Specs
Content here...
## Epic 1
### User Management System
Epic content...
## Epic 2
### Payment Processing
Epic content...
## Success Metrics
Content here...
```text
### Before (Non-PRD):
```markdown
# Architecture Document
## 1. System Overview
Content...
## 2.1 Technical Stack & Tools
Content...
```text
### After (Non-PRD):
```markdown
# Architecture Document
## System Overview
Content...
## Technical Stack Tools
Content...
````
`````
```text
```

389
z1/.bmad-core/tasks/document-project.md Normal file
View File

@@ -0,0 +1,389 @@
# Document an Existing Project
## Purpose
Generate comprehensive documentation for existing projects optimized for AI development agents. This task creates structured reference materials that enable AI agents to understand project context, conventions, and patterns for effective contribution to any codebase.
## Task Instructions
### 1. Initial Project Analysis
[[LLM: Begin by conducting a comprehensive analysis of the existing project. Use available tools to:
1. **Project Structure Discovery**: Examine the root directory structure, identify main folders, and understand the overall organization
2. **Technology Stack Identification**: Look for package.json, requirements.txt, Cargo.toml, pom.xml, etc. to identify languages, frameworks, and dependencies
3. **Build System Analysis**: Find build scripts, CI/CD configurations, and development commands
4. **Existing Documentation Review**: Check for README files, docs folders, and any existing documentation
5. **Code Pattern Analysis**: Sample key files to understand coding patterns, naming conventions, and architectural approaches
Ask the user these elicitation questions to better understand their needs:
- What is the primary purpose of this project?
- Are there any specific areas of the codebase that are particularly complex or important for agents to understand?
- What types of tasks do you expect AI agents to perform on this project? (e.g., bug fixes, feature additions, refactoring, testing)
- Are there any existing documentation standards or formats you prefer?
- What level of technical detail should the documentation target? (junior developers, senior developers, mixed team)
]]
### 2. Core Documentation Generation
[[LLM: Based on your analysis, generate the following core documentation files. Adapt the content and structure to match the specific project type and context you discovered:
**Core Documents (always generate):**
1. **docs/index.md** - Master documentation index
2. **docs/architecture/index.md** - Architecture documentation index
3. **docs/architecture/coding-standards.md** - Coding conventions and style guidelines
4. **docs/architecture/tech-stack.md** - Technology stack and version constraints
5. **docs/architecture/unified-project-structure.md** - Project structure and organization
6. **docs/architecture/testing-strategy.md** - Testing approaches and requirements
**Backend Documents (generate for backend/full-stack projects):**
7. **docs/architecture/backend-architecture.md** - Backend service patterns and structure
8. **docs/architecture/rest-api-spec.md** - API endpoint specifications
9. **docs/architecture/data-models.md** - Data structures and validation rules
10. **docs/architecture/database-schema.md** - Database design and relationships
11. **docs/architecture/external-apis.md** - Third-party integrations
**Frontend Documents (generate for frontend/full-stack projects):**
12. **docs/architecture/frontend-architecture.md** - Frontend patterns and structure
13. **docs/architecture/components.md** - UI component specifications
14. **docs/architecture/core-workflows.md** - User interaction flows
15. **docs/architecture/ui-ux-spec.md** - UI/UX specifications and guidelines
**Additional Documents (generate if applicable):**
16. **docs/prd.md** - Product requirements document (if not exists)
17. **docs/architecture/deployment-guide.md** - Deployment and operations info
18. **docs/architecture/security-considerations.md** - Security patterns and requirements
19. **docs/architecture/performance-guidelines.md** - Performance optimization patterns
**Optional Enhancement Documents:**
20. **docs/architecture/troubleshooting-guide.md** - Common issues and solutions
21. **docs/architecture/changelog-conventions.md** - Change management practices
22. **docs/architecture/code-review-checklist.md** - Review standards and practices
Present each document section by section, using the advanced elicitation task after each major section.]]
### 3. Document Structure Template
[[LLM: Use this standardized structure for each documentation file, adapting content as needed:
```markdown
# {{Document Title}}
## Overview
{{Brief description of what this document covers and why it's important for AI agents}}
## Quick Reference
{{Key points, commands, or patterns that agents need most frequently}}
## Detailed Information
{{Comprehensive information organized into logical sections}}
## Examples
{{Concrete examples showing proper usage or implementation}}
## Common Patterns
{{Recurring patterns agents should recognize and follow}}
## Things to Avoid
{{Anti-patterns, deprecated approaches, or common mistakes}}
## Related Resources
{{Links to other relevant documentation or external resources}}
```
Each document should be:
- **Concrete and actionable** - Focus on what agents need to do, not just concepts
- **Pattern-focused** - Highlight recurring patterns agents can recognize and replicate
- **Example-rich** - Include specific code examples and real file references
- **Context-aware** - Reference actual project files, folders, and conventions
- **Assumption-free** - Don't assume agents know project history or implicit knowledge
]]
### 4. Content Guidelines for Each Document Type
#### Core Architecture Documents
##### docs/architecture/index.md
[[LLM: Create a comprehensive index of all architecture documentation:
- List all architecture documents with brief descriptions
- Group documents by category (backend, frontend, shared)
- Include quick links to key sections
- Provide reading order recommendations for different use cases]]
##### docs/architecture/unified-project-structure.md
[[LLM: Document the complete project structure:
- Root-level directory structure with explanations
- Where each type of code belongs (backend, frontend, tests, etc.)
- File naming conventions and patterns
- Module/package organization
- Generated vs. source file locations
- Build output locations]]
##### docs/architecture/coding-standards.md
[[LLM: Capture project-wide coding conventions:
- Language-specific style guidelines
- Naming conventions (variables, functions, classes, files)
- Code organization within files
- Import/export patterns
- Comment and documentation standards
- Linting and formatting tool configurations
- Git commit message conventions]]
##### docs/architecture/tech-stack.md
[[LLM: Document all technologies and versions:
- Primary languages and versions
- Frameworks and major libraries with versions
- Development tools and their versions
- Database systems and versions
- External services and APIs used
- Browser/runtime requirements]]
##### docs/architecture/testing-strategy.md
[[LLM: Define testing approaches and requirements:
- Test file locations and naming conventions
- Unit testing patterns and frameworks
- Integration testing approaches
- E2E testing setup (if applicable)
- Test coverage requirements
- Mocking strategies
- Test data management]]
#### Backend Architecture Documents
##### docs/architecture/backend-architecture.md
[[LLM: Document backend service structure:
- Service layer organization
- Controller/route patterns
- Middleware architecture
- Authentication/authorization patterns
- Request/response flow
- Background job processing
- Service communication patterns]]
##### docs/architecture/rest-api-spec.md
[[LLM: Specify all API endpoints:
- Base URL and versioning strategy
- Authentication methods
- Common headers and parameters
- Each endpoint with:
- HTTP method and path
- Request parameters/body
- Response format and status codes
- Error responses
- Rate limiting and quotas]]
##### docs/architecture/data-models.md
[[LLM: Define data structures and validation:
- Core business entities
- Data validation rules
- Relationships between entities
- Computed fields and derivations
- Data transformation patterns
- Serialization formats]]
##### docs/architecture/database-schema.md
[[LLM: Document database design:
- Database type and version
- Table/collection structures
- Indexes and constraints
- Relationships and foreign keys
- Migration patterns
- Seed data requirements
- Backup and recovery procedures]]
##### docs/architecture/external-apis.md
[[LLM: Document third-party integrations:
- List of external services used
- Authentication methods for each
- API endpoints and usage patterns
- Rate limits and quotas
- Error handling strategies
- Webhook configurations
- Data synchronization patterns]]
#### Frontend Architecture Documents
##### docs/architecture/frontend-architecture.md
[[LLM: Document frontend application structure:
- Component hierarchy and organization
- State management patterns
- Routing architecture
- Data fetching patterns
- Authentication flow
- Error boundary strategies
- Performance optimization patterns]]
##### docs/architecture/components.md
[[LLM: Specify UI components:
- Component library/design system used
- Custom component specifications
- Props and state for each component
- Component composition patterns
- Styling approaches
- Accessibility requirements
- Component testing patterns]]
##### docs/architecture/core-workflows.md
[[LLM: Document user interaction flows:
- Major user journeys
- Screen flow diagrams
- Form handling patterns
- Navigation patterns
- Data flow through workflows
- Error states and recovery
- Loading and transition states]]
##### docs/architecture/ui-ux-spec.md
[[LLM: Define UI/UX guidelines:
- Design system specifications
- Color palette and typography
- Spacing and layout grids
- Responsive breakpoints
- Animation and transition guidelines
- Accessibility standards
- Browser compatibility requirements]]
### 5. Adaptive Content Strategy
[[LLM: Adapt your documentation approach based on project characteristics:
**For Web Applications:**
- Focus on component patterns, routing, state management
- Include build processes, asset handling, and deployment
- Cover API integration patterns and data fetching
**For Backend Services:**
- Emphasize service architecture, data models, and API design
- Include database interaction patterns and migration strategies
- Cover authentication, authorization, and security patterns
**For CLI Tools:**
- Focus on command structure, argument parsing, and output formatting
- Include plugin/extension patterns if applicable
- Cover configuration file handling and user interaction patterns
**For Libraries/Frameworks:**
- Emphasize public API design and usage patterns
- Include extension points and customization approaches
- Cover versioning, compatibility, and migration strategies
**For Mobile Applications:**
- Focus on platform-specific patterns and navigation
- Include state management and data persistence approaches
- Cover platform integration and native feature usage
**For Data Science/ML Projects:**
- Emphasize data pipeline patterns and model organization
- Include experiment tracking and reproducibility approaches
- Cover data validation and model deployment patterns
]]
### 6. Quality Assurance
[[LLM: Before completing each document:
1. **Accuracy Check**: Verify all file paths, commands, and code examples work
2. **Completeness Review**: Ensure the document covers the most important patterns an agent would encounter
3. **Clarity Assessment**: Check that explanations are clear and actionable
4. **Consistency Verification**: Ensure terminology and patterns align across all documents
5. **Agent Perspective**: Review from the viewpoint of an AI agent that needs to contribute to this project
Ask the user to review each completed document and use the advanced elicitation task to refine based on their feedback.]]
### 7. Final Integration
[[LLM: After all documents are completed:
1. Ensure all documents are created in the proper BMAD-expected locations:
- Core docs in `docs/` (index.md, prd.md)
- Architecture shards in `docs/architecture/` subdirectory
- Create the `docs/architecture/` directory if it doesn't exist
2. Create/update the master index documents:
- Update `docs/index.md` to reference all documentation
- Create `docs/architecture/index.md` listing all architecture shards
3. Verify document cross-references:
- Ensure all documents link to related documentation
- Check that file paths match the actual project structure
- Validate that examples reference real files in the project
4. Provide maintenance guidance:
- Document update triggers (when to update each doc)
- Create a simple checklist for keeping docs current
- Suggest automated validation approaches
5. Summary report including:
- List of all documents created with their paths
- Any gaps or areas needing human review
- Recommendations for project-specific additions
- Next steps for maintaining documentation accuracy
Present a summary of what was created and ask if any additional documentation would be helpful for AI agents working on this specific project.]]
## Success Criteria
- Documentation enables AI agents to understand project context without additional explanation
- All major architectural patterns and coding conventions are captured
- Examples reference actual project files and demonstrate real usage
- Documentation is structured consistently and easy to navigate
- Content is actionable and focuses on what agents need to do, not just understand
## Notes
- This task is designed to work with any project type, language, or framework
- The documentation should reflect the project as it actually is, not as it should be
- Focus on patterns that agents can recognize and replicate consistently
- Include both positive examples (what to do) and negative examples (what to avoid)

97
z1/.bmad-core/tasks/execute-checklist.md Normal file
View File

@@ -0,0 +1,97 @@
# Checklist Validation Task
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
## Context
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. Each checklist contains embedded prompts and instructions to guide the LLM through thorough validation and advanced elicitation. The checklists automatically identify their required artifacts and guide the validation process.
## Available Checklists
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the bmad-core/checklists folder to select the appropriate one to run.
## 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
- Load the appropriate checklist from bmad-core/checklists/
- If no checklist specified:
- Ask the user which checklist they want to use
- Present the available options from the files in the checklists folder
- Confirm if they want to work through the checklist:
- Section by section (interactive mode - very time consuming)
- 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
- Check each item against the relevant documentation or artifacts as appropriate
- Present summary of findings for that section, highlighting warnings, errors and non applicable items (rationale for non-applicability).
- 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
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
- Aside from this, follow all checklist llm instructions
- Mark items as:
- ✅ PASS: Requirement clearly met
- ❌ FAIL: Requirement not met or insufficient coverage
- ⚠️ PARTIAL: Some aspects covered but needs improvement
- N/A: Not applicable to this case
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
- In interactive mode, discuss findings with user
- Document any user decisions or explanations
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
- Specific recommendations for improvement
- Any sections or items marked as N/A with justification
## Checklist Execution Methodology
Each checklist now contains embedded LLM prompts and instructions that will:
1. **Guide thorough thinking** - Prompts ensure deep analysis of each section
2. **Request specific artifacts** - Clear instructions on what documents/access is needed
3. **Provide contextual guidance** - Section-specific prompts for better validation
4. **Generate comprehensive reports** - Final summary with detailed findings
The LLM will:
- Execute the complete checklist validation
- Present a final report with pass/fail rates and key findings
- Offer to provide detailed analysis of any section, especially those with warnings or failures

51
z1/.bmad-core/tasks/generate-ai-frontend-prompt.md Normal file
View File

@@ -0,0 +1,51 @@
# Create AI Frontend Prompt Task
## Purpose
To generate a masterful, comprehensive, and optimized prompt that can be used with any AI-driven frontend development tool (e.g., Vercel v0, Lovable.ai, or similar) to scaffold or generate significant portions of a frontend application.
## Inputs
- Completed UI/UX Specification (`front-end-spec`)
- Completed Frontend Architecture Document (`front-end-architecture`) or a full stack combined architecture such as `architecture.md`
- Main System Architecture Document (`architecture` - for API contracts and tech stack to give further context)
## Key Activities & Instructions
### 1. Core Prompting Principles
Before generating the prompt, you must understand these core principles for interacting with a generative AI for code.
- **Be Explicit and Detailed**: The AI cannot read your mind. Provide as much detail and context as possible. Vague requests lead to generic or incorrect outputs.
- **Iterate, Don't Expect Perfection**: Generating an entire complex application in one go is rare. The most effective method is to prompt for one component or one section at a time, then build upon the results.
- **Provide Context First**: Always start by providing the AI with the necessary context, such as the tech stack, existing code snippets, and overall project goals.
- **Mobile-First Approach**: Frame all UI generation requests with a mobile-first design mindset. Describe the mobile layout first, then provide separate instructions for how it should adapt for tablet and desktop.
### 2. The Structured Prompting Framework
To ensure the highest quality output, you MUST structure every prompt using the following four-part framework.
1. **High-Level Goal**: Start with a clear, concise summary of the overall objective. This orients the AI on the primary task.
- _Example: "Create a responsive user registration form with client-side validation and API integration."_
2. **Detailed, Step-by-Step Instructions**: Provide a granular, numbered list of actions the AI should take. Break down complex tasks into smaller, sequential steps. This is the most critical part of the prompt.
- _Example: "1. Create a new file named `RegistrationForm.js`. 2. Use React hooks for state management. 3. Add styled input fields for 'Name', 'Email', and 'Password'. 4. For the email field, ensure it is a valid email format. 5. On submission, call the API endpoint defined below."_
3. **Code Examples, Data Structures & Constraints**: Include any relevant snippets of existing code, data structures, or API contracts. This gives the AI concrete examples to work with. Crucially, you must also state what _not_ to do.
- _Example: "Use this API endpoint: `POST /api/register`. The expected JSON payload is `{ "name": "string", "email": "string", "password": "string" }`. Do NOT include a 'confirm password' field. Use Tailwind CSS for all styling."_
4. **Define a Strict Scope**: Explicitly define the boundaries of the task. Tell the AI which files it can modify and, more importantly, which files to leave untouched to prevent unintended changes across the codebase.
- _Example: "You should only create the `RegistrationForm.js` component and add it to the `pages/register.js` file. Do NOT alter the `Navbar.js` component or any other existing page or component."_
### 3. Assembling the Master Prompt
You will now synthesize the inputs and the above principles into a final, comprehensive prompt.
1. **Gather Foundational Context**:
- Start the prompt with a preamble describing the overall project purpose, the full tech stack (e.g., Next.js, TypeScript, Tailwind CSS), and the primary UI component library being used.
2. **Describe the Visuals**:
- If the user has design files (Figma, etc.), instruct them to provide links or screenshots.
- If not, describe the visual style: color palette, typography, spacing, and overall aesthetic (e.g., "minimalist", "corporate", "playful").
3. **Build the Prompt using the Structured Framework**:
- Follow the four-part framework from Section 2 to build out the core request, whether it's for a single component or a full page.
4. **Present and Refine**:
- Output the complete, generated prompt in a clear, copy-pasteable format (e.g., a large code block).
- Explain the structure of the prompt and why certain information was included, referencing the principles above.
- <important_note>Conclude by reminding the user that all AI-generated code will require careful human review, testing, and refinement to be considered production-ready.</important_note>

183
z1/.bmad-core/tasks/index-docs.md Normal file
View File

@@ -0,0 +1,183 @@
# Index Documentation Task
## Purpose
This task maintains the integrity and completeness of the `docs/index.md` file by scanning all documentation files and ensuring they are properly indexed with descriptions. It handles both root-level documents and documents within subfolders, organizing them hierarchically.
## Task Instructions
You are now operating as a Documentation Indexer. Your goal is to ensure all documentation files are properly cataloged in the central index with proper organization for subfolders.
### 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
- Keep track of already-indexed content
- 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
- Check if it's already in the index
- Note which folder it belongs to (if in a subfolder)
- 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)
- Ask for explicit confirmation before removal
- Provide option to update the path if file was moved
- Log the decision (remove/update/keep) for final report
5. Update `docs/index.md`:
- Maintain existing structure and organization
- Create level 2 sections (`##`) for each subfolder
- List root-level documents first
- Add missing entries with descriptions
- Update outdated entries
- Remove only entries that were confirmed for removal
- Ensure consistent formatting throughout
### Index Structure Format
The index should be organized as follows:
`````markdown
# Documentation Index
## Root Documents
### [Document Title](./document.md)
Brief description of the document's purpose and contents.
### [Another Document](./another.md)
Description here.
## Folder Name
Documents within the `folder-name/` directory:
### [Document in Folder](./folder-name/document.md)
Description of this document.
### [Another in Folder](./folder-name/another.md)
Description here.
## Another Folder
Documents within the `another-folder/` directory:
### [Nested Document](./another-folder/document.md)
Description of nested document.
````text
### Index Entry Format
Each entry should follow this format:
```markdown
### [Document Title](relative/path/to/file.md)
Brief description of the document's purpose and contents.
````
`````
````
### Rules of Operation
1. NEVER modify the content of indexed files
2. Preserve existing descriptions in index.md when they are adequate
3. Maintain any existing categorization or grouping in the index
4. Use relative paths for all links (starting with `./`)
5. Ensure descriptions are concise but informative
6. NEVER remove entries without explicit confirmation
7. Report any broken links or inconsistencies found
8. Allow path updates for moved files before considering removal
9. Create folder sections using level 2 headings (`##`)
10. Sort folders alphabetically, with root documents listed first
11. Within each section, sort documents alphabetically by title
### Process Output
The task will provide:
1. A summary of changes made to index.md
2. List of newly indexed files (organized by folder)
3. List of updated entries
4. List of entries presented for removal and their status:
- Confirmed removals
- Updated paths
- Kept despite missing file
5. Any new folders discovered
6. Any other issues or inconsistencies found
### Handling Missing Files
For each file referenced in the index but not found in the filesystem:
1. Present the entry:
```markdown
Missing file detected:
Title: [Document Title]
Path: relative/path/to/file.md
Description: Existing description
Section: [Root Documents | Folder Name]
Options:
1. Remove this entry
2. Update the file path
3. Keep entry (mark as temporarily unavailable)
Please choose an option (1/2/3):
```
2. Wait for user confirmation before taking any action
3. Log the decision for the final report
### 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
2. **README files**: Convert `README.md` to more descriptive titles based on content
3. **Nested Subfolders**: For deeply nested folders, maintain the hierarchy but limit to 2 levels in the main index. Deeper structures should have their own index files.
## Required Input
Please provide:
1. Location of the `docs/` directory (default: `./docs`)
2. Confirmation of write access to `docs/index.md`
3. Any specific categorization preferences
4. Any files or directories to exclude from indexing (e.g., `.git`, `node_modules`)
5. Whether to include hidden files/folders (starting with `.`)
Would you like to proceed with documentation indexing? Please provide the required input above.
````

173
z1/.bmad-core/tasks/shard-doc.md Normal file
View File

@@ -0,0 +1,173 @@
# Document Sharding Task
## Purpose
- Split a large document into multiple smaller documents based on level 2 sections
- Create a folder structure to organize the sharded documents
- Maintain all content integrity including code blocks, diagrams, and markdown formatting
## Recommended Method: @kayvan/markdown-tree-parser
[[LLM: First, suggest the user install and use the @kayvan/markdown-tree-parser tool if the md-tree command is unavailable so we can have the best performance and reliable document sharding. Let the user know this will save cost of having the LLM to the expensive sharding operation. Give instructions for MPV NPX and PNPM global installs.]]
### Installation and Usage
1. **Install globally**:
```bash
npm install -g @kayvan/markdown-tree-parser
```
2. **Use the explode command**:
```bash
# For PRD
md-tree explode docs/prd.md docs/prd
# For Architecture
md-tree explode docs/architecture.md docs/architecture
# For any document
md-tree explode [source-document] [destination-folder]
```
3. **What it does**:
- Automatically splits the document by level 2 sections
- Creates properly named files
- Adjusts heading levels appropriately
- Handles all edge cases with code blocks and special markdown
If the user has @kayvan/markdown-tree-parser installed, use it and skip the manual process below.
---
## Manual Method (if @kayvan/markdown-tree-parser is not available)
[[LLM: Only proceed with the manual instructions below if the user cannot or does not want to use @kayvan/markdown-tree-parser.]]
### Task Instructions
### 1. Identify Document and Target Location
- Determine which document to shard (user-provided path)
- Create a new folder under `docs/` with the same name as the document (without extension)
- Example: `docs/prd.md` → create folder `docs/prd/`
### 2. Parse and Extract Sections
[[LLM: When sharding the document:
1. Read the entire document content
2. Identify all level 2 sections (## headings)
3. For each level 2 section:
- Extract the section heading and ALL content until the next level 2 section
- Include all subsections, code blocks, diagrams, lists, tables, etc.
- Be extremely careful with:
- Fenced code blocks (```) - ensure you capture the full block including closing backticks
- Mermaid diagrams - preserve the complete diagram syntax
- Nested markdown elements
- Multi-line content that might contain ## inside code blocks
CRITICAL: Use proper parsing that understands markdown context. A ## inside a code block is NOT a section header.]]
### 3. Create Individual Files
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 ##)
- All subsection levels decrease by 1:
```txt
- ### → ##
- #### → ###
- ##### → ####
- etc.
```
3. **Write content**: Save the adjusted content to the new file
### 4. Create Index File
Create an `index.md` file in the sharded folder that:
1. Contains the original level 1 heading and any content before the first level 2 section
2. Lists all the sharded files with links:
```markdown
# Original Document Title
[Original introduction content if any]
## Sections
- [Section Name 1](./section-name-1.md)
- [Section Name 2](./section-name-2.md)
- [Section Name 3](./section-name-3.md)
...
```text
### 5. Preserve Special Content
[[LLM: Pay special attention to preserving:
1. **Code blocks**: Must capture complete blocks including:
```language
content
```
2. **Mermaid diagrams**: Preserve complete syntax:
```mermaid
graph TD
...
```
3. **Tables**: Maintain proper markdown table formatting
4. **Lists**: Preserve indentation and nesting
5. **Inline code**: Preserve backticks
6. **Links and references**: Keep all markdown links intact
7. **Template markup**: If documents contain {{placeholders}} or [[LLM instructions]], preserve exactly]]
### 6. Validation
After sharding:
1. Verify all sections were extracted
2. Check that no content was lost
3. Ensure heading levels were properly adjusted
4. Confirm all files were created successfully
### 7. Report Results
Provide a summary:
```text
Document sharded successfully:
- Source: [original document path]
- Destination: docs/[folder-name]/
- Files created: [count]
- Sections:
- section-name-1.md: "Section Title 1"
- section-name-2.md: "Section Title 2"
...
```
## Important Notes
- Never modify the actual content, only adjust heading levels
- Preserve ALL formatting, including whitespace where significant
- Handle edge cases like sections with code blocks containing ## symbols
- Ensure the sharding is reversible (could reconstruct the original from shards)