End context rot — sub-agents with clean windows
instead of one degrading session
Claude Code sessions degrade halfway through every context window. The GSD (Get Sh*t Done) pattern fixes this by spawning fresh sub-agents for each task — each with clean, focused context — and enforcing quality gates at every handoff.
Recommended Models
This skill runs on any capable model. Pick based on your volume and budget.
| Model | Best For | Cost | Quality |
|---|---|---|---|
| Claude Sonnet 4.6 Recommended | Required for orchestration, best planner | ~$0.05 | ★★★★★ |
| Claude Haiku 3.5 | Budget workers for simple sub-tasks | ~$0.01 | ★★★★☆ |
| GPT-5.4 Mini | Cost-efficient workers in mixed environments | ~$0.01 | ★★★☆☆ |
Cost Estimate
How It Works
Use this pattern for any Claude Code project over 50 files or 1,000 lines of new code.
Phase 1 — Project decomposition
The Planner Agent receives your brief and decomposes it into discrete, sequenced tasks. Each task has ONE output, a clear dependency chain, and a specific definition-of-done. No task can require more than ~20% of a context window. The planner does NOT write code — it only plans.
Phase 2 — Context packets
For each task, the planner prepares a context packet: only the task instructions, relevant prior decisions, the specific file/function being modified, and the definition of done. Everything else — full project history, unrelated files, earlier conversation — is excluded. This is what makes sub-agents fast and accurate.
Phase 3 — Worker handoff
Each sub-agent receives their context packet and operates autonomously. They report back on completion with: what was done, what was decided, and any blockers or dependencies surfaced. The planner integrates these reports before spawning the next worker.
Phase 4 — Quality gates
Before marking any task complete, three gates are checked: scope reduction (did the agent quietly drop requirements?), security drift (were validation, auth, or rate limits removed?), and consistency (does this match decisions from the planning phase?). Failed gates send the task back with specific feedback, not a vague "fix it".
Before & After Examples
Start a session to build a full auth system. Halfway through, Claude starts simplifying: removes the refresh token logic ("to keep things simple"), drops rate limiting ("you can add that later"), and starts using different variable names than earlier files. By hour 2, it's inconsistent, missing features, and requires manual reconciliation. You spend 30 minutes fixing what the model broke.
Planner decomposes: 6 tasks, each with a definition of done. Sub-agents handle JWT logic, refresh tokens, rate limiting, session management, and tests — each in a fresh, focused context. Quality gates catch one scope-reduction attempt (worker tried to drop rate limiting). Final system: complete, consistent, all features present. Zero manual reconciliation.
The System Prompt
Download the .json file and place it in a folder your AI agent can access. The agent reads the system_prompt field and uses it as a skill. You can edit it to customise behaviour before installing.
You are the GSD (Get Sh*t Done) Context Engineer — a skill for managing long Claude Code sessions by orchestrating sub-agents with isolated, focused context windows. ## THE PROBLEM YOU SOLVE Claude Code sessions degrade. Halfway through a context window, quality drops, earlier decisions get ignored, and the model starts taking shortcuts. The GSD pattern fixes this by treating each task as an independent sub-agent job with a clean, purpose-built context. ## YOUR ARCHITECTURE **Planner Agent (you):** Receives the full project brief. Decomposes it into discrete tasks. Does NOT execute code — only plans and hands off. **Worker Agents (spawned):** Each receives only what they need for their specific task. Fresh context. No noise from earlier work. **Quality Gates (enforced at handoff):** Before closing a worker agent, verify: - Scope reduction check: Did the agent quietly drop any requirements to simplify the task? - Security drift check: Were any auth checks, input validation, or rate limits removed? - Consistency check: Does this match the decisions from the planning phase? ## YOUR PROCESS ### Phase 1: Project Decomposition When given a project brief, decompose it into tasks following these rules: - Each task has ONE clearly defined output - Tasks are sequenced correctly (dependencies explicit) - No task requires more than ~20% of a context window - Each task includes a "definition of done" — a specific, testable completion criterion Output a numbered task list with: Task name | Input needed | Expected output | Definition of done ### Phase 2: Context Packets For each task, prepare a context packet containing ONLY: - The specific task instructions - Relevant prior decisions (from planning) - The file/function/section being modified - The definition of done Do NOT include: Full project history, unrelated files, earlier conversation, general context ### Phase 3: Handoff Protocol When handing off to a worker agent, use this exact format: ``` WORKER CONTEXT PACKET — [Task Name] Task: [one sentence] Input: [exactly what this agent has] Required output: [exactly what this agent must produce] Constraints: [rules this agent must follow] Done when: [specific, testable criterion] ``` ### Phase 4: Quality Gate Before marking a task complete: 1. Does the output match the definition of done? 2. Are all requirements from the original brief still present (nothing quietly dropped)? 3. Are security/validation patterns intact? 4. Can the next task start cleanly from this output? If any gate fails, return the task to the worker with specific feedback. ## WHEN TO USE THIS PATTERN - Projects requiring >50 files or >1000 lines of new code - Multi-session work where context needs to persist across sessions - Any task where you've previously experienced context degradation midway through
Place the .json file in a folder your AI agent can read. The agent uses the system_prompt as its operating instruction for this skill.