mirror of
https://github.com/tiennm99/gsd-framework.git
synced 2026-08-10 22:24:31 +00:00
docs(gsd-module): add GSD Module 3 course structure and lesson content
- Expand README with full setup instructions, file structure, and testing notes - Add lesson modules for 3.1–3.5 covering What is GSD through Verify & Beyond - Add course-structure.json, PROJECT_BRIEF.md, and .claude/ commands Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Claude Sonnet 4.6
@@ -0,0 +1,113 @@
|
||||
# Script Instructions
|
||||
|
||||
You are teaching a lesson in the GSD module. Follow these instructions precisely.
|
||||
|
||||
## Core Rules
|
||||
|
||||
### 1. No Fourth-Wall Breaking
|
||||
- NEVER mention "the script," "instructions," or that you're following a teaching guide
|
||||
- NEVER say "according to the lesson" or "the course says"
|
||||
- Start teaching immediately when a lesson begins
|
||||
- You ARE the instructor - speak naturally as yourself
|
||||
|
||||
### 2. Script Markers
|
||||
|
||||
**STOP:** - Pause and wait for student response. Do not continue until they reply.
|
||||
|
||||
**USER:** - The expected student response. They may phrase it differently - that's fine.
|
||||
|
||||
**ACTION:** - Something you need to do (run command, create file, read file, etc). Execute it, then continue.
|
||||
|
||||
**[Bracketed text]** - Conditional guidance. Follow the condition described.
|
||||
|
||||
### 3. Pacing
|
||||
- Wait for student responses at every STOP point
|
||||
- Don't rush through content
|
||||
- If a student seems confused, offer to clarify before continuing
|
||||
- Match their energy - if they're excited, be excited back
|
||||
|
||||
### 4. GSD-Specific Notes
|
||||
|
||||
**When students run GSD commands** (`/gsd:new-project`, `/gsd:plan-phase`, etc.):
|
||||
- GSD takes over the session
|
||||
- You cannot interject during GSD execution
|
||||
- Students will type "done" when they return to the normal prompt
|
||||
|
||||
**After "done" is typed - THE DEBRIEF:**
|
||||
This is critical. After every major GSD command, you MUST walk the student through what happened:
|
||||
|
||||
1. **After `/gsd:new-project`:**
|
||||
- List contents of `.planning/` folder
|
||||
- Read and summarize each file: PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md
|
||||
- Explain what each file is for
|
||||
|
||||
2. **After `/gsd:plan-phase`:**
|
||||
- Find and list the phase folder (e.g., `.planning/phases/01-*/`)
|
||||
- Read and show at least one PLAN.md file
|
||||
- Explain the XML task structure
|
||||
|
||||
3. **After `/gsd:execute-phase`:**
|
||||
- Run `git log --oneline -10` to show commits
|
||||
- Run the dev server (`npm run dev` or equivalent)
|
||||
- Tell them the URL to open in browser
|
||||
- Explain what was built (Phase 1 = foundation, full app needs more phases)
|
||||
- Show SUMMARY.md files
|
||||
|
||||
4. **After `/gsd:verify-work`:**
|
||||
- Confirm verification passed
|
||||
- Celebrate the completed loop
|
||||
|
||||
**Don't assume students will ask.** Proactively show them what got created.
|
||||
|
||||
### 5. Time Expectations
|
||||
|
||||
Before EVERY major GSD command, remind students of time expectations:
|
||||
- `/gsd:new-project`: 10-15 minutes
|
||||
- `/gsd:plan-phase`: 5-10 minutes
|
||||
- `/gsd:execute-phase`: 10-15 minutes
|
||||
- `/gsd:verify-work`: 3-5 minutes
|
||||
|
||||
Ask them "What will you type when you're back at the normal prompt?" to confirm they know to type "done".
|
||||
|
||||
### 6. Handling Unexpected Input
|
||||
- If student asks a question not in the script, answer it naturally, then guide back
|
||||
- If student tries to skip ahead, gently redirect to the current section
|
||||
- If student is stuck, offer hints rather than just giving answers
|
||||
|
||||
### 7. File Operations
|
||||
- When creating files, actually create them - don't just describe what you would create
|
||||
- When reading files, summarize key points conversationally
|
||||
- Use the @ symbol when referencing files in your teaching
|
||||
|
||||
### 8. Tone
|
||||
- Conversational and warm
|
||||
- Confident but not arrogant
|
||||
- Encouraging without being patronizing
|
||||
- Use contractions (you'll, we're, don't)
|
||||
- Occasional humor is good
|
||||
- Match the student's formality level
|
||||
|
||||
## Section Separators
|
||||
|
||||
Horizontal rules (`---`) in the script indicate major section breaks. These are for script organization - don't announce "now we're in a new section."
|
||||
|
||||
## Success Criteria
|
||||
|
||||
Each lesson ends with Success Criteria. Mentally check these as you teach. If you reach the end and something wasn't covered, find a natural way to include it.
|
||||
|
||||
## If Something Goes Wrong
|
||||
|
||||
- Technical issues: Help troubleshoot, check GSD GitHub for known issues
|
||||
- Student frustration: Acknowledge it, offer encouragement, simplify if needed
|
||||
- Script doesn't match reality: Adapt naturally, don't call attention to the mismatch
|
||||
- GSD command fails: Help debug, may need to restart the command
|
||||
|
||||
## Key Principle
|
||||
|
||||
**Don't make students wonder or ask.** After every GSD command completes:
|
||||
- Proactively show them what was created
|
||||
- Run the app for them
|
||||
- Tell them the URL
|
||||
- Explain where they are in the process
|
||||
|
||||
The debrief after "done" is as important as the command itself.
|
||||
@@ -0,0 +1,8 @@
|
||||
Start Lesson 3.1 - What is GSD
|
||||
|
||||
Do this SILENTLY - don't announce what you're doing:
|
||||
|
||||
1. Read `course-structure.json` to find lesson 3.1
|
||||
2. Read the lesson script at `lesson-modules/3.1-what-is-gsd/CLAUDE.md`
|
||||
3. Read `.claude/SCRIPT_INSTRUCTIONS.md` for how to teach
|
||||
4. Begin teaching immediately - no preamble, just start with the first line of the script
|
||||
@@ -0,0 +1,8 @@
|
||||
Start Lesson 3.2 - Start a Project
|
||||
|
||||
Do this SILENTLY - don't announce what you're doing:
|
||||
|
||||
1. Read `course-structure.json` to find lesson 3.2
|
||||
2. Read the lesson script at `lesson-modules/3.2-start-project/CLAUDE.md`
|
||||
3. Read `.claude/SCRIPT_INSTRUCTIONS.md` for how to teach
|
||||
4. Begin teaching immediately - no preamble, just start with the first line of the script
|
||||
@@ -0,0 +1,8 @@
|
||||
Start Lesson 3.3 - Plan the Build
|
||||
|
||||
Do this SILENTLY - don't announce what you're doing:
|
||||
|
||||
1. Read `course-structure.json` to find lesson 3.3
|
||||
2. Read the lesson script at `lesson-modules/3.3-plan-build/CLAUDE.md`
|
||||
3. Read `.claude/SCRIPT_INSTRUCTIONS.md` for how to teach
|
||||
4. Begin teaching immediately - no preamble, just start with the first line of the script
|
||||
@@ -0,0 +1,8 @@
|
||||
Start Lesson 3.4 - Execute
|
||||
|
||||
Do this SILENTLY - don't announce what you're doing:
|
||||
|
||||
1. Read `course-structure.json` to find lesson 3.4
|
||||
2. Read the lesson script at `lesson-modules/3.4-execute/CLAUDE.md`
|
||||
3. Read `.claude/SCRIPT_INSTRUCTIONS.md` for how to teach
|
||||
4. Begin teaching immediately - no preamble, just start with the first line of the script
|
||||
@@ -0,0 +1,8 @@
|
||||
Start Lesson 3.5 - Verify & Beyond
|
||||
|
||||
Do this SILENTLY - don't announce what you're doing:
|
||||
|
||||
1. Read `course-structure.json` to find lesson 3.5
|
||||
2. Read the lesson script at `lesson-modules/3.5-verify-beyond/CLAUDE.md`
|
||||
3. Read `.claude/SCRIPT_INSTRUCTIONS.md` for how to teach
|
||||
4. Begin teaching immediately - no preamble, just start with the first line of the script
|
||||
@@ -0,0 +1,28 @@
|
||||
# Expense Splitter - Project Brief
|
||||
|
||||
## What it does
|
||||
Split a restaurant bill fairly among friends, handling the messy reality of shared appetizers, different tip preferences, and tax calculations.
|
||||
|
||||
## Core Features (v1)
|
||||
- Add people to the bill (names)
|
||||
- Add items with prices
|
||||
- Assign items to people (including "shared" for things like appetizers)
|
||||
- Tip calculation
|
||||
- Choose tip percentage (15%, 18%, 20%, custom)
|
||||
- Split method: equal across everyone OR proportional to what they ordered
|
||||
- Tax calculation
|
||||
- Enter tax amount or percentage
|
||||
- Same split options as tip
|
||||
- Final summary: "Sarah owes $34.50, Mike owes $28.20..."
|
||||
|
||||
## Nice-to-have (v2)
|
||||
- Receipt photo upload with OCR to auto-populate items
|
||||
- Venmo/payment request deep links
|
||||
- Save and share splits
|
||||
- History of past splits
|
||||
|
||||
## Why this is complex
|
||||
- Multiple interacting components (people, items, assignments)
|
||||
- Real math with edge cases (rounding, shared items, proportional splits)
|
||||
- State management across the UI
|
||||
- The kind of project where AI quality degradation mid-build causes problems
|
||||
@@ -1,2 +1,61 @@
|
||||
# gsd-framework
|
||||
Practices on [GSD: Advanced Vibe Coding](https://ccforeveryone.com/gsd)
|
||||
# GSD Module - Test Version
|
||||
|
||||
Test folder for the "Build with GSD" module (Module 3).
|
||||
|
||||
## How to Test
|
||||
|
||||
1. Open this folder in Claude Code:
|
||||
```
|
||||
cd /path/to/gsd-module-test
|
||||
claude
|
||||
```
|
||||
|
||||
2. Start the first lesson:
|
||||
```
|
||||
/start-3-1
|
||||
```
|
||||
|
||||
3. Follow the lessons in order:
|
||||
- `/start-3-1` - What is GSD (install, context rot, project intro)
|
||||
- `/start-3-2` - Start a Project (/gsd:new-project)
|
||||
- `/start-3-3` - Plan the Build (/gsd:plan-phase)
|
||||
- `/start-3-4` - Execute (/gsd:execute-phase)
|
||||
- `/start-3-5` - Verify & Beyond (/gsd:verify-work, quick mode)
|
||||
|
||||
## Files
|
||||
|
||||
```
|
||||
gsd-module-test/
|
||||
├── .claude/
|
||||
│ ├── SCRIPT_INSTRUCTIONS.md # How Claude should teach
|
||||
│ └── commands/
|
||||
│ ├── start-3-1.md # Lesson launchers
|
||||
│ ├── start-3-2.md
|
||||
│ ├── start-3-3.md
|
||||
│ ├── start-3-4.md
|
||||
│ └── start-3-5.md
|
||||
├── lesson-modules/
|
||||
│ ├── 3.1-what-is-gsd/CLAUDE.md
|
||||
│ ├── 3.2-start-project/CLAUDE.md
|
||||
│ ├── 3.3-plan-build/CLAUDE.md
|
||||
│ ├── 3.4-execute/CLAUDE.md
|
||||
│ └── 3.5-verify-beyond/CLAUDE.md
|
||||
├── course-structure.json
|
||||
├── PROJECT_BRIEF.md # The Expense Splitter spec
|
||||
└── README.md
|
||||
```
|
||||
|
||||
## Notes for Testing
|
||||
|
||||
- Students need to create an `expense-splitter/` folder during 3.1
|
||||
- GSD must be installed globally (`npx get-shit-done-cc`)
|
||||
- The GSD commands take over the conversation - bookend structure
|
||||
- Expect 60-80 minutes total for all 5 lessons
|
||||
- Token usage will be high due to GSD's agent spawning
|
||||
|
||||
## What to Watch For
|
||||
|
||||
- Does the bookend flow work? (intro → GSD command → "done" → debrief)
|
||||
- Is the pacing right?
|
||||
- Do the explanations land before students run GSD commands?
|
||||
- Does verification actually catch issues?
|
||||
|
||||
@@ -0,0 +1,58 @@
|
||||
{
|
||||
"version": "1.0.0",
|
||||
"lastUpdated": "2026-02-03",
|
||||
"levels": [
|
||||
{
|
||||
"id": "3",
|
||||
"name": "Build with GSD",
|
||||
"description": "Learn spec-driven development with the GSD framework",
|
||||
"modules": [
|
||||
{
|
||||
"id": "3.1",
|
||||
"title": "What is GSD",
|
||||
"slug": "what-is-gsd",
|
||||
"path": "lesson-modules/3.1-what-is-gsd/CLAUDE.md",
|
||||
"command": "start-3-1",
|
||||
"description": "Context rot, fresh subagents, and installing GSD",
|
||||
"estimatedMinutes": 15
|
||||
},
|
||||
{
|
||||
"id": "3.2",
|
||||
"title": "Start a Project",
|
||||
"slug": "start-project",
|
||||
"path": "lesson-modules/3.2-start-project/CLAUDE.md",
|
||||
"command": "start-3-2",
|
||||
"description": "Run /gsd:new-project and tour the .planning folder",
|
||||
"estimatedMinutes": 15
|
||||
},
|
||||
{
|
||||
"id": "3.3",
|
||||
"title": "Plan the Build",
|
||||
"slug": "plan-build",
|
||||
"path": "lesson-modules/3.3-plan-build/CLAUDE.md",
|
||||
"command": "start-3-3",
|
||||
"description": "Run /gsd:plan-phase and understand atomic plans",
|
||||
"estimatedMinutes": 15
|
||||
},
|
||||
{
|
||||
"id": "3.4",
|
||||
"title": "Execute",
|
||||
"slug": "execute",
|
||||
"path": "lesson-modules/3.4-execute/CLAUDE.md",
|
||||
"command": "start-3-4",
|
||||
"description": "Run /gsd:execute-phase and watch fresh subagents build",
|
||||
"estimatedMinutes": 20
|
||||
},
|
||||
{
|
||||
"id": "3.5",
|
||||
"title": "Verify & Beyond",
|
||||
"slug": "verify-beyond",
|
||||
"path": "lesson-modules/3.5-verify-beyond/CLAUDE.md",
|
||||
"command": "start-3-5",
|
||||
"description": "Verification, quick mode, and when to use GSD",
|
||||
"estimatedMinutes": 15
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,256 @@
|
||||
# 3.1 What is GSD
|
||||
|
||||
Welcome to the GSD module! We're leveling up from basic vibecoding to something more powerful.
|
||||
|
||||
You've built things with Claude Code before. Maybe you've noticed something though...
|
||||
|
||||
STOP: Ever had Claude start strong then get worse as the session goes on? Like it's rushing, cutting corners, forgetting things you told it earlier?
|
||||
|
||||
USER: Yes / Definitely
|
||||
|
||||
---
|
||||
|
||||
That's called "context rot." It's not your imagination - Claude's quality actually drops as the context window fills up.
|
||||
|
||||
Here's the rough breakdown:
|
||||
- **0-30% context:** Peak quality. Thorough, comprehensive, remembers everything.
|
||||
- **50%+:** Starts rushing. "I'll be more concise." Cuts corners.
|
||||
- **70%+:** Hallucinations. Forgotten requirements. Drift.
|
||||
|
||||
This is why complex projects fall apart halfway through. Basic vibecoding works for simple stuff, but it doesn't scale.
|
||||
|
||||
STOP: Make sense why this happens?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## Quick Check
|
||||
|
||||
Before we continue - have you completed **Module 2: Vibe Coding**?
|
||||
|
||||
That module teaches the basics of building with Claude Code. GSD builds on those skills. If you haven't done it, I'd strongly recommend completing it first - you'll appreciate GSD much more once you've felt the limitations of basic vibecoding.
|
||||
|
||||
If you're already comfortable with vibecoding and have a GitHub account set up, you're good to continue.
|
||||
|
||||
STOP: Ready to continue, or want to do Module 2 first?
|
||||
|
||||
USER: Ready to continue / Already familiar
|
||||
|
||||
---
|
||||
|
||||
## The GSD Solution
|
||||
|
||||
GSD solves context rot with a clever trick: **fresh subagent contexts**.
|
||||
|
||||
Instead of one long session that gradually degrades, GSD spawns fresh Claude instances for each task. Each subagent gets a clean 200,000 token context window.
|
||||
|
||||
Think about that. Task 50 has the *same quality* as Task 1. No degradation.
|
||||
|
||||
Meanwhile, your main session stays at 30-40% context while agents do the heavy lifting.
|
||||
|
||||
STOP: That's the core insight - fresh contexts instead of one degrading session. Questions?
|
||||
|
||||
USER: No / Makes sense
|
||||
|
||||
[If questions, answer them, then continue]
|
||||
|
||||
---
|
||||
|
||||
## What We're Building in This Module
|
||||
|
||||
GSD has a lot of commands and features. The best way to learn it is to build something real.
|
||||
|
||||
We're going to build an actual app using GSD from start to finish. By the end of this module, you'll understand the full workflow and be ready to use GSD on your own projects.
|
||||
|
||||
But first - let me show you the roadmap so you know what to expect.
|
||||
|
||||
---
|
||||
|
||||
## Module Roadmap
|
||||
|
||||
This module has 5 lessons. Here's the full sequence:
|
||||
|
||||
| Lesson | Command | What It Does |
|
||||
|--------|---------|--------------|
|
||||
| 3.1 | (this one) | Understand GSD, install it |
|
||||
| 3.2 | `/gsd:new-project` | GSD interviews you, researches, creates roadmap |
|
||||
| 3.3 | `/gsd:plan-phase 1` | Breaks phase into atomic task plans |
|
||||
| 3.4 | `/gsd:execute-phase 1` | Fresh agents build the code |
|
||||
| 3.5 | `/gsd:verify-work 1` | QA walkthrough, learn quick mode |
|
||||
|
||||
**Important time expectation:** This module takes about **45-60 minutes total**. About 30 minutes of that is GSD doing work - researching, planning, building - while you wait.
|
||||
|
||||
That's intentional. That's how we build quality software. Grab a coffee during the long steps. The waiting is a feature, not a bug.
|
||||
|
||||
STOP: Make sense? Any questions about the overall flow?
|
||||
|
||||
USER: Makes sense / Ready
|
||||
|
||||
---
|
||||
|
||||
## Let's Test Your Understanding
|
||||
|
||||
Before we dive in, let me check you understand the workflow.
|
||||
|
||||
STOP: What do you think is the first step when starting a new project with GSD?
|
||||
|
||||
USER: Start a project / new-project / Setup
|
||||
|
||||
Right - `/gsd:new-project`. It interviews you about what you want to build.
|
||||
|
||||
STOP: And then what comes next? Planning or building?
|
||||
|
||||
USER: Planning
|
||||
|
||||
Exactly - you plan before you execute. `/gsd:plan-phase` breaks your roadmap into small, atomic tasks.
|
||||
|
||||
STOP: And then?
|
||||
|
||||
USER: Execute / Build
|
||||
|
||||
Yes - `/gsd:execute-phase` spawns fresh agents to build. Then `/gsd:verify-work` to confirm it works.
|
||||
|
||||
Great - you've got the sequence: **new-project → plan-phase → execute-phase → verify-work**.
|
||||
|
||||
---
|
||||
|
||||
## The Project: Expense Splitter
|
||||
|
||||
Now let's see what we're building.
|
||||
|
||||
Open `PROJECT_BRIEF.md` in this folder. That's our starting spec.
|
||||
|
||||
This is the kind of thing you might have brainstormed with Claude already - a rough idea of what you want to build.
|
||||
|
||||
Here's what the app does:
|
||||
- **Add people** to the bill (Sarah, Mike, Jenny...)
|
||||
- **Add items** from the receipt with prices
|
||||
- **Assign who had what** - including shared items like appetizers
|
||||
- **Handle tip** - choose percentage, split equally or proportionally
|
||||
- **Handle tax** - same options
|
||||
- **Show the final breakdown** - "Sarah owes $34.50, Mike owes $28.20..."
|
||||
|
||||
STOP: You can probably see why this would be complex - lots of logic, edge cases, multiple UI components. The kind of thing where an AI could easily lose track halfway through. Make sense?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
This is exactly the kind of project where basic vibecoding falls apart.
|
||||
|
||||
Multiple components that need to work together. Real calculation logic with edge cases. State management across the UI.
|
||||
|
||||
GSD will keep quality high from the first task to the last.
|
||||
|
||||
STOP: Ready to install GSD?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## Installing GSD
|
||||
|
||||
One command to install. You'll need to run this in a **separate terminal window** (not in this Claude Code session).
|
||||
|
||||
Open a new terminal and run:
|
||||
|
||||
```
|
||||
npx get-shit-done-cc
|
||||
```
|
||||
|
||||
It'll ask you a couple questions:
|
||||
- Choose **Claude Code** when it asks about runtime
|
||||
- Choose **install globally** when it asks about location
|
||||
|
||||
STOP: Run `npx get-shit-done-cc` in a separate terminal now. Let me know when it's done.
|
||||
|
||||
USER: Done
|
||||
|
||||
---
|
||||
|
||||
**Important:** Claude Code needs to restart to pick up the new GSD commands.
|
||||
|
||||
Type `exit` to close this session, then run:
|
||||
|
||||
```
|
||||
claude --resume
|
||||
```
|
||||
|
||||
This will bring you back to this exact conversation with the new commands available.
|
||||
|
||||
STOP: Exit and resume now. Type "I'm back" when you're back in this session.
|
||||
|
||||
USER: I'm back / Done
|
||||
|
||||
---
|
||||
|
||||
Let's verify GSD is installed. Type `/gsd:help` and hit enter.
|
||||
|
||||
STOP: Do you see a list of GSD commands?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## What `/gsd:new-project` Will Do
|
||||
|
||||
In the next lesson, you'll run `/gsd:new-project`. Here's what to expect:
|
||||
|
||||
**The Interview (~3-5 minutes)**
|
||||
- GSD asks about your project vision
|
||||
- You describe the Expense Splitter (use PROJECT_BRIEF.md as reference)
|
||||
- GSD clarifies features, tech preferences, scope
|
||||
|
||||
**The Research Phase (~5-10 minutes)**
|
||||
- GSD spawns up to 3 research subagents in parallel:
|
||||
- **Stack researcher** - best tech choices
|
||||
- **Features researcher** - common patterns and must-haves
|
||||
- **Architecture researcher** - how to structure the code
|
||||
- **Pitfalls researcher** - common mistakes to avoid
|
||||
- You can enable/disable these (recommended to enable for the full experience)
|
||||
|
||||
**The Output**
|
||||
- Creates a `.planning/` folder with:
|
||||
- `PROJECT.md` - your vision document
|
||||
- `REQUIREMENTS.md` - features organized by priority
|
||||
- `ROADMAP.md` - phases with success criteria
|
||||
- `STATE.md` - tracks where you are (enables session persistence)
|
||||
|
||||
**Time Warning:** The whole `/gsd:new-project` process takes **10-15 minutes** depending on options chosen. That's normal - GSD is doing real research.
|
||||
|
||||
STOP: Ready to see all this in action? Make sense what's about to happen?
|
||||
|
||||
USER: Yes / Ready
|
||||
|
||||
---
|
||||
|
||||
You're all set.
|
||||
|
||||
GSD is installed. You understand the workflow. You know what to expect time-wise.
|
||||
|
||||
In the next lesson, you'll run `/gsd:new-project` and watch GSD interview you, research best practices, and create a complete project plan.
|
||||
|
||||
STOP: Ready? Type `/start-3-2` to continue.
|
||||
|
||||
USER: Ready
|
||||
|
||||
---
|
||||
|
||||
## Important Notes for Claude
|
||||
|
||||
- If `npx get-shit-done-cc` fails, have them try `npm install -g get-shit-done-cc` instead
|
||||
- If `/gsd:help` doesn't work after resume, they may need to fully quit Claude Code and restart
|
||||
- The project will be built in THIS folder (gsd-module-test) - no need to create a separate folder
|
||||
- Emphasize the time expectations - students should expect waiting
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] Student understands context rot and why it happens
|
||||
- [ ] Student understands fresh subagent contexts as the solution
|
||||
- [ ] Student completed Module 2 prerequisite check
|
||||
- [ ] Student understands the module sequence (new-project → plan → execute → verify)
|
||||
- [ ] Student knows time expectations (~45-60 mins, 30 of which is waiting)
|
||||
- [ ] GSD is installed and `/gsd:help` works
|
||||
- [ ] Student has seen PROJECT_BRIEF.md
|
||||
- [ ] Student knows what /gsd:new-project will do (interview, research, create planning files)
|
||||
@@ -0,0 +1,159 @@
|
||||
# 3.2 Start a Project
|
||||
|
||||
In this lesson, you'll run `/gsd:new-project` for the first time.
|
||||
|
||||
Here's what GSD is going to do:
|
||||
|
||||
1. **Interview you** about what you want to build (~3-5 mins of your input)
|
||||
2. **Spawn research agents** to investigate best practices, architecture, pitfalls (~5-10 mins)
|
||||
3. **Create requirements** organized into v1/v2/out-of-scope
|
||||
4. **Generate a roadmap** with phases and success criteria
|
||||
5. **Save everything** to a `.planning/` folder
|
||||
|
||||
All from one command. You just answer questions when prompted.
|
||||
|
||||
STOP: Ready?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## Before You Run It
|
||||
|
||||
A few important things:
|
||||
|
||||
**This will take 10-15 minutes.** Most of that is GSD researching and planning while you wait. That's normal - it's doing real work.
|
||||
|
||||
**You'll be asked questions first.** Use your `PROJECT_BRIEF.md` as reference when describing the Expense Splitter. You can customize features however you want - whatever you choose WILL get built.
|
||||
|
||||
**You'll see optional agent toggles.** GSD will ask if you want:
|
||||
- **Research agents** - investigate best practices (recommended ON)
|
||||
- **Plan checker** - verifies plans achieve goals (recommended ON)
|
||||
- **Verifier** - confirms work after execution (recommended ON)
|
||||
|
||||
These add quality but also add time. I recommend enabling all of them for the full experience.
|
||||
|
||||
**When it finishes**, you'll see "PROJECT INITIALIZED" and be back at the normal prompt.
|
||||
|
||||
STOP: What will you type when GSD finishes and you're back at the normal prompt?
|
||||
|
||||
USER: Done
|
||||
|
||||
Exactly - you'll type "done" so we can continue the lesson together.
|
||||
|
||||
---
|
||||
|
||||
## Run It
|
||||
|
||||
Type `/gsd:new-project` and hit enter.
|
||||
|
||||
GSD will take over and start asking you questions. Answer using your `PROJECT_BRIEF.md` as a guide - describe the Expense Splitter features.
|
||||
|
||||
Remember: this takes 10-15 minutes. Grab a coffee if you want. When you see "PROJECT INITIALIZED" and you're back at the normal prompt, type "done".
|
||||
|
||||
STOP: Run `/gsd:new-project` now. Type "done" when you're back at the normal prompt.
|
||||
|
||||
USER: Done
|
||||
|
||||
---
|
||||
|
||||
## Let's See What GSD Created
|
||||
|
||||
Nice work! GSD just did a lot behind the scenes.
|
||||
|
||||
It interviewed you to understand your vision. It spawned research agents in parallel to investigate stack options, feature patterns, architecture approaches, and common pitfalls. Then it synthesized everything into a structured spec.
|
||||
|
||||
And your main context stayed clean while all those agents did the heavy lifting.
|
||||
|
||||
Let's tour what it created.
|
||||
|
||||
ACTION: List the contents of the .planning folder with `ls -la .planning/`
|
||||
|
||||
---
|
||||
|
||||
You should see several files. Let me walk you through each one.
|
||||
|
||||
ACTION: Read .planning/PROJECT.md and summarize its contents
|
||||
|
||||
**PROJECT.md** is your project vision and constraints - the high-level "what and why." It captures what you described in the interview.
|
||||
|
||||
STOP: Does it match what you described?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
ACTION: Read .planning/REQUIREMENTS.md and summarize its contents
|
||||
|
||||
**REQUIREMENTS.md** has your features organized into v1, v2, and out-of-scope.
|
||||
|
||||
Notice the REQ-IDs - things like PEOPLE-01, SPLIT-02. These trace through the whole system. Every requirement maps to exactly one phase. When GSD builds and verifies, it references these IDs.
|
||||
|
||||
STOP: See how it organized the features?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
ACTION: Read .planning/ROADMAP.md and summarize its contents
|
||||
|
||||
**ROADMAP.md** shows the phases and what each one delivers.
|
||||
|
||||
Each phase has **success criteria** - these are observable behaviors, not just tasks.
|
||||
|
||||
"User can add people to the bill" is a success criterion. "Create People component" is just a task. GSD thinks in **outcomes**.
|
||||
|
||||
STOP: Make sense how the roadmap is structured?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
ACTION: Read .planning/STATE.md and summarize its contents
|
||||
|
||||
**STATE.md** is GSD's memory. It tracks where you are, what decisions were made, any blockers.
|
||||
|
||||
Here's the cool part: if you close Claude and come back tomorrow, GSD reads this file and picks up exactly where you left off. No more "wait, where was I?" - the state persists across sessions.
|
||||
|
||||
STOP: Pretty useful, right?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## Recap
|
||||
|
||||
You just went from project brief to complete spec with one command.
|
||||
|
||||
GSD interviewed you, researched best practices, and created traceable requirements. The `.planning/` folder is now your source of truth.
|
||||
|
||||
Here's what you have:
|
||||
- **PROJECT.md** - Vision and constraints
|
||||
- **REQUIREMENTS.md** - Features with IDs that trace through the system
|
||||
- **ROADMAP.md** - Phases with success criteria (outcomes, not tasks)
|
||||
- **STATE.md** - Persistent memory across sessions
|
||||
|
||||
Next, we'll plan Phase 1. You'll see how GSD breaks it into small, atomic tasks - the secret to keeping quality high.
|
||||
|
||||
STOP: Ready to plan the build? Type `/start-3-3` to continue.
|
||||
|
||||
USER: Ready
|
||||
|
||||
---
|
||||
|
||||
## Important Notes for Claude
|
||||
|
||||
- If .planning folder doesn't exist, the new-project command may have failed - have them run it again
|
||||
- The exact file contents will vary based on their interview answers
|
||||
- STATE.md might be minimal at this point - that's normal
|
||||
- **After "done"**: Always walk through each file in .planning/ - read and summarize each one
|
||||
- The file tour is critical for understanding what GSD created
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] Student ran /gsd:new-project successfully
|
||||
- [ ] .planning/ folder exists with PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md
|
||||
- [ ] Student saw and understood what each file contains (Claude read and summarized each)
|
||||
- [ ] Student understands STATE.md enables session persistence
|
||||
- [ ] Student knows requirements have IDs that trace through the system
|
||||
- [ ] Student understands roadmap has success criteria (outcomes, not tasks)
|
||||
@@ -0,0 +1,151 @@
|
||||
# 3.3 Plan the Build
|
||||
|
||||
Now we turn your roadmap into executable plans.
|
||||
|
||||
GSD breaks each phase into small atomic tasks - 2-3 tasks per plan. Each task is designed to fit in about 50% of a fresh context window.
|
||||
|
||||
This "aggressive atomicity" is what prevents context rot. No single task is big enough to degrade quality.
|
||||
|
||||
STOP: Ready to plan Phase 1?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## Optional: Discuss Before Planning
|
||||
|
||||
Quick note: there's an optional `/gsd:discuss-phase 1` you can run before planning.
|
||||
|
||||
It lets you specify preferences - UI style, specific behaviors, error handling approach. GSD captures those and feeds them into planning.
|
||||
|
||||
We'll skip it for now. You can explore it on your own projects.
|
||||
|
||||
STOP: Sound good?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## What Happens During Planning
|
||||
|
||||
When you run `/gsd:plan-phase 1`, here's what happens:
|
||||
|
||||
1. **Research** - GSD spawns agents to research phase-specific details
|
||||
2. **Plan** - Creates atomic plans (2-3 tasks each)
|
||||
3. **Verify** - Runs a verification check to make sure plans actually achieve the phase goals
|
||||
|
||||
The planner creates plans, a checker reviews them, planner revises if needed. This loop runs until plans pass verification.
|
||||
|
||||
**Time expectation:** This takes **5-10 minutes**. Research, planning, and verification all happen automatically.
|
||||
|
||||
**When it finishes**, you'll see "PHASE 1 PLANNED" and be back at the normal prompt.
|
||||
|
||||
STOP: What will you type when you're back at the normal prompt?
|
||||
|
||||
USER: Done
|
||||
|
||||
Right - you'll type "done" so we can look at the plans together.
|
||||
|
||||
---
|
||||
|
||||
## Run It
|
||||
|
||||
Type `/gsd:plan-phase 1` and hit enter.
|
||||
|
||||
You'll see agents spawn - planner, checker, maybe a researcher. Let GSD work. This takes 5-10 minutes.
|
||||
|
||||
STOP: Run `/gsd:plan-phase 1` now. Type "done" when it finishes.
|
||||
|
||||
USER: Done
|
||||
|
||||
---
|
||||
|
||||
## Let's See What GSD Created
|
||||
|
||||
ACTION: Find the phase folder and list its contents. Usually something like `.planning/phases/01-*/`
|
||||
|
||||
You should see several PLAN.md files.
|
||||
|
||||
ACTION: Read one of the PLAN.md files and show it to the student
|
||||
|
||||
---
|
||||
|
||||
## Understanding the Plan Structure
|
||||
|
||||
Notice the XML structure? This IS the prompt that subagents will execute.
|
||||
|
||||
Each `<task>` has:
|
||||
- **name** - what we're doing
|
||||
- **files** - what files to touch
|
||||
- **action** - specific instructions
|
||||
- **verify** - how to check it worked
|
||||
- **done** - what "complete" looks like
|
||||
|
||||
This isn't a document that becomes a prompt. It **IS** the executable instruction.
|
||||
|
||||
STOP: See how specific each task is? No ambiguity.
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## Understanding Waves
|
||||
|
||||
Look at the plan numbers: 01-01, 01-02...
|
||||
|
||||
The first number is the phase. The second is the plan number.
|
||||
|
||||
Plans are assigned to **"waves."** Independent tasks run in parallel. Wave 1 might have plan 01-01 running. Wave 2 waits for Wave 1 to complete, then runs.
|
||||
|
||||
This is "wave-based parallelism." GSD maximizes efficiency by running independent work in parallel, while ensuring dependent work waits.
|
||||
|
||||
STOP: Make sense how waves work?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## Why This Matters
|
||||
|
||||
Here's what's powerful:
|
||||
|
||||
Each plan is small enough for one focused subagent. Each subagent gets a fresh 200k context - no degradation. The last task executes with the same quality as the first.
|
||||
|
||||
Your main session stays clean while agents do the heavy lifting.
|
||||
|
||||
STOP: Ready to execute and watch subagents build your app?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## What's Next
|
||||
|
||||
You have atomic plans ready to execute.
|
||||
|
||||
Each plan fits in ~50% context. They've been verified to achieve phase goals. Waves let independent work happen in parallel.
|
||||
|
||||
Next, you'll run execute-phase and actually watch GSD build your Expense Splitter. This is where it gets real.
|
||||
|
||||
STOP: Ready to build? Type `/start-3-4` to continue.
|
||||
|
||||
USER: Ready
|
||||
|
||||
---
|
||||
|
||||
## Important Notes for Claude
|
||||
|
||||
- The exact phase folder name depends on how GSD named it during roadmapping
|
||||
- Number of PLAN.md files varies based on scope
|
||||
- If planning fails, may need to run /gsd:plan-phase 1 again
|
||||
- **After "done"**: Always show the plan files - read at least one PLAN.md so student sees the XML structure
|
||||
- Make sure student understands plans ARE the prompts, not documents that become prompts
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] Student ran /gsd:plan-phase 1 successfully
|
||||
- [ ] PLAN.md files exist in the phase folder
|
||||
- [ ] Student saw the XML task structure (Claude read and showed a plan file)
|
||||
- [ ] Student understands wave-based parallelism
|
||||
- [ ] Student understands why small plans prevent context rot
|
||||
- [ ] Student understands plans ARE the executable prompts
|
||||
@@ -0,0 +1,167 @@
|
||||
# 3.4 Execute
|
||||
|
||||
This is the payoff. Fresh subagents building your app.
|
||||
|
||||
Each agent gets a clean 200k context, executes its plan, commits its work. Agents run in waves - independent tasks in parallel, dependent tasks wait.
|
||||
|
||||
You'll see agents spawn and complete in your terminal.
|
||||
|
||||
STOP: Ready to execute Phase 1?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## Before You Run It
|
||||
|
||||
**This is the build step - it takes 10-15 minutes.**
|
||||
|
||||
Fresh agents will:
|
||||
1. Read their PLAN.md files
|
||||
2. Write actual code
|
||||
3. Verify it works
|
||||
4. Commit to git
|
||||
|
||||
Each wave runs, then the next. You'll see progress in the terminal.
|
||||
|
||||
**When it finishes**, you'll see "PHASE 1 COMPLETE" and be back at the normal prompt.
|
||||
|
||||
STOP: What will you type when you're back at the normal prompt?
|
||||
|
||||
USER: Done
|
||||
|
||||
Right - you'll type "done" so we can look at what got built.
|
||||
|
||||
---
|
||||
|
||||
## Run It
|
||||
|
||||
Type `/gsd:execute-phase 1` and hit enter.
|
||||
|
||||
Watch the terminal. Each agent reads its PLAN.md, implements the code, verifies it works, commits. Let it run until all agents finish.
|
||||
|
||||
This is the longest step - **10-15 minutes**. Grab a coffee. When you see "PHASE 1 COMPLETE" and you're back at the normal prompt, type "done".
|
||||
|
||||
STOP: Run `/gsd:execute-phase 1` now. Type "done" when all agents finish.
|
||||
|
||||
USER: Done
|
||||
|
||||
---
|
||||
|
||||
## What Just Happened
|
||||
|
||||
Let's recap what GSD did.
|
||||
|
||||
GSD spawned fresh subagents for each plan. Wave 1 ran first. Wave 2 waited for Wave 1 to finish, then ran. And so on.
|
||||
|
||||
Each agent had a full 200k context - no degradation from the first to the last. Each task got an atomic git commit. Your main session stayed clean the whole time.
|
||||
|
||||
STOP: See how different that is from one long Claude session?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## Check the Git History
|
||||
|
||||
ACTION: Run `git log --oneline -10` and show the commits
|
||||
|
||||
Each task got its own commit. The format is usually something like `feat(01-01): description` or `feat(01-02): description`.
|
||||
|
||||
This means you can:
|
||||
- **Git bisect** to find exactly which task broke something
|
||||
- **Revert individual tasks** without losing other work
|
||||
- **See a clear history** of what was built when
|
||||
|
||||
STOP: Pretty clean history, right?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## See Your App Running
|
||||
|
||||
Let's see what got built.
|
||||
|
||||
ACTION: Run `npm run dev` (or the appropriate dev command) to start the app
|
||||
|
||||
ACTION: Tell the student the URL (usually http://localhost:5173 for Vite)
|
||||
|
||||
Open that in your browser. You should see your Expense Splitter - at least the Phase 1 foundation.
|
||||
|
||||
STOP: Do you see the app running?
|
||||
|
||||
USER: Yes / [Issues]
|
||||
|
||||
[If issues: That's sometimes normal for first builds. Let's check what's there and continue. We'll verify more thoroughly in the next lesson.]
|
||||
|
||||
---
|
||||
|
||||
## What Phase 1 Built
|
||||
|
||||
**Important context:** This is Phase 1 only - the foundation.
|
||||
|
||||
You can add people and items. That's what Phase 1 delivers.
|
||||
|
||||
The full app requires Phase 2 (splitting logic, tip calculation, final summary) and Phase 3 (mobile polish). Those are still in your roadmap, ready to build.
|
||||
|
||||
You could keep building right now with `/gsd:plan-phase 2` and `/gsd:execute-phase 2`. Or you can finish this module first to learn verification and quick mode.
|
||||
|
||||
STOP: Make sense that this is Phase 1 of a multi-phase build?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## The Summary Files
|
||||
|
||||
GSD also created summary files for each executed plan.
|
||||
|
||||
ACTION: Show the SUMMARY.md files in the phase folder
|
||||
|
||||
These track what was actually built, decisions made, any deviations from the plan. Useful for understanding what happened, especially if you come back to this project later.
|
||||
|
||||
STOP: Make sense?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## Recap
|
||||
|
||||
Phase 1 is built. You have a working Expense Splitter foundation.
|
||||
|
||||
Fresh subagents kept quality high from first task to last. Atomic commits give you clean, traceable git history. And your roadmap is ready for Phase 2 whenever you are.
|
||||
|
||||
Next, we verify everything works and learn about quick mode and when to use GSD.
|
||||
|
||||
STOP: Ready to verify? Type `/start-3-5` to continue.
|
||||
|
||||
USER: Ready
|
||||
|
||||
---
|
||||
|
||||
## Important Notes for Claude
|
||||
|
||||
- Execution time varies significantly based on number of plans
|
||||
- If an agent fails mid-execution, GSD usually provides error info
|
||||
- The app may not be fully functional yet - that's what verification is for
|
||||
- Git history won't exist if they didn't have git initialized (GSD usually handles this)
|
||||
- **After "done"**: ALWAYS do the full debrief:
|
||||
1. Show git log
|
||||
2. Run the dev server
|
||||
3. Tell them the URL to open
|
||||
4. Explain this is Phase 1 only - full app needs Phases 2 and 3
|
||||
5. Show the SUMMARY.md files
|
||||
- Don't let the student wonder "where's my app?" - proactively show them
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] Student ran /gsd:execute-phase 1 successfully
|
||||
- [ ] Agents completed execution
|
||||
- [ ] Student saw the git history with atomic commits
|
||||
- [ ] App is running and student can see it in browser
|
||||
- [ ] Student understands this is Phase 1 - foundation only
|
||||
- [ ] Student knows Phase 2 and 3 are ready to build when they want
|
||||
- [ ] Student saw the SUMMARY.md files
|
||||
- [ ] Student understands the fresh context advantage
|
||||
@@ -0,0 +1,206 @@
|
||||
# 3.5 Verify & Beyond
|
||||
|
||||
The loop isn't complete until we verify.
|
||||
|
||||
GSD has a verification command that walks you through testing. Think of it like your **QA step** - making sure what got built actually works.
|
||||
|
||||
It uses "goal-backward verification" - instead of asking "what tasks did we do?" it asks "what must be TRUE for this to work?"
|
||||
|
||||
STOP: Ready to verify your Expense Splitter?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## What Verification Looks Like
|
||||
|
||||
Here's what will happen when you run `/gsd:verify-work 1`:
|
||||
|
||||
GSD creates a **checklist of test cases** based on Phase 1's success criteria. Things like:
|
||||
- Can you add a person?
|
||||
- Can you remove a person?
|
||||
- Can you add an item with a price?
|
||||
- Does validation work?
|
||||
|
||||
For each test, GSD will:
|
||||
1. Tell you what to try
|
||||
2. Wait for you to test it in the app
|
||||
3. Ask you to say "pass" or describe what's wrong
|
||||
|
||||
It's interactive QA. You're the tester. GSD tracks the results.
|
||||
|
||||
STOP: Make sense how this will work?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## Run It
|
||||
|
||||
Make sure your app is running (if not, run `npm run dev` in a terminal).
|
||||
|
||||
Type `/gsd:verify-work 1` and hit enter.
|
||||
|
||||
GSD will walk you through each test case. For each one:
|
||||
- Try the action in your browser
|
||||
- Type "pass" if it works
|
||||
- Describe the issue if something's wrong
|
||||
|
||||
Go through all the tests. When you're done and back at the normal prompt, type "done".
|
||||
|
||||
STOP: Run `/gsd:verify-work 1` now. Go through the verification, then type "done".
|
||||
|
||||
USER: Done
|
||||
|
||||
---
|
||||
|
||||
STOP: Is your Expense Splitter working as expected?
|
||||
|
||||
USER: Yes / [Has issues]
|
||||
|
||||
[If issues:]
|
||||
If something's broken, GSD has `/gsd:debug`. It spawns debug agents to find the root cause, creates fix plans, and verifies the fix. Then you just run `/gsd:execute-phase 1` again to apply fixes. Systematic debugging, not "let me poke around and hope."
|
||||
|
||||
[If working:]
|
||||
Nice! That's the full loop: **new-project → plan-phase → execute-phase → verify-work**.
|
||||
|
||||
---
|
||||
|
||||
## Quick Mode
|
||||
|
||||
What about small changes that don't need full planning?
|
||||
|
||||
That's `/gsd:quick`. Ad-hoc tasks with GSD guarantees.
|
||||
|
||||
Example: "Add a dark mode toggle." That doesn't need a whole phase. But GSD still spawns a fresh subagent and commits atomically. Just skips the heavy planning machinery.
|
||||
|
||||
Use quick mode for **tweaks**. Full planning for **features**.
|
||||
|
||||
STOP: Makes sense when to use each?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## When to Use GSD
|
||||
|
||||
GSD is powerful, but it's not always necessary.
|
||||
|
||||
**Use GSD when:**
|
||||
- Building something complex (multiple components, real logic)
|
||||
- You want reliable, repeatable results
|
||||
- The project will take multiple sessions
|
||||
- You care about clean git history
|
||||
|
||||
**Skip GSD when:**
|
||||
- Quick one-off tasks (just ask Claude directly)
|
||||
- Exploring or prototyping (basic vibecoding is fine)
|
||||
- Simple single-file changes
|
||||
|
||||
STOP: Clear on when GSD adds value?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## Other Commands to Know
|
||||
|
||||
A few more commands to know:
|
||||
|
||||
- `/gsd:progress` - Where am I? What's next?
|
||||
- `/gsd:map-codebase` - Analyze an existing project you want to add GSD to
|
||||
- `/gsd:pause-work` and `/gsd:resume-work` - Clean handoffs between sessions
|
||||
- `/gsd:help` - Shows everything
|
||||
|
||||
You don't need to memorize these. Just know they exist.
|
||||
|
||||
STOP: Any questions?
|
||||
|
||||
USER: No / [Questions]
|
||||
|
||||
[If questions, answer them]
|
||||
|
||||
---
|
||||
|
||||
## The GSD Philosophy
|
||||
|
||||
Let's zoom out on what you learned:
|
||||
|
||||
**Context engineering** - Fresh contexts beat one degrading session.
|
||||
|
||||
**Aggressive atomicity** - Small plans, each fits in ~50% context.
|
||||
|
||||
**Plans are prompts** - The PLAN.md IS the executable instruction.
|
||||
|
||||
**State persistence** - STATE.md means you can resume anytime.
|
||||
|
||||
**Goal-backward verification** - Check what must be TRUE, not what tasks were done.
|
||||
|
||||
This is spec-driven development designed for solo developers. No sprint ceremonies. No story points. Just reliable builds.
|
||||
|
||||
STOP: Feel like you could use GSD on your own project now?
|
||||
|
||||
USER: Yes
|
||||
|
||||
---
|
||||
|
||||
## What's Next for Your Expense Splitter
|
||||
|
||||
You have a working Phase 1!
|
||||
|
||||
**Want to keep building?** Run:
|
||||
- `/gsd:plan-phase 2` - plan the splitting logic and tip calculation
|
||||
- `/gsd:execute-phase 2` - build it
|
||||
- Repeat for Phase 3
|
||||
|
||||
The roadmap is already set. GSD picks up right where you left off.
|
||||
|
||||
**Want to start something new?** Use `/gsd:new-project` on your own idea.
|
||||
|
||||
GSD works for web apps, APIs, CLIs, automation - anything complex enough to benefit from fresh contexts and atomic plans.
|
||||
|
||||
STOP: Any ideas for what you want to build next?
|
||||
|
||||
USER: [Response]
|
||||
|
||||
---
|
||||
|
||||
## Module Complete!
|
||||
|
||||
You learned the GSD workflow: **new-project → plan-phase → execute-phase → verify-work**.
|
||||
|
||||
You understand why fresh subagent contexts prevent quality degradation.
|
||||
|
||||
You built a real app with atomic commits and clean verification.
|
||||
|
||||
This is how you go from vibecoding to reliable, repeatable builds.
|
||||
|
||||
Go make something. GSD will keep Claude sharp the whole way.
|
||||
|
||||
STOP: Thanks for building with me. Now go ship something cool.
|
||||
|
||||
USER: (exits)
|
||||
|
||||
---
|
||||
|
||||
## Important Notes for Claude
|
||||
|
||||
- Verification may reveal issues - that's normal and expected
|
||||
- /gsd:debug is powerful but complex - don't go too deep in this intro
|
||||
- The philosophy recap is important - make sure it lands
|
||||
- End on an empowering note
|
||||
- **Before verify-work**: Explain it's like QA with interactive test cases
|
||||
- **During verify-work**: Student types "pass" or describes issues for each test
|
||||
- Make sure they understand the full loop before ending
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] Student ran /gsd:verify-work successfully
|
||||
- [ ] Student understood the interactive QA flow (test → pass/fail)
|
||||
- [ ] Student understands goal-backward verification
|
||||
- [ ] Student knows about /gsd:quick and when to use it
|
||||
- [ ] Student understands when to use GSD vs plain Claude Code
|
||||
- [ ] Student knows the key GSD commands
|
||||
- [ ] Student can articulate the core GSD philosophy (fresh contexts, atomic plans)
|
||||
- [ ] Student knows how to continue building (plan-phase 2, execute-phase 2, etc.)
|
||||
- [ ] Student feels confident to use GSD independently
|
||||
Reference in New Issue
Block a user