chore: initial backup of Claude Code configuration

Includes: CLAUDE.md, settings.json, agents, commands, rules, skills,
hooks, contexts, evals, get-shit-done, plugin configs (installed list
and marketplace sources). Excludes credentials, runtime caches,
telemetry, session data, and plugin binary cache.
This commit is contained in:
Yaojia Wang
2026-03-24 22:26:05 +01:00
commit 2876cca8fe
245 changed files with 54437 additions and 0 deletions

43
commands/gsd/add-phase.md Normal file
View File

@@ -0,0 +1,43 @@
---
name: gsd:add-phase
description: Add phase to end of current milestone in roadmap
argument-hint: <description>
allowed-tools:
- Read
- Write
- Bash
---
<objective>
Add a new integer phase to the end of the current milestone in the roadmap.
Routes to the add-phase workflow which handles:
- Phase number calculation (next sequential integer)
- Directory creation with slug generation
- Roadmap structure updates
- STATE.md roadmap evolution tracking
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/add-phase.md
</execution_context>
<context>
Arguments: $ARGUMENTS (phase description)
Roadmap and state are resolved in-workflow via `init phase-op` and targeted tool calls.
</context>
<process>
**Follow the add-phase workflow** from `@C:/Users/yaoji/.claude/get-shit-done/workflows/add-phase.md`.
The workflow handles all logic including:
1. Argument parsing and validation
2. Roadmap existence checking
3. Current milestone identification
4. Next phase number calculation (ignoring decimals)
5. Slug generation from description
6. Phase directory creation
7. Roadmap entry insertion
8. STATE.md updates
</process>

41
commands/gsd/add-tests.md Normal file
View File

@@ -0,0 +1,41 @@
---
name: gsd:add-tests
description: Generate tests for a completed phase based on UAT criteria and implementation
argument-hint: "<phase> [additional instructions]"
allowed-tools:
- Read
- Write
- Edit
- Bash
- Glob
- Grep
- Task
- AskUserQuestion
argument-instructions: |
Parse the argument as a phase number (integer, decimal, or letter-suffix), plus optional free-text instructions.
Example: /gsd:add-tests 12
Example: /gsd:add-tests 12 focus on edge cases in the pricing module
---
<objective>
Generate unit and E2E tests for a completed phase, using its SUMMARY.md, CONTEXT.md, and VERIFICATION.md as specifications.
Analyzes implementation files, classifies them into TDD (unit), E2E (browser), or Skip categories, presents a test plan for user approval, then generates tests following RED-GREEN conventions.
Output: Test files committed with message `test(phase-{N}): add unit and E2E tests from add-tests command`
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/add-tests.md
</execution_context>
<context>
Phase: $ARGUMENTS
@.planning/STATE.md
@.planning/ROADMAP.md
</context>
<process>
Execute the add-tests workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/add-tests.md end-to-end.
Preserve all workflow gates (classification approval, test plan approval, RED-GREEN verification, gap reporting).
</process>

47
commands/gsd/add-todo.md Normal file
View File

@@ -0,0 +1,47 @@
---
name: gsd:add-todo
description: Capture idea or task as todo from current conversation context
argument-hint: [optional description]
allowed-tools:
- Read
- Write
- Bash
- AskUserQuestion
---
<objective>
Capture an idea, task, or issue that surfaces during a GSD session as a structured todo for later work.
Routes to the add-todo workflow which handles:
- Directory structure creation
- Content extraction from arguments or conversation
- Area inference from file paths
- Duplicate detection and resolution
- Todo file creation with frontmatter
- STATE.md updates
- Git commits
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/add-todo.md
</execution_context>
<context>
Arguments: $ARGUMENTS (optional todo description)
State is resolved in-workflow via `init todos` and targeted reads.
</context>
<process>
**Follow the add-todo workflow** from `@C:/Users/yaoji/.claude/get-shit-done/workflows/add-todo.md`.
The workflow handles all logic including:
1. Directory ensuring
2. Existing area checking
3. Content extraction (arguments or conversation)
4. Area inference
5. Duplicate checking
6. File creation with slug generation
7. STATE.md updates
8. Git commits
</process>

View File

@@ -0,0 +1,36 @@
---
name: gsd:audit-milestone
description: Audit milestone completion against original intent before archiving
argument-hint: "[version]"
allowed-tools:
- Read
- Glob
- Grep
- Bash
- Task
- Write
---
<objective>
Verify milestone achieved its definition of done. Check requirements coverage, cross-phase integration, and end-to-end flows.
**This command IS the orchestrator.** Reads existing VERIFICATION.md files (phases already verified during execute-phase), aggregates tech debt and deferred gaps, then spawns integration checker for cross-phase wiring.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/audit-milestone.md
</execution_context>
<context>
Version: $ARGUMENTS (optional — defaults to current milestone)
Core planning files are resolved in-workflow (`init milestone-op`) and loaded only as needed.
**Completed Work:**
Glob: .planning/phases/*/*-SUMMARY.md
Glob: .planning/phases/*/*-VERIFICATION.md
</context>
<process>
Execute the audit-milestone workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/audit-milestone.md end-to-end.
Preserve all workflow gates (scope determination, verification reading, integration check, requirements coverage, routing).
</process>

View File

@@ -0,0 +1,41 @@
---
name: gsd:autonomous
description: Run all remaining phases autonomously — discuss→plan→execute per phase
argument-hint: "[--from N]"
allowed-tools:
- Read
- Write
- Bash
- Glob
- Grep
- AskUserQuestion
- Task
---
<objective>
Execute all remaining milestone phases autonomously. For each phase: discuss → plan → execute. Pauses only for user decisions (grey area acceptance, blockers, validation requests).
Uses ROADMAP.md phase discovery and Skill() flat invocations for each phase command. After all phases complete: milestone audit → complete → cleanup.
**Creates/Updates:**
- `.planning/STATE.md` — updated after each phase
- `.planning/ROADMAP.md` — progress updated after each phase
- Phase artifacts — CONTEXT.md, PLANs, SUMMARYs per phase
**After:** Milestone is complete and cleaned up.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/autonomous.md
@C:/Users/yaoji/.claude/get-shit-done/references/ui-brand.md
</execution_context>
<context>
Optional flag: `--from N` — start from phase N instead of the first incomplete phase.
Project context, phase list, and state are resolved inside the workflow using init commands (`gsd-tools.cjs init milestone-op`, `gsd-tools.cjs roadmap analyze`). No upfront context loading needed.
</context>
<process>
Execute the autonomous workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/autonomous.md end-to-end.
Preserve all workflow gates (phase discovery, per-phase execution, blocker handling, progress display).
</process>

View File

@@ -0,0 +1,45 @@
---
name: gsd:check-todos
description: List pending todos and select one to work on
argument-hint: [area filter]
allowed-tools:
- Read
- Write
- Bash
- AskUserQuestion
---
<objective>
List all pending todos, allow selection, load full context for the selected todo, and route to appropriate action.
Routes to the check-todos workflow which handles:
- Todo counting and listing with area filtering
- Interactive selection with full context loading
- Roadmap correlation checking
- Action routing (work now, add to phase, brainstorm, create phase)
- STATE.md updates and git commits
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/check-todos.md
</execution_context>
<context>
Arguments: $ARGUMENTS (optional area filter)
Todo state and roadmap correlation are loaded in-workflow using `init todos` and targeted reads.
</context>
<process>
**Follow the check-todos workflow** from `@C:/Users/yaoji/.claude/get-shit-done/workflows/check-todos.md`.
The workflow handles all logic including:
1. Todo existence checking
2. Area filtering
3. Interactive listing and selection
4. Full context loading with file summaries
5. Roadmap correlation checking
6. Action offering and execution
7. STATE.md updates
8. Git commits
</process>

