@codemcp/workflows 5.2.4 → 6.0.1

package/packages/docs/.vitepress/dist/workflows/epcc.yaml

@@ -0,0 +1,183 @@
+# yaml-language-server: $schema=../state-machine-schema.json
+---
+name: 'epcc'
+description: "A comprehensive development workflow based on Anthropic's best practices: Explore, Plan, Code, Commit - ideal for smaller features and iterative development"
+initial_state: 'explore'
+
+# Enhanced metadata for better discoverability
+metadata:
+  domain: 'code'
+  complexity: 'medium'
+  bestFor:
+    - 'Medium-sized features'
+    - 'Iterative development'
+    - 'Research-heavy tasks'
+    - 'Exploratory coding'
+  useCases:
+    - 'Adding a new API endpoint'
+    - 'Implementing a new algorithm'
+    - 'Integrating a third-party service'
+  examples:
+    - 'Add user profile management'
+    - 'Implement search functionality'
+    - 'Create data export feature'
+
+# States with default instructions and transitions
+states:
+  explore:
+    description: 'Research and exploration phase - understanding the problem space'
+    default_instructions: |
+      Research the codebase to understand existing patterns and gather context about the problem space.
+
+      - If uncertain about conventions or rules, ask the user about them
+      - Read relevant files and documentation
+      - If `$REQUIREMENTS_DOC` exists: Understand and document requirements there
+      - Otherwise: Document requirements in your task management system
+
+      Focus on understanding without writing code yet. Document your findings and create tasks as needed.
+    transitions:
+      - trigger: 'exploration_complete'
+        to: 'plan'
+        additional_instructions: 'Present the plan to the user, describing the impact of the changes.'
+        transition_reason: 'Sufficient understanding gained, ready to create implementation plan'
+
+  plan:
+    description: 'Planning phase - creating a detailed implementation strategy'
+    default_instructions: |
+      Create a detailed implementation strategy based on your exploration:
+
+      - If `$REQUIREMENTS_DOC` exists: Base your strategy on requirements from it
+      - Otherwise: Use existing task context
+
+      Break down the work into specific, actionable tasks. Consider edge cases, dependencies, and potential challenges.
+
+      - If architectural changes needed and `$ARCHITECTURE_DOC` exists: Document in `$ARCHITECTURE_DOC`
+      - Otherwise: Create tasks to track architectural decisions
+
+      - If `$DESIGN_DOC` exists: Adhere to the design in it
+      - Otherwise: Elaborate design options and present them to the user
+
+      Document the planning work thoroughly and create implementation tasks as part of the code phase as needed.
+    transitions:
+      - trigger: 'need_more_exploration'
+        to: 'explore'
+        additional_instructions: 'Focus on the specific areas that need clarification and ask the user about needs and preferences.'
+        transition_reason: 'Planning work revealed need for more exploration'
+
+      - trigger: 'plan_complete'
+        to: 'code'
+        transition_reason: 'Implementation plan is complete and ready for coding'
+        review_perspectives:
+          - perspective: 'architect'
+            prompt: 'Review implementation strategy, design decisions, and integration approach for soundness and maintainability. Ensure the plan aligns with existing system architecture and follows best practices.'
+          - perspective: 'security_expert'
+            prompt: 'Assess security considerations and potential risks in the planned implementation approach. Review data handling, authentication, and potential vulnerabilities.'
+
+      - trigger: 'abandon_feature'
+        to: 'explore'
+        instructions: >
+          Feature development abandoned during planning. Return to exploration state for new tasks.
+          Task history will remain for future reference.
+        additional_instructions: 'Feature development abandoned during planning. Clean up any planning work and prepare for new tasks.'
+        transition_reason: 'User decided to abandon feature during planning phase'
+
+  code:
+    description: 'Implementation phase - writing and building the solution'
+    default_instructions: |
+      Follow your plan to build the solution:
+
+      - If `$DESIGN_DOC` exists: Follow the design from it
+      - Otherwise: Elaborate design options and present them to the user
+      - If `$ARCHITECTURE_DOC` exists: Build according to the architecture from it
+      - Otherwise: Elaborate architectural options and present them to the user
+      - If `$REQUIREMENTS_DOC` exists: Ensure requirements from it are met
+      - Otherwise: Ensure existing requirements are met based on your task context
+
+      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:
+      - trigger: 'need_replanning'
+        to: 'plan'
+        additional_instructions: "Consider what you've learned during coding and adjust the plan accordingly. Document the changes and reasons."
+        transition_reason: 'Implementation work revealed need to revise the plan'
+
+      - trigger: 'need_more_exploration'
+        to: 'explore'
+        additional_instructions: 'Focus on the specific areas that are blocking implementation progress.'
+        transition_reason: 'Implementation work revealed need for more exploration'
+
+      - trigger: 'code_complete'
+        to: 'commit'
+        transition_reason: 'Core implementation is complete, ready for finalization'
+        review_perspectives:
+          - perspective: 'senior_software_developer'
+            prompt: 'Review code quality, best practices, testing coverage, and readiness for production deployment. Ensure the implementation follows coding standards and is maintainable.'
+          - perspective: 'performance_engineer'
+            prompt: 'Evaluate performance impact, resource efficiency, and scalability of the implemented solution. Check for potential bottlenecks or optimization opportunities.'
+
+      - trigger: 'abandon_feature'
+        to: 'explore'
+        instructions: >
+          Feature development abandoned during implementation. Clean up any incomplete code and return to exploration.
+          Task history and any completed work will remain for future reference.
+        additional_instructions: 'Clean up any incomplete code and prepare for new tasks.'
+        transition_reason: 'User decided to abandon feature during implementation'
+
+  commit:
+    description: 'Code cleanup and documentation finalization'
+    default_instructions: >
+      Ensure code quality and documentation accuracy through systematic cleanup and review.
+
+      **STEP 1: Code Cleanup**
+
+      Systematically clean up development artifacts:
+
+      1. **Remove Debug Output**: Search for and remove all temporary debug output statements used during development.
+         Look for language-specific debug output methods (console logging, print statements, debug output functions).
+         Remove any debugging statements that were added for development purposes.
+
+      2. **Review TODO/FIXME Comments**:
+         - Address each TODO/FIXME comment by either implementing the solution or documenting why it's deferred
+         - Remove completed TODOs
+         - Convert remaining TODOs to proper issue tracking if needed
+
+      3. **Remove Debugging Code Blocks**:
+         - Remove temporary debugging code, test code blocks, and commented-out code
+         - Clean up any experimental code that's no longer needed
+         - Ensure proper error handling replaces temporary debug logging
+
+      **STEP 2: Documentation Review**
+
+      Review and update documentation to reflect final implementation:
+
+      1. **Update Long-Term Memory Documents**: Based on what was actually implemented:
+         - If `$REQUIREMENTS_DOC` exists: Update it if requirements changed during development
+         - If `$ARCHITECTURE_DOC` exists: Update it if architectural impacts were identified
+         - If `$DESIGN_DOC` exists: Update it if design details were refined or changed
+         - Otherwise: Document any changes in the plan file
+      2. **Compare Against Implementation**: Review documentation against actual implemented functionality
+      3. **Update Changed Sections**: Only modify documentation sections that have functional changes
+      4. **Remove Development Progress**: Remove references to development iterations, progress notes, and temporary decisions
+      5. **Focus on Final State**: Ensure documentation describes the final implemented state, not the development process
+      6. **Ask User to Review Document Updates**
+
+      **STEP 3: Final Validation**
+
+      - Run existing tests to ensure cleanup didn't break functionality
+      - Verify documentation accuracy with a final review
+      - Ensure code is ready for production/delivery
+
+      Update task progress and mark completed work as you finalize the feature.
+    transitions:
+      - trigger: 'need_code_changes'
+        to: 'code'
+        additional_instructions: 'Focus on the problems identified during final review.'
+        transition_reason: 'Final review found issues requiring code changes'
+
+      - trigger: 'commit_complete'
+        to: 'explore'
+        transition_reason: 'Feature delivery complete, ready for next task'
+
+      - trigger: 'abandon_feature'
+        to: 'explore'
+        additional_instructions: 'Clean up any finalization artifacts and prepare for new tasks.'
+        transition_reason: 'User decided to abandon feature during finalization'

