@codemcp/workflows-core 5.2.2 → 5.2.3

package/resources/workflows/sdd-feature.yaml

@@ -27,25 +27,26 @@ states:
   analyze:
     description: 'Analyze current state and requirements (optional for new features)'
     default_instructions: |
-      You are analyzing the current state to understand the context for this feature development.
+      Analyze the current state to understand the context for this feature development.
 
       **Analysis Tasks:**
-      1. **For New Features**: This phase can be brief - focus on understanding:
-         - How this feature fits into the existing system
-         - Integration points with current functionality
-         - Existing patterns and conventions to follow
-
-      2. **For Enhancements**: Conduct thorough analysis:
-         - Current implementation and its limitations
-         - User pain points and feedback
-         - Performance or usability issues
-         - Technical debt that should be addressed
-
-      3. **Context Gathering**:
-         - Review existing codebase and architecture
-         - Understand current user workflows
-         - Identify constraints and dependencies
-         - Document assumptions about the current state
+
+      **For New Features**: This phase can be brief. Focus on understanding:
+      - How this feature fits into the existing system
+      - Integration points with current functionality
+      - Existing patterns and conventions to follow
+
+      **For Enhancements**: Conduct thorough analysis:
+      - Current implementation and its limitations
+      - User pain points and feedback
+      - Performance or usability issues
+      - Technical debt that should be addressed
+
+      **Context Gathering**:
+      - Review existing codebase and architecture
+      - Understand current user workflows
+      - Identify constraints and dependencies
+      - Document assumptions about the current state
 
       **Output**: Create `$VIBE_DIR/specs/$BRANCH_NAME/current-state-analysis.md` documenting your findings. For simple new features, this can be brief. For enhancements, be comprehensive.
 
@@ -66,37 +67,39 @@ states:
   specify:
     description: 'Create feature specification'
     default_instructions: |
-      You are creating the feature specification that will guide all development decisions.
+      Create the feature specification that will guide all development decisions.
 
       **Specification Process:**
 
-      1. **Parse Requirements**: Extract key concepts from the user's description
-         - Identify: actors, actions, data, constraints
-         - Consider existing system context (from analysis if performed)
-         - Focus on WHAT users need and WHY, not HOW to implement
-
-      2. **Interactive Requirements Gathering**: Ask clarifying questions about:
-         - **Integration Points**: How should this integrate with existing features?
-         - **User Impact**: Which existing users will be affected?
-         - **Data Dependencies**: What existing data does this feature need?
-         - **Performance**: Any specific performance requirements for this feature?
-         - **Compatibility**: Any backward compatibility concerns?
-
-      3. **Handle Ambiguities Systematically**:
-         - Make informed guesses based on context, existing patterns, and industry standards
-         - Only use [NEEDS CLARIFICATION: specific question] for critical decisions that:
-           - Significantly impact feature scope or user experience
-           - Have multiple reasonable interpretations with different implications
-           - Lack any reasonable default
-         - **LIMIT: Maximum 3 [NEEDS CLARIFICATION] markers total**
-         - Prioritize: scope > security/privacy > user experience > technical details
-
-      4. **Quality Validation**:
-         - No implementation details (languages, frameworks, APIs)
-         - Written for non-technical stakeholders
-         - All requirements are testable
-         - Success criteria are measurable and technology-agnostic
-         - Considers existing system constraints
+      **STEP 1: Parse Requirements**
+      - Extract key concepts from the user's description
+      - Identify: actors, actions, data, constraints
+      - Consider existing system context (from analysis if performed)
+      - Focus on WHAT users need and WHY, not HOW to implement
+
+      **STEP 2: Interactive Requirements Gathering**
+      Ask clarifying questions about:
+      - **Integration Points**: How should this integrate with existing features?
+      - **User Impact**: Which existing users will be affected?
+      - **Data Dependencies**: What existing data does this feature need?
+      - **Performance**: Any specific performance requirements for this feature?
+      - **Compatibility**: Any backward compatibility concerns?
+
+      **STEP 3: Handle Ambiguities Systematically**
+      - Make informed guesses based on context, existing patterns, and industry standards
+      - Only use `[NEEDS CLARIFICATION: specific question]` for critical decisions that:
+        - Significantly impact feature scope or user experience
+        - Have multiple reasonable interpretations with different implications
+        - Lack any reasonable default
+      - **LIMIT: Maximum 3** `[NEEDS CLARIFICATION]` markers total
+      - Prioritize: scope > security/privacy > user experience > technical details
+
+      **STEP 4: Quality Validation**
+      - Ensure no implementation details (languages, frameworks, APIs)
+      - Ensure written for non-technical stakeholders
+      - Verify all requirements are testable
+      - Ensure success criteria are measurable and technology-agnostic
+      - Consider existing system constraints
 
       Create `$VIBE_DIR/specs/$BRANCH_NAME/spec.md` using the template provided below.
     additional_instructions: |
