@codemcp/workflows 6.0.1 → 6.0.2

package/packages/cli/resources/templates/design/comprehensive.md

@@ -0,0 +1,207 @@
+<!--
+DESIGN DOCUMENT TEMPLATE - TIERED BY PROJECT COMPLEXITY
+
+PURPOSE: Document design principles, patterns, and standards that guide implementation.
+NOTE: Technology stack decisions belong in the Architecture Document, not here.
+
+PROJECT COMPLEXITY GUIDE:
+🚀 ESSENTIAL (Startup/MVP, 1-3 developers, <6 months): Sections 1-2 only
+🏢 CORE (Small team, 2-5 developers, 6-18 months): Sections 1-4
+🏗️ ADVANCED (Enterprise, 5+ developers, 18+ months): Sections 1-5
+⚡ SPECIALIZED (Mission-critical, high reliability): All sections + custom
+
+WHAT TO INCLUDE:
+✅ Design principles and patterns
+✅ Naming conventions and standards
+✅ Component design approaches
+✅ Data modeling principles
+✅ Quality attribute design strategies
+❌ Technology stack choices (goes in Architecture doc)
+❌ Concrete class names or implementations
+❌ Code snippets or method signatures
+
+START SMALL: Begin with Essential sections, add more as project matures.
+
+IMPORTANT: DO NOT REMOVE THIS COMMENT HOW TO USE THE TEMPLATE!
+-->
+
+# Design Document
+
+<!-- # 🚀 ESSENTIAL - Required for all projects -->
+
+## 1. Naming Conventions
+
+<!-- Standards for naming classes, methods, variables, constants, packages
+     Language-specific conventions and project-specific additions
+     Examples: PascalCase for classes, camelCase for methods, etc. -->
+
+### Classes and Types
+
+<!-- How to name classes, interfaces, enums, type definitions -->
+
+### Methods and Functions
+
+<!-- Method naming patterns, verb conventions, parameter naming -->
+
+### Variables and Constants
+
+<!-- Local variables, class fields, constants, configuration values -->
+
+### Packages and Modules
+
+<!-- Package/namespace organization, module naming patterns -->
+
+## 2. Error Handling Design
+
+<!-- Exception hierarchy design, error propagation strategies
+     How errors should be categorized, handled, and communicated
+     Principles for graceful degradation and error recovery -->
+
+### Exception Design Principles
+
+<!-- When to use checked vs unchecked exceptions, custom exception hierarchy -->
+
+### Error Propagation Strategy
+
+<!-- How errors flow through system layers, error boundaries -->
+
+### Error Recovery Patterns
+
+<!-- How system should behave when errors occur, fallback strategies -->
+
+<!-- # 🏢 CORE - Recommended for professional projects -->
+
+## 3. Architecture Patterns & Principles
+
+<!-- SOLID principles, DRY, KISS, YAGNI applied to this project
+     Which architectural patterns are preferred and why
+     Design pattern selection criteria and usage guidelines -->
+
+### Core Design Principles
+
+<!-- How SOLID, DRY, KISS principles apply to this specific project -->
+
+### Preferred Architectural Patterns
+
+<!-- Which patterns (MVC, Repository, Observer, etc.) to use when -->
+
+### Pattern Selection Guidelines
+
+<!-- Criteria for choosing between different design patterns -->
+
+## 4. Component Design Strategy
+
+<!-- How functionality is organized into components
+     Principles for component boundaries and responsibilities
+     Interface design and dependency management approaches -->
+
+### Component Boundary Principles
+
+<!-- How to determine what belongs in each component, separation of concerns -->
+
+### Responsibility Assignment
+
+<!-- How to distribute functionality across components -->
+
+### Interface Design Standards
+
+<!-- How components should expose functionality, API design principles -->
+
+### Dependency Management
+
+<!-- How components depend on each other, injection patterns -->
+
+<!-- # 🏗️ ADVANCED - For complex systems and mature teams -->
+
+## 5. Data Design Approach
+
+<!-- Domain modeling principles, entity design, data flow patterns
+     How data structures support business requirements
+     Consistency and integrity design strategies -->
+
+### Domain Modeling Principles
+
+<!-- How to model business concepts, entity vs value object decisions -->
+
+### Data Transfer Patterns
+
+<!-- DTOs, mapping between layers, data transformation strategies -->
+
+### Data Consistency Strategy
+
+<!-- How to maintain data integrity, transaction boundaries -->
+
+### Data Access Design
+
+<!-- Repository patterns, abstraction layers, query design -->
+
+## 6. Quality Attribute Implementation
+
+<!-- How design decisions support performance, security, maintainability
+     Trade-off analysis and quality attribute prioritization
+     Specific design strategies for quality goals -->
+
+### Performance Design Strategy
+
+<!-- How design choices impact performance, optimization approaches -->
+
+### Security Design Principles
+
+<!-- How security requirements influence design decisions -->
+
+### Maintainability Design Approach
+
+<!-- Design choices that support long-term maintenance and evolution -->
+
+### Scalability Design Considerations
+
+<!-- How design supports system growth and scaling -->
+
+<!-- # ⚡ SPECIALIZED - Add based on specific project needs -->
+
+## 7. Concurrency Design (If Applicable)
+
+<!-- Thread safety principles, synchronization strategies
+     Asynchronous processing patterns, concurrent data access -->
+
+### Thread Safety Strategy
+
+<!-- How to handle concurrent access, synchronization approaches -->
+
+### Asynchronous Processing Design
+
+<!-- Promise/Future patterns, event-driven design -->
+
+## 8. Testing Design Philosophy (If Complex Testing Needs)
+
+<!-- How design supports testability, test structure principles
+     Mocking strategies, test data management -->
+
+### Testability Design Principles
+
+<!-- How to design for effective testing, dependency injection for tests -->
+
+### Test Structure Standards
+
+<!-- Test organization, naming, assertion patterns -->
+
+## 9. Extension and Evolution Strategy (If Long-term Project)
+
+<!-- How design accommodates future changes
+     Extension points, plugin architectures, versioning strategies -->
+
+### Design for Change Principles
+
+<!-- How to create flexible designs that adapt to requirements -->
+
+### Extension Point Design
+
+<!-- Where and how to build extensibility into the system -->
+
+---
+
+# Implementation Notes
+
+<!-- Any project-specific notes about how these design principles should be applied
+     Exceptions or modifications to standard patterns
+     Team agreements about design trade-offs -->

