From 8d231f00d5405745afc3f07a19a06a34b0c0c58e Mon Sep 17 00:00:00 2001 From: Leo Kwan Date: Wed, 4 Nov 2026 15:14:32 -0500 Subject: [PATCH] Use T3 Code delegation and completion wakes when T3 Code hosts the chat Co-authored-by: Cursor --- pstack/skills/arena/SKILL.md | 2 +- pstack/skills/poteto-mode/SKILL.md | 2 ++ pstack/skills/swarm/SKILL.md | 2 +- 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/pstack/skills/arena/SKILL.md b/pstack/skills/arena/SKILL.md index 7580c3c9a..3ea3cab73 100644 --- a/pstack/skills/arena/SKILL.md +++ b/pstack/skills/arena/SKILL.md @@ -19,7 +19,7 @@ Every candidate gets the same prompt, so the prompt is the contract. ## Phase B: Fan out -Spawn all N subagents in one message with `run_in_background: true`, each with the task, the path to the shared grounding, its own output path, and instructions to produce the artifact and a short rationale naming the alternatives it considered and what it rejected. +Spawn all N subagents in one message with `run_in_background: true`, each with the task, the path to the shared grounding, its own output path, and instructions to produce the artifact and a short rationale naming the alternatives it considered and what it rejected. In T3 Code, spawn them as the poteto-mode **In T3 Code** rule says. If a candidate produces no output, proceed with N-1 and note the dropout. diff --git a/pstack/skills/poteto-mode/SKILL.md b/pstack/skills/poteto-mode/SKILL.md index 2dd5e76fd..17cbf2764 100644 --- a/pstack/skills/poteto-mode/SKILL.md +++ b/pstack/skills/poteto-mode/SKILL.md @@ -95,6 +95,8 @@ Read the leaf skill in full for any principle you apply. Each entry names when i **Defaults for every `Task` call.** `run_in_background: true` (a steer or resume of a running agent too, because a foreground call holds your turn while other reports wait), agent mode (readonly strips MCP), file pointers not inlined context, explicit model per role (configurable via `/setup-pstack`. Defaults `grok-4.7-xhigh-fast` for code, `claude-opus-5-5-xhigh` for prose and judgment). Code delegates tier by difficulty. The hardest changes (cross-cutting design, gnarly concurrency, subtle algorithms) go to your strongest judgment model (`claude-opus-5-5-xhigh`), whether the task needs judgment on vague intent or is a precisely specified sequence of steps to execute to the letter. Trivial mechanical edits go to your fast code model. Per-role lines in the `/setup-pstack` rule override these defaults and the model choices in the routed skills (`how`, `why`, `arena`, `swarm`, `architect`, `interrogate`, `reflect`). A role with no line keeps its default, and a role line of `inherit-parent` or `auto` runs that role on the parent chat model (omit Task `model`). Each code playbook's configured model comes from its line (`feature, refactoring`, `bug-fix`, `perf-issue`, or `hillclimb`), and the hardest changes read `hardest tasks`. Prose and judgment read `judgment and prose`. +**In T3 Code.** When `orchestrator_capabilities` is listed or loadable through ToolSearch, T3 Code hosts the chat and its orchestration instructions win over the `Task` defaults above. Spawn background or other-provider work with T3's `delegate_task` in `async` mode, not a background `Task` or `Agent`. A child's completion wakes you, so arm no `/loop` heartbeat or watcher for delegated children, even when someone asks for periodic check-ins. `/loop` and watchers stay for external events such as CI or a merge. + **Match the model to the job.** Before each spawn, start from the role's line or default and pick the reasoning level and speed the job needs. The `/setup-pstack` budget sets each role's starting level, xhigh by default. Raise it one step, up to max, for the hardest or subtlest work. Lower it one step for judgment and two or more steps for routine work. Use fast mode only when the job is urgent, meaning CI or trunk is red or a person is blocked on the result right now. Otherwise use standard speed, the same slug without `-fast`. Verification is the exception and stays on the `swarm workers` model and speed (`grok-4.7-xhigh-fast` by default). Change only the effort level and whether the slug is fast, and keep the family the role names, so a diverse panel stays diverse. If the family has no slug at that level and speed, use its nearest slug. A role on `auto` or `inherit-parent` stays on the parent model. If the Task tool rejects the adjusted slug, do not try another adjusted slug. Use the role's line or default and say so. If the Task tool rejects that too, continue with the calling skill's fallback. A slug counts as rejected once a Task error says that the model is not valid, or leaves the slug out of its list of valid slugs. Never pass a rejected slug, and skip any fallback whose slug is already rejected. When the calling skill has no fallback, use the closest valid slug of the role's family from the error's list of valid slugs, or omit `model` so the subagent runs on the parent model when the list has none. When the calling skill's fallback runs out of slugs without saying what to do next, omit `model` too. Say so in both cases. You own every subagent's work. Review the diff and write your own summary, don't pass through what it said. A second opinion is the same prompt against a different model. Agreement is high-signal. diff --git a/pstack/skills/swarm/SKILL.md b/pstack/skills/swarm/SKILL.md index 9cd32247b..5e54afebe 100644 --- a/pstack/skills/swarm/SKILL.md +++ b/pstack/skills/swarm/SKILL.md @@ -24,7 +24,7 @@ Open a todolist with one entry per phase before launching anything. ## Phase B: Fan out -Spawn all N workers in one message with `subagent_type: generalPurpose`, `environment: "cloud"`, `run_in_background: true`, and the step 3 model, left unset for `auto` or `inherit-parent`. Use `environment: "local"` only when the worker needs access to something on the user's computer. +Spawn all N workers in one message with `subagent_type: generalPurpose`, `environment: "cloud"`, `run_in_background: true`, and the step 3 model, left unset for `auto` or `inherit-parent`. Use `environment: "local"` only when the worker needs access to something on the user's computer. In T3 Code, spawn workers as the poteto-mode **In T3 Code** rule says. When a worker must start from a non-default pushed branch, pass `cloud_base_branch`.