Skip to main content

ADR-014 — Extract claude-kit to a standalone public repo (cckit)

canonical · tech-lead · updated 2026-06-28 · source

  • Status: Accepted
  • Date: 2026-06-28
  • Owner: Tech Lead
  • Related issue: #1087 (effort), #1088 (this ADR — the decision gate)

Context

  • The dev-workflow kit (the scripts/kit dispatcher + scripts/lib/*.sh bundle, the .claude/ skills/rules/hooks/agents, the orchestrate scripts, the kit-ui TUI) has lived inside the tedos monorepo and shipped to other projects only as a de-tedos-ified plugin (packages/claude-kit-plugin/, distributed via /kit-update from tedos@develop). Prior calls locked this: no separate kit repo — kit lives in tedos, contributions are tedos PRs, and the global-only direction kept the marketplace pointed at tedos@develop.
  • That coupling now costs more than it saves. The kit is agent-agnostic by design (Claude Code first-class, but drivable by any agent), its release cadence is independent of tedos's product work, and adopting projects (tedos, NTS, future clients) want a clean, public, versioned CLI — not a plugin lensed out of a private product monorepo. Keeping it in-tree blocks a real OSS surface, a proper auto-release, generated docs, and an AGENTS.md-driven multi-agent contract.
  • The plugin fork (packages/claude-kit-plugin/) already proved the de-tedos-ification — it is the head start for a true extraction, not a substitute for it.

Decision

Extract the whole claude-kit out of tedos into a standalone public monorepo jeiemgi/cckit, stripped of tedos, installed globally as the cckit CLI, auto-released, documented, and drivable by any agent. This reverses the "no separate kit repo / kit lives in tedos" decision.

  • Repo: jeiemgi/cckit, public. Config file cckit.config.json. Branding is cckit's own (no tedos identity; the CLI asks the user their name — identity is agnostic).
  • Done = the bash kit is migrated (dispatcher + lib bundle + orchestrate/autopilot, driven from cckit.config.json, structured --output). Migrating the consumer projects (tedos, NTS) is a separate, deferred effort — this ADR does not cut tedos over.
  • Release: auto-on-merge to main (conventional-commits bump → tag → GitHub Release) + re-deploy of the Astro Starlight docs (TSDoc/TypeDoc API + copy-ready LLM blocks + a workflows cookbook).
  • Agents: agent-agnostic contract (AGENTS.md + cckit <verb> --llm), Claude Code first-class; TUI is a thin viewer over native tools; deps auto-detect with a pure-bash fallback; autonomy is on-demand.
  • Scope boundary: the ADR lives in tedos knowledge/decisions/adrs; everything else is built in jeiemgi/cckit. Cutting tedos/NTS to consume cckit is out of scope (deferred).

Consequences

Positive

  • A clean, public, versioned, auto-released CLI with its own docs and OSS surface.
  • Kit release cadence decouples from tedos product work; contributions land in cckit, not tedos PRs.
  • Agent-agnostic contract unblocks driving the kit from Codex/Copilot/Antigravity/custom agents.

Negative / trade-offs

  • Two repos to keep in sync until the consumers are migrated; a transition window where tedos still carries the in-tree kit AND cckit exists (drift risk — mitigated by deferring, not duplicating).
  • The /kit-update-from-tedos@develop channel is now legacy; the cutover is a follow-up effort.

Follow-ups required

  • Migrate tedos + NTS to consume cckit (separate deferred effort — supersedes the global-only plan [[kit-global-only-nts-adoption]]).
  • Retire packages/claude-kit-plugin/ distribution once cckit is the source of truth. Done (#1113, 2026-07-02): packages/claude-kit-plugin/, .claude-plugin/marketplace.json, the plugin-autobump workflow, and kit-bump-version.sh are removed. The update channel is cckit: git -C <cckit checkout> pull (the global cckit binary is a symlink into it) + cckit init --upgrade to refresh a project's .claude/ under the keep-local manifest. /kit-update from tedos@develop is dead; .claude/statusline.sh now resolves the cckit install instead of the plugin cache. Adoption of the full lifecycle: effort #1122.

Alternatives considered

OptionWhy not
Keep kit in tedos (status quo, ADR-013-adjacent)Blocks OSS surface, independent release, agent-agnostic contract; couples kit cadence to product
Global-only plugin from tedos@develop ([[kit-global-only-nts-adoption]])Still lensed out of a private product monorepo; no public versioned CLI, no auto-release/docs
Publish the plugin to a registry without its own repoNo home for issues, CI, release, docs, or the agent contract; a registry artifact is not a project

References

  • Effort #1087 (parent issue) + native sub-issues #1088–#1104.
  • Prior decisions: kit-lives-in-tedos / no-separate-repo, kit-global-only (decisions/log.md).
  • ADR-013 — knowledge SoT is the monorepo (per-project, self-owned).
  • TOON format (https://github.com/toon-format/toon); Charm gum/glow; Astro Starlight.