Claude Code를 위한 GSD: 워크플로 시스템에 대한 심층 분석

Anatomy of a Claude Code Workflow: How Slash Commands become an AI Development System The tooling surrounding AI-driven development workflows for Claude Code is currently evolving at breathtaking speed. To understand how such a tool works under the hood, I took a closer look at GSD (Get Shit Done). In this post, using GSD as an example, I will briefly explain how Spec-Driven Development workflows function and which Claude Code tools are utilized in the process. The goal is to understand fundamental patterns in order to apply them to your own workflows. The Idea of Spec-Driven Development In short: the idea is to define detailed requirements and the expected behavior of software before implementation. This specification then serves as a guide for development and a basis for testing to ensure the code meets the requirements. The objective is to create better context for implementation by an LLM. Tools like GSD use sophisticated question-and-answer workflows to help clearly define requirements. Additionally, they solve a core problem of agentic coding—Context Rot: the gradual loss of quality as limited token context windows fill up during long coding sessions. What is "Get-Shit-Done"? With 23k stars on GitHub (as of March 2026), GSD is currently among the most well-known Spec-Driven Development tools. Its complexity is manageable compared to other tools like BMAD or Speckit. The system relies entirely on native Claude Code features. No proprietary runtime. No framework. Just ~50 Markdown files, a Node.js CLI helper, and a few hooks—orchestrating a complete software development cycle from idea to delivered code. The GSD workflow is divided into a chain of slash commands. Each command handles a phase—and ideally, each phase runs in a fresh context window. | Command | Purpose | |---|---| /gsd:new-project | Capture idea, research domain, define requirements & roadmap | /gsd:discuss-phase N | Clarify implementation details for phase N | /gsd:plan-phase N | Create task breakdown for phase N | /gsd:execute-phase N | Execute plans in parallel, one commit per task | /gsd:verify-work N | Validate that phase goals have been achieved | /gsd:complete-milestone | Archive, tag release, initialize next cycle | Behind these commands are exclusively standard Claude Code features: - 29 Skills — the slash commands called by the user. - 12 Custom Agents — specialized sub-agents for research, planning, execution, and verification. - 2 Hooks — a status bar and an update checker running in the background. During installation, the corresponding files are written to the .claude/ directory structure, making them available in every Claude session, even independent of GSD commands. Since my focus is on the tools behind the commands, I refer anyone wanting to understand GSD better to the official documentation. From the commands described above, I have selected /gsd:new-project to break down step-by-step. This command sits at the start of the workflow and initiates a guided process that asks questions, gathers information, starts research agents, defines trackable requirements, and generates a roadmap for further execution. Slash Commands and Skills Every GSD command executable in Claude is defined in a Markdown file within claude/commands/gsd/ (hence the /gsd prefix). The file for /gsd:new-project looks like this: 1--- 2name: gsd:new-project 3description: Initialize a new project with deep context gathering and PROJECT.md 4argument-hint: "[--auto]" 5allowed-tools: [Read, Bash, Write, Task, AskUserQuestion] 6--- At the top is the frontmatter, containing metadata for the command: - argument-hint signals an optional --auto flag (in GSD, this flag skips some user prompts). - allowed-tools sets explicit privileges for tool execution (all internal tools). - description appears in the command palette. Below the frontmatter follows the actual prompt, structured by XML tags (abbreviated here): 1 2Initialize a new project through unified flow: questioning → research 3(optional) → requirements → roadmap. 4 5**Creates:** 6- `.planning/PROJECT.md` — project context 7- `.planning/config.json` — workflow preferences 8- `.planning/research/` — domain research (optional) 9- `.planning/REQUIREMENTS.md` — scoped requirements 10- `.planning/ROADMAP.md` — phase structure 11- `.planning/STATE.md` — project memory 12 13**After this command:** Run `/gsd:plan-phase 1` to start execution. 14 15 16 17@./.claude/get-shit-done/workflows/new-project.md 18@./.claude/get-shit-done/references/questioning.md 19@./.claude/get-shit-done/references/ui-brand.md 20@./.claude/get-shit-done/templates/project.md 21@./.claude/get-shit-done/templates/requirements.md 22 23 24 25Execute the new-project workflow from @./.claude/get-shit-done/workflows/new-project.md end-to-end. 26Preserve all workflow gates (validation, approvals, commits, routing). 27 Claude models were trained to recognize XML tags as structural boundaries, as it is not always clear where a section ends with Markdow