package/packages/cli/resources/templates/design/freestyle.md

@@ -0,0 +1,37 @@
+<!--
+DESIGN DOCUMENT TEMPLATE - FREESTYLE APPROACH
+
+PURPOSE: Document design principles and standards in your preferred format.
+NOTE: Technology stack decisions belong in the Architecture Document, not here.
+
+DESIGN FOCUS AREAS:
+✅ Design principles and patterns that guide implementation
+✅ Naming conventions and coding standards
+✅ Component design approaches and boundaries
+✅ Data modeling and design principles
+✅ Quality attribute design strategies (performance, security, etc.)
+❌ NO Technology stack choices (goes in Architecture doc)
+❌ NO Concrete class names or implementations
+❌ NO Code snippets or method signatures
+
+TIERED APPROACH SUGGESTION:
+Start with core design principles, add complexity as project grows.
+Consider organizing by: Essential → Core → Advanced → Specialized sections.
+
+EXAMPLES:
+✅ GOOD: "Repository pattern abstracts data access with clean interfaces"
+✅ GOOD: "Components follow single responsibility principle with clear boundaries"
+✅ GOOD: "Error handling uses custom exception hierarchy for different failure types"
+❌ BAD: "PaymentController.processPayment() validates and processes transactions"
+❌ BAD: "UserService extends BaseService and implements AuthService interface"
+
+IMPORTANT: DO NOT REMOVE THIS COMMENT HOW TO USE THE TEMPLATE!
+-->
+
+# Design Document
+
+## Architecture Reference
+
+See [Architecture Document](./architecture.md) for high-level system context and architecture decisions such as chosen technologies and frameworks.
+
+<!-- Here goes your freestyle design -->