18
commands/gsd/cleanup.md Normal file
View File

@@ -0,0 +1,18 @@
---
name: gsd:cleanup
description: Archive accumulated phase directories from completed milestones
---
<objective>
Archive phase directories from completed milestones into `.planning/milestones/v{X.Y}-phases/`.
Use when `.planning/phases/` has accumulated directories from past milestones.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/cleanup.md
</execution_context>
<process>
Follow the cleanup workflow at @C:/Users/yaoji/.claude/get-shit-done/workflows/cleanup.md.
Identify completed milestones, show a dry-run summary, and archive on confirmation.
</process>

View File

@@ -0,0 +1,136 @@
---
type: prompt
name: gsd:complete-milestone
description: Archive completed milestone and prepare for next version
argument-hint: <version>
allowed-tools:
- Read
- Write
- Bash
---
<objective>
Mark milestone {{version}} complete, archive to milestones/, and update ROADMAP.md and REQUIREMENTS.md.
Purpose: Create historical record of shipped version, archive milestone artifacts (roadmap + requirements), and prepare for next milestone.
Output: Milestone archived (roadmap + requirements), PROJECT.md evolved, git tagged.
</objective>
<execution_context>
**Load these files NOW (before proceeding):**
- @C:/Users/yaoji/.claude/get-shit-done/workflows/complete-milestone.md (main workflow)
- @C:/Users/yaoji/.claude/get-shit-done/templates/milestone-archive.md (archive template)
</execution_context>
<context>
**Project files:**
- `.planning/ROADMAP.md`
- `.planning/REQUIREMENTS.md`
- `.planning/STATE.md`
- `.planning/PROJECT.md`
**User input:**
- Version: {{version}} (e.g., "1.0", "1.1", "2.0")
</context>
<process>
**Follow complete-milestone.md workflow:**
0. **Check for audit:**
- Look for `.planning/v{{version}}-MILESTONE-AUDIT.md`
- If missing or stale: recommend `/gsd:audit-milestone` first
- If audit status is `gaps_found`: recommend `/gsd:plan-milestone-gaps` first
- If audit status is `passed`: proceed to step 1
```markdown
## Pre-flight Check
{If no v{{version}}-MILESTONE-AUDIT.md:}
⚠ No milestone audit found. Run `/gsd:audit-milestone` first to verify
requirements coverage, cross-phase integration, and E2E flows.
{If audit has gaps:}
⚠ Milestone audit found gaps. Run `/gsd:plan-milestone-gaps` to create
phases that close the gaps, or proceed anyway to accept as tech debt.
{If audit passed:}
✓ Milestone audit passed. Proceeding with completion.
```
1. **Verify readiness:**
- Check all phases in milestone have completed plans (SUMMARY.md exists)
- Present milestone scope and stats
- Wait for confirmation
2. **Gather stats:**
- Count phases, plans, tasks
- Calculate git range, file changes, LOC
- Extract timeline from git log
- Present summary, confirm
3. **Extract accomplishments:**
- Read all phase SUMMARY.md files in milestone range
- Extract 4-6 key accomplishments
- Present for approval
4. **Archive milestone:**
- Create `.planning/milestones/v{{version}}-ROADMAP.md`
- Extract full phase details from ROADMAP.md
- Fill milestone-archive.md template
- Update ROADMAP.md to one-line summary with link
5. **Archive requirements:**
- Create `.planning/milestones/v{{version}}-REQUIREMENTS.md`
- Mark all v1 requirements as complete (checkboxes checked)
- Note requirement outcomes (validated, adjusted, dropped)
- Delete `.planning/REQUIREMENTS.md` (fresh one created for next milestone)
6. **Update PROJECT.md:**
- Add "Current State" section with shipped version
- Add "Next Milestone Goals" section
- Archive previous content in `<details>` (if v1.1+)
7. **Commit and tag:**
- Stage: MILESTONES.md, PROJECT.md, ROADMAP.md, STATE.md, archive files
- Commit: `chore: archive v{{version}} milestone`
- Tag: `git tag -a v{{version}} -m "[milestone summary]"`
- Ask about pushing tag
8. **Offer next steps:**
- `/gsd:new-milestone` — start next milestone (questioning → research → requirements → roadmap)
</process>
<success_criteria>
- Milestone archived to `.planning/milestones/v{{version}}-ROADMAP.md`
- Requirements archived to `.planning/milestones/v{{version}}-REQUIREMENTS.md`
- `.planning/REQUIREMENTS.md` deleted (fresh for next milestone)
- ROADMAP.md collapsed to one-line entry
- PROJECT.md updated with current state
- Git tag v{{version}} created
- Commit successful
- User knows next steps (including need for fresh requirements)
</success_criteria>
<critical_rules>
- **Load workflow first:** Read complete-milestone.md before executing
- **Verify completion:** All phases must have SUMMARY.md files
- **User confirmation:** Wait for approval at verification gates
- **Archive before deleting:** Always create archive files before updating/deleting originals
- **One-line summary:** Collapsed milestone in ROADMAP.md should be single line with link
- **Context efficiency:** Archive keeps ROADMAP.md and REQUIREMENTS.md constant size per milestone
- **Fresh requirements:** Next milestone starts with `/gsd:new-milestone` which includes requirements definition
</critical_rules>

168
commands/gsd/debug.md Normal file
View File

