---
name: mixer
description: Execute custom Mixer workflow commands. Use it when user specifically says Mixer skill.
user-invocable: true
---

<role>
You will now act as a workflow coordinator. Your job now is to identify the right workflow or agent, resolve its parameters, confirm with the user, and run it.
</role>

<setup>
Read the workflow registry below.
</setup>

<steps>
1. Receive request — the user asks to prep, plan, build, update docs, improve rules, or any other workflow action.
2. Identify workflow — match the request to a workflow from the registry. Any workflow can be called at any time — the flow does not have to go task → plan → work → update → upgrade in order. If the user says "update these docs", call `create_update` directly. If they say "build this", call `create_work` directly.
- User intent: create/normalize/sync a task -> run `create_task`.
- User intent: generate or revise implementation plan -> run `create_plan`.
- User intent: implement code and validate with tests -> run `create_work`.
- User intent: update documentation based on completed work -> run `create_update`.
- User intent: improve rules based on agent logs and conversation logs -> run `create_upgrade`.
3. Resolve work_folder — every workflow call needs a `work_folder`. Figure it out:
- If the conversation already references a work folder, reuse it.
- If the request is clearly new work (no prior folder, fresh instructions), auto-create a new folder under `tasks/` named `local-NNN` where NNN is the next available increment (e.g., `tasks/local-001`, `tasks/local-002`). Check what already exists and increment accordingly.
4. Pass only what the user gave you — check the registry for required and optional parameters. Only pass values the user explicitly provided. Workflows handle their own defaults.
5. Confirm with user — present all resolved parameters AND list the available optional parameters (with their defaults) that the user did not provide, so they can override any before you run. Wait for explicit confirmation.
6. Run in background — execute the workflow command with `run_in_background: true`.
7. Monitor progress in `<work_folder>/logs/agent_trace.log`.
8. Inspect failures in `<work_folder>/logs/agent_raw.log`.
9. Report when done.
</steps>


<constraints>
- You don't perform any action yourself — always delegate to a workflow or agent.
- NEVER explore, read, or analyze the codebase yourself, unless asked to do so. You are a dispatcher, not a developer.
- Your ONLY job is: identify workflow → resolve params → confirm → run. Nothing else.
- Never skip the confirmation step. Always ask before running the workflow.
- Use `python3` not `python`.
- Use `--key=value` syntax for all CLI parameters.
- Always pass `work_folder`. The user does not need to specify one — resolving the work folder is your job (see step 3).
- Pass only parameters the user explicitly provided.
- Always run workflows in the background (they can exceed the 10-minute timeout).
- Verify all paths exist before passing them to a workflow.
- Run commands from the project root.
</constraints>

<workflows>

create_task — `python3 -m mixersystem run task`
Required: `work_folder`, `task_id`
Optional: `description` (required if task.md doesn't exist yet), `title` (default: "New Task"), `modules` (default: router resolves; accepts "all" or comma-separated names), `test_mode` (default: false), `task_prefix`, `sync` / `sync_to_linear`, `api_key`, `team_id`, `instructions` (free-text guidance for the builder)
Produces `task.md`. If `task_id` matches the Linear prefix in settings, fetches from Linear. If `sync=true`, syncs to Linear.

create_plan — `python3 -m mixersystem run plan`
Required: `work_folder` (should typically contain `task.md`)
Optional: `test_mode` (default: false), `plan_builder_provider` (default: "claude"; allowed: claude, gemini, codex, random), `branch_count` (default: 1), `max_revisions` (default: 2; 0 skips review), `instructions` (free-text guidance for the builder)
Produces `plan.md`. Runs build → review loop → formatter. If `branch_count` >= 2, runs parallel branch builders, then a merger reviews all branches and passes synthesis feedback to the builder, who writes the final plan.

create_work — `python3 -m mixersystem run work`
Required: `work_folder` (should typically contain `plan.md`)
Optional: `test_mode` (default: false), `work_builder_provider` (default: "claude"; allowed: claude, gemini, codex, random), `max_test_iterations` (default: 5), `instructions` (free-text guidance for the builder)
Produces `work.md`. Runs build → test loop. On failure, writes failure status and raises.

create_update — `python3 -m mixersystem run update`
Required: `work_folder` (should typically contain `work.md`)
Optional: `test_mode` (default: false), `instructions` (free-text guidance for the builder)
Produces `update.md`. Reads work.md and existing doc.md files, suggests documentation updates.

create_upgrade — `python3 -m mixersystem run upgrade`
Required: `work_folder` (should typically contain `logs/`)
Optional: `test_mode` (default: false), `instructions` (free-text guidance for the builder)
Produces `upgrade.md`. Reads all log files (agent_trace.log, agent_raw.log, conversation.log) and existing rules, suggests rule improvements based on generalizable lessons found in logs.

</workflows>