package/packages/cli/resources/templates/design/game.md

@@ -0,0 +1,66 @@
+# Game Design 🛠️
+
+**My Game**: [GAME_NAME]  
+**Platform**: [PLATFORM - from architecture.md]  
+**Date**: [DATE]
+
+---
+
+## What This Document Is For
+
+This document explains **HOW we organize and structure** the code for building the game.
+
+Think of it like a construction plan:
+
+- **Requirements** = What we're building
+- **Architecture** = The main parts and their jobs
+- **Design** (this doc) = How to organize the construction
+
+---
+
+## Core Concepts We'll Use
+
+<!-- LLM INSTRUCTION:
+Explain the 3-4 fundamental coding patterns the child will use repeatedly.
+Keep explanations simple and concrete. Use analogies.
+Platform-specific examples are good.
+
+Typical patterns:
+
+- State (Memory) 🧠
+- Mechanics (Rules) 📏
+- Presentation (Drawing) 🎨
+- The Game Loop 🔄
+
+-->
+
+## Usage of libraries
+
+<!--
+There are many libraries providing e. g. physics or other game specific features. Based on the requirements, pick proper libraries and explain to the child what they do.
+-->
+
+## 🗺️ How Code Is Organized
+
+<!-- LLM INSTRUCTION:
+Show the actual file/sprite structure for this specific game.
+Be concrete - list actual file names or sprite names.
+Explain WHAT goes in each file and WHY.
+
+IMPORTANT:
+- Maintain single responsibility principle!
+- Keep it object-oriented (one building block = one file)
+-->
+
+### File Structure for [PLATFORM]
+
+```
+[ACTUAL_FILE_STRUCTURE]
+
+Example for Browser/JavaScript:
+game/
+  ├── game.js       ← Game loop, manages everything
+  ├── player.js     ← Player class (state, mechanics, drawing)
+  ├── enemy.js      ← Enemy class
+  └── main.js       ← Starts the game
+```

package/packages/cli/resources/templates/design/none.md

@@ -0,0 +1,17 @@
+# Design Placeholder
+
+This is a placeholder document. The user has chosen not to maintain separate design documentation for this project.
+
+## INSTRUCTIONS FOR LLM
+
+**DO NOT EDIT THIS FILE**
+
+- Use the current development plan file to specify design decisions for ongoing development
+- Reference design information from the plan file context when needed
+- Focus design discussion in the plan file's "Key Decisions" and implementation task sections
+- When design decisions are needed, document them in the plan file rather than here
+- This placeholder ensures the workflow variables work correctly while respecting the user's choice
+
+## User's Choice
+
+The user has explicitly chosen not to use dedicated design documentation for this project. Please respect this decision and work with the plan file for design-related information.

package/packages/cli/resources/templates/requirements/ears.md

