context-intelligence-gds

name	context-intelligence-gds
description	Use when an analysis over the context-intelligence graph is about to be written as naive Cypher — reach for Neo4j GDS (Graph Data Science) or APOC instead when the question is really a complex topology search: pathfinding, reachability, centrality/influence, community/clustering, topological/structural similarity, or finding similar event PATHS / trajectories (with or without a time dimension). Names the advantages of the graph-data-science package and the best-fit scenarios for it, so you stop hand-rolling traversals and re-deriving structure one hop at a time. This is the WHEN/WHY layer; the graph-query skill's "Push Work to the Database" section is the HOW.
license	MIT
metadata	{"version":"1.2.0","changelog":["1.2.0: Lifted patterns from a real graph exploration — TF-IDF weighting to defeat glue-tool dominance in similarity; read-only vector-property gds.knn fallback (no bipartite edges); a derived co-occurrence/teaming projection (distinct from the edge-less Agent-node dead end); apoc.map.fromPairs/apoc.coll.sort as a fourth primitive (in-graph frequency map); a read-only .stream/.stats vs .write/.mutate guardrail; and a 'When GDS itself isn't enough' boundary (structure vs intent → escalate to LLM embeddings).","1.1.0: Added the 'Complex topology searches' section — centrality, topological/structural similarity (nodeSimilarity/KNN/FastRP embeddings), and similar event PATHS / trajectories with-or-without a time dimension (set-similarity vs transition-signature), plus pathfinding and a non-lineage projection recipe. These are the hard searches the skill exists to route off naive Cypher.","1.0.0: Initial — GDS/APOC scenario-selection and advantages, avoid-naive-Cypher decision map, three reusable primitives tuned to this graph."]}

Context Intelligence — Graph Data Science First

The context-intelligence graph is large (millions of nodes across thousands of sessions). Naive Cypher tends to re-derive, one hop and one round-trip at a time, what a graph algorithm computes in a single server-side pass. This skill trains the reflex: recognize the shape of the question, and when it is a graph-algorithm shape, reach for GDS or APOC instead of improvising Cypher.

This skill is WHEN and WHY. The HOW lives next door. The graph-query skill owns the schema meaning, the traps, and the worked projection queries — its Section 8, "Push Work to the Database (APOC / GDS)" has the concrete gds.graph.project → algorithm → gds.graph.drop lifecycle and the Session/FORKED + agent-rollup example. Load context-intelligence-graph-query for mechanics; use this skill to decide whether the algorithm is the right tool at all.

---

The naive-query smell test

You are probably about to write naive Cypher where GDS/APOC would be better if you catch yourself doing any of these:

• Guessing edge types to walk a tree (-[:HAS_SUBSESSION|FORKED|HAS_FORK]->) or repeatedly stepping Session.parent_id one hop at a time to rebuild a delegation tree.
• collect() then size([x IN … WHERE …]) to count how many things are reachable / match — reconstructing an algorithm's output by hand.
• A giant WHERE node_id IN [ …50 literals… ] pasted into the query text (client-side set-building shoved into Cypher).
• UNWIND range(0, size(list)-2) to compute consecutive gaps / pairwise math.
• Variable-length -[*1..n]-> followed by client-side filtering of the paths.
• Pulling many rows to the client to iterate and aggregate what the DB could reduce.

Each of these is a tell that the question has a graph-algorithm shape.

---

What the graph-data-science package buys you (the advantages)

Advantage	Naive Cypher	GDS / APOC
One pass, not many round-trips	N queries + client stitching