← Back to Home

Open GSD — AI Coding Agent Meta-Framework That Beats Context Rot

2026-07-10

Open GSD — AI Coding Agent Meta-Framework That Beats Context Rot

You've been there. You start a session with Claude Code or Codex, explain your architecture, write some solid code. Three hours and 50 tool calls later, the agent starts hallucinating — forgetting what file it just edited, suggesting things you already tried, and losing the plot entirely. That's context rot: the quality degradation that accumulates as an AI agent fills its context window with conversation history.

Open GSD (Git. Ship. Done.) fixes this. It's not another AI coding agent — it's a meta-framework that wraps existing agents (Claude Code, Codex, Cursor, Copilot, Cline, Gemini CLI, and more) in a disciplined phase loop. Each phase runs heavy research, planning, and execution work in fresh-context subagents while keeping your main session lean. The result: no context rot, structured verification, and code that actually ships.

Since its release in late May 2026, Open GSD has garnered over 6,200 GitHub stars and an active Discord community. It's MIT-licensed and works with any major AI coding runtime.

Why It's Trending

  • Context rot is solved — every subagent starts with a clean 200K-token context window (up to 1M for supported models). No accumulated session junk degrading quality.
  • Universal runtime support — works with Claude Code, Codex, Cursor, Copilot, Cline, Windsurf, Gemini CLI, Kimi CLI, Kilo, OpenCode, Antigravity, Trae, Augment Code — any runtime where AI agents run.
  • Structured phase loop — Discuss → Plan → Execute → Verify → Ship. Each step catches a specific failure mode that the previous step can't prevent.
  • File-based state — all project state lives in .planning/ as Markdown and JSON. No database, no server. Survives context resets and spans multiple sessions.
  • 33 specialized agents — researchers, planners, executors, verifiers, debuggers, security auditors, UI auditors — each with focused prompts and tool permissions.
  • Spec-driven development — requirements → research → plans → execution → verification pipeline. Every phase has clear acceptance criteria.
  • Active community — Discord, growing plugin ecosystem, active development with frequent releases.

Architecture Overview

Open GSD Architecture

The architecture follows a layered design. At the top, commands (/gsd-* slash commands or $gsd-* skill invocations) serve as user entry points. These trigger workflows — orchestration .md files that load context, spawn specialized agents, and manage state transitions. The CLI Tools Layer (gsd-tools.cjs) provides utility commands for context loading, model resolution, state management, and plan verification. Everything reads and writes to the .planning/ File System — the persistent state layer that survives session resets.

Specialized agents fall into several categories: Researchers (4 parallel — stack, features, architecture, pitfalls), Synthesizers (combines research into summary), Planners (decompose into bounded work units), Checkers (verify plan correctness), Executors (implement plans in parallel waves), Verifiers (confirm acceptance criteria met), and Shippers (create PRs, archive phases).

The phase loop works through .planning/ which carries state across the loop — CONTEXT.md from Discuss, RESEARCH.md and PLAN.md from Plan, SUMMARY.md from Execute, VERIFICATION.md from Verify — all persisted for cross-session access.

Prerequisites

  • Node.js 18+ (for the npx @opengsd/gsd-core installer)
  • One of the supported AI coding runtimes: Claude Code, Codex, Cursor, Copilot, Cline, Windsurf, Gemini CLI, Kimi CLI, Kilo, OpenCode, or Antigravity
  • Git (for version control and PR creation)
  • A terminal emulator with sufficient context window support (recommended: 200K tokens minimum)

Installation

GSD Core installs with a single command:

npx @opengsd/gsd-core@latest

The installer prompts you for:

  1. Your runtime (Claude Code, Codex, Cursor, Copilot, Cline, etc.)
  2. Whether to install globally or locally in the current project

For runtimes without Node.js, see the install-on-your-runtime guide.

Starting a New Project

Once installed, initialize a greenfield project:

cd my-new-project
/gsd-new-project

The command walks you through a structured Q&A session (based on questioning.md philosophy) to capture your idea, then spawns 4 parallel researchers (stack, features, architecture, pitfalls), a research synthesizer, and sets up your .planning/ directory.

Onboarding an Existing Codebase

For brownfield projects:

cd your-existing-repo
/gsd-onboard

This generates a codebase map (technology stack, architecture patterns, conventions, testing setup, known concerns) and creates your initial .planning/ structure.