@@ -0,0 +1,90 @@
+<!--
+INSTRUCTIONS FOR REQUIREMENTS (EARS FORMAT):
+- Use EARS format
+- Number requirements as REQ-1, REQ-2, etc.
+- Keep user stories concise and focused on user value
+- Make acceptance criteria specific and testable
+- Reference requirements in tasks using: (_Requirements: REQ-1, REQ-3_)
+
+EXAMPLE:
+## REQ-1: User Authentication
+**User Story:** As a website visitor, I want to create an account so that I can access personalized features.
+
+**Acceptance Criteria:**
+- WHEN user provides valid email and password THEN the system SHALL create new account
+- WHEN user provides duplicate email THEN the system SHALL show "email already exists" error
+- WHEN user provides weak password THEN the system SHALL show password strength requirements
+
+FULL EARS SYNTAX:
+While <optional pre-condition>, when <optional trigger>, the <system name> shall <system response>
+
+The EARS ruleset states that a requirement must have: Zero or many preconditions; Zero or one trigger; One system name; One or many system responses.
+
+The application of the EARS notation produces requirements in a small number of patterns, depending on the clauses that are used. The patterns are illustrated below.
+
+Ubiquitous requirements
+Ubiquitous requirements are always active (so there is no EARS keyword)
+
+The <system name> shall <system response>
+
+Example: The mobile phone shall have a mass of less than XX grams.
+
+State driven requirements
+State driven requirements are active as long as the specified state remains true and are denoted by the keyword While.
+
+While <precondition(s)>, the <system name> shall <system response>
+
+Example: While there is no card in the ATM, the ATM shall display “insert card to begin”.
+
+Event driven requirements
+Event driven requirements specify how a system must respond when a triggering event occurs and are denoted by the keyword When.
+
+When <trigger>, the <system name> shall <system response>
+
+Example: When “mute” is selected, the laptop shall suppress all audio output.
+
+Optional feature requirements
+Optional feature requirements apply in products or systems that include the specified feature and are denoted by the keyword Where.
+
+Where <feature is included>, the <system name> shall <system response>
+
+Example: Where the car has a sunroof, the car shall have a sunroof control panel on the driver door.
+
+Unwanted behavior requirements
+Unwanted behavior requirements are used to specify the required system response to undesired situations and are denoted by the keywords If and Then.
+
+If <trigger>, then the <system name> shall <system response>
+
+Example: If an invalid credit card number is entered, then the website shall display “please re-enter credit card details”.
+
+Complex requirements
+The simple building blocks of the EARS patterns described above can be combined to specify requirements for richer system behavior. Requirements that include more than one EARS keyword are called Complex requirements.
+
+While <precondition(s)>, When <trigger>, the <system name> shall <system response>
+
+Example: While the aircraft is on ground, when reverse thrust is commanded, the engine control system shall enable reverse thrust.
+
+Complex requirements for unwanted behavior also include the If-Then keywords.
+-->
+
+# Requirements Document
+
+## REQ-1: [First Requirement Title]
+
+**User Story:** As a [user type], I want [goal] so that [benefit].
+
+**Acceptance Criteria:**
+
+- WHEN [condition] THEN the system SHALL [expected behavior]
+- WHEN [condition] THEN the system SHALL [expected behavior]
+
+## REQ-2: [Second Requirement Title]
+
+**User Story:** As a [user type], I want [goal] so that [benefit].
+
+**Acceptance Criteria:**
+
+- WHEN [condition] THEN the system SHALL [expected behavior]
+- WHEN [condition] THEN the system SHALL [expected behavior]
+
+<!-- Add more requirements as REQ-3, REQ-4, etc. -->

package/packages/cli/resources/templates/requirements/freestyle.md

@@ -0,0 +1,42 @@
+<!--
+INSTRUCTIONS FOR REQUIREMENTS (FREESTYLE):
+- Document user needs and system requirements in any format that works for your project
+- Consider using user stories, use cases, or functional specifications
+- Make requirements specific and testable
+- Number or organize requirements for easy reference
+- Focus on what the system should do, not how it should do it
+-->
+
+# Requirements Document
+
+## Functional Requirements
+
+<!-- What the system should do -->
+
+### [Requirement Category]
+
+<!-- Group related requirements together -->
+
+## Non-Functional Requirements
+
+<!-- Performance, security, usability, etc. -->
+
+### Performance
+
+<!-- Response times, throughput, scalability requirements -->
+
+### Security
+
+<!-- Authentication, authorization, data protection requirements -->
+
+### Usability
+
+<!-- User experience, accessibility requirements -->
+
+## Business Rules
+
+<!-- Constraints and rules that govern system behavior -->
+
+## Assumptions and Dependencies
+
+<!-- External dependencies and assumptions made -->

