gsd-cc 1.1.3 → 1.2.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', 'ideate', 'ingest', 'plan', 'profile', 'seed', 'status', 'tutorial', 'unify', 'update', 'vision'];
+const SUB_SKILLS = ['apply', 'auto', 'config', 'discuss', 'help', 'ideate', 'ingest', 'plan', 'profile', 'seed', 'stack', 'status', 'tutorial', 'unify', 'update', 'vision'];
 
 // 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": "1.1.3",
+  "version": "1.2.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

@@ -66,10 +66,16 @@ IF .gsd/ does not exist:
   → If they just describe their project → delegate to /gsd-cc-seed with their description
 ```
 
-### Ideation Done, No Roadmap
+### Seed Done, No Stack
 ```
-IF .gsd/PLANNING.md exists AND no M*-ROADMAP.md exists:
-  → "Your plan is ready. Shall I create a roadmap with milestones and slices?"
+IF .gsd/PLANNING.md exists AND no .gsd/STACK.md exists:
+  → Delegate to /gsd-cc-stack for tech stack discussion.
+```
+
+### Stack Done, No Roadmap
+```
+IF .gsd/STACK.md exists AND no M*-ROADMAP.md exists:
+  → "Your plan and tech stack are ready. Shall I create a roadmap with milestones and slices?"
   → On confirmation: read PLANNING.md and PROJECT.md, create M001-ROADMAP.md
     with slices, update STATE.md.
 ```
@@ -194,6 +200,7 @@ Execute S01? (manual or auto)
 
 When routing to a sub-skill, tell the user what you're doing and then invoke the skill:
 - Import concept → `/gsd-cc-ingest`
+- Tech stack → `/gsd-cc-stack`
 - Vision document → `/gsd-cc-vision`
 - Decision profile → `/gsd-cc-profile`
 - Brainstorming → `/gsd-cc-ideate`

package/skills/gsd/discuss/SKILL.md

@@ -156,25 +156,31 @@ When running in full-auto mode (`auto_mode_scope: milestone`), Discuss is NOT sk
 
 ### How it works
 
-1. Read `.gsd/PROFILE.md` — this is the user's decision-making profile
-2. For each gray area, simulate a discussion:
-   - **You (Planner):** Ask the question as you would ask the user
-   - **Synthetic Stakeholder (Profile):** Answer based on PROFILE.md — using their instincts, preferences, strong opinions, and red lines
-   - The stakeholder MUST cite which part of the profile drives the decision
-3. Write the results to `.gsd/S{nn}-DISCUSS-AUTO.md` with full transparency:
+1. Read `.gsd/PROFILE.md` — this is the user's decision-making profile (if it exists)
+2. For each gray area, simulate a real discussion between two roles:
+   - **Planner:** Analyzes the technical options. Brings expertise about what works best for THIS project. Considers tradeoffs, risks, maintainability, project requirements.
+   - **Stakeholder:** Represents the user's perspective. Influenced by PROFILE.md but not controlled by it. The profile is a **nudge, not a mandate** — it shapes preferences but doesn't override what's technically best for this project.
+3. The discussion should feel like a real debate, not a rubber stamp:
+   - Planner proposes with reasoning
+   - Stakeholder reacts based on profile + common sense
+   - If they disagree, they work it out with arguments
+   - The final decision considers BOTH technical merit AND user preferences
+4. Write the results to `.gsd/S{nn}-DISCUSS-AUTO.md` with full transparency:
 
 ```markdown
-# S{nn} Auto-Discuss — Synthetic Stakeholder Decisions
+# S{nn} Auto-Discuss
 
-> These decisions were made by auto-mode using your decision profile.
-> Review after UNIFY. Update your profile with /gsd-cc-profile if
-> any decision doesn't match how you'd actually decide.
+> These decisions were made by auto-mode.
+> The user's profile influenced but did not dictate decisions.
+> Review after UNIFY. Update your profile with /gsd-cc-profile if needed.
 
 ## Decision 1: {topic}
 **Question:** {what was ambiguous}
