@codemcp/workflows 6.2.1 → 6.3.0

package/packages/mcp-server/resources/workflows/skilled-greenfield.yaml

@@ -33,7 +33,7 @@ states:
       - How will you measure product success?
       - Have you validated this need with potential users?
 
-      Use the **starting-project** skill to understand how SAB projects are set up and what conventions and tooling to expect.
+      Use your **starting-project** skill if available, or ask the user about their project setup practices and conventions.
 
       Don't discuss technical implementation yet - focus purely on understanding the problem space and requirements. Check whether there is a requirements document in the project and if so, read it carefully. Create tasks as needed.
     transitions:
@@ -55,7 +55,7 @@ states:
       - Challenge their choices by presenting alternatives
       - Evaluate pros and cons of different tech stacks, frameworks, and architectural patterns
       - Consider non-functional requirements like scalability, performance, maintainability, and deployment
-      - Use the **architecture** skill to understand SAB architectural conventions and apply them to your design
+      - Use your **architecture** skill if available, or ask the user about their architectural conventions
 
       Check whether there is an architecture document in the project and if so, read and build on it. Don't start coding yet - focus on technical design decisions.
     transitions:
@@ -87,7 +87,7 @@ states:
     default_instructions: |
       Create a detailed implementation strategy based on your completed architecture and requirements.
 
-      - Use the **application-design** skill when planning authentication, routing, error handling, or forms
+      - Use your **application-design** skill if available, or ask the user about their application design practices
       - Check whether there is a design document in the project and adhere to it
 
       **STEP 1: Break Down Work**
@@ -128,8 +128,8 @@ states:
 
       - Check whether there is a design document in the project and follow it
       - Check whether there is a requirements document in the project and ensure all requirements you are currently working on are met
-      - Use the **coding** skill to implement components, styling, and coding patterns. Apply this skill to all coding tasks of this phase!
-      - Use the **testing** skill to write and run tests. Apply this skill to all test tasks of this phase!
+      - Use your **coding** skill if available, or ask the user about their coding practices and patterns
+      - Use your **testing** skill if available, or ask the user about their testing practices
       - Write clean, well-structured code with proper error handling
       - Prevent regression by building, linting, and executing existing tests
       - Stay flexible and adapt the plan as you learn more during implementation, but maintain alignment with your architecture decisions
@@ -186,7 +186,7 @@ states:
       Ensure project has complete documentation for newcomers including setup, usage, architecture overview, and contribution guidelines.
 
       **STEP 4: Final Validation**
-      - Use the **testing** skill to run and verify all tests
+      - Use your **testing** skill if available, or ask the user about their testing practices
       - Verify documentation accuracy with a final review
       - Ensure project is ready for users and contributors
       - Update task progress and mark completed work as you finalize the project

package/packages/visualizer/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codemcp/workflows-visualizer",
-  "version": "6.2.1",
+  "version": "6.3.0",
   "type": "module",
   "main": "dist/index.ts",
   "module": "dist/index.ts",

package/resources/templates/skills/application-design.md

@@ -0,0 +1,29 @@
+---
+name: application-design
+description: General conventions when creating an application design
+---
+
+practices
+
+# Application Design Conventions
+
+**Organization:**
+
+- Apply the Single Responsibility Principle
+- Use packages with defined interfaces to apply open-close principle for components
+
+**APIs:**
+
+- Use RESTful conventions
+- Handle 404s gracefully
+
+**Validation:**
+
+- Validate on client and server
+- Provide immediate feedback
+- Handle edge cases and malicious input
+
+**Configurability**
+
+- Only provide configurability if explicitly requested
+- If needed, use the registry pattern

package/resources/templates/skills/architecture.md

@@ -0,0 +1,13 @@
+---
+name: architecture
+description: General practices to consider when setting up a new application or enhancing it structurally
+---
+
+# Architecture conventions
+
+**Organization:**
+
+- SRP, separation of concerns, dependency injection
+- Fail fast with clear error messages
+- Use packages with defined interfaces to apply open-close principle for components
+- Start with simple, testable components