package/packages/cli/resources/templates/requirements/game.md

@@ -0,0 +1,162 @@
+# My Game Plan 🎮
+
+**My Name**: [YOUR_NAME]  
+**Today's Date**: [DATE]  
+**My Game**: [GAME_NAME]
+
+---
+
+## 🎯 Core Game Principle
+
+<!-- LLM INSTRUCTION:
+This section captures the ABSOLUTE MINIMUM game - the simplest possible version that's still fun.
+Think: "What's the ONE thing that makes this game special?"
+Example: For a space shooter: "Player shoots enemies that move toward them"
+Example: For a platformer: "Player jumps over gaps to reach the end"
+Keep it to ONE sentence that describes the core gameplay loop.
+-->
+
+**The Main Idea** (in one sentence):
+
+[CORE_GAME_MECHANIC] - e.g., "A player dodges falling objects and collects coins"
+
+**What Makes It Fun**:
+
+[WHY_IS_THIS_FUN] - e.g., "It's exciting to see how long you can survive!"
+
+**Game Type**: [e.g., Arcade, Platformer, Puzzle, Space Shooter]
+
+---
+
+## 🚀 Version 1: Let's Build This First!
+
+<!-- LLM INSTRUCTION:
+These are the MINIMUM features needed to make the core game principle playable.
+Aim for 3-5 SIMPLE features. Child should be able to build this in 1-2 sessions.
+Each feature should be testable and celebratable when complete.
+Use simple, action-oriented language kids understand.
+-->
+
+**Goal**: Make a playable game with just the basics!
+
+### Must-Have Features:
+
+**1. [FEATURE_1]** 🎮
+
+- Example: "Player can move left and right"
+- Why we need it: So you can control your character!
+
+**2. [FEATURE_2]** 🎯
+
+- Example: "Enemies appear at the top and move down"
+- Why we need it: Something to dodge or shoot!
+
+**3. [FEATURE_3]** ⭐
+
+- Example: "Score goes up when you collect coins"
+- Why we need it: To know how well you're doing!
+
+**4. [FEATURE_4]** 💥
+
+- Example: "Game over when player hits enemy"
+- Why we need it: Games need a win/lose condition!
+
+**5. [FEATURE_5]** 🔄
+
+- Example: "Restart button to play again"
+- Why we need it: So you can try to beat your score!
+
+### ✅ How We Know Version 1 is Done:
+
+- [ ] I can start the game and see my character
+- [ ] I can control my character with the keyboard
+- [ ] [MAIN_THING] works (e.g., "Enemies appear and move")
+- [ ] I can win OR lose the game
+- [ ] I can play again after game over
+
+**When Version 1 is done**: We have a REAL GAME! 🎉
+
+**New features can be added incrementally – just start a new conversation and explain them**
+
+---
+
+## 🚧 Not Building This now (And That's OK!)
+
+<!-- LLM INSTRUCTION:
+Be explicit about what's out of scope to manage expectations.
+Help child understand why some things are too complex for now.
+Always end on a positive note about what they ARE building.
+-->
+
+**Things We're NOT Building** (maybe later!):
+
+- ❌ [OUT_OF_SCOPE_1] - e.g., "Multiplayer" → Too complex! Let's master single-player first
+- ❌ [OUT_OF_SCOPE_2] - e.g., "3D graphics" → 2D is perfect for learning!
+- ❌ [OUT_OF_SCOPE_3] - e.g., "Mobile app" → Browser version is easier to share!
+
+**Why not?** These would take a LONG time and lots of advanced skills. What we're building is already AWESOME! 🌟
+
+---
+
+## 📋 Our Build Order
+
+**Phase 1**: Core Game Principle → Version 1  
+_"Get something playable!"_
+
+**Phase 2**: Add Level 2 Polish  
+_"Make it feel great!"_
+
+**Phase 3**: Add Level 3 Features  
+_"Add variety and depth!"_
+
+---
+
+## 💭 Notes & Ideas
+
+<!-- LLM INSTRUCTION:
+Use this space to capture the child's random ideas, inspirations, or decisions made during development.
+Keep their creativity documented even if ideas don't fit current version.
+-->
+
+**Cool Ideas We Thought Of**:
+
+- [IDEA_1]
+- [IDEA_2]
+- [IDEA_3]
+
+**Games That Inspired Us**:
+
+- [INSPIRATION_1]
+- [INSPIRATION_2]
+
+**Things We Learned**:
+
+- [LEARNING_1]
+- [LEARNING_2]
+
+---
+
+## 🎊 Celebration Log
+
+<!-- LLM INSTRUCTION:
+Document milestones and achievements. This builds confidence and tracks progress.
+Update this as features are completed.
+-->
+
+**What We've Built So Far**:
+
+- [ ] Version 1 Complete! (Date: **\_**) 🎉
+- [ ] Level 2 Complete! (Date: **\_**) 🌟
+- [ ] Level 3 Complete! (Date: **\_**) 🚀
+
+**My Proudest Moments**:
+
+1. [ACHIEVEMENT_1]
+2. [ACHIEVEMENT_2]
+3. [ACHIEVEMENT_3]
+
+---
+
+**Remember**: Every great game developer started exactly where you are now! 🌟
+
+Let's build something awesome together! 🚀

