Get Shit Done (GSD): как организовать работу ИИ-агента

## The short answer

Get Shit Done (GSD) is a set of commands and files for working with an AI agent. He is. Helps to turn the idea into a coherent plan, save the project decisions and Check the results in stages. It is not a stand-alone model or a replacement. Man: The agent can still make a mistake, and the requirements and checks are necessary control.

GSD is useful when the project has already gone beyond one small task. lose context. For a single edit in a single file, it is likely to unnecessary.

We're going to go through the installation, the basic commands and the boundaries of the tool without any promises. It will automatically make the project reliable.

## Why did you create GSD

The author is a solo developer who uses AI for coding. Other tools like SpecKit or BMAD add extra complexity: sprints, story points, retrospectives, Jira. That's for 50-man teams. GSD simplifies: hides complexity (context engineering, XML prompts, subagent orchestration, state management) behind simple commands that just work.

For whom: For those who describe an idea and want to get the right code without simulating corporate processes. Ideal for creative people who build cool things.

## How to get started

Launch:

npx get-shit-done-cc@latest

Installer will ask:

• Runtime: Claude Code, OpenCode, Gemini or all.
• Location: Global (for all projects) or local (only current).

Check with /gsd:help in your environment.

Update regularly as GSD is evolving rapidly:

npx get-shit-done-cc@latest

For scripts, Docker or CI (no questions asked):

npx get-shit-done-cc --claude --global # In ~/.claude/
npx get-shit-done-cc --claude --local # In./.claude/

Or for all environments:

npx get-shit-done-cc --all --global

Cloning the repository and running:

git clone https://github.com/gsd-build/get-shit-done.git
cd get-shit-done
node bin/install.js --claude --local

Don't turn on the mode that disables permission checks, just for the sake of speed. It is safer to leave confirmations on or allow only specific ones. The teams that the project really needs. Before launching, check which ones The agent can change the files and actions.

## How it works

If you already have a code, run /gsd:map-codebase first. The system spawns parallel agents to analyze stack, architecture, conventions, and issues. Then /gsd:new-project will take into account the existing code.

### 1. Project initialization

/gsd:new-project

One team, one stream:

• He asks questions until he understands the whole idea: goals, limitations, technology preferences, edge cases.
• Domain: Parallel Agents (optional, but recommended).
• Extracts requirements: v1, v2, out of scope.
• Creates a roadmap with phases tied to requirements.

You approve the road map and you're ready to build.

Creates files: PROJECT.md (project vision), REQUIREMENTS.md (requirements), ROADMAP.md (roadmap), STATE.md (solutions, blockers, status), .planning/research/ (research).

### 2. Talk phase

/gsd:discuss-phase 1

Here's the implementation. The roadmap has a couple of sentences per phase - that's not enough for your vision. The system analyzes the phase and identifies gray areas:

• For visual features: layout, density, interaction, empty states.
• For API/CLI: response format, flags, error handling, verbosity.
• For content systems: structure, tone, depth, flow.

For each zone, ask until satisfied. The output is CONTEXT.md, which goes into research and planning. The deeper you get, the closer you get to your vision. Skip - get reasonable defaults.

### 3. Plan the phase

/gsd:plan-phase 1

System:

• Explores how to implement, based on CONTEXT.md (e.g. looking for libraries for card layout).
• Creates 2-3 atomic task plans in an XML structure.
• Checks: the plans meet the requirements, hits before passing.

Each plan is small to fit in a fresh context without degradation.

Creates: {phase}-RESEARCH.md (research), {phase}-{N}-PLAN.md (plans).

### 4. Perform phase

/gsd:execute-phase 1

System:

• Launches plans in waves: parallel independent, consistently dependent.
• Fresh context on the plan: 200k tokens purely for implementation.
• Commit to the task: atomic, with a pure history.
• Checks: the code delivers what the phase promised.