@@ -0,0 +1,168 @@
---
name: gsd:debug
description: Systematic debugging with persistent state across context resets
argument-hint: [issue description]
allowed-tools:
- Read
- Bash
- Task
- AskUserQuestion
---
<objective>
Debug issues using scientific method with subagent isolation.
**Orchestrator role:** Gather symptoms, spawn gsd-debugger agent, handle checkpoints, spawn continuations.
**Why subagent:** Investigation burns context fast (reading files, forming hypotheses, testing). Fresh 200k context per investigation. Main context stays lean for user interaction.
</objective>
<context>
User's issue: $ARGUMENTS
Check for active sessions:
```bash
ls .planning/debug/*.md 2>/dev/null | grep -v resolved | head -5
```
</context>
<process>
## 0. Initialize Context
```bash
INIT=$(node "C:/Users/yaoji/.claude/get-shit-done/bin/gsd-tools.cjs" state load)
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
```
Extract `commit_docs` from init JSON. Resolve debugger model:
```bash
debugger_model=$(node "C:/Users/yaoji/.claude/get-shit-done/bin/gsd-tools.cjs" resolve-model gsd-debugger --raw)
```
## 1. Check Active Sessions
If active sessions exist AND no $ARGUMENTS:
- List sessions with status, hypothesis, next action
- User picks number to resume OR describes new issue
If $ARGUMENTS provided OR user describes new issue:
- Continue to symptom gathering
## 2. Gather Symptoms (if new issue)
Use AskUserQuestion for each:
1. **Expected behavior** - What should happen?
2. **Actual behavior** - What happens instead?
3. **Error messages** - Any errors? (paste or describe)
4. **Timeline** - When did this start? Ever worked?
5. **Reproduction** - How do you trigger it?
After all gathered, confirm ready to investigate.
## 3. Spawn gsd-debugger Agent
Fill prompt and spawn:
```markdown
<objective>
Investigate issue: {slug}
**Summary:** {trigger}
</objective>
<symptoms>
expected: {expected}
actual: {actual}
errors: {errors}
reproduction: {reproduction}
timeline: {timeline}
</symptoms>
<mode>
symptoms_prefilled: true
goal: find_and_fix
</mode>
<debug_file>
Create: .planning/debug/{slug}.md
</debug_file>
```
```
Task(
prompt=filled_prompt,
subagent_type="gsd-debugger",
model="{debugger_model}",
description="Debug {slug}"
)
```
## 4. Handle Agent Return
**If `## ROOT CAUSE FOUND`:**
- Display root cause and evidence summary
- Offer options:
- "Fix now" - spawn fix subagent
- "Plan fix" - suggest /gsd:plan-phase --gaps
- "Manual fix" - done
**If `## CHECKPOINT REACHED`:**
- Present checkpoint details to user
- Get user response
- If checkpoint type is `human-verify`:
- If user confirms fixed: continue so agent can finalize/resolve/archive
- If user reports issues: continue so agent returns to investigation/fixing
- Spawn continuation agent (see step 5)
**If `## INVESTIGATION INCONCLUSIVE`:**
- Show what was checked and eliminated
- Offer options:
- "Continue investigating" - spawn new agent with additional context
- "Manual investigation" - done
- "Add more context" - gather more symptoms, spawn again
## 5. Spawn Continuation Agent (After Checkpoint)
When user responds to checkpoint, spawn fresh agent:
```markdown
<objective>
Continue debugging {slug}. Evidence is in the debug file.
</objective>
<prior_state>
<files_to_read>
- .planning/debug/{slug}.md (Debug session state)
</files_to_read>
</prior_state>
<checkpoint_response>
**Type:** {checkpoint_type}
**Response:** {user_response}
</checkpoint_response>
<mode>
goal: find_and_fix
</mode>
```
```
Task(
prompt=continuation_prompt,
subagent_type="gsd-debugger",
model="{debugger_model}",
description="Continue debug {slug}"
)
```
</process>
<success_criteria>
- [ ] Active sessions checked
- [ ] Symptoms gathered (if new)
- [ ] gsd-debugger spawned with context
- [ ] Checkpoints handled correctly
- [ ] Root cause confirmed before fixing
</success_criteria>

View File

@@ -0,0 +1,91 @@
---
name: gsd:discuss-phase
description: Gather phase context through adaptive questioning before planning. Use --auto to skip interactive questions (Claude picks recommended defaults).
argument-hint: "<phase> [--auto]"
allowed-tools:
- Read
- Write
- Bash
- Glob
- Grep
- AskUserQuestion
- Task
- mcp__context7__resolve-library-id
- mcp__context7__query-docs
---
<objective>
Extract implementation decisions that downstream agents need — researcher and planner will use CONTEXT.md to know what to investigate and what choices are locked.
**How it works:**
1. Load prior context (PROJECT.md, REQUIREMENTS.md, STATE.md, prior CONTEXT.md files)
2. Scout codebase for reusable assets and patterns
3. Analyze phase — skip gray areas already decided in prior phases
4. Present remaining gray areas — user selects which to discuss
5. Deep-dive each selected area until satisfied
6. Create CONTEXT.md with decisions that guide research and planning
**Output:** `{phase_num}-CONTEXT.md` — decisions clear enough that downstream agents can act without asking the user again
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/discuss-phase.md
@C:/Users/yaoji/.claude/get-shit-done/templates/context.md
</execution_context>
<context>
Phase number: $ARGUMENTS (required)
Context files are resolved in-workflow using `init phase-op` and roadmap/state tool calls.
</context>
<process>
1. Validate phase number (error if missing or not in roadmap)
2. Check if CONTEXT.md exists (offer update/view/skip if yes)
3. **Load prior context** — Read PROJECT.md, REQUIREMENTS.md, STATE.md, and all prior CONTEXT.md files
4. **Scout codebase** — Find reusable assets, patterns, and integration points
5. **Analyze phase** — Check prior decisions, skip already-decided areas, generate remaining gray areas
6. **Present gray areas** — Multi-select: which to discuss? Annotate with prior decisions + code context
7. **Deep-dive each area** — 4 questions per area, code-informed options, Context7 for library choices
8. **Write CONTEXT.md** — Sections match areas discussed + code_context section
9. Offer next steps (research or plan)
**CRITICAL: Scope guardrail**
- Phase boundary from ROADMAP.md is FIXED
- Discussion clarifies HOW to implement, not WHETHER to add more
- If user suggests new capabilities: "That's its own phase. I'll note it for later."
- Capture deferred ideas — don't lose them, don't act on them
**Domain-aware gray areas:**
Gray areas depend on what's being built. Analyze the phase goal:
- Something users SEE → layout, density, interactions, states
- Something users CALL → responses, errors, auth, versioning
- Something users RUN → output format, flags, modes, error handling
- Something users READ → structure, tone, depth, flow
- Something being ORGANIZED → criteria, grouping, naming, exceptions
Generate 3-4 **phase-specific** gray areas, not generic categories.
**Probing depth:**
- Ask 4 questions per area before checking
- "More questions about [area], or move to next? (Remaining: [list unvisited areas])"
- Show remaining unvisited areas so user knows what's still ahead
- If more → ask 4 more, check again
- After all areas → "Ready to create context?"
**Do NOT ask about (Claude handles these):**
- Technical implementation
- Architecture choices
- Performance concerns
- Scope expansion
</process>
<success_criteria>
- Prior context loaded and applied (no re-asking decided questions)
- Gray areas identified through intelligent analysis
- User chose which areas to discuss
- Each selected area explored until satisfied
- Scope creep redirected to deferred ideas
- CONTEXT.md captures decisions, not vague vision
- User knows next steps
</success_criteria>

30
commands/gsd/do.md Normal file
View File

@@ -0,0 +1,30 @@
---
name: gsd:do
description: Route freeform text to the right GSD command automatically
argument-hint: "<description of what you want to do>"
allowed-tools:
- Read
- Bash
- AskUserQuestion
---
<objective>
Analyze freeform natural language input and dispatch to the most appropriate GSD command.
Acts as a smart dispatcher — never does the work itself. Matches intent to the best GSD command using routing rules, confirms the match, then hands off.
Use when you know what you want but don't know which `/gsd:*` command to run.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/do.md
@C:/Users/yaoji/.claude/get-shit-done/references/ui-brand.md
</execution_context>
<context>
$ARGUMENTS
</context>
<process>
Execute the do workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/do.md end-to-end.
Route user intent to the best GSD command and invoke it.
</process>

View File

@@ -0,0 +1,42 @@
---
name: gsd:execute-phase
description: Execute all plans in a phase with wave-based parallelization
argument-hint: "<phase-number> [--gaps-only] [--interactive]"
allowed-tools:
- Read
- Write
- Edit
- Glob
- Grep
- Bash
- Task
- TodoWrite
- AskUserQuestion
---
<objective>
Execute all plans in a phase using wave-based parallel execution.
Orchestrator stays lean: discover plans, analyze dependencies, group into waves, spawn subagents, collect results. Each subagent loads the full execute-plan context and handles its own plan.
Context budget: ~15% orchestrator, 100% fresh per subagent.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/execute-phase.md
@C:/Users/yaoji/.claude/get-shit-done/references/ui-brand.md
</execution_context>
<context>
Phase: $ARGUMENTS
**Flags:**
- `--gaps-only` — Execute only gap closure plans (plans with `gap_closure: true` in frontmatter). Use after verify-work creates fix plans.
- `--interactive` — Execute plans sequentially inline (no subagents) with user checkpoints between tasks. Lower token usage, pair-programming style. Best for small phases, bug fixes, and verification gaps.
Context files are resolved inside the workflow via `gsd-tools init execute-phase` and per-subagent `<files_to_read>` blocks.
</context>
<process>
Execute the execute-phase workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/execute-phase.md end-to-end.
Preserve all workflow gates (wave execution, checkpoint handling, verification, state updates, routing).
</process>

