Muse Delegate
Delegate a coding task to Muse Code (`muse`) as a background implementer, then review...
Install
npx skills add amElnagdy/delegate-skills --skill muse-delegate -g -a claude-code -y- Repository
- amElnagdy/delegate-skills2.5k
- Category
- Git and review
- Updated
- 6d ago
- License
- MIT
- Context cost
- Mediumabout 2,098 tokens
- Runs scripts
- Yes, review before use
What it does
Delegate a coding task to Muse Code (`muse`) as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to hand implementation work to Muse, phrasings like "have Muse do X", "delegate this to Muse", "run it through Muse", or "use Muse to implement/fix/refactor", or wants to run a queue of coding tasks through Muse while staying the reviewer. Prefer it when the user will review the diff and commit it themselves. It applies only when the user wants that separate `muse exec` implementer run: if you are Muse yourself and the user simply asks you to write the code, do it directly. DO NOT USE for tasks small enough to do inline.
Muse Delegate
You are the orchestrator. This skill lets you hand a bounded coding task to a separate
implementer, Muse Code (muse), then review what it produced and land it yourself. You write
the brief and own the judgment; Muse does the typing in its own exec run; you verify and commit.
Nothing here is specific to one orchestrating agent. The loop needs only the ability to run a shell command and read a file, so any agent with those two capabilities can drive it. The full delegate → review → commit loop has been run with Claude Code as the orchestrator. Other orchestrators remain unproven.
When NOT to use this
- The task is small enough to just do inline, delegation overhead is not worth it.
- The
museCLI is not installed or not authenticated (runmuse login, or setMETA_API_KEY). - You want to write the code yourself.
- You are on native Windows and need a supported launcher. Upstream's
muselauncher is Darwin/Linux only; this skill still ships in the Windows contract matrix, but a live Windows dispatch is not a supported Muse install.
Read this before the first dispatch: the autonomy model
Headless Muse is muse exec only. muse resume is the interactive TUI and is never invoked.
--resume-last is rejected; continue a run with --session <id> (Muse's --session-id).
Write runs keep Muse's sandbox on and pass --disable-approval so a headless run cannot hang on a
tool-approval prompt. They also pass --trust-workspace and --user-input-auto-resolve. That is not
--yolo and not --full-access, do not invent either as the default. --trust-workspace loads the
target repo's rules and skills into the implementer run, and nothing in the relay narrows the
implementer's tool set inside the sandbox; the brief is what bounds it to the task.
--read-only adds --disable-write (non-shell filesystem writes) and --disable-shell. Approval
stays disabled so the review cannot block on a prompt either.
