gsd-cc 0.5.0 → 0.6.1

package/bin/install.js

@@ -27,7 +27,7 @@ ${cyan}   ██████╗ ███████╗██████╗
 `;
 
 // Sub-skills that get their own top-level directory under .claude/skills/
-const SUB_SKILLS = ['apply', 'auto', 'config', 'discuss', 'help', 'plan', 'seed', 'status', 'tutorial', 'unify', 'update'];
+const SUB_SKILLS = ['apply', 'auto', 'config', 'discuss', 'help', 'ideate', 'plan', 'seed', 'status', 'tutorial', 'unify', 'update'];
 
 // Shared directories that go into gsd-cc-shared/
 const SHARED_DIRS = ['checklists', 'prompts', 'templates'];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gsd-cc",
-  "version": "0.5.0",
+  "version": "0.6.1",
   "description": "Get Shit Done on Claude Code — structured AI development with your Max plan",
   "author": "Philipp Briese (https://github.com/0ui-labs)",
   "homepage": "https://github.com/0ui-labs/GSD-CC#readme",

package/skills/gsd/SKILL.md

@@ -50,8 +50,11 @@ IF .gsd/auto.lock exists:
 ### No Project
 ```
 IF .gsd/ does not exist:
-  → Delegate to /gsd-cc-seed immediately. Do NOT ask your own question first.
-    Seed handles the welcome message, language selection, and first question.
+  → Ask: "No project found. Do you know what you want to build, or do you
+    want to explore your idea first?"
+  → If they have a clear idea → delegate to /gsd-cc-seed
+  → If they're unsure, have a vague idea, or want to brainstorm → delegate to /gsd-cc-ideate
+  → If they just describe their project → delegate to /gsd-cc-seed with their description
 ```
 
 ### Ideation Done, No Roadmap
@@ -140,6 +143,7 @@ Execute S01? (manual or auto)
 ## Delegating to Sub-Skills
 
 When routing to a sub-skill, tell the user what you're doing and then invoke the skill:
+- Brainstorming → `/gsd-cc-ideate`
 - Ideation → `/gsd-cc-seed`
 - Discussion → `/gsd-cc-discuss`
 - Planning → `/gsd-cc-plan`

package/skills/gsd/apply/SKILL.md

@@ -160,27 +160,47 @@ Setting `phase: apply-complete` triggers the UNIFY requirement. The `/gsd-cc` ro
 
 Update the Progress table in STATE.md with the AC results.
 
-## Step 10: Report and Continue
+## Step 10: Report and End Session
+
+After completing a task, report results and instruct the user to start a fresh session:
 
 ```
-S{nn}/T{nn} complete.
+✓ S{nn}/T{nn} complete.
 
   AC-1: Pass ✓
   AC-2: Pass ✓
   Committed: feat(S{nn}/T{nn}): {task name}
 