package/packages/docs/.vitepress/dist/workflows/game-beginner.html

@@ -0,0 +1,26 @@
+<!DOCTYPE html>
+<html lang="en-US" dir="ltr">
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width,initial-scale=1">
+    <title>Responsible Vibe MCP</title>
+    <meta name="description" content="Model Context Protocol server for intelligent conversation state management and development guidance">
+    <meta name="generator" content="VitePress v1.6.4">
+    <link rel="preload stylesheet" href="/responsible-vibe-mcp/assets/style.CAgdBzOq.css" as="style">
+    <link rel="preload stylesheet" href="/responsible-vibe-mcp/vp-icons.css" as="style">
+    
+    <script type="module" src="/responsible-vibe-mcp/assets/app.Dz3lZH3M.js"></script>
+    <link rel="preload" href="/responsible-vibe-mcp/assets/inter-roman-latin.Di8DUHzh.woff2" as="font" type="font/woff2" crossorigin="">
+    <link rel="modulepreload" href="/responsible-vibe-mcp/assets/chunks/theme.q5Ewb3F1.js">
+    <link rel="modulepreload" href="/responsible-vibe-mcp/assets/chunks/framework.DZS7lpav.js">
+    <link rel="modulepreload" href="/responsible-vibe-mcp/assets/workflows_game-beginner.md.CNxzWLtd.lean.js">
+    <link rel="icon" href="/responsible-vibe-mcp/favicon.ico">
+    <script id="check-dark-mode">(()=>{const e=localStorage.getItem("vitepress-theme-appearance")||"auto",a=window.matchMedia("(prefers-color-scheme: dark)").matches;(!e||e==="auto"?a:e==="dark")&&document.documentElement.classList.add("dark")})();</script>
+    <script id="check-mac-os">document.documentElement.classList.toggle("mac",/Mac|iPhone|iPod|iPad/i.test(navigator.platform));</script>
+  </head>
+  <body>
+    <div id="app"><div style="position:relative;" data-v-c1df4d5c><div><div id="workflow-visualizer-app" class="" data-v-b5ec7de4><!----><main class="app-main"><div class="diagram-container"><div id="diagram-canvas" class="diagram-canvas"><div class="loading-message">Loading workflow...</div></div></div><aside class="side-panel"><div class="side-panel-header"><h2>Details</h2></div><div class="side-panel-content"><div class="empty-state"> Click on a state or transition to see details </div></div></aside></main><div id="error-container" class="error-container hidden"><div class="error-message"><span class="error-text"></span><button class="error-close">×</button></div></div></div></div></div></div>
+    <script>window.__VP_HASH_MAP__=JSON.parse("{\"dev_architecture.md\":\"da_vFDwM\",\"dev_development.md\":\"DWl9cccE\",\"dev_logging.md\":\"BebvbW7z\",\"dev_publishing.md\":\"CQqbiIOF\",\"index.md\":\"D6ROLohf\",\"user_advanced-engineering.md\":\"MkETYNtq\",\"user_agent-setup.md\":\"B54OLL2H\",\"user_beads-integration.md\":\"BzdR5Fif\",\"user_crowd-mcp-integration.md\":\"C15kSdIJ\",\"user_custom-workflows.md\":\"Cz4IYCXa\",\"user_git-commit-feature.md\":\"UcTvDR-O\",\"user_how-it-works.md\":\"DiOXNgaL\",\"user_long-term-memory.md\":\"DZh0tjNa\",\"user_packaged-workflows.md\":\"s1HT89ZU\",\"user_tutorial.md\":\"Dmj8zLB2\",\"user_workflow-selection.md\":\"CrPGw9Hr\",\"workflows.md\":\"Bm5sGt3u\",\"workflows_adr.md\":\"DEaXkbRp\",\"workflows_big-bang-conversion.md\":\"BA5R1LxZ\",\"workflows_boundary-testing.md\":\"DBcYnMhx\",\"workflows_bugfix.md\":\"CZRCL0Hp\",\"workflows_business-analysis.md\":\"fGLml8Hw\",\"workflows_c4-analysis.md\":\"Dnssqzuf\",\"workflows_epcc.md\":\"M6DnIhpp\",\"workflows_game-beginner.md\":\"CNxzWLtd\",\"workflows_greenfield.md\":\"vx_g-WOe\",\"workflows_minor.md\":\"DdnfwMf4\",\"workflows_posts.md\":\"SOldXvq7\",\"workflows_sdd-bugfix-crowd.md\":\"-lSf42gJ\",\"workflows_sdd-bugfix.md\":\"oRAsEVbc\",\"workflows_sdd-feature-crowd.md\":\"DAtnfCAd\",\"workflows_sdd-feature.md\":\"Ce3-H_g3\",\"workflows_sdd-greenfield-crowd.md\":\"8DUvcmLe\",\"workflows_sdd-greenfield.md\":\"eEN6U0J4\",\"workflows_slides.md\":\"Cqt-19_1\",\"workflows_tdd.md\":\"BjVC69tu\",\"workflows_waterfall.md\":\"CL6jTZP9\"}");window.__VP_SITE_DATA__=JSON.parse("{\"lang\":\"en-US\",\"dir\":\"ltr\",\"title\":\"Responsible Vibe MCP\",\"description\":\"Model Context Protocol server for intelligent conversation state management and development guidance\",\"base\":\"/responsible-vibe-mcp/\",\"head\":[],\"router\":{\"prefetchLinks\":true},\"appearance\":true,\"themeConfig\":{\"nav\":[{\"text\":\"Documentation\",\"link\":\"/\"},{\"text\":\"Workflows\",\"link\":\"/workflows\"},{\"text\":\"Github\",\"link\":\"https://github.com/mrsimpson/responsible-vibe-mcp\"}],\"sidebar\":[{\"text\":\"User Guide\",\"items\":[{\"text\":\"Overview\",\"link\":\"/\"},{\"text\":\"How It Works\",\"link\":\"/user/how-it-works\"},{\"text\":\"Agent Setup\",\"link\":\"/user/agent-setup\"},{\"text\":\"Vibe Engineering\",\"link\":\"/user/advanced-engineering\"},{\"text\":\"Long-Term Memory\",\"link\":\"/user/long-term-memory\"},{\"text\":\"Beads-Integration\",\"link\":\"/user/beads-integration\"},{\"text\":\"Tutorial\",\"link\":\"/user/tutorial\"}]},{\"text\":\"Workflows\",\"items\":[{\"text\":\"Workflow-Selection\",\"link\":\"/user/workflow-selection\"},{\"text\":\"Packaged Workflows\",\"link\":\"/user/packaged-workflows\"},{\"text\":\"Custom Workflows\",\"link\":\"/user/custom-workflows\"},{\"text\":\"Explore All Workflows\",\"link\":\"/workflows\"},{\"text\":\"Crowd MCP Integration\",\"link\":\"/user/crowd-mcp-integration\"}]}]},\"locales\":{},\"scrollOffset\":134,\"cleanUrls\":false}");</script>
+    
+  </body>
+</html>

