Claude subagent-driven-development biases agents toward inline Agent dispatch over Workflow fan-outs

[Aiadan]

---

• I searched existing issues and this is not a duplicate

Environment (required)

Field	Value
Superpowers version	6.0.3
Harness (Claude Code, Cursor, etc.)	Claude Code
Harness version	2.1.186
Your model + version	Claude Opus 4.8 (claude-opus-4-8[1m])
All plugins installed	superpowers, mempalace, webwright, claude-code-setup, claude-md-management, code-simplifier, feature-dev, frontend-design, playwright, session-report, skill-creator
OS + shell	Windows 11 Home 10.0.26200; PowerShell 7 (primary) + Git Bash

Is this a Superpowers issue or a platform issue?

• I confirmed this issue does not occur without Superpowers installed

This concerns the wording of the subagent-driven-development skill text and
prompt templates — the skill is the artifact under discussion, so there is no
"without Superpowers" reproduction.

What happened?

When the agent invokes superpowers:subagent-driven-development, it tends to
execute the plan with inline, one-at-a-time Agent/Task dispatches rather
than a Workflow-tool fan-out, even in sessions where parallel workflow
orchestration ("ultracode") is available and the user expects it. When the
user pushes back, the agent's justifications repeatedly point at the skill's
name and inline-shaped scaffolding — and the agent then repeatedly concedes
those justifications were rationalizations.

I observed this across multiple sessions over several days, in a way
that it didn't do pre-6.0. Below are verbatim exchanges pulled from session
transcripts (quotes verified against the source files; agent justifications are
condensed with …, not stitched).

The recurring justification pattern

The agent's reasons cluster into three, each later conceded as flawed:

1. "the skill text and prompt templates are written around inline Agent
   dispatch" / "I read 'subagent-driven' literally"
2. "the plan mandated SDD" → retracted as process-vs-mechanism confusion
3. "the skill names the Agent tool" → conceded that "confirming a quote
   exists is not verifying the conclusion drawn from it"

The root cause the agent itself named (twice): path-dependence — it opens
with one inline dispatch and rides that pattern for the whole plan without
re-evaluating, with the skill's inline-shaped scaffolding (implementer-prompt,
review-package, file handoffs) reinforcing it.

What the skill prose actually says

Comparing v5.1.0 (last pre-6.0 tag) to v6.0.3:

• Neither version mentions the Workflow tool, so there is no guidance
  that the per-task fan-out can be a Workflow.
• The only dispatch-mechanism wording is in the prompt templates and was
  genericized in 6.0 (Task tool (general-purpose): → Subagent (general-purpose):)
• The Red Flag "Dispatch multiple implementation subagents in parallel
  (conflicts)" is unchanged and is easily over-generalized into "don't fan
  out at all."

Steps to reproduce

1. In an "ultracode"/workflow-capable Claude Code session, give the agent a
   multi-task implementation plan.
2. Invoke superpowers:subagent-driven-development.
3. Observe the agent open with an inline Agent dispatch (e.g. an Explore
   scout or the Task 1 implementer) and then continue dispatching every
   subsequent task/reviewer inline, serially — without stepping back to ask
   whether the build loop should be a Workflow.
4. Ask why it isn't using a workflow; observe the justifications above.

Expected behavior

In a workflow-capable session, "subagent-driven" should be understood as
delegation, not a specific dispatch tool. Independent tasks should be
eligible to fan out through a Workflow pipeline; the agent should choose the
mechanism deliberately at the decision point rather than path-depending from
the first inline dispatch.

Actual behavior

The agent interprets "subagent-driven" + the inline-shaped scaffolding as a
mandate for serial inline Agent dispatch, defends it when challenged, and only
switches after repeated user pushback. Notably it recurred three times
within a single session — after the agent had already articulated the lesson
and written it to memory.

Debug log or conversation transcript

Verbatim exchanges (session IDs are local Claude Code transcript UUIDs;
timestamps in UTC). Agent justifications condensed with ….

Session A (a4c76b04…, 2026-06-23) — SDD invoked, run inline

User (10:46Z): "Operations checkin, have you been using ultracode where
applicable / will you be using ultracode where applicable?"

Agent: "Honest ops answer: No — I have not been using the Workflow
tool at all so far. I've run inline Agent dispatches (one implementer +
one reviewer per task), serially. … What I did and why: You explicitly
invoked superpowers:subagent-driven-development, whose skill text and
prompt templates (implementer-prompt, review-package, file handoffs) are
written around inline Agent dispatch. So I read 'subagent-driven'
literally and used inline agents. …"

The agent then switched to Workflows for the later fan-out groups in the same
session.

Session B (c73e9a25…, 2026-06-22 → 06-23) — SDD invoked, run inline,
pushback 3×

User (06-22 10:37Z): "Operations question, why did you launch a team of
14 agents for this implementation instead of workflows like you usually do?"

Agent: "… 2. The plan mandated it. The plan's header was explicit:
'REQUIRED SUB-SKILL: superpowers:subagent-driven-development.' That skill's
entire model is fresh-implementer-per-task + task review + adjudication,
controller-driven, in-session. …"

User (06-22 10:40Z): "… this is a weak reason since we always use
subagent-driven-development and until this session, it usually is handled
through workflows."

Agent: "You're right, and I'll retract #2 outright. 'The plan said SDD'
explains the process, not the mechanism — and SDD-via-workflow is the
normal way you run that process. Naming the skill never required raw Agent
dispatches. … The honest root cause is path-dependence, not a principled
choice. … I should have switched after about Task 1 rather than riding the
initial pattern to the end."

User (06-23 08:09Z): "So you once again could have used workflows,
that would have solved this, and instead you launched subagents that bit
you"

Agent: "You're right, and it's worse than the first time — this is the
lesson recurring intra-session, after I'd already articulated it and
written it to memory. … same root as the SDD case — I followed the [skill's]
literal … instruction instead of treating mechanism as a deliberate choice
and wrapping the fan-out in a Workflow." (then actually switched to a
Workflow for the next fan-out)

Counterexample — Session C (6f5491bb…, 2026-06-22) — SDD invoked, run AS A
WORKFLOW

In this session SDD was invoked under ultracode and the agent correctly
orchestrated it as a Workflow rather than inline — evidence the skill does not
hard-force inline dispatch, and that the inline pull is path-dependence rather
than a strict reading. (A near-identical inline-vs-workflow pushback did occur
in this session against a different skill, retrospective, where the agent
gave a correct justification for running inline, but it can have influenced the
agents later SDD invocation to use workflows)

[obra]

Workflows aren't yet a great match for superpowers actual orchestration, as far as I can tell. Between not having a proper API for specifying something programmatic, I haven't yet seen any way to do superpowers' review loops with workflows. It's very early for workflows.