@@ -203,38 +206,38 @@ states:
   clarify:
     description: 'Review and clarify specification details'
     default_instructions: |
-      You are reviewing the specification for completeness and clarity.
+      Review the specification for completeness and clarity.
 
       **Clarification Process:**
 
-      1. **Specification Review**:
-         - Check for any remaining [NEEDS CLARIFICATION] markers
-         - Verify all functional requirements are testable
-         - Ensure success criteria are measurable
-         - Validate user scenarios are complete
-
-      2. **Handle Remaining Clarifications**:
-         If [NEEDS CLARIFICATION] markers exist:
-         - Extract all markers from the spec
-         - For each clarification (max 3), present options in structured format:
-           ```
-           ## Question [N]: [Topic]
-           **Context**: [Quote relevant spec section]
-           **What we need to know**: [Specific question]
-           **Suggested Answers**:
-           | Option | Answer | Implications |
-           |--------|--------|--------------|
-           | A      | [First option] | [Impact on feature] |
-           | B      | [Second option] | [Impact on feature] |
-           | C      | [Third option] | [Impact on feature] |
-           ```
-         - Wait for user responses
-         - Update specification with chosen answers
-
-      3. **Final Validation**:
-         - Ensure no implementation details leaked in
-         - Verify requirements align with existing system
-         - Confirm specification is ready for planning
+      **STEP 1: Specification Review**
+      - Check for any remaining `[NEEDS CLARIFICATION]` markers
+      - Verify all functional requirements are testable
+      - Ensure success criteria are measurable
+      - Validate user scenarios are complete
+
+      **STEP 2: Handle Remaining Clarifications**
+      If `[NEEDS CLARIFICATION]` markers exist:
+      - Extract all markers from the spec
+      - For each clarification (max 3), present options in structured format:
+        ```
+        ## Question [N]: [Topic]
+        **Context**: [Quote relevant spec section]
+        **What we need to know**: [Specific question]
+        **Suggested Answers**:
+        | Option | Answer | Implications |
+        |--------|--------|--------------|
+        | A      | [First option] | [Impact on feature] |
+        | B      | [Second option] | [Impact on feature] |
+        | C      | [Third option] | [Impact on feature] |
+        ```
+      - Wait for user responses
+      - Update specification with chosen answers
+
+      **STEP 3: Final Validation**
+      - Ensure no implementation details leaked in
+      - Verify requirements align with existing system
+      - Confirm specification is ready for planning
 
       **Output**: Updated `$VIBE_DIR/specs/$BRANCH_NAME/spec.md` with all clarifications resolved and ready for implementation planning.
 
@@ -253,46 +256,47 @@ states:
   plan:
     description: 'Generate implementation plan with constitutional compliance'
     default_instructions: |
-      You are creating the implementation plan, considering existing system architecture.
+      Create the implementation plan, considering existing system architecture.
 
       **Planning Process:**
 
