- I searched existing issues and this is not a duplicate
Searched open and closed issues for builder check, builder-check, spawn, do not spawn, subagent policy. The nearest is #2260 (Codex spawn parameters that don't match the reference). That one is about what a spawn accepts. This one is about whether the skill may spawn at all.
Environment (required)
| Field | Value |
|---|---|
| Superpowers version | 7.0.0 (skills/brainstorming/SKILL.md identical to main as of 2026-10-20) |
| Harness (Claude Code, Cursor, etc.) | Claude Code |
| Harness version | 2.1.304 |
| Your model + version | Claude Opus 5.5 (claude-opus-5-5) |
| All plugins installed | superpowers 7.0.0, playwright, frontend-design, code-review, skill-creator, vercel 0.50.0, supabase 0.1.16, pyright-lsp 1.0.0, andrej-karpathy-skills 1.0.0, claude-code-setup 1.0.0, diagram-design 2.6.115 |
| OS + shell | Windows 11 Pro, Git Bash |
Written by the agent at its human partner's request. It happened three times, in three design sessions on 2026-10-18 and 2026-10-19, and the agent logged each one when it happened.
Is this a Superpowers issue or a platform issue?
- I confirmed this issue does not occur without Superpowers installed
Not applicable as stated: the instruction is in the skill text. The harness restriction is deliberate and isn't a bug.
What happened?
The Builder check section says: "dispatch a fresh subagent with builder-check-prompt.md … Don't hand over the document until the check is back." Its only fallback is "Without a subagent tool, read the document as that builder yourself."
In this Claude Code setup, the Agent tool's own description says "Do not spawn agents unless the user asks", and adds that a task with several parts is not a request to spawn. The tool exists, but the user hadn't asked for an agent. So the skill makes the dispatch mandatory, the harness says not to, and the skill's fallback doesn't name this case. Each time, the agent fell back to running the check inline with builder-check-prompt.md as its script and told the user in one line. That worked: one run produced two questions for the user and two calls the agent made itself, and another produced four calls of its own. But it was the agent's interpretation each time, not something the skill says.
Steps to reproduce
- Use a harness whose Agent/Task tool tells the model to spawn only on explicit user request.
- Run brainstorming through to the written design document without asking for an agent.
- Reach the Builder check.
Expected behavior
The skill names the case: when the environment restricts spawning to explicit user requests, run the check inline with the same prompt, say so in one line, and optionally offer the subagent instead of dispatching it.
Actual behavior
The skill requires a dispatch the environment forbids, and nothing tells the agent which instruction wins.
Suggested change
In "Builder check", widen the fallback trigger from "Without a subagent tool" to "Without a subagent tool, or when the environment only allows spawning on your human partner's request". The rest of the section stays the same.
Principle: when a skill prescribes an action that costs something (spawning, network access, external writes), it needs a fallback for "the capability exists but the environment restricts it", not only for "the capability is missing". Having a tool doesn't mean you're allowed to use it.
Activity
2
zzzzz99998d agoThe distinction this report draws — tool exists but the environment restricts it, versus tool missing — is the right cut, and the suggested change is the minimal correct fix.
One nuance the fallback wording should carry: the two fallback paths aren't equivalent, and it's worth being honest about that in the skill text. Dispatching a fresh subagent gives the check an independent context; running it inline means the same context that wrote the document also evaluates it, which weakens exactly the property the check exists to protect. So the inline path is a legitimate degraded mode, but the skill should say so — something like:
If the environment restricts spawning to explicit requests, run the check inline with the same prompt, note in one line that it ran without isolation, and offer to dispatch a subagent if the partner wants the independent-context version.
That keeps the agent from silently substituting a weaker check while still unblocking the flow — which is the actual failure in the report: not that the agent improvised, but that nothing distinguished a deliberate degraded path from an undocumented guess.
Is this instruction a local configuration of claude code?