Commands are now installed as commands/gsd/<name>.md and invoked as /gsd:<name> in Claude Code. The old hyphen form /gsd-<name> was still hardcoded in hundreds of places across workflows, references, templates, lib modules, and command files — causing "Unknown command" errors whenever GSD suggested a command to the user. Replace all /gsd-<cmd> occurrences where <cmd> is a known command name (derived at runtime from commands/gsd/*.md) using a targeted Node.js script. Agent names, tool names (gsd-sdk, gsd-tools), directory names, and path fragments are not touched. Adds regression test tests/bug-2543-gsd-slash-namespace.test.cjs that enforces zero legacy occurrences going forward. Removes inverted tests/stale-colon-refs.test.cjs (bug #1748) which enforced the now-obsolete hyphen form; the new bug-2543 test supersedes it. Updates 5 assertion tests that hardcoded the old hyphen form to accept the new colon form. Closes #2543 Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5.5 KiB
<required_reading> Read all files referenced by the invoking prompt's execution_context before starting. </required_reading>
**Check for input.**Text mode (workflow.text_mode: true in config or --text flag): Set TEXT_MODE=true if --text is present in $ARGUMENTS OR text_mode from init JSON is true. When TEXT_MODE is active, replace every AskUserQuestion call with a plain-text numbered list and ask the user to type their choice number. This is required for non-Claude runtimes (OpenAI Codex, Gemini CLI, etc.) where AskUserQuestion is not available.
If $ARGUMENTS is empty, ask via AskUserQuestion:
What would you like to do? Describe the task, bug, or idea and I'll route it to the right GSD command.
Wait for response before continuing.
**Check if project exists.**INIT=$(gsd-sdk query state.load 2>/dev/null)
Track whether .planning/ exists — some routes require it, others don't.
Evaluate $ARGUMENTS against these routing rules. Apply the first matching rule:
| If the text describes... | Route to | Why |
|---|---|---|
| Starting a new project, "set up", "initialize" | /gsd:new-project |
Needs full project initialization |
| Mapping or analyzing an existing codebase | /gsd:map-codebase |
Codebase discovery |
| A bug, error, crash, failure, or something broken | /gsd:debug |
Needs systematic investigation |
| Spiking, "test if", "will this work", "experiment", "prove this out", validate feasibility | /gsd:spike |
Throwaway experiment to validate feasibility |
| Sketching, "mockup", "what would this look like", "prototype the UI", "design this", explore visual direction | /gsd:sketch |
Throwaway HTML mockups to explore design |
| Wrapping up spikes, "package the spikes", "consolidate spike findings" | /gsd:spike-wrap-up |
Package spike findings into reusable skill |
| Wrapping up sketches, "package the designs", "consolidate sketch findings" | /gsd:sketch-wrap-up |
Package sketch findings into reusable skill |
| Exploring, researching, comparing, or "how does X work" | /gsd:research-phase |
Domain research before planning |
| Discussing vision, "how should X look", brainstorming | /gsd:discuss-phase |
Needs context gathering |
| A complex task: refactoring, migration, multi-file architecture, system redesign | /gsd:add-phase |
Needs a full phase with plan/build cycle |
| Planning a specific phase or "plan phase N" | /gsd:plan-phase |
Direct planning request |
| Executing a phase or "build phase N", "run phase N" | /gsd:execute-phase |
Direct execution request |
| Running all remaining phases automatically | /gsd:autonomous |
Full autonomous execution |
| A review or quality concern about existing work | /gsd:verify-work |
Needs verification |
| Checking progress, status, "where am I" | /gsd:progress |
Status check |
| Resuming work, "pick up where I left off" | /gsd:resume-work |
Session restoration |
| A note, idea, or "remember to..." | /gsd:add-todo |
Capture for later |
| Adding tests, "write tests", "test coverage" | /gsd:add-tests |
Test generation |
| Completing a milestone, shipping, releasing | /gsd:complete-milestone |
Milestone lifecycle |
| A specific, actionable, small task (add feature, fix typo, update config) | /gsd:quick |
Self-contained, single executor |
Requires .planning/ directory: All routes except /gsd:new-project, /gsd:map-codebase, /gsd:spike, /gsd:sketch, /gsd:help, and /gsd:join-discord. If the project doesn't exist and the route requires it, suggest /gsd:new-project first.
Ambiguity handling: If the text could reasonably match multiple routes, ask the user via AskUserQuestion with the top 2-3 options. For example:
"Refactor the authentication system" could be:
1. /gsd:add-phase — Full planning cycle (recommended for multi-file refactors)
2. /gsd:quick — Quick execution (if scope is small and clear)
Which approach fits better?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GSD ► ROUTING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
**Input:** {first 80 chars of $ARGUMENTS}
**Routing to:** {chosen command}
**Reason:** {one-line explanation}
Run the selected /gsd-* command, passing $ARGUMENTS as args.
If the chosen command expects a phase number and one wasn't provided in the text, extract it from context or ask via AskUserQuestion.
After invoking the command, stop. The dispatched command handles everything from here.
<success_criteria>
- Input validated (not empty)
- Intent matched to exactly one GSD command
- Ambiguity resolved via user question (if needed)
- Project existence checked for routes that require it
- Routing decision displayed before dispatch
- Command invoked with appropriate arguments
- No work done directly — dispatcher only </success_criteria>