Cypher To Helix Queries
Translate Cypher into Helix Rust DSL by mapping patterns into explicit anchors, traversals, predicates, and return shaping.
When To Use
Use this skill when the task is to:
- translate a Cypher query into Helix Rust DSL
- port a Neo4j query into a stored Helix route
- replace , , , , , , , , , , , or with Helix DSL equivalents
- explain how a Cypher graph pattern should be expressed in Helix Rust
Do not use this skill as the main guide for Gremlin, SQL, or dynamic inline-query JSON.
First Steps
Before translating:
- Inspect the local repo for real labels, edge labels, property names, and route style.
- Parse the Cypher into anchors, edge directions, hop depth, filters, return shape, ordering, and pagination.
- Decide whether the target route is read or write.
- Identify optional branches, per-element writes, null or existence checks, and timestamp usage.
- Identify any Cypher constructs that need semantic rather than literal translation.
If the local repo does not already contain an obvious Helix pattern, use:
examples/authoring-patterns.md
examples/search-patterns.md
Translation Workflow
1. Choose The First Anchor
Translate the first practical Cypher node pattern into the narrowest Helix anchor you can justify.
Prefer:
- node ID or edge ID
- unique property lookup
- equality-indexed property lookup
- scoped label scan
- broad label scan
2. Translate Edge Direction Explicitly
Cypher pattern direction should map directly:
- to
- to
- to
- undirected or symmetric traversal usually to or when the schema and task justify it
3. Translate WHERE Into Predicates
Typical mappings:
- equality to
- numeric comparisons to , , ,
- membership to
- null checks to
- property-existence checks to
- compound logic to
Predicate::and(vec![...])
and
4. Translate RETURN Into Explicit Output Shaping
Use:
- for intentional fields
- when a looser property map is acceptable
- for counts
- for
- , , , and for result ordering and pagination
5. Handle Non-1:1 Cypher Features Carefully
Do not force literal translations for:
Translate them semantically instead.
Key Cypher Rules
MATCH
usually becomes one or more
bindings plus explicit traversal steps.
WHERE
becomes explicit predicate calls. Keep parameter names aligned with the user's query or local route conventions.
RETURN
should become a deliberate Helix result shape, not an implicit full-object dump unless the route truly wants that.
DISTINCT
Use
before shaping or returning results.
MERGE
There is no single drop-in
translation pattern in this skill. Use explicit read-first branching with
.
OPTIONAL MATCH
Use
when a related traversal should not eliminate the root path just because the optional branch has no match.
CASE WHEN
Use
for traversal-level if/then/else logic.
UNWIND And FOREACH
Use
when a write route needs to iterate an array parameter and perform graph work per element.
Multi-Hop Patterns
Use bounded
repeat(RepeatConfig::new(...).times(N).emit_after())
for Cypher patterns like
.
IS NULL And Property Existence
Use
for null-style checks and
when the query is really testing whether the property exists.
Server-Side Timestamps
Use the server-side timestamp helper from your current Helix build when translating Cypher
usage.
Canonical Example
Cypher:
cypher
MATCH (u:User {userId: $userId})-[:FOLLOWS]->(v:User)
WHERE v.status = $status
RETURN v
ORDER BY v.createdAt DESC
LIMIT $limit
Helix Rust DSL:
rust
read_batch()
.var_as(
"user",
g().n_with_label("User")
.where_(Predicate::eq_param("userId", "userId")),
)
.var_as(
"results",
g().n(NodeRef::var("user"))
.out(Some("FOLLOWS"))
.where_(Predicate::eq_param("status", "status"))
.order_by("createdAt", Order::Desc)
.limit(Expr::param("limit"))
.project(vec![
PropertyProjection::new("$id"),
PropertyProjection::new("userId"),
PropertyProjection::new("name"),
PropertyProjection::new("status"),
PropertyProjection::new("createdAt"),
]),
)
.returning(["results"])
Anti-Patterns
Do not:
- translate Cypher by string substitution alone
- ignore edge direction
- preserve Cypher variable names if they conflict with the local Helix route style and make the translation worse
- assume every Cypher clause is a single-token replacement in Helix
- return every property by default just because the Cypher query returned a node variable
- invent labels, properties, or edge names instead of reading the target schema
Validation Checklist
Before finishing:
- verify the first anchor is correct and narrow enough
- verify edge directions are translated correctly
- verify clauses became explicit logic
- verify optional traversals use when required
- verify multi-hop traversal uses bounded with explicit emission behavior
- verify became an intentional Helix output shape
- verify , , , and were mapped deliberately
- verify , , , delete, and timestamp logic were translated to Helix-native constructs when present
- verify was translated semantically, not literally
- verify labels, edge labels, and properties match the local repo exactly
Repo References
For shared references in this repo, see:
examples/authoring-patterns.md
examples/search-patterns.md