team.management vs GSD Core.
GSD Core runs your work through a five-step loop that opens with Discuss — the same instinct team.management is built on. Both projects also install runtime hooks in Claude Code. The honest comparison is not whether either one enforces anything. It is what each one gates.
What GSD Core is
GSD Core — “Git. Ship. Done.” — is, in its own words, “a light-weight meta-prompting, context engineering, and spec-driven development system…” It installs from npm (@opengsd/gsd-core) and drives each milestone through the same five steps: Discuss, Plan, Execute, Verify, Ship. Discuss captures decisions before planning starts; Execute runs plans in parallel waves; Verify walks through what was built and writes fix plans before anything is called done.
The problem it is built around is context rot — the quality decay that accumulates as an AI fills its context window. Its answer is architectural: heavy work runs in fresh-context subagents so the main session stays lean, and structured artifacts like STATE.md and CONTEXT.md survive session boundaries. It is MIT, sits at ≈8.4k stars, ships near-daily, and installs across nine-plus runtimes — Claude Code, OpenCode, Antigravity CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor and Windsurf.
What team.management is
team.management is an open-source protocol engine that runs inside Claude Code. You describe the process your work should follow; the engine holds which step you are on and decides, before every tool call, what the agent is allowed to do right now. A PreToolUse hook is the mechanism (the DAIC loop is the detail). Each task carries a branch, a work log and an audit trail, produced as a side effect of the process rather than by anyone remembering.
Both gate at runtime — the difference is what they gate
It would be easy, and wrong, to say GSD Core only hands the agent advice. It does not: it registers PreToolUse hooks on Write, Edit and MultiEdit, alongside PostToolUse, SessionStart, Stop and PreCompact. That is the same machinery team.management uses.
What those hooks protect is the distinction worth reading. Four of them cover Write or Edit, and two of those really do hard-block — but on paths, not on phases. gsd-write-guard rejects a whole-file write that would catastrophically shrink one of its curated planning files — the project roadmap, a milestone roadmap, STATE.md — and gsd-worktree-path-guard rejects a write whose absolute path falls outside the worktree root. Both are good guards on artifact integrity.
On ordinary source files, a default install advises — and only sometimes. gsd-read-guard is the hook that fires there, its own header calls it an “Advisory (does not block)”, and it runs only when the target file already exists, so a brand-new file meets nothing at all; gsd-prompt-guard only inspects .planning/ content. The one guard written for edits outside a GSD workflow, gsd-workflow-guard, is opt-in and off by default (hooks.workflow_guard), and it is equally candid about what it is: “This is a SOFT guard — it advises, not blocks. The edit still proceeds.” Its single hard block is a forced git add on an agent branch.
Nothing in that set holds the phase boundary. An agent in Discuss can still edit your source, because the loop’s order is carried by prompts. In team.management the gate is the phase: in discussion mode Edit and Write are refused until the step changes, so “we agreed to plan first” is a property of the session rather than a hope about it.
The limit is the same for both, and worth stating plainly: hooks bind the agent, not you. Every config is MIT and lives in your repo — you can remove a gate whenever you like. The model, mid-session, cannot.
| GSD Core | team.management | |
|---|---|---|
| Own words | “A light-weight meta-prompting, context engineering, and spec-driven development system…” | A protocol engine that gates each step of your process at runtime |
| The loop | Discuss → Plan → Execute → Verify → Ship, per milestone | Named protocols whose steps the engine sequences and records |
| Runtime hooks | Yes — PreToolUse on Write/Edit/MultiEdit, plus PostToolUse, SessionStart, Stop, PreCompact | Yes — a PreToolUse hook rules on every tool call against the current step |
| What the hooks protect | Curated .planning/ files, worktree paths, git safety — the hook that fires on ordinary edits advises | The phase itself — Edit and Write are refused in discussion mode |
| Context strategy | The headline feature: fresh-context subagents, a clean window per executor | Subagents per step; task files carry context across sessions |
| Runtimes | Nine-plus, incl. Cursor, Windsurf, Codex, OpenCode, Kimi | Claude Code only |
| Adoption | ≈8.4k stars, shipping near-daily | Newer and much smaller — open source, active |
| Repository | github.com/open-gsd/gsd-core | github.com/TeamManagementPlugin/claude-plugin |
| Price & license | Free, MIT | Free, MIT |
When GSD Core is the right call
If your team does not work in Claude Code, this comparison is already settled — GSD Core installs on nine runtimes and team.management installs on one. If the failure you actually keep hitting is an agent degrading over a long session rather than an agent skipping a step, GSD Core is aimed squarely at that, and it is bigger, older and more widely adopted than we are.
Choose team.management when the thing that keeps going wrong is the process being skipped: code before the discussion finished, a review step quietly dropped, “done” claimed on work nothing checked. That is the case the engine was built for, and it is the one a soft guard leaves open.
FAQ
Does GSD Core stop the agent from writing code during its Discuss phase?
No. GSD Core does ship PreToolUse hooks — four of them cover Write or Edit — but none gates a phase. Two hard-block on paths: gsd-write-guard rejects a whole-file Write that would clobber a curated .planning/ROADMAP.md or STATE.md, and gsd-worktree-path-guard rejects a write outside the worktree root. On ordinary source files it advises: gsd-read-guard is the hook that fires there and calls itself “Advisory (does not block)”, while gsd-prompt-guard only inspects .planning/ content. The guard written for edits outside a GSD workflow, gsd-workflow-guard, is opt-in and off by default, and is candid about what it is: “This is a SOFT guard — it advises, not blocks. The edit still proceeds.” So an agent in Discuss can still edit your source. team.management blocks Edit and Write outright until the protocol step changes.
GSD Core installs on nine runtimes. Does team.management?
No — team.management runs inside Claude Code only. If your team works in Cursor, Windsurf, Codex, OpenCode or Kimi, GSD Core covers ground we do not. The engine can call Codex and Antigravity as reviewers, but the process itself runs in Claude Code.
Can I run GSD Core and team.management together?
Technically yes — Claude Code composes hooks from multiple plugins. In practice you would be running two workflow systems with two sets of planning artifacts, .planning/ for GSD Core and team-management/ for us, each with its own idea of what step you are on. Pick one to own the process.
What is context rot, and does team.management handle it?
Context rot is the quality decay that builds up as an agent’s context window fills. It is GSD Core’s headline problem: it runs research, planning and execution in fresh subagent contexts so the main session stays lean. team.management addresses it less directly — protocol steps delegate to subagents with their own windows, and task files carry context across sessions — but it is not the problem the engine was built around.
Facts and figures on this page are as of August 2026, verified against the sources linked inline. If you’re reading this much later — check the sources.
Related comparisons
Other loops that run before the code does, where the discuss-first idea started, and the map of the field.