22
commands/gsd/health.md Normal file
View File

@@ -0,0 +1,22 @@
---
name: gsd:health
description: Diagnose planning directory health and optionally repair issues
argument-hint: [--repair]
allowed-tools:
- Read
- Bash
- Write
- AskUserQuestion
---
<objective>
Validate `.planning/` directory integrity and report actionable issues. Checks for missing files, invalid configurations, inconsistent state, and orphaned plans.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/health.md
</execution_context>
<process>
Execute the health workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/health.md end-to-end.
Parse --repair flag from arguments and pass to workflow.
</process>

22
commands/gsd/help.md Normal file
View File

@@ -0,0 +1,22 @@
---
name: gsd:help
description: Show available GSD commands and usage guide
---
<objective>
Display the complete GSD command reference.
Output ONLY the reference content below. Do NOT add:
- Project-specific analysis
- Git status or file context
- Next-step suggestions
- Any commentary beyond the reference
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/help.md
</execution_context>
<process>
Output the complete GSD command reference from @C:/Users/yaoji/.claude/get-shit-done/workflows/help.md.
Display the reference content directly — no additions or modifications.
</process>

View File

@@ -0,0 +1,32 @@
---
name: gsd:insert-phase
description: Insert urgent work as decimal phase (e.g., 72.1) between existing phases
argument-hint: <after> <description>
allowed-tools:
- Read
- Write
- Bash
---
<objective>
Insert a decimal phase for urgent work discovered mid-milestone that must be completed between existing integer phases.
Uses decimal numbering (72.1, 72.2, etc.) to preserve the logical sequence of planned phases while accommodating urgent insertions.
Purpose: Handle urgent work discovered during execution without renumbering entire roadmap.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/insert-phase.md
</execution_context>
<context>
Arguments: $ARGUMENTS (format: <after-phase-number> <description>)
Roadmap and state are resolved in-workflow via `init phase-op` and targeted tool calls.
</context>
<process>
Execute the insert-phase workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/insert-phase.md end-to-end.
Preserve all validation gates (argument parsing, phase verification, decimal calculation, roadmap updates).
</process>

View File

@@ -0,0 +1,18 @@
---
name: gsd:join-discord
description: Join the GSD Discord community
---
<objective>
Display the Discord invite link for the GSD community server.
</objective>
<output>
# Join the GSD Discord
Connect with other GSD users, get help, share what you're building, and stay updated.
**Invite link:** https://discord.gg/gsd
Click the link or paste it into your browser to join.
</output>

View File

@@ -0,0 +1,46 @@
---
name: gsd:list-phase-assumptions
description: Surface Claude's assumptions about a phase approach before planning
argument-hint: "[phase]"
allowed-tools:
- Read
- Bash
- Grep
- Glob
---
<objective>
Analyze a phase and present Claude's assumptions about technical approach, implementation order, scope boundaries, risk areas, and dependencies.
Purpose: Help users see what Claude thinks BEFORE planning begins - enabling course correction early when assumptions are wrong.
Output: Conversational output only (no file creation) - ends with "What do you think?" prompt
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/list-phase-assumptions.md
</execution_context>
<context>
Phase number: $ARGUMENTS (required)
Project state and roadmap are loaded in-workflow using targeted reads.
</context>
<process>
1. Validate phase number argument (error if missing or invalid)
2. Check if phase exists in roadmap
3. Follow list-phase-assumptions.md workflow:
- Analyze roadmap description
- Surface assumptions about: technical approach, implementation order, scope, risks, dependencies
- Present assumptions clearly
- Prompt "What do you think?"
4. Gather feedback and offer next steps
</process>
<success_criteria>
- Phase validated against roadmap
- Assumptions surfaced across five areas
- User prompted for feedback
- User knows next steps (discuss context, plan phase, or correct assumptions)
</success_criteria>

View File

@@ -0,0 +1,71 @@
---
name: gsd:map-codebase
description: Analyze codebase with parallel mapper agents to produce .planning/codebase/ documents
argument-hint: "[optional: specific area to map, e.g., 'api' or 'auth']"
allowed-tools:
- Read
- Bash
- Glob
- Grep
- Write
- Task
---
<objective>
Analyze existing codebase using parallel gsd-codebase-mapper agents to produce structured codebase documents.
Each mapper agent explores a focus area and **writes documents directly** to `.planning/codebase/`. The orchestrator only receives confirmations, keeping context usage minimal.
Output: .planning/codebase/ folder with 7 structured documents about the codebase state.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/map-codebase.md
</execution_context>
<context>
Focus area: $ARGUMENTS (optional - if provided, tells agents to focus on specific subsystem)
**Load project state if exists:**
Check for .planning/STATE.md - loads context if project already initialized
**This command can run:**
- Before /gsd:new-project (brownfield codebases) - creates codebase map first
- After /gsd:new-project (greenfield codebases) - updates codebase map as code evolves
- Anytime to refresh codebase understanding
</context>
<when_to_use>
**Use map-codebase for:**
- Brownfield projects before initialization (understand existing code first)
- Refreshing codebase map after significant changes
- Onboarding to an unfamiliar codebase
- Before major refactoring (understand current state)
- When STATE.md references outdated codebase info
**Skip map-codebase for:**
- Greenfield projects with no code yet (nothing to map)
- Trivial codebases (<5 files)
</when_to_use>
<process>
1. Check if .planning/codebase/ already exists (offer to refresh or skip)
2. Create .planning/codebase/ directory structure
3. Spawn 4 parallel gsd-codebase-mapper agents:
- Agent 1: tech focus → writes STACK.md, INTEGRATIONS.md
- Agent 2: arch focus → writes ARCHITECTURE.md, STRUCTURE.md
- Agent 3: quality focus → writes CONVENTIONS.md, TESTING.md
- Agent 4: concerns focus → writes CONCERNS.md
4. Wait for agents to complete, collect confirmations (NOT document contents)
5. Verify all 7 documents exist with line counts
6. Commit codebase map
7. Offer next steps (typically: /gsd:new-project or /gsd:plan-phase)
</process>
<success_criteria>
- [ ] .planning/codebase/ directory created
- [ ] All 7 codebase documents written by mapper agents
- [ ] Documents follow template structure
- [ ] Parallel agents completed without errors
- [ ] User knows next steps
</success_criteria>

View File

@@ -0,0 +1,44 @@
---
name: gsd:new-milestone
description: Start a new milestone cycle — update PROJECT.md and route to requirements
argument-hint: "[milestone name, e.g., 'v1.1 Notifications']"
allowed-tools:
- Read
- Write
- Bash
- Task
- AskUserQuestion
---
<objective>
Start a new milestone: questioning → research (optional) → requirements → roadmap.
Brownfield equivalent of new-project. Project exists, PROJECT.md has history. Gathers "what's next", updates PROJECT.md, then runs requirements → roadmap cycle.
**Creates/Updates:**
- `.planning/PROJECT.md` — updated with new milestone goals
- `.planning/research/` — domain research (optional, NEW features only)
- `.planning/REQUIREMENTS.md` — scoped requirements for this milestone
- `.planning/ROADMAP.md` — phase structure (continues numbering)
- `.planning/STATE.md` — reset for new milestone
**After:** `/gsd:plan-phase [N]` to start execution.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/new-milestone.md
@C:/Users/yaoji/.claude/get-shit-done/references/questioning.md
@C:/Users/yaoji/.claude/get-shit-done/references/ui-brand.md
@C:/Users/yaoji/.claude/get-shit-done/templates/project.md
@C:/Users/yaoji/.claude/get-shit-done/templates/requirements.md
</execution_context>
<context>
Milestone name: $ARGUMENTS (optional - will prompt if not provided)
Project and milestone context files are resolved inside the workflow (`init new-milestone`) and delegated via `<files_to_read>` blocks where subagents are used.
</context>
<process>
Execute the new-milestone workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/new-milestone.md end-to-end.
Preserve all workflow gates (validation, questioning, research, requirements, roadmap approval, commits).
</process>

