@meltstudio/meltctl 1.1.0

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

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

package/dist/commands/project/init.js

@@ -0,0 +1,665 @@
+import { intro, outro, select, confirm, spinner } from '@clack/prompts';
+import chalk from 'chalk';
+import { existsSync, mkdirSync, writeFileSync, readFileSync } from 'fs';
+import { join, dirname } from 'path';
+import { platform } from 'os';
+import { fileURLToPath } from 'url';
+const SHELL_CHOICES = {
+    sh: 'POSIX Shell (bash/zsh)',
+    ps: 'PowerShell',
+};
+export async function initCommand(options = {}) {
+    intro(chalk.blue('🚀 Melt Project - Initialize'));
+    const currentDir = process.cwd();
+    // Check if directories already exist
+    const cursorDir = join(currentDir, '.cursor', 'commands');
+    const meltDir = join(currentDir, '.melt');
+    const existingPaths = [];
+    if (existsSync(cursorDir))
+        existingPaths.push('.cursor/commands/');
+    if (existsSync(meltDir))
+        existingPaths.push('.melt/');
+    if (existingPaths.length > 0 && !options.force) {
+        console.log(chalk.yellow('⚠️  The following directories already exist:'));
+        existingPaths.forEach(path => console.log(`   • ${path}`));
+        console.log();
+        const shouldContinue = await confirm({
+            message: 'Do you want to continue? This may overwrite existing files.',
+        });
+        if (!shouldContinue) {
+            outro(chalk.gray('Operation cancelled.'));
+            return;
+        }
+    }
+    // Shell selection (explicit, auto-detect, or interactive)
+    let selectedShell;
+    if (options.shell) {
+        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,
+        }));
+    }
+    console.log(chalk.cyan(`Selected shell: ${SHELL_CHOICES[selectedShell]}`));
+    console.log();
+    const s = spinner();
+    s.start('Setting up Melt development workspace...');
+    try {
+        // Create directory structures
+        createDirectoryStructure(currentDir, selectedShell);
+        // Copy templates
+        await copyTemplates(currentDir, selectedShell);
+        // Create version file
+        createVersionFile(meltDir);
+        s.stop('✅ Workspace setup complete!');
+        console.log();
+        console.log(chalk.green('🎉 Melt development workspace initialized!'));
+        console.log();
+        console.log('Created directories:');
+        console.log(`  • ${chalk.cyan('.cursor/commands/')}`);
+        console.log(`  • ${chalk.cyan('.melt/memory/')}`);
+        console.log(`  • ${chalk.cyan('.melt/outputs/plans/')}`);
+        console.log(`  • ${chalk.cyan('.melt/outputs/implementations/')}`);
+        console.log(`  • ${chalk.cyan('.melt/outputs/reviews/')}`);
+        console.log(`  • ${chalk.cyan('.melt/scripts/' + selectedShell + '/')}`);
+        console.log(`  • ${chalk.cyan('.melt/templates/')}`);
+        console.log();
+        console.log('Next steps:');
+        console.log('  1. Start using Cursor commands:');
+        console.log(`     • ${chalk.cyan('/melt-implement')} - Execute implementation with Melt standards`);
+        console.log(`     • ${chalk.cyan('/melt-plan')} - Create implementation plans`);
+        console.log(`     • ${chalk.cyan('/melt-review')} - Review code with domain architecture`);
+        console.log(`     • ${chalk.cyan('/melt-debug')} - Debug issues systematically`);
+        console.log('  2. Customize templates in .melt/templates/');
+        console.log(`  3. Use utility scripts in .melt/scripts/${selectedShell}/`);
+        outro(chalk.green('Happy coding with Melt! 🚀'));
+    }
+    catch (error) {
+        s.stop('❌ Setup failed');
+        console.error(chalk.red('Error during setup:'), error);
+        process.exit(1);
+    }
+}
+function createDirectoryStructure(baseDir, shell) {
+    const dirs = [
+        '.cursor/commands',
+        '.melt/memory',
+        '.melt/outputs/plans',
+        '.melt/outputs/implementations',
+        '.melt/outputs/reviews',
+        `.melt/scripts/${shell}`,
+        '.melt/templates',
+    ];
+    dirs.forEach(dir => {
+        const fullPath = join(baseDir, dir);
+        mkdirSync(fullPath, { recursive: true });
+    });
+}
+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');
+    }
+    // Create initial context file
+    const contextPath = join(baseDir, '.melt', 'memory', 'context.md');
+    writeFileSync(contextPath, getInitialContext(), 'utf8');
+    // Create basic shell utility (cross-platform)
+    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');
+}
+function createVersionFile(meltDir) {
+    const __filename = fileURLToPath(import.meta.url);
+    const __dirname = dirname(__filename);
+    const packageJson = JSON.parse(readFileSync(join(__dirname, '../../package.json'), '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.`;
+}

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

@@ -0,0 +1 @@
+export declare function updateCommand(): Promise<void>;

package/dist/commands/project/update.js

@@ -0,0 +1,15 @@
+import { intro, outro } from '@clack/prompts';
+import chalk from 'chalk';
+export async function updateCommand() {
+    intro(chalk.blue('🔄 Melt Project - Update'));
+    console.log(chalk.yellow('⏳ Coming soon!'));
+    console.log();
+    console.log('This command will:');
+    console.log('• Check for CLI package updates');
+    console.log('• Update .cursor/commands/ with latest prompts');
+    console.log('• Migrate .melt/ workspace if needed');
+    console.log('• Handle version compatibility');
+    console.log();
+    console.log(chalk.gray('Usage: meltctl project update'));
+    outro(chalk.green('Stay tuned for the full implementation!'));
+}

package/dist/index.d.ts

@@ -0,0 +1,2 @@
+#!/usr/bin/env node
+export {};

package/dist/index.js

@@ -0,0 +1,22 @@
+#!/usr/bin/env node
+import { Command } from '@commander-js/extra-typings';
+import { initCommand } from './commands/project/init.js';
+import { updateCommand } from './commands/project/update.js';
+const program = new Command();
+program
+    .name('meltctl')
+    .description('CLI tool for Melt development process automation')
+    .version('0.1.0');
+// Project management commands
+const projectCommand = program
+    .command('project')
+    .description('Project setup and management commands');
+projectCommand
+    .command('init')
+    .description('Initialize project with Melt development tools')
+    .action(initCommand);
+projectCommand
+    .command('update')
+    .description('Update project configurations to latest version')
+    .action(updateCommand);
+program.parse(process.argv);

package/package.json

@@ -0,0 +1,65 @@
+{
+  "name": "@meltstudio/meltctl",
+  "version": "1.1.0",
+  "description": "CLI tool for Melt development process automation - initialize and update project configurations",
+  "main": "dist/index.js",
+  "type": "module",
+  "bin": {
+    "meltctl": "dist/index.js"
+  },
+  "files": [
+    "dist/**/*",
+    "templates/**/*",
+    "README.md",
+    "LICENSE"
+  ],
+  "publishConfig": {
+    "registry": "https://registry.npmjs.org/",
+    "access": "public"
+  },
+  "scripts": {
+    "build": "tsc",
+    "dev": "tsx watch src/index.ts",
+    "start": "node dist/index.js",
+    "clean": "rm -rf dist",
+    "lint": "eslint src/**/*.ts",
+    "lint:fix": "eslint src/**/*.ts --fix",
+    "type-check": "tsc --noEmit",
+    "format": "prettier --write src/**/*.ts",
+    "format:check": "prettier --check src/**/*.ts",
+    "prepublishOnly": "yarn build"
+  },
+  "keywords": [
+    "cli",
+    "development-tools",
+    "cursor",
+    "ai-development",
+    "melt",
+    "automation"
+  ],
+  "author": "Melt Studio",
+  "license": "MIT",
+  "dependencies": {
+    "@clack/prompts": "^0.9.0",
+    "commander": "^12.1.0",
+    "@commander-js/extra-typings": "^12.1.0",
+    "chalk": "^5.4.1",
+    "ora": "^8.2.0",
+    "fs-extra": "^11.2.0"
+  },
+  "devDependencies": {
+    "@types/fs-extra": "^11.0.4",
+    "@types/node": "^24.0.10",
+    "@typescript-eslint/eslint-plugin": "^8.19.0",
+    "@typescript-eslint/parser": "^8.19.0",
+    "eslint": "^9.17.0",
+    "eslint-config-prettier": "^9.1.0",
+    "eslint-plugin-prettier": "^5.2.1",
+    "prettier": "^3.4.2",
+    "tsx": "^4.19.5",
+    "typescript": "^5.7.3"
+  },
+  "engines": {
+    "node": ">=22.0.0"
+  }
+}

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

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

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

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

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

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

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

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

package/templates/cursor-commands/plan.md

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