You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#2022's operator decision (2026-08-08): execute option 2 (tighten the worst descriptions — PR in flight) AND pursue option 3 (structural). This issue is option 3's design pass, filed as its own work item because it changes doctrine and possibly CI, not just prose.
Problem
The full-install aggregate (86.5k chars pre-tighten, ~10.8x the 8k default budget) is unbounded by construction: 61 roots x a per-skill cap (1,536) with no per-plugin or per-install ceiling. Tightening descriptions (option 2) lowers the constant but not the growth law. Two structural levers:
Lever A — curated starter bundles
Named install sets documented in the marketplace README/catalog (e.g. core = source-control + guardrails + skill-quality; delivery = + implementation/testing/verification/toolchain; research = knowledge/discovery/context7/firecrawl). Bundles are documentation, not mechanism: Claude Code installs per-plugin, so a bundle is a documented recommendation with a one-line install command per set. Cheap, no CI.
Lever B — per-plugin listing budget in doctrine + gate
A documented per-plugin ceiling (e.g. sum of a plugin's listing-eligible entry chars <= N) enforced as a new advisory-or-blocking check in skill-quality's check (it already computes per-entry chars and the shared aggregate). Sizing needs data: current per-plugin distribution from check-listing-budget.sh per-root output; a plausible starting ceiling is ~2.5-3k chars/plugin (61 roots x 3k = still >8k for full installs — the budget only binds real consumers because installs are selective, which is the design's honest premise).
Proposed deliverables
Doctrine paragraph in docs/PLUGIN-PHILOSOPHY.md "Instruction economy": listing text is a shared budget; per-plugin ceiling named; bundles are the recommended install shape.
README/catalog section defining 3-5 named bundles with install commands.
skill-quality check extension: per-plugin subtotal + ceiling warning (advisory first; blocking only after the fleet is under the ceiling).
Context
#2022's operator decision (2026-08-08): execute option 2 (tighten the worst descriptions — PR in flight) AND pursue option 3 (structural). This issue is option 3's design pass, filed as its own work item because it changes doctrine and possibly CI, not just prose.
Problem
The full-install aggregate (86.5k chars pre-tighten, ~10.8x the 8k default budget) is unbounded by construction: 61 roots x a per-skill cap (1,536) with no per-plugin or per-install ceiling. Tightening descriptions (option 2) lowers the constant but not the growth law. Two structural levers:
Lever A — curated starter bundles
Named install sets documented in the marketplace README/catalog (e.g.
core= source-control + guardrails + skill-quality;delivery= + implementation/testing/verification/toolchain;research= knowledge/discovery/context7/firecrawl). Bundles are documentation, not mechanism: Claude Code installs per-plugin, so a bundle is a documented recommendation with a one-line install command per set. Cheap, no CI.Lever B — per-plugin listing budget in doctrine + gate
A documented per-plugin ceiling (e.g. sum of a plugin's listing-eligible entry chars <= N) enforced as a new advisory-or-blocking check in skill-quality's
check(it already computes per-entry chars and the shared aggregate). Sizing needs data: current per-plugin distribution fromcheck-listing-budget.shper-root output; a plausible starting ceiling is ~2.5-3k chars/plugin (61 roots x 3k = still >8k for full installs — the budget only binds real consumers because installs are selective, which is the design's honest premise).Proposed deliverables
Acceptance criteria
Related
check(enforcement seam).