d3a79917fa
* feat: Phase 2 caller migration — gsd-sdk query in workflows (#2122) Cherry-picked orchestration rewrites from feat/sdk-foundation (#2008, 4018fee) onto current main, resolving conflicts to keep upstream worktree guards and post-merge test gate. SDK stub registry omitted (out of Phase 2 scope per #2122). Refs: #2122 #2008 Made-with: Cursor * docs: add gsd-sdk query migration blurb Made-with: Cursor * docs(workflows): extend Phase 2 gsd-sdk query caller migration - Swap node gsd-tools.cjs for gsd-sdk query in review, plan-phase, execute-plan, ship, extract_learnings, ai-integration-phase, eval-review, next, thread - Document graphify CJS-only in gsd-planner; dual-path in CLI-TOOLS and ARCHITECTURE - Update tests: workstreams gsd-sdk path, thread frontmatter.get, workspace init.*, CRLF-safe autonomous frontmatter parse - CHANGELOG: Phase 2 caller migration scope Made-with: Cursor * docs(phase2): USER-GUIDE + remaining gsd-sdk query call sites - USER-GUIDE: dual-path CLI section; state validate/sync use full CJS path - Commands: debug (config-get+tdd), quick (security note), intel Task prompt - Agent: gsd-debug-session-manager resolve-model via jq - Workflows: milestone-summary, forensics, next, complete-milestone/verify-work (audit-open CJS notes), discuss-phase, progress, verify-phase, add/insert/remove phase, transition, manager, quick workflow; remove-phase commit without --files - Test: quick-session-management accepts frontmatter.get - CHANGELOG: Phase 2 follow-up bullet Made-with: Cursor * docs(phase2): align gsd-sdk query examples in commands and agents - init.* query names; frontmatter.get uses positional field name - state.* handlers use positional args; commit uses positional paths - CJS-only notes for from-gsd2 and graphify; learnings.query wording - CHANGELOG: Phase 2 orchestration doc pass Made-with: Cursor * docs(phase2): normalize gsd-sdk query commit to positional file paths - Strip --files from commit examples in workflows, references, commands - Keep commit-to-subrepo ... --files (separate handler) - git-planning-commit.md: document positional args - Tests: new-project commit line, state.record-session, gates CRLF, roadmap.analyze - CHANGELOG [Unreleased] Made-with: Cursor * feat(sdk): gsd-sdk query parity with gsd-tools and PR 2179 registry fixes - Route query via longest-prefix match and dotted single-token expansion; fall back to runGsdToolsQuery (same argv as node gsd-tools.cjs) for full CLI coverage. - Parse gsd-sdk query permissively so gsd-tools flags (--json, --verify, etc.) are not rejected by strict parseArgs. - resolveGsdToolsPath: honor GSD_TOOLS_PATH; prefer bundled get-shit-done copy over project .claude installs; export runGsdToolsQuery from the SDK. - Fix gsd-tools audit-open (core.output; pass object for --json JSON). - Register summary-extract as alias of summary.extract; fix audit-fix workflow to call audit-uat instead of invalid init.audit-uat (PR review). Updates QUERY-HANDLERS.md and CHANGELOG [Unreleased]. Made-with: Cursor * fix(sdk): Phase 2 scope — Trek-e review (#2179, #2122) - Remove gsd-sdk query passthrough to gsd-tools.cjs; drop GSD_TOOLS_PATH - Consolidate argv routing in resolveQueryArgv(); update USAGE and QUERY-HANDLERS - Surface @file: read failures in GSDTools.parseOutput - execute-plan: defer Task Commit Protocol to gsd-executor - stale-colon-refs: skip .planning/ and root CLAUDE.md (gitignored overlays) - CHANGELOG [Unreleased]: maintainer review and routing notes Made-with: Cursor
107 lines
4.9 KiB
Markdown
107 lines
4.9 KiB
Markdown
<purpose>
|
|
Analyze freeform text from the user and route to the most appropriate GSD command. This is a dispatcher — it never does the work itself. Match user intent to the best command, confirm the routing, and hand off.
|
|
</purpose>
|
|
|
|
<required_reading>
|
|
Read all files referenced by the invoking prompt's execution_context before starting.
|
|
</required_reading>
|
|
|
|
<process>
|
|
|
|
<step name="validate">
|
|
**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.
|
|
</step>
|
|
|
|
<step name="check_project">
|
|
**Check if project exists.**
|
|
|
|
```bash
|
|
INIT=$(gsd-sdk query state.load 2>/dev/null)
|
|
```
|
|
|
|
Track whether `.planning/` exists — some routes require it, others don't.
|
|
</step>
|
|
|
|
<step name="route">
|
|
**Match intent to command.**
|
|
|
|
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 |
|
|
| 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-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?
|
|
```
|
|
</step>
|
|
|
|
<step name="display">
|
|
**Show the routing decision.**
|
|
|
|
```
|
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
GSD ► ROUTING
|
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
|
|
**Input:** {first 80 chars of $ARGUMENTS}
|
|
**Routing to:** {chosen command}
|
|
**Reason:** {one-line explanation}
|
|
```
|
|
</step>
|
|
|
|
<step name="dispatch">
|
|
**Invoke the chosen command.**
|
|
|
|
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.
|
|
</step>
|
|
|
|
</process>
|
|
|
|
<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>
|