package/resources/templates/skills/coding.md

@@ -0,0 +1,35 @@
+---
+name: coding
+description: General practices to consider when writing code
+---
+
+# Coding conventions
+
+**Code Quality:**
+
+- Write self-documenting code with clear names. Prefer verbose names over comments
+- Comment the intend (why), do not describe the code (how)
+- KISS
+- DRY
+- Prefer simplicity (understandability over elegance)
+
+**Error Handling:**
+
+- Handle errors explicitly
+- Use explicit error types
+- Provide context in messages
+- Use structured logging and debugger over console.log
+
+**Performance:**
+
+- Avoid premature optimization
+- Use appropriate data structures
+- Consider memory usage
+- Profile before optimizing
+
+**Security:**
+
+- Follow OWASP security guidelines and dependency scanning
+- Validate and sanitize inputs
+- Use parameterized queries
+- Never hardcode secrets

package/resources/templates/skills/starting-project.md

@@ -0,0 +1,23 @@
+---
+name: starting-project
+description: How to set-up the skeleton of a new application
+---
+
+# Starting Project conventions
+
+**Check existing structure:**
+
+- Look for README.md, package.json, or project files
+- Identify tech stack
+
+**Setup patterns:**
+
+- Set up gitignore and linting tools
+- Create basic test structure with common framework
+- Add standard build scripts and CI/CD templates
+- Document setup and contribution guidelines
+
+**Mandatory user interaction:**
+
+- Ask the user for preferences on starter templates
+- Before you write any package or launch a generator, ALWAYS present it to the user and wait for confirmation!

package/resources/templates/skills/task-handling.md

@@ -0,0 +1,19 @@
+---
+name: task-handling
+description: Important conventions on how to author and work on tasks
+---
+
+## Task Writing Methodology
+
+**SMART Tasks:**
+
+- Use task description for SMART criteria
+- Include all context for new team members
+- Include instructions to research known sources of knowledge
+- Specify dependencies and prerequisites
+
+**Task Completion:**
+
+- Record results and key findings when completing
+- Document "how it was done" - methods, approaches, decisions
+- Update plan file with key results in addition

package/resources/templates/skills/testing.md

@@ -0,0 +1,20 @@
+---
+name: testing
+description: General practices when writing and executing tests
+---
+
+## Testing Best Practices
+
+**Test Authoring:**
+
+- Test behavior, not implementation
+- Use testing pyramid (many unit, some integration, few E2E)
+- Test edge cases and error conditions
+- Keep tests simple and fast
+
+**Test Organization:**
+
+- Group related tests
+- Use descriptive test names
+- Follow AAA pattern (Arrange, Act, Assert)
+- Keep test data minimal

package/resources/workflows/bugfix.yaml

@@ -40,19 +40,6 @@ states:
         to: 'analyze'
         transition_reason: 'Bug reproduced successfully, ready to analyze root cause'
 
-      - trigger: 'bug_not_reproducible'
-        to: 'reproduce'
-        instructions: >
-          Unable to reproduce the bug with current information. Gather more details about the environment,
-          conditions, or steps that might be missing. Contact the reporter for additional information if needed.
-          Continue attempting reproduction with new information.
-        transition_reason: 'Bug could not be reproduced, need more information'
-
-      - trigger: 'abandon_bug'
-        to: 'reproduce'
-        additional_instructions: 'Bug investigation abandoned. Clean up any reproduction work and prepare for new bug reports.'
-        transition_reason: 'Bug investigation abandoned'
-
   analyze:
     description: 'Analyze the bug and identify root cause'
     default_instructions: Examine the code paths involved in the bug, identify the root cause, and understand why the issue occurs. Use debugging tools, add logging, and trace through the problematic code. Document your analysis and create tasks as needed.