package/packages/docs/.vitepress/dist/workflows/game-beginner.yaml

@@ -0,0 +1,434 @@
+# yaml-language-server: $schema=../../state-machine-schema.json
+---
+name: 'game'
+description: 'Educational game development workflow for children (ages 8-12): Learn to build games step-by-step with guidance, frequent reviews, explanations, and fun!'
+initial_state: 'constitution'
+
+# Enhanced metadata for better discoverability
+metadata:
+  domain: 'children'
+  complexity: 'medium'
+  bestFor:
+    - 'Children learning game development'
+    - 'First-time game creators (ages 8-12)'
+    - 'Educational game projects'
+    - 'Learning programming through games'
+  useCases:
+    - 'Building your first video game'
+    - 'Learning game development concepts'
+    - 'Creating simple 2D games'
+  examples:
+    - 'Build a space shooter game'
+    - 'Create a platformer game'
+    - 'Make a simple puzzle game'
+  requiresDocumentation: true
+
+# States with default instructions and transitions
+states:
+  constitution:
+    description: 'Set up project documentation with game development principles'
+    default_instructions: |
+      **STEP 1: Check for Existing Documentation**
+
+      Verify whether project documentation exists in `.vibe/docs/`:
+      - `requirements.md`
+      - `architecture.md`
+      - `design.md`
+
+      **Conditional Actions:**
+      - If documentation exists: Skip ahead to imagine phase (the child already understands the importance of notes)
+      - If documentation missing: Proceed to set up documents
+
+      **STEP 2: Create Project Documentation (REQUIRED)**
+
+      Call `setup_project_docs()` with these parameters:
+
+      ```
+      setup_project_docs({
+        requirements: "game-requirements",
+        architecture: "game-architecture",
+        design: "game-design"
+      })
+      ```
+
+      This creates three child-friendly documents in `.vibe/docs/`:
+      - `requirements.md` - Game development principles and what we're building
+      - `architecture.md` - Platform choice and code structure
+      - `design.md` - Features and how to implement them
+
+      **These documents are your long-term memory for this project!**
+
+      **STEP 3: Explain the Helper Documents**
+
+      After calling `setup_project_docs()`, explain what was created:
+
+      "Hi! I'm so excited to help you build your first game! 🎮
+
+      I just created three special helper documents for us. Think of them like a smart notebook
+      that remembers everything we decide while building your game!
+
+      - **Game Development Principles** - Our rules for making awesome games! Like: Start small, test often, and celebrate every win!
+      - **Game Architecture** - Where we'll write down HOW to build your game (what platform to use, how to organize the code)
+      - **Game Design** - Our plan for WHAT features to create and in what order
+
+      These documents are like our game's memory! Every time we make an important decision,
+      we'll write it down so we never forget. 🧠
+
+      Ready to start dreaming up your game idea?"
+
+      **STEP 4: Verify Understanding**
+
+      Ask: "Do you understand what these helper documents are for? Any questions before we start?"
+
+      Wait for the child's response. Answer any questions patiently. Only proceed when they're ready.
+
+      **Guidelines:**
+      - Keep explanations simple and enthusiastic
+      - Use the analogy of a "smart notebook" or "game's memory"
+      - Avoid technical details about templates or file structure
+      - Focus on WHY we have documents (to remember decisions)
+
+    transitions:
+      - trigger: 'docs_ready'
+        to: 'imagine'
+        additional_instructions: |
+          Translate all created documents completely into the children's language
+        transition_reason: 'Project documentation initialized, ready to imagine the game'
+
+  imagine:
+    description: 'Dream phase - describe the game you want to create'
+    default_instructions: |
+      **STEP 1: Gather Game Ideas**
+
+      Ask the child to describe their game using open-ended questions:
+      - "What kind of game do you want to make?"
+      - "What does the player do in your game?"
+      - "What makes it fun?"
+      - "What games do you like that are similar?"
+
+      **STEP 2: Apply "Start Small, Dream Big" Principle**
+
+      When they describe complex concepts (like "Minecraft" or "Fortnite"):
+      - Respond: "That's an AMAZING idea!"
+      - Guide them: "Big games like that are built in small pieces. What's the ONE most fun thing in your game?"
+      - Refocus: "Let's build that part first, then add more later!"
+
+      **STEP 3: Document the Game Idea**
+
+      Update `$REQUIREMENTS_DOC` with:
+      - Game concept and type
+      - Main goal
+      - What makes it fun
+      - Version 1 features (3-5 simple features)
+      - Future ideas (complex features for later)
+
+      **STEP 4: Confirm Understanding**
+
+      Summarize back to the child:
+
+      "So you want to build a game where [summarize their idea]. That sounds AWESOME!
+      For Version 1, let's build: [list 3-5 simple features]."
+
+      Ask: "Did I understand your idea correctly? Is there anything else you want to tell me
+      about your game before we figure out HOW to build it?"
+
+      Wait for confirmation. Adjust if needed. Only proceed when they're happy with the plan.
+
+    transitions:
+      - trigger: 'idea_captured'
+        to: 'architecture'
+        additional_instructions: |
+          Awesome game idea! 🌟
+          Now let's figure out WHERE and HOW we'll build it!
+        transition_reason: 'Game idea documented in requirements, ready for technical planning'
+
+  architecture:
+    description: 'Choose platform and design the technical structure'
+    default_instructions: |
+      **STEP 1: Understand Game Concept**
+
+      Read `$REQUIREMENTS_DOC` to understand the game concept and features.
+
+      **STEP 2: Choose the Platform**
+
+      Ask the child: "Where do you want to play your game?"
+      - "In a web browser?" → HTML5/JavaScript
+      - "As a program on your computer?" → Python/Pygame
+
+      Explain each option in simple terms:
+      - **Browser**: Write code, works anywhere, more visual control
+      - **Python**: Desktop game, requires Python knowledge
+
+      **STEP 3: Update Architecture Documentation**
+
+      Document in `$ARCHITECTURE_DOC`:
+      - Platform decision and why
+      - Main game components (Player, Enemy, Game Manager, etc.)
+      - Simple ASCII diagram showing component connections
+      - OOP concepts explained simply (classes as blueprints)
+      - File organization for chosen platform
+      - State/Mechanics/Presentation separation
+
+      **STEP 4: Set Up Development Environment**
+
+      Configure quality tools based on platform choice:
+
+      **For HTML5/JavaScript:**
+      - Install ESLint, Prettier, Husky
+      - Configure scripts in package.json
+
+      **For Python:**
+      - Create virtual environment
+      - Install Ruff
+
+      **STEP 5: Explain Platform Architecture to Child**
+
+      "I figured out HOW we'll build your game!
+
+      We're using [PLATFORM] because [REASON].
+
+      Your game will have these main parts:
+      - [COMPONENT_1] - like [SIMPLE_ANALOGY]
+      - [COMPONENT_2] - like [SIMPLE_ANALOGY]
+      - [COMPONENT_3] - like [SIMPLE_ANALOGY]
+
+      I also set up helper tools that check your code automatically - like spell-check for code!"
+
+      **STEP 6: Verify Understanding**
+
+      Ask: "Does that make sense? Do you understand how these pieces will work together?
+      Any questions before we plan out WHAT features to build?"
+
+      Wait for confirmation before proceeding.
+
+    transitions:
+      - trigger: 'architecture_complete'
+        to: 'design'
+        additional_instructions: |
+          Great! We have set the foundation for your game! 🏗️
+          Now let's plan out how we're going to build it!
+        transition_reason: 'Technical architecture complete, ready for detailed design'
+
+  design:
+    description: 'Plan features and implementation strategy'
+    default_instructions: |
+      **STEP 1: Review Requirements and Architecture**
+
+      Read `$REQUIREMENTS_DOC` and `$ARCHITECTURE_DOC` to understand what we're building and the technical foundation.
+
+      **STEP 2: Select Libraries and Dependencies**
+
+      Choose appropriate libraries based on requirements (e.g., physics engines, platformer frameworks).
+
+      Document in `$DESIGN_DOC`:
+      - Which libraries will be used
+      - Why each library was chosen
+
+      **STEP 3: Design Major Features**
+
+      Update `$DESIGN_DOC` with detailed designs for each major feature:
+      - What it does (from player perspective)
+      - How it works (technical implementation)
+      - State/Mechanics/Presentation separation
+
+      **IMPORTANT: Create file structures (single responsibility) without writing full code yet!**
+
+      **STEP 4: Explain Technology Choices to Child**
+
+      "We've selected the technologies we'll use to build your game.
+
+      This might sound technical, but as you gain experience, picking the right tools gets easier!
+      I've helped you make these decisions because my creator shared what works best for beginners like you.
+
+      You can review the design.md in the `.vibe/docs` folder to see what we picked and why."
+
+      **STEP 5: Verify Understanding**
+
+      Wait for the child's confirmation before proceeding to implementation.
+
+    transitions:
+      - trigger: 'design_complete'
+        to: 'code'
+        additional_instructions: |
+          Perfect! We have our plan! 🎯
+          We'll be doing this step by step: After each major part we built, we will review it together to make sure you understand everything!
+        transition_reason: 'Detailed design complete, ready to implement'
+
+  code:
+    description: 'Build the game incrementally with frequent reviews'
+    default_instructions: |
+      **STEP 1: Follow Implementation Plan**
+
+      Use `$DESIGN_DOC` for implementation order and `$ARCHITECTURE_DOC` for code structure.
+
+      **STEP 2: Build One Feature at a Time**
+
+      Implement features incrementally, testing each one thoroughly before moving to the next.
+
+      **CRITICAL: Transition to review phase after completing each major feature**
+
+      Call `proceed_to_phase('review')` after each completed task from the plan.
+    transitions:
+      - trigger: 'feature_complete'
+        to: 'review'
+        additional_instructions: |
+          Feature complete! Let's review what we just built! 🎉
+        transition_reason: 'Major feature completed, time for incremental review'
+
+      - trigger: 'game_complete'
+        to: 'celebrate'
+        additional_instructions: |
+          The entire game is done! Time to celebrate! 🎊
+        transition_reason: 'All features complete, game is finished'
+
+  review:
+    description: 'Review and understand what was just built'
+    default_instructions: |
+      **STEP 1: Summarize the Feature**
+
+      Describe the completed feature in one sentence:
+      - "We just added player movement!"
+      - "We just made enemies appear and move!"
+      - "We just added collision detection!"
+
+      **STEP 2: Show Key Code Changes**
+
+      Highlight 2-3 key parts of the code and explain each clearly. Encourage the child to open their code editor and follow along.
+
+      Example explanation:
+
+      "Let me show you the important parts of what we just built:
+
+      1. **Keyboard Listener** - This is like a sensor that detects when you press arrow keys
+         [Show the code]
+
+      2. **Movement Logic** - This changes the player's position when keys are pressed
+         [Show the code]
+
+      3. **Boundary Check** - This keeps the player from going off the screen
+         [Show the code]"
+
+      Use simple analogies to explain concepts:
+      - Event listeners = sensors
+      - Variables = boxes that store information
+      - Functions = recipes that do specific jobs
+      - Classes = blueprints or instruction manuals
+
+      **STEP 3: Demonstrate the Feature**
+
+      Run the game and show the new feature working:
+      "Let's test it! Try pressing the arrow keys..."
+
+      **STEP 4: Celebrate the Achievement**
+
+      Encourage the child: "You just built [FEATURE]! That's a real game programming skill! 🌟"
+
+      **STEP 5: Check Understanding**
+
+      Ask: "Do you understand how this works? Want me to explain any part again?"
+
+      Wait for response and answer questions patiently.
+
+      **STEP 6: Plan Next Steps**
+
+      Ask: "Ready to build the next feature? Or do you need a break?"
+
+      **Conditional Next Actions:**
+      - If ready to continue: Transition to 'code' with 'continue_coding' trigger
+      - If game is complete: Transition to 'celebrate' with 'game_complete' trigger
+
+    transitions:
+      - trigger: 'continue_coding'
+        to: 'code'
+        additional_instructions: |
+          Great! Let's build the next feature! 🚀
+        transition_reason: 'Child understands current feature, ready to continue'
+        review_perspectives:
+          - perspective: 'quiz-master'
+            prompt: |
+              You are a friendly quiz master helping a child explore and understand their code!
+
+              Ask 2-3 exploratory questions that make them FIND things in the code:
+
+              **Good Questions (make them explore):**
+              - "Can you find the line where we check if the spacebar was pressed? What does it say?"
+              - "Look for the variable that holds the player's score. What's it called?"
+              - "Find the Enemy class - what happens when an enemy reaches the bottom of the screen?"
+              - "Can you spot where we draw the player on the screen? Show me that function!"
+
+              **Bad Questions (too abstract):**
+              - ❌ "What is a variable?"
+              - ❌ "Explain object-oriented programming"
+              - ❌ "What does this function return?"
+
+              **Important:**
+              - Make it a treasure hunt, not a test!
+              - If they can't find it, give hints: "Look in the Player class..."
+              - Celebrate when they find it: "Yes! That's it! 🎉"
+              - The goal is active code exploration, not memorization
+              - Keep it fun and encouraging!
+
+      - trigger: 'game_complete'
+        to: 'celebrate'
+        additional_instructions: |
+          All features are done! Time for the final celebration! 🎊
+        transition_reason: 'All features complete and understood'
+
+  celebrate:
+    description: 'Celebrate the completed game and reflect on learning'
+    default_instructions: |
+      **STEP 1: Play the Complete Game**
+
+      Celebrate with the child: "Let's play your finished game together! You built this!"
+
+      Let them play and enjoy their creation.
+
+      **STEP 2: Celebrate the Achievement**
+
+      Be enthusiastic and genuinely celebrate their work:
+
+      "You just built a REAL game! You're a game developer now! 🌟
+
+      Think about everything you learned:
+      - How to plan a game
+      - How to organize code (classes, state, mechanics, presentation)
+      - How to make things move on screen
+      - How to detect collisions
+      - How to add scoring and game rules
+
+      That's AMAZING! Many adults don't know how to do this!"
+
+      **STEP 3: Reflect on Learning**
+
+      Ask the child:
+      - "What was the hardest part of building this game?"
+      - "What was the most fun part?"
+      - "What are you most proud of?"
+
+      **STEP 4: Explore Future Ideas**
+
+      Ask: "Now that you've built Version 1, what would you want to add next?"
+
+      Review the "Future Ideas" list from `$REQUIREMENTS_DOC`.
+
+      **STEP 5: Document the Achievement**
+
+      Update the plan file with:
+      - Game completion date
+      - What was learned
+      - What the child wants to build next
+      - Any notes for future sessions
+
+      **STEP 6: Encourage Next Steps**
+
+      "You can keep building on this game, or start a new one!
+      You now have the skills to make ANY simple game you can imagine!"
+
+      **Congratulations, young game developer! 🚀**
+
+    transitions:
+      - trigger: 'enhance_game'
+        to: 'imagine'
+        additional_instructions: |
+          copy the development plan to a new file. Also move the existing conversation in .vibe to .vibe/archive
+        transition_reason: 'Adding features to existing game'