Query the GitLab Knowledge Graph (Orbit) via `glab orbit remote` CLI subcommands or run a local copy with `glab orbit local`. Use for code-structure questions (who calls this function, where is this symbol defined), cross-project dependency and blast-radius analysis, merge-request and contributor queries that require relationship traversal or aggregation, repository map / repo-map generation, and any question spanning relationships, cross-entity joins, or multi-entity aggregation across GitLab entities (projects, users, MRs, issues, pipelines, files, definitions, vulnerabilities). Do not use for single-entity GitLab lookups or write operations that `glab` handles directly (e.g. `glab mr view`, `glab mr create`).
73
92%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No known issues
Query the GitLab Knowledge Graph (product name Orbit) via the typed
glab orbit remote CLI subcommands (shipped in glab v1.94.0+). The typed CLI
handles the Content-Type header, response framing, and exit codes for you —
always go through glab orbit remote.
If glab orbit commands fail (command not found, auth errors, feature-flag
exit codes), work through the first-run setup checklist in
references/prerequisites.md.
glab orbit remote --help and glab orbit remote query --help are the
authoritative usage references. For entity properties, prefer the recipes in
references/recipes.md over schema introspection —
they already encode the columns and filters known to work.
If you must introspect, call glab orbit remote schema <Entity…> with explicit
entity names — always pass the entity names you need rather than the unscoped
form, which returns ~17 KB+ of output. Call schema at most once per session;
schemas don't change mid-session. Use glab orbit remote dsl for the full DSL
JSON Schema. Note that per-node outgoing_edges/incoming_edges are arrays
of strings (edge type names), not objects — use --jq accordingly (e.g.
schema Project --jq '.nodes[] | select(.name=="Project") | .properties').
Each glab orbit remote query has fixed per-call overhead. Prefer one
aggregation query over N traversal queries for "how many X grouped by Y", and
batch related lookups.
When editing Orbit docs or skills, fence executable query JSON as
json orbit-query so docs smoke tests run it.
Write the request body to a file and pass it to glab orbit remote query.
Default output is llm (compact, agent-friendly); pass --format raw to pipe
into jq. Endpoints are user-scoped — do not pass -R owner/repo.
Put the request body in /tmp/q.json:
{
"query": {
"query_type": "traversal",
"nodes": [
{"id": "p", "entity": "Project",
"filters": {"id": {"eq": 278964}}},
{"id": "mr", "entity": "MergeRequest",
"columns": ["iid", "title", "state"]}
],
"relationships": [
{"type": "IN_PROJECT", "from": "mr", "to": "p"}
],
"order_by": "-mr.created_at",
"limit": 5
}
}glab orbit remote query /tmp/q.jsonfilters is an object keyed by property name — not an array. Use either
shorthand equality ({"state": "opened"}) or the operator form
({"iid": {"eq": 1216}}). Operators: eq, gt, lt, gte,
lte, in, contains, starts_with, ends_with, is_null, is_not_null,
plus text-token operators (token_match, all_tokens, any_tokens) for
text-indexed properties — see query_language.md.
All queries declare node selectors in the nodes array — a 1-element array
for neighbors and single-node traversal; multi-node traversal,
aggregation, and path_finding add relationships.
relationships[].max_hops (and
optionally min_hops). Default 1, max 3.path.max_depth inside the required
path sub-object. Max 3. max_hops does not apply to path_finding.
When endpoints use filters, include path.rel_types to bound fan-out;
path_finding follows edges only in their schema direction (see
recipe pitfall).Read references/recipes.md before constructing a
query — the same question often has one canonical paste-ready shape and several
wrong-looking-correct ones. Four traps recur:
Pipeline.source = "merge_request_event". Both Pipeline.merge_request_id and the
MergeRequest --TRIGGERED--> Pipeline edge return parent and downstream
child pipelines (source = "parent_pipeline"). Apply the
source = "merge_request_event" filter (or the
canonical recipe)
to match the MR Pipelines tab.Project +
MergeRequest + Pipeline when you already know merge_request_id) can
change the row shape and skew aggregation counts. If recipes.md shows a
single-node form, use it.HAS_LATEST_DIFF vs HAS_DIFF for file history. HAS_LATEST_DIFF
points only at the most recent diff snapshot of an MR. "Every MR that ever
touched this file" needs HAS_DIFF (all snapshots) — HAS_LATEST_DIFF here
can substantially undercount long-lived files. See
recipe.WorkItem entity, not
Issue. Modern GitLab unifies these under work items, and Orbit follows the
same model: there is no Issue node, so entity: "Issue" is rejected. Query
WorkItem for any of them (see
recipe).A single user question should resolve in at most 5 query attempts. Tweaking
only limit/columns is not progress; changing entity, relationship type, or
a filter is. Validation errors (HTTP 400) count toward the budget. If you
exceed 5 without converging, give up loudly: report the shapes you tried,
what failed, and the next step — do not keep iterating or inflate a partial
answer. Full rules:
references/troubleshooting.md.
Orbit answers are graph queries against ClickHouse, not an authoritative source
of truth. Always surface known coverage gaps inline (e.g. HAS_LATEST_DIFF
vs HAS_DIFF, time-bounded aggregates) and show the query body so the user
can audit it. Do not add a "Methodology" header that implies rigor the data
lacks. Full guidance and worked examples:
references/reporting.md.
For code-structure orientation before planning a change, use a repo-map helper:
the native local command glab orbit local repo-map for an
uncommitted/branch-local checkout, or the bundled remote helper script (path
relative to this skill root, not the user's current repo) for a project already
indexed in Orbit Remote. See the repository-map rows in
References below.
glab orbit local downloads and runs a managed Orbit CLI binary for indexing
and querying a local copy of the Knowledge Graph (macOS/Linux only,
x86_64/aarch64). Prefer it over glab orbit remote when indexing a local
repository for offline analysis; use remote to query production. Install/run
with glab orbit local (add --install or --update). Full config keys and
pass-through args: references/local_cli.md.
| Topic | Location |
|---|---|
| First-run setup checklist (install, auth, feature flag) | references/prerequisites.md |
| Full DSL reference | references/query_language.md |
Paste-ready bodies per query_type | references/recipes.md |
| Reporting results & coverage caveats | references/reporting.md |
Local repository map command (glab orbit local repo-map) | references/local_repo_map.md |
| Remote repository map helper | references/remote_repo_map.md |
| CLI exit codes (1-5), errors, iteration budget | references/troubleshooting.md |
| Local CLI flags, config keys & pass-through args | references/local_cli.md |
| Maintaining this skill (contributing, doc sync) | references/maintaining.md |
78fa8a1
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.