package/resources/workflows/skilled-bugfix.yaml

@@ -39,21 +39,13 @@ states:
         to: 'analyze'
         transition_reason: 'Bug reproduced successfully, ready to analyze root cause'
 
-      - trigger: 'bug_not_reproducible'
-        to: 'reproduce'
-        instructions: >
-          Unable to reproduce the bug with current information. Gather more details about the environment,
-          conditions, or steps that might be missing. Contact the reporter for additional information if needed.
-          Continue attempting reproduction with new information.
-        transition_reason: 'Bug could not be reproduced, need more information'
-
   analyze:
     description: 'Analyze the bug and identify root cause'
     default_instructions: |
       Examine the code paths involved in the bug, identify the root cause, and understand why the issue occurs. Use debugging tools, add logging, and trace through the problematic code.
 
-      - Use the **architecture** skill to understand the architectural conventions of this project
-      - Use the **application-design** skill to understand authentication, routing, error handling, or form patterns that may be involved
+      - Use your **architecture** skill if available, or ask the user about their architectural conventions
+      - Use your **application-design** skill if available, or ask the user about their application design practices
 
       Document your analysis and create tasks as needed.
     transitions:
@@ -83,8 +75,8 @@ states:
       Implement the solution based on your analysis:
 
       - Check whether there is a design document in the project and follow it
-      - Use the **coding** skill to implement the fix. Apply this skill to all coding tasks of this phase!
-      - Use the **testing** skill to write targeted tests that cover the bug scenario. Apply this skill to all test tasks of this phase!
+      - Use your **coding** skill if available, or ask the user about their coding practices and patterns
+      - Use your **testing** skill if available, or ask the user about their testing practices
 
       Before implementing, assess the approach:
       - How critical is this system? What is the blast radius if the fix causes issues?
@@ -117,7 +109,7 @@ states:
     default_instructions: |
       Test the fix thoroughly to ensure the original bug is resolved and no new issues were introduced.
 
-      - Use the **testing** skill to run existing tests and write new ones covering the bug scenario
+      - Use your **testing** skill if available, or ask the user about their testing practices
       - Verify the solution is robust and handles edge cases
     transitions:
       - trigger: 'fix_needs_adjustment'
@@ -162,7 +154,7 @@ states:
       - Ask the user to review document updates
 
       **STEP 3: Final Validation**
-      - Use the **testing** skill to run and verify all tests
+      - Use your **testing** skill if available, or ask the user about their testing practices
       - Verify documentation accuracy with a final review
       - Ensure bug fix is ready for production
       - Update task progress and mark completed work as you finalize the bug fix

package/resources/workflows/skilled-epcc.yaml

@@ -31,8 +31,8 @@ states:
       - If uncertain about conventions or rules, ask the user about them
       - Read relevant files and documentation
       - Check whether there is a requirements document in the project and if so, read it carefully
-      - If the project is still empty, use the **starting-project** skill to understand how to set it up correctly
-      - Use the **architecture** skill to understand the architectural conventions of this project
+      - If the project is still empty, use your **starting-project** skill if available, or ask the user about their project setup practices
+      - Use your **architecture** skill if available, or ask the user about their architectural conventions
 
       Focus on understanding without writing code yet. Document your findings and create tasks as needed.
     transitions:
@@ -48,8 +48,8 @@ states:
 
       - Check whether there is a requirements document in the project and base your strategy on it
       - Check whether there is a design document in the project and adhere to it; if not, elaborate design options and present them to the user
-      - Use the **architecture** skill to ensure architectural decisions align with SAB conventions
-      - Use the **application-design** skill when planning authentication, routing, error handling, or forms
+      - Use your **architecture** skill if available, or ask the user about their architectural conventions
+      - Use your **application-design** skill if available, or ask the user about their application design practices
 
       Break down the work into specific, actionable tasks. Consider edge cases, dependencies, and potential challenges. Document the planning work thoroughly and create implementation tasks as part of the code phase as needed.
     transitions:
