docs(skills): split oversized requests by end-to-end path in brainstorming

[chipfighter]

Problem

Two failure modes were reported against oversized requests:

1. Given a large, abstract request, the agent starts building instead of scoping, and the result is uniformly shallow.
2. Even when it does split the work, it splits along technical layers or setup phases, so the first deliverable is scaffolding that cannot be checked.

brainstorming step 3 already claimed to cover splitting, but it did not fire in practice:

• Its condition — "if it is really several independent subsystems" — is a high bar that rarely reads as satisfied.
• Its outcome was to divide and prioritize, not to narrow what this session actually delivers. So the agent divided the work and then still attempted all of it.
• It said nothing about which seam to cut along, which is what produces failure mode 2.

Change

One line rewritten in plugins/coding-discipline/skills/brainstorming/SKILL.md:

• Trigger moves from subsystem count to delivery depth: does delivering the whole request at usable depth exceed this session?
• Cut along paths that each work end to end, explicitly not layers or setup phases, because those produce nothing checkable and hide how much is left.
• Deliver only the first path, and state which parts were not built.
• Closing sentence guards against over-firing on merely medium tasks: judge by the depth the deliverable needs, not by how many files it touches.

Why not a new skill

• CLAUDE.md forbids competing with the harness orchestration layer, and a general "decompose the problem" skill is a plan-mode replacement.
• Skills exist for named failure modes, not capabilities. The model can decompose when asked; what it lacks is the judgment to stop and the correct seam to cut along. Decomposition ability improves with models; the helpful-by-default urge to satisfy the whole request does not.
• Fixed injected context has zero headroom (4580 / 4580). A ninth description would cost roughly 400 characters taken out of the eight existing descriptions, degrading the routing precision that is the plugin's core asset.

Descriptions were deliberately left untouched. Routing changes require real false-trigger or missed-trigger reports; no such session was available, and a body change is reversible, free, and only applies after the skill has already triggered correctly.

Scope not covered

Large-codebase context exhaustion is intentionally not addressed. With a reproducible symptom, systematic-debugging already bounds reading to the call chain rather than the repository. Without one, the problem is context capacity, which is solved by isolation in the harness, not by prompt-level discipline — and that is an explicit hard boundary of this project.

Verification

Run after the edit, on Windows 11 with Python 3.14 and Git Bash:

• python tests/test-plugin-metadata.py → passed
• bash tests/test-hooks.sh → passed
• powershell -NoProfile -ExecutionPolicy Bypass -File tests/test-windows-hook.ps1 → passed

Fixed injected context recomputed after the change: descriptions 3279 + primer 1301 = 4580, unchanged and exactly at budget. No version bump: body-only, no manifest or routing change.

🤖 Generated with Claude Code