team.management vs cc-sessions.
cc-sessions pioneered the idea team.management is built on: DAIC modes enforced by hooks, not prompts. It has been dormant since October 2025; team.management carries the same DNA forward — credited on our landing page — as a maintained, full protocol engine.
What cc-sessions is
cc-sessions (GWUDCAP) is the opinionated Claude Code harness that proved the core mechanism: block Edit/Write in discussion mode with a hook, flip modes on explicit trigger phrases, keep tasks in files, enforce git discipline. Modest in stars (≈1.5k) but big in influence: it proved that runtime gating works, and a generation of “make Claude behave” tools followed.
As of July 2026 the repository is dormant: last commit October 17, 2025. For a tool whose value lives in hooks tracking a fast-moving harness, dormancy is the one status that matters.
What team.management is
team.management carries cc-sessions’ core insight — gate the tools, not the prompts — into a maintained, open-source engine: named protocols sequence whole lifecycles, the PreToolUse hook sets the mode per step (the DAIC loop), and every task gets a branch, a work log, and an audit trail.
The difference — a mechanism vs an engine
cc-sessions is the mechanism: DAIC gating plus conventions. team.management builds it out: a protocol engine (over MCP) that sequences whole lifecycles — task, brainstorm, research, refactoring, optimize — sets the DAIC mode per step, manages branches and task state, runs gated code review with optional Codex/Antigravity reviewer panels, writes audit logs, and syncs issues with GitHub/GitLab/Jira. If you liked cc-sessions, nothing needs unlearning — the concepts are the same, held by an engine instead of by convention.
The limit is inherited too: hooks bind the agent, never the operator. That was the original design’s point, and it still is.
| cc-sessions | team.management | |
|---|---|---|
| Status (July 2026) | Dormant — last commit 2025-10-17 | Actively developed |
| DAIC gating | Yes — the original implementation | Yes — inherited, set per protocol step by the engine |
| Workflow model | Conventions + trigger phrases | Named protocols with step state, goto, and audit logs |
| Beyond the loop | — | AI-provider review panels, issue tracking, notifications, wiki |
| Task management | Hand-maintained task files | Engine-created tasks, branches, status transitions |
| Repository | github.com/GWUDCAP/cc-sessions | github.com/TeamManagementPlugin/claude-plugin |
| Price & license | Free, open source | Free, MIT |
When cc-sessions is still the right call
If you want the smallest possible thing that gates tools by mode — a few hooks you can read in an afternoon and own outright — cc-sessions still delivers exactly that, dormancy accepted. If you want the idea maintained and grown into a team-grade engine, that is why team.management exists. cc-sessions is credited on the landing page: team.management started from its idea.
FAQ
Is cc-sessions abandoned?
As of July 2026 it appears dormant: the last commit landed October 17, 2025. It still works as published, but there’s no active maintenance to track Claude Code’s changes — which, for a hooks-based tool, matters.
Is team.management a fork of cc-sessions?
It’s a descendant in design rather than a fork: the DAIC discussion/implementation gating, task files, and git discipline carry over as concepts. Around them team.management adds what cc-sessions never had — an MCP protocol engine with multiple named protocols, step state and audit logs, AI-provider review panels, issue tracking, notifications, and a wiki system.
I use cc-sessions today — what does migrating look like?
Install the team.management plugin, run its init, and your working habits mostly transfer: discussion-first remains the default, trigger-phrase-style alignment becomes protocol steps. Task files are created by the engine per task rather than by hand. The enforced feel of DAIC is the same — that’s the inherited part.
Facts and figures on this page are as of July 2026, verified against the sources linked inline. If you’re reading this much later — check the sources.