Blocking conflict — must be resolved before test-analyze ships a harness.
Source: docs/plans/dynamic-workflow-migration.md §Repo-level consequences, item 5 (merged in #2162).
The conflict
scripts/plugin-compliance-check.sh:826 hard-pins context: fork on agents-plugin/agents-analyze and testing-plugin/test-analyze.
.claude/rules/skill-fork-context.md holds fork off for skills that fan out in parallel.
A skill that both holds the pin and gains a parallel() harness satisfies neither.
Resolution
agents-analyze — resolved by not shipping a harness. Its Tier C outcome is schema/prose edits only; the pin stands untouched. No action here.
test-analyze — fork stays, and the resolution must be stated explicitly in its SKILL.md delta: the parallel() width is capped at the fixed agent-type set (8 categories max) precisely so it does not become the wide fan-out the rule warns about. This is a narrow, bounded fan-out, which is the case the rule's prohibition was never aimed at.
The hard constraint
Never a silent frontmatter edit. Changing context: on a pinned skill requires editing skill-fork-context.md and the guard list in plugin-compliance-check.sh in the same commit. If this issue's resolution is instead "drop the pin", that is what must happen — not a one-line frontmatter change that leaves the rule and the guard disagreeing.
Decide and record
Pick one, and write the reasoning into skill-fork-context.md either way:
- (a) Narrow the rule.
fork is compatible with a fan-out whose width is statically bounded (a fixed enum, not a discovered list). Cleanest, and matches the plan's finding that the movers all have script-enumerable N.
- (b) Exempt by name. Keep the rule absolute, list
test-analyze as a documented exception. Cheaper now, worse later.
(a) is recommended — it generalises to every future harness, and the "statically bounded" test is the same gate workflow-vs-skill.md already applies.
Acceptance
Blocked by: the workflow-vs-skill.md rule landing (shares the "statically bounded N" test).
Blocking conflict — must be resolved before
test-analyzeships a harness.Source:
docs/plans/dynamic-workflow-migration.md§Repo-level consequences, item 5 (merged in #2162).The conflict
scripts/plugin-compliance-check.sh:826hard-pinscontext: forkonagents-plugin/agents-analyzeandtesting-plugin/test-analyze..claude/rules/skill-fork-context.mdholdsforkoff for skills that fan out in parallel.A skill that both holds the pin and gains a
parallel()harness satisfies neither.Resolution
agents-analyze— resolved by not shipping a harness. Its Tier C outcome is schema/prose edits only; the pin stands untouched. No action here.test-analyze— fork stays, and the resolution must be stated explicitly in its SKILL.md delta: theparallel()width is capped at the fixed agent-type set (8 categories max) precisely so it does not become the wide fan-out the rule warns about. This is a narrow, bounded fan-out, which is the case the rule's prohibition was never aimed at.The hard constraint
Never a silent frontmatter edit. Changing
context:on a pinned skill requires editingskill-fork-context.mdand the guard list inplugin-compliance-check.shin the same commit. If this issue's resolution is instead "drop the pin", that is what must happen — not a one-line frontmatter change that leaves the rule and the guard disagreeing.Decide and record
Pick one, and write the reasoning into
skill-fork-context.mdeither way:forkis compatible with a fan-out whose width is statically bounded (a fixed enum, not a discovered list). Cleanest, and matches the plan's finding that the movers all have script-enumerable N.test-analyzeas a documented exception. Cheaper now, worse later.(a) is recommended — it generalises to every future harness, and the "statically bounded" test is the same gate
workflow-vs-skill.mdalready applies.Acceptance
.claude/rules/skill-fork-context.mdplugin-compliance-check.shguard list agrees with the ruletest-analyzeSKILL.md states the resolution inlineBlocked by: the
workflow-vs-skill.mdrule landing (shares the "statically bounded N" test).