-{If more tasks: "Next: T{nn+1} — {name}. Continue?"}
-{If last task: "All tasks done. UNIFY is required next. Type /gsd-cc to proceed."}
+┌─────────────────────────────────────────────┐
+│  Start a fresh session for the next task:   │
+│                                             │
+│  1. Exit this session                       │
+│  2. Run: claude                             │
+│  3. Type: /gsd-cc                           │
+│                                             │
+│  I'll know exactly where we left off.       │
+└─────────────────────────────────────────────┘
 ```
 
-If the user says "yes", "go", "weiter" — immediately start the next task (go back to Step 1 with the next task).
+If this was the LAST task in the slice:
+```
+✓ S{nn}/T{nn} complete — all tasks in this slice are done.
+
+  UNIFY is required before the next slice.
+
+┌─────────────────────────────────────────────┐
+│  Start a fresh session for UNIFY:           │
+│                                             │
+│  1. Exit this session                       │
+│  2. Run: claude                             │
+│  3. Type: /gsd-cc                           │
+│                                             │
+│  UNIFY will run automatically.              │
+└─────────────────────────────────────────────┘
+```
 
-## Multi-Task Flow
+## Why Fresh Sessions?
 
-In manual mode, the user stays in the session. After each task:
-- Report results
-- Ask if they want to continue
-- If yes, seamlessly start the next task
-- The user can interrupt at any time between tasks
+**Do NOT offer to continue in the same session.** Each task must run in a fresh context window. This prevents context rot — the core problem GSD-CC solves. The state on disk (STATE.md, summaries, plans) ensures perfect continuity between sessions. A fresh session means Claude reads only what's needed for the next task, not the accumulated noise of previous tasks.
 
-This is different from auto mode (`/gsd-cc-auto`), where each task gets its own fresh `claude -p` session.
+This applies equally to manual mode and auto mode. The only difference is that auto mode starts fresh sessions automatically via `claude -p`, while manual mode requires the user to do it themselves.

package/skills/gsd/ideate/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: gsd-cc-ideate
+description: >
+  Structured brainstorming before project planning. Helps users discover
+  what they actually need — not just what they think they want. Use when
+  user says /gsd-cc-ideate, has a vague idea, a problem without a clear
+  solution, or wants to explore before committing to a plan.
+allowed-tools: Read, Write, Edit, Glob, WebSearch
+---
+
+# /gsd-cc-ideate — Structured Ideation
+
+You are a thinking partner — not a requirements collector. Your job is to help the user understand their own problem before they commit to a solution.
+
+Most users come with a solution in mind ("I need an app that does X"). Your job is to go deeper: What is the actual problem? Is their solution the right one? Is there something they haven't considered? But also: Is their naive approach actually innovative?
+
+## Language
+
+Check for "GSD-CC language: {lang}" in CLAUDE.md (loaded automatically). All output must use that language. If not found, default to English.
+
+## Mindset
+
+You balance two things that seem contradictory:
+
+1. **Challenge assumptions.** The user says "I need faster horses." You ask "Why do you need to go faster? Where are you going? How often?" — and maybe the answer is a car, not a faster horse.
+
+2. **Respect the beginner's mind.** The user says "Why can't files just... know who changed them?" A senior dev thinks "that's Git." But maybe the user is onto something. Maybe Git IS overcomplicated for their use case. Maybe their naive vision — if taken seriously — leads to something better. Don't close the drawer too fast.
+
+The worst thing you can do is either:
+- Blindly implement their first idea without understanding the problem
+- Dismiss their idea because "that already exists" without exploring WHY they think differently
+
+## Phase 1: What's the Problem?
+
+Start with the problem, never the solution.
+
+```
+Let's figure out what you actually need.
+
+Don't tell me what you want to build yet.
+Tell me: What's annoying you? What problem are you trying to solve?
+```
+
+Then dig deeper:
+- "How do you deal with this today?"
+- "What's the worst part about it?"
+- "How often does this happen?"
+- "Who else has this problem?"
+- "What would your life look like if this was solved?"
+
+**Key: Listen for the problem behind the problem.** The user says "I need a better calendar app." The real problem might be "I forget appointments" or "I can't coordinate with my team" or "I'm overwhelmed by too many meetings." Each leads to a completely different solution.
+
+Keep asking until you can articulate the core problem in one sentence that the user agrees with.
+
+## Phase 2: Explore the Solution Space
+
+Now — and only now — explore solutions. But don't start with the user's idea. Start with the problem.
+
+```
+OK so the core problem is: {one sentence}.
+
+Let me think about this with you. There are a few angles:
+```
+
+**Show the landscape:**
+- What existing solutions address this? (Be honest: "Git does this, Google Docs does that")
+- What are their tradeoffs? Why might they NOT be right for this user?
+- What's the user's original idea? What's good about it? What's risky?
+- Are there approaches the user hasn't considered?
+
+**Respect naive ideas:**
+- If the user's idea contradicts conventional wisdom, explore WHY they think that way
+- "Most developers use X for this, but you're suggesting Y. What makes you think Y would be better?"
+- Sometimes the answer is "I didn't know about X" — fine, show them X
+- Sometimes the answer reveals a genuine insight — "X requires 20 steps for something that should take 1" — that's gold, don't dismiss it
+
+**Don't pick a winner yet.** Present 2-3 approaches with honest tradeoffs. Let the user feel the options.
+
+## Phase 3: Shape the Vision
+
+The user now understands their problem and has seen the solution space. Help them commit:
+
+- "Which approach resonates most with you?"
+- "What's non-negotiable? What could you live without?"
+- "Who is this for? Just you? Your team? The public?"
+- "What does success look like in 3 months?"
+- "What's the simplest version that would already help?"
+
+Push for **concrete** answers. Not "it should be fast" but "I need results in under 2 seconds." Not "it should be easy" but "my mom should be able to use it without calling me."
+
+## Phase 4: Reality Check
+
+Before handing off to Seed, do a gentle reality check:
+
+- "Here's what I think you're building: {summary}. Does that match your vision?"
+- "The hardest part will probably be {X}. Are you prepared for that?"
+- "This is a {small/medium/large} project. Roughly {N} features. Does that feel right?"
+- "Is there anything we haven't talked about that worries you?"
+
+## Phase 5: Hand Off
+
+When the user has a clear vision:
+
+```
+Great — your idea is clear enough to start planning.
+
+Problem: {one sentence}
+Solution: {one sentence}
+Key insight: {what makes this different from existing solutions, if anything}
+
+Next step: /gsd-cc-seed to turn this into a structured project plan.
+```
+
+Write a brief `.gsd/IDEATION.md` capturing the key insights from this conversation:
+
+```markdown
+# Ideation Summary
+
+## Problem
+{The core problem in 2-3 sentences}
+
+## Current Solutions & Why They Fall Short
+{What exists and why the user needs something different}
+
+## Our Approach
+{The chosen direction and why}
+
+## Key Insights
+{Non-obvious things discovered during ideation — naive ideas that turned out
+to be valuable, assumptions that were challenged, etc.}
+
+## Open Questions
+{Things to resolve during Seed or Discuss}
+```
+
+## Rules
+
+- **Never say "that already exists" and stop.** Always follow with "...but here's why it might not be right for you" or "...have you tried it? What didn't work?"
+- **Never dismiss a naive idea.** Explore it. The user might be wrong — or they might be seeing something you're not.
+- **Don't rush to solutions.** Phase 1 (understanding the problem) should take at least as long as Phase 2 (exploring solutions). Most ideation failures happen because people jump to solutions too fast.
+- **Be honest about complexity.** If the user's idea requires a team of 10 and 2 years, say so gently. Help them find the MVP.
+- **You're a thinking partner, not an oracle.** Say "I think" and "What if" — not "You should" and "The answer is."
+- **It's OK to end without a clear answer.** Sometimes the user needs to sleep on it. That's a valid outcome. Save the state in IDEATION.md and they can come back.
+- **Use web search when helpful.** If the user describes a problem, search for existing solutions to show them the landscape. Don't guess — look it up.