The Phase Loop in Practice

Each milestone repeats the same five-step loop:

1. Discuss

/gsd-discuss "Add Redis caching layer to the API gateway"

The Discuss step captures implementation decisions before planning begins. Which Redis client library? What cache invalidation strategy? Per-route or global TTL? Edge cases? Output: CONTEXT.md in the phase directory.

2. Plan

/gsd-plan

Runs a sequence of fresh-context subagents: a researcher investigates the ecosystem and records findings in RESEARCH.md, a planner reads both research and CONTEXT.md to produce PLAN.md files, and a plan-checker verifies plans are complete, consistent, and within scope.

3. Execute

/gsd-execute

Plans are grouped into dependency waves. Executors in the same wave run in parallel with fresh 200K-token contexts. Each executor has:

  • The specific PLAN.md to execute
  • Project context (PROJECT.md, STATE.md)
  • Phase context (CONTEXT.md, RESEARCH.md if available)

Executors write code and commit atomically. Later waves wait for earlier ones to complete.

4. Verify

/gsd-verify

A verifier agent reads the phase goal, CONTEXT.md decisions, the plans, and execution summaries — then checks that what was built matches what was intended. Produces VERIFICATION.md and generates targeted fix plans if discrepancies exist.

5. Ship

/gsd-ship

Creates the pull request, archives the phase artifacts, and updates STATE.md to mark the phase complete. The loop then begins again for the next phase.

Quick Commands Reference

Command Purpose
/gsd-new-project Start a greenfield project
/gsd-onboard Onboard an existing codebase
/gsd-discuss Capture implementation decisions
/gsd-ui-phase Optional UI design step (between Discuss and Plan)
/gsd-plan Research, decompose, and plan
/gsd-execute Execute plans in parallel waves
/gsd-verify Verify built work against phase goals
/gsd-ship Create PR and archive phase
/gsd-status Show current phase and project state
/gsd-quick Quick work below the phase-loop threshold

Key Concepts

Fresh-Context Subagents

Every subagent spawned by an orchestrator gets a clean context window (up to 200K tokens). This is the core mechanism that prevents context rot. An executor that runs with 180K tokens of accumulated session history is a degraded executor; one that starts clean and reads only what its plan requires operates at full capacity.

Wave Execution Model

During execute-phase, plans are grouped into dependency waves:

  • Wave 1: Plans with no dependencies run in parallel
  • Wave 2: Plans depending on Wave 1 run after Wave 1 completes
  • Wave 3: Plans depending on Waves 1 and 2 run last

This maximizes parallelism while ensuring correctness. Each executor in the same wave touches non-overlapping concerns, with --no-verify commits to avoid hook contention and STATE.md file locking for safe parallel state writes.

File-Based State

All state lives in .planning/ as human-readable Markdown and JSON:

  • PROJECT.md — Project overview and goals
  • REQUIREMENTS.md — Feature requirements
  • ROADMAP.md — Milestone and phase tracking
  • STATE.md — Current position in the loop
  • phases/ — Phase-specific artifacts (CONTEXT, RESEARCH, PLAN, SUMMARY, VERIFICATION)
  • config.json — Runtime configuration

This means state survives context resets (/clear), is inspectable by both humans and agents, and can be committed to git for team visibility.

Adaptive Context Enrichment (1M Models)

When the context window is 500K+ tokens (1M-class models like Opus 4.6, Sonnet 4.6), subagent prompts are automatically enriched — executor agents receive prior wave SUMMARY.md files and phase CONTEXT.md/RESEARCH.md for cross-plan awareness, and verifier agents receive all PLAN.md, SUMMARY.md, CONTEXT.md, and REQUIREMENTS.md files.

Use Cases

  • Greenfield projects — structured development from idea to shipped product
  • Brownfield refactoring — systematic codebase improvements with verification gates
  • Debugging complex issues — structured debug sessions with subagent isolation
  • Code review pipelines — automated multi-agent review workflows
  • Team collaboration — shared .planning/ state committed to git for team visibility

Comparison with Other Tools

