Summary
discipline:sweep-all's entire batched pass depends on Agent({subagent_type: "fork"}) for its per-corrector audit fan-out. When CLAUDE_CODE_FORK_SUBAGENT is off (observed this session, Claude Code 2.1.220, variable unset), the skill correctly reports "the fan-out cannot run" per its own documented gotcha and stops — but the net, practical effect in an unattended /loop/autonomous context is that the skill runs and accomplishes nothing, with no cheap fallback exercised despite the skill's own text elsewhere sanctioning inline direct corrector invocation as a valid pattern.
What happened this session
/discipline:sweep-all was invoked once at cycle root (per its own "once per cycle" instruction) inside an unattended, multi-hour autonomous /loop session. Agent({subagent_type: "fork", ...}) returned Agent type 'fork' not found. The skill's own gotcha text was followed correctly (report and stop rather than substitute a context-blind fresh subagent for the conversation-inheriting audit fork it requires) — this is NOT a mis-implementation of the documented contract. The problem is the contract itself: in an environment where forks are unavailable, sweep-all has zero degrade path, and nothing surfaced that dependency before the round-trip was spent.
Finding 1 (CRITICAL) — silent-in-practice degrade
"Report the fan-out can't run and stop" is correct behavior per spec, but functionally indistinguishable from silence in an unattended context with no human reading the stop message. Given the skill's own documented cost profile (each fork consumes ~170K tokens of inherited transcript; an 8-in-scope pass runs ~1.4M tokens for the audit phase alone), the ABSENCE of a cheap fallback means every invocation in a fork-unavailable environment either burns the full cost for nothing, or (as here) is caught early but delivers zero value either way.
Finding 2 (IMPORTANT) — the "fork vs. blind fresh-subagent" framing is a false dichotomy
The skill's own body text elsewhere sanctions each corrector being invoked directly, inline, one at a time (the shared method doc's normal per-corrector loop) — the salience-dilution rationale that motivates the FORK-based batching specifically covers PARALLEL correction (step 4, "correct once, in rank order"), not a sequential inline audit-then-correct pass. A degraded mode that falls back to running each in-scope corrector's audit+correct loop directly, inline, in rank order — accepting the salience-dilution tradeoff as a documented, deliberate degrade rather than the parallel-batched ideal — would still deliver most of sweep-all's value when forks are unavailable, instead of none. This is a design suggestion, not a reproduced failure mode on its own — filed as IMPORTANT, not CRITICAL, since it has no independent user-visible breakage beyond Finding 1's.
Finding 3 (IMPORTANT) — fork dependency is documented, but only after the round-trip is already committed
Correction to an earlier draft of this report: the fork dependency IS documented — sweep-all's own SKILL.md names it explicitly (the gotcha describing CLAUDE_CODE_FORK_SUBAGENT and the fallback-to-fresh-general-purpose behavior). The real gap is where: it lives in the skill BODY, which only loads once a user has already decided to invoke the skill — nothing in sweep-all's description/listing entry (what a user sees BEFORE invoking) mentions the dependency or its failure mode. Recommend surfacing a one-line caveat in the description itself, so the tradeoff is visible before the round-trip is spent, not just after.
Finding 4 (SUGGESTION)
A pre-flight $CLAUDE_CODE_FORK_SUBAGENT check is cheap and authoritative when the variable is explicitly 0/1 — official docs (code.claude.com/docs/en/sub-agents, fetched 2026-07-26) confirm 1=on, 0=off — but genuinely ambiguous when unset (as observed this session, Claude Code 2.1.220), where a real attempted dispatch may still be the only fully authoritative test. A pre-flight check could still cheaply short-circuit the explicit-0 case.
Finding 5 (CRITICAL, cross-plugin) — discipline and discovery hold contradictory claims about fork-subagent default-on timing
discipline and discovery@melodic-software v0.9.1's setup skill hold contradictory claims about whether fork-subagent-type dispatch has been on-by-default since Claude Code v2.1.161. This session's empirical failure (Claude Code 2.1.220, fork unavailable, variable unset) is consistent with discipline's more cautious framing, not discovery's "stale to gate on this" claim — but a proper resolution needs someone with authority over both plugins' docs to reconcile, not a unilateral pick by an audit run. Filed CRITICAL because acting on the wrong claim (assuming forks are reliably available when they empirically are not, in a real recent Claude Code build) is exactly what produces Finding 1's silent-degrade failure mode in practice. Recommend a maintainer conversation between whoever owns discipline and discovery docs.
Severity
CRITICAL (Findings 1, 5), IMPORTANT (Findings 2, 3), SUGGESTION (Finding 4) — severities as originally assigned by the dispatched auditor; a mid-drafting pass initially mis-bucketed these (swapping Finding 2 into a CRITICAL slot and Finding 5 into an IMPORTANT slot) and that miscount has been corrected here to match the auditor's actual assignment.
Provenance
Surfaced by /plugin-quality:audit, session-loop-audit run, dispatched via the plugin's auditor agent. Corrected during pre-publication review: Finding 3's original framing incorrectly claimed the fork dependency was undiscoverable anywhere in the skill; it IS in the skill body, just not the pre-invocation description — restated above. The official-docs citation for CLAUDE_CODE_FORK_SUBAGENT is code.claude.com/docs/en/sub-agents (documents the 1/0 values); a separate env-var reference page carries no entry for it as of this session.
Blindspots noted by the original auditor: fork-reproduction was not independently re-attempted from within that auditor's own dispatch context; a marketplace-wide grep found no other installed plugin sharing this exact runtime dependency.
Summary
discipline:sweep-all's entire batched pass depends onAgent({subagent_type: "fork"})for its per-corrector audit fan-out. WhenCLAUDE_CODE_FORK_SUBAGENTis off (observed this session, Claude Code 2.1.220, variable unset), the skill correctly reports "the fan-out cannot run" per its own documented gotcha and stops — but the net, practical effect in an unattended/loop/autonomous context is that the skill runs and accomplishes nothing, with no cheap fallback exercised despite the skill's own text elsewhere sanctioning inline direct corrector invocation as a valid pattern.What happened this session
/discipline:sweep-allwas invoked once at cycle root (per its own "once per cycle" instruction) inside an unattended, multi-hour autonomous/loopsession.Agent({subagent_type: "fork", ...})returnedAgent type 'fork' not found. The skill's own gotcha text was followed correctly (report and stop rather than substitute a context-blind fresh subagent for the conversation-inheriting audit fork it requires) — this is NOT a mis-implementation of the documented contract. The problem is the contract itself: in an environment where forks are unavailable,sweep-allhas zero degrade path, and nothing surfaced that dependency before the round-trip was spent.Finding 1 (CRITICAL) — silent-in-practice degrade
"Report the fan-out can't run and stop" is correct behavior per spec, but functionally indistinguishable from silence in an unattended context with no human reading the stop message. Given the skill's own documented cost profile (each fork consumes ~170K tokens of inherited transcript; an 8-in-scope pass runs ~1.4M tokens for the audit phase alone), the ABSENCE of a cheap fallback means every invocation in a fork-unavailable environment either burns the full cost for nothing, or (as here) is caught early but delivers zero value either way.
Finding 2 (IMPORTANT) — the "fork vs. blind fresh-subagent" framing is a false dichotomy
The skill's own body text elsewhere sanctions each corrector being invoked directly, inline, one at a time (the shared method doc's normal per-corrector loop) — the salience-dilution rationale that motivates the FORK-based batching specifically covers PARALLEL correction (step 4, "correct once, in rank order"), not a sequential inline audit-then-correct pass. A degraded mode that falls back to running each in-scope corrector's audit+correct loop directly, inline, in rank order — accepting the salience-dilution tradeoff as a documented, deliberate degrade rather than the parallel-batched ideal — would still deliver most of
sweep-all's value when forks are unavailable, instead of none. This is a design suggestion, not a reproduced failure mode on its own — filed as IMPORTANT, not CRITICAL, since it has no independent user-visible breakage beyond Finding 1's.Finding 3 (IMPORTANT) — fork dependency is documented, but only after the round-trip is already committed
Correction to an earlier draft of this report: the fork dependency IS documented —
sweep-all's ownSKILL.mdnames it explicitly (the gotcha describingCLAUDE_CODE_FORK_SUBAGENTand the fallback-to-fresh-general-purpose behavior). The real gap is where: it lives in the skill BODY, which only loads once a user has already decided to invoke the skill — nothing insweep-all'sdescription/listing entry (what a user sees BEFORE invoking) mentions the dependency or its failure mode. Recommend surfacing a one-line caveat in the description itself, so the tradeoff is visible before the round-trip is spent, not just after.Finding 4 (SUGGESTION)
A pre-flight
$CLAUDE_CODE_FORK_SUBAGENTcheck is cheap and authoritative when the variable is explicitly0/1— official docs (code.claude.com/docs/en/sub-agents, fetched 2026-07-26) confirm1=on,0=off — but genuinely ambiguous when unset (as observed this session, Claude Code 2.1.220), where a real attempted dispatch may still be the only fully authoritative test. A pre-flight check could still cheaply short-circuit the explicit-0case.Finding 5 (CRITICAL, cross-plugin) —
disciplineanddiscoveryhold contradictory claims about fork-subagent default-on timingdisciplineanddiscovery@melodic-softwarev0.9.1'ssetupskill hold contradictory claims about whether fork-subagent-type dispatch has been on-by-default since Claude Code v2.1.161. This session's empirical failure (Claude Code 2.1.220, fork unavailable, variable unset) is consistent withdiscipline's more cautious framing, notdiscovery's "stale to gate on this" claim — but a proper resolution needs someone with authority over both plugins' docs to reconcile, not a unilateral pick by an audit run. Filed CRITICAL because acting on the wrong claim (assuming forks are reliably available when they empirically are not, in a real recent Claude Code build) is exactly what produces Finding 1's silent-degrade failure mode in practice. Recommend a maintainer conversation between whoever ownsdisciplineanddiscoverydocs.Severity
CRITICAL (Findings 1, 5), IMPORTANT (Findings 2, 3), SUGGESTION (Finding 4) — severities as originally assigned by the dispatched auditor; a mid-drafting pass initially mis-bucketed these (swapping Finding 2 into a CRITICAL slot and Finding 5 into an IMPORTANT slot) and that miscount has been corrected here to match the auditor's actual assignment.
Provenance
Surfaced by
/plugin-quality:audit, session-loop-audit run, dispatched via the plugin'sauditoragent. Corrected during pre-publication review: Finding 3's original framing incorrectly claimed the fork dependency was undiscoverable anywhere in the skill; it IS in the skill body, just not the pre-invocation description — restated above. The official-docs citation forCLAUDE_CODE_FORK_SUBAGENTiscode.claude.com/docs/en/sub-agents(documents the1/0values); a separate env-var reference page carries no entry for it as of this session.Blindspots noted by the original auditor: fork-reproduction was not independently re-attempted from within that auditor's own dispatch context; a marketplace-wide grep found no other installed plugin sharing this exact runtime dependency.