Use when the user needs something that ships outside cognee core — community database adapters (Qdrant, Milvus, Weaviate, Redis, Pinecone, FalkorDB, Memgraph, DuckDB, NetworkX, …), data-source connectors (Slack, Gmail, Notion, Confluence, Google Drive), custom tasks/pipelines/retrievers (Exa, ScrapeGraph, codify), Keywords AI observability — or wants to contribute a package to the cognee-community repo.
Community-maintained plugins live in a separate monorepo:
https://github.com/topoteretes/cognee-community. Everything installable is
under packages/; experimental/ holds demos (n8n nodes, dlt demos,
bauplan, tower) that are not published packages. Each package publishes to
PyPI as cognee-community-<family>-<kind>-<name> and imports as the same
name with underscores.
| Family | Packages |
|---|---|
| Vector adapters | azureaisearch, milvus, moss, opengauss, opensearch, pinecone, qdrant, redis, singlestore, turbopuffer, valkey, weaviate |
| Graph adapters | arcadedb, memgraph, networkx, pggraph, spanner, turbopuffer, turingdb |
| Hybrid (graph+vector in one DB) | arcadedb, duckdb, falkordb, helixdb |
| Connectors (data sources) | confluence, gmail, google-drive, notion, slack |
| Tasks / pipelines / retrievers | codify_tasks, codify_pipeline, code_retriever, exa_tasks, scrapegraph_tasks |
| Observability | keywordsai (MONITORING_TOOL=keywordsai + KEYWORDSAI_API_KEY) |
Install, then import the package's register module before cognee touches
any engine — registration is what makes the provider name valid:
uv pip install cognee-community-vector-adapter-qdrant
import cognee
from cognee import config
from cognee_community_vector_adapter_qdrant import register # noqa: F401
config.set_vector_db_config({
"vector_db_provider": "qdrant",
"vector_db_url": "http://localhost:6333",
"vector_db_key": "...",
"vector_dataset_database_handler": "qdrant", # only if the adapter ships one
})
The register.py calls use_vector_adapter(name, AdapterClass) /
use_graph_adapter(...). Setting VECTOR_DB_PROVIDER/GRAPH_DATABASE_PROVIDER
to a community name without the register import raises "Unsupported
vector database provider". Hybrid adapters (e.g. falkordb) register as both
graph and vector — set both configs to the same provider name.
Multi-tenancy caveat: with ENABLE_BACKEND_ACCESS_CONTROL=true (the
default), both backends must have a dataset-database handler or cognee raises
EnvironmentError. Community adapters that ship one (registered via
use_dataset_database_handler in their register.py): qdrant, moss,
singlestore, turbopuffer (vector + graph), falkordb, arcadedb, helixdb. All
other community adapters need ENABLE_BACKEND_ACCESS_CONTROL=false.
Connectors expose a dlt source you hand straight to remember(); they
reuse core's DLT ingestion path, so snapshot sync and forget-on-delete work
with no core changes:
from cognee_community_connector_slack import slack_export_source
await cognee.remember(
slack_export_source("/path/to/slack-export"),
dataset_name="team-slack-export", # use a dedicated dataset
max_rows_per_table=0,
)
Same shape for gmail ("ask my inbox"), notion, confluence, and google-drive (incremental, forget-on-delete). Each package README documents its credentials; always give a connector its own dataset.
Every package has examples/example.py (run uv run python examples/example.py
from the package dir) and a tests/ directory. An LLM API key is still
required (LLM_API_KEY, OpenAI by default).
main — unlike the core repo, cognee-community does not
use a dev branch.packages/<family>/<name>/
with pyproject.toml, a README.md (install + usage), examples/example.py,
and tests/ that go beyond the example.VectorDBInterface / GraphDBInterface from
core, expose a register.py, and should run the shared conformance tests
in packages/shared/contract_suite/ (vector_contract.py / graph_contract.py).use_dataset_database_handler(...) if the backend can
isolate per user+dataset — that's what makes it work with access control on.cognee-community-<family>-<kind>-<name> and add it to the tables
in the repo README. Lint config is the repo-root ruff.toml.Copy a source-pinned command for your client. You run it yourself.
Destination: .claude/skills/cognee-community · pinned to the source commit
# Run from your project root
git clone https://github.com/topoteretes/cognee.git .skillboard-tmp
git -C .skillboard-tmp checkout 690c0ec023719a2a277dc893cdecfec1ca8012cc
mkdir -p ".claude/skills"
cp -r ".skillboard-tmp/.claude/skills/cognee-community" ".claude/skills/"
rm -rf .skillboard-tmpReview the source before running. This copies files into your project; it is not a one-click install and does not verify runtime safety.
sudo apt update && sudo apt install -y gitnpm install -g @anthropic-ai/claude-code# Run from your project root
git clone https://github.com/topoteretes/cognee.git .skillboard-tmp
git -C .skillboard-tmp checkout 690c0ec023719a2a277dc893cdecfec1ca8012cc
mkdir -p ".claude/skills"
cp -r ".skillboard-tmp/.claude/skills/cognee-community" ".claude/skills/"
rm -rf .skillboard-tmpDestination: .claude/skills/cognee-community
Scanner static-checks@0.1.0 · commit 690c0ec02371. Static checks cannot prove runtime safety – review the source and the exact diff before installing. How checks work.
References credentials, tokens or secret files that a skill should not need.
Evidence: [redacted]· fingerprint ccae6d912a41bfef
Instructs shell/process/package operations that run commands on the host.
Evidence: pip install· fingerprint 7944ec554efca445