Feature GSD Core Claude Code (raw) Codex (raw) Cursor
Context rot prevention ⭐ Subagents + phase loop ❌ None ❌ None ⭐ Partial (tabs)
Multi-agent orchestration ⭐ 33 agents ❌ Single agent ❌ Single agent ❌ Single agent
Runtime support ⭐ 10+ runtimes ⚠️ Claude only ⚠️ Codex only ⚠️ Cursor only
Cross-session memory ⭐ .planning/ files ❌ None ❌ None ⚠️ Limited
Verification pipeline ⭐ Built-in verifier ❌ Manual ❌ Manual ❌ Manual
Spec-driven development ⭐ Full pipeline ❌ None ❌ None ❌ None
Open source ⭐ MIT ❌ Proprietary ❌ Proprietary ❌ Proprietary

Resources

← Retour à l'Accueil

Open GSD — Le Méta-Framework pour Agents de Codage IA qui Vainc la Dégradation du Contexte

2026-07-10

Open GSD — Le Méta-Framework pour Agents de Codage IA qui Vainc la Dégradation du Contexte

Vous connaissez ça. Vous démarrez une session avec Claude Code ou Codex, vous expliquez votre architecture, vous écrivez du bon code. Trois heures et 50 appels d'outils plus tard, l'agent commence à halluciner — oubliant quel fichier il vient de modifier, suggérant des choses que vous avez déjà essayées, et perdant complètement le fil. C'est la dégradation du contexte (context rot) : la perte de qualité qui s'accumule à mesure qu'un agent IA remplit sa fenêtre de contexte avec l'historique de la conversation.

Open GSD (Git. Ship. Done.) résout ce problème. Ce n'est pas un autre agent de codage IA — c'est un méta-framework qui enveloppe les agents existants (Claude Code, Codex, Cursor, Copilot, Cline, Gemini CLI, et plus) dans une boucle de phases disciplinée. Chaque phase exécute les travaux lourds de recherche, planification et exécution dans des sous-agents à contexte frais tout en gardant votre session principale légère. Résultat : pas de dégradation du contexte, une vérification structurée, et du code qui est vraiment livré.

Depuis sa sortie fin mai 2026, Open GSD a accumulé plus de 6 200 étoiles GitHub et une communauté Discord active. Il est sous licence MIT et fonctionne avec tous les principaux runtimes de codage IA.

