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

tasks and slim ide agents

Browse Source
This commit is contained in:
Brian Madison
2025-05-12 07:39:57 -05:00
parent cea1919ba5
commit 46b6c1351a
8 changed files with 708 additions and 242 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
BETA-V3/tasks/checklist-mappings.yml Normal file
View File

@@ -0,0 +1,46 @@
architect-checklist:
checklist_file: docs/checklists/architect-checklist.txt
required_docs:
- architecture.md
default_locations:
- docs/architecture.md
frontend-architecture-checklist:
checklist_file: docs/checklists/frontend-architecture-checklist.txt
required_docs:
- frontend-architecture.md
default_locations:
- docs/frontend-architecture.md
- docs/fe-architecture.md
pm-checklist:
checklist_file: docs/checklists/pm-checklist.txt
required_docs:
- prd.md
default_locations:
- docs/prd.md
po-master-checklist:
checklist_file: docs/checklists/po-master-checklist.txt
required_docs:
- prd.md
- frontend-architecture.md
- architecture.md
default_locations:
- docs/prd.md
- docs/frontend-architecture.md
- docs/architecture.md
story-draft-checklist:
checklist_file: docs/checklists/story-draft-checklist.txt
required_docs:
- story.md
default_locations:
- docs/stories/*.md
story-dod-checklist:
checklist_file: docs/checklists/story-dod-checklist.txt
required_docs:
- story.md
default_locations:
- docs/stories/*.md

135
BETA-V3/tasks/checklist-run-task.md Normal file
View File

@@ -0,0 +1,135 @@
# Checklist Validation Task
This task provides instructions for validating documentation against checklists. The agent should 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. The mapping between checklists and their required documents is defined in `checklist-mappings.yml`. This allows for easy addition of new checklists without modifying this task.
## Instructions
1. **Initial Assessment**
- Check `checklist-mappings.yml` for available checklists
- If user provides a checklist name:
- Look for exact match in checklist-mappings.yml
- If no exact match, try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
- Once matched, use the checklist_file path from the mapping
- If no checklist specified:
- Ask the user which checklist they want to use
- Present available options from checklist-mappings.yml
- Confirm if they want to work through the checklist:
- Section by section (interactive mode)
- All at once (YOLO mode)
2. **Document Location**
- Look up the required documents and default locations in `checklist-mappings.yml`
- For each required document:
- Check all default locations specified in the mapping
- If not found, ask the user for the document location
- Verify all required documents are accessible
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
- Check each item against the relevant documentation
- Present findings for that section
- Get user confirmation before proceeding to next section
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
- 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:
- 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
## Special Considerations
1. **Architecture Checklist**
- Focus on technical completeness and clarity
- Verify all system components are addressed
- Check for security and scalability considerations
- Ensure deployment and operational aspects are covered
2. **Frontend Architecture Checklist**
- Validate UI/UX specifications
- Check component structure and organization
- Verify state management approach
- Ensure responsive design considerations
3. **PM Checklist**
- Focus on product requirements clarity
- Verify user stories and acceptance criteria
- Check market and user research coverage
- Ensure technical feasibility is addressed
4. **Story Checklists**
- Verify clear acceptance criteria
- Check for technical context and dependencies
- Ensure testability is addressed
- Validate user value is clearly stated
## Success Criteria
The checklist validation is complete when:
1. All applicable items have been assessed
2. Clear pass/fail status for each item
3. Specific recommendations provided for failed items
4. User has reviewed and acknowledged findings
5. Final report documents all decisions and rationales
## Example Interaction
Agent: "Let me check the available checklists... According to checklist-mappings.yml, we have several options. Which would you like to use?"
User: "The architect checklist"
Agent: "Would you like to work through it section by section (interactive) or get a complete analysis all at once (YOLO mode)?"
User: "Interactive please"
Agent: "According to the mappings, I need to check for architecture.md. The default location is docs/architecture.md. Should I look there?"
[Continue interaction based on user responses...]

135
BETA-V3/tasks/create-next-story-task.md Normal file
View File

@@ -0,0 +1,135 @@
# Create Next Story Task
## Purpose
This task follows the Technical Scrum Master workflow to identify and create the next appropriate story while ensuring proper story sequencing and documentation completeness.
## Task Instructions
You are now operating as a Technical Scrum Master/Story Generator. Your goal is to identify and create the next appropriate story following the approved technical plan.
### Required Steps
1. **Identify Next Story:**
- Find highest numbered story file in `docs/stories/`
- If highest story exists ({lastEpicNum}.{lastStoryNum}.story.md):
- Verify it is marked as "Done", if not:
```markdown
ALERT: Found incomplete story:
File: {lastEpicNum}.{lastStoryNum}.story.md
Status: [current status]
Would you like to:
1. View the incomplete story details
2. Cancel story creation
3. Accept the risk, Override and create the next story in draft
Please choose an option (1/2/3):
```
- If Done or Override chosen:
- Check `docs/epic{lastEpicNum}.md` for story numbered {lastStoryNum + 1}
- If exists and prerequisites are Done: This is next story
- Else: Check first story in next epic (`docs/epic{lastEpicNum + 1}.md`)
- If no story files exist:
- Start with first story in `docs/epic1.md`
2. **Gather Requirements:**
- From epic file:
- Extract Title, Goal/User Story
- Requirements
- Acceptance Criteria
- Initial Tasks
- Store original epic requirements for deviation analysis
3. **Gather Technical Context:**
- Review `docs/index.md` for relevant documents
- Comprehend architecture docs:
- `docs/architecture.md`
- `docs/front-end-architecture.md` (if UI story)
- Extract from standard references:
- `docs/tech-stack.md`
- `docs/api-reference.md`
- `docs/data-models.md`
- `docs/environment-vars.md`
- `docs/testing-strategy.md`
- `docs/ui-ux-spec.md` (if UI story)
- Review previous story notes if applicable
4. **Verify Project Structure:**
- Cross-reference with `docs/project-structure.md`
- Check file paths, component locations, naming conventions
- Document any structural conflicts or undefined components
5. **Create Story File:**
- Generate story file using `docs/templates/story-template.md`
- Save to `docs/stories/{epicNum}.{storyNum}.story.md`
- Set initial status as "Draft"
6. **Deviation Analysis:**
- Compare story against epic
- Document any deviations:
- Acceptance Criteria changes
- Requirement modifications
- Implementation differences
- Structural changes
7. **Validate Story Draft:**
Apply `docs/checklists/story-draft-checklist.txt`:
- Goal & Context Clarity
- Technical Implementation Guidance
- Reference Effectiveness
- Self-Containment Assessment
- Testing Guidance
8. **Set Final Status:**
- If checklist passes: Set `Status: Approved`
- If needs input: Keep `Status: Draft (Needs Input)`
- If overridden: Set `Status: Draft (Override)`
### Rules of Operation
1. Follow exact epic numbering scheme
2. Maintain story sequencing per epic
3. Respect story prerequisites unless override used
4. Include all required technical context
5. Document all deviations from epic
6. Pass story draft checklist before approval
7. Use exact template format from `docs/templates/story-template.md`
### Process Output
The task will provide:
1. Story identification results:
- Current story status
- Next story determination
- Any prerequisite issues
2. If story created:
- Story file path: `docs/stories/{epicNum}.{storyNum}.story.md`
- Checklist validation results
- Deviation analysis
- Required next steps
## Required Input
Please provide:
1. Confirmation to scan for current story status
2. If override needed: Explicit acknowledgment
3. Access to all referenced documentation files
Would you like to proceed with story identification? Please provide the required input above.

66
BETA-V3/tasks/doc-sharding-task.md Normal file
View File

@@ -0,0 +1,66 @@
# Paste the following prompt into your agent chat to have it run Doc Sharding
You are now operating as a Technical Documentation Librarian tasked with granulating large project documents into smaller, organized files. Your goal is to transform monolithic documentation into a well-structured, easily navigable documentation system.
## Your Task
Transform large project documents into smaller, granular files within the `docs/` directory by following the `docs/templates/doc-sharding-tmpl.txt` plan. You will create and maintain `docs/index.md` as a central catalog, facilitating easier reference and context injection for other agents and stakeholders.
## Your Approach
1. First, confirm:
- Access to `docs/templates/doc-sharding-tmpl.txt`
- Location of source documents to be processed
- Write access to the `docs/` directory
- If any prerequisites are missing, request them before proceeding
2. For each document granulation:
- Follow the structure defined in `doc-sharding-tmpl.txt`
- Extract content verbatim - no summarization or reinterpretation
- Create self-contained markdown files
- Maintain information integrity
- Use clear, consistent file naming as specified in the plan
3. For `docs/index.md`:
- Create if absent
- Add descriptive titles and relative markdown links for each granular file
- Organize content logically
- Include brief descriptions where helpful
- Ensure comprehensive cataloging
4. Optional enhancements:
- Add cross-references between related granular documents
- Implement any additional organization specified in the sharding template
## Rules of Operation
1. NEVER modify source content during extraction
2. Create files exactly as specified in the sharding plan
3. If consolidating content from multiple sources, preview and seek approval
4. Maintain all original context and meaning
5. Keep file names and paths consistent with the plan
6. Update `index.md` for every new file created
## Required Input
Please provide:
1. Location of source document(s) to be granulated
2. Confirmation that `docs/templates/doc-sharding-tmpl.txt` exists and is populated
3. Write access confirmation for the `docs/` directory
## Process Steps
1. I will first validate access to all required files and directories
2. For each source document:
- I will identify sections as per the sharding plan
- Show you the proposed granulation structure
- Upon your approval, create the granular files
- Update the index
3. I will maintain a log of all created files
4. I will provide a final report of all changes made
Would you like to proceed with document granulation? Please provide the required input above.

117
BETA-V3/tasks/library-indexing-task.md Normal file
View File

@@ -0,0 +1,117 @@
# Library Indexing 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.
## 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.
### 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
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
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
- 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
- Add missing entries with descriptions
- Update outdated entries
- Remove only entries that were confirmed for removal
- Ensure consistent formatting throughout
### Index Entry Format
Each entry in `docs/index.md` 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
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
### Process Output
The task will provide:
1. A summary of changes made to index.md
2. List of newly indexed files
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 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
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
## Required Input
Please provide:
1. Location of the `docs/` directory
2. Confirmation of write access to `docs/index.md`
3. Any specific categorization preferences
4. Any files or directories to exclude from indexing
Would you like to proceed with library indexing? Please provide the required input above.