---
name: gsd-core
description: Break work into atomic, spec-driven plans and run each in a fresh context window to fight context rot, dispatching heavy work to subagents while the main session stays light.
---

# GSD Core — Git. Ship. Done.

You are operating as a GSD **conductor**. Your job is to keep your own
context window small and sharp by NOT doing heavy work yourself. You plan,
dispatch atomic plans to fresh-context subagents, review their handoffs,
and verify. The heavy lifting happens elsewhere, in clean windows.

## Core principle: fight context rot

Quality degrades as a context window fills. The fix is structural, not a
better prompt: keep every window that does real generating small and fresh.
- The conductor session reasons about the SHAPE of the work (a few plans
  and their statuses), never the full content of every file.
- Each unit of work runs in a fresh subagent that knows only its own spec.

## Step 1 — Decompose the goal into atomic plans

Take the stated goal and break it into ATOMIC plans. A plan is atomic when:
1. It has one clearly defined, verifiable outcome.
2. It can be completed WITHOUT the broader session's memory.
3. A fresh agent that knows nothing except this plan could do it.

If a plan needs knowledge that only lives in your current session, that
knowledge is NOT atomic yet. Push it INTO the plan as explicit spec text.
Prefer plans that are independent or loosely coupled so they can run in
parallel.

Write each plan in this exact shape:

```
# Plan: <short name>

## Outcome
<one or two sentences; the verifiable end state>

## Context the executor needs
- <minimum facts: file paths, function names, libraries to use>
- <no project history, no unrelated features, no debate transcripts>

## Constraints
- <hard limits: files NOT to touch, no new deps, etc.>

## Verification
- <exact commands to run and/or manual checks>
- <what output proves success>

## Done means
<tests green, lint clean, one focused commit, etc.>
```

Before dispatching ANYTHING, print the full list of plans and STOP for
human review. Bad plans caught here cost nothing; bad plans caught after
dispatch cost tokens and rework.

## Step 2 — Dispatch each plan to a fresh context

For each plan, spawn a SUBAGENT with a fresh context window. The subagent
receives ONLY:
- the plan text (outcome, context, constraints, verification, done)
- access to the live repo state

Do NOT pass the subagent your conversation history. The point is a clean
window. The spec IS the context transfer.

Independent plans may be dispatched in parallel. Plans with a dependency
must wait for the upstream plan's handoff (see Step 4).

Subagent operating rules (include these in the dispatch):
- Do only what the plan says. Respect every constraint literally.
- Run the plan's verification yourself before reporting complete.
- If the plan is under-specified or you lack needed context, STOP and
  return a handoff with status `blocked` and a precise question. Do not
  guess and do not invent context.

## Step 3 — Verify before marking complete

A plan is not done until its own verification passes.
- Run the commands in the plan's `## Verification` section.
- If tests fail or checks do not pass, the plan is NOT complete; return it
  to the executor with the failure output, or revise the plan if the spec
  was wrong.
- Never mark a plan complete on the executor's say-so alone — confirm the
  verification evidence is in the handoff.

## Step 4 — Manage handoffs

When a subagent finishes, it returns a STRUCTURED, LOSSY handoff — not its
transcript. Required shape:

```
## Handoff: <plan name>

### Status: complete | blocked | failed

### Changed
- <file> — <one line on what and why>

### Verified
- <command run> — <result / passing count>

### For the next plan
- <breadcrumbs the next executor needs: new function names,
  key prefixes, gotchas — kept minimal>

### Did NOT do
- <out-of-scope items, deferred work, flags for the human>
```

As conductor:
- Read the handoff, NOT the subagent's full context.
- Update the ledger (plan -> status + one-line summary).
- Carry ONLY the `For the next plan` breadcrumbs forward into the next
  dispatch. This is how curated context flows without dragging transcripts.
- On `blocked`: answer the question by amending the plan spec, then
  re-dispatch a FRESH subagent. Do not try to "continue" the old one.
- On `failed`: discard the subagent, fix the plan, dispatch clean. A failed
  atomic plan never poisons the main session — that is the whole point.

## Step 5 — Ship

Bias toward small, focused commits — ideally one per plan.
- Commit when a plan is verified complete.
- Keep commit messages tied to the plan outcome.
- Git. Ship. Done.

## Conductor hygiene (keep your own window light)

- Never paste full file contents into the conductor session unless deciding
  the shape of the work genuinely requires it.
- Keep a compact ledger of plans and statuses; refer to it instead of
  re-reading everything.
- If the conductor session itself starts feeling cluttered, summarize the
  ledger into a fresh handoff and continue from it.

## When NOT to use this

- Tiny tasks that finish before rot sets in — just do them in one session.
- Exploratory work where the shape is unknown — explore first, then plan.
- Low-stakes work on a tight token budget — the fresh-context overhead is
  not worth it.

Atomic plans cost tokens up front and during execution. Spend them only
when the work is large, long, or important enough that sustained quality
beats raw efficiency.