Przeglądaj źródła

feat: add project-level scope assessment to brainstorming pipeline

Brainstorming now assesses whether a project is too large for a single
spec and helps decompose into sub-projects. Spec reviewer checks scope.
Writing-plans has a backstop if brainstorming missed it.
Jesse Vincent 7 miesięcy temu
rodzic
commit
56e22b2afc

+ 7 - 0
skills/brainstorming/SKILL.md

@@ -61,6 +61,13 @@ digraph brainstorming {
 - 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

+ 1 - 0
skills/brainstorming/spec-document-reviewer-prompt.md

@@ -23,6 +23,7 @@ Task tool (general-purpose):
     | Consistency | Internal contradictions, conflicting requirements |
     | Clarity | Ambiguous requirements |
     | YAGNI | Unrequested features, over-engineering |
+    | Scope | Focused enough for a single plan — not covering multiple independent subsystems |
     | Architecture | Units with clear boundaries, well-defined interfaces, independently understandable and testable |
 
     ## CRITICAL

+ 4 - 0
skills/writing-plans/SKILL.md

@@ -18,6 +18,10 @@ Assume they are a skilled developer, but know almost nothing about our toolset o
 **Save plans to:** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`
 - (User preferences for plan location override this default)
 
+## Scope Check
+
+If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own.
+
 ## File Structure
 
 Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.