-      1. **Load Context**:
-         - Read the feature specification (`$VIBE_DIR/specs/$BRANCH_NAME/spec.md`)
-         - Read analysis findings (`$VIBE_DIR/specs/$BRANCH_NAME/current-state-analysis.md` if exists)
-         - Review existing project constitution or architectural principles
-         - Understand current system architecture and patterns
-
-      2. **Interactive Integration Planning**: Ask the user about:
-         - **Technology Consistency**: Should this use the same tech stack as existing features?
-         - **Architecture Alignment**: How should this fit into the current architecture?
-         - **Database Changes**: Any new data models or schema changes needed?
-
-      3. **Technical Context Analysis**:
-         - Identify how this feature integrates with existing system
-         - Map dependencies and integration points
-         - Choose appropriate technology stack (consistent with existing)
-         - Mark unknowns as "NEEDS CLARIFICATION" for research
-
-      4. **Constitutional/Architectural Compliance**:
-         - Evaluate approach against existing architectural principles
-         - Ensure consistency with current patterns and conventions
-         - Identify any violations and justify or resolve them
-
-      5. **Phase 0 - Research & Decisions**:
-         - For each unknown → research task
-         - For each integration point → compatibility analysis
-         - Generate `$VIBE_DIR/specs/$BRANCH_NAME/technology-research.md` with decisions and rationale
-
-      6. **Phase 1 - High-Level Integration Design**:
-         - Document how this feature integrates with existing architecture
-         - Identify integration points and dependencies
-         - Plan compatibility and migration requirements
-
-      7. **Integration Strategy**:
-         - Plan how to integrate with existing codebase
-         - Identify migration or compatibility requirements
-         - Document rollout strategy if needed
+      **STEP 1: Load Context**
+      - Read the feature specification (`$VIBE_DIR/specs/$BRANCH_NAME/spec.md`)
+      - Read analysis findings (`$VIBE_DIR/specs/$BRANCH_NAME/current-state-analysis.md` if exists)
+      - Review existing project constitution or architectural principles
+      - Understand current system architecture and patterns
+
+      **STEP 2: Interactive Integration Planning**
+      Ask the user about:
+      - **Technology Consistency**: Should this use the same tech stack as existing features?
+      - **Architecture Alignment**: How should this fit into the current architecture?
+      - **Database Changes**: Any new data models or schema changes needed?
+
+      **STEP 3: Technical Context Analysis**
+      - Identify how this feature integrates with existing system
+      - Map dependencies and integration points
+      - Choose appropriate technology stack (consistent with existing)
+      - Mark unknowns as "NEEDS CLARIFICATION" for research
+
+      **STEP 4: Constitutional/Architectural Compliance**
+      - Evaluate approach against existing architectural principles
+      - Ensure consistency with current patterns and conventions
+      - Identify any violations and justify or resolve them
+
+      **STEP 5: Phase 0 - Research & Decisions**
+      - For each unknown → research task
+      - For each integration point → compatibility analysis
+      - Generate `$VIBE_DIR/specs/$BRANCH_NAME/technology-research.md` with decisions and rationale
+
+      **STEP 6: Phase 1 - High-Level Integration Design**
+      - Document how this feature integrates with existing architecture
+      - Identify integration points and dependencies
+      - Plan compatibility and migration requirements
+
+      **STEP 7: Integration Strategy**
+      - Plan how to integrate with existing codebase
+      - Identify migration or compatibility requirements
+      - Document rollout strategy if needed
 
       Create `$VIBE_DIR/specs/$BRANCH_NAME/plan.md` with complete implementation strategy that respects existing system architecture.
 
@@ -311,63 +315,65 @@ states:
   tasks:
     description: 'Generate actionable, dependency-ordered tasks organized by user stories'
     default_instructions: |
-      You are generating actionable tasks organized by user stories for independent implementation.
+      Generate actionable tasks organized by user stories for independent implementation.
 
       **Task Generation Process:**
 
-      1. **Load Design Documents**:
-         - **Required**: `$VIBE_DIR/specs/$BRANCH_NAME/plan.md`, `$VIBE_DIR/specs/$BRANCH_NAME/spec.md` (user stories with priorities)
-         - **Optional**: `$VIBE_DIR/specs/$BRANCH_NAME/technology-research.md`, `$VIBE_DIR/specs/$BRANCH_NAME/current-state-analysis.md`
-
-      2. **Extract User Stories**: Load $VIBE_DIR/specs/$BRANCH_NAME/spec.md and extract user stories with priorities (P1, P2, P3...)
-
-      3. **Generate Tasks Organized by User Story**:
-         - **Setup Phase**: Integration setup and shared infrastructure
-         - **Foundational Phase**: Prerequisites for this feature (database changes, etc.)
-         - **User Story Phases** (P1, P2, P3...): One phase per story in priority order
-           - Group all tasks needed to complete JUST that story
-           - Include models, services, endpoints, UI components specific to that story
-           - Consider integration with existing components
-           - Mark parallelizable tasks with [P]
-           - Each story should be independently testable
-
-      4. **Integration Tasks**:
-         - Tasks for connecting with existing system
-         - Migration or compatibility tasks if needed
-         - Testing integration points
-
-      5. **Task Rules**:
-         - Different files/components = mark [P] for parallel execution
-         - Same file = sequential (no [P])
-         - Number tasks sequentially (T001, T002...)
-         - Each task specific enough for LLM to complete
-
-      6. **Rollout Strategy**: Plan for gradual feature rollout if applicable
+      **STEP 1: Load Design Documents**
+      - **Required**: `$VIBE_DIR/specs/$BRANCH_NAME/plan.md`, `$VIBE_DIR/specs/$BRANCH_NAME/spec.md` (user stories with priorities)
+      - **Optional**: `$VIBE_DIR/specs/$BRANCH_NAME/technology-research.md`, `$VIBE_DIR/specs/$BRANCH_NAME/current-state-analysis.md`
+
+      **STEP 2: Extract User Stories**
+      Load `$VIBE_DIR/specs/$BRANCH_NAME/spec.md` and extract user stories with priorities (P1, P2, P3...)
+
+      **STEP 3: Generate Tasks Organized by User Story**
+      - **Setup Phase**: Integration setup and shared infrastructure
+      - **Foundational Phase**: Prerequisites for this feature (database changes, etc.)
+      - **User Story Phases** (P1, P2, P3...): One phase per story in priority order
+        - Group all tasks needed to complete JUST that story
+        - Include models, services, endpoints, UI components specific to that story
+        - Consider integration with existing components
+        - Mark parallelizable tasks with `[P]`
+        - Each story should be independently testable
+
+      **STEP 4: Integration Tasks**
+      - Tasks for connecting with existing system
+      - Migration or compatibility tasks if needed
+      - Testing integration points
+
+      **STEP 5: Apply Task Rules**
+      - Different files/components = mark `[P]` for parallel execution
+      - Same file = sequential (no `[P]`)
+      - Number tasks sequentially (T001, T002...)
+      - Ensure each task is specific enough for LLM to complete
+
+      **STEP 6: Rollout Strategy**
+      Plan for gradual feature rollout if applicable
 
     additional_instructions: |
       **Document Creation Instructions:**
 
       Create these documents in the following order:
 
