Contributing

CLDK extends along two clean axes, and they’re independent. Understanding the split is the whole game.

flowchart LR
    subgraph Backends["Backends: emit canonical JSON"]
      direction TB
      G["codeanalyzer-go<br/>(new!)"]
      J["codeanalyzer-java"]
      P["codeanalyzer-python"]
    end
    subgraph Frontends["Frontends: consume canonical JSON"]
      direction TB
      PY["Python SDK (cldk)"]
      RS["Rust SDK<br/>(planned)"]
    end
    Backends -->|typed JSON| Frontends

• A backend teaches CLDK to understand a new language. It parses source, builds a symbol table and call graph, and serializes them to the canonical JSON schema. Backends are standalone tools (the codeanalyzer-* family) and can be written in whatever language suits the analysis: Java analysis in Java, Python analysis in Python, and so on.
• A frontend is an SDK that consumes that JSON and exposes an ergonomic analysis API. Today there’s one frontend: the Python SDK. A second (Rust) is on the roadmap.

Add a backend and every existing frontend can analyze the new language. Add a frontend and it inherits every existing backend.

There's a skill for this

The maintainers use the cldk-language-pack skill to scaffold a new language end-to-end. These guides instead walk the manual path (the same stages, done by hand) so you understand every moving part.

Guides

Add a language backend (Go) A full, manual walkthrough: build codeanalyzer-go (schema, symbol table, call graph, CLI) and wire the Python SDK frontend.

Add a Rust frontend Stub / roadmap: a second SDK, in Rust, that consumes the same canonical backends.