Waves are important: independent plans in one wave are parallel, dependent plans in the next. It is better to parallel “vertical slices” (end-to-end feature) than “horizontal layers” (all models, then all APIs).

Creates: {phase}-{N}-SUMMARY.md (what happened), {phase}-VERIFICATION.md (check).

### 5. Check the work

/gsd:verify-work 1

Automatic check is OK, but here you confirm manually:

• Retrieves test results: what should work.
• Walkthrough: "Can you log in by email?" Yes/no, describe the problem.
• Diagnoses failures: spawns debug agents for root cause.
• Creates fix plans: ready to restart.

If you're okay, you move on. If not, restart /gsd:execute-phase with fixes.

Creates: {phase}-UAT.md (user testing), fix plans if problems.

### 6. Repeat, end and next stage

Repeat the cycle: discuss → plan → execute → verify for each phase.

Finished the milestone? /gsd:complete-milestone - archives, tags release.

Then /gsd:new-milestone: as new-project, but for existing code. Describe what's next, the system explores, scopes requirements, creates a fresh roadmap.

Quick mode for small things:

/gsd:quick
"Add the dark mode switch to the settings"

Same agents, but no research, plan checks, verification. For bugfixes, small features, configs.

## Why does it work

• Context Engineering: AI is powerful if given context. GSD gives: PROJECT.md (vision), research (ecosystem, stack, pitfalls), REQUIREMENTS.md (requirements with traceability), ROADMAP.md (progress), STATE.md (session memory), PLAN.md (XML structure), SUMMARY.md (changes), todos/ (ideas).
• XML Prompts: Accurate, with action, verify, done. No guess.
• Multi-agents: The orchestrator spawns specialists (researchers, planners, executors, verifiers). Working in fresh contexts, the session remains responsive.
• Atomic Commites: Each task is its commit, traceable, revertable. Pure git story.
• Modularity: add phases, insert urgent work, adjust without restructuring.

## Teams

** Main workflow:**

• /gsd:new-project [--auto]: initialization.
• /gsd:discuss-phase [N] [--auto]: refinements.
• /gsd:plan-phase [N] [--auto]: planning.
• /gsd:execute-phase : execution.
• /gsd:verify-work [N]: check.
• /gsd:audit-milestone: check the milestone.
• /gsd:complete-milestone: completion.
• /gsd:new-milestone [name]: next.

** Navigation:**

• /gsd:progress: status.
• /gsd:help: all teams.
• /gsd:update: update.

** Existing code:**

• /gsd:map-codebase: analysis.

Phase control:

• /gsd:add-phase: add.
• /gsd:insert-phase [N]: insert.
• /gsd:remove-phase [N]: delete.

** Session:**

• /gsd:pause-work: pause.
• /gsd:resume-work: resume.

Utilities:

• /gsd:quick [--full]: fast.
• /gsd:debug [desc]: debugging.
• /gsd:health [-repair]: integrity check.
• /gsd:add-todo [desc]: add a task.
• /gsd:check-todos: list.

Link to GitHub: get-shit-done

### What to read next

• n8n для автоматизации: что это, как работает и с чего начатьXX
• OpenCode Desktop App: что это, как начать и где он полезенXX
• Codex Cloud vs Cline vs Cursor: сравнение для вайбкодинга в 2026XX

## Частые вопросы

Что такое Get Shit Done? Это набор команд и файлов для работы с ИИ-агентом. Он помогает разложить проект на этапы и не терять принятые решения.

Когда GSD действительно нужен? Когда проект состоит из нескольких связанных задач и контекста уже не хватает одной переписки. Для маленькой правки он может оказаться лишним.

GSD сам сделает проект надёжным? Нет. Он организует работу, но требования, разрешения, тесты и проверка результата остаются ответственностью человека.

### Что читать дальше

• n8n для автоматизации: что это, как работает и с чего начать
• OpenCode Desktop App: что это, как начать и где он полезен
• Codex Cloud vs Cline vs Cursor: сравнение инструментов