# Melt

> 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.

- Skill: `olivier-motium/melt` (Agent Skill)
- Install (CLI): `npx skillmds@latest add olivier-motium/melt`
- Raw SKILL.md: https://api.skillmd.com/api/skills/olivier-motium/melt/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: olivier-motium (https://skillmd.com/u/olivier-motium)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/olivier-motium/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:

```text
[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:

```text
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:

```bash
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