メニュー
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コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？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.