Урок 2.9. Get Shit Done / GSD

Зачем это нужно

Get Shit Done, или GSD, полезен как пример lightweight SDD system, который вырос из практической боли AI coding:

Чем дольше agent работает в одном context window,
тем выше риск context rot, drift и странных решений.

GSD пытается решить эту проблему через context engineering, phase loop, structured artifacts и subagent orchestration. В отличие от более "корпоративных" frameworks, GSD делает акцент на простом developer workflow: меньше ceremony, больше контроля над тем, что agent понимает, планирует, выполняет и проверяет.

Основная идея

GSD - это meta-prompting, context engineering и spec-driven development system для coding agents.

Его цель:

Дать агенту ровно тот context,
который нужен для текущей phase,
и не позволить ему терять картину проекта.

Типовая ошибка без такого слоя:

User describes large idea
-> agent starts coding
-> context fills up
-> agent forgets decisions
-> code drifts from requirements
-> user manually repairs result

GSD предлагает:

understand project
-> ask questions
-> extract requirements
-> create roadmap
-> discuss phase
-> plan phase
-> execute phase
-> verify
-> ship

Ключевые термины

Термин	Значение
Context rot	Падение качества решений агента по мере заполнения context window и накопления неактуальной информации.
Phase	Ограниченный кусок work, который можно обсудить, спланировать, выполнить и проверить.
Roadmap	Последовательность phases, привязанных к requirements.
State	Persistent project state, который помогает resume и progress tracking.
Research	Дополнительное исследование domain, architecture или stack до planning.
Execute phase	Реализация заранее согласованного phase plan.
Verify work	Проверка результата перед объявлением phase complete.
Ship	Закрытие phase или milestone через archive, PR, tag или release step.

Как это устроено

flowchart TD A[Idea or existing codebase] --> B[Map / initialize] B --> C[Questions] C --> D[Requirements] D --> E[Roadmap] E --> F[Discuss phase] F --> G[Plan phase] G --> H[Execute phase] H --> I[Verify work] I --> J[Audit milestone] J --> K[Complete milestone]

GSD работает не как один большой "build everything" prompt. Он заставляет agent проходить phase loop.

Базовые команды

Синтаксис зависит от runtime. В Claude-style environments часто встречается форма /gsd:*. В Codex или skills-based environments routing может отличаться. Поэтому команды ниже нужно читать как conceptual map.

Команда	Назначение
`/gsd:new-project`	Инициализация greenfield project: questions, research, requirements, roadmap.
`/gsd:map-codebase`	Анализ существующего codebase перед planning.
`/gsd:discuss-phase N`	Обсуждение implementation decisions для phase.
`/gsd:plan-phase N`	Research, decomposition и phase plan.
`/gsd:execute-phase N`	Выполнение phase plan.
`/gsd:verify-work N`	Проверка результата перед completion.
`/gsd:audit-milestone`	Проверка, что milestone достиг definition of done.
`/gsd:complete-milestone`	Архивация milestone, release/tag workflow.
`/gsd:progress`	Понять, где находится workflow.
`/gsd:quick`	Выполнить малую задачу с GSD guarantees без полного overhead.

Какие artifacts появляются

GSD создает и поддерживает project artifacts, например:

PROJECT.md
REQUIREMENTS.md
ROADMAP.md
STATE.md
.planning/
  research/

Идея этих файлов:

PROJECT.md описывает текущую картину проекта;
REQUIREMENTS.md фиксирует capability contract и out of scope;
ROADMAP.md разбивает работу на phases;
STATE.md помогает понимать progress и resume;
.planning/research/ хранит results of investigation.

Эти artifacts важны для course discipline: agent не должен хранить весь plan только в chat history.

Как пользоваться

Greenfield

/gsd:new-project

Agent должен:

Задать вопросы о цели.
Уточнить constraints and edge cases.
Провести optional research.
Сформировать requirements.
Создать roadmap.
Дождаться approval.

Затем:

/gsd:discuss-phase 1
/gsd:plan-phase 1
/gsd:execute-phase 1
/gsd:verify-work 1

