Browse Source

fix: move scope assessment into understanding phase

Testing showed the model skipped scope assessment when it was a
separate step after "Understanding the idea." Inlining it as the
first thing in understanding ensures it fires before detailed questions.
Jesse Vincent 7 months ago
parent
commit
84cd6e7c20
1 changed files with 3 additions and 8 deletions
  1. 3 8
      skills/brainstorming/SKILL.md

+ 3 - 8
skills/brainstorming/SKILL.md

@@ -13,18 +13,13 @@ Start by understanding the current project context, then ask questions one at a
 
 **Understanding the idea:**
 - Check out the current project state first (files, docs, recent commits)
-- Ask questions one at a time to refine the idea
+- Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
+- If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.
+- For appropriately-scoped projects, ask questions one at a time to refine the idea
 - Prefer multiple choice questions when possible, but open-ended is fine too
 - Only one question per message - if a topic needs more exploration, break it into multiple questions
 - Focus on understanding: purpose, constraints, success criteria
 
-**Assessing scope:**
-- Once you understand the idea, assess whether it fits in a single design or needs to be broken into sub-projects
-- If the project has multiple independent subsystems — each needing its own design decisions, file structure, and test strategy — it's too large for a single spec
-- Help the user decompose: what are the independent pieces, how do they relate, what order should they be built?
-- Document the high-level decomposition, then brainstorm the first sub-project through the normal design flow
-- Each sub-project gets its own spec → plan → implementation cycle
-
 **Exploring approaches:**
 - Propose 2-3 different approaches with trade-offs
 - Present options conversationally with your recommendation and reasoning