@meltstudio/meltctl 1.4.0 → 1.6.0

package/README.md

@@ -43,14 +43,20 @@ After running `meltctl project init`, you get these commands in Cursor:
 ### Initialize a New Project
 
 ```bash
+# Auto-detect shell type
 meltctl project init
+
+# Specify shell type explicitly
+meltctl project init --shell sh    # for bash/zsh
+meltctl project init --shell ps    # for PowerShell
 ```
 
 This command:
-- Creates necessary directories
-- Installs Cursor command templates
+- Creates necessary directories using bundled templates
+- Installs Cursor command templates from organized template files
 - Sets up project structure for AI-assisted development
 - Supports both shell (sh/bash/zsh) and PowerShell environments
+- Uses fs-extra for robust file operations and template copying
 
 ### Update Project (Coming Soon)
 
@@ -60,29 +66,6 @@ meltctl project update
 
 Updates your project templates to the latest version.
 
-## 💡 Example Workflow
-
-1. **Plan Your Feature**
-   ```
-   # In Cursor, use:
-   /melt-plan
-   ```
-
-2. **Generate Tests**
-   ```
-   /melt-test-plan
-   ```
-
-3. **Implement**
-   ```
-   /melt-implement
-   ```
-
-4. **Create PR**
-   ```
-   /melt-pr
-   ```
-
 ## 🛠️ Requirements
 
 - Node.js 22+ (works with Node.js 18+ but 22+ recommended)
