@meltstudio/meltctl 2.4.0 → 3.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/commands/init.d.ts +5 -0
- package/dist/commands/init.js +102 -0
- package/dist/index.js +5 -28
- package/package.json +5 -4
- package/templates/agents-md.md +117 -0
- package/templates/claude-settings.json +36 -0
- package/templates/cursor-rules.mdc +39 -0
- package/templates/env-melt-example +23 -0
- package/templates/mcp-configs/base.json +8 -0
- package/templates/workflows/debug.md +32 -0
- package/templates/workflows/plan.md +32 -0
- package/templates/workflows/pr.md +28 -0
- package/templates/workflows/review.md +28 -0
- package/dist/commands/project/clean.d.ts +0 -5
- package/dist/commands/project/clean.js +0 -243
- package/dist/commands/project/init.d.ts +0 -5
- package/dist/commands/project/init.js +0 -152
- package/dist/commands/project/update.d.ts +0 -1
- package/dist/commands/project/update.js +0 -107
- package/templates/cursor-commands/melt-complete.md +0 -55
- package/templates/cursor-commands/melt-debug.md +0 -43
- package/templates/cursor-commands/melt-docs.md +0 -44
- package/templates/cursor-commands/melt-implement.md +0 -43
- package/templates/cursor-commands/melt-plan.md +0 -60
- package/templates/cursor-commands/melt-pr.md +0 -53
- package/templates/cursor-commands/melt-review.md +0 -43
- package/templates/cursor-commands/melt-test-plan.md +0 -50
|
@@ -1,43 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Execute implementation using Melt development standards and domain-driven architecture
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
You are implementing a feature following Melt's domain-driven development process. Follow these steps:
|
|
6
|
-
|
|
7
|
-
1. **Load Context**:
|
|
8
|
-
- Read `.melt/memory/context.md` for project context and requirements
|
|
9
|
-
- Check `.melt/outputs/plans/` for any existing implementation plans
|
|
10
|
-
- Review relevant domain structure in `src/domains/` if it exists
|
|
11
|
-
|
|
12
|
-
2. **Architecture Compliance**:
|
|
13
|
-
- Follow React 2025 standards (functional components, hooks, TypeScript strict)
|
|
14
|
-
- Use domain-driven design with clear separation of concerns
|
|
15
|
-
- Implement server components by default, client components when needed
|
|
16
|
-
- Use Zod for all data validation
|
|
17
|
-
- Follow Tailwind CSS for styling
|
|
18
|
-
|
|
19
|
-
3. **Implementation Process**:
|
|
20
|
-
- Create/update domain structures under `src/domains/[domain]/`
|
|
21
|
-
- Implement components in `src/domains/[domain]/components/`
|
|
22
|
-
- Add business logic in `src/domains/[domain]/hooks/` and `src/domains/[domain]/services/`
|
|
23
|
-
- Create types in `src/domains/[domain]/types/`
|
|
24
|
-
- Add tests in `src/domains/[domain]/__tests__/`
|
|
25
|
-
|
|
26
|
-
4. **Quality Standards**:
|
|
27
|
-
- Ensure 80% test coverage minimum
|
|
28
|
-
- Use TypeScript strict mode
|
|
29
|
-
- Add proper JSDoc documentation
|
|
30
|
-
- Follow atomic commit principles
|
|
31
|
-
- No debugging code in commits
|
|
32
|
-
|
|
33
|
-
5. **Documentation**:
|
|
34
|
-
- Update `.melt/memory/context.md` with implementation details
|
|
35
|
-
- Save implementation notes to `.melt/outputs/implementations/[timestamp].md`
|
|
36
|
-
- Update relevant README files if needed
|
|
37
|
-
|
|
38
|
-
6. **Testing**:
|
|
39
|
-
- Write unit tests for all business logic
|
|
40
|
-
- Add integration tests for complex workflows
|
|
41
|
-
- Ensure all tests pass before completing
|
|
42
|
-
|
|
43
|
-
Remember: Focus on clean, maintainable code that follows our established patterns and domain boundaries.
|
|
@@ -1,60 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Create implementation plan with User Story and RFC validation following Melt's domain-driven architecture standards
|
|
3
|
-
scripts:
|
|
4
|
-
sh: .melt/scripts/sh/get-plan-context.sh --json
|
|
5
|
-
ps: .melt/scripts/ps/get-plan-context.ps1 -Json
|
|
6
|
-
---
|
|
7
|
-
|
|
8
|
-
Create a comprehensive implementation plan for the requested feature. Follow these steps:
|
|
9
|
-
|
|
10
|
-
1. **Collect Requirements**:
|
|
11
|
-
- Run `{SCRIPT}` from the project root and parse JSON for USER_STORY, RFC, ISSUE_ID, PLAN_FILE, and PROJECT_ROOT
|
|
12
|
-
- If script fails, prompt manually for User Story and RFC
|
|
13
|
-
- Validate that both User Story and RFC are complete and actionable
|
|
14
|
-
|
|
15
|
-
2. **Analyze Requirements**:
|
|
16
|
-
- Analyze the provided User Story for clear acceptance criteria and user value
|
|
17
|
-
- Review the RFC for technical decisions, architecture, and constraints
|
|
18
|
-
- Read `.melt/memory/context.md` for additional project context
|
|
19
|
-
- Identify the target domain(s) this feature belongs to
|
|
20
|
-
- Determine integration points with existing domains
|
|
21
|
-
|
|
22
|
-
3. **Architecture Planning**:
|
|
23
|
-
- Design domain structure following our patterns:
|
|
24
|
-
```
|
|
25
|
-
src/domains/[domain]/
|
|
26
|
-
├── components/ # React components
|
|
27
|
-
├── hooks/ # Custom hooks for business logic
|
|
28
|
-
├── services/ # API calls and external integrations
|
|
29
|
-
├── types/ # TypeScript types and Zod schemas
|
|
30
|
-
├── utils/ # Domain-specific utilities
|
|
31
|
-
└── __tests__/ # Domain tests
|
|
32
|
-
```
|
|
33
|
-
- Plan component hierarchy and state management
|
|
34
|
-
- Design data flow and API integration points
|
|
35
|
-
|
|
36
|
-
4. **Technical Decisions**:
|
|
37
|
-
- Choose appropriate React patterns (server vs client components)
|
|
38
|
-
- Plan Zod schemas for data validation
|
|
39
|
-
- Design TypeScript interfaces and types
|
|
40
|
-
- Plan testing strategy (unit, integration, e2e)
|
|
41
|
-
|
|
42
|
-
5. **Implementation Strategy**:
|
|
43
|
-
- Break down into atomic, testable units
|
|
44
|
-
- Identify dependencies and execution order
|
|
45
|
-
- Plan for error handling and edge cases
|
|
46
|
-
- Consider accessibility and performance requirements
|
|
47
|
-
|
|
48
|
-
6. **Create Detailed Plan**:
|
|
49
|
-
- List specific files to create/modify
|
|
50
|
-
- Define component interfaces and props
|
|
51
|
-
- Specify API endpoints and data contracts
|
|
52
|
-
- Plan test cases and coverage targets
|
|
53
|
-
|
|
54
|
-
7. **Save Planning Output**:
|
|
55
|
-
- Save comprehensive plan to the PLAN_FILE path provided by the script
|
|
56
|
-
- Include User Story and RFC as context sections in the plan
|
|
57
|
-
- Update `.melt/memory/context.md` with planning decisions and issue reference
|
|
58
|
-
- Create task breakdown for implementation with clear dependencies
|
|
59
|
-
|
|
60
|
-
Focus on maintainable, testable code that follows our domain-driven architecture principles.
|
|
@@ -1,53 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Create comprehensive pull request with proper description and metadata
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
Create a detailed pull request following Melt's standards for code review and deployment:
|
|
6
|
-
|
|
7
|
-
1. **Gather Context**:
|
|
8
|
-
- Read `.melt/outputs/plans/` for implementation plan details
|
|
9
|
-
- Review `.melt/outputs/implementations/` for implementation notes
|
|
10
|
-
- Check `.melt/memory/context.md` for project context
|
|
11
|
-
- Identify related Linear story and RFC references
|
|
12
|
-
|
|
13
|
-
2. **PR Description Structure**:
|
|
14
|
-
- **Summary**: Brief description of what was implemented
|
|
15
|
-
- **Changes**: Bulleted list of specific changes made
|
|
16
|
-
- **Testing**: How the changes were tested (unit, integration, manual)
|
|
17
|
-
- **Screenshots**: For UI changes, include before/after images
|
|
18
|
-
- **Linear Story**: Link to Linear story and requirements
|
|
19
|
-
- **RFC Reference**: Link to relevant RFC section if applicable
|
|
20
|
-
|
|
21
|
-
3. **PR Metadata**:
|
|
22
|
-
- Add appropriate labels (feature, bugfix, docs, etc.)
|
|
23
|
-
- Assign reviewers based on affected domains
|
|
24
|
-
- Set milestone if applicable
|
|
25
|
-
- Link to related issues or PRs
|
|
26
|
-
|
|
27
|
-
4. **Code Review Preparation**:
|
|
28
|
-
- Ensure all tests pass
|
|
29
|
-
- Run linting and type checking
|
|
30
|
-
- Verify accessibility compliance
|
|
31
|
-
- Check performance impact
|
|
32
|
-
- Validate security considerations
|
|
33
|
-
|
|
34
|
-
5. **Deployment Readiness**:
|
|
35
|
-
- Document any environment variable changes
|
|
36
|
-
- Note database migration requirements
|
|
37
|
-
- Include feature flag configurations
|
|
38
|
-
- Specify rollback procedures if needed
|
|
39
|
-
|
|
40
|
-
6. **Quality Checklist**:
|
|
41
|
-
- [ ] Code follows domain architecture patterns
|
|
42
|
-
- [ ] Tests have adequate coverage (80%+)
|
|
43
|
-
- [ ] Documentation updated
|
|
44
|
-
- [ ] No debugging code committed
|
|
45
|
-
- [ ] TypeScript strict mode compliance
|
|
46
|
-
- [ ] Performance considerations addressed
|
|
47
|
-
|
|
48
|
-
7. **Save PR Information**:
|
|
49
|
-
- Create PR with comprehensive description
|
|
50
|
-
- Save PR details to `.melt/outputs/implementations/[timestamp]-pr.md`
|
|
51
|
-
- Update `.melt/memory/context.md` with PR status
|
|
52
|
-
|
|
53
|
-
Focus on clear communication and thorough preparation for efficient code review.
|
|
@@ -1,43 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Review code following Melt's quality standards and architecture compliance
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
Perform a comprehensive code review following Melt's standards:
|
|
6
|
-
|
|
7
|
-
1. **Architecture Review**:
|
|
8
|
-
- Verify domain-driven design compliance
|
|
9
|
-
- Check proper separation of concerns
|
|
10
|
-
- Validate component placement within domain structure
|
|
11
|
-
- Review data flow and state management patterns
|
|
12
|
-
|
|
13
|
-
2. **Code Quality**:
|
|
14
|
-
- TypeScript strict mode compliance
|
|
15
|
-
- Proper error handling and edge cases
|
|
16
|
-
- Performance considerations (memo, useMemo, useCallback)
|
|
17
|
-
- Accessibility compliance (ARIA, semantic HTML)
|
|
18
|
-
|
|
19
|
-
3. **Testing Coverage**:
|
|
20
|
-
- Unit tests for business logic (80% minimum)
|
|
21
|
-
- Integration tests for complex workflows
|
|
22
|
-
- Test quality and maintainability
|
|
23
|
-
- Mock strategies and test isolation
|
|
24
|
-
|
|
25
|
-
4. **Documentation**:
|
|
26
|
-
- JSDoc comments for public APIs
|
|
27
|
-
- README updates for new features
|
|
28
|
-
- Architecture decision records when applicable
|
|
29
|
-
- Code comments for complex business logic
|
|
30
|
-
|
|
31
|
-
5. **Security & Best Practices**:
|
|
32
|
-
- Input validation with Zod schemas
|
|
33
|
-
- XSS prevention in dynamic content
|
|
34
|
-
- Proper authentication/authorization patterns
|
|
35
|
-
- Environment variable usage
|
|
36
|
-
|
|
37
|
-
6. **Review Output**:
|
|
38
|
-
- Document findings in `.melt/outputs/reviews/[timestamp]-review.md`
|
|
39
|
-
- Categorize issues by severity (critical, major, minor)
|
|
40
|
-
- Provide specific recommendations and examples
|
|
41
|
-
- Update `.melt/memory/context.md` with lessons learned
|
|
42
|
-
|
|
43
|
-
Focus on constructive feedback that improves code quality and team knowledge.
|
|
@@ -1,50 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Generate comprehensive test strategy and test files based on implementation plan
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
Create a comprehensive testing strategy and generate test files following Melt's testing standards:
|
|
6
|
-
|
|
7
|
-
1. **Load Implementation Context**:
|
|
8
|
-
- Read `.melt/outputs/plans/` for the current implementation plan
|
|
9
|
-
- Review `.melt/memory/context.md` for project testing patterns
|
|
10
|
-
- Analyze existing test files in `src/domains/[domain]/__tests__/`
|
|
11
|
-
|
|
12
|
-
2. **Test Strategy Design**:
|
|
13
|
-
- **Unit Tests**: Test individual components, hooks, and utilities
|
|
14
|
-
- **Integration Tests**: Test component interactions and data flow
|
|
15
|
-
- **API Tests**: Test service layer and external integrations
|
|
16
|
-
- **Accessibility Tests**: Ensure WCAG compliance
|
|
17
|
-
- **Performance Tests**: Validate rendering and interaction performance
|
|
18
|
-
|
|
19
|
-
3. **Test File Generation**:
|
|
20
|
-
- Create test files following domain structure:
|
|
21
|
-
```
|
|
22
|
-
src/domains/[domain]/__tests__/
|
|
23
|
-
├── components/ # Component tests
|
|
24
|
-
├── hooks/ # Hook tests
|
|
25
|
-
├── services/ # Service/API tests
|
|
26
|
-
└── utils/ # Utility function tests
|
|
27
|
-
```
|
|
28
|
-
- Use React Testing Library for component tests
|
|
29
|
-
- Use @testing-library/react-hooks for hook tests
|
|
30
|
-
- Mock external dependencies appropriately
|
|
31
|
-
|
|
32
|
-
4. **Testing Patterns**:
|
|
33
|
-
- Follow TDD approach - write tests before implementation
|
|
34
|
-
- Test behavior, not implementation details
|
|
35
|
-
- Use meaningful test descriptions and organize with describe blocks
|
|
36
|
-
- Include edge cases and error scenarios
|
|
37
|
-
- Ensure accessibility testing with @testing-library/jest-dom
|
|
38
|
-
|
|
39
|
-
5. **Test Coverage Strategy**:
|
|
40
|
-
- Target 80% minimum coverage for new code
|
|
41
|
-
- Focus on critical business logic and user flows
|
|
42
|
-
- Test error handling and edge cases
|
|
43
|
-
- Validate prop types and component contracts
|
|
44
|
-
|
|
45
|
-
6. **Save Test Plan**:
|
|
46
|
-
- Document test strategy in `.melt/outputs/plans/[timestamp]-test-plan.md`
|
|
47
|
-
- Create test files in appropriate domain directories
|
|
48
|
-
- Update `.melt/memory/context.md` with testing decisions
|
|
49
|
-
|
|
50
|
-
Focus on creating comprehensive, maintainable tests that validate both functionality and user experience.
|