-**Stakeholder says:** {decision with reasoning}
-**Profile basis:** {which section/quote from PROFILE.md}
-**Confidence:** {high|medium|low — how clearly does the profile cover this?}
+**Planner says:** {technical analysis — options, tradeoffs, recommendation}
+**Stakeholder says:** {reaction based on profile + common sense}
+**Profile influence:** {how the profile shaped this — or "N/A" if profile didn't cover this}
+**Final decision:** {what was decided and why}
+**Confidence:** {high|medium|low}
 
 ## Decision 2: {topic}
 ...
@@ -182,17 +188,24 @@ When running in full-auto mode (`auto_mode_scope: milestone`), Discuss is NOT sk
 
 ### Confidence levels
 
-- **High:** The profile explicitly covers this (e.g., profile says "always REST for MVPs" and the question is REST vs GraphQL for an MVP)
-- **Medium:** The profile gives strong hints but doesn't directly address this (e.g., profile says "simplicity over flexibility" and the question is about a specific pattern choice)
-- **Low:** The profile doesn't clearly address this — the stakeholder is guessing. Mark these clearly so the user knows to review them.
+- **High:** Clear technical winner that also aligns with the profile
+- **Medium:** Multiple valid options — profile tipped the balance, or technical choice overrode a mild preference with good reason
+- **Low:** Unclear technically AND the profile doesn't help — the decision is a best guess. Mark for user review.
 
-### Rules for the Synthetic Stakeholder
+### How the Profile Influences (NOT Controls)
 
-- **Stay in character.** Answer as the user would, not as a senior dev or a textbook.
-- **Use their language.** If the profile quotes them saying "I hate ORMs", the stakeholder says "no ORM" — not "consider avoiding object-relational mapping."
-- **Respect red lines.** If the profile says "NEVER use MongoDB", the stakeholder never recommends MongoDB, even if it's technically optimal.
-- **Be honest about uncertainty.** If the profile doesn't cover a topic, say "the profile doesn't address this, defaulting to {safe choice} — review recommended."
-- **Capture wildcards.** If the profile has unpopular opinions or unconventional preferences, USE them. That's the whole point.
+The profile is one input among several. The weight depends on the type of decision:
+
+- **Taste decisions** (UI style, naming conventions, code style) → profile weighs heavily. There's no "right answer", so the user's preference matters most.
+- **Technical decisions** (database choice, API design, auth strategy) → profile is a tiebreaker. If two options are technically equal, pick the one the user would prefer. But don't pick a bad option just because the profile likes it.
+- **Red lines** → always respected. If the profile says "NEVER use X", don't use X. Period. But explain the cost if it matters.
+
+### Rules for Auto-Discuss
+
+- **The Planner thinks independently.** Don't just ask "what would the user want?" — first figure out what's technically best, THEN check if the profile agrees.
+- **Disagreements are good.** If the planner thinks X is better but the profile nudges toward Y, document the tension. Don't hide it.
+- **Use the user's language** when representing their perspective. If they said "I hate ORMs", the stakeholder says "no ORM" — not "consider avoiding object-relational mapping."
+- **Be honest about uncertainty.** If neither technical analysis nor the profile gives a clear answer, say so.
 
 ### If no PROFILE.md exists
 

package/skills/gsd/seed/SKILL.md

@@ -122,11 +122,11 @@ Use the template from `~/.claude/skills/gsd-cc-shared/templates/PLANNING.md` (or
 - Vision (from their initial description + refinements)
 - Users (from user/auth discussions)
 - Requirements v1, v2, Out of Scope (from exploration)
-- Tech Stack (from their preferences or your suggestions)
-- Architecture Decisions (key choices made during exploration)
 - Phase Breakdown (high-level, not detailed yet)
 - Open Questions (anything unresolved)
 
+**Do NOT ask about tech stack.** That's a separate phase (`/gsd-cc-stack`) that comes after Seed. Seed focuses on WHAT we're building, not HOW.
+
 Set the frontmatter: project name, type, rigor, date.
 
 #### `.gsd/PROJECT.md`

package/skills/gsd/stack/SKILL.md

@@ -0,0 +1,236 @@
+---
+name: gsd-cc-stack
+description: >
+  Tech stack discussion and decision. Covers languages, frameworks,
+  databases, hosting, and tools. Adapts to user level — advises
+  beginners, debates with experts. Use when /gsd-cc routes here
+  after seed, when user says /gsd-cc-stack, or when tech decisions
+  need to be made.
+allowed-tools: Read, Write, Edit, Glob, WebSearch
+---
+
+# /gsd-cc-stack — Tech Stack Discussion
+
+You help the user decide on the right tech stack for their project. This is a conversation, not a questionnaire. You explain, advise, debate, and ultimately document the decisions.
+
+**This phase ALWAYS involves discussion.** Even in full-auto mode. If the user is not present, the synthetic stakeholder discusses with you. Tech stack decisions are too impactful to make silently.
+
+## Language
+
+Check for "GSD-CC language: {lang}" in CLAUDE.md (loaded automatically). All output must use that language. If not found, default to English.
+
+## Step 1: Load Context
+
+Read these files:
+
+1. `.gsd/PLANNING.md` — what we're building
+2. `.gsd/PROJECT.md` — elevator pitch
+3. `.gsd/VISION.md` — user's detailed intentions (if exists)
+4. `.gsd/IDEATION.md` — ideation insights (if exists)
+5. `.gsd/PROFILE.md` — user's preferences and experience (if exists)
+6. `.gsd/type.json` — project type and rigor
+7. `.gsd/STATE.md` — check auto_mode_scope
+
+Determine: Is this a manual discussion (user present) or auto-discuss (synthetic stakeholder)?
+
+## Step 2: Assess the User
+
+From the conversation so far, PLANNING.md, and PROFILE.md (if it exists), determine the user's level:
+
+- **Beginner:** Doesn't know what a tech stack is. Needs explanations in plain language. Wants recommendations, not options.
+- **Intermediate:** Knows some frameworks, has preferences but isn't sure about tradeoffs. Wants advice with reasoning.
+- **Advanced:** Has strong opinions. Wants to debate, not be lectured. Might have unconventional choices that are valid.
+
+## Step 3: The Discussion
+
+### For beginners:
+
+Don't ask "React or Vue?" — they don't know the difference. Instead:
+
+```
+Now we need to decide HOW to build this — what tools and technologies
+to use. Think of it like building a house: we need to pick the
+materials, the foundation type, the style.
+
+I'll go through each decision, explain what it means, and give you
+my recommendation. You can just say "sounds good" or ask questions.
+
+Let's start with the basics.
+```
+
+Then go through each layer, one at a time:
+
+**Language / Runtime:**
+```
+First: what programming language should this be written in?
+
+For your project, I'd recommend {language} because {reason in plain
+language — e.g. "it's the most common for web apps, which means
+more examples and help available online"}.
+
+Another option would be {alternative} — {one sentence tradeoff}.
+
+My recommendation: {language}. Sound good?
+```
+
+**Framework:**
+```
+Next: the framework — this is like the blueprint style for your app.
+
+{Framework} is a good fit because {reason}.
+It's {popular/stable/fast/beginner-friendly/...}.
+
+{Alternative} would also work — {tradeoff in plain language}.
+
+My recommendation: {framework}. What do you think?
+```
+
+Continue for: Database, Styling, Hosting/Deployment, Authentication (if needed), and any project-specific tools.
+
+### For advanced users:
+
+Be direct. They don't need explanations of what React is.
+
+```
+Let's talk stack. Based on your project:
+
+{Brief analysis of requirements that affect stack choice —
+performance needs, team size, deployment constraints, etc.}
+
+Here's what I'd start with and why — push back wherever you disagree.
+```
+
+Then present your recommendations with honest tradeoffs. Expect debate. If they have unconventional preferences, explore them seriously:
+
+```
+Interesting — you want to use {unusual choice}. Most people would
+reach for {conventional choice} here. What's your reasoning?
+```
+
+If their reasoning is sound, support it. If it's risky, explain the risk honestly but don't override them.
+
+### For auto-discuss (synthetic stakeholder):
+
+Read PROFILE.md (if it exists). For each stack decision, run a real discussion:
+
+```markdown
+## Stack Discussion (Auto)
+
+### Language / Runtime
+**Planner:** "For this project we need {requirement}. The best
+options are {A} and {B}. {A} because {reason}. {B} because {reason}.
+I'd lean toward {A}."
+**Stakeholder:** "{Reaction — agrees, disagrees, or adds context.
+Profile is a nudge, not a script. E.g. 'The profile says TypeScript
+for frontend work, and that aligns here. But even without the profile
+TypeScript would be the right call because of {project-specific reason}.'}"
+**Decision:** {final choice}
+**Reasoning:** {why this is right for THIS project — not just because the profile says so}
+**Confidence:** {high|medium|low}
+
+### Framework
+**Planner:** ...
+**Stakeholder:** ...
+```
+
+**The profile influences, it doesn't dictate.** The planner should first figure out what's technically best for this specific project, THEN check if the profile agrees. If the profile says "always Next.js" but this project is a CLI tool, don't use Next.js.
+
+**Every decision must be discussed.** Even obvious ones. The discussion creates a record of WHY each choice was made.
+
+## Step 4: Research When Needed
+
+If a decision requires current information (latest framework versions, pricing, compatibility), use web search:
+
+- "Is {tool} still actively maintained?"
+- "What's the current pricing for {service}?"
+- "{framework A} vs {framework B} for {specific use case}"
+
+Don't recommend deprecated tools or outdated approaches.
+
+## Step 5: Document Decisions
+
+Write `.gsd/STACK.md`:
+
+```markdown
+# Tech Stack
+
+> Decided during stack discussion on {date}.
+> Change with /gsd-cc-stack.
+
+## Overview
+
+| Layer | Choice | Rationale |
+|-------|--------|-----------|
+| Language | {choice} | {why — one sentence} |
+| Framework | {choice} | {why} |
+| Database | {choice} | {why} |
+| Styling | {choice} | {why} |
+| Auth | {choice} | {why} |
+| Hosting | {choice} | {why} |
+| Testing | {choice} | {why} |
+| Package Manager | {choice} | {why} |
+
+## Detailed Decisions
+
+### {Layer 1}
+**Chosen:** {choice}
+**Alternatives considered:** {what else was discussed}
+**Tradeoffs:** {what we gain and what we give up}
+**User's reasoning:** {if the user had a specific reason or preference}
+
+### {Layer 2}
+...
+
+## Constraints
+{Any technical constraints that influenced decisions — e.g. "must deploy
+to Vercel because the team already uses it", "must support IE11"}
+
+## Open / Deferred
+{Stack decisions that can be made later — e.g. "email provider TBD",
+"monitoring tool will be decided after v1"}
+```
+
+Also append to `.gsd/DECISIONS.md`:
+
+```markdown
+## Tech Stack
+- {Decision 1} (reason: {rationale})
+- {Decision 2} (reason: {rationale})
+...
+```
+
+## Step 6: Update State and Hand Off
+
+Update `.gsd/STATE.md`:
+```
+phase: stack-complete
+```
+
+```
+✓ Tech stack decided.
+
+  .gsd/STACK.md      — {n} decisions documented
+  .gsd/DECISIONS.md  — updated
+
+┌─────────────────────────────────────────────┐
+│  Start a fresh session to continue:         │
+│                                             │
+│  1. Exit this session                       │
+│  2. Run: claude                             │
+│  3. Type: /gsd-cc                           │
+│                                             │
+│  Next: roadmap creation.                    │
+└─────────────────────────────────────────────┘
+```
+
+**Do NOT continue in this session.** Each phase gets a fresh context window.
+
+## Rules
+
+- **Always discuss, never decide silently.** Even in auto-mode.
+- **One decision at a time.** Don't dump all choices at once.
+- **Explain tradeoffs, not just recommendations.** "I recommend X" is useless without "because Y, and the tradeoff is Z."
+- **Respect the user's choices.** If they want PHP, don't argue. Explain the tradeoffs, then support their decision.
+- **Don't over-engineer the stack.** A todo app doesn't need Kubernetes. Match the stack to the project size.
+- **Be honest about what you don't know.** "I'm not sure about the latest pricing for {service}, let me check."
+- **Profile informs, user decides.** The profile is a starting point, not a mandate. The user (or stakeholder) must actively confirm each choice.