Brownfield

Для existing codebase сначала:

/gsd:map-codebase

Смысл: agent должен понять stack, architecture, conventions, testing style и risk zones до того, как будет планировать новую feature.

Потом:

/gsd:new-project

Но questions уже должны быть focused на том, что добавляется, а не на угадывании всего проекта.

Пример: notifications в Task Manager

Идея:

Добавить notifications для task assignment и comments.

Плохой prompt:

Add notifications.

GSD-style prompt:

Use GSD workflow.

Goal:
Add notifications for task assignments and comments.

Start by mapping the current codebase if needed.
Then ask questions, extract requirements, and create a roadmap.
Do not implement until phase 1 is discussed and planned.

Возможный roadmap:

Phase 1: notification domain model and tests
Phase 2: assignment notifications
Phase 3: comment notifications
Phase 4: UI notification center
Phase 5: verification and cleanup

Каждая phase проходит discuss, plan, execute, verify.

Когда GSD полезен

GSD хорошо подходит, когда:

feature больше одной маленькой task;
agent теряет context на длинной работе;
нужно вести работу phases;
проект может быть как greenfield, так и brownfield;
команда хочет меньше ceremony, чем BMAD;
нужны persistent artifacts;
важно разделить planning and execution.

Когда не стоит брать

GSD может не подойти, если:

команда хочет строгий enterprise lifecycle;
нужен formal PRD/architecture/story process;
задача слишком маленькая для phase loop;
project owner не готов отвечать на вопросы agent;
тестовая база отсутствует и verification нечем подтвердить.

Риски

Риск	Как проявляется	Что делать
Too much trust in automation	Agent красиво ведет phase, но tests не доказывают behavior.	Требовать verification commands and fresh output.
Weak roadmap	Phases не соответствуют реальным dependencies.	Review roadmap before execution.
Context artifacts stale	`PROJECT.md` или `STATE.md` устаревают.	Обновлять artifacts после крупных changes.
Brownfield misunderstanding	Agent неправильно понял architecture.	Начинать с codebase mapping and focused review.
Command syntax drift	Runtime меняет routing commands.	Проверять README and install output.

Prompt patterns

Начать проект

Use GSD.
Run the initialization flow.
Ask questions until requirements and non-goals are explicit.
Create roadmap phases and stop for approval.

Начать phase

Discuss phase 1 before planning.
Capture implementation decisions, constraints, dependencies, and verification expectations.
Do not write code during discussion.

Проверить phase

Verify phase 1 against:
- requirements
- phase plan
- tests
- API contracts if changed
- manual acceptance checklist

Do not mark the phase complete without fresh evidence.

Практика

Возьмите крупную feature и разбейте ее на phases:

Feature:
Requirements:
Out of scope:
Phase 1:
Phase 2:
Phase 3:
Verification per phase:

Проверьте:

можно ли каждую phase проверить отдельно;
не смешан ли UI, API и migration в один слишком большой phase;
есть ли explicit definition of done.

Критерии готовности

После урока студент должен уметь:

объяснить, что такое context rot;
описать GSD phase loop;
назвать основные artifacts GSD;
отличить greenfield и brownfield start;
сформулировать GSD-style prompt;
объяснить, почему phase verification важнее фразы "done".

Краткое резюме

GSD показывает lightweight путь к SDD: не строить тяжелую agile-методологию, а дать agent четкий phase loop, persistent artifacts и context engineering. Его основная сила - борьба с context rot и дисциплина "discuss, plan, execute, verify, ship".

Вопросы для самопроверки

Что такое context rot?
Почему GSD разбивает работу на phases?
Зачем в brownfield проекте начинать с codebase mapping?
Какие artifacts помогают agent resume?
Почему phase нельзя завершать без verification?

Источники для актуализации

GSD repository: https://github.com/gsd-build/get-shit-done
GSD architecture docs: https://github.com/gsd-build/get-shit-done/tree/main/docs

Что дальше

Следующий урок разберет OpenSpec - lightweight SDD CLI, построенный вокруг change proposals, delta specs и архивации выполненных изменений.