菜单
GSD tutorial, command reference, and workflow explainer. Explains what a GSD workflow command does before you run it. Activates when user is new to GSD, asks about commands, wants to understand workflows, or mentions preview.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Tibsfox/gsd-skill-creator --skill gsd-guide命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use the moment a request is underspecified and you are about to act on an ASSUMED goal. Enumerate the candidate goals the request could mean, project the action or artifact each one implies, and check whether they diverge: if two or more plausible goals lead to materially different actions or artifacts, ask exactly ONE targeted clarifying question; otherwise proceed on the most-likely goal and state the assumption in one line. Clarification is an evidence-producing action, not a delay — but one question, never an interrogation. Distinct from gsd-spec-phase (GSD-phase-bound, emits a heavy SPEC.md) and intent-router (fetch strategy, not goal disambiguation). Backed by agent goal-state inference (arxiv 2606.16813v1). Triggers on acting under an assumed goal when the request admits more than one materially different reading.
Use at write time to vector/embedding memory — Grove content-addressed insertion, chroma/pgvector upserts, memory-consolidation promoting session traces to MEMORY.md, or embedding externally-ingested content. Scores each candidate record against a fixed panel of sentinel queries and quarantines any record that would become the nearest neighbor of too many unrelated queries — a hub — whether from adversarial poisoning or accidental over-generality. This is the memory-record-side sibling of skill-injection-guardian (file-side) and the write-side complement of memory-use-warrant (read-side). Quarantine, never silently drop; a human reviews. Backed by the admission-time hubness gate (arxiv 2606.19692v1). Triggers on inserting into vector memory, consolidating memory, and embedding stranger content.
Run this appropriateness check the moment you are about to integrate a retrieved long-term memory — a Grove content-addressed hit, a chroma/pgvector neighbour, a memory-consolidation digest, or a MEMORY.md line — into a response, especially anything touching private origins, Fox Companies IP, credentials, or Center Camp / consent-governed content. It answers a question intent-router never asks: not WHAT to fetch or HOW, but WHETHER a correctly-retrieved item should reach output. Relevance is not appropriateness — a perfect similarity match can still be a boundary violation. Default is FAIL-CLOSED: if in-context authorization is uncertain, the memory may inform behaviour but must not be surfaced. Backed by RBI-Eval (arxiv 2606.06055v1). Triggers on surfacing recalled sensitive memory into a response.
正在显示 SKILL.md
基于 SOC 职业分类
| name | gsd-guide |
| description | GSD tutorial, command reference, and workflow explainer. Explains what a GSD workflow command does before you run it. Activates when user is new to GSD, asks about commands, wants to understand workflows, or mentions preview. |
| format | "2025-10-02T00:00:00.000Z" |
| version | 1.0.0 |
| status | ACTIVE |
| updated | "2026-04-15T00:00:00.000Z" |
| triggers | ["user is new to GSD, asks about commands, wants to understand workflows, or mentions preview"] |
Combines the GSD tutorial/command reference (formerly gsd-onboard) with the per-command workflow explainer (formerly gsd-explain). Section 1 is the compact reference; Section 2 is the detailed "what will this do before I run it" explainer.
GSD = question → research → plan → execute → verify.
.planning/
├── PROJECT.md # Vision, decisions
├── REQUIREMENTS.md # REQ-IDs
├── ROADMAP.md # Phases
├── STATE.md # Current position
├── config.json # Settings
├── phases/NN-name/ # Plans + summaries
└── milestones/ # Archives
| Command | Purpose |
|---|---|
| /gsd:new-project | Init project |
| /gsd:new-milestone | New version |
| /gsd:progress | State + next action |
| /gsd:discuss-phase N | Gather context |
| /gsd:plan-phase N | Create plans |
| /gsd:execute-phase N | Build plans |
| /gsd:quick | Small tasks |
| /gsd:verify-work N | Test deliverables |
| /gsd:audit-milestone | Completion check |
| /gsd:complete-milestone | Archive |
| /gsd:debug | Debug with state |
| /gsd:pause-work | Checkpoint |
| /gsd:resume-work | Restore |
plan-phase N → /clear → execute-phase N → verify-work N
/clear + STATE.mdHelps users understand what a GSD command will do before they run it, reducing hesitation and preventing incorrect usage.
Activate when the user:
.claude/get-shit-done/workflows/When explaining a GSD workflow, use this structure:
## /gsd:command-name - [Purpose]
**What it does:**
[2-3 sentence overview]
**Process:**
1. [First step - what happens]
2. [Second step - what happens]
3. [Third step - what happens]
**Files created/modified:**
- `.planning/path/to/file.md` - [purpose]
- `.planning/other/file.json` - [purpose]
**Agents spawned:**
- `agent-name` (model) - [what it does]
**User interaction:**
- [Number] prompts expected
- [Type of input needed]
**Estimated:**
- Time: [duration estimate]
- Context: [percentage of window]
**After completion:**
- [What state the project will be in]
- [Next recommended command]
/gsd:new-project
/gsd:new-milestone
/gsd:discuss-phase N
.planning/phases/NN-name/NN-CONTEXT.md/gsd:plan-phase N
gsd-phase-researcher (if enabled)gsd-planner to create PLAN.md filesgsd-plan-checker to verify plansNN-01-PLAN.md, NN-02-PLAN.md, …)/gsd:research-phase N
gsd-phase-researcher standaloneNN-RESEARCH.md with findings/gsd:execute-phase N
gsd-executor agents (1 per wave)NN-NN-SUMMARY.md for each plan/gsd:quick
gsd-executor agent/gsd:verify-work N
gsd-verifier agent/gsd:audit-milestone
gsd-verifier and gsd-integration-checkerHelp users visualize what files GSD creates:
.planning/
├── PROJECT.md # Vision, requirements, decisions
├── REQUIREMENTS.md # What we're building (REQ-IDs)
├── ROADMAP.md # Phase structure and status
├── STATE.md # Session memory, current position
├── config.json # Workflow preferences
│
├── phases/
│ ├── 01-foundation/
│ │ ├── 01-CONTEXT.md # User vision for phase
│ │ ├── 01-RESEARCH.md # Optional research findings
│ │ ├── 01-01-PLAN.md # Executable plan
│ │ └── 01-01-SUMMARY.md # What was built
│ │
│ └── 02-features/
│ └── [same structure]
│
└── milestones/
└── v1.0-ROADMAP.md # Archived completed milestones
| Agent Type | Purpose | Spawned By |
|---|---|---|
gsd-project-researcher | Research domain before roadmap | /gsd:new-project |
gsd-research-synthesizer | Synthesize parallel research | /gsd:new-project |
gsd-roadmapper | Create project roadmap | /gsd:new-project |
gsd-phase-researcher | Research implementation approach | /gsd:plan-phase, /gsd:research-phase |
gsd-planner | Create executable plans | /gsd:plan-phase |
gsd-plan-checker | Verify plans match goals | /gsd:plan-phase |
gsd-executor | Execute plans with atomic commits | /gsd:execute-phase, /gsd:quick |
gsd-verifier | Test phase deliverables | /gsd:verify-work |
gsd-debugger | Systematic debugging | /gsd:debug |
gsd-integration-checker | Cross-phase integration tests | /gsd:audit-milestone |
"How long will this take?" — Initialization: 15-30 minutes. Planning a phase: 3-8 minutes. Executing a phase: 5-40 minutes depending on complexity. Verification: 3-7 minutes.
"Will this modify my code?" — Planning workflows only create .planning/ files. Execution workflows modify code with atomic commits. Verification workflows are read-only.
"Can I undo this?" — All GSD commits are atomic (one per plan). Use git revert <commit> to undo specific plans. STATE.md tracks what was done.
"What happens if I /clear mid-workflow?" — GSD writes .continue-here.md files at checkpoints. /gsd:resume-work or /gsd:progress restores context. STATE.md maintains session continuity.
User asks: "What does /gsd:plan-phase 3 do?"
## /gsd:plan-phase 3 - Create Executable Plans for Phase 3
**What it does:**
Reads Phase 3 from your ROADMAP.md and creates detailed, executable
PLAN.md files that break the phase goal into atomic tasks with
verification criteria.
**Process:**
1. Reads Phase 3 details from .planning/ROADMAP.md
2. Checks for .planning/phases/03-name/03-CONTEXT.md (optional)
3. Spawns gsd-phase-researcher if research enabled in config
4. Spawns gsd-planner to create PLAN.md files
5. Spawns gsd-plan-checker to verify plans achieve phase goal
6. Commits plans to git
**Files created:**
- `.planning/phases/03-name/03-RESEARCH.md` (if research enabled)
- `.planning/phases/03-name/03-01-PLAN.md` (first plan)
- `.planning/phases/03-name/03-02-PLAN.md` (additional plans)
**Agents spawned:**
- gsd-phase-researcher (Opus) - Optional, researches implementation
- gsd-planner (Opus/Sonnet) - Creates executable plans
- gsd-plan-checker (Opus) - Verifies plans match phase goals
**User interaction:**
- 0-2 prompts (only if plan checker finds issues)
**Estimated:**
- Time: 3-8 minutes (longer if research enabled)
- Context: ~30-40% of window
**After completion:**
- Phase 3 plans ready in .planning/phases/03-name/
- Ready to run /gsd:execute-phase 3
This skill complements GSD by reducing onboarding friction, providing "what if" previews before running commands, explaining GSD's internal agent orchestration, and helping users choose the right workflow. It does not replace GSD — users still run the actual commands, no workflow logic is duplicated, and this is purely educational.