@@ -128,22 +111,20 @@ This tool is part of the Melt Development Process. For issues or contributions:
 - [GitHub Repository](https://github.com/MeltStudio/melt-development-prompts)
 - [Report Issues](https://github.com/MeltStudio/melt-development-prompts/issues)
 
-## 📦 What's Included
+## 🏛️ Template Architecture
 
-- Domain-driven development templates
-- React 2025 patterns and standards
-- TypeScript strict mode configurations
-- Comprehensive testing strategies
-- Accessibility compliance checks
-- Performance optimization patterns
+The CLI uses a bundled template system organized in:
 
-## ⚡ Benefits
+```
+packages/cli/templates/
+├── cursor-commands/     # All 8 Cursor AI command templates
+├── melt-memory/        # Project context templates with dynamic timestamps
+└── melt-scripts/       # Utility scripts for sh and PowerShell
+    ├── sh/            # Bash/zsh utility scripts
+    └── ps/            # PowerShell utility scripts
+```
 
-- **40% faster development** with AI assistance
-- **Consistent code quality** across teams
-- **Built-in best practices** and standards
-- **Systematic debugging** approach
-- **Streamlined PR process**
+Templates support dynamic content replacement (like timestamps) and are copied to your project during initialization.
 
 ## 📄 License
 

package/dist/commands/project/init.d.ts

@@ -1,6 +1,5 @@
 interface InitOptions {
-    shell?: 'sh' | 'ps';
-    force?: boolean;
+    shell?: 'sh' | 'ps' | 'auto';
 }
 export declare function initCommand(options?: InitOptions): Promise<void>;
 export {};

package/dist/commands/project/init.js

@@ -1,6 +1,7 @@
 import { intro, outro, select, confirm, spinner } from '@clack/prompts';
 import chalk from 'chalk';
-import { existsSync, mkdirSync, writeFileSync, readFileSync } from 'fs';
+import { existsSync, readFileSync } from 'fs';
+import fs from 'fs-extra';
 import { join, dirname } from 'path';
 import { platform } from 'os';
 import { fileURLToPath } from 'url';
@@ -19,7 +20,7 @@ export async function initCommand(options = {}) {
         existingPaths.push('.cursor/commands/');
     if (existsSync(meltDir))
         existingPaths.push('.melt/');
-    if (existingPaths.length > 0 && !options.force) {
+    if (existingPaths.length > 0) {
         console.log(chalk.yellow('⚠️  The following directories already exist:'));
         existingPaths.forEach(path => console.log(`   • ${path}`));
         console.log();
@@ -33,21 +34,26 @@ export async function initCommand(options = {}) {
     }
     // Shell selection (explicit, auto-detect, or interactive)
     let selectedShell;
-    if (options.shell) {
+    if (options.shell && options.shell !== 'auto') {
         selectedShell = options.shell;
     }
     else {
         // Auto-detect based on platform
         const defaultShell = platform() === 'win32' ? 'ps' : 'sh';
-        // Interactive selection with default
-        selectedShell = (await select({
-            message: 'Choose script type:',
-            options: [
-                { value: 'sh', label: SHELL_CHOICES.sh, hint: defaultShell === 'sh' ? 'default' : '' },
-                { value: 'ps', label: SHELL_CHOICES.ps, hint: defaultShell === 'ps' ? 'default' : '' },
-            ],
-            initialValue: defaultShell,
-        }));
+        if (options.shell === 'auto') {
+            selectedShell = defaultShell;
+        }
+        else {
+            // Interactive selection with default
+            selectedShell = (await select({
+                message: 'Choose script type:',
+                options: [
+                    { value: 'sh', label: SHELL_CHOICES.sh, hint: defaultShell === 'sh' ? 'default' : '' },
+                    { value: 'ps', label: SHELL_CHOICES.ps, hint: defaultShell === 'ps' ? 'default' : '' },
+                ],
+                initialValue: defaultShell,
+            }));
+        }
     }
     console.log(chalk.cyan(`Selected shell: ${SHELL_CHOICES[selectedShell]}`));
     console.log();
@@ -105,565 +111,49 @@ function createDirectoryStructure(baseDir, shell) {
     ];
     dirs.forEach(dir => {
         const fullPath = join(baseDir, dir);
-        mkdirSync(fullPath, { recursive: true });
+        fs.ensureDirSync(fullPath);
     });
 }
 async function copyTemplates(baseDir, shell) {
-    // For now, we'll create basic templates inline
-    // TODO: Copy from bundled templates directory
-    const cursorCommands = {
-        'melt-plan.md': getPlanTemplate(),
-        'melt-test-plan.md': getTestPlanTemplate(),
-        'melt-docs.md': getDocsTemplate(),
-        'melt-implement.md': getImplementTemplate(),
-        'melt-pr.md': getPrTemplate(),
-        'melt-review.md': getReviewTemplate(),
-        'melt-complete.md': getCompleteTemplate(),
-        'melt-debug.md': getDebugTemplate(),
-    };
-    for (const [filename, content] of Object.entries(cursorCommands)) {
-        const filePath = join(baseDir, '.cursor', 'commands', filename);
-        writeFileSync(filePath, content, 'utf8');
+    const __filename = fileURLToPath(import.meta.url);
+    const __dirname = dirname(__filename);
+    // In dist, we need to go back to the CLI package root and find templates (from dist/commands/project to CLI root)
+    const templatesDir = join(__dirname, '../../../templates');
+    // Copy cursor commands
+    const cursorCommandsTemplateDir = join(templatesDir, 'cursor-commands');
+    const cursorCommandsDestDir = join(baseDir, '.cursor', 'commands');
+    if (existsSync(cursorCommandsTemplateDir)) {
+        fs.copySync(cursorCommandsTemplateDir, cursorCommandsDestDir);
+    }
+    // Create initial context file from template
+    const contextTemplatePath = join(templatesDir, 'melt-memory', 'context.md');
+    const contextDestPath = join(baseDir, '.melt', 'memory', 'context.md');
+    if (existsSync(contextTemplatePath)) {
+        let contextContent = readFileSync(contextTemplatePath, 'utf8');
+        // Replace timestamp placeholders
+        const timestamp = new Date().toISOString();
+        contextContent = contextContent.replace(/{{timestamp}}/g, timestamp);
+        fs.writeFileSync(contextDestPath, contextContent, 'utf8');
     }
-    // Create initial context file
-    const contextPath = join(baseDir, '.melt', 'memory', 'context.md');
-    writeFileSync(contextPath, getInitialContext(), 'utf8');
-    // Create basic shell utility (cross-platform)
+    // Copy shell script from template
     const scriptExt = shell === 'ps' ? 'ps1' : 'sh';
-    const scriptPath = join(baseDir, '.melt', 'scripts', shell, `common.${scriptExt}`);
-    const scriptContent = shell === 'ps' ? getPowerShellCommon() : getBashCommon();
-    writeFileSync(scriptPath, scriptContent, 'utf8');
+    const scriptTemplatePath = join(templatesDir, 'melt-scripts', shell, `common.${scriptExt}`);
+    const scriptDestPath = join(baseDir, '.melt', 'scripts', shell, `common.${scriptExt}`);
+    if (existsSync(scriptTemplatePath)) {
+        fs.copySync(scriptTemplatePath, scriptDestPath);
+    }
 }
 function createVersionFile(meltDir) {
     const __filename = fileURLToPath(import.meta.url);
     const __dirname = dirname(__filename);
-    const packageJson = JSON.parse(readFileSync(join(__dirname, '../../package.json'), 'utf8'));
+    // In dist, we need to go back to the CLI package root (from dist/commands/project to CLI root)
+    const packageJsonPath = join(__dirname, '../../../package.json');
+    const packageJson = JSON.parse(readFileSync(packageJsonPath, 'utf8'));
     const versionData = {
         cliVersion: packageJson.version,
         initialized: new Date().toISOString(),
         lastUpdate: new Date().toISOString(),
     };
     const versionPath = join(meltDir, 'version.json');
-    writeFileSync(versionPath, JSON.stringify(versionData, null, 2), 'utf8');
-}
-// Template content functions
-function getImplementTemplate() {
-    return `---
-description: Execute implementation using Melt development standards and domain-driven architecture
----
-
-You are implementing a feature following Melt's domain-driven development process. Follow these steps:
-
-1. **Load Context**:
-   - Read \`.melt/memory/context.md\` for project context and requirements
-   - Check \`.melt/outputs/plans/\` for any existing implementation plans
-   - Review relevant domain structure in \`src/domains/\` if it exists
-
-2. **Architecture Compliance**:
-   - Follow React 2025 standards (functional components, hooks, TypeScript strict)
-   - Use domain-driven design with clear separation of concerns
-   - Implement server components by default, client components when needed
-   - Use Zod for all data validation
-   - Follow Tailwind CSS for styling
-
-3. **Implementation Process**:
-   - Create/update domain structures under \`src/domains/[domain]/\`
-   - Implement components in \`src/domains/[domain]/components/\`
-   - Add business logic in \`src/domains/[domain]/hooks/\` and \`src/domains/[domain]/services/\`
-   - Create types in \`src/domains/[domain]/types/\`
-   - Add tests in \`src/domains/[domain]/__tests__/\`
-
-4. **Quality Standards**:
-   - Ensure 80% test coverage minimum
-   - Use TypeScript strict mode
-   - Add proper JSDoc documentation
-   - Follow atomic commit principles
-   - No debugging code in commits
-
-5. **Documentation**:
-   - Update \`.melt/memory/context.md\` with implementation details
-   - Save implementation notes to \`.melt/outputs/implementations/[timestamp].md\`
-   - Update relevant README files if needed
-
-6. **Testing**:
-   - Write unit tests for all business logic
-   - Add integration tests for complex workflows
-   - Ensure all tests pass before completing
-
-Remember: Focus on clean, maintainable code that follows our established patterns and domain boundaries.`;
-}
-function getPlanTemplate() {
-    return `---
-description: Create implementation plan following Melt's domain-driven architecture standards
----
-
-Create a comprehensive implementation plan for the requested feature. Follow these steps:
-
-1. **Analyze Requirements**:
-   - Read \`.melt/memory/context.md\` for project context and constraints
-   - Identify the target domain(s) this feature belongs to
-   - Determine integration points with existing domains
-
-2. **Architecture Planning**:
-   - Design domain structure following our patterns:
-     \`\`\`
-     src/domains/[domain]/
-     ├── components/          # React components
-     ├── hooks/              # Custom hooks for business logic
-     ├── services/           # API calls and external integrations
-     ├── types/              # TypeScript types and Zod schemas
-     ├── utils/              # Domain-specific utilities
-     └── __tests__/          # Domain tests
-     \`\`\`
-   - Plan component hierarchy and state management
-   - Design data flow and API integration points
-
-3. **Technical Decisions**:
-   - Choose appropriate React patterns (server vs client components)
-   - Plan Zod schemas for data validation
-   - Design TypeScript interfaces and types
-   - Plan testing strategy (unit, integration, e2e)
-
-4. **Implementation Strategy**:
-   - Break down into atomic, testable units
-   - Identify dependencies and execution order
-   - Plan for error handling and edge cases
-   - Consider accessibility and performance requirements
-
-5. **Create Detailed Plan**:
-   - List specific files to create/modify
-   - Define component interfaces and props
-   - Specify API endpoints and data contracts
-   - Plan test cases and coverage targets
-
-6. **Save Planning Output**:
-   - Save comprehensive plan to \`.melt/outputs/plans/[timestamp]-plan.md\`
-   - Update \`.melt/memory/context.md\` with planning decisions
-   - Create task breakdown for implementation
-
-Focus on maintainable, testable code that follows our domain-driven architecture principles.`;
-}
-function getReviewTemplate() {
-    return `---
-description: Review code following Melt's quality standards and architecture compliance
----
-
-Perform a comprehensive code review following Melt's standards:
-
-1. **Architecture Review**:
-   - Verify domain-driven design compliance
-   - Check proper separation of concerns
-   - Validate component placement within domain structure
-   - Review data flow and state management patterns
-
-2. **Code Quality**:
-   - TypeScript strict mode compliance
-   - Proper error handling and edge cases
-   - Performance considerations (memo, useMemo, useCallback)
-   - Accessibility compliance (ARIA, semantic HTML)
-
-3. **Testing Coverage**:
-   - Unit tests for business logic (80% minimum)
-   - Integration tests for complex workflows
-   - Test quality and maintainability
-   - Mock strategies and test isolation
-
-4. **Documentation**:
-   - JSDoc comments for public APIs
-   - README updates for new features
-   - Architecture decision records when applicable
-   - Code comments for complex business logic
-
-5. **Security & Best Practices**:
-   - Input validation with Zod schemas
-   - XSS prevention in dynamic content
-   - Proper authentication/authorization patterns
-   - Environment variable usage
-
-6. **Review Output**:
-   - Document findings in \`.melt/outputs/reviews/[timestamp]-review.md\`
-   - Categorize issues by severity (critical, major, minor)
-   - Provide specific recommendations and examples
-   - Update \`.melt/memory/context.md\` with lessons learned
-
-Focus on constructive feedback that improves code quality and team knowledge.`;
-}
-function getDebugTemplate() {
-    return `---
-description: Debug issues using systematic approach and Melt development patterns
----
-
-Debug the issue systematically following our structured approach:
-
-1. **Issue Analysis**:
-   - Document the problem clearly in \`.melt/memory/context.md\`
-   - Identify affected domains and components
-   - Gather error messages, stack traces, and reproduction steps
-   - Check recent changes in \`.melt/outputs/implementations/\`
-
-2. **Domain-Specific Debugging**:
-   - Review component hierarchy and props flow
-   - Check custom hooks for state management issues
-   - Validate service layer API calls and data transformation
-   - Examine TypeScript types and Zod schema validation
-
-3. **Tool-Assisted Debugging**:
-   - Use React DevTools for component inspection
-   - Leverage TypeScript compiler for type checking
-   - Check browser console for runtime errors
-   - Use network tab for API debugging
-
-4. **Testing & Validation**:
-   - Run existing tests to identify regression
-   - Write minimal reproduction test case
-   - Check test coverage for the affected area
-   - Validate fix with comprehensive testing
-
-5. **Root Cause Analysis**:
-   - Document the underlying cause
-   - Identify if it's architectural, implementation, or configuration
-   - Check if similar issues exist elsewhere
-   - Plan preventive measures
-
-6. **Resolution Documentation**:
-   - Save debug session to \`.melt/outputs/implementations/[timestamp]-debug.md\`
-   - Update context with lessons learned
-   - Document any architectural improvements needed
-   - Share findings with team if applicable
-
-Remember: Focus on understanding the problem deeply before implementing solutions.`;
-}
-function getInitialContext() {
-    return `# Project Context
-
-## Project Overview
-This project uses Melt's development standards with domain-driven architecture.
-
-## Architecture Principles
-- **Domain-Driven Design**: Code organized by business domains
-- **React 2025 Standards**: Functional components, hooks, TypeScript strict
-- **Type Safety**: Zod schemas for runtime validation
-- **Testing**: 80% coverage minimum with comprehensive test strategies
-
-## Development Workflow
-1. **Plan**: Create implementation plans in \`.melt/outputs/plans/\`
-2. **Implement**: Follow domain architecture patterns
-3. **Review**: Ensure quality and compliance
-4. **Debug**: Systematic problem-solving approach
-
-## Current Status
-- Initialized: ${new Date().toISOString()}
-- Last Updated: ${new Date().toISOString()}
-
-## Notes
-Update this file as the project evolves to maintain context for AI assistants and team members.
-`;
-}
-function getBashCommon() {
-    return `#!/usr/bin/env bash
-# Common utilities for Melt development workflow
-
-# Get project root directory
-get_project_root() {
-    git rev-parse --show-toplevel 2>/dev/null || pwd
-}
-
-# Get current timestamp for file naming
-get_timestamp() {
-    date '+%Y%m%d-%H%M%S'
-}
-
-# Check if .melt directory exists
-check_melt_workspace() {
-    if [[ ! -d ".melt" ]]; then
-        echo "ERROR: .melt workspace not found. Run 'meltctl project init' first."
-        exit 1
-    fi
-}
-
-# Create output file with timestamp
-create_output_file() {
-    local category="$1"
-    local name="$2"
-    local timestamp=$(get_timestamp)
-    local filename="\${timestamp}-\${name}.md"
-    local filepath=".melt/outputs/\${category}/\${filename}"
-
-    mkdir -p ".melt/outputs/\${category}"
-    echo "$filepath"
-}
-
-# Update context file with new information
-update_context() {
-    local message="$1"
-    local timestamp=$(date -Iseconds)
-
-    echo "## Update: $timestamp" >> .melt/memory/context.md
-    echo "$message" >> .melt/memory/context.md
-    echo "" >> .melt/memory/context.md
-}
-
-echo "Melt development utilities loaded."
-`;
-}
-function getPowerShellCommon() {
-    return `#!/usr/bin/env pwsh
-# Common utilities for Melt development workflow
-
-function Get-ProjectRoot {
-    try {
-        git rev-parse --show-toplevel
-    }
-    catch {
-        Get-Location
-    }
-}
-
-function Get-Timestamp {
-    Get-Date -Format "yyyyMMdd-HHmmss"
-}
-
-function Test-MeltWorkspace {
-    if (-not (Test-Path ".melt" -PathType Container)) {
-        Write-Error "ERROR: .melt workspace not found. Run 'meltctl project init' first."
-        exit 1
-    }
-}
-
-function New-OutputFile {
-    param(
-        [string]$Category,
-        [string]$Name
-    )
-
-    $timestamp = Get-Timestamp
-    $filename = "$timestamp-$Name.md"
-    $filepath = ".melt/outputs/$Category/$filename"
-
-    New-Item -Path ".melt/outputs/$Category" -ItemType Directory -Force | Out-Null
-    return $filepath
-}
-
-function Update-Context {
-    param([string]$Message)
-
-    $timestamp = Get-Date -Format "yyyy-MM-ddTHH:mm:ssK"
-
-    Add-Content -Path ".melt/memory/context.md" -Value "## Update: $timestamp"
-    Add-Content -Path ".melt/memory/context.md" -Value $Message
-    Add-Content -Path ".melt/memory/context.md" -Value ""
-}
-
-Write-Output "Melt development utilities loaded."
-`;
-}
-function getTestPlanTemplate() {
-    return `---
-description: Generate comprehensive test strategy and test files based on implementation plan
----
-
-Create a comprehensive testing strategy and generate test files following Melt's testing standards:
-
-1. **Load Implementation Context**:
-   - Read \`.melt/outputs/plans/\` for the current implementation plan
-   - Review \`.melt/memory/context.md\` for project testing patterns
-   - Analyze existing test files in \`src/domains/[domain]/__tests__/\`
-
-2. **Test Strategy Design**:
-   - **Unit Tests**: Test individual components, hooks, and utilities
-   - **Integration Tests**: Test component interactions and data flow
-   - **API Tests**: Test service layer and external integrations
-   - **Accessibility Tests**: Ensure WCAG compliance
-   - **Performance Tests**: Validate rendering and interaction performance
-
-3. **Test File Generation**:
-   - Create test files following domain structure:
-     \`\`\`
-     src/domains/[domain]/__tests__/
-     ├── components/          # Component tests
-     ├── hooks/              # Hook tests
-     ├── services/           # Service/API tests
-     └── utils/              # Utility function tests
-     \`\`\`
-   - Use React Testing Library for component tests
-   - Use @testing-library/react-hooks for hook tests
-   - Mock external dependencies appropriately
-
-4. **Testing Patterns**:
-   - Follow TDD approach - write tests before implementation
-   - Test behavior, not implementation details
-   - Use meaningful test descriptions and organize with describe blocks
-   - Include edge cases and error scenarios
-   - Ensure accessibility testing with @testing-library/jest-dom
-
-5. **Test Coverage Strategy**:
-   - Target 80% minimum coverage for new code
-   - Focus on critical business logic and user flows
-   - Test error handling and edge cases
-   - Validate prop types and component contracts
-
-6. **Save Test Plan**:
-   - Document test strategy in \`.melt/outputs/plans/[timestamp]-test-plan.md\`
-   - Create test files in appropriate domain directories
-   - Update \`.melt/memory/context.md\` with testing decisions
-
-Focus on creating comprehensive, maintainable tests that validate both functionality and user experience.`;
-}
-function getDocsTemplate() {
-    return `---
-description: Update project documentation and README based on implementation changes
----
-
-Update project documentation to reflect implementation changes and maintain accuracy:
-
-1. **Analyze Changes**:
-   - Review recent implementation in \`.melt/outputs/implementations/\`
-   - Check \`.melt/outputs/plans/\` for planned changes
-   - Identify new features, APIs, or architectural changes
-   - Review \`.melt/memory/context.md\` for context
-
-2. **Documentation Updates**:
-   - **README.md**: Update installation, usage, and examples
-   - **API Documentation**: Document new endpoints or changed interfaces
-   - **Component Documentation**: Add JSDoc comments and usage examples
-   - **Architecture Docs**: Update domain structure if changed
-   - **Deployment Docs**: Update if new environment variables or configs added
-
-3. **Documentation Patterns**:
-   - Use clear, concise language focused on developers
-   - Include code examples for new features
-   - Document breaking changes and migration steps
-   - Add troubleshooting sections for common issues
-   - Include links to relevant domain documentation
-
-4. **Code Documentation**:
-   - Add/update JSDoc comments for public APIs
-   - Document complex business logic with inline comments
-   - Update TypeScript interfaces with proper descriptions
-   - Ensure prop types are documented for components
-
-5. **Validation**:
-   - Verify all links work correctly
-   - Test code examples to ensure they're accurate
-   - Check that documentation matches actual implementation
-   - Ensure consistent formatting and style
-
-6. **Save Documentation Updates**:
-   - Update relevant documentation files
-   - Save documentation notes to \`.melt/outputs/implementations/[timestamp]-docs.md\`
-   - Update \`.melt/memory/context.md\` with documentation decisions
-
-Focus on keeping documentation current, accurate, and developer-focused.`;
-}
-function getPrTemplate() {
-    return `---
-description: Create comprehensive pull request with proper description and metadata
----
-
-Create a detailed pull request following Melt's standards for code review and deployment:
-
-1. **Gather Context**:
-   - Read \`.melt/outputs/plans/\` for implementation plan details
-   - Review \`.melt/outputs/implementations/\` for implementation notes
-   - Check \`.melt/memory/context.md\` for project context
-   - Identify related Linear story and RFC references
-
-2. **PR Description Structure**:
-   - **Summary**: Brief description of what was implemented
-   - **Changes**: Bulleted list of specific changes made
-   - **Testing**: How the changes were tested (unit, integration, manual)
-   - **Screenshots**: For UI changes, include before/after images
-   - **Linear Story**: Link to Linear story and requirements
-   - **RFC Reference**: Link to relevant RFC section if applicable
-
-3. **PR Metadata**:
-   - Add appropriate labels (feature, bugfix, docs, etc.)
-   - Assign reviewers based on affected domains
-   - Set milestone if applicable
-   - Link to related issues or PRs
-
-4. **Code Review Preparation**:
-   - Ensure all tests pass
-   - Run linting and type checking
-   - Verify accessibility compliance
-   - Check performance impact
-   - Validate security considerations
-
-5. **Deployment Readiness**:
-   - Document any environment variable changes
-   - Note database migration requirements
-   - Include feature flag configurations
-   - Specify rollback procedures if needed
-
-6. **Quality Checklist**:
-   - [ ] Code follows domain architecture patterns
-   - [ ] Tests have adequate coverage (80%+)
-   - [ ] Documentation updated
-   - [ ] No debugging code committed
-   - [ ] TypeScript strict mode compliance
-   - [ ] Performance considerations addressed
-
-7. **Save PR Information**:
-   - Create PR with comprehensive description
-   - Save PR details to \`.melt/outputs/implementations/[timestamp]-pr.md\`
-   - Update \`.melt/memory/context.md\` with PR status
-
-Focus on clear communication and thorough preparation for efficient code review.`;
-}
-function getCompleteTemplate() {
-    return `---
-description: Complete story implementation, handle deployment, and update Linear status
----
-
-Complete the story implementation and handle all post-development tasks:
-
-1. **Verify Completion**:
-   - Read \`.melt/outputs/plans/\` to check all planned tasks completed
-   - Review \`.melt/outputs/implementations/\` for implementation status
-   - Ensure all tests pass and coverage targets met
-   - Verify documentation is updated and accurate
-
-2. **Linear Story Update**:
-   - Update Linear story status to "Ready for Review" or "Complete"
-   - Add implementation notes and links to PR
-   - Update story with actual effort vs. estimated effort
-   - Link any follow-up stories or technical debt identified
-
-3. **Deployment Process**:
-   - Verify PR is approved and merged
-   - Monitor deployment pipeline for success
-   - Validate feature works in staging/production
-   - Check monitoring and logging for any issues
-
-4. **Feature Validation**:
-   - Test feature functionality end-to-end
-   - Verify acceptance criteria are fully met
-   - Check performance metrics if applicable
-   - Validate accessibility compliance
-
-5. **Documentation & Handoff**:
-   - Ensure user-facing documentation is updated
-   - Share feature with stakeholders if needed
-   - Document any lessons learned or technical debt
-   - Update architectural decision records if applicable
-
-6. **Cleanup Tasks**:
-   - Remove feature flags if no longer needed
-   - Archive implementation planning materials
-   - Update project roadmap or backlog
-   - Share knowledge with team members
-
-7. **Post-Completion Analysis**:
-   - Document actual vs. estimated effort
-   - Note any process improvements identified
-   - Record architectural patterns that worked well
-   - Identify any technical debt for future sprints
-
-8. **Save Completion Records**:
-   - Update Linear story with final status and notes
-   - Save completion summary to \`.melt/outputs/implementations/[timestamp]-complete.md\`
-   - Update \`.melt/memory/context.md\` with completion details
-   - Archive relevant planning and implementation files
-
-Focus on thorough validation and knowledge capture for continuous improvement.`;
+    fs.writeFileSync(versionPath, JSON.stringify(versionData, null, 2), 'utf8');
 }

package/dist/index.js

@@ -21,7 +21,15 @@ const projectCommand = program
 projectCommand
     .command('init')
     .description('Initialize project with Melt development tools')
-    .action(initCommand);
+    .option('--shell <type>', 'specify shell type (sh|ps)', 'auto')
+    .action(options => {
+    // Validate shell option
+    const validShells = ['sh', 'ps', 'auto'];
+    const shell = validShells.includes(options.shell)
+        ? options.shell
+        : 'auto';
+    return initCommand({ shell });
+});
 projectCommand
     .command('update')
     .description('Update project configurations to latest version')

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@meltstudio/meltctl",
-  "version": "1.4.0",
+  "version": "1.6.0",
   "description": "CLI tool for Melt development process automation - initialize and update project configurations",
   "main": "dist/index.js",
   "type": "module",
@@ -19,7 +19,7 @@
   },
   "scripts": {
     "build": "tsc",
-    "dev": "tsx watch src/index.ts",
+    "dev": "tsx src/index.ts",
     "start": "node dist/index.js",
     "clean": "rm -rf dist",
     "lint": "eslint src/**/*.ts",

package/templates/cursor-commands/melt-complete.md

@@ -0,0 +1,55 @@
+---
+description: Complete story implementation, handle deployment, and update Linear status
+---
+
+Complete the story implementation and handle all post-development tasks:
+
+1. **Verify Completion**:
+   - Read `.melt/outputs/plans/` to check all planned tasks completed
+   - Review `.melt/outputs/implementations/` for implementation status
+   - Ensure all tests pass and coverage targets met
+   - Verify documentation is updated and accurate
+
+2. **Linear Story Update**:
+   - Update Linear story status to "Ready for Review" or "Complete"
+   - Add implementation notes and links to PR
+   - Update story with actual effort vs. estimated effort
+   - Link any follow-up stories or technical debt identified
+
+3. **Deployment Process**:
+   - Verify PR is approved and merged
+   - Monitor deployment pipeline for success
+   - Validate feature works in staging/production
+   - Check monitoring and logging for any issues
+
+4. **Feature Validation**:
+   - Test feature functionality end-to-end
+   - Verify acceptance criteria are fully met
+   - Check performance metrics if applicable
+   - Validate accessibility compliance
+
+5. **Documentation & Handoff**:
+   - Ensure user-facing documentation is updated
+   - Share feature with stakeholders if needed
+   - Document any lessons learned or technical debt
+   - Update architectural decision records if applicable
+
+6. **Cleanup Tasks**:
+   - Remove feature flags if no longer needed
+   - Archive implementation planning materials
+   - Update project roadmap or backlog
+   - Share knowledge with team members
+
+7. **Post-Completion Analysis**:
+   - Document actual vs. estimated effort
+   - Note any process improvements identified
+   - Record architectural patterns that worked well
+   - Identify any technical debt for future sprints
+
+8. **Save Completion Records**:
+   - Update Linear story with final status and notes
+   - Save completion summary to `.melt/outputs/implementations/[timestamp]-complete.md`
+   - Update `.melt/memory/context.md` with completion details
+   - Archive relevant planning and implementation files
+
+Focus on thorough validation and knowledge capture for continuous improvement.

package/templates/cursor-commands/melt-docs.md

@@ -0,0 +1,44 @@
+---
+description: Update project documentation and README based on implementation changes
+---
+
+Update project documentation to reflect implementation changes and maintain accuracy:
+
+1. **Analyze Changes**:
+   - Review recent implementation in `.melt/outputs/implementations/`
+   - Check `.melt/outputs/plans/` for planned changes
+   - Identify new features, APIs, or architectural changes
+   - Review `.melt/memory/context.md` for context
+
+2. **Documentation Updates**:
+   - **README.md**: Update installation, usage, and examples
+   - **API Documentation**: Document new endpoints or changed interfaces
+   - **Component Documentation**: Add JSDoc comments and usage examples
+   - **Architecture Docs**: Update domain structure if changed
+   - **Deployment Docs**: Update if new environment variables or configs added
+
+3. **Documentation Patterns**:
+   - Use clear, concise language focused on developers
+   - Include code examples for new features
+   - Document breaking changes and migration steps
+   - Add troubleshooting sections for common issues
+   - Include links to relevant domain documentation
+
+4. **Code Documentation**:
+   - Add/update JSDoc comments for public APIs
+   - Document complex business logic with inline comments
+   - Update TypeScript interfaces with proper descriptions
+   - Ensure prop types are documented for components
+
+5. **Validation**:
+   - Verify all links work correctly
+   - Test code examples to ensure they're accurate
+   - Check that documentation matches actual implementation
+   - Ensure consistent formatting and style
+
+6. **Save Documentation Updates**:
+   - Update relevant documentation files
+   - Save documentation notes to `.melt/outputs/implementations/[timestamp]-docs.md`
+   - Update `.melt/memory/context.md` with documentation decisions
+
+Focus on keeping documentation current, accurate, and developer-focused.

package/templates/cursor-commands/melt-pr.md

@@ -0,0 +1,53 @@
+---
+description: Create comprehensive pull request with proper description and metadata
+---
+
+Create a detailed pull request following Melt's standards for code review and deployment:
+
+1. **Gather Context**:
+   - Read `.melt/outputs/plans/` for implementation plan details
+   - Review `.melt/outputs/implementations/` for implementation notes
+   - Check `.melt/memory/context.md` for project context
+   - Identify related Linear story and RFC references
+
+2. **PR Description Structure**:
+   - **Summary**: Brief description of what was implemented
+   - **Changes**: Bulleted list of specific changes made
+   - **Testing**: How the changes were tested (unit, integration, manual)
+   - **Screenshots**: For UI changes, include before/after images
+   - **Linear Story**: Link to Linear story and requirements
+   - **RFC Reference**: Link to relevant RFC section if applicable
+
+3. **PR Metadata**:
+   - Add appropriate labels (feature, bugfix, docs, etc.)
+   - Assign reviewers based on affected domains
+   - Set milestone if applicable
+   - Link to related issues or PRs
+
+4. **Code Review Preparation**:
+   - Ensure all tests pass
+   - Run linting and type checking
+   - Verify accessibility compliance
+   - Check performance impact
+   - Validate security considerations
+
+5. **Deployment Readiness**:
+   - Document any environment variable changes
+   - Note database migration requirements
+   - Include feature flag configurations
+   - Specify rollback procedures if needed
+
+6. **Quality Checklist**:
+   - [ ] Code follows domain architecture patterns
+   - [ ] Tests have adequate coverage (80%+)
+   - [ ] Documentation updated
+   - [ ] No debugging code committed
+   - [ ] TypeScript strict mode compliance
+   - [ ] Performance considerations addressed
+
+7. **Save PR Information**:
+   - Create PR with comprehensive description
+   - Save PR details to `.melt/outputs/implementations/[timestamp]-pr.md`
+   - Update `.melt/memory/context.md` with PR status
+
+Focus on clear communication and thorough preparation for efficient code review.

package/templates/cursor-commands/melt-test-plan.md

@@ -0,0 +1,50 @@
+---
+description: Generate comprehensive test strategy and test files based on implementation plan
+---
+
+Create a comprehensive testing strategy and generate test files following Melt's testing standards:
+
+1. **Load Implementation Context**:
+   - Read `.melt/outputs/plans/` for the current implementation plan
+   - Review `.melt/memory/context.md` for project testing patterns
+   - Analyze existing test files in `src/domains/[domain]/__tests__/`
+
+2. **Test Strategy Design**:
+   - **Unit Tests**: Test individual components, hooks, and utilities
+   - **Integration Tests**: Test component interactions and data flow
+   - **API Tests**: Test service layer and external integrations
+   - **Accessibility Tests**: Ensure WCAG compliance
+   - **Performance Tests**: Validate rendering and interaction performance
+
+3. **Test File Generation**:
+   - Create test files following domain structure:
+     ```
+     src/domains/[domain]/__tests__/
+     ├── components/          # Component tests
+     ├── hooks/              # Hook tests
+     ├── services/           # Service/API tests
+     └── utils/              # Utility function tests
+     ```
+   - Use React Testing Library for component tests
+   - Use @testing-library/react-hooks for hook tests
+   - Mock external dependencies appropriately
+
+4. **Testing Patterns**:
+   - Follow TDD approach - write tests before implementation
+   - Test behavior, not implementation details
+   - Use meaningful test descriptions and organize with describe blocks
+   - Include edge cases and error scenarios
+   - Ensure accessibility testing with @testing-library/jest-dom
+
+5. **Test Coverage Strategy**:
+   - Target 80% minimum coverage for new code
+   - Focus on critical business logic and user flows
+   - Test error handling and edge cases
+   - Validate prop types and component contracts
+
+6. **Save Test Plan**:
+   - Document test strategy in `.melt/outputs/plans/[timestamp]-test-plan.md`
+   - Create test files in appropriate domain directories
+   - Update `.melt/memory/context.md` with testing decisions
+
+Focus on creating comprehensive, maintainable tests that validate both functionality and user experience.

package/templates/melt-memory/context.md

@@ -0,0 +1,23 @@
+# Project Context
+
+## Project Overview
+This project uses Melt's development standards with domain-driven architecture.
+
+## Architecture Principles
+- **Domain-Driven Design**: Code organized by business domains
+- **React 2025 Standards**: Functional components, hooks, TypeScript strict
+- **Type Safety**: Zod schemas for runtime validation
+- **Testing**: 80% coverage minimum with comprehensive test strategies
+
+## Development Workflow
+1. **Plan**: Create implementation plans in `.melt/outputs/plans/`
+2. **Implement**: Follow domain architecture patterns
+3. **Review**: Ensure quality and compliance
+4. **Debug**: Systematic problem-solving approach
+
+## Current Status
+- Initialized: {{timestamp}}
+- Last Updated: {{timestamp}}
+
+## Notes
+Update this file as the project evolves to maintain context for AI assistants and team members.

package/templates/melt-scripts/ps/common.ps1

@@ -0,0 +1,48 @@
+#!/usr/bin/env pwsh
+# Common utilities for Melt development workflow
+
+function Get-ProjectRoot {
+    try {
+        git rev-parse --show-toplevel
+    }
+    catch {
+        Get-Location
+    }
+}
+
+function Get-Timestamp {
+    Get-Date -Format "yyyyMMdd-HHmmss"
+}
+
+function Test-MeltWorkspace {
+    if (-not (Test-Path ".melt" -PathType Container)) {
+        Write-Error "ERROR: .melt workspace not found. Run 'meltctl project init' first."
+        exit 1
+    }
+}
+
+function New-OutputFile {
+    param(
+        [string]$Category,
+        [string]$Name
+    )
+
+    $timestamp = Get-Timestamp
+    $filename = "$timestamp-$Name.md"
+    $filepath = ".melt/outputs/$Category/$filename"
+
+    New-Item -Path ".melt/outputs/$Category" -ItemType Directory -Force | Out-Null
+    return $filepath
+}
+
+function Update-Context {
+    param([string]$Message)
+
+    $timestamp = Get-Date -Format "yyyy-MM-ddTHH:mm:ssK"
+
+    Add-Content -Path ".melt/memory/context.md" -Value "## Update: $timestamp"
+    Add-Content -Path ".melt/memory/context.md" -Value $Message
+    Add-Content -Path ".melt/memory/context.md" -Value ""
+}
+
+Write-Output "Melt development utilities loaded."

package/templates/melt-scripts/sh/common.sh

@@ -0,0 +1,44 @@
+#!/usr/bin/env bash
+# Common utilities for Melt development workflow
+
+# Get project root directory
+get_project_root() {
+    git rev-parse --show-toplevel 2>/dev/null || pwd
+}
+
+# Get current timestamp for file naming
+get_timestamp() {
+    date '+%Y%m%d-%H%M%S'
+}
+
+# Check if .melt directory exists
+check_melt_workspace() {
+    if [[ ! -d ".melt" ]]; then
+        echo "ERROR: .melt workspace not found. Run 'meltctl project init' first."
+        exit 1
+    fi
+}
+
+# Create output file with timestamp
+create_output_file() {
+    local category="$1"
+    local name="$2"
+    local timestamp=$(get_timestamp)
+    local filename="${timestamp}-${name}.md"
+    local filepath=".melt/outputs/${category}/${filename}"
+
+    mkdir -p ".melt/outputs/${category}"
+    echo "$filepath"
+}
+
+# Update context file with new information
+update_context() {
+    local message="$1"
+    local timestamp=$(date -Iseconds)
+
+    echo "## Update: $timestamp" >> .melt/memory/context.md
+    echo "$message" >> .melt/memory/context.md
+    echo "" >> .melt/memory/context.md
+}
+
+echo "Melt development utilities loaded."

package/templates/cursor-commands/plan.md

@@ -1,49 +0,0 @@
----
-description: Create implementation plan following Melt's domain-driven architecture standards
----
-
-Create a comprehensive implementation plan for the requested feature. Follow these steps:
-
-1. **Analyze Requirements**:
-   - Read `.melt/memory/context.md` for project context and constraints
-   - Identify the target domain(s) this feature belongs to
-   - Determine integration points with existing domains
-
-2. **Architecture Planning**:
-   - Design domain structure following our patterns:
-     ```
-     src/domains/[domain]/
-     ├── components/          # React components
-     ├── hooks/              # Custom hooks for business logic
-     ├── services/           # API calls and external integrations
-     ├── types/              # TypeScript types and Zod schemas
-     ├── utils/              # Domain-specific utilities
-     └── __tests__/          # Domain tests
-     ```
-   - Plan component hierarchy and state management
-   - Design data flow and API integration points
-
-3. **Technical Decisions**:
-   - Choose appropriate React patterns (server vs client components)
-   - Plan Zod schemas for data validation
-   - Design TypeScript interfaces and types
-   - Plan testing strategy (unit, integration, e2e)
-
-4. **Implementation Strategy**:
-   - Break down into atomic, testable units
-   - Identify dependencies and execution order
-   - Plan for error handling and edge cases
-   - Consider accessibility and performance requirements
-
-5. **Create Detailed Plan**:
-   - List specific files to create/modify
-   - Define component interfaces and props
-   - Specify API endpoints and data contracts
-   - Plan test cases and coverage targets
-
-6. **Save Planning Output**:
-   - Save comprehensive plan to `.melt/outputs/plans/[timestamp]-plan.md`
-   - Update `.melt/memory/context.md` with planning decisions
-   - Create task breakdown for implementation
-
-Focus on maintainable, testable code that follows our domain-driven architecture principles.