@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.
@@ -0,0 +1,5 @@
1
+ interface InitOptions {
2
+ force?: boolean;
3
+ }
4
+ export declare function initCommand(options: InitOptions): Promise<void>;
5
+ export {};
@@ -0,0 +1,102 @@
1
+ import chalk from 'chalk';
2
+ import fs from 'fs-extra';
3
+ import path from 'path';
4
+ import { fileURLToPath } from 'url';
5
+ const __dirname = path.dirname(fileURLToPath(import.meta.url));
6
+ const TEMPLATES_DIR = path.join(__dirname, '../../templates');
7
+ const SKILL_FRONTMATTER = {
8
+ plan: `---
9
+ user-invocable: true
10
+ description: Design an implementation approach before writing code
11
+ ---
12
+
13
+ `,
14
+ review: `---
15
+ user-invocable: true
16
+ description: Review changes against project standards
17
+ ---
18
+
19
+ `,
20
+ pr: `---
21
+ user-invocable: true
22
+ description: Create a well-structured pull request
23
+ ---
24
+
25
+ `,
26
+ debug: `---
27
+ user-invocable: true
28
+ description: Systematically investigate and fix bugs
29
+ ---
30
+
31
+ `,
32
+ };
33
+ const GITIGNORE_ENTRIES = ['.env.local', '.claude/settings.local.json'];
34
+ export async function initCommand(options) {
35
+ const cwd = process.cwd();
36
+ // Check if already initialized (AGENTS.md exists)
37
+ if (!options.force && (await fs.pathExists(path.join(cwd, 'AGENTS.md')))) {
38
+ console.log(chalk.yellow('Project already has an AGENTS.md file. Use --force to overwrite.'));
39
+ process.exit(1);
40
+ }
41
+ console.log(chalk.bold('Initializing Melt development tools...'));
42
+ console.log();
43
+ // Copy AGENTS.md
44
+ await fs.copyFile(path.join(TEMPLATES_DIR, 'agents-md.md'), path.join(cwd, 'AGENTS.md'));
45
+ // Copy .claude/settings.json
46
+ await fs.ensureDir(path.join(cwd, '.claude'));
47
+ await fs.copyFile(path.join(TEMPLATES_DIR, 'claude-settings.json'), path.join(cwd, '.claude/settings.json'));
48
+ // Create Claude skills from workflow templates
49
+ const workflows = ['plan', 'review', 'pr', 'debug'];
50
+ for (const name of workflows) {
51
+ const skillDir = path.join(cwd, `.claude/skills/melt-${name}`);
52
+ await fs.ensureDir(skillDir);
53
+ const workflowContent = await fs.readFile(path.join(TEMPLATES_DIR, `workflows/${name}.md`), 'utf-8');
54
+ const skillContent = SKILL_FRONTMATTER[name] + workflowContent;
55
+ await fs.writeFile(path.join(skillDir, 'SKILL.md'), skillContent, 'utf-8');
56
+ }
57
+ // Copy .cursor/rules/standards.mdc
58
+ await fs.ensureDir(path.join(cwd, '.cursor/rules'));
59
+ await fs.copyFile(path.join(TEMPLATES_DIR, 'cursor-rules.mdc'), path.join(cwd, '.cursor/rules/standards.mdc'));
60
+ // Copy Cursor commands from workflow templates
61
+ await fs.ensureDir(path.join(cwd, '.cursor/commands'));
62
+ for (const name of workflows) {
63
+ await fs.copyFile(path.join(TEMPLATES_DIR, `workflows/${name}.md`), path.join(cwd, `.cursor/commands/melt-${name}.md`));
64
+ }
65
+ // Copy .mcp.json
66
+ await fs.copyFile(path.join(TEMPLATES_DIR, 'mcp-configs/base.json'), path.join(cwd, '.mcp.json'));
67
+ // Copy .env.melt.example
68
+ await fs.copyFile(path.join(TEMPLATES_DIR, 'env-melt-example'), path.join(cwd, '.env.melt.example'));
69
+ // Update .gitignore
70
+ await updateGitignore(cwd);
71
+ // Print summary
72
+ console.log(chalk.green('Created files:'));
73
+ console.log(chalk.dim(' AGENTS.md'));
74
+ console.log(chalk.dim(' .claude/settings.json'));
75
+ console.log(chalk.dim(' .claude/skills/melt-{plan,review,pr,debug}/SKILL.md'));
76
+ console.log(chalk.dim(' .cursor/rules/standards.mdc'));
77
+ console.log(chalk.dim(' .cursor/commands/melt-{plan,review,pr,debug}.md'));
78
+ console.log(chalk.dim(' .mcp.json'));
79
+ console.log(chalk.dim(' .env.melt.example'));
80
+ console.log();
81
+ console.log(chalk.yellow('Next steps:'));
82
+ console.log(chalk.dim(' 1. Edit AGENTS.md to describe your project and add team-specific standards'));
83
+ console.log(chalk.dim(' 2. Copy .env.melt.example to .env.local and fill in credentials'));
84
+ console.log(chalk.dim(' 3. Commit the generated files'));
85
+ console.log();
86
+ console.log(chalk.green('Done!'));
87
+ }
88
+ async function updateGitignore(cwd) {
89
+ const gitignorePath = path.join(cwd, '.gitignore');
90
+ let content = '';
91
+ if (await fs.pathExists(gitignorePath)) {
92
+ content = await fs.readFile(gitignorePath, 'utf-8');
93
+ }
94
+ const missingEntries = GITIGNORE_ENTRIES.filter(entry => !content.includes(entry));
95
+ if (missingEntries.length > 0) {
96
+ const suffix = content.endsWith('\n') || content === '' ? '' : '\n';
97
+ const section = missingEntries.length > 0
98
+ ? `${suffix}\n# Melt - local settings\n${missingEntries.join('\n')}\n`
99
+ : '';
100
+ await fs.writeFile(gitignorePath, content + section, 'utf-8');
101
+ }
102
+ }
package/dist/index.js CHANGED
@@ -3,9 +3,7 @@ import { Command } from '@commander-js/extra-typings';
3
3
  import { readFileSync } from 'fs';
