메뉴
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에 표시된 보조 파일을 읽어 보세요.
SOC 직업 분류 기준
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/Tibsfox/gsd-skill-creator --skill gsd-guide명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
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.
| 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.