| name | melt |
| description | Full autonomous execution for Codex. Use when asked to "go do", "just do it", "execute this", "/melt", or when the user wants planning, implementation, validation, and delivery with minimal back-and-forth. |
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.
| Complexity | Signals | Execution style |
|---|
| Trivial | Small fix, rename, typo, one-file change | Single agent |
| Standard | Clear feature or bugfix across a few files | Single agent plus 1-2 sidecar agents |
| Complex | Multiple subsystems, unclear approach, risky refactor | Coordinator plus several subagents |
| Deep | Cross-cutting architecture or high-stakes migration | Heavy planning plus worker split |
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
