Melt

Autonomous Execution With /melt

Use /melt when the user wants action, not a proposal. The job is to take a task from vague request to verified result.

This skill is for execution, not endless clarification. Make reasonable assumptions, move forward, and only ask once if blocked by missing credentials, missing target environment, or a risky irreversible choice.

Quick Start

Use this for prompts like:

• /melt fix the flaky login redirect
• /melt add CSV export and open a PR
• /melt refactor this service into smaller modules

Workflow

Print these labels as you go:

[1/8] Activating execution mode
[2/8] Triaging complexity
[3/8] Planning the work
[4/8] Isolating execution
[5/8] Implementing changes
[6/8] Running quality gates
[7/8] Verifying real behavior
[8/8] Delivering the result

1. Activate

Start by grounding yourself in the repo:

• Inspect the current tree and git status
• Read the nearest relevant docs before editing unfamiliar areas
• Identify whether the task is local-only or should end in a branch/PR

If unrelated user changes exist, work around them. Never revert them unless explicitly asked.

2. Triage Complexity

Classify the task before planning.

Default to Standard.

State it explicitly:

TRIAGE: STANDARD → coordinator + 2 sidecar agents

3. Plan

Use update_plan for any task that is more than trivial.

The plan should be concrete and execution-shaped:

• Inspect relevant files
• Implement targeted changes
• Run repo-native validation
• Verify real behavior
• Package delivery

Do not stop at the plan. The plan exists to drive execution.

4. Isolate Execution

For non-trivial git work, prefer a linked worktree instead of editing on the primary checkout. Good default branch name:

git worktree add ../repo--melt-fix-thing -b melt/fix-thing

If the repo is not under git or the user clearly wants in-place edits, continue locally.

5. Implement

Implementation rules:

• Use apply_patch for manual file edits
• Prefer rg for search and multi_tool_use.parallel for parallel reads
• Delegate sidecar work with spawn_agent only when it is bounded and non-blocking
• Give workers explicit file ownership
• Keep changes focused on the task

Good delegation:

• Test failure triage while you implement
• README update while you refactor code
• Parallel edits in non-overlapping files

Bad delegation:

• Handing off the immediate blocker and then waiting
• Asking multiple agents to edit the same files

6. Run Quality Gates

Run the checks the repo already expects:

• Formatter
• Linter
• Type checker
• Tests
• Build if relevant

If the repo has no explicit tooling, run the closest credible checks instead of claiming validation.

Do not ignore failures in touched areas. If unrelated failures remain, say so clearly.

7. Verify Real Behavior

Verification must match the kind of change:

• Web UI: use Playwright or the repo's browser harness and exercise the changed flow
• API: call the real endpoint and inspect status plus response content
• CLI: run the command with real arguments
• Library: write or run a small consumer example
• Docs: render or inspect the final artifact

At least one check must be behavior-based, not just exit code 0.

8. Deliver

When delivery includes git:

• Create or reuse a feature branch
• Commit with a concise message
• Push and open a PR when GitHub tooling is available

Do not commit directly to the default branch if the expected workflow is PR-based.

Your final handoff should include:

• What changed
• What you ran
• What you verified
• Any residual risk or blocker

Rules

• Prefer action over clarification loops
• Do not stop after analysis when code should be written
• Do not claim verification you did not perform
• Do not revert unrelated user changes
• Use subagents to accelerate execution, not to avoid ownership