-      **1. Data Model (`$VIBE_DIR/specs/$BRANCH_NAME/data-model.md`)**:
+      **1. Data Model** (`$VIBE_DIR/specs/$BRANCH_NAME/data-model.md`)
       - Extract entities from the specification
       - Design data models that integrate with existing system
       - Document relationships with existing entities
       - Include migration requirements if needed
 
-      **2. API Contracts (`$VIBE_DIR/specs/$BRANCH_NAME/contracts/`)**:
+      **2. API Contracts** (`$VIBE_DIR/specs/$BRANCH_NAME/contracts/`)
       - Design API contracts that integrate with existing system
       - Ensure compatibility with existing data models and APIs
       - Include versioning strategy if needed
       - Document integration points
 
-      **3. Development Setup (`$VIBE_DIR/specs/$BRANCH_NAME/quickstart.md`)**:
+      **3. Development Setup** (`$VIBE_DIR/specs/$BRANCH_NAME/quickstart.md`)
       - Feature development setup instructions
       - Integration testing setup
       - Local development environment for this feature
       - Testing instructions specific to this feature
 
-      **4. Task Breakdown (`$VIBE_DIR/specs/$BRANCH_NAME/tasks.md`)**:
+      **4. Task Breakdown** (`$VIBE_DIR/specs/$BRANCH_NAME/tasks.md`)
       Use this structure for the tasks file:
 
       ```markdown
@@ -415,25 +421,26 @@ states:
   implement:
     description: 'Execute implementation following the task breakdown'
     default_instructions: |
-      You are implementing the feature by executing the tasks defined in `$VIBE_DIR/specs/$BRANCH_NAME/tasks.md`, ensuring proper integration with the existing system.
+      Execute the feature implementation by following the tasks defined in `$VIBE_DIR/specs/$BRANCH_NAME/tasks.md`, ensuring proper integration with the existing system.
 
       **Implementation Guidelines:**
-      1. **Follow Task Order**: Execute tasks respecting dependencies and integration requirements
-      2. **System Integration**: Ensure new code follows existing patterns and conventions
-      3. **User Story Focus**: Complete one user story at a time for incremental delivery
-      4. **Quality Gates**: Each user story must meet success criteria from specification
-      5. **Testing**: Test both new functionality and integration with existing features
-      6. **Documentation**: Update existing documentation as needed
-
-      **Integration Considerations**:
+
+      - Follow task order respecting dependencies and integration requirements
+      - Ensure new code follows existing patterns and conventions
+      - Complete one user story at a time for incremental delivery
+      - Verify each user story meets success criteria from specification
+      - Test both new functionality and integration with existing features
+      - Update existing documentation as needed
+
+      **Integration Considerations:**
       - Follow existing code style and patterns
       - Respect current architectural decisions
       - Test integration points thoroughly
       - Consider backward compatibility
       - Update relevant configuration or setup
 
-      **Progress Tracking**:
-      - Mark completed tasks with [x] in `$VIBE_DIR/specs/$BRANCH_NAME/tasks.md`
+      **Progress Tracking:**
+      - Mark completed tasks with `[x]` in `$VIBE_DIR/specs/$BRANCH_NAME/tasks.md`
       - Document any integration challenges or decisions
       - Update specification if requirements evolve