Pourquoi C'est Tendance

  • La dégradation du contexte est résolue — chaque sous-agent démarre avec une fenêtre de contexte propre de 200K tokens (jusqu'à 1M pour les modèles supportés). Aucun encombrement de session accumulé ne dégrade la qualité.
  • Support universel des runtimes — fonctionne avec Claude Code, Codex, Cursor, Copilot, Cline, Windsurf, Gemini CLI, Kimi CLI, Kilo, OpenCode, Antigravity, Trae, Augment Code — tout runtime où les agents IA s'exécutent.
  • Boucle de phase structurée — Discuss → Plan → Execute → Verify → Ship. Chaque étape capture un mode d'échec spécifique que l'étape précédente ne peut pas empêcher.
  • État basé sur fichiers — tout l'état du projet vit dans .planning/ en Markdown et JSON. Pas de base de données, pas de serveur. Survit aux réinitialisations de contexte et s'étend sur plusieurs sessions.
  • 33 agents spécialisés — chercheurs, planificateurs, exécuteurs, vérificateurs, débogueurs, auditeurs de sécurité, auditeurs UI — chacun avec des prompts ciblés et des permissions d'outils spécifiques.
  • Développement piloté par spécifications — pipeline exigences → recherche → plans → exécution → vérification. Chaque phase a des critères d'acceptation clairs.
  • Communauté active — Discord, écosystème de plugins en croissance, développement actif avec des versions fréquentes.

Architecture

Architecture Open GSD

L'architecture suit une conception en couches. En haut, les commandes (slash commands /gsd-* ou invocations de skills $gsd-*) servent de points d'entrée utilisateur. Elles déclenchent des workflows — des fichiers d'orchestration .md qui chargent le contexte, invoquent des agents spécialisés et gèrent les transitions d'état. La couche d'outils CLI (gsd-tools.cjs) fournit des commandes utilitaires pour le chargement de contexte, la résolution de modèle, la gestion d'état et la vérification de plan. Le tout lit et écrit dans le système de fichiers .planning/ — la couche d'état persistante qui survit aux réinitialisations de session.

Les agents spécialisés se répartissent en plusieurs catégories : Chercheurs (4 en parallèle — stack, fonctionnalités, architecture, pièges), Synthétiseurs (combine les recherches en résumé), Planificateurs (décomposent en unités de travail bornées), Vérificateurs de plan (valident l'exactitude du plan), Exécuteurs (implémentent les plans en vagues parallèles), Vérificateurs (confirment que les critères d'acceptation sont remplis), et Expéditeurs (créent les PR, archivent les phases).

La boucle de phases fonctionne via .planning/ qui transporte l'état à travers la boucle — CONTEXT.md de Discuss, RESEARCH.md et PLAN.md de Plan, SUMMARY.md d'Execute, VERIFICATION.md de Verify — tous persistés pour un accès inter-sessions.

Prérequis

  • Node.js 18+ (pour l'installateur npx @opengsd/gsd-core)
  • Un des runtimes de codage IA supportés : Claude Code, Codex, Cursor, Copilot, Cline, Windsurf, Gemini CLI, Kimi CLI, Kilo, OpenCode, ou Antigravity
  • Git (pour le contrôle de version et la création de PR)
  • Un émulateur de terminal avec une fenêtre de contexte suffisante (recommandé : 200K tokens minimum)

Installation

GSD Core s'installe avec une seule commande :

npx @opengsd/gsd-core@latest

L'installateur vous demande :

  1. Votre runtime (Claude Code, Codex, Cursor, Copilot, Cline, etc.)
  2. S'il faut installer globalement ou localement dans le projet courant

Pour les runtimes sans Node.js, consultez le guide d'installation par runtime.

Démarrer un Nouveau Projet

Une fois installé, initialisez un projet greenfield :

cd mon-nouveau-projet
/gsd-new-project

La commande vous guide à travers une session de questions-réponses structurée pour capturer votre idée, puis lance 4 chercheurs en parallèle (stack, fonctionnalités, architecture, pièges), un synthétiseur de recherche, et configure votre répertoire .planning/.

Intégrer un Codebase Existant

Pour les projets brownfield :

cd votre-repo-existant
/gsd-onboard

Cela génère une cartographie du codebase (stack technologique, patterns d'architecture, conventions, configuration de test, problèmes connus) et crée votre structure .planning/ initiale.

La Boucle de Phases en Pratique

Chaque jalon répète la même boucle en cinq étapes :

1. Discuss

/gsd-discuss "Ajouter un cache Redis à la passerelle API"

L'étape Discuss capture les décisions d'implémentation avant la planification. Quelle bibliothèque cliente Redis ? Quelle stratégie d'invalidation du cache ? TTL par route ou global ? Cas limites ? Sortie : CONTEXT.md dans le répertoire de phase.

2. Plan

/gsd-plan

Exécute une séquence de sous-agents à contexte frais : un chercheur étudie l'écosystème et enregistre les résultats dans RESEARCH.md, un planificateur lit la recherche et CONTEXT.md pour produire des fichiers PLAN.md, et un vérificateur de plan valide que les plans sont complets, cohérents et dans le périmètre.

3. Execute

/gsd-execute

Les plans sont groupés en vagues de dépendances. Les exécuteurs d'une même vague s'exécutent en parallèle avec des contextes frais de 200K tokens. Chaque exécuteur reçoit :

  • Le PLAN.md spécifique à exécuter
  • Le contexte du projet (PROJECT.md, STATE.md)
  • Le contexte de phase (CONTEXT.md, RESEARCH.md si disponible)

Les exécuteurs écrivent le code et font des commits atomiques. Les vagues suivantes attendent que les précédentes soient terminées.

4. Verify

/gsd-verify

Un agent vérificateur lit l'objectif de la phase, les décisions de CONTEXT.md, les plans et les résumés d'exécution — puis vérifie que ce qui a été construit correspond à ce qui était prévu. Produit VERIFICATION.md et génère des plans de correction ciblés si des écarts existent.

5. Ship

/gsd-ship

Crée la pull request, archive les artefacts de phase et met à jour STATE.md pour marquer la phase comme terminée. La boucle recommence ensuite pour la phase suivante.

Référence Rapide des Commandes

Commande Objectif
/gsd-new-project Démarrer un projet greenfield
/gsd-onboard Intégrer un codebase existant
/gsd-discuss Capturer les décisions d'implémentation
/gsd-ui-phase Étape de design UI optionnelle (entre Discuss et Plan)
/gsd-plan Rechercher, décomposer et planifier
/gsd-execute Exécuter les plans en vagues parallèles
/gsd-verify Vérifier le travail par rapport aux objectifs de phase
/gsd-ship Créer la PR et archiver la phase
/gsd-status Afficher la phase actuelle et l'état du projet
/gsd-quick Travail rapide sous le seuil de la boucle de phases

Concepts Clés

Sous-Agents à Contexte Frais

Chaque sous-agent invoqué par un orchestrateur reçoit une fenêtre de contexte propre (jusqu'à 200K tokens). C'est le mécanisme central qui empêche la dégradation du contexte. Un exécuteur qui tourne avec 180K tokens d'historique de session accumulé est un exécuteur dégradé ; celui qui démarre propre et lit seulement ce que son plan nécessite opère à pleine capacité.

Modèle d'Exécution par Vagues

Pendant la phase d'exécution, les plans sont groupés en vagues de dépendances :

  • Vague 1 : Les plans sans dépendances s'exécutent en parallèle
  • Vague 2 : Les plans dépendant de la Vague 1 s'exécutent après
  • Vague 3 : Les plans dépendant des Vagues 1 et 2 s'exécutent en dernier

Cela maximise le parallélisme tout en garantissant l'exactitude. Chaque exécuteur dans la même vague touche des préoccupations qui ne se chevauchent pas, avec des commits --no-verify pour éviter la contention des hooks et un verrouillage de fichier STATE.md pour des écritures d'état parallèles sûres.

État Basé sur Fichiers

Tout l'état vit dans .planning/ en Markdown et JSON lisibles :

  • PROJECT.md — Vue d'ensemble et objectifs du projet
  • REQUIREMENTS.md — Exigences fonctionnelles
  • ROADMAP.md — Suivi des jalons et phases
  • STATE.md — Position actuelle dans la boucle
  • phases/ — Artefacts spécifiques aux phases (CONTEXT, RESEARCH, PLAN, SUMMARY, VERIFICATION)
  • config.json — Configuration d'exécution

Cela signifie que l'état survit aux réinitialisations de contexte (/clear), est inspectable par les humains et les agents, et peut être commité dans git pour la visibilité d'équipe.

Enrichissement Adaptatif du Contexte (Modèles 1M)

Quand la fenêtre de contexte est de 500K+ tokens (modèles de classe 1M comme Opus 4.6, Sonnet 4.6), les prompts des sous-agents sont automatiquement enrichis — les exécuteurs reçoivent les fichiers SUMMARY.md des vagues précédentes et CONTEXT.md/RESEARCH.md pour une conscience inter-plans, et les vérificateurs reçoivent tous les fichiers PLAN.md, SUMMARY.md, CONTEXT.md et REQUIREMENTS.md.

Cas d'Utilisation

  • Projets greenfield — développement structuré de l'idée au produit livré
  • Refactoring brownfield — améliorations systématiques du codebase avec des portes de vérification
  • Débogage de problèmes complexes — sessions de débogage structurées avec isolation des sous-agents
  • Pipelines de revue de code — workflows de révision multi-agents automatisés
  • Collaboration d'équipe — état .planning/ partagé commité dans git pour la visibilité d'équipe

Comparaison avec d'Autres Outils

Fonctionnalité GSD Core Claude Code (brut) Codex (brut) Cursor
Prévention dégradation contexte ⭐ Sous-agents + boucle ❌ Aucune ❌ Aucune ⭐ Partielle (onglets)
Orchestration multi-agents ⭐ 33 agents ❌ Agent unique ❌ Agent unique ❌ Agent unique
Support des runtimes ⭐ 10+ runtimes ⚠️ Claude seulement ⚠️ Codex seulement ⚠️ Cursor seulement
Mémoire inter-sessions ⭐ Fichiers .planning/ ❌ Aucune ❌ Aucune ⚠️ Limitée
Pipeline de vérification ⭐ Vérificateur intégré ❌ Manuel ❌ Manuel ❌ Manuel
Développement piloté specs ⭐ Pipeline complet ❌ Aucun ❌ Aucun ❌ Aucun
Open source ⭐ MIT ❌ Propriétaire ❌ Propriétaire ❌ Propriétaire

Ressources