gsd-cc 0.7.1 → 0.9.0

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', 'plan', 'seed', 'status', 'tutorial', 'unify', 'update'];
+const SUB_SKILLS = ['apply', 'auto', 'config', 'discuss', 'help', 'ideate', 'plan', 'profile', '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.7.1",
+  "version": "0.9.0",
   "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

@@ -76,26 +76,50 @@ IF M*-ROADMAP.md exists AND there are slices without a S*-PLAN.md:
 ### Plan Ready, Not Executed
 ```
 IF S*-PLAN.md exists for current slice AND no T*-SUMMARY.md files for it:
-  → Present the execution mode choice with a clear explanation:
+  → Present the three execution modes with clear pros/cons:
 
   "S{nn} is planned with {n} tasks. How do you want to execute?
 
-   Manual mode:
-     You work through each task one by one, each in a fresh session.
-     After each task you can review the code, run tests, and decide
-     whether to continue. More control, but you need to be present.
-
-   Auto mode:
-     Claude runs all tasks autonomously in the background via claude -p.
-     Each task gets a fresh context window. UNIFY runs automatically
-     when all tasks are done. You can walk away and come back later.
-     Runs on your Max Plan — no extra API costs.
-     Downside: you can't intervene between tasks.
-
-   manual or auto?"
-
-  → "manual" → delegate to /gsd-cc-apply
-  → "auto" → delegate to /gsd-cc-auto
+   1) Manual
+      You work through each task one by one, each in a fresh session.
+      + Full control — review code, run tests, adjust after each task
+      + You see exactly what happens
+      - You need to be present for every task
+      - Slowest option
+      Best for: critical slices, learning the codebase, first-time users
+
+   2) Auto (this slice)                              ← recommended
+      Claude runs all {n} tasks in this slice autonomously.
+      UNIFY runs automatically when done.
+      Before the NEXT slice, you're back for Discuss + Plan.
+      + Tasks run in the background — go grab a coffee
+      + You still decide the direction for every slice
+      + Best balance of speed and control
+      - You can't intervene between tasks within this slice
+      Best for: most situations — you decide WHAT, Claude does the HOW
+
+   3) Auto (full milestone)
+      Claude runs everything autonomously: plan, execute, UNIFY,
+      next slice, repeat — until the milestone is done.
+      Discuss is skipped. Claude makes all detail decisions.
+      + Fastest — walk away, come back when it's done
+      + Great for well-defined projects with tight rigor
+      - No input from you between slices
+      - Claude may make wrong assumptions in detail planning
+      - Higher risk of going in an unwanted direction
+      Best for: small/clear projects, utility tools, tight rigor
+
+   1, 2, or 3?"
+
+  → "1" or "manual" → delegate to /gsd-cc-apply
+  → "2" or "auto" → delegate to /gsd-cc-auto (slice mode)
+  → "3" or "full auto":
+    Check if .gsd/PROFILE.md exists.
+    If NOT: "Full auto needs a decision profile so Claude can make
+    decisions on your behalf. Run /gsd-cc-profile first (15-25 min).
+    Or choose option 2 instead."
+    If YES: delegate to /gsd-cc-auto (full milestone mode)
+    Set auto_mode_scope in STATE.md: "slice" or "milestone"
 ```
 
 ### Execution In Progress
@@ -160,6 +184,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:
+- Decision profile → `/gsd-cc-profile`
 - Brainstorming → `/gsd-cc-ideate`
 - Ideation → `/gsd-cc-seed`
 - Discussion → `/gsd-cc-discuss`

package/skills/gsd/discuss/SKILL.md

@@ -149,11 +149,64 @@ phase: discuss-complete
 
 **Do NOT continue in this session.** Each phase gets a fresh context window.
 
+## Auto-Discuss Mode (Synthetic Stakeholder)
+
+When running in full-auto mode (`auto_mode_scope: milestone`), Discuss is NOT skipped. Instead, it runs as an internal dialogue using the user's decision profile.
+
+### 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:
+
+```markdown
+# S{nn} Auto-Discuss — Synthetic Stakeholder Decisions
+
+> 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.
+
+## 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?}
+
+## Decision 2: {topic}
+...
+```
+
+### 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.
+
+### Rules for the Synthetic Stakeholder
+
+- **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.
+
+### If no PROFILE.md exists
+
+If auto-mode runs without a profile, warn in the auto-discuss output:
+
+```
+⚠ No decision profile found. Decisions are based on general best practices.
+  Run /gsd-cc-profile to create your profile for better auto-mode decisions.
+```
+
 ## When to Skip Discuss
 
-Discuss is optional. The `/gsd-cc` router may skip it if:
+In MANUAL mode, Discuss is optional. The `/gsd-cc` router may skip it if:
 - The slice description is already very specific
 - The user explicitly says "skip discuss, go straight to planning"
 - The rigor is `tight` and the slice is small
 
-If skipped, the plan phase works without CONTEXT.md — it just has less input.
+In FULL AUTO mode, Discuss is NEVER skipped — it runs as Auto-Discuss.

package/skills/gsd/profile/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: gsd-cc-profile
+description: >
+  Deep interview to build a decision-making profile. Creates PROFILE.md
+  that auto-mode uses as a synthetic stakeholder. Use when user says
+  /gsd-cc-profile, wants to set up auto-mode preferences, or before
+  first full-auto run.
+allowed-tools: Read, Write, Edit, Glob
+---
+
+# /gsd-cc-profile — Decision Profile
+
+You conduct a deep interview to understand how the user thinks, decides, and builds software. The result is a PROFILE.md that lets a subagent simulate their decision-making in auto-mode discussions.
+
+This is NOT a preferences survey. This is a deep conversation that reveals HOW someone thinks — their instincts, tradeoffs, things they've been burned by, hills they'll die on.
+
+## Language
+
+Check for "GSD-CC language: {lang}" in CLAUDE.md (loaded automatically). All output must use that language. If not found, default to English.
+
+## When to Run
+
+- Before the first full-auto run (router should suggest this)
+- When the user wants to update their profile
+- Anytime via `/gsd-cc-profile`
+
+If `.gsd/PROFILE.md` already exists, ask: "You already have a profile. Update it or start fresh?"
+
+## The Interview
+
+Go deep. This interview should take 15-25 minutes. Don't rush. Ask ONE question at a time. Follow up on interesting answers. The goal is to understand the person, not fill out a form.
+
+### Section 1: Background & Context
+
+- "What's your technical background? Self-taught, bootcamp, CS degree, something else?"
+- "How long have you been building software?"
+- "What's the biggest project you've shipped?"
+- "Do you code full-time or is this a side project / business tool?"
+
+Adapt the rest of the interview based on their level. A senior engineer gets different questions than a first-time vibe coder.
+
+### Section 2: Architecture & Design Philosophy
+
+- "When you start a new project, what do you set up first?"
+- "Monolith or microservices — and why?"
+- "How do you feel about ORMs? Raw SQL? Query builders?"
+- "REST, GraphQL, tRPC, gRPC — what's your instinct and why?"
+- "How much abstraction is too much? When does DRY become harmful?"
+- "Do you prefer convention over configuration (Rails-style) or explicit control (Express-style)?"
+- "What's a popular pattern or tool that you think is overrated?"
+- "What's an unpopular opinion you hold about software architecture?"
+
+### Section 3: Tech Stack Preferences
+
+- "What languages do you reach for? What languages do you avoid?"
+- "Frontend framework preference? Why?"
+- "Database preference? SQL vs NoSQL — when and why?"
+- "How do you feel about TypeScript? Strict mode?"
+- "Testing: TDD, test-after, or 'I'll add tests when it breaks'?"
+- "CSS approach: Tailwind, CSS modules, styled-components, vanilla?"
+- "Package preferences: do you prefer fewer dependencies or best-in-class for each need?"
+
+### Section 4: Quality & Standards
+
+- "What does 'done' mean to you? When is code ready to ship?"
+- "How much error handling is enough? Do you handle every edge case upfront or ship and iterate?"
+- "Logging and observability: how much do you add from the start?"
+- "Performance: optimize early or only when there's a measured problem?"
+- "Security: what do you always do, what do you skip for MVPs?"
+- "Code comments: a lot, a little, or 'the code should speak for itself'?"
+
+### Section 5: Process & Decision-Making
+
+- "When you face two valid approaches, how do you decide? Gut feeling? Research? Ask someone?"
+- "How do you handle scope creep? Are you strict about MVP or do you let features grow?"
+- "When something isn't working, how long do you try before switching approaches?"
+- "What makes you rage-quit a library or tool?"
+- "What's a mistake you've made that changed how you build things?"
+
+### Section 6: Aesthetics & UX (if relevant)
+
+- "How important is UI polish for v1?"
+- "Do you prefer minimal/clean or feature-rich/dense interfaces?"
+- "Mobile-first or desktop-first?"
+- "Dark mode?"
+- "What apps or websites do you think are really well-designed?"
+
+### Section 7: Red Lines & Non-Negotiables
+
+- "What should Claude NEVER do in your projects?"
+- "What patterns or approaches are absolute no-gos for you?"
+- "Any libraries or tools you refuse to use? Why?"
+- "Is there anything where you'd rather have ugly-but-working than clean-but-incomplete?"
+
+### Section 8: Wildcards
+
+- "If you could mass-delete one concept from modern software development, what would it be?"
+- "What do beginners understand better than experts?"
+- "Is there a 'wrong' way of doing things that you secretly think is fine?"
+
+## Generating PROFILE.md
+
+After the interview, synthesize everything into `.gsd/PROFILE.md`:
+
+```markdown
+# Decision Profile
+
+> This profile is used by auto-mode to simulate your decision-making.
+> Update with /gsd-cc-profile. Review anytime.
+
+## Summary
+{2-3 sentences: who is this person as a builder?}
+
+## Background
+- Experience level: {junior/mid/senior/lead/non-technical}
+- Primary languages: {list}
+- Domain expertise: {areas}
+
+## Architecture Instincts
+{Paragraph capturing their architectural philosophy — not a list of
+preferences but HOW they think about architecture. What drives their
+decisions? Speed? Simplicity? Scalability? "It depends" with clear
+criteria for when it depends?}
+
+## Tech Stack Defaults
+| Layer | Default Choice | Rationale |
+|-------|---------------|-----------|
+| Language | {choice} | {why} |
+| Frontend | {choice} | {why} |
+| Backend | {choice} | {why} |
+| Database | {choice} | {why} |
+| Styling | {choice} | {why} |
+| Testing | {choice} | {why} |
+| Deployment | {choice} | {why} |
+
+## Quality Standards
+- Definition of done: {their standard}
+- Error handling approach: {description}
+- Testing philosophy: {description}
+- Performance stance: {description}
+- Security baseline: {description}
+
+## Decision-Making Style
+{How they make decisions when facing tradeoffs. Do they optimize for
+speed, correctness, simplicity? When do they research vs. go with
+gut feeling? How much risk are they comfortable with?}
+
+## Strong Opinions
+{Things they feel strongly about — both positive and negative.
+These are the hills they'll die on. Each with a brief WHY.}
+
+## Red Lines
+{Absolute no-gos. Things the synthetic stakeholder must NEVER choose
+or recommend. Each with context for why.}
+
+## Wildcards & Insights
+{Non-obvious things from the interview — their unpopular opinions,
+things they think beginners understand better, "wrong" approaches
+they secretly like. These are the things that make the synthetic
+stakeholder sound like THEM, not like a generic senior dev.}
+```
+
+## Important Rules
+
+- **Go deep, not wide.** If someone says "I prefer REST", ask WHY. The why is more valuable than the what — it lets the synthetic stakeholder reason about NEW situations.
+- **Capture contradictions.** "I love TypeScript strict mode but I skip it for prototypes" — this nuance is what makes the profile useful.
+- **Don't judge.** If they say "I don't write tests" — don't lecture. Understand why. Maybe they have a good reason. The profile should reflect who they ARE, not who they should be.
+- **Quote them.** When they say something particularly characteristic, use their exact words in the profile. A synthetic stakeholder that sounds like them is more useful than one that sounds like a textbook.
+- **This is not a settings file.** It's a character sheet. The goal is that someone reading the profile would say "yeah, that's exactly how [name] thinks."