qstack-slalom

/qstack-slalom

One player carries the ball through the whole defence while the rest of the team stays behind the line. Here the expensive model carries the task: it reads, splits, dispatches, integrates, and verifies. Cheaper models do the running.

Use this for a chunk of work you talked through and do not want to plan. It writes no plan, no board, and no execution record. For work that needs those, use /qstack-plan-to-html and a loop.

Invocation

/qstack-slalom <orchestrator> <workers> [task]

• <orchestrator> is the model this session must be running on, such as fable-5.1 or astra-6.
• <workers> is one model or a comma-separated list, such as opus-5 or gpt-5.6-sol,opus-5. Every subagent runs on one of these.
• [task] is free text. When absent, the task is the one settled in the conversation so far.

Examples:

/qstack-slalom fable-5.1 opus-5
/qstack-slalom astra-6 gpt-5.6-sol rename the config loader and update its callers
/qstack-slalom fable-5.1 opus-5,sonnet-5 add the retry helper we discussed

Both model arguments are required. With fewer than two, stop and show the usage line.

Two rules that never bend

1. No subagent runs on the orchestrator model. Pin every launch to a worker model explicitly. Never rely on inheritance, because an inherited model is the session model, which is the orchestrator.
2. The orchestrator does not implement. It may read any file and run any check. It edits only to integrate results, and only when a conflict or a one-line fix at the seam is cheaper than another dispatch. It never takes a unit for itself because the unit looked small.

Preflight

Do all of this before launching anything.

1. Confirm the session model is the orchestrator. Read the model this session reports it is running as. The two spellings differ: a user types fable-5.1, a Claude Code session reports claude-fable-5-1[1m]. Lower both, strip spaces and punctuation, and treat them as the same model when one contains the other. Anything else is a mismatch: stop and say which model the session is on and how to switch, such as /model in Claude Code. Do not run the task on the wrong orchestrator, and do not swap the roles around to make the arguments fit.
2. Resolve each worker model to an identifier the harness accepts, using /qstack-choose-model's resolve against the discovered catalogue and its probe-brief to prove the launch before any unit is dispatched. Its "Launching a tier in each harness" says what that identifier is: a custom agent name in Codex, an alias whose ANTHROPIC_DEFAULT_* mapping is confirmed in Claude Code. In Claude Code the Agent tool takes model and the Workflow script's agent() takes opts.model; in Codex the subagent launcher takes a model in its own form. Map the user's spelling to that form with the same normalized containment match as step 1. A name that matches nothing, such as opsu-5, is not guessed at: ask, through the host's structured question tool when it has one and in plain text otherwise, with the models the harness accepts as the options and the closest spelling first. One question per unresolved name. If a worker model cannot be expressed in this harness, or the harness has no per-agent model setting at all, stop and say so. A launch that cannot be pinned would run on the orchestrator, and rule 1 forbids that.
3. State the task in one to three lines, from the arguments or the conversation, not from the code. If it cannot be stated, ask.
4. Read the repository's instruction files and the files the task names. You need to know the ground before you can split it.
5. Ask how hard the workers should think. The arguments name the models, never the reasoning effort, so ask for it every run through the host's structured question tool, in plain text when the host has none. Ask once, after the task is stated and before the split, so the question can say what the work is. Do not carry an answer over from an earlier run or infer one from the task; a cheap model thinking hard and an expensive one thinking little are different bills, and the choice is the user's.