Problem to Fix
The /delegate skill lets an operator carve a piece of work off during the planning gate and hand it to another agent. It explains thoroughly how to produce a delegation prompt — branch context, issue body, changed files, the rules the receiving agent must follow — but it says nothing about whether the work should be delegated in the first place. That judgement is left entirely to the operator, unassisted, at the exact moment they are already thinking about something else.
Two failure modes follow. The first is delegating work whose wrongness is expensive to detect: a change to authentication, permissions, a migration, or anything else carrying an invariant. When a delegated agent gets that subtly wrong, the cost is not the tokens, it is the regression you later have to go find. The second is delegating work whose briefing costs more than the work itself — a subtle change to a module that only makes sense given the last forty minutes of conversation. The delegated agent starts context-blind, and the operator spends longer writing the brief than they would have spent doing it.
Both failure modes are avoidable with a rule stated at the point of decision.
Why it Matters
This is the piece of the delegation question that stays true regardless of what the agent tooling does next. Which harness is running, whether it can spawn subagents, and what models it offers all change constantly. What does not change is which work in this particular workflow is safe to hand to someone — or something — that lacks the surrounding context. Code Cannon is the only layer that knows that, because it is the layer that knows the workflow.
Half the answer is already in the repo. The /story skill's pre-flight escalation check enumerates the sensitive surface — authentication, authorization, payments, billing, secrets, credentials, production configuration, destructive operations — and stops to ask the operator before proceeding. That is the same list a delegation decision needs, serving the same purpose. /delegate should reuse it rather than growing a second, separately-maintained copy that will drift.
The other half is the reason /delegate exists at all: it is a briefing tool. Making the briefing-cost trade explicit costs a short section and prevents the most common way delegation wastes time.
This came out of research into per-task model tiering, which was declined (see #181). The tiering machinery was the wrong thing to build; this judgement is the part worth keeping.
General Approach
Add a candidacy check to /delegate, before the prompt is generated, expressed as two filters the operator applies to the work they are about to carve off.
The first filter is review burden. Handing work to a cheaper, faster, or less context-aware agent is a good trade only where a wrong answer is verifiable in seconds — documentation and API lookups, dependency and changelog research, mechanical sweeps across many files, test scaffolding that follows an established pattern, inventory and audit passes. It is a bad trade for anything carrying an invariant, where a subtle wrong answer becomes a defect somebody has to hunt down later. Point at the sensitive-surface list the /story skill already maintains rather than restating it; if that list changes, both skills should change together.
The second filter is briefing cost. Delegation pays only when writing the task spec is cheap relative to the work being delegated. Work that can be described in a sentence and verified against an external source qualifies. Work that requires transplanting the current conversation's context does not — and note that this failure feeds the first filter, because a context-blind agent produces exactly the kind of plausible-but-wrong output that is expensive to review.
When work fails either filter, /delegate should say so and let the operator override rather than refusing. The operator holds the judgement; the skill supplies the check.
One hard constraint on the wording: never name a model, a model tier, a price point, or a vendor. Phrase the outcome in terms of the work — low-risk and cheaply verifiable, or not — and leave the choice of what executes it to the operator and their harness. This is what keeps the guidance from expiring. If harnesses begin routing this kind of work automatically, correctly-worded guidance becomes redundant; guidance naming models becomes wrong.
Optionally, carry the same judgement into ticket creation: a short candidacy note written by /start would let /story see it at its existing pre-flight check without any new machinery. Treat this as a follow-on only if the /delegate change proves useful in practice — it is not required for this ticket to deliver value.
Complexity
Verification / QA effort: light
Prose changes to one skill body, with a cross-reference to an existing list in another. No engine changes, no new configuration, no new placeholders. Verification is exercising /delegate during a real planning gate against work that should pass the filters and work that should fail them, and confirming the guidance fires correctly and remains overridable.
Acceptance Criteria
/delegate states both filters — review burden and briefing cost — before generating a delegation prompt.- The sensitive-surface list is referenced from the
/story skill's existing escalation triggers rather than duplicated.
- Failing either filter produces a warning the operator can override, not a refusal.
- No model name, tier name, vendor name, or price consideration appears anywhere in the added wording.
- No new configuration placeholder is introduced.
- Exercised during a real
/start planning gate on both a passing and a failing case.
./sync.py --force is run and the regenerated adapter output is committed alongside the source change.
Problem to Fix
The
/delegateskill lets an operator carve a piece of work off during the planning gate and hand it to another agent. It explains thoroughly how to produce a delegation prompt — branch context, issue body, changed files, the rules the receiving agent must follow — but it says nothing about whether the work should be delegated in the first place. That judgement is left entirely to the operator, unassisted, at the exact moment they are already thinking about something else.Two failure modes follow. The first is delegating work whose wrongness is expensive to detect: a change to authentication, permissions, a migration, or anything else carrying an invariant. When a delegated agent gets that subtly wrong, the cost is not the tokens, it is the regression you later have to go find. The second is delegating work whose briefing costs more than the work itself — a subtle change to a module that only makes sense given the last forty minutes of conversation. The delegated agent starts context-blind, and the operator spends longer writing the brief than they would have spent doing it.
Both failure modes are avoidable with a rule stated at the point of decision.
Why it Matters
This is the piece of the delegation question that stays true regardless of what the agent tooling does next. Which harness is running, whether it can spawn subagents, and what models it offers all change constantly. What does not change is which work in this particular workflow is safe to hand to someone — or something — that lacks the surrounding context. Code Cannon is the only layer that knows that, because it is the layer that knows the workflow.
Half the answer is already in the repo. The
/storyskill's pre-flight escalation check enumerates the sensitive surface — authentication, authorization, payments, billing, secrets, credentials, production configuration, destructive operations — and stops to ask the operator before proceeding. That is the same list a delegation decision needs, serving the same purpose./delegateshould reuse it rather than growing a second, separately-maintained copy that will drift.The other half is the reason
/delegateexists at all: it is a briefing tool. Making the briefing-cost trade explicit costs a short section and prevents the most common way delegation wastes time.This came out of research into per-task model tiering, which was declined (see #181). The tiering machinery was the wrong thing to build; this judgement is the part worth keeping.
General Approach
Add a candidacy check to
/delegate, before the prompt is generated, expressed as two filters the operator applies to the work they are about to carve off.The first filter is review burden. Handing work to a cheaper, faster, or less context-aware agent is a good trade only where a wrong answer is verifiable in seconds — documentation and API lookups, dependency and changelog research, mechanical sweeps across many files, test scaffolding that follows an established pattern, inventory and audit passes. It is a bad trade for anything carrying an invariant, where a subtle wrong answer becomes a defect somebody has to hunt down later. Point at the sensitive-surface list the
/storyskill already maintains rather than restating it; if that list changes, both skills should change together.The second filter is briefing cost. Delegation pays only when writing the task spec is cheap relative to the work being delegated. Work that can be described in a sentence and verified against an external source qualifies. Work that requires transplanting the current conversation's context does not — and note that this failure feeds the first filter, because a context-blind agent produces exactly the kind of plausible-but-wrong output that is expensive to review.
When work fails either filter,
/delegateshould say so and let the operator override rather than refusing. The operator holds the judgement; the skill supplies the check.One hard constraint on the wording: never name a model, a model tier, a price point, or a vendor. Phrase the outcome in terms of the work — low-risk and cheaply verifiable, or not — and leave the choice of what executes it to the operator and their harness. This is what keeps the guidance from expiring. If harnesses begin routing this kind of work automatically, correctly-worded guidance becomes redundant; guidance naming models becomes wrong.
Optionally, carry the same judgement into ticket creation: a short candidacy note written by
/startwould let/storysee it at its existing pre-flight check without any new machinery. Treat this as a follow-on only if the/delegatechange proves useful in practice — it is not required for this ticket to deliver value.Complexity
Verification / QA effort: light
Prose changes to one skill body, with a cross-reference to an existing list in another. No engine changes, no new configuration, no new placeholders. Verification is exercising
/delegateduring a real planning gate against work that should pass the filters and work that should fail them, and confirming the guidance fires correctly and remains overridable.Acceptance Criteria
/delegatestates both filters — review burden and briefing cost — before generating a delegation prompt./storyskill's existing escalation triggers rather than duplicated./startplanning gate on both a passing and a failing case../sync.py --forceis run and the regenerated adapter output is committed alongside the source change.