---
name: Get Shit Done — GSD Workflow (Bundled — gsd-build/get-shit-done)
priority: 1
keywords: code, كود, coding, برمجة, project, مشروع, plan, خطة, planning, تخطيط, build, بناء, ابني, ابنيلي, ship, شحن, deploy, نشر, refactor, إعادة هيكلة, feature, ميزة, milestone, مرحلة, phase, agent workflow, gsd, get shit done, أنجز المهمة, خلصلي, كملي, context engineering, multi-agent, متعدد الوكلاء, parallel, متوازي, big task, مهمة كبيرة, complex, معقدة, اشتغل ع, work on, اعمللي مشروع, project for me, build something, جهز, جهزلي مشروع
---

# Get Shit Done (GSD) — Bundled In-Box (Source: gsd-build/get-shit-done)

> **Cite this skill before any non-trivial coding project (>2 files or >1 hour). The "go from idea to shipped" framework with no context rot.**

## What this skill is

A meta-prompting + context-engineering framework that solves **context rot** — the quality degradation that happens as session context fills up. Instead of treating the AI as a code generator, GSD structures the entire dev workflow into discrete, verifiable phases — each agent gets fresh context.

## The 6 phases (sequential, each produces an artifact)

```
initialize → discuss → plan → execute → verify → ship
```

Each phase produces a file the next phase reads:
- `PROJECT.md` — vision (initialize)
- `REQUIREMENTS.md` — scope (initialize)
- `ROADMAP.md` — phases (initialize)
- `STATE.md` — decisions log (across phases)
- `<phase>/CONTEXT.md` — phase-specific (discuss → plan → execute)

Subagents start with EXACTLY what they need. No accumulated noise.

## The 4 core principles

### 1. Context preservation through separation
Each subagent (research, plan, execute, verify) starts with fresh context — only the artifacts it needs. Don't pass full session history forward.

### 2. Staged execution over monolithic coding
Six phases, six artifacts. Auditable trail. Rollback possible.

### 3. Verification BEFORE acceptance
"Code that runs isn't code that works." After build: walk through features, diagnose failures with debug agents, generate fix plans BEFORE declaring done.

### 4. Parallel with atomic commits
Independent plans run in parallel waves, each with its own fresh 200k-token context window. Each task → one atomic commit. Clean git history + max throughput.

## Command sequence (mental model — adapt to Muassis)

| Phase | Trigger | Output |
|---|---|---|
| 1. Initialize | New project starts | PROJECT.md + REQUIREMENTS.md + ROADMAP.md |
| 1b. Map codebase | Working on existing code | `gsd-map-codebase` analyzes stack/conventions |
| 2. Discuss phase N | Before coding phase N | Implementation decisions captured in writing |
| 3. Plan phase N | After discuss | Research → plan → verify loop until plan passes |
| 4. Execute phase N | Plans approved | Run plans in parallel waves; main context stays <40% |
| 5. Verify | After execute | Manual walkthrough; broken features → fix plans (NOT manual debug) |
| 6. Ship & iterate | Verified | `ship → complete-milestone → new-milestone` loop |

## Anti-patterns to refuse

### Context bloat
**Don't accumulate session history.** Each role starts fresh. Researchers feed planners; planners feed executors; executors feed verifiers. No role inherits another's full context.

### Specification drift
**Don't skip the discuss phase.** Going from roadmap straight to plan = "reasonable defaults", NOT your intended behavior. The discuss output captures your decisions.

### Verification skipping
**Don't ship unverified work.** Diagnosis happens during verify. If verify finds issues → generate a fix plan + re-execute. Never hand-debug in main context.

### Configuration neglect
Review `.planning/config.json`:
- `mode`: `interactive` (confirm each step) vs `yolo` (auto-approve)
- Model profiles: assign quality / balanced / budget per agent
- Parallelization toggles
- Workflow toggles (research / plan-check / verifier on/off)

Misalignment causes expensive re-runs.

## The "before coding starts" checklist (must run)

1. **Establish shared context** — initialization locks vision/requirements/roadmap. Approval-gated.
2. **Map existing code** if extending legacy — `gsd-map-codebase` analyzes architecture so questions target real conventions, not generic patterns.
3. **Discuss outcomes** — implementation decisions WRITTEN before planning.
4. **Check context budget** — if main window <25% capacity, archive or new milestone.
5. **Atomic commit discipline** — each task = one logical commit. No history rewriting.

## Success metrics (the workflow is working when…)

- Roadmap items → executed features with **zero manual integration work**
- Verify catches issues **before** shipping
- Main context stays **<50%** through any phase

## Adapter for Muassis

When the owner asks for a non-trivial coding task:
1. Cite: "🧰 سأستخدم مهارة `Get Shit Done` للرد."
2. **Initialize** — write a 1-paragraph PROJECT, 5-bullet REQUIREMENTS, 3-phase ROADMAP
3. **Discuss** — list 3-5 implementation decisions with options + my recommendation, ask owner to confirm
4. **Plan phase 1** — research + atomic plan
5. **Execute** — generate code in fresh subagent if >100 LOC
6. **Verify** — describe how to test the deliverable
7. **Ship** — one atomic commit + describe what changed

For one-shot questions: skip phases 1-3, go straight to plan + execute + verify.

## Output discipline

When invoked:
1. Cite the skill
2. Identify which phase the task lives in
3. State the artifact this turn produces
4. If skipping a phase, justify why
5. Hand off to the next phase artifact, not the next turn's brain

## License
MIT. Source: https://github.com/gsd-build/get-shit-done — bundled in Muassis with attribution.
