agentvibes 2.4.3-beta.2 → 2.4.3

package/.claude/commands/BMad/tasks/brownfield-create-story.md

@@ -1,153 +0,0 @@
-# /brownfield-create-story Task
-
-When this command is used, execute the following task:
-
-<!-- Powered by BMAD™ Core -->
-
-# 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

package/.claude/commands/BMad/tasks/correct-course.md

@@ -1,76 +0,0 @@
-# /correct-course Task
-
-When this command is used, execute the following task:
-
-<!-- Powered by BMAD™ Core -->
-
-# Correct Course Task
-
-## Purpose
-
-- Guide a structured response to a change trigger using the `.bmad-core/checklists/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, re-scope 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 `.bmad-core/checklists/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."
-  - Once the user chooses, confirm the selected mode and then 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."
-
-### 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.
-- 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.

package/.claude/commands/BMad/tasks/create-brownfield-story.md

@@ -1,318 +0,0 @@
-# /create-brownfield-story Task
-
-When this command is used, execute the following task:
-
-<!-- Powered by BMAD™ Core -->
-
-# Create Brownfield Story Task
-
-## Purpose
-
-Create detailed, implementation-ready stories for brownfield projects where traditional sharded PRD/architecture documents may not exist. This task bridges the gap between various documentation formats (document-project output, brownfield PRDs, epics, or user documentation) and executable stories for the Dev agent.
-
-## When to Use This Task
-
-**Use this task when:**
-
-- Working on brownfield projects with non-standard documentation
-- Stories need to be created from document-project output
-- Working from brownfield epics without full PRD/architecture
-- Existing project documentation doesn't follow BMad v4+ structure
-- Need to gather additional context from user during story creation
-
-**Use create-next-story when:**
-
-- Working with properly sharded PRD and v4 architecture documents
-- Following standard greenfield or well-documented brownfield workflow
-- All technical context is available in structured format
-
-## Task Execution Instructions
-
-### 0. Documentation Context
-
-Check for available documentation in this order:
-
-1. **Sharded PRD/Architecture** (docs/prd/, docs/architecture/)
-   - If found, recommend using create-next-story task instead
-
-2. **Brownfield Architecture Document** (docs/brownfield-architecture.md or similar)
-   - Created by document-project task
-   - Contains actual system state, technical debt, workarounds
-
-3. **Brownfield PRD** (docs/prd.md)
-   - May contain embedded technical details
-
-4. **Epic Files** (docs/epics/ or similar)
-   - Created by brownfield-create-epic task
-
-5. **User-Provided Documentation**
-   - Ask user to specify location and format
-
-### 1. Story Identification and Context Gathering
-
-#### 1.1 Identify Story Source
-
-Based on available documentation:
-
-- **From Brownfield PRD**: Extract stories from epic sections
-- **From Epic Files**: Read epic definition and story list
-- **From User Direction**: Ask user which specific enhancement to implement
-- **No Clear Source**: Work with user to define the story scope
-
-#### 1.2 Gather Essential Context
-
-CRITICAL: For brownfield stories, you MUST gather enough context for safe implementation. Be prepared to ask the user for missing information.
-
-**Required Information Checklist:**
-
-- [ ] What existing functionality might be affected?
-- [ ] What are the integration points with current code?
-- [ ] What patterns should be followed (with examples)?
-- [ ] What technical constraints exist?
-- [ ] Are there any "gotchas" or workarounds to know about?
-
-If any required information is missing, list the missing information and ask the user to provide it.
-
-### 2. Extract Technical Context from Available Sources
-
-#### 2.1 From Document-Project Output
-
-If using brownfield-architecture.md from document-project:
-
-- **Technical Debt Section**: Note any workarounds affecting this story
-- **Key Files Section**: Identify files that will need modification
-- **Integration Points**: Find existing integration patterns
-- **Known Issues**: Check if story touches problematic areas
-- **Actual Tech Stack**: Verify versions and constraints
-
-#### 2.2 From Brownfield PRD
-
-If using brownfield PRD:
-
-- **Technical Constraints Section**: Extract all relevant constraints
-- **Integration Requirements**: Note compatibility requirements
-- **Code Organization**: Follow specified patterns
-- **Risk Assessment**: Understand potential impacts
-
-#### 2.3 From User Documentation
-
-Ask the user to help identify:
-
-- Relevant technical specifications
-- Existing code examples to follow
-- Integration requirements
-- Testing approaches used in the project
-
-### 3. Story Creation with Progressive Detail Gathering
-
-#### 3.1 Create Initial Story Structure
-
-Start with the story template, filling in what's known:
-
-```markdown
-# Story {{Enhancement Title}}
-
-## Status: Draft
-
-## Story
-
-As a {{user_type}},
-I want {{enhancement_capability}},
-so that {{value_delivered}}.
-
-## Context Source
-
-- Source Document: {{document name/type}}
-- Enhancement Type: {{single feature/bug fix/integration/etc}}
-- Existing System Impact: {{brief assessment}}
-```
-
-#### 3.2 Develop Acceptance Criteria
-
-Critical: For brownfield, ALWAYS include criteria about maintaining existing functionality
-
-Standard structure:
-
-1. New functionality works as specified
-2. Existing {{affected feature}} continues to work unchanged
-3. Integration with {{existing system}} maintains current behavior
-4. No regression in {{related area}}
-5. Performance remains within acceptable bounds
-
-#### 3.3 Gather Technical Guidance
-
-Critical: This is where you'll need to be interactive with the user if information is missing
-
-Create Dev Technical Guidance section with available information:
-
-````markdown
-## Dev Technical Guidance
-
-### Existing System Context
-
-[Extract from available documentation]
-
-### Integration Approach
-
-[Based on patterns found or ask user]
-
-### Technical Constraints
-
-[From documentation or user input]
-
-### Missing Information
-
-Critical: List anything you couldn't find that dev will need and ask for the missing information
-
-### 4. Task Generation with Safety Checks
-
-#### 4.1 Generate Implementation Tasks
-
-Based on gathered context, create tasks that:
-
-- Include exploration tasks if system understanding is incomplete
-- Add verification tasks for existing functionality
-- Include rollback considerations
-- Reference specific files/patterns when known
-
-Example task structure for brownfield:
-
-```markdown
-## Tasks / Subtasks
-
-- [ ] Task 1: Analyze existing {{component/feature}} implementation
-  - [ ] Review {{specific files}} for current patterns
-  - [ ] Document integration points
-  - [ ] Identify potential impacts
-
-- [ ] Task 2: Implement {{new functionality}}
-  - [ ] Follow pattern from {{example file}}
-  - [ ] Integrate with {{existing component}}
-  - [ ] Maintain compatibility with {{constraint}}
-
-- [ ] Task 3: Verify existing functionality
-  - [ ] Test {{existing feature 1}} still works
-  - [ ] Verify {{integration point}} behavior unchanged
-  - [ ] Check performance impact
-
-- [ ] Task 4: Add tests
-  - [ ] Unit tests following {{project test pattern}}
-  - [ ] Integration test for {{integration point}}
-  - [ ] Update existing tests if needed
-```
-````
-
-### 5. Risk Assessment and Mitigation
-
-CRITICAL: for brownfield - always include risk assessment
-
-Add section for brownfield-specific risks:
-
-```markdown
-## Risk Assessment
-
-### Implementation Risks
-
-- **Primary Risk**: {{main risk to existing system}}
-- **Mitigation**: {{how to address}}
-- **Verification**: {{how to confirm safety}}
-
-### Rollback Plan
-
-- {{Simple steps to undo changes if needed}}
-
-### Safety Checks
-
-- [ ] Existing {{feature}} tested before changes
-- [ ] Changes can be feature-flagged or isolated
-- [ ] Rollback procedure documented
-```
-
-### 6. Final Story Validation
-
-Before finalizing:
-
-1. **Completeness Check**:
-   - [ ] Story has clear scope and acceptance criteria
-   - [ ] Technical context is sufficient for implementation
-   - [ ] Integration approach is defined
-   - [ ] Risks are identified with mitigation
-
-2. **Safety Check**:
-   - [ ] Existing functionality protection included
-   - [ ] Rollback plan is feasible
-   - [ ] Testing covers both new and existing features
-
-3. **Information Gaps**:
-   - [ ] All critical missing information gathered from user
-   - [ ] Remaining unknowns documented for dev agent
-   - [ ] Exploration tasks added where needed
-
-### 7. Story Output Format
-
-Save the story with appropriate naming:
-
-- If from epic: `docs/stories/epic-{n}-story-{m}.md`
-- If standalone: `docs/stories/brownfield-{feature-name}.md`
-- If sequential: Follow existing story numbering
-
-Include header noting documentation context:
-
-```markdown
-# Story: {{Title}}
-
-<!-- Source: {{documentation type used}} -->
-<!-- Context: Brownfield enhancement to {{existing system}} -->
-
-## Status: Draft
-
-[Rest of story content...]
-```
-
-### 8. Handoff Communication
-
-Provide clear handoff to the user:
-
-```text
-Brownfield story created: {{story title}}
-
-Source Documentation: {{what was used}}
-Story Location: {{file path}}
-
-Key Integration Points Identified:
-- {{integration point 1}}
-- {{integration point 2}}
-
-Risks Noted:
-- {{primary risk}}
-
-{{If missing info}}:
-Note: Some technical details were unclear. The story includes exploration tasks to gather needed information during implementation.
-
-Next Steps:
-1. Review story for accuracy
-2. Verify integration approach aligns with your system
-3. Approve story or request adjustments
-4. Dev agent can then implement with safety checks
-```
-
-## Success Criteria
-
-The brownfield story creation is successful when:
-
-1. Story can be implemented without requiring dev to search multiple documents
-2. Integration approach is clear and safe for existing system
-3. All available technical context has been extracted and organized
-4. Missing information has been identified and addressed
-5. Risks are documented with mitigation strategies
-6. Story includes verification of existing functionality
-7. Rollback approach is defined
-
-## Important Notes
-
-- This task is specifically for brownfield projects with non-standard documentation
-- Always prioritize existing system stability over new features
-- When in doubt, add exploration and verification tasks
-- It's better to ask the user for clarification than make assumptions
-- Each story should be self-contained for the dev agent
-- Include references to existing code patterns when available