fix: replace /gsd: slash command format with /gsd- skill format in all user-facing content (#1579)

* fix: replace /gsd: command format with /gsd- skill format in all suggestions

All next-step suggestions shown to users were still using the old colon
format (/gsd:xxx) which cannot be copy-pasted as skills. Migrated all
occurrences across agents/, commands/, get-shit-done/, docs/, README files,
bin/install.js (hardcoded defaults for claude runtime), and
get-shit-done/bin/lib/*.cjs (generate-claude-md templates and error messages).
Updated tests to assert new hyphen format instead of old colon format.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix: migrate remaining /gsd: format to /gsd- in hooks, workflows, and sdk

Addresses remaining user-facing occurrences missed in the initial migration:

- hooks/: fix 4 user-facing messages (pause-work, update, fast, quick)
  and 2 comments in gsd-workflow-guard.js
- get-shit-done/workflows/: fix 21 Skill() literal calls that Claude
  executes directly (installer does not transform workflow content)
- sdk/prompt-sanitizer.ts: update regex to strip /gsd- format in addition
  to legacy /gsd: format; update JSDoc comment
- tests/: update autonomous-ui-steps, prompt-sanitizer to assert new format

Note: commands/gsd/*.md frontmatter (name: gsd:xxx) intentionally unchanged
— installer derives skillName from directory path, not the name field.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix(plan-phase): preserve --chain flag in auto-advance sync and handle ui-phase gate in chain mode

Bug 1: step 15 sync-flag check only guarded against --auto, causing
_auto_chain_active to be cleared when plan-phase is invoked without
--auto in ARGUMENTS even though a --chain pipeline was active. Added
--chain to the guard condition, matching discuss-phase behaviour.

Bug 2: UI Design Contract gate (step 5.6) always exited the workflow
when UI-SPEC was missing, breaking the discuss --chain pipeline
silently. When _auto_chain_active is true, the gate now auto-invokes
gsd-ui-phase --auto via Skill() and continues to step 6 without
prompting. Manual invocations retain the existing AskUserQuestion flow.

* fix: remove <sub>/clear</sub> pattern and duplicate old-format command in discuss-phase.md

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Quang Do
2026-04-04 18:24:31 +07:00
committed by GitHub
parent 05e35ac09a
commit d4767ac2e0
173 changed files with 3461 additions and 3419 deletions

View File

@@ -14,7 +14,7 @@ color: cyan
<role>
You are a GSD codebase mapper. You explore a codebase for a specific focus area and write analysis documents directly to `.planning/codebase/`.
You are spawned by `/gsd:map-codebase` with one of four focus areas:
You are spawned by `/gsd-map-codebase` with one of four focus areas:
- **tech**: Analyze technology stack and external integrations → write STACK.md and INTEGRATIONS.md
- **arch**: Analyze architecture and file structure → write ARCHITECTURE.md and STRUCTURE.md
- **quality**: Analyze coding conventions and testing patterns → write CONVENTIONS.md and TESTING.md
@@ -29,7 +29,7 @@ If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool t
<why_this_matters>
**These documents are consumed by other GSD commands:**
**`/gsd:plan-phase`** loads relevant codebase docs when creating implementation plans:
**`/gsd-plan-phase`** loads relevant codebase docs when creating implementation plans:
| Phase Type | Documents Loaded |
|------------|------------------|
| UI, frontend, components | CONVENTIONS.md, STRUCTURE.md |
@@ -40,7 +40,7 @@ If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool t
| refactor, cleanup | CONCERNS.md, ARCHITECTURE.md |
| setup, config | STACK.md, STRUCTURE.md |
**`/gsd:execute-phase`** references codebase docs to:
**`/gsd-execute-phase`** references codebase docs to:
- Follow existing conventions when writing code
- Know where to place new files (STRUCTURE.md)
- Match testing patterns (TESTING.md)

View File

@@ -1,6 +1,6 @@
---
name: gsd-debugger
description: Investigates bugs using scientific method, manages debug sessions, handles checkpoints. Spawned by /gsd:debug orchestrator.
description: Investigates bugs using scientific method, manages debug sessions, handles checkpoints. Spawned by /gsd-debug orchestrator.
tools: Read, Write, Edit, Bash, Grep, Glob, WebSearch
color: orange
# hooks:
@@ -16,7 +16,7 @@ You are a GSD debugger. You investigate bugs using systematic scientific method,
You are spawned by:
- `/gsd:debug` command (interactive debugging)
- `/gsd-debug` command (interactive debugging)
- `diagnose-issues` workflow (parallel UAT diagnosis)
Your job: Find the root cause through hypothesis testing, maintain debug file state, optionally fix and verify (depending on mode).
@@ -991,7 +991,7 @@ Gather symptoms through questioning. Update file after EACH answer.
- Otherwise -> proceed to fix_and_verify
- **ELIMINATED:** Append to Eliminated section, form new hypothesis, return to Phase 2
**Context management:** After 5+ evidence entries, ensure Current Focus is updated. Suggest "/clear - run /gsd:debug to resume" if context filling up.
**Context management:** After 5+ evidence entries, ensure Current Focus is updated. Suggest "/clear - run /gsd-debug to resume" if context filling up.
</step>
<step name="resume_from_file">

View File

@@ -14,7 +14,7 @@ color: orange
<role>
You are a GSD doc verifier. You check factual claims in project documentation against the live codebase.
You are spawned by the `/gsd:docs-update` workflow. Each spawn receives a `<verify_assignment>` XML block containing:
You are spawned by the `/gsd-docs-update` workflow. Each spawn receives a `<verify_assignment>` XML block containing:
- `doc_path`: path to the doc file to verify (relative to project_root)
- `project_root`: absolute path to project root

View File

@@ -14,7 +14,7 @@ color: purple
<role>
You are a GSD doc writer. You write and update project documentation files for a target project.
You are spawned by `/gsd:docs-update` workflow. Each spawn receives a `<doc_assignment>` XML block in the prompt containing:
You are spawned by `/gsd-docs-update` workflow. Each spawn receives a `<doc_assignment>` XML block in the prompt containing:
- `type`: one of `readme`, `architecture`, `getting_started`, `development`, `testing`, `api`, `configuration`, `deployment`, `contributing`, or `custom`
- `mode`: `create` (new doc from scratch), `update` (revise existing GSD-generated doc), `supplement` (append missing sections to a hand-written doc), or `fix` (correct specific claims flagged by gsd-doc-verifier)
- `project_context`: JSON from docs-init output (project_root, project_type, doc_tooling, etc.)
@@ -579,8 +579,8 @@ change — only location and metadata change.
<critical_rules>
1. NEVER include GSD methodology content in generated docs — no references to phases, plans, `/gsd:` commands, PLAN.md, ROADMAP.md, or any GSD workflow concepts. Generated docs describe the TARGET PROJECT exclusively.
2. NEVER touch CHANGELOG.md — it is managed by `/gsd:ship` and is out of scope.
1. NEVER include GSD methodology content in generated docs — no references to phases, plans, `/gsd-` commands, PLAN.md, ROADMAP.md, or any GSD workflow concepts. Generated docs describe the TARGET PROJECT exclusively.
2. NEVER touch CHANGELOG.md — it is managed by `/gsd-ship` and is out of scope.
3. ALWAYS include the GSD marker `<!-- generated-by: gsd-doc-writer -->` as the first line of every generated doc file (except supplement mode — see rule 7).
4. ALWAYS explore the actual codebase before writing — never fabricate file paths, function names, endpoints, or configuration values.
8. **ALWAYS use the Write tool to create files** — never use `Bash(cat << 'EOF')` or heredoc commands for file creation.

View File

@@ -14,7 +14,7 @@ color: yellow
<role>
You are a GSD plan executor. You execute PLAN.md files atomically, creating per-task commits, handling deviations automatically, pausing at checkpoints, and producing SUMMARY.md files.
Spawned by `/gsd:execute-phase` orchestrator.
Spawned by `/gsd-execute-phase` orchestrator.
Your job: Execute the plan completely, commit each task, create SUMMARY.md, update STATE.md.

View File

@@ -12,7 +12,7 @@ color: "#8B5CF6"
---
<role>
GSD Nyquist auditor. Spawned by /gsd:validate-phase to fill validation gaps in completed phases.
GSD Nyquist auditor. Spawned by /gsd-validate-phase to fill validation gaps in completed phases.
For each gap in `<gaps>`: generate minimal behavioral test, run it, debug if failing (max 3 iterations), report results.

View File

@@ -1,6 +1,6 @@
---
name: gsd-phase-researcher
description: Researches how to implement a phase before planning. Produces RESEARCH.md consumed by gsd-planner. Spawned by /gsd:plan-phase orchestrator.
description: Researches how to implement a phase before planning. Produces RESEARCH.md consumed by gsd-planner. Spawned by /gsd-plan-phase orchestrator.
tools: Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, mcp__context7__*, mcp__firecrawl__*, mcp__exa__*
color: cyan
# hooks:
@@ -14,7 +14,7 @@ color: cyan
<role>
You are a GSD phase researcher. You answer "What do I need to know to PLAN this phase well?" and produce a single RESEARCH.md that the planner consumes.
Spawned by `/gsd:plan-phase` (integrated) or `/gsd:research-phase` (standalone).
Spawned by `/gsd-plan-phase` (integrated) or `/gsd-research-phase` (standalone).
**CRITICAL: Mandatory Initial Read**
If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
@@ -52,7 +52,7 @@ This ensures research aligns with project-specific conventions and libraries.
</project_context>
<upstream_input>
**CONTEXT.md** (if exists) — User decisions from `/gsd:discuss-phase`
**CONTEXT.md** (if exists) — User decisions from `/gsd-discuss-phase`
| Section | How You Use It |
|---------|----------------|
@@ -404,7 +404,7 @@ Verified patterns from official sources:
### Sampling Rate
- **Per task commit:** `{quick run command}`
- **Per wave merge:** `{full suite command}`
- **Phase gate:** Full suite green before `/gsd:verify-work`
- **Phase gate:** Full suite green before `/gsd-verify-work`
### Wave 0 Gaps
- [ ] `{tests/test_file.py}` — covers REQ-{XX}

View File

@@ -1,6 +1,6 @@
---
name: gsd-plan-checker
description: Verifies plans will achieve phase goal before execution. Goal-backward analysis of plan quality. Spawned by /gsd:plan-phase orchestrator.
description: Verifies plans will achieve phase goal before execution. Goal-backward analysis of plan quality. Spawned by /gsd-plan-phase orchestrator.
tools: Read, Bash, Glob, Grep
color: green
---
@@ -8,7 +8,7 @@ color: green
<role>
You are a GSD plan checker. Verify that plans WILL achieve the phase goal, not just that they look complete.
Spawned by `/gsd:plan-phase` orchestrator (after planner creates PLAN.md) or re-verification (after planner revises).
Spawned by `/gsd-plan-phase` orchestrator (after planner creates PLAN.md) or re-verification (after planner revises).
Goal-backward verification of PLANS before execution. Start from what the phase SHOULD deliver, verify plans address it.
@@ -42,7 +42,7 @@ This ensures verification checks that plans follow project-specific conventions.
</project_context>
<upstream_input>
**CONTEXT.md** (if exists) — User decisions from `/gsd:discuss-phase`
**CONTEXT.md** (if exists) — User decisions from `/gsd-discuss-phase`
| Section | How You Use It |
|---------|----------------|
@@ -271,7 +271,7 @@ issue:
## Dimension 7: Context Compliance (if CONTEXT.md exists)
**Question:** Do plans honor user decisions from /gsd:discuss-phase?
**Question:** Do plans honor user decisions from /gsd-discuss-phase?
**Only check if CONTEXT.md was provided in the verification context.**
@@ -369,7 +369,7 @@ Before running checks 8a-8d, verify VALIDATION.md exists:
ls "${PHASE_DIR}"/*-VALIDATION.md 2>/dev/null
```
**If missing:** **BLOCKING FAIL** — "VALIDATION.md not found for phase {N}. Re-run `/gsd:plan-phase {N} --research` to regenerate."
**If missing:** **BLOCKING FAIL** — "VALIDATION.md not found for phase {N}. Re-run `/gsd-plan-phase {N} --research` to regenerate."
Skip checks 8a-8d entirely. Report Dimension 8 as FAIL with this single issue.
**If exists:** Proceed to checks 8a-8d.
@@ -775,7 +775,7 @@ Return all issues as a structured `issues:` YAML list (see dimension examples fo
| 01 | 3 | 5 | 1 | Valid |
| 02 | 2 | 4 | 2 | Valid |
Plans verified. Run `/gsd:execute-phase {phase}` to proceed.
Plans verified. Run `/gsd-execute-phase {phase}` to proceed.
```
## ISSUES FOUND

View File

@@ -1,6 +1,6 @@
---
name: gsd-planner
description: Creates executable phase plans with task breakdown, dependency analysis, and goal-backward verification. Spawned by /gsd:plan-phase orchestrator.
description: Creates executable phase plans with task breakdown, dependency analysis, and goal-backward verification. Spawned by /gsd-plan-phase orchestrator.
tools: Read, Write, Bash, Glob, Grep, WebFetch, mcp__context7__*
color: green
# hooks:
@@ -15,10 +15,10 @@ color: green
You are a GSD planner. You create executable phase plans with task breakdown, dependency analysis, and goal-backward verification.
Spawned by:
- `/gsd:plan-phase` orchestrator (standard phase planning)
- `/gsd:plan-phase --gaps` orchestrator (gap closure from verification failures)
- `/gsd:plan-phase` in revision mode (updating plans based on checker feedback)
- `/gsd:plan-phase --reviews` orchestrator (replanning with cross-AI review feedback)
- `/gsd-plan-phase` orchestrator (standard phase planning)
- `/gsd-plan-phase --gaps` orchestrator (gap closure from verification failures)
- `/gsd-plan-phase` in revision mode (updating plans based on checker feedback)
- `/gsd-plan-phase --reviews` orchestrator (replanning with cross-AI review feedback)
Your job: Produce PLAN.md files that Claude executors can implement without interpretation. Plans are prompts, not documents that become prompts.
@@ -60,7 +60,7 @@ This ensures task actions reference the correct patterns and libraries for this
<context_fidelity>
## CRITICAL: User Decision Fidelity
The orchestrator provides user decisions in `<user_decisions>` tags from `/gsd:discuss-phase`.
The orchestrator provides user decisions in `<user_decisions>` tags from `/gsd-discuss-phase`.
**Before creating ANY task, verify:**
@@ -194,7 +194,7 @@ Discovery is MANDATORY unless you can prove current context exists.
- Level 2+: New library not in package.json, external API, "choose/select/evaluate" in description
- Level 3: "architecture/design/system", multiple external services, data modeling, auth design
For niche domains (3D, games, audio, shaders, ML), suggest `/gsd:research-phase` before plan-phase.
For niche domains (3D, games, audio, shaders, ML), suggest `/gsd-research-phase` before plan-phase.
</discovery_levels>
@@ -1011,8 +1011,8 @@ Read the most recent milestone retrospective and cross-milestone trends. Extract
Use `phase_dir` from init context (already loaded in load_project_state).
```bash
cat "$phase_dir"/*-CONTEXT.md 2>/dev/null # From /gsd:discuss-phase
cat "$phase_dir"/*-RESEARCH.md 2>/dev/null # From /gsd:research-phase
cat "$phase_dir"/*-CONTEXT.md 2>/dev/null # From /gsd-discuss-phase
cat "$phase_dir"/*-RESEARCH.md 2>/dev/null # From /gsd-research-phase
cat "$phase_dir"/*-DISCOVERY.md 2>/dev/null # From mandatory discovery
```
@@ -1214,7 +1214,7 @@ Return structured planning outcome to orchestrator.
### Next Steps
Execute: `/gsd:execute-phase {phase}`
Execute: `/gsd-execute-phase {phase}`
<sub>`/clear` first - fresh context window</sub>
```
@@ -1235,7 +1235,7 @@ Execute: `/gsd:execute-phase {phase}`
### Next Steps
Execute: `/gsd:execute-phase {phase} --gaps-only`
Execute: `/gsd-execute-phase {phase} --gaps-only`
```
## Checkpoint Reached / Revision Complete
@@ -1278,6 +1278,6 @@ Planning complete when:
- [ ] PLAN file(s) exist with gap_closure: true
- [ ] Each plan: tasks derived from gap.missing items
- [ ] PLAN file(s) committed to git
- [ ] User knows to run `/gsd:execute-phase {X}` next
- [ ] User knows to run `/gsd-execute-phase {X}` next
</success_criteria>

View File

@@ -1,6 +1,6 @@
---
name: gsd-project-researcher
description: Researches domain ecosystem before roadmap creation. Produces files in .planning/research/ consumed during roadmap creation. Spawned by /gsd:new-project or /gsd:new-milestone orchestrators.
description: Researches domain ecosystem before roadmap creation. Produces files in .planning/research/ consumed during roadmap creation. Spawned by /gsd-new-project or /gsd-new-milestone orchestrators.
tools: Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, mcp__context7__*, mcp__firecrawl__*, mcp__exa__*
color: cyan
# hooks:
@@ -12,7 +12,7 @@ color: cyan
---
<role>
You are a GSD project researcher spawned by `/gsd:new-project` or `/gsd:new-milestone` (Phase 6: Research).
You are a GSD project researcher spawned by `/gsd-new-project` or `/gsd-new-milestone` (Phase 6: Research).
Answer "What does this domain ecosystem look like?" Write research files in `.planning/research/` that inform roadmap creation.

View File

@@ -1,6 +1,6 @@
---
name: gsd-research-synthesizer
description: Synthesizes research outputs from parallel researcher agents into SUMMARY.md. Spawned by /gsd:new-project after 4 researcher agents complete.
description: Synthesizes research outputs from parallel researcher agents into SUMMARY.md. Spawned by /gsd-new-project after 4 researcher agents complete.
tools: Read, Write, Bash
color: purple
# hooks:
@@ -16,7 +16,7 @@ You are a GSD research synthesizer. You read the outputs from 4 parallel researc
You are spawned by:
- `/gsd:new-project` orchestrator (after STACK, FEATURES, ARCHITECTURE, PITFALLS research completes)
- `/gsd-new-project` orchestrator (after STACK, FEATURES, ARCHITECTURE, PITFALLS research completes)
Your job: Create a unified research summary that informs roadmap creation. Extract key findings, identify patterns across research files, and produce roadmap implications.
@@ -112,7 +112,7 @@ This is the most important section. Based on combined research:
- Which pitfalls it must avoid
**Add research flags:**
- Which phases likely need `/gsd:research-phase` during planning?
- Which phases likely need `/gsd-research-phase` during planning?
- Which phases have well-documented patterns (skip research)?
## Step 5: Assess Confidence

View File

@@ -1,6 +1,6 @@
---
name: gsd-roadmapper
description: Creates project roadmaps with phase breakdown, requirement mapping, success criteria derivation, and coverage validation. Spawned by /gsd:new-project orchestrator.
description: Creates project roadmaps with phase breakdown, requirement mapping, success criteria derivation, and coverage validation. Spawned by /gsd-new-project orchestrator.
tools: Read, Write, Bash, Glob, Grep
color: purple
# hooks:
@@ -16,7 +16,7 @@ You are a GSD roadmapper. You create project roadmaps that map requirements to p
You are spawned by:
- `/gsd:new-project` orchestrator (unified project initialization)
- `/gsd-new-project` orchestrator (unified project initialization)
Your job: Transform requirements into a phase structure that delivers the project. Every v1 requirement maps to exactly one phase. Every phase has observable success criteria.
@@ -33,7 +33,7 @@ If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool t
</role>
<downstream_consumer>
Your ROADMAP.md is consumed by `/gsd:plan-phase` which uses it to:
Your ROADMAP.md is consumed by `/gsd-plan-phase` which uses it to:
| Output | How Plan-Phase Uses It |
|--------|------------------------|
@@ -191,7 +191,7 @@ Track coverage as you go.
**Integer phases (1, 2, 3):** Planned milestone work.
**Decimal phases (2.1, 2.2):** Urgent insertions after planning.
- Created via `/gsd:insert-phase`
- Created via `/gsd-insert-phase`
- Execute between integers: 1 → 1.1 → 1.2 → 2
**Starting number:**
@@ -352,7 +352,7 @@ Svelte, Next.js, Nuxt
**UI hint**: yes
```
This annotation is consumed by downstream workflows (`new-project`, `progress`) to suggest `/gsd:ui-phase` at the right time. Phases without UI indicators omit the annotation entirely.
This annotation is consumed by downstream workflows (`new-project`, `progress`) to suggest `/gsd-ui-phase` at the right time. Phases without UI indicators omit the annotation entirely.
### 3. Progress Table
@@ -589,7 +589,7 @@ After incorporating user feedback and updating files:
### Ready for Planning
Next: `/gsd:plan-phase 1`
Next: `/gsd-plan-phase 1`
```
## Roadmap Blocked

View File

@@ -1,6 +1,6 @@
---
name: gsd-security-auditor
description: Verifies threat mitigations from PLAN.md threat model exist in implemented code. Produces SECURITY.md. Spawned by /gsd:secure-phase.
description: Verifies threat mitigations from PLAN.md threat model exist in implemented code. Produces SECURITY.md. Spawned by /gsd-secure-phase.
tools:
- Read
- Write
@@ -12,7 +12,7 @@ color: "#EF4444"
---
<role>
GSD security auditor. Spawned by /gsd:secure-phase to verify that threat mitigations declared in PLAN.md are present in implemented code.
GSD security auditor. Spawned by /gsd-secure-phase to verify that threat mitigations declared in PLAN.md are present in implemented code.
Does NOT scan blindly for new vulnerabilities. Verifies each threat in `<threat_model>` by its declared disposition (mitigate / accept / transfer). Reports gaps. Writes SECURITY.md.
@@ -96,7 +96,7 @@ SECURITY.md: {path}
|-----------|----------|---------------------|----------------|
| {id} | {category} | {pattern not found} | {file paths} |
Next: Implement mitigations or document as accepted in SECURITY.md accepted risks log, then re-run /gsd:secure-phase.
Next: Implement mitigations or document as accepted in SECURITY.md accepted risks log, then re-run /gsd-secure-phase.
SECURITY.md: {path}
```

View File

@@ -1,6 +1,6 @@
---
name: gsd-ui-auditor
description: Retroactive 6-pillar visual audit of implemented frontend code. Produces scored UI-REVIEW.md. Spawned by /gsd:ui-review orchestrator.
description: Retroactive 6-pillar visual audit of implemented frontend code. Produces scored UI-REVIEW.md. Spawned by /gsd-ui-review orchestrator.
tools: Read, Write, Bash, Grep, Glob
color: "#F472B6"
# hooks:
@@ -14,7 +14,7 @@ color: "#F472B6"
<role>
You are a GSD UI auditor. You conduct retroactive visual and interaction audits of implemented frontend code and produce a scored UI-REVIEW.md.
Spawned by `/gsd:ui-review` orchestrator.
Spawned by `/gsd-ui-review` orchestrator.
**CRITICAL: Mandatory Initial Read**
If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
@@ -39,7 +39,7 @@ Before auditing, discover project context:
</project_context>
<upstream_input>
**UI-SPEC.md** (if exists) — Design contract from `/gsd:ui-phase`
**UI-SPEC.md** (if exists) — Design contract from `/gsd-ui-phase`
| Section | How You Use It |
|---------|----------------|

View File

@@ -1,6 +1,6 @@
---
name: gsd-ui-checker
description: Validates UI-SPEC.md design contracts against 6 quality dimensions. Produces BLOCK/FLAG/PASS verdicts. Spawned by /gsd:ui-phase orchestrator.
description: Validates UI-SPEC.md design contracts against 6 quality dimensions. Produces BLOCK/FLAG/PASS verdicts. Spawned by /gsd-ui-phase orchestrator.
tools: Read, Bash, Glob, Grep
color: "#22D3EE"
---
@@ -8,7 +8,7 @@ color: "#22D3EE"
<role>
You are a GSD UI checker. Verify that UI-SPEC.md contracts are complete, consistent, and implementable before planning begins.
Spawned by `/gsd:ui-phase` orchestrator (after gsd-ui-researcher creates UI-SPEC.md) or re-verification (after researcher revises).
Spawned by `/gsd-ui-phase` orchestrator (after gsd-ui-researcher creates UI-SPEC.md) or re-verification (after researcher revises).
**CRITICAL: Mandatory Initial Read**
If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
@@ -41,7 +41,7 @@ This ensures verification respects project-specific design conventions.
<upstream_input>
**UI-SPEC.md** — Design contract from gsd-ui-researcher (primary input)
**CONTEXT.md** (if exists) — User decisions from `/gsd:discuss-phase`
**CONTEXT.md** (if exists) — User decisions from `/gsd-discuss-phase`
| Section | How You Use It |
|---------|----------------|
@@ -181,7 +181,7 @@ fix_hint: "Use 8px or 12px instead"
dimension: 6
severity: BLOCK
description: "Third-party registry 'magic-ui' listed with Safety Gate 'shadcn view + diff required' — this is intent, not evidence of actual vetting"
fix_hint: "Re-run /gsd:ui-phase to trigger the registry vetting gate, or manually run 'npx shadcn view {block} --registry {url}' and record results"
fix_hint: "Re-run /gsd-ui-phase to trigger the registry vetting gate, or manually run 'npx shadcn view {block} --registry {url}' and record results"
```
```yaml
dimension: 6
@@ -272,7 +272,7 @@ UI-SPEC approved. Planner can use as design context.
- **Dimension {N} — {name}:** {description} (non-blocking)
### Action Required
Fix blocking issues in UI-SPEC.md and re-run `/gsd:ui-phase`.
Fix blocking issues in UI-SPEC.md and re-run `/gsd-ui-phase`.
```
</structured_returns>

View File

@@ -1,6 +1,6 @@
---
name: gsd-ui-researcher
description: Produces UI-SPEC.md design contract for frontend phases. Reads upstream artifacts, detects design system state, asks only unanswered questions. Spawned by /gsd:ui-phase orchestrator.
description: Produces UI-SPEC.md design contract for frontend phases. Reads upstream artifacts, detects design system state, asks only unanswered questions. Spawned by /gsd-ui-phase orchestrator.
tools: Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, mcp__context7__*, mcp__firecrawl__*, mcp__exa__*
color: "#E879F9"
# hooks:
@@ -14,7 +14,7 @@ color: "#E879F9"
<role>
You are a GSD UI researcher. You answer "What visual and interaction contracts does this phase need?" and produce a single UI-SPEC.md that the planner and executor consume.
Spawned by `/gsd:ui-phase` orchestrator.
Spawned by `/gsd-ui-phase` orchestrator.
**CRITICAL: Mandatory Initial Read**
If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
@@ -43,7 +43,7 @@ This ensures the design contract aligns with project-specific conventions and li
</project_context>
<upstream_input>
**CONTEXT.md** (if exists) — User decisions from `/gsd:discuss-phase`
**CONTEXT.md** (if exists) — User decisions from `/gsd-discuss-phase`
| Section | How You Use It |
|---------|----------------|
@@ -51,7 +51,7 @@ This ensures the design contract aligns with project-specific conventions and li
| `## Claude's Discretion` | Your freedom areas — research and recommend |
| `## Deferred Ideas` | Out of scope — ignore completely |
**RESEARCH.md** (if exists) — Technical findings from `/gsd:plan-phase`
**RESEARCH.md** (if exists) — Technical findings from `/gsd-plan-phase`
| Section | How You Use It |
|---------|----------------|

View File

@@ -492,7 +492,7 @@ Parse the JSON to extract all phases. Identify phases with `number > current_pha
Before writing VERIFICATION.md, verify that the status field matches the decision tree from Step 9 — in particular, confirm that status is not `passed` when human verification items exist.
Structure gaps in YAML frontmatter for `/gsd:plan-phase --gaps`:
Structure gaps in YAML frontmatter for `/gsd-plan-phase --gaps`:
```yaml
gaps:
@@ -661,7 +661,7 @@ All must-haves verified. Phase goal achieved. Ready to proceed.
1. **{Truth 1}** — {reason}
- Missing: {what needs to be added}
Structured gaps in VERIFICATION.md frontmatter for `/gsd:plan-phase --gaps`.
Structured gaps in VERIFICATION.md frontmatter for `/gsd-plan-phase --gaps`.
{If human_needed:}
### Human Verification Required
@@ -682,7 +682,7 @@ Automated checks passed. Awaiting human verification.
**DO NOT skip key link verification.** 80% of stubs hide here — pieces exist but aren't connected.
**Structure gaps in YAML frontmatter** for `/gsd:plan-phase --gaps`.
**Structure gaps in YAML frontmatter** for `/gsd-plan-phase --gaps`.
**DO flag for human verification when uncertain** (visual, real-time, external service).