package/packages/cli/resources/templates/requirements/none.md

@@ -0,0 +1,17 @@
+# Requirements Placeholder
+
+This is a placeholder document. The user has chosen not to maintain separate requirements documentation for this project.
+
+## INSTRUCTIONS FOR LLM
+
+**DO NOT EDIT THIS FILE**
+
+- Use the current development plan file to specify requirements for ongoing development
+- Reference requirements from the plan file context when needed
+- Focus requirements discussion in the plan file's "Goal" and relevant task sections
+- When requirements clarification is needed, document them in the plan file rather than here
+- This placeholder ensures the workflow variables work correctly while respecting the user's choice
+
+## User's Choice
+
+The user has explicitly chosen not to use dedicated requirements documentation for this project. Please respect this decision and work with the plan file for requirements-related information.

package/packages/cli/resources/templates/skills/POWER.md

@@ -0,0 +1,23 @@
+---
+name: 'responsible-vibe'
+displayName: 'Responsible Vibe Development Workflows'
+description: >
+  Structured development workflows for AI-assisted coding. Provides guided 
+  phases for feature development, bug fixing, TDD, and more.
+keywords:
+  - 'development'
+  - 'workflow'
+  - 'feature'
+  - 'bug fix'
+  - 'TDD'
+  - 'test driven'
+  - 'refactor'
+  - 'planning'
+  - 'start development'
+  - 'new feature'
+license: MIT
+metadata:
+  version: '${VERSION}'
+  repository: https://github.com/mrsimpson/responsible-vibe-mcp
+  author: mrsimpson
+---

package/packages/cli/resources/templates/skills/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: responsible-vibe
+description: >
+  Structured development workflows for AI-assisted coding. Use when starting 
+  new features, fixing bugs, following TDD, refactoring code, or any development 
+  task that benefits from planning and structure. Activate it when 
+  users mention to build, enhance or fix code.
+license: MIT
+metadata:
+  version: '${VERSION}'
+  repository: https://github.com/mrsimpson/responsible-vibe-mcp
+  author: mrsimpson
+requires-mcp-servers:
+  - name: workflows
+    package: '@codemcp/workflows-server'
+    description: 'Structured development workflows for AI-assisted coding'
+    command: npx
+    args: ['-y', '@codemcp/workflows-server']
+---