Files
cline/sdk/AGENTS.md
T
Saoud Rizwan c84da27d09 refactor: rename @clinebot npm scope to @cline (#24)
* refactor: rename @clinebot npm scope to @cline

Rename all package names, dependencies, imports, workflow references,
build scripts, and documentation from @clinebot/* to @cline/* to match
the newly claimed @cline npm organization.

* fix: complete @cline scope rename

* chore: update root lockfile package scope

* fix: update usage cost import scope
2026-05-06 17:01:54 -07:00

4.0 KiB

description, globs, alwaysApply
description globs alwaysApply
Development reference for the Cline SDK workspace. *.ts,*.tsx,*.js,*.jsx,*.json,*.md true

Cline SDK — Development Reference

Quick-reference for active development. For onboarding, workspace setup, publishing, and detailed workflow see CONTRIBUTING.md. For architecture and runtime flows see ARCHITECTURE.md. For API details see DOC.md.

Package Boundaries

Published SDK Packages

  • @cline/shared: shared contracts, schemas, path helpers, hook engine, extension registry, low-level utilities
  • @cline/llms: provider settings/config, model catalogs, provider manifests, gateway contracts, handler creation
  • @cline/agents: stateless agent loop, tool orchestration, hook/extension runtime, event streaming
  • @cline/core: stateful orchestration, session lifecycle, storage, config watching, plugin loading, default tools, telemetry. Exposes @cline/core/hub for discovery, the detached daemon entry, WebSocket clients, and session/UI client adapters, plus @cline/core/hub/daemon-entry for launching the shared daemon

Internal Package

  • @cline/enterprise: enterprise identity adapters, control-plane sync, managed instruction materialization, claims-to-role mapping, telemetry bridging. Composes with core but core must not depend on it. Excluded from root SDK build/version/publish flows.

Dependency Direction

flowchart TD
  shared["@cline/shared"] --> llms["@cline/llms"] & agents["@cline/agents"] & core["@cline/core"]
  llms --> agents & core
  agents --> core
  enterprise["@cline/enterprise"] --> agents & core & shared
  core --> apps["CLI / VS Code / Code App"]

Rules:

  • shared stays low-level and reusable
  • agents stays stateless — no session/storage/config concerns
  • core owns stateful orchestration, including the shared-hub daemon, server, and client adapters under src/hub/
  • enterprise may depend on core, but not the reverse

Change Routing

Route changes to the package that owns the concern:

  • model/provider schemas or handler behavior: @cline/llms
  • stateless loop, tool orchestration, streaming, hook/extension runtime: @cline/agents
  • session lifecycle, storage, config watching, default tools, plugin loading, telemetry, hub runtime services, hub discovery, hub daemon spawn, and session-oriented client helpers (HubSessionClient, HubUIClient, connectToHub): @cline/core (hub pieces live under src/hub/)
  • enterprise identity, control-plane sync, materialization, claims mapping: @cline/enterprise
  • host-specific UX or shell behavior: app package

Verifying Changes

Root commands for cross-package confidence:

bun run types       # typecheck all packages
bun run test        # run all tests
bun run check       # lint + build + typecheck + check-publish

If you touch hub/bootstrap/session flows, please update ARCHITECTURE.md.

Practical Guidance

Keep Boundaries Clean

  • Don't move stateful logic down into agents
  • Don't put app-specific behavior into core unless it is truly shared host behavior
  • Don't let enterprise concerns leak into published core APIs unless they are generic and reusable

Refactor Standard

  • Prefer direct architectural cleanup over compatibility shims
  • Move code to the layer that owns the concern and update all call sites
  • If a helper just projects watcher state, keep it with the config layer instead of creating thin runtime wrappers

Documentation Responsibilities

  • README.md: visitor-facing overview. Update when the repo story or package inventory changes.
  • CONTRIBUTING.md: onboarding, workflow, publishing. Update when contributor setup or release process changes.
  • AGENTS.md (this file): development reference. Update when package boundaries, dependency rules, or change routing changes.
  • ARCHITECTURE.md: design, boundaries, runtime flows. Update when system design or architectural constraints change.
  • DOC.md: API and behavior reference. Update when exported surfaces, lifecycle semantics, or runtime behavior changes.