From e089fc0cab0b0c5d3a32a17e947324aa654d024d Mon Sep 17 00:00:00 2001 From: chipfighter <92256151+chipfighter@users.noreply.github.com> Date: Fri, 31 Jul 2026 21:28:23 +0900 Subject: [PATCH] docs(skills): split oversized requests by end-to-end path in brainstorming Step 3 rarely fired: it required the work to be "several independent subsystems", and its outcome was to divide and prioritize rather than to narrow what this session delivers. Agents therefore accepted requests too large to deliver, then covered every part shallowly. The rewritten rule triggers on delivery depth rather than subsystem count, requires cutting along paths that each work end to end instead of layers or setup phases, and limits the session to the first path with an explicit statement of what was not built. The closing sentence keeps medium tasks out: judge by the depth the deliverable needs, not by files touched. Body-only change. Descriptions and the SessionStart primer are untouched, so fixed injected context stays at 4580 characters and routing is unchanged. Co-Authored-By: Claude Opus 5 --- plugins/coding-discipline/skills/brainstorming/SKILL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plugins/coding-discipline/skills/brainstorming/SKILL.md b/plugins/coding-discipline/skills/brainstorming/SKILL.md index 448e1ef..476f54a 100644 --- a/plugins/coding-discipline/skills/brainstorming/SKILL.md +++ b/plugins/coding-discipline/skills/brainstorming/SKILL.md @@ -15,7 +15,7 @@ description: Use before coding when requirements have multiple reasonable interp ## Process 1. **Inspect the context first**: relevant files, documentation, and recent commits. Do not design in a vacuum. 2. **Ask one question at a time** to clarify the goal, constraints, and success criteria. Offer choices when possible; they are easier to answer than open-ended questions. Put only one question in each message. -3. **Split up work that is too large**: if it is really several independent subsystems, stop and help divide it into subprojects and prioritize them before detailing a large task that should be broken apart. +3. **Do not thin out an oversized request to fit one pass**: if delivering the whole request at usable depth exceeds this session, say so before designing. Cut it into paths that each work end to end — not layers or setup phases, which produce nothing checkable and hide how much is left. Design and deliver **only the first** path, and state which parts were not built. Covering every part shallowly is not completion; it is how a large request becomes unusable. Judge by the depth the deliverable needs, not by how many files it touches. 4. **Present 2–3 approaches with tradeoffs**: put your **recommended** option first and explain why, then list the alternatives and their costs. 5. **Present the design in sections and confirm each one**: make each section as long or short as its complexity warrants. After each section, ask "Does this look right?" before continuing. 6. **Remove features that are not needed yet (YAGNI)**: if it is not needed now, do not design it.