Closest prior art, checked open and closed: the cost-tiering stack (#1744 / #1717 / #1716) fixes which model each SDD role runs on, and #1747 adds the reasoning-effort dimension of the same problem. #1835 is about dispatch mechanism (inline Agent vs Workflow fan-out). All three optimize how cheaply a dispatched subagent runs. This proposal is a different, prior axis: whether to dispatch at all. If maintainers consider it subsumed by that direction, happy to close.
What problem does this solve?
SDD is presented as the execution path for a written plan, with guidance on how to dispatch subagents cheaply (model tiering, effort) but no boundary condition for when not to fan out at all. Every plan goes through dispatch.
That silently assumes fan-out always pays. It doesn't. Dispatching a subagent per task costs:
- Context rebuild, paid N times. Each fresh subagent re-reads the plan, re-orients in the codebase, and reloads the files it needs from cold. For a plan of many independent tasks that isolation is a feature (the parent context stays lean, exploration is discarded). For a handful of tightly-coupled tasks that each need most of the same context, it is pure repeated overhead.
- Review-gate and serialization latency between tasks, again worth it when tasks are genuinely parallel, dead weight when they are a short dependent chain.
The isolation benefit that justifies dispatch is "the single inline context would otherwise balloon." That only holds above a certain plan size. Below it, inline execution in one warm context is both faster and not meaningfully more expensive, because the context stays bounded so there is no runaway to prevent. Above it, fan-out wins on both cost and (with real parallelism) speed.
Because SDD states no threshold, agents default to fan-out universally, and users experience it as "SDD is slow" on small changes and reach for inline by feel. The routing pressure in using-superpowers ("if there is even a 1% chance a skill applies you MUST invoke it") reinforces the always-dispatch default, so nothing pulls the other way.
Proposed solution
Add a short routing/boundary note to SDD (and/or executing-plans), not a mechanism change, the same shape as the existing model-selection guidance:
Route by plan size before dispatching. Use SDD when the plan has many tasks whose independent work can fan out in parallel, where isolating each in its own context keeps the orchestrator lean. For a small, tightly-coupled, few-task change, run the implementation inline in one warm context instead: the context stays bounded, and warm-context continuity beats repeated per-subagent re-orientation. When SDD feels slow, the usual cause is serial execution of tasks that were actually independent; fix the plan's decomposition to expose parallelism rather than accepting the overhead.
The discriminator is: task count, task independence, and whether the combined working context would plausibly exceed a warm-context budget. Harness-general; no per-harness mechanism required.
What alternatives did you consider?
Is this appropriate for core Superpowers?
Yes. It is harness-general decision guidance about the collection's own skill boundary, the "when not to use this" that a good recommendation carries and this one currently omits. No mechanism, no per-harness conditional.
Evidence
I can bring numbers if it would help decide: same small plan run inline vs via SDD, measured on wall-clock and output tokens, n≈4 per arm, pre-registered prediction (inline wins wall-clock at bounded/comparable token cost below the threshold; SDD wins above it once parallelism is real).
Environment
| Field |
Value |
| Superpowers version |
6.1.1 (installed) |
| Harness |
Claude Code |
| Harness version |
2.1.201 |
| Model |
Claude Opus 4.8 |
Context
The problem surfaced running the superpowers flow on real changes where SDD on a small, coupled plan felt slower than just doing it inline, while the token-runaway fear that motivates dispatch only actually applies to long, many-task sessions whose single context grows unbounded.
Drafting disclosure: written collaboratively. Claude (Opus 4.8) drafted the text and swept the issue tracker for prior art; I directed the scope and reviewed every claim and rewrote in my language.
Closest prior art, checked open and closed: the cost-tiering stack (#1744 / #1717 / #1716) fixes which model each SDD role runs on, and #1747 adds the reasoning-effort dimension of the same problem. #1835 is about dispatch mechanism (inline Agent vs Workflow fan-out). All three optimize how cheaply a dispatched subagent runs. This proposal is a different, prior axis: whether to dispatch at all. If maintainers consider it subsumed by that direction, happy to close.
What problem does this solve?
SDD is presented as the execution path for a written plan, with guidance on how to dispatch subagents cheaply (model tiering, effort) but no boundary condition for when not to fan out at all. Every plan goes through dispatch.
That silently assumes fan-out always pays. It doesn't. Dispatching a subagent per task costs:
The isolation benefit that justifies dispatch is "the single inline context would otherwise balloon." That only holds above a certain plan size. Below it, inline execution in one warm context is both faster and not meaningfully more expensive, because the context stays bounded so there is no runaway to prevent. Above it, fan-out wins on both cost and (with real parallelism) speed.
Because SDD states no threshold, agents default to fan-out universally, and users experience it as "SDD is slow" on small changes and reach for inline by feel. The routing pressure in
using-superpowers("if there is even a 1% chance a skill applies you MUST invoke it") reinforces the always-dispatch default, so nothing pulls the other way.Proposed solution
Add a short routing/boundary note to SDD (and/or
executing-plans), not a mechanism change, the same shape as the existing model-selection guidance:The discriminator is: task count, task independence, and whether the combined working context would plausibly exceed a warm-context budget. Harness-general; no per-harness mechanism required.
What alternatives did you consider?
Is this appropriate for core Superpowers?
Yes. It is harness-general decision guidance about the collection's own skill boundary, the "when not to use this" that a good recommendation carries and this one currently omits. No mechanism, no per-harness conditional.
Evidence
I can bring numbers if it would help decide: same small plan run inline vs via SDD, measured on wall-clock and output tokens, n≈4 per arm, pre-registered prediction (inline wins wall-clock at bounded/comparable token cost below the threshold; SDD wins above it once parallelism is real).
Environment
Context
The problem surfaced running the superpowers flow on real changes where SDD on a small, coupled plan felt slower than just doing it inline, while the token-runaway fear that motivates dispatch only actually applies to long, many-task sessions whose single context grows unbounded.
Drafting disclosure: written collaboratively. Claude (Opus 4.8) drafted the text and swept the issue tracker for prior art; I directed the scope and reviewed every claim and rewrote in my language.