Skip to main content
GSD Core organizes all development work into a disciplined, repeatable cycle called the phase loop. Every milestone is broken into numbered phases, and every phase moves through the same five steps in sequence. This structure is what separates GSD Core from ad-hoc AI coding: each step produces artifacts that the next step consumes, so nothing relies on conversation memory and every decision is traceable to a document on disk.

​
The five-step phase loop

Each phase in your ROADMAP.md moves through these steps in order:
1

Discuss

Before any planning begins, you lock in your implementation preferences by running /gsd-discuss-phase N. GSD Core reads the phase description from your roadmap, scans the existing codebase for relevant patterns, and asks targeted questions about gray areas — library choices, design patterns, testing approach, and any decisions where multiple options are viable.Your answers are written to .planning/phases/XX-name/XX-CONTEXT.md. Every downstream agent — the planner, the executor, and the verifier — reads this file. Nothing is inferred; everything is explicit.Outcome: CONTEXT.md containing a <decisions> block of numbered implementation decisions.
2

Plan

The /gsd-plan-phase N command runs the full research-and-planning pipeline. Four specialist researchers run in parallel, each exploring a different dimension of the implementation domain. A synthesizer combines their findings into RESEARCH.md. The planner then reads PROJECT.md, REQUIREMENTS.md, CONTEXT.md, and RESEARCH.md together to create two to three atomic execution plans.A plan-checker agent verifies the plans across eight dimensions before they are approved. If plans fail the check, the planner revises them automatically (up to three iterations). The plans are not approved until the checker returns a PASS verdict.Outcome: RESEARCH.md and one or more XX-YY-PLAN.md files containing structured task lists with explicit dependency ordering.
3

Execute

The /gsd-execute-phase N command analyzes plan dependencies, groups plans into waves, and spawns parallel executor subagents. Each executor runs in a fresh context window — up to 200K tokens, or up to 1M tokens on models that support it — with no accumulated conversation history.Each executor reads only its assigned PLAN.md plus the phase context files, implements the tasks, makes an atomic git commit per completed task, and writes a SUMMARY.md documenting outcomes and deviations. After all waves complete, a verifier agent runs a goal-backward check against the phase requirements.Outcome: Committed code, per-plan SUMMARY.md files, and a VERIFICATION.md with a PASS or FAIL verdict.
4

Verify

The /gsd-verify-work N command walks you through a structured user acceptance testing session. You test the implemented features against the phase goals, document your findings, and mark the phase as verified or flag issues. GSD Core reads the automated verification results alongside your UAT notes to build a complete picture of phase quality.If issues are found, GSD Core generates targeted fix plans. The phase is not considered done until both automated verification and UAT pass.Outcome: UAT.md documenting your acceptance test results and any outstanding issues.
5

Ship

The /gsd-ship N command reads all phase artifacts — plans, summaries, verification results, and UAT notes — and generates a structured pull request. It archives the phase state, advances STATE.md to the next phase, and writes a continue-here.md handoff for the next session.Outcome: A pull request, archived phase artifacts, and an updated STATE.md ready for the next phase.

​
How phases map to milestones

A milestone is a major product goal — a shippable increment that delivers meaningful value. A phase is one step toward that milestone. Your ROADMAP.md organizes phases under milestones and tracks the status of each. 
Milestone 1: Core Authentication
  Phase 1: Database schema and user model
  Phase 2: Registration and login endpoints
  Phase 3: Session management and JWT
  Phase 4: Password reset flow

Milestone 2: Dashboard
  Phase 5: Layout and navigation shell
  Phase 6: Data fetching and charts
  ...
Each phase is small enough to plan, execute, and verify in one session. Phases that are too large produce plans with too many tasks, which executors cannot reliably complete in a single context window. The guideline is two to three atomic plans per phase, each with two to three tasks. When a milestone is complete, run /gsd-audit-milestone to check requirement coverage and detect any stubs, then /gsd-complete-milestone to archive and tag the work.

​
Spec-driven development

GSD Core applies a spec-driven development approach: every requirement is written down before any code is written, and every artifact gates the next stage. The flow looks like this: 
User vision
    │
    ▼
REQUIREMENTS.md — scoped requirements with IDs (REQ-001, REQ-002, ...)
    │
    ▼
ROADMAP.md — phases mapped to requirement IDs (traceability guaranteed)
    │
    ▼
CONTEXT.md — implementation preferences per phase
    │
    ▼
RESEARCH.md — ecosystem research per phase
    │
    ▼
PLAN.md — atomic execution tasks referencing requirements and acceptance criteria
    │
    ▼
SUMMARY.md — what was built, deviations from plan
    │
    ▼
VERIFICATION.md — goal-backward check against phase requirements
    │
    ▼
UAT.md — human acceptance testing results
The plan-checker enforces that every plan covers the requirements it claims to cover. The verifier enforces that every requirement mapped to the phase is actually implemented. If a requirement is not covered, the phase does not advance.

​
Artifact dependency map

Each artifact is consumed by specific agents downstream. The table below shows which agents read each planning artifact:
ArtifactRead by
PROJECT.mdAll agents — planner, executor, verifier, researcher
REQUIREMENTS.mdPlanner, plan-checker, verifier, auditor
ROADMAP.mdOrchestrators, roadmapper
STATE.mdAll agents — decisions, blockers, current position
CONTEXT.md (per phase)Researcher, planner, executor
RESEARCH.md (per phase)Planner, plan-checker
PLAN.md (per plan)Executor, plan-checker
SUMMARY.md (per plan)Verifier, state tracking
Nothing is held in conversation memory. If you run /clear between steps, everything the next agent needs is already on disk.

​
Namespace routing

GSD Core ships six namespace meta-skills as top-level entry points for the phase pipeline. Each namespace router maps natural-language intent to the correct concrete command:
NamespaceCommandRoutes to
Phase pipeline/gsd-workflowdiscuss, plan, execute, verify, progress
Project lifecycle/gsd-projectmilestones, audits, summary
Quality gates/gsd-qualitycode review, debug, security, UI audit
Codebase intelligence/gsd-contextmap, graphify, docs, learnings
Management/gsd-manageconfig, workspace, workstreams, ship
Exploration/gsd-ideateexplore, sketch, spike, spec, capture
You can always invoke concrete commands directly (for example, /gsd-plan-phase 1). The namespace routers exist to reduce the token cost of skill discovery — six entries instead of eighty-six.