@codemcp/workflows 6.3.0 → 6.3.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codemcp/workflows",
-  "version": "6.3.0",
+  "version": "6.3.1",
   "description": "A Model Context Protocol server that acts as an intelligent conversation state manager and development guide for LLMs, featuring comprehensive long-term memory with persistent project artifacts",
   "type": "module",
   "main": "packages/cli/dist/index.js",
@@ -51,7 +51,7 @@
     "typescript": "^5.9.3",
     "vitepress": "^1.6.4",
     "vitest": "4.0.18",
-    "@codemcp/workflows-core": "6.3.0"
+    "@codemcp/workflows-core": "6.3.1"
   },
   "lint-staged": {
     "*.{ts,js,mts,cts,tsx,jsx}": [

package/packages/cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codemcp/workflows-cli",
-  "version": "6.3.0",
+  "version": "6.3.1",
   "description": "CLI tools for responsible-vibe development workflows",
   "type": "module",
   "scripts": {

package/packages/core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codemcp/workflows-core",
-  "version": "6.3.0",
+  "version": "6.3.1",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
   "type": "module",

package/packages/docs/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codemcp/workflows-docs",
-  "version": "6.3.0",
+  "version": "6.3.1",
   "description": "Documentation site for Responsible Vibe MCP",
   "type": "module",
   "scripts": {

package/packages/mcp-server/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codemcp/workflows-server",
-  "version": "6.3.0",
+  "version": "6.3.1",
   "description": "MCP server for responsible-vibe development workflows - provides structured workflow guidance",
   "type": "module",
   "main": "dist/index.js",

package/packages/visualizer/package.json

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

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

@@ -1,29 +0,0 @@
----
-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/packages/core/resources/templates/skills/architecture.md

@@ -1,13 +0,0 @@
----
-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/packages/core/resources/templates/skills/coding.md

@@ -1,35 +0,0 @@
----
-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/packages/core/resources/templates/skills/starting-project.md

@@ -1,23 +0,0 @@
----
-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/packages/core/resources/templates/skills/task-handling.md

@@ -1,19 +0,0 @@
----
-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/packages/core/resources/templates/skills/testing.md

@@ -1,20 +0,0 @@
----
-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/packages/mcp-server/resources/templates/skills/application-design.md

@@ -1,29 +0,0 @@
----
-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/packages/mcp-server/resources/templates/skills/architecture.md

@@ -1,13 +0,0 @@
----
-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/packages/mcp-server/resources/templates/skills/coding.md

@@ -1,35 +0,0 @@
----
-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/packages/mcp-server/resources/templates/skills/starting-project.md

@@ -1,23 +0,0 @@
----
-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/packages/mcp-server/resources/templates/skills/task-handling.md

@@ -1,19 +0,0 @@
----
-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/packages/mcp-server/resources/templates/skills/testing.md

@@ -1,20 +0,0 @@
----
-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/templates/skills/application-design.md

@@ -1,29 +0,0 @@
----
-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

@@ -1,13 +0,0 @@
----
-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

@@ -1,35 +0,0 @@
----
-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

@@ -1,23 +0,0 @@
----
-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

@@ -1,19 +0,0 @@
----
-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

@@ -1,20 +0,0 @@
----
-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