4
4
  import { join, dirname } from 'path';
5
5
  import { fileURLToPath } from 'url';
6
- import { initCommand } from './commands/project/init.js';
7
- import { updateCommand } from './commands/project/update.js';
8
- import { cleanCommand } from './commands/project/clean.js';
6
+ import { initCommand } from './commands/init.js';
9
7
  import { checkAndEnforceUpdate } from './utils/version-check.js';
10
8
  import { versionCheckCommand } from './commands/version.js';
11
9
  // Read version from package.json
@@ -15,39 +13,18 @@ const packageJson = JSON.parse(readFileSync(join(__dirname, '../package.json'),
15
13
  const program = new Command();
16
14
  program
17
15
  .name('meltctl')
18
- .description('CLI tool for Melt development process automation')
16
+ .description('AI-first development tools for teams')
19
17
  .version(packageJson.version)
20
18
  .hook('preAction', async () => {
21
19
  await checkAndEnforceUpdate();
22
20
  });
23
- // Project management commands
24
- const projectCommand = program
25
- .command('project')
26
- .description('Project setup and management commands');
27
- projectCommand
21
+ program
28
22
  .command('init')
29
23
  .description('Initialize project with Melt development tools')
30
- .option('--shell <type>', 'specify shell type (sh|ps)', 'auto')
31
- .action(options => {
32
- // Validate shell option
33
- const validShells = ['sh', 'ps', 'auto'];
34
- const shell = validShells.includes(options.shell)
35
- ? options.shell
36
- : 'auto';
37
- return initCommand({ shell });
38
- });
39
- projectCommand
40
- .command('update')
41
- .description('Update project configurations to latest version')
42
- .action(updateCommand);
43
- projectCommand
44
- .command('clean')
45
- .description('Remove all Melt-generated files from the project')
46
- .option('-y, --yes', 'skip confirmation prompt')
24
+ .option('--force', 'overwrite existing files')
47
25
  .action(options => {
48
- return cleanCommand({ yes: options.yes });
26
+ return initCommand({ force: options.force });
49
27
  });
50
- // Version check command
51
28
  program
52
29
  .command('version')
53
30
  .description('Display version information')
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@meltstudio/meltctl",
3
- "version": "2.4.0",
4
- "description": "CLI tool for Melt development process automation - initialize and update project configurations",
3
+ "version": "3.0.0",
4
+ "description": "AI-first development tools for teams - set up AGENTS.md, Claude Code, Cursor, and Copilot standards",
5
5
  "main": "dist/index.js",
6
6
  "type": "module",
7
7
  "bin": {
@@ -37,7 +37,10 @@
37
37
  "keywords": [
38
38
  "cli",
39
39
  "development-tools",
40
+ "agents-md",
41
+ "claude-code",
40
42
  "cursor",
43
+ "copilot",
41
44
  "ai-development",
42
45
  "melt",
43
46
  "automation"
@@ -45,11 +48,9 @@
45
48
  "author": "Melt Studio",
46
49
  "license": "MIT",
47
50
  "dependencies": {
48
- "@clack/prompts": "^0.9.0",
49
51
  "commander": "^12.1.0",
50
52
  "@commander-js/extra-typings": "^12.1.0",
51
53
  "chalk": "^5.4.1",
52
- "ora": "^8.2.0",
53
54
  "fs-extra": "^11.2.0"
54
55
  },
55
56
  "devDependencies": {
@@ -0,0 +1,117 @@
1
+ # AGENTS.md
2
+
3
+ ## Project Overview
4
+
5
+ <!-- Describe your project here: what it does, key technologies, and architecture overview -->
6
+
7
+ ## Architecture Standards
8
+
9
+ ### Important: Respect Existing Code
10
+
11
+ Before applying any standards below, **understand the existing project structure first**. If the project already follows a different architecture or pattern, continue following the existing conventions. These standards apply to new code in greenfield areas - never refactor or restructure existing code to match these guidelines unless explicitly asked.
12
+
13
+ ### Recommended Structure (for new projects/domains)
14
+
15
+ For new frontend code, prefer domain-driven architecture:
16
+
17
+ ```
18
+ src/
19
+ domains/
20
+ <domain>/
21
+ components/ # UI components scoped to this domain
22
+ hooks/ # Custom hooks for this domain
23
+ services/ # API calls and business logic
24
+ types/ # TypeScript types and interfaces
25
+ utils/ # Domain-specific utilities
26
+ shared/
27
+ components/ # Shared UI components
28
+ hooks/ # Shared custom hooks
29
+ services/ # Shared API services
30
+ types/ # Shared TypeScript types
31
+ utils/ # Shared utilities
32
+ ```
33
+
34
+ - Each domain is self-contained with its own components, hooks, services, types, and utils
35
+ - Cross-domain imports go through the `shared/` directory
36
+ - Never import directly between domains
37
+
38
+ If the project uses a different structure, follow the existing patterns instead.
39
+
40
+ ### TypeScript Standards
41
+ - Strict mode enabled (`strict: true` in tsconfig)
42
+ - No `any` types - use `unknown` with type guards when the type is truly unknown
43
+ - Validate external data with Zod schemas at system boundaries
44
+ - Export types from dedicated `types.ts` files
45
+
46
+ ### Code Quality
47
+ - Minimum 80% test coverage for new code
48
+ - Use conventional commits (feat:, fix:, chore:, docs:, refactor:, test:)
49
+ - No eslint-disable comments without team approval
50
+ - All functions must have explicit return types
51
+ - Prefer composition over inheritance
52
+
53
+ ## Agent Permissions
54
+
55
+ ### Automatically Approved (No Confirmation Needed)
56
+ - Reading any file in the repository
57
+ - Running tests, linters, type checkers, and formatters
58
+ - Git read operations (status, log, diff, branch)
59
+ - Searching code and exploring the codebase
60
+ - Package dependency lookups
61
+
62
+ ### Requires Approval
63
+ - Writing or modifying files
64
+ - Git write operations (add, commit, checkout, branch creation)
65
+ - Running build commands
66
+ - Installing or removing dependencies
67
+ - Creating pull requests or issues
68
+
69
+ ### Blocked (Never Execute)
70
+ - `git push --force` or `git push --force-with-lease`
71
+ - `git reset --hard`
72
+ - `rm -rf /` or any recursive delete of root paths
73
+ - Force push to main or master branches
74
+ - Dropping database tables in production
75
+ - Modifying CI/CD pipeline files without explicit request
76
+
77
+ ## Tool Access
78
+
79
+ ### CLI Tools
80
+ - Use `gh` CLI for GitHub operations (PRs, issues, releases)
81
+ - Use project's package manager (check for yarn.lock, pnpm-lock.yaml, or package-lock.json)
82
+ - Run tests with the project's configured test runner
83
+
84
+ ### Browser (via DevTools MCP)
85
+ - Use Chrome DevTools MCP server for browser testing when available
86
+ - Inspect elements, check console errors, verify visual output
87
+ - Test responsive layouts and interactions
88
+
89
+ ### Databases
90
+ - Read queries are safe to execute
91
+ - Write queries require approval
92
+ - Schema changes require explicit request and approval
93
+
94
+ ## Project Management
95
+
96
+ - Reference issue/ticket IDs in commit messages and PR descriptions
97
+ - Follow the team's workflow for issue progression
98
+ - Update ticket status when starting and completing work
99
+
100
+ ## Workflow Skills
101
+
102
+ The following workflows are available as AI skills:
103
+
104
+ - **plan** - Gather requirements, explore codebase, design approach, present plan for approval
105
+ - **review** - Review changes against these standards, categorize findings
106
+ - **pr** - Analyze changes, draft PR description, run pre-flight checks, create PR
107
+ - **debug** - Investigate issues, isolate root cause, write regression test, fix
108
+
109
+ ## Customization
110
+
111
+ <!-- Add project-specific standards below this line -->
112
+ <!-- Examples of things to add: -->
113
+ <!-- - API conventions (REST patterns, error formats, pagination) -->
114
+ <!-- - Component patterns (naming, file structure, state management) -->
115
+ <!-- - Database rules (naming conventions, migration patterns) -->
116
+ <!-- - Testing patterns (what to mock, integration test setup) -->
117
+ <!-- - Deployment rules (environment-specific concerns) -->
@@ -0,0 +1,36 @@
1
+ {
2
+ "permissions": {
3
+ "allow": [
4
+ "Bash(git status*)",
5
+ "Bash(git log*)",
6
+ "Bash(git diff*)",
7
+ "Bash(git branch*)",
8
+ "Bash(git show*)",
9
+ "Bash(npm test*)",
10
+ "Bash(yarn test*)",
11
+ "Bash(pnpm test*)",
12
+ "Bash(npx vitest*)",
13
+ "Bash(npx jest*)",
14
+ "Bash(npm run lint*)",
15
+ "Bash(yarn lint*)",
16
+ "Bash(pnpm lint*)",
17
+ "Bash(npm run build*)",
18
+ "Bash(yarn build*)",
19
+ "Bash(pnpm build*)",
20
+ "Bash(npx tsc*)",
21
+ "Bash(gh pr *)",
22
+ "Bash(gh issue *)",
23
+ "Read(*)"
24
+ ],
25
+ "deny": [
26
+ "Bash(git push --force*)",
27
+ "Bash(git push * --force*)",
28
+ "Bash(git push --force-with-lease*)",
29
+ "Bash(git push * --force-with-lease*)",
30
+ "Bash(git reset --hard*)",
31
+ "Bash(rm -rf /*)",
32
+ "Bash(git push * main*)",
33
+ "Bash(git push * master*)"
34
+ ]
35
+ }
36
+ }
@@ -0,0 +1,39 @@
1
+ ---
2
+ description: Melt development standards and architecture guidelines
3
+ globs:
4
+ alwaysApply: true
5
+ ---
6
+
7
+ # Project Standards
8
+
9
+ ## Important
10
+ - Always understand the existing project structure before making changes
11
+ - If the project follows different conventions than listed here, follow the existing patterns
12
+ - These standards apply to new greenfield code - never refactor existing code to match unless asked
13
+
14
+ ## Architecture
15
+ - Prefer domain-driven architecture for new code: `src/domains/<domain>/{components,hooks,services,types,utils}`
16
+ - Cross-domain imports go through `src/shared/`
17
+ - Never import directly between domains
18
+ - Follow existing project patterns when they differ from the above
19
+
20
+ ## TypeScript
21
+ - Strict mode enabled, no `any` types
22
+ - Validate external data with Zod at system boundaries
23
+ - All functions must have explicit return types
24
+
25
+ ## Code Quality
26
+ - 80% minimum test coverage for new code
27
+ - Conventional commits (feat:, fix:, chore:, docs:, refactor:, test:)
28
+ - No eslint-disable comments without team approval
29
+
30
+ ## Agent Behavior
31
+ - Read operations: auto-approved
32
+ - Write operations: require developer approval
33
+ - Destructive operations: blocked (no force push, no hard reset)
34
+
35
+ ## Workflows
36
+ - Use `plan` before starting non-trivial implementations
37
+ - Use `review` to check changes against these standards
38
+ - Use `pr` to create well-structured pull requests
39
+ - Use `debug` for systematic bug investigation
@@ -0,0 +1,23 @@
1
+ # Melt Development Tools - Environment Variables
2
+ # Copy this file to .env.local and fill in your values
3
+ # Never commit .env.local to version control
4
+
5
+ # --- Linear (if using Linear for project management) ---
6
+ # LINEAR_API_KEY=lin_api_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
7
+
8
+ # --- Jira (if using Jira for project management) ---
9
+ # JIRA_API_TOKEN=your-jira-api-token
10
+ # JIRA_BASE_URL=https://your-org.atlassian.net
11
+ # JIRA_USER_EMAIL=your-email@company.com
12
+
13
+ # --- Database (if agents need database access) ---
14
+ # DATABASE_URL=postgresql://user:password@localhost:5432/dbname
15
+
16
+ # --- AWS (if agents need AWS access) ---
17
+ # AWS_ACCESS_KEY_ID=your-access-key
18
+ # AWS_SECRET_ACCESS_KEY=your-secret-key
19
+ # AWS_REGION=us-east-1
20
+
21
+ # --- Other Integrations ---
22
+ # OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
23
+ # ANTHROPIC_API_KEY=sk-ant-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
@@ -0,0 +1,8 @@
1
+ {
2
+ "mcpServers": {
3
+ "chrome-devtools": {
4
+ "command": "npx",
5
+ "args": ["-y", "@anthropic-ai/chrome-devtools-mcp@latest"]
6
+ }
7
+ }
8
+ }
@@ -0,0 +1,32 @@
1
+ # Debug
2
+
3
+ Investigate and fix bugs systematically.
4
+
5
+ ## Instructions
6
+
7
+ 1. **Understand the Problem**
8
+ - Read the bug report or error description
9
+ - Reproduce the issue if possible
10
+ - Identify expected vs actual behavior
11
+
12
+ 2. **Investigate**
13
+ - Search the codebase for relevant code paths
14
+ - Read error messages and stack traces carefully
15
+ - Use browser DevTools MCP if it's a UI issue
16
+ - Check recent changes that might have introduced the bug
17
+ - Add temporary logging if needed to trace execution
18
+
19
+ 3. **Isolate the Root Cause**
20
+ - Narrow down to the specific file and function
21
+ - Understand why the current code produces the wrong behavior
22
+ - Verify your hypothesis by checking related code paths
23
+
24
+ 4. **Write a Regression Test**
25
+ - Write a test that reproduces the bug (it should fail before the fix)
26
+ - Cover the specific edge case that caused the issue
27
+
28
+ 5. **Fix the Bug**
29
+ - Make the minimal change needed to fix the issue
30
+ - Verify the regression test now passes
31
+ - Run the full test suite to check for regressions
32
+ - Clean up any temporary debugging code
@@ -0,0 +1,32 @@
1
+ # Plan
2
+
3
+ Design an implementation approach before writing code.
4
+
5
+ ## Instructions
6
+
7
+ 1. **Gather Requirements**
8
+ - Read the task description carefully
9
+ - Identify acceptance criteria and constraints
10
+ - Ask clarifying questions if requirements are ambiguous
11
+
12
+ 2. **Explore the Codebase**
13
+ - Find relevant files and understand existing patterns
14
+ - Check for similar implementations to follow as examples
15
+ - Identify files that will need changes
16
+
17
+ 3. **Design the Approach**
18
+ - Break the task into concrete implementation steps
19
+ - Consider edge cases and error handling
20
+ - Note any dependencies or ordering constraints
21
+ - Estimate which files will be created or modified
22
+
23
+ 4. **Present the Plan**
24
+ - Summarize the approach in a clear, numbered list
25
+ - Highlight any architectural decisions or trade-offs
26
+ - List files to be modified with a brief description of changes
27
+ - Call out any risks or open questions
28
+
29
+ 5. **Wait for Approval**
30
+ - Do not start implementation until the developer approves
31
+ - Adjust the plan based on feedback
32
+ - Once approved, proceed with implementation
@@ -0,0 +1,28 @@
1
+ # Pull Request
2
+
3
+ Create a well-structured pull request from the current changes.
4
+
5
+ ## Instructions
6
+
7
+ 1. **Analyze Changes**
8
+ - Run `git diff` to understand all changes
9
+ - Run `git log` to review commit history on this branch
10
+ - Identify the purpose and scope of the changes
11
+
12
+ 2. **Draft PR Description**
13
+ - Write a clear title (under 70 characters)
14
+ - Summarize changes in 1-3 bullet points
15
+ - Reference related issues or tickets
16
+ - Note any breaking changes or migration steps
17
+
18
+ 3. **Run Pre-flight Checks**
19
+ - Run the test suite and verify all tests pass
20
+ - Run the linter and fix any issues
21
+ - Run type checking and resolve any errors
22
+ - Verify the build succeeds
23
+
24
+ 4. **Create the PR**
25
+ - Use `gh pr create` with the drafted title and description
26
+ - Add appropriate labels if the project uses them
27
+ - Request reviewers if specified
28
+ - Return the PR URL to the developer
@@ -0,0 +1,28 @@
1
+ # Review
2
+
3
+ Review code changes against project standards.
4
+
5
+ ## Instructions
6
+
7
+ 1. **Understand Context**
8
+ - Read the PR description or task context
9
+ - Understand what the changes are trying to accomplish
10
+ - Check AGENTS.md for project-specific standards
11
+
12
+ 2. **Review the Changes**
13
+ - Read all modified files carefully
14
+ - Check for correctness, readability, and maintainability
15
+ - Verify adherence to architecture standards (domain structure, typing, etc.)
16
+ - Look for potential bugs, edge cases, or security issues
17
+ - Check that tests cover the changes adequately
18
+
19
+ 3. **Categorize Findings**
20
+ - **Must Fix**: Bugs, security issues, broken functionality, standards violations
21
+ - **Should Fix**: Code quality issues, missing tests, unclear naming
22
+ - **Suggestion**: Style preferences, optional improvements, alternative approaches
23
+
24
+ 4. **Present the Review**
25
+ - Start with a summary of what the changes do
26
+ - List findings by category with file paths and line numbers
27
+ - Provide specific suggestions for how to fix each issue
28
+ - End with an overall assessment (approve, request changes, or needs discussion)
@@ -1,5 +0,0 @@
1
- interface CleanOptions {
2
- yes?: boolean;
3
- }
4
- export declare function cleanCommand(options?: CleanOptions): Promise<void>;
5
- export {};