@tekyzinc/gsd-t 3.12.10 → 3.12.13

package/commands/gsd-t-execute.md

@@ -66,7 +66,7 @@ This calls `getSessionStatus()` (v2.0.0) which reads `.gsd-t/.context-meter-stat
 
 Use the returned `threshold` as the gate signal for the rest of this run. The gate logic is in Step 3.5; do NOT skip it. If the Context Meter hook isn't installed (`.gsd-t/.context-meter-state.json` missing and doctor reports it), run `gsd-t doctor` to diagnose — the gate still works via the heuristic fallback but real-time readings give much better guardrails.
 
-Why: every `/user:gsd-t-execute` invocation is a fresh orchestrator session and needs a current reading of context utilization before spawning any subagents. The authoritative source is the Context Meter state file; the fallback keeps the gate functional on projects that haven't installed the hook yet.
+Why: every `/gsd-t-execute` invocation is a fresh orchestrator session and needs a current reading of context utilization before spawning any subagents. The authoritative source is the Context Meter state file; the fallback keeps the gate functional on projects that haven't installed the hook yet.
 
 ## Step 1: Load State
 

package/commands/gsd-t-feature.md

@@ -1,6 +1,6 @@
 # GSD-T: Feature — Add a Major Feature to an Existing Project
 
-You are the lead agent planning a significant new feature for an existing codebase. Unlike `/user:gsd-t-project` (greenfield), this command respects and builds on what already exists — existing patterns, schema, auth, conventions, and contracts.
+You are the lead agent planning a significant new feature for an existing codebase. Unlike `/gsd-t-project` (greenfield), this command respects and builds on what already exists — existing patterns, schema, auth, conventions, and contracts.
 
 ## Step 0.5: Scan Freshness Auto-Refresh
 
@@ -154,7 +154,7 @@ The feature may be a single milestone or multiple, depending on scope:
 ### Single Milestone (if feature is focused):
 - 2-4 domains, < 15 tasks total
 - Minimal impact on existing contracts
-- Skip roadmap, go straight to: "Run `/user:gsd-t-partition` to begin"
+- Skip roadmap, go straight to: "Run `/gsd-t-partition` to begin"
 
 ### Multiple Milestones (if feature is complex):
 Apply these sequencing rules:
@@ -267,7 +267,7 @@ Present:
 4. Any conflicts with existing work
 5. Recommended starting point
 
-Ask: "Ready to start? Run `/user:gsd-t-partition` for Milestone {N}."
+Ask: "Ready to start? Run `/gsd-t-partition` for Milestone {N}."
 
 $ARGUMENTS
 

package/commands/gsd-t-gap-analysis.md

@@ -224,13 +224,13 @@ Show the recommended groupings and offer promotion paths:
 ## Recommended Next Steps
 
 1. {Milestone name} — {N} gaps ({critical} critical, {high} high)
-   → /user:gsd-t-milestone "{name}"
+   → /gsd-t-milestone "{name}"
 
 2. {Feature name} — {N} gaps
-   → /user:gsd-t-feature "{name}"
+   → /gsd-t-feature "{name}"
 
 3. Quick fixes — {N} items
-   → /user:gsd-t-quick "{description}"
+   → /gsd-t-quick "{description}"
 
 Promote any of these now, or review the gap analysis first?
 ```

package/commands/gsd-t-health.md

@@ -131,9 +131,9 @@ After repair, re-run the checks and report the final state.
 ## Step 6: Next Steps
 
 If HEALTHY → "✅ GSD-T structure is healthy — all required files present."
-If DEGRADED with --repair done → "✅ Repaired {N} missing files. Run /user:gsd-t-health again to confirm."
-If DEGRADED without --repair → "⚠ Run /user:gsd-t-health --repair to create {N} missing files."
-If BROKEN → "🔴 Project structure is broken. Run /user:gsd-t-health --repair or /user:gsd-t-init to rebuild."
+If DEGRADED with --repair done → "✅ Repaired {N} missing files. Run /gsd-t-health again to confirm."
+If DEGRADED without --repair → "⚠ Run /gsd-t-health --repair to create {N} missing files."
+If BROKEN → "🔴 Project structure is broken. Run /gsd-t-health --repair or /gsd-t-init to rebuild."
 
 $ARGUMENTS
 

package/commands/gsd-t-help.md