@@ -82,8 +82,8 @@ states:
 
       - Check whether there is a design document in the project and follow it; if not, elaborate design options and present them to the user
       - Check whether there is a requirements document in the project and ensure all requirements are met
-      - Use the **coding** skill to implement components, styling, and coding patterns. Apply this skill to all coding tasks of this phase!
-      - Use the **testing** skill to write and run tests. Apply this skill to all test tasks of this phase!
+      - Use your **coding** skill if available, or ask the user about their coding practices and patterns
+      - Use your **testing** skill if available, or ask the user about their testing practices
 
       Write clean, well-structured code with proper error handling. Prevent regression by building, linting, and executing existing tests. Stay flexible and adapt the plan as you learn more during implementation. Update task progress and create new tasks as needed.
     transitions:
@@ -150,7 +150,7 @@ states:
 
       **STEP 3: Final Validation**
 
-      - Use the **testing** skill to run and verify all tests
+      - Use your **testing** skill if available, or ask the user about their testing practices
       - Verify documentation accuracy with a final review
       - Ensure code is ready for production/delivery
 

package/resources/workflows/skilled-greenfield.yaml

@@ -33,7 +33,7 @@ states:
       - How will you measure product success?
       - Have you validated this need with potential users?
 
-      Use the **starting-project** skill to understand how SAB projects are set up and what conventions and tooling to expect.
+      Use your **starting-project** skill if available, or ask the user about their project setup practices and conventions.
 
       Don't discuss technical implementation yet - focus purely on understanding the problem space and requirements. Check whether there is a requirements document in the project and if so, read it carefully. Create tasks as needed.
     transitions:
@@ -55,7 +55,7 @@ states:
       - Challenge their choices by presenting alternatives
       - Evaluate pros and cons of different tech stacks, frameworks, and architectural patterns
       - Consider non-functional requirements like scalability, performance, maintainability, and deployment
-      - Use the **architecture** skill to understand SAB architectural conventions and apply them to your design
+      - Use your **architecture** skill if available, or ask the user about their architectural conventions
 
       Check whether there is an architecture document in the project and if so, read and build on it. Don't start coding yet - focus on technical design decisions.
     transitions:
@@ -87,7 +87,7 @@ states:
     default_instructions: |
       Create a detailed implementation strategy based on your completed architecture and requirements.
 
-      - Use the **application-design** skill when planning authentication, routing, error handling, or forms
+      - Use your **application-design** skill if available, or ask the user about their application design practices
       - Check whether there is a design document in the project and adhere to it
 
       **STEP 1: Break Down Work**
@@ -128,8 +128,8 @@ states:
 
       - Check whether there is a design document in the project and follow it
       - Check whether there is a requirements document in the project and ensure all requirements you are currently working on are met
-      - Use the **coding** skill to implement components, styling, and coding patterns. Apply this skill to all coding tasks of this phase!
-      - Use the **testing** skill to write and run tests. Apply this skill to all test tasks of this phase!
+      - Use your **coding** skill if available, or ask the user about their coding practices and patterns
+      - Use your **testing** skill if available, or ask the user about their testing practices
       - Write clean, well-structured code with proper error handling
       - Prevent regression by building, linting, and executing existing tests
       - Stay flexible and adapt the plan as you learn more during implementation, but maintain alignment with your architecture decisions
@@ -186,7 +186,7 @@ states:
       Ensure project has complete documentation for newcomers including setup, usage, architecture overview, and contribution guidelines.
 
       **STEP 4: Final Validation**
-      - Use the **testing** skill to run and verify all tests
+      - Use your **testing** skill if available, or ask the user about their testing practices
       - Verify documentation accuracy with a final review
       - Ensure project is ready for users and contributors
       - Update task progress and mark completed work as you finalize the project