# Aic Delegation Craft > Use when deciding which model-seat drives a piece of work in Cursor, setting up the operator's thinking-seat / execution-seat workflow, dispatching Composer subagents from an Opus session, configuring Custom Modes or the statusline for seat awareness, or recovering when an execution model misreads intent. Codifies the HOW of the AIC delegation protocol. Triggers on phrases like model routing, thinking seat, execution seat, Opus vs Composer, subagent dispatch, Custom Mode, statusline, switch back, misread recovery, delegate to AIC. Pairs with .cursor/rules/akos-aic-delegation.mdc (the WHEN); this skill is the HOW. - Skill: `tomevault-io/aic-delegation-craft` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/aic-delegation-craft` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/aic-delegation-craft/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/aic-delegation-craft --- # AIC Delegation Craft > The *how* layer paired with [`akos-aic-delegation.mdc`](../../rules/akos-aic-delegation.mdc). > The rule says *when* to route between seats; this skill shows *how* to do it > well, matched to the operator's working style (fast, messy, high-context > input). Ratified 2026-05-29 (DQ-TAX-04 advisory-only; F5 per `D-IH-84-C`). ## When to use this skill Read this before setting up the delegation workflow, dispatching subagents, or recovering from a misread. Assumes you have read the paired rule, which defines the two seats and the advisory non-goal (Cursor can't auto-switch the foreground model). ## The two seats, in plain terms | | Foreground thinking seat | Background execution seats | |:---|:---|:---| | Model class | Opus / thinking models | Composer-pinned subagents | | Best at | judgment, scope, doctrine, messy input, irreversible calls | bounded mechanical work against a settled plan | | The operator | talks to this seat first | rarely talks to directly; receives decomposed packets | | Cost posture | expensive — use deliberately | cheap — parallelise freely | The operator's deepest need: **stay messy in the thinking seat without guilt.** Dump high-context, multi-topic, typo-heavy input to Opus; let it sort, decompose, and dispatch. Do not make the operator pre-sort work into the "right" model. ## Principle — the seat frames, the operator decides The thinking seat does **not** "own" the decision; it *frames* it and hands the operator a clean choice with a recommended default. Judgment calls — which shape, which trade-off, go / hold — are the **operator's**, surfaced as an inline-ratify gate. Saying "let me switch to the thinking model to decide" is a category error: the model *structures* the call; the human *makes* it. (Worked example: the 2026-05-29 entity-registry shape — the seat laid out three options + a recommended default; the operator chose Option 1. The seat never needed to "decide" anything; it needed to make the decision easy.) ## Pattern 1 — Opening prompts that signal the seat (no model names needed) The operator should not have to remember model names. Teach these openers: - *"Think with me about ..."* / *"Help me decide ..."* / *"Is this coherent ..."* → thinking seat (judgment). - *"Go do ..."* / *"Apply ... across ..."* / *"Run the validators and fix ..."* → execution seat (mechanical), usually dispatched to subagents. If an opener is ambiguous, the thinking seat asks one clarifying question rather than guessing — cheaper than a misread. ## Pattern 2 — Decompose, then dispatch (the multitask shape) The high-leverage workflow: 1. **One Opus chat** receives the messy input and decomposes it into bounded packets — each packet names files, validators, decision IDs, acceptance check. 2. **N Composer subagents** (Task tool, `run_in_background: true`) each take one packet and execute in parallel. 3. **The Opus chat** collects the results and renders the verdict / synthesis — the judgment layer the execution seats should not own. Dispatch template (per subagent): > "Execute packet K: edit ``; the change is ``; run > ``; do NOT make judgment calls — if you hit an ambiguity or a > validator FAIL, stop and report. Return: files changed + validator result." The judgment ("is this the right change?") stays with the thinking seat; the execution ("make exactly this change") goes to the subagents. ## Pattern 3 — Assign the seat in each workflow (Agent / Plan / Multitask) The two-seat split is **operator-configurable in the UI + config**, not just an advisory recommendation. (Verified 2026-05-29 against Cursor Plan Mode docs + the 3.2 `/multitask` changelog — this corrects an earlier draft that framed subagents as the only lever.) Three workflows, three places to set the model: ### Agent mode — Custom Modes (save the setup once) Cursor Custom Modes preselect a model + instructions. Save two: - **Holistika Interpret** — Opus + "focus on judgment, scope, doctrine; decompose before delegating; surface decisions as inline-ratify gates." Pair with the research-action craft. - **Holistika Execute** — Composer + "make precise, settled changes; run validators; stop and report on any ambiguity or FAIL." Pair with this rule. Switch with the mode picker (or a keyboard shortcut) — a one-click seat change. ### Plan mode (`Shift+Tab`) — pick the planning model, then choose how to build The **planning model** is the model selector in the chat input — set it to Opus (or Codex) so judgment drives the plan. When the plan is ready you get two build buttons: - **Build Locally** — the foreground Agent (your picked execution model) runs it. - **Build in parallel** — kicks off `/multitask` (the execution fleet). The read-only *exploration* subagents Plan mode spawns to scout context have their own model at **Settings → Subagents → Explore subagent model** (default is a cheap model; leave it cheap). So the native pattern is literally: **Opus plans → build on Composer.** No vibes required. ### `/multitask` — pin per-subagent models in `.cursor/agents/` `/multitask` (Agents Window, Cursor 3.2+) runs an async fleet in worktrees. By default subagents **inherit** the parent model; to pin a seat per role, create one file per agent: ``` --- name: executor description: Mechanical multi-file edits + validators against a settled packet. model: composer-2.5 # inherit | fast | a slug that matches your picker readonly: false --- ``` - `model:` accepts `inherit`, `fast`, or an exact picker slug (e.g. `claude-4.6-opus-high-thinking`, `composer-2.5`, `gpt-5.3-codex-xhigh`). - **Caveat — verify it took:** in early `/multitask` the `model:` field was sometimes ignored and fell back to inherit (fix rolling in ~3.3). Check the request's model before trusting a per-seat pin on irreversible work. - A read-only `planner` / `reviewer` agent (`readonly: true`) on a thinking model is the safe first one to add — it can't write, so it can't break anything. ## Pattern 4 — Statusline (know which seat you're in) Configure the Cursor statusline via the **Cursor-bundled statusline skill** at `~/.cursor/skills-cursor/statusline/SKILL.md` (a built-in skill, **not** a repo skill) to show the active model + context-window %. Free, no tokens, persistent visual cue. Keep the config on the operator's machine; never commit machine-specific config or secrets. ## Pattern 5 — Misread recovery (the two-strike rule) If an execution seat misreads intent twice in a row: 1. Stop dispatching to it for this task class. 2. Escalate the session to the thinking seat. 3. Treat it as a knowledge-test signal (per the People agentic doctrine): the misread means doctrine absorption degraded for this task class; the thinking seat re-establishes the packet spec, then may re-dispatch. Two misreads is the trigger, not one — a single misread is noise; a pattern is signal. ## Pattern 6 — Make governance gates legible at build time A plan that contains an approval gate must make that gate the **explicit first todo**, clearly labelled (e.g. "⛔ OPERATOR APPROVAL — canonical-CSV gate"), so that pushing the build button never surprises the operator with an approval they did not know they owed. A buried gate produces exactly the friction the operator named on 2026-05-29 — *"I thought the plan was completely drafted and I wanted to push the build button … maybe it's me that didn't see I had to approve something."* That confusion is a workflow defect, not an operator error. Two clean ways to clear a gate before building: 1. **Pre-clear in chat** — the operator says "go,