View File

@@ -0,0 +1,42 @@
---
name: gsd:new-project
description: Initialize a new project with deep context gathering and PROJECT.md
argument-hint: "[--auto]"
allowed-tools:
- Read
- Bash
- Write
- Task
- AskUserQuestion
---
<context>
**Flags:**
- `--auto` — Automatic mode. After config questions, runs research → requirements → roadmap without further interaction. Expects idea document via @ reference.
</context>
<objective>
Initialize a new project through unified flow: questioning → research (optional) → requirements → roadmap.
**Creates:**
- `.planning/PROJECT.md` — project context
- `.planning/config.json` — workflow preferences
- `.planning/research/` — domain research (optional)
- `.planning/REQUIREMENTS.md` — scoped requirements
- `.planning/ROADMAP.md` — phase structure
- `.planning/STATE.md` — project memory
**After this command:** Run `/gsd:plan-phase 1` to start execution.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/new-project.md
@C:/Users/yaoji/.claude/get-shit-done/references/questioning.md
@C:/Users/yaoji/.claude/get-shit-done/references/ui-brand.md
@C:/Users/yaoji/.claude/get-shit-done/templates/project.md
@C:/Users/yaoji/.claude/get-shit-done/templates/requirements.md
</execution_context>
<process>
Execute the new-project workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/new-project.md end-to-end.
Preserve all workflow gates (validation, approvals, commits, routing).
</process>

24
commands/gsd/next.md Normal file
View File

@@ -0,0 +1,24 @@
---
name: gsd:next
description: Automatically advance to the next logical step in the GSD workflow
allowed-tools:
- Read
- Bash
- Grep
- Glob
- SlashCommand
---
<objective>
Detect the current project state and automatically invoke the next logical GSD workflow step.
No arguments needed — reads STATE.md, ROADMAP.md, and phase directories to determine what comes next.
Designed for rapid multi-project workflows where remembering which phase/step you're on is overhead.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/next.md
</execution_context>
<process>
Execute the next workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/next.md end-to-end.
</process>

34
commands/gsd/note.md Normal file
View File

@@ -0,0 +1,34 @@
---
name: gsd:note
description: Zero-friction idea capture. Append, list, or promote notes to todos.
argument-hint: "<text> | list | promote <N> [--global]"
allowed-tools:
- Read
- Write
- Glob
- Grep
---
<objective>
Zero-friction idea capture — one Write call, one confirmation line.
Three subcommands:
- **append** (default): Save a timestamped note file. No questions, no formatting.
- **list**: Show all notes from project and global scopes.
- **promote**: Convert a note into a structured todo.
Runs inline — no Task, no AskUserQuestion, no Bash.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/note.md
@C:/Users/yaoji/.claude/get-shit-done/references/ui-brand.md
</execution_context>
<context>
$ARGUMENTS
</context>
<process>
Execute the note workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/note.md end-to-end.
Capture the note, list notes, or promote to todo — depending on arguments.
</process>

View File

@@ -0,0 +1,38 @@
---
name: gsd:pause-work
description: Create context handoff when pausing work mid-phase
allowed-tools:
- Read
- Write
- Bash
---
<objective>
Create `.continue-here.md` handoff file to preserve complete work state across sessions.
Routes to the pause-work workflow which handles:
- Current phase detection from recent files
- Complete state gathering (position, completed work, remaining work, decisions, blockers)
- Handoff file creation with all context sections
- Git commit as WIP
- Resume instructions
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/pause-work.md
</execution_context>
<context>
State and phase progress are gathered in-workflow with targeted reads.
</context>
<process>
**Follow the pause-work workflow** from `@C:/Users/yaoji/.claude/get-shit-done/workflows/pause-work.md`.
The workflow handles all logic including:
1. Phase directory detection
2. State gathering with user clarifications
3. Handoff file writing with timestamp
4. Git commit
5. Confirmation with resume instructions
</process>

View File

@@ -0,0 +1,34 @@
---
name: gsd:plan-milestone-gaps
description: Create phases to close all gaps identified by milestone audit
allowed-tools:
- Read
- Write
- Bash
- Glob
- Grep
- AskUserQuestion
---
<objective>
Create all phases necessary to close gaps identified by `/gsd:audit-milestone`.
Reads MILESTONE-AUDIT.md, groups gaps into logical phases, creates phase entries in ROADMAP.md, and offers to plan each phase.
One command creates all fix phases — no manual `/gsd:add-phase` per gap.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/plan-milestone-gaps.md
</execution_context>
<context>
**Audit results:**
Glob: .planning/v*-MILESTONE-AUDIT.md (use most recent)
Original intent and current planning state are loaded on demand inside the workflow.
</context>
<process>
Execute the plan-milestone-gaps workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/plan-milestone-gaps.md end-to-end.
Preserve all workflow gates (audit loading, prioritization, phase grouping, user confirmation, roadmap updates).
</process>

View File

@@ -0,0 +1,45 @@
---
name: gsd:plan-phase
description: Create detailed phase plan (PLAN.md) with verification loop
argument-hint: "[phase] [--auto] [--research] [--skip-research] [--gaps] [--skip-verify] [--prd <file>]"
agent: gsd-planner
allowed-tools:
- Read
- Write
- Bash
- Glob
- Grep
- Task
- WebFetch
- mcp__context7__*
---
<objective>
Create executable phase prompts (PLAN.md files) for a roadmap phase with integrated research and verification.
**Default flow:** Research (if needed) → Plan → Verify → Done
**Orchestrator role:** Parse arguments, validate phase, research domain (unless skipped), spawn gsd-planner, verify with gsd-plan-checker, iterate until pass or max iterations, present results.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/plan-phase.md
@C:/Users/yaoji/.claude/get-shit-done/references/ui-brand.md
</execution_context>
<context>
Phase number: $ARGUMENTS (optional — auto-detects next unplanned phase if omitted)
**Flags:**
- `--research` — Force re-research even if RESEARCH.md exists
- `--skip-research` — Skip research, go straight to planning
- `--gaps` — Gap closure mode (reads VERIFICATION.md, skips research)
- `--skip-verify` — Skip verification loop
- `--prd <file>` — Use a PRD/acceptance criteria file instead of discuss-phase. Parses requirements into CONTEXT.md automatically. Skips discuss-phase entirely.
Normalize phase input in step 2 before any directory lookups.
</context>
<process>
Execute the plan-phase workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/plan-phase.md end-to-end.
Preserve all workflow gates (validation, research, planning, verification loop, routing).
</process>

View File

@@ -0,0 +1,46 @@
---
name: gsd:profile-user
description: Generate developer behavioral profile and create Claude-discoverable artifacts
argument-hint: "[--questionnaire] [--refresh]"
allowed-tools:
- Read
- Write
- Bash
- Glob
- Grep
- AskUserQuestion
- Task
---
<objective>
Generate a developer behavioral profile from session analysis (or questionnaire) and produce artifacts (USER-PROFILE.md, /gsd:dev-preferences, CLAUDE.md section) that personalize Claude's responses.
Routes to the profile-user workflow which orchestrates the full flow: consent gate, session analysis or questionnaire fallback, profile generation, result display, and artifact selection.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/profile-user.md
@C:/Users/yaoji/.claude/get-shit-done/references/ui-brand.md
</execution_context>
<context>
Flags from $ARGUMENTS:
- `--questionnaire` -- Skip session analysis entirely, use questionnaire-only path
- `--refresh` -- Rebuild profile even when one exists, backup old profile, show dimension diff
</context>
<process>
Execute the profile-user workflow end-to-end.
The workflow handles all logic including:
1. Initialization and existing profile detection
2. Consent gate before session analysis
3. Session scanning and data sufficiency checks
4. Session analysis (profiler agent) or questionnaire fallback
5. Cross-project split resolution
6. Profile writing to USER-PROFILE.md
7. Result display with report card and highlights
8. Artifact selection (dev-preferences, CLAUDE.md sections)
9. Sequential artifact generation
10. Summary with refresh diff (if applicable)
</process>

24
commands/gsd/progress.md Normal file
View File

@@ -0,0 +1,24 @@
---
name: gsd:progress
description: Check project progress, show context, and route to next action (execute or plan)
allowed-tools:
- Read
- Bash
- Grep
- Glob
- SlashCommand
---
<objective>
Check project progress, summarize recent work and what's ahead, then intelligently route to the next action - either executing an existing plan or creating the next one.
Provides situational awareness before continuing work.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/progress.md
</execution_context>
<process>
Execute the progress workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/progress.md end-to-end.
Preserve all routing logic (Routes A through F) and edge case handling.
</process>

47
commands/gsd/quick.md Normal file
View File

@@ -0,0 +1,47 @@
---
name: gsd:quick
description: Execute a quick task with GSD guarantees (atomic commits, state tracking) but skip optional agents
argument-hint: "[--full] [--discuss] [--research]"
allowed-tools:
- Read
- Write
- Edit
- Glob
- Grep
- Bash
- Task
- AskUserQuestion
---
<objective>
Execute small, ad-hoc tasks with GSD guarantees (atomic commits, STATE.md tracking).
Quick mode is the same system with a shorter path:
- Spawns gsd-planner (quick mode) + gsd-executor(s)
- Quick tasks live in `.planning/quick/` separate from planned phases
- Updates STATE.md "Quick Tasks Completed" table (NOT ROADMAP.md)
**Default:** Skips research, discussion, plan-checker, verifier. Use when you know exactly what to do.
**`--discuss` flag:** Lightweight discussion phase before planning. Surfaces assumptions, clarifies gray areas, captures decisions in CONTEXT.md. Use when the task has ambiguity worth resolving upfront.
**`--full` flag:** Enables plan-checking (max 2 iterations) and post-execution verification. Use when you want quality guarantees without full milestone ceremony.
**`--research` flag:** Spawns a focused research agent before planning. Investigates implementation approaches, library options, and pitfalls for the task. Use when you're unsure of the best approach.
Flags are composable: `--discuss --research --full` gives discussion + research + plan-checking + verification.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/quick.md
</execution_context>
<context>
$ARGUMENTS
Context files are resolved inside the workflow (`init quick`) and delegated via `<files_to_read>` blocks.
</context>
<process>
Execute the quick workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/quick.md end-to-end.
Preserve all workflow gates (validation, task description, planning, execution, state updates, commits).
</process>

View File

@@ -0,0 +1,123 @@
---
description: Reapply local modifications after a GSD update
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
---
<purpose>
After a GSD update wipes and reinstalls files, this command merges user's previously saved local modifications back into the new version. Uses intelligent comparison to handle cases where the upstream file also changed.
</purpose>
<process>
## Step 1: Detect backed-up patches
Check for local patches directory:
```bash
# Global install — detect runtime config directory
if [ -d "$HOME/.config/opencode/gsd-local-patches" ]; then
PATCHES_DIR="$HOME/.config/opencode/gsd-local-patches"
elif [ -d "$HOME/.opencode/gsd-local-patches" ]; then
PATCHES_DIR="$HOME/.opencode/gsd-local-patches"
elif [ -d "$HOME/.gemini/gsd-local-patches" ]; then
PATCHES_DIR="$HOME/.gemini/gsd-local-patches"
else
PATCHES_DIR="C:/Users/yaoji/.claude/gsd-local-patches"
fi
# Local install fallback — check all runtime directories
if [ ! -d "$PATCHES_DIR" ]; then
for dir in .config/opencode .opencode .gemini .claude; do
if [ -d "./$dir/gsd-local-patches" ]; then
PATCHES_DIR="./$dir/gsd-local-patches"
break
fi
done
fi
```
Read `backup-meta.json` from the patches directory.
**If no patches found:**
```
No local patches found. Nothing to reapply.
Local patches are automatically saved when you run /gsd:update
after modifying any GSD workflow, command, or agent files.
```
Exit.
## Step 2: Show patch summary
```
## Local Patches to Reapply
**Backed up from:** v{from_version}
**Current version:** {read VERSION file}
**Files modified:** {count}
| # | File | Status |
|---|------|--------|
| 1 | {file_path} | Pending |
| 2 | {file_path} | Pending |
```
## Step 3: Merge each file
For each file in `backup-meta.json`:
1. **Read the backed-up version** (user's modified copy from `gsd-local-patches/`)
2. **Read the newly installed version** (current file after update)
3. **Compare and merge:**
- If the new file is identical to the backed-up file: skip (modification was incorporated upstream)
- If the new file differs: identify the user's modifications and apply them to the new version
**Merge strategy:**
- Read both versions fully
- Identify sections the user added or modified (look for additions, not just differences from path replacement)
- Apply user's additions/modifications to the new version
- If a section the user modified was also changed upstream: flag as conflict, show both versions, ask user which to keep
4. **Write merged result** to the installed location
5. **Report status:**
- `Merged` — user modifications applied cleanly
- `Skipped` — modification already in upstream
- `Conflict` — user chose resolution
## Step 4: Update manifest
After reapplying, regenerate the file manifest so future updates correctly detect these as user modifications:
```bash
# The manifest will be regenerated on next /gsd:update
# For now, just note which files were modified
```
## Step 5: Cleanup option
Ask user:
- "Keep patch backups for reference?" → preserve `gsd-local-patches/`
- "Clean up patch backups?" → remove `gsd-local-patches/` directory
## Step 6: Report
```
## Patches Reapplied
| # | File | Status |
|---|------|--------|
| 1 | {file_path} | ✓ Merged |
| 2 | {file_path} | ○ Skipped (already upstream) |
| 3 | {file_path} | ⚠ Conflict resolved |
{count} file(s) updated. Your local modifications are active again.
```
</process>
<success_criteria>
- [ ] All backed-up patches processed
- [ ] User modifications merged into new version
- [ ] Conflicts resolved with user input
- [ ] Status reported for each file
</success_criteria>

View File

@@ -0,0 +1,31 @@
---
name: gsd:remove-phase
description: Remove a future phase from roadmap and renumber subsequent phases
argument-hint: <phase-number>
allowed-tools:
- Read
- Write
- Bash
- Glob
---
<objective>
Remove an unstarted future phase from the roadmap and renumber all subsequent phases to maintain a clean, linear sequence.
Purpose: Clean removal of work you've decided not to do, without polluting context with cancelled/deferred markers.
Output: Phase deleted, all subsequent phases renumbered, git commit as historical record.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/remove-phase.md
</execution_context>
<context>
Phase: $ARGUMENTS
Roadmap and state are resolved in-workflow via `init phase-op` and targeted reads.
</context>
<process>
Execute the remove-phase workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/remove-phase.md end-to-end.
Preserve all validation gates (future phase check, work check), renumbering logic, and commit.
</process>

View File

@@ -0,0 +1,190 @@
---
name: gsd:research-phase
description: Research how to implement a phase (standalone - usually use /gsd:plan-phase instead)
argument-hint: "[phase]"
allowed-tools:
- Read
- Bash
- Task
---
<objective>
Research how to implement a phase. Spawns gsd-phase-researcher agent with phase context.
**Note:** This is a standalone research command. For most workflows, use `/gsd:plan-phase` which integrates research automatically.
**Use this command when:**
- You want to research without planning yet
- You want to re-research after planning is complete
- You need to investigate before deciding if a phase is feasible
**Orchestrator role:** Parse phase, validate against roadmap, check existing research, gather context, spawn researcher agent, present results.
**Why subagent:** Research burns context fast (WebSearch, Context7 queries, source verification). Fresh 200k context for investigation. Main context stays lean for user interaction.
</objective>
<context>
Phase number: $ARGUMENTS (required)
Normalize phase input in step 1 before any directory lookups.
</context>
<process>
## 0. Initialize Context
```bash
INIT=$(node "C:/Users/yaoji/.claude/get-shit-done/bin/gsd-tools.cjs" init phase-op "$ARGUMENTS")
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
```
Extract from init JSON: `phase_dir`, `phase_number`, `phase_name`, `phase_found`, `commit_docs`, `has_research`, `state_path`, `requirements_path`, `context_path`, `research_path`.
Resolve researcher model:
```bash
RESEARCHER_MODEL=$(node "C:/Users/yaoji/.claude/get-shit-done/bin/gsd-tools.cjs" resolve-model gsd-phase-researcher --raw)
```
## 1. Validate Phase
```bash
PHASE_INFO=$(node "C:/Users/yaoji/.claude/get-shit-done/bin/gsd-tools.cjs" roadmap get-phase "${phase_number}")
```
**If `found` is false:** Error and exit. **If `found` is true:** Extract `phase_number`, `phase_name`, `goal` from JSON.
## 2. Check Existing Research
```bash
ls .planning/phases/${PHASE}-*/RESEARCH.md 2>/dev/null
```
**If exists:** Offer: 1) Update research, 2) View existing, 3) Skip. Wait for response.
**If doesn't exist:** Continue.
## 3. Gather Phase Context
Use paths from INIT (do not inline file contents in orchestrator context):
- `requirements_path`
- `context_path`
- `state_path`
Present summary with phase description and what files the researcher will load.
## 4. Spawn gsd-phase-researcher Agent
Research modes: ecosystem (default), feasibility, implementation, comparison.
```markdown
<research_type>
Phase Research — investigating HOW to implement a specific phase well.
</research_type>
<key_insight>
The question is NOT "which library should I use?"
The question is: "What do I not know that I don't know?"
For this phase, discover:
- What's the established architecture pattern?
- What libraries form the standard stack?
- What problems do people commonly hit?
- What's SOTA vs what Claude's training thinks is SOTA?
- What should NOT be hand-rolled?
</key_insight>
<objective>
Research implementation approach for Phase {phase_number}: {phase_name}
Mode: ecosystem
</objective>
<files_to_read>
- {requirements_path} (Requirements)
- {context_path} (Phase context from discuss-phase, if exists)
- {state_path} (Prior project decisions and blockers)
</files_to_read>
<additional_context>
**Phase description:** {phase_description}
</additional_context>
<downstream_consumer>
Your RESEARCH.md will be loaded by `/gsd:plan-phase` which uses specific sections:
- `## Standard Stack` → Plans use these libraries
- `## Architecture Patterns` → Task structure follows these
- `## Don't Hand-Roll` → Tasks NEVER build custom solutions for listed problems
- `## Common Pitfalls` → Verification steps check for these
- `## Code Examples` → Task actions reference these patterns
Be prescriptive, not exploratory. "Use X" not "Consider X or Y."
</downstream_consumer>
<quality_gate>
Before declaring complete, verify:
- [ ] All domains investigated (not just some)
- [ ] Negative claims verified with official docs
- [ ] Multiple sources for critical claims
- [ ] Confidence levels assigned honestly
- [ ] Section names match what plan-phase expects
</quality_gate>
<output>
Write to: .planning/phases/${PHASE}-{slug}/${PHASE}-RESEARCH.md
</output>
```
```
Task(
prompt=filled_prompt,
subagent_type="gsd-phase-researcher",
model="{researcher_model}",
description="Research Phase {phase}"
)
```
## 5. Handle Agent Return
**`## RESEARCH COMPLETE`:** Display summary, offer: Plan phase, Dig deeper, Review full, Done.
**`## CHECKPOINT REACHED`:** Present to user, get response, spawn continuation.
**`## RESEARCH INCONCLUSIVE`:** Show what was attempted, offer: Add context, Try different mode, Manual.
## 6. Spawn Continuation Agent
```markdown
<objective>
Continue research for Phase {phase_number}: {phase_name}
</objective>
<prior_state>
<files_to_read>
- .planning/phases/${PHASE}-{slug}/${PHASE}-RESEARCH.md (Existing research)
</files_to_read>
</prior_state>
<checkpoint_response>
**Type:** {checkpoint_type}
**Response:** {user_response}
</checkpoint_response>
```
```
Task(
prompt=continuation_prompt,
subagent_type="gsd-phase-researcher",
model="{researcher_model}",
description="Continue research Phase {phase}"
)
```
</process>
<success_criteria>
- [ ] Phase validated against roadmap
- [ ] Existing research checked
- [ ] gsd-phase-researcher spawned with context
- [ ] Checkpoints handled correctly
- [ ] User knows next steps
</success_criteria>

View File

@@ -0,0 +1,40 @@
---
name: gsd:resume-work
description: Resume work from previous session with full context restoration
allowed-tools:
- Read
- Bash
- Write
- AskUserQuestion
- SlashCommand
---
<objective>
Restore complete project context and resume work seamlessly from previous session.
Routes to the resume-project workflow which handles:
- STATE.md loading (or reconstruction if missing)
- Checkpoint detection (.continue-here files)
- Incomplete work detection (PLAN without SUMMARY)
- Status presentation
- Context-aware next action routing
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/resume-project.md
</execution_context>
<process>
**Follow the resume-project workflow** from `@C:/Users/yaoji/.claude/get-shit-done/workflows/resume-project.md`.
The workflow handles all resumption logic including:
1. Project existence verification
2. STATE.md loading or reconstruction
3. Checkpoint and incomplete work detection
4. Visual status presentation
5. Context-aware option offering (checks CONTEXT.md before suggesting plan vs discuss)
6. Routing to appropriate next command
7. Session continuity updates
</process>

View File

@@ -0,0 +1,19 @@
---
name: gsd:session-report
description: Generate a session report with token usage estimates, work summary, and outcomes
allowed-tools:
- Read
- Bash
- Write
---
<objective>
Generate a structured SESSION_REPORT.md document capturing session outcomes, work performed, and estimated resource usage. Provides a shareable artifact for post-session review.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/session-report.md
</execution_context>
<process>
Execute the session-report workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/session-report.md end-to-end.
</process>

View File

@@ -0,0 +1,12 @@
---
name: gsd:set-profile
description: Switch model profile for GSD agents (quality/balanced/budget/inherit)
argument-hint: <profile (quality|balanced|budget|inherit)>
model: haiku
allowed-tools:
- Bash
---
Show the following output to the user verbatim, with no extra commentary:
!`node "C:/Users/yaoji/.claude/get-shit-done/bin/gsd-tools.cjs" config-set-model-profile $ARGUMENTS --raw`

36
commands/gsd/settings.md Normal file
View File

@@ -0,0 +1,36 @@
---
name: gsd:settings
description: Configure GSD workflow toggles and model profile
allowed-tools:
- Read
- Write
- Bash
- AskUserQuestion
---
<objective>
Interactive configuration of GSD workflow agents and model profile via multi-question prompt.
Routes to the settings workflow which handles:
- Config existence ensuring
- Current settings reading and parsing
- Interactive 5-question prompt (model, research, plan_check, verifier, branching)
- Config merging and writing
- Confirmation display with quick command references
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/settings.md
</execution_context>
<process>
**Follow the settings workflow** from `@C:/Users/yaoji/.claude/get-shit-done/workflows/settings.md`.
The workflow handles all logic including:
1. Config file creation with defaults if missing
2. Current config reading
3. Interactive settings presentation with pre-selection
4. Answer parsing and config merging
5. File writing
6. Confirmation display
</process>

23
commands/gsd/ship.md Normal file
View File

@@ -0,0 +1,23 @@
---
name: gsd:ship
description: Create PR, run review, and prepare for merge after verification passes
argument-hint: "[phase number or milestone, e.g., '4' or 'v1.0']"
allowed-tools:
- Read
- Bash
- Grep
- Glob
- Write
- AskUserQuestion
---
<objective>
Bridge local completion → merged PR. After /gsd:verify-work passes, ship the work: push branch, create PR with auto-generated body, optionally trigger review, and track the merge.
Closes the plan → execute → verify → ship loop.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/ship.md
</execution_context>
Execute the ship workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/ship.md end-to-end.

18
commands/gsd/stats.md Normal file
View File

@@ -0,0 +1,18 @@
---
name: gsd:stats
description: Display project statistics — phases, plans, requirements, git metrics, and timeline
allowed-tools:
- Read
- Bash
---
<objective>
Display comprehensive project statistics including phase progress, plan execution metrics, requirements completion, git history stats, and project timeline.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/stats.md
</execution_context>
<process>
Execute the stats workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/stats.md end-to-end.
</process>

34
commands/gsd/ui-phase.md Normal file
View File

@@ -0,0 +1,34 @@
---
name: gsd:ui-phase
description: Generate UI design contract (UI-SPEC.md) for frontend phases
argument-hint: "[phase]"
allowed-tools:
- Read
- Write
- Bash
- Glob
- Grep
- Task
- WebFetch
- AskUserQuestion
- mcp__context7__*
---
<objective>
Create a UI design contract (UI-SPEC.md) for a frontend phase.
Orchestrates gsd-ui-researcher and gsd-ui-checker.
Flow: Validate → Research UI → Verify UI-SPEC → Done
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/ui-phase.md
@C:/Users/yaoji/.claude/get-shit-done/references/ui-brand.md
</execution_context>
<context>
Phase number: $ARGUMENTS — optional, auto-detects next unplanned phase if omitted.
</context>
<process>
Execute @C:/Users/yaoji/.claude/get-shit-done/workflows/ui-phase.md end-to-end.
Preserve all workflow gates.
</process>

32
commands/gsd/ui-review.md Normal file
View File

@@ -0,0 +1,32 @@
---
name: gsd:ui-review
description: Retroactive 6-pillar visual audit of implemented frontend code
argument-hint: "[phase]"
allowed-tools:
- Read
- Write
- Bash
- Glob
- Grep
- Task
- AskUserQuestion
---
<objective>
Conduct a retroactive 6-pillar visual audit. Produces UI-REVIEW.md with
graded assessment (1-4 per pillar). Works on any project.
Output: {phase_num}-UI-REVIEW.md
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/ui-review.md
@C:/Users/yaoji/.claude/get-shit-done/references/ui-brand.md
</execution_context>
<context>
Phase: $ARGUMENTS — optional, defaults to last completed phase.
</context>
<process>
Execute @C:/Users/yaoji/.claude/get-shit-done/workflows/ui-review.md end-to-end.
Preserve all workflow gates.
</process>

37
commands/gsd/update.md Normal file
View File

@@ -0,0 +1,37 @@
---
name: gsd:update
description: Update GSD to latest version with changelog display
allowed-tools:
- Bash
- AskUserQuestion
---
<objective>
Check for GSD updates, install if available, and display what changed.
Routes to the update workflow which handles:
- Version detection (local vs global installation)
- npm version checking
- Changelog fetching and display
- User confirmation with clean install warning
- Update execution and cache clearing
- Restart reminder
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/update.md
</execution_context>
<process>
**Follow the update workflow** from `@C:/Users/yaoji/.claude/get-shit-done/workflows/update.md`.
The workflow handles all logic including:
1. Installed version detection (local/global)
2. Latest version checking via npm
3. Version comparison
4. Changelog fetching and extraction
5. Clean install warning display
6. User confirmation
7. Update execution
8. Cache clearing
</process>

View File

@@ -0,0 +1,35 @@
---
name: gsd:validate-phase
description: Retroactively audit and fill Nyquist validation gaps for a completed phase
argument-hint: "[phase number]"
allowed-tools:
- Read
- Write
- Edit
- Bash
- Glob
- Grep
- Task
- AskUserQuestion
---
<objective>
Audit Nyquist validation coverage for a completed phase. Three states:
- (A) VALIDATION.md exists — audit and fill gaps
- (B) No VALIDATION.md, SUMMARY.md exists — reconstruct from artifacts
- (C) Phase not executed — exit with guidance
Output: updated VALIDATION.md + generated test files.
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/validate-phase.md
</execution_context>
<context>
Phase: $ARGUMENTS — optional, defaults to last completed phase.
</context>
<process>
Execute @C:/Users/yaoji/.claude/get-shit-done/workflows/validate-phase.md.
Preserve all workflow gates.
</process>

View File

@@ -0,0 +1,38 @@
---
name: gsd:verify-work
description: Validate built features through conversational UAT
argument-hint: "[phase number, e.g., '4']"
allowed-tools:
- Read
- Bash
- Glob
- Grep
- Edit
- Write
- Task
---
<objective>
Validate built features through conversational testing with persistent state.
Purpose: Confirm what Claude built actually works from user's perspective. One test at a time, plain text responses, no interrogation. When issues are found, automatically diagnose, plan fixes, and prepare for execution.
Output: {phase_num}-UAT.md tracking all test results. If issues found: diagnosed gaps, verified fix plans ready for /gsd:execute-phase
</objective>
<execution_context>
@C:/Users/yaoji/.claude/get-shit-done/workflows/verify-work.md
@C:/Users/yaoji/.claude/get-shit-done/templates/UAT.md
</execution_context>
<context>
Phase: $ARGUMENTS (optional)
- If provided: Test specific phase (e.g., "4")
- If not provided: Check for active sessions or prompt for phase
Context files are resolved inside the workflow (`init verify-work`) and delegated via `<files_to_read>` blocks.
</context>
<process>
Execute the verify-work workflow from @C:/Users/yaoji/.claude/get-shit-done/workflows/verify-work.md end-to-end.
Preserve all workflow gates (session management, test presentation, diagnosis, fix planning, routing).
</process>