@@ -84,8 +84,8 @@ BACKLOG                                                                Manual
   backlog-settings    Manage types, apps, categories, and defaults
 
 ───────────────────────────────────────────────────────────────────────────────
-Type /user:gsd-t-help {command} for detailed help on any command.
-Example: /user:gsd-t-help impact
+Type /gsd-t-help {command} for detailed help on any command.
+Example: /gsd-t-help impact
 ╚══════════════════════════════════════════════════════════════════════════════╝
 ```
 
@@ -94,7 +94,7 @@ Example: /user:gsd-t-help impact
 When user provides a command name, show detailed help:
 
 ```
-/user:gsd-t-help {command}
+/gsd-t-help {command}
 ```
 
 ### Command Details Format:
@@ -108,7 +108,7 @@ SUMMARY
   {One-line description}
 
 USAGE
-  /user:gsd-t-{command} [arguments]
+  /gsd-t-{command} [arguments]
 
 WHEN TO USE
   • {Use case 1}
@@ -131,8 +131,8 @@ FILES CREATED/UPDATED
   • {file 2}
 
 EXAMPLES
-  /user:gsd-t-{command}
-  /user:gsd-t-{command} "with argument"
+  /gsd-t-{command}
+  /gsd-t-{command} "with argument"
 
 RELATED COMMANDS
   • {related 1} — {why related}
@@ -149,10 +149,10 @@ Use these when user asks for help on a specific command:
 - **Summary**: Describe what you need in plain language — auto-routes to the right GSD-T command using semantic evaluation
 - **Auto-invoked**: Yes — via UserPromptSubmit hook when prompt does not start with `/`
 - **Files**: Reads `CLAUDE.md`, `.gsd-t/progress.md`, command summaries from `gsd-t-help`
-- **How it works**: First checks if this is a continuation of an ongoing command (mid-task follow-up, status report, or acknowledgment) — if so, outputs `→ /gsd ──▶ continue /user:gsd-t-{last-command}` and resumes. For new requests, evaluates against every command's purpose and "Use when" criteria. Commands that match get shortlisted, best fit is selected. Shows runner-up when close.
+- **How it works**: First checks if this is a continuation of an ongoing command (mid-task follow-up, status report, or acknowledgment) — if so, outputs `→ /gsd ──▶ continue /gsd-t-{last-command}` and resumes. For new requests, evaluates against every command's purpose and "Use when" criteria. Commands that match get shortlisted, best fit is selected. Shows runner-up when close.
 - **Auto-route**: After `gsd-t install`, any plain text message (no leading `/`) is automatically routed through `/gsd`. Slash commands pass through unchanged. Binary detection — no heuristics.
 - **Use when**: You don't want to remember which command to use — just describe what you want
-- **Examples**: `/user:gsd Fix the login bug`, `/user:gsd Add dark mode`, `/user:gsd Scan for tech debt`
+- **Examples**: `/gsd Fix the login bug`, `/gsd Add dark mode`, `/gsd Scan for tech debt`
 - **Auto-route examples**: `Fix the login bug` (no slash needed), `Add dark mode`, `Scan for tech debt`
 
 ### prd
@@ -228,7 +228,7 @@ Use these when user asks for help on a specific command:
 - **Use when**: Ready to define specific implementation tasks
 - **Note (M22)**: Tasks auto-split if estimated scope exceeds 70% context window — guarantees fresh dispatch works
 - **Note (M26)**: Pre-mortem step now also reads rules.jsonl for historical failure patterns via getPreMortemRules
-- **Note (M38)**: Conversational use cases (formerly `/user:gsd-t-prompt`, `/user:gsd-t-brainstorm`, `/user:gsd-t-discuss`) are now handled by the Smart Router's conversational mode — just describe what you want via `/user:gsd` or plain text.
+- **Note (M38)**: Conversational use cases (formerly `/gsd-t-prompt`, `/gsd-t-brainstorm`, `/gsd-t-discuss`) are now handled by the Smart Router's conversational mode — just describe what you want via `/gsd` or plain text.
 
 ### impact
 - **Summary**: Analyze downstream effects of planned changes
@@ -433,7 +433,7 @@ Did you mean one of these?
   • {closest match 1}
   • {closest match 2}
 
-Run /user:gsd-t-help for full command list.
+Run /gsd-t-help for full command list.
 ```
 
 $ARGUMENTS

package/commands/gsd-t-impact.md

@@ -3,7 +3,7 @@
 You are analyzing the downstream effects of planned changes before execution. Your job is to identify what might break, what needs updating, and what risks exist.
 
 This command is:
-- **Auto-invoked** between plan and execute phases in `/user:gsd-t-wave`
+- **Auto-invoked** between plan and execute phases in `/gsd-t-wave`
 - **Standalone** when user wants to evaluate potential changes
 
 ## Step 1: Load Context
@@ -273,7 +273,7 @@ Validate the test landscape before recommending proceed/block:
 - List the red items
 - Generate remediation tasks
 - Add tasks to current domain's task list
-- "Run `/user:gsd-t-execute` to address these first, then re-run impact analysis."
+- "Run `/gsd-t-execute` to address these first, then re-run impact analysis."
 - Do NOT proceed to execute phase
 
 ## Standalone Mode
@@ -281,7 +281,7 @@ Validate the test landscape before recommending proceed/block:
 When run independently (not as part of wave):
 
 ```
-/user:gsd-t-impact "considering adding user roles to the auth system"
+/gsd-t-impact "considering adding user roles to the auth system"
 ```
 
 1. Ask clarifying questions about the change

package/commands/gsd-t-init-scan-setup.md

@@ -64,7 +64,7 @@ All subsequent steps run from inside the project directory.
 
 ## Step 3: Initialize Project (gsd-t-init)
 
-Execute the full init workflow (same as `/user:gsd-t-init`):
+Execute the full init workflow (same as `/gsd-t-init`):
 
 1. Create `.gsd-t/` directory structure (contracts/, domains/, progress.md, backlog.md, backlog-settings.md, token-log.md, qa-issues.md)
 2. Ensure `CLAUDE.md` exists (create starter if missing, append GSD-T section if present without it)
@@ -101,7 +101,7 @@ If the project has source code, graph indexing (`.gsd-t/graph/`) will run as par
 
 ## Step 4: Deep Codebase Scan (gsd-t-scan)
 
-Execute the full scan workflow (same as `/user:gsd-t-scan`):
+Execute the full scan workflow (same as `/gsd-t-scan`):
 
 1. Scan across all dimensions: architecture, business rules, security, quality, contracts
 2. Build `.gsd-t/techdebt.md` register
@@ -114,7 +114,7 @@ Always use team mode for the scan unless the codebase is trivially small (< 5 fi
 
 ## Step 5: Generate Project CLAUDE.md (gsd-t-setup)
 
-Execute the full setup workflow (same as `/user:gsd-t-setup`):
+Execute the full setup workflow (same as `/gsd-t-setup`):
 
 1. Read global `~/.claude/CLAUDE.md` to understand what's already covered
 2. Use scan findings + auto-detection to populate project-specific sections
@@ -139,8 +139,8 @@ Project Onboarded: {project name}
 
 Next steps:
   → Review .gsd-t/techdebt.md for critical items
-  → /user:gsd-t-milestone to define your first milestone
-  → /user:gsd-t-wave to run a full development cycle
+  → /gsd-t-milestone to define your first milestone
+  → /gsd-t-wave to run a full development cycle
 ```
 
 ### Autonomy Behavior

package/commands/gsd-t-init.md

@@ -154,7 +154,7 @@ Read the project's `CLAUDE.md` (if it exists) to auto-populate backlog settings:
 1. **Apps**: Scan for app names, service names, or product names (look for headings, "Tech Stack" sections, or named components). Populate the `## Apps` section in `backlog-settings.md` with discovered names (lowercase).
 2. **Categories**: Scan for domain concepts, module names, and technical areas (e.g., "authentication", "payments", "api", "database"). Populate the `## Categories` section.
 3. **Default App**: Set `**Default App:**` to the most prominent app found (the one mentioned most, or the first one). If only one app is found, use it.
-4. **If nothing found**: Leave the placeholder values from the template — the user can configure later via `/user:gsd-t-backlog-settings`.
+4. **If nothing found**: Leave the placeholder values from the template — the user can configure later via `/gsd-t-backlog-settings`.
 
 ## Step 5: Initialize Progress File
 
@@ -366,10 +366,10 @@ After initialization:
 Tell the user:
 1. What was created (including backlog files: `.gsd-t/backlog.md` and `.gsd-t/backlog-settings.md`)
 2. What they should fill in (CLAUDE.md details, requirements)
-3. Backlog settings status: whether apps/categories were auto-derived from CLAUDE.md or need manual configuration via `/user:gsd-t-backlog-settings`
+3. Backlog settings status: whether apps/categories were auto-derived from CLAUDE.md or need manual configuration via `/gsd-t-backlog-settings`
 4. Recommended next step:
-   - New project: "Define your milestone, then run /user:gsd-t-partition"
-   - Existing code: "I've mapped the codebase. Ready for /user:gsd-t-partition {milestone}"
+   - New project: "Define your milestone, then run /gsd-t-partition"
+   - Existing code: "I've mapped the codebase. Ready for /gsd-t-partition {milestone}"
 
 $ARGUMENTS
 

package/commands/gsd-t-log.md

@@ -8,7 +8,7 @@ Read:
 1. `.gsd-t/progress.md` — current Decision Log entries
 2. Note the **last entry's timestamp** — this is the cutoff; only commits after this time need processing
 
-If `.gsd-t/progress.md` doesn't exist, inform user: "No GSD-T state found. Run `/user:gsd-t-init` first."
+If `.gsd-t/progress.md` doesn't exist, inform user: "No GSD-T state found. Run `/gsd-t-init` first."
 
 ## Step 2: Get Recent Commits
 

package/commands/gsd-t-milestone.md

@@ -44,7 +44,7 @@ Before formal partitioning, do a quick assessment:
 
 - **Complexity estimate**: Simple (1-2 domains), Medium (3-4), Complex (5+)
 - **Recommended approach**:
-  - Simple: Consider using /user:gsd-t-quick for each piece
+  - Simple: Consider using /gsd-t-quick for each piece
   - Medium: Standard partition → plan → execute flow
   - Complex: Partition → discuss → plan → execute → integrate → verify
 
@@ -78,7 +78,7 @@ Before proceeding to partition:
 If the user wants to proceed immediately, execute the partition workflow (same as gsd-t-partition) for this milestone.
 
 Otherwise, set status to DEFINED and remind them:
-"Run /user:gsd-t-partition to decompose into domains, or /user:gsd-t-discuss to explore approaches first."
+"Run /gsd-t-partition to decompose into domains, or /gsd-t-discuss to explore approaches first."
 
 $ARGUMENTS
 

package/commands/gsd-t-pause.md

@@ -54,7 +54,7 @@ Create `.gsd-t/continue-here-{timestamp}.md`:
 {$ARGUMENTS if provided, otherwise: _No note provided._}
 
 ## Resume Command
-/user:gsd-t-resume
+/gsd-t-resume
 ```
 
 ## Step 4: Confirm to User
@@ -67,7 +67,7 @@ Output:
 Saved position: .gsd-t/continue-here-{timestamp}.md
 Next action:    {next action summary}
 
-To resume: /user:gsd-t-resume
+To resume: /gsd-t-resume
 ```
 
 ## Step 5: Do NOT Stop Work (unless user asked to pause all work)

package/commands/gsd-t-prd.md

@@ -291,13 +291,13 @@ Next steps:
 
 For a new project:
 ```
-/user:gsd-t-project {one-line summary}
+/gsd-t-project {one-line summary}
 ```
 Then paste the PRD when prompted. The PRD's requirements table becomes docs/requirements.md. The architecture section seeds docs/architecture.md. The milestone sequence becomes your roadmap.
 
 For a feature on an existing project:
 ```
-/user:gsd-t-feature {one-line summary}
+/gsd-t-feature {one-line summary}
 ```
 Then paste the PRD when prompted.
 

package/commands/gsd-t-project.md

@@ -200,7 +200,7 @@ Present:
 4. Any scope decisions you made and why
 5. Questions or trade-offs that need user input
 
-Ask: "Ready to start Milestone 1? Run `/user:gsd-t-partition` to decompose it into domains."
+Ask: "Ready to start Milestone 1? Run `/gsd-t-partition` to decompose it into domains."
 
 Or if the user wants to review first: "Review the roadmap in `.gsd-t/roadmap.md` and let me know if you want to adjust scope or ordering."
 

package/commands/gsd-t-resume.md

@@ -149,7 +149,7 @@ Progress:
 Next up: {specific next action}
 Blockers: {any pending items} | None
 
-Ready to continue? Or run /user:gsd-t-status for full details.
+Ready to continue? Or run /gsd-t-status for full details.
 ```
 
 ## Step 4: Continue
@@ -171,9 +171,9 @@ When the resumed work reaches a natural handoff point, do NOT print a "Next Up"
 |--------------------------|-----------------|
 | A task (mid-wave, tasks remaining) | next task in the same wave |
 | The last task of a wave (waves remaining) | next wave |
-| The last task of the last wave | `/user:gsd-t-verify` (which auto-invokes `/user:gsd-t-complete-milestone` per verify Step 8) |
-| `/user:gsd-t-verify` (VERIFIED or VERIFIED-WITH-WARNINGS) | `/user:gsd-t-complete-milestone` (verify already spawns this — do not re-invoke) |
-| `/user:gsd-t-complete-milestone` | honor any outstanding multi-step user directive (see below) |
+| The last task of the last wave | `/gsd-t-verify` (which auto-invokes `/gsd-t-complete-milestone` per verify Step 8) |
+| `/gsd-t-verify` (VERIFIED or VERIFIED-WITH-WARNINGS) | `/gsd-t-complete-milestone` (verify already spawns this — do not re-invoke) |
+| `/gsd-t-complete-milestone` | honor any outstanding multi-step user directive (see below) |
 
 **Never stop at "Wave N complete" or "Task N done" and wait.** The only stopping points are:
 1. VERIFY-FAILED (report failures)

package/commands/gsd-t-scan.md

@@ -235,7 +235,7 @@ Operations implemented independently in 2+ places — candidates for extraction
 If none found: `✅ No shared service candidates detected.`
 
 > **Note**: These candidates should seed Step 1.6 (Consumer Surface Identification) the next
-> time `/user:gsd-t-partition` is run. Copy the "Consumer Surfaces Detected" table into
+> time `/gsd-t-partition` is run. Copy the "Consumer Surfaces Detected" table into
 > partition's Step 1.6.1 to skip re-research.
 
 ## Complexity Hotspots
@@ -442,7 +442,7 @@ Can be scheduled: During next maintenance window
 Combines: all "Shared Service Candidates" from quality.md Reusability Analysis
 Estimated effort: {assessment}
 Should be prioritized: BEFORE adding new consumer surfaces to the system
-Note: Use `/user:gsd-t-partition` Step 1.6 to design the SharedCore domain
+Note: Use `/gsd-t-partition` Step 1.6 to design the SharedCore domain
 ```
 
 ## Step 5: Update Living Documents
@@ -563,7 +563,7 @@ If `.gsd-t/progress.md` exists:
 
 If `.gsd-t/roadmap.md` exists:
 - Do NOT auto-add milestones — present suggestions to user
-- User decides which to promote with `/user:gsd-t-promote-debt`
+- User decides which to promote with `/gsd-t-promote-debt`
 
 If `CLAUDE.md` exists:
 - Suggest updates for any patterns or conventions discovered during scan

package/commands/gsd-t-setup.md

@@ -192,7 +192,7 @@ Options:
   [2] web-app  — "User-facing app: accessible, performant, visually consistent. UX is the product."
   [3] cli      — "Developer CLI: fast, predictable, clear output. Error messages explain what went wrong and how to fix it."
   [4] custom   — Write your own 1–3 sentences
-  [5] skip     — No Quality North Star (can add later via /user:gsd-t-setup)
+  [5] skip     — No Quality North Star (can add later via /gsd-t-setup)
 ```
 
 If the user picks 1–3, use the corresponding preset text from the table below.
@@ -240,7 +240,7 @@ Would you like to generate a design brief at .gsd-t/contracts/design-brief.md?
 This gives subagents a consistent visual language reference (colors, typography, spacing, patterns).
 
   [1] Yes — generate now (sources: Tailwind config if exists, then project defaults)
-  [2] No — skip for now (can generate later by re-running /user:gsd-t-setup)
+  [2] No — skip for now (can generate later by re-running /gsd-t-setup)
 ```
 
 If user picks 1: generate `.gsd-t/contracts/design-brief.md` using the format defined in `.gsd-t/contracts/design-brief-contract.md` (or the standard format):

package/commands/gsd-t-test-sync.md

@@ -322,7 +322,7 @@ Full sync:
 
 ### Standalone Mode:
 ```
-/user:gsd-t-test-sync
+/gsd-t-test-sync
 ```
 1. Full analysis of entire codebase
 2. Comprehensive report

package/commands/gsd-t-unattended-watch.md

@@ -2,7 +2,7 @@
 
 **Model**: haiku (polling a state file is mechanical — no reasoning needed)
 
-You are running one tick of the unattended supervisor watch loop. This command is **stateless**: every firing re-reads `.gsd-t/.unattended/supervisor.pid` + `state.json` + `run.log` from disk and makes a fresh decision. There is no in-memory state between ticks, and a `/clear` followed by `/user:gsd-t-resume` during a live unattended run is a no-op.
+You are running one tick of the unattended supervisor watch loop. This command is **stateless**: every firing re-reads `.gsd-t/.unattended/supervisor.pid` + `state.json` + `run.log` from disk and makes a fresh decision. There is no in-memory state between ticks, and a `/clear` followed by `/gsd-t-resume` during a live unattended run is a no-op.
 
 The watch loop is the user's visibility surface into the running supervisor. It fires every 270 seconds (inside the 5-minute prompt-cache TTL) and either:
 1. Renders a compact status block + reschedules itself, OR
@@ -245,7 +245,7 @@ The supervisor process is gone but it did not remove its PID file — this is a
 
     Recovery: inspect .gsd-t/.unattended/run.log and .gsd-t/.unattended/state.json.
     Remove the stale PID file with: rm .gsd-t/.unattended/supervisor.pid
-    Then relaunch with: /user:gsd-t-unattended
+    Then relaunch with: /gsd-t-unattended
 ```
 
 **STOP** — do NOT reschedule. End the turn.
@@ -296,7 +296,7 @@ The supervisor is still alive but has transitioned to a terminal status on its l
     Total elapsed: {Hh Mm}
     Log:           {LOG_PATH}
 
-    Stop sentinel was honored between worker iterations. Relaunch with /user:gsd-t-unattended.
+    Stop sentinel was honored between worker iterations. Relaunch with /gsd-t-unattended.
 ```
 
 **STOP** — do NOT reschedule. End the turn.
@@ -321,7 +321,7 @@ Format rules:
 📋  Tasks: {TASKS_DONE}/{TASKS_TOTAL} [{progress bar}] · elapsed {Hh Mm}
 🔧  {DOMAIN_SUMMARY or "No domains yet (pre-partition)"}
 ⏱  Iter {ITER}/{MAX_ITER} · last tick {tickAge} · last exit {LAST_EXIT} ({durationSec}s)
-⏰  Next tick in 270s · Stop: /user:gsd-t-unattended-stop
+⏰  Next tick in 270s · Stop: /gsd-t-unattended-stop
 ```
 
 Progress bar rendering (8 chars wide):
@@ -392,7 +392,7 @@ After the tool call, end the turn. Do NOT output a "Next Up" hint, do NOT contin
 ## Notes
 
 - **Stateless**: every tick re-reads state from disk. No memory between firings.
-- **Terminal = STOP**: any terminal branch (3, 4, 5) ends the loop. The user relaunches via `/user:gsd-t-unattended` if needed.
+- **Terminal = STOP**: any terminal branch (3, 4, 5) ends the loop. The user relaunches via `/gsd-t-unattended` if needed.
 - **Never spawn subagents**: this is a pure polling command — no Task, no TeamCreate, no observability logging block.
 - **No branch guard, no pre-commit gate, no doc ripple**: this command does not modify any files.
 - **Stale-tick tolerance**: if `lastTick` is >540s old but PID is still alive, warn soft (`⚠️  stale`) but still reschedule — the supervisor may be mid-worker.

package/commands/gsd-t-unattended.md

@@ -16,7 +16,7 @@ Run via Bash:
 
 ```bash
 if [ ! -f ".gsd-t/progress.md" ]; then
-  echo "ERROR: .gsd-t/progress.md not found — not a GSD-T project. Run /user:gsd-t-init first."
+  echo "ERROR: .gsd-t/progress.md not found — not a GSD-T project. Run /gsd-t-init first."
   exit 1
 fi
 ```
@@ -61,10 +61,10 @@ If `PID_RUNNING=true`, **STOP** and print:
 ```
 🔴  Unattended supervisor is already running (PID {PID}).
 
-    Use /user:gsd-t-unattended-stop to request a clean halt, then wait for the
+    Use /gsd-t-unattended-stop to request a clean halt, then wait for the
     watch loop to confirm it has stopped before relaunching.
 
-    To just watch the current run: /user:gsd-t-unattended-watch
+    To just watch the current run: /gsd-t-unattended-watch
 ```
 
 Do NOT spawn a second supervisor. End the turn.
@@ -137,7 +137,7 @@ The `/gsd-t-resume` worker already knows how to chain through phases automatical
      ```
      ❌  No active milestone found and none identifiable from context.
 
-         Specify one explicitly: /user:gsd-t-unattended --milestone=M1
+         Specify one explicitly: /gsd-t-unattended --milestone=M1
      ```
    - **STOP.** Do NOT spawn.
 
@@ -230,7 +230,7 @@ If `PREFLIGHT=fail`, **STOP** and print:
       • {name}
         Install: {install}
 
-    Install the missing software and retry: /user:gsd-t-unattended
+    Install the missing software and retry: /gsd-t-unattended
 ```
 
 End the turn. Do NOT spawn.
@@ -393,7 +393,7 @@ If `LIVENESS=dead`, the supervisor crashed at startup. Print diagnostics and **S
       • Protected branch or dirty worktree rejected by safety rails
       • Permissions error on .gsd-t/.unattended/ directory
 
-    Fix the issue above and retry: /user:gsd-t-unattended
+    Fix the issue above and retry: /gsd-t-unattended
 ```
 
 End the turn without scheduling a watch tick.
@@ -415,8 +415,8 @@ Print the launch confirmation block:
     Watch:          ScheduleWakeup every 270s
 
     The supervisor is running detached — it survives /clear and terminal close.
-    Stop gracefully: /user:gsd-t-unattended-stop
-    Watch manually:  /user:gsd-t-unattended-watch
+    Stop gracefully: /gsd-t-unattended-stop
+    Watch manually:  /gsd-t-unattended-watch
 ```
 
 ## Step 5: Schedule the First Watch Tick
@@ -446,6 +446,6 @@ After the tool call, end the turn. The in-session watch loop takes over from her
 - **Platform helper**: uses `spawnSupervisor` from `bin/gsd-t-unattended-platform.cjs` — never hand-rolls `child_process.spawn` directly. This handles macOS/Linux/Windows differences.
 - **Dry-run**: `--dry-run` prints the would-be invocation without spawning. Useful for validating flags before a long overnight run.
 - **No doc ripple, no pre-commit gate**: this command spawns a background process; it does not modify any source files or contracts.
-- **watch command is stateless**: after this command returns, every `/user:gsd-t-unattended-watch` tick re-reads state from disk. There is no in-memory state to preserve.
+- **watch command is stateless**: after this command returns, every `/gsd-t-unattended-watch` tick re-reads state from disk. There is no in-memory state to preserve.
 
 $ARGUMENTS

package/commands/gsd-t-wave.md

@@ -49,7 +49,7 @@ After reading progress.md, verify it contains the required fields before proceed
 - **Domains table**: A `| Domain |` table with at least one row
 
 If ANY of these are missing or malformed, STOP and report:
-"Wave cannot proceed — progress.md is missing required fields: {list}. Run `/user:gsd-t-status` to inspect, or `/user:gsd-t-init` to repair."
+"Wave cannot proceed — progress.md is missing required fields: {list}. Run `/gsd-t-status` to inspect, or `/gsd-t-init` to repair."
 Do NOT attempt to fix progress.md yourself — that risks data loss.
 
 ## Step 2: Determine Resume Point
@@ -304,8 +304,8 @@ Summary:
 
 Next steps:
 - Push tag: git push origin milestone/{name}
-- Start next: /user:gsd-t-milestone "{next}"
-- View roadmap: /user:gsd-t-status
+- Start next: /gsd-t-milestone "{next}"
+- View roadmap: /gsd-t-status
 ═══════════════════════════════════════════════════════════════════════════════
 ```
 
@@ -313,7 +313,7 @@ Next steps:
 
 If the user interrupts or a phase agent fails:
 1. The current phase agent saves its own state to `.gsd-t/progress.md`
-2. Report: "Paused at {phase}. Run `/user:gsd-t-resume` to continue."
+2. Report: "Paused at {phase}. Run `/gsd-t-resume` to continue."
 3. Resume will pick up from the last completed phase
 
 ## Error Recovery

package/commands/gsd.md

@@ -28,7 +28,7 @@ Before semantic evaluation, determine if this is a **continuation** of an alread
 
 For non-continuation messages, decide whether the request is **conversational** (user is thinking, exploring, or articulating — no command spawn) or **workflow** (user wants work done — route to a GSD-T command via Step 2).
 
-This step replaces the retired `/user:gsd-t-prompt`, `/user:gsd-t-brainstorm`, and `/user:gsd-t-discuss` commands, whose use cases the router now handles inline.
+This step replaces the retired `/gsd-t-prompt`, `/gsd-t-brainstorm`, and `/gsd-t-discuss` commands, whose use cases the router now handles inline.
 
 ### Conversational triggers (respond inline, NO command spawn):
 
@@ -74,7 +74,7 @@ Read the **Command Summaries** section of `commands/gsd-t-help.md` (or the in-me
 - **1 match** → Route immediately
 - **2+ matches** → Pick the best fit based on scope and context. Show the runner-up:
   ```
-  → Routing to /user:gsd-t-{command}: {reason}
+  → Routing to /gsd-t-{command}: {reason}
     (also considered: gsd-t-{runner-up} — Esc to switch)
   ```
 
@@ -136,7 +136,7 @@ When cleanup is needed, do it at the start of `design-decompose` before reading
 
 ### New request (from Step 2):
 ```
-→ Routing to /user:gsd-t-{command}: {brief reason}
+→ Routing to /gsd-t-{command}: {brief reason}
 ```
 
 ### Conversational (from Step 2.5):
@@ -148,13 +148,13 @@ Follow this header with your direct in-line response — ask clarifying question
 ### Design pipeline (from design-to-code routing):
 ```
 → Design pipeline: clean → decompose → build
-  Starting: /user:gsd-t-design-decompose
+  Starting: /gsd-t-design-decompose
 ```
 Use this format when the router detects a design-to-code pipeline. Show the full pipeline with the current step highlighted. Auto-advance between steps without returning to the router.
 
 ### Continuation (from Step 2a):
 ```
-→ /gsd ──▶ continue /user:gsd-t-{last-command}
+→ /gsd ──▶ continue /gsd-t-{last-command}
 ```
 
 Where `{last-command}` is:
@@ -188,10 +188,10 @@ Valid command slugs: `quick`, `debug`, `feature`, `execute`, `milestone`, `proje
 
 **RIGHT ✅** — always use the exact command slug:
 ```
-→ Routing to /user:gsd-t-execute: implement auth feature across backend
-→ Routing to /user:gsd-t-debug: investigate login bug before fixing
-→ /gsd ──▶ continue /user:gsd-t-execute
-→ /gsd ──▶ continue /user:gsd-t-quick
+→ Routing to /gsd-t-execute: implement auth feature across backend
+→ Routing to /gsd-t-debug: investigate login bug before fixing
+→ /gsd ──▶ continue /gsd-t-execute
+→ /gsd ──▶ continue /gsd-t-quick
 ```
 
 This MUST be the very first line of your response. Then immediately execute that command's full workflow, passing `$ARGUMENTS` through.
@@ -203,16 +203,16 @@ This MUST be the very first line of your response. Then immediately execute that
 If called with no arguments, show:
 
 ```
-Usage: /user:gsd {describe what you want}
+Usage: /gsd {describe what you want}
 
 Examples:
-  /user:gsd Fix the login timeout bug
-  /user:gsd Add dark mode support
-  /user:gsd Scan the codebase for tech debt
-  /user:gsd What's the current progress?
-  /user:gsd Compare this spec against our code
-  /user:gsd Help me think through this integration before I start
-  /user:gsd I'm stuck — what are other angles?
+  /gsd Fix the login timeout bug
+  /gsd Add dark mode support
+  /gsd Scan the codebase for tech debt
+  /gsd What's the current progress?
+  /gsd Compare this spec against our code
+  /gsd Help me think through this integration before I start
+  /gsd I'm stuck — what are other angles?
 
 I'll route to the right GSD-T command — or just think out loud with you
 if you're still figuring things out (no command spawn).