OrbitOnboard

• 

  OrbitOnboard posts the full contributor starter kit as an issue comment in under 10 seconds. One command, five queries, one comment.

• 

  Two merged MRs link automatically to the issue. The OrbitOnboard starter kit comment appears at the bottom for every developer assigned.

• 

  Reading order from Orbit path finding: the dependency chain from foundational base to implementation. No keyword search produces this.

• 

  One command generates reading order, critical files, expert map, similar MRs, and related issues using the GitLab Orbit knowledge graph.

• 

  All four GitLab Orbit query types in a single workflow. Five parallel queries post a structured starter kit directly to the GitLab issue.

• 

  35 tests pass with no live Orbit connection. Coverage spans all five query types, fallback logic, budget enforcement, and output formatting.

• 

  Similar MRs and related issues complete the starter kit. All five queries run in parallel with total wall-clock time under 10 seconds.

• 

  The only tool using all four GitLab Orbit query types in one workflow: aggregation, path finding, traversal, and neighbors.

• 

  Expert map: who shipped here, not just who committed. AUTHORED traversal ranks contributors by merged MRs in this area of the codebase.

• 

  Five sections, five Orbit query types. Critical files by merge history. Reading order by path finding. Expert map by AUTHORED traversal.

Inspiration

Half of new contributors abandon their first attempt to contribute to an unfamiliar codebase. Not because the problem is too hard -- because the map doesn't exist. Which files matter? What's the reading order? Who owns this area? Figuring that out takes days of spelunking through git history, asking around in Slack, and trial-and-error. That cost is invisible and entirely avoidable.

GitLab Orbit models the codebase as a knowledge graph: MR history, file relationships, contributor patterns, dependency chains. Every answer a new contributor needs is already in there. OrbitOnboard makes it instantly accessible.

What it does

Given a GitLab project and issue IID, OrbitOnboard runs five Orbit queries in parallel and posts a structured Markdown starter kit directly to the issue as a comment -- in under 10 seconds:

1. Reading order -- a path-finding traversal from the implementation file to its foundational dependencies, establishing the bottom-up sequence to read the code. This section is only possible because Orbit models the codebase as a graph. No keyword search or static analysis produces it.
2. Critical files -- ranked by activity-based centrality: MR touch count from the AUTHORED -> MergeRequest -> HAS_DIFF -> File edge chain. History-derived importance, not compile-time analysis.
3. Expert map -- top contributors by merged-MR count in this area. Who shipped here, not just who committed. For InnerSource teams, this breaks the contribution wall: you know who to contact before opening an MR.
4. Similar past MRs -- how analogous problems were solved before.
5. Related open issues -- other work in flight nearby.

How we built it

Python 3.9+ agent using httpx for async Orbit API calls and the GitLab REST API for issue comment posting. A SKILL.md defines query recipes for GitLab Duo. A Custom Agent system prompt (gitlab-agent/system-prompt.md) is published to the AI Catalog so any team can enable it without installing anything.

OrbitOnboard is the only submission that uses all four Orbit query types -- aggregation, path finding, traversal, and neighbors -- in a single coordinated workflow. Most Orbit-based tools use only traversal. Path finding is what makes reading order possible and is the architectural centerpiece of the design.

35 tests, all mocked -- no live Orbit connection required for CI.

Challenges we ran into

Orbit's HAS_FILE edges are sparse on some GitLab instances: the aggregation query returns empty rows when the diff index hasn't fully propagated. Added a fallback traversal query (token_match on File.path) so the critical files section always produces output. Path finding has a server-enforced 3-hop max; the reading order query is designed around that constraint. Fallbacks share the iteration budget slot with their failed primary -- the 5-query hard limit is always respected.

Accomplishments that we're proud of

The path finding approach to reading order -- it was non-obvious, required understanding Orbit's graph model deeply, and it produces output that no other tool can replicate. Using all four Orbit query types simultaneously. The 5-query budget discipline. 35 tests with zero live connections.

What we learned

Orbit rewards thinking in traversal paths, not SQL-style queries. Activity-based centrality from MR history is a fundamentally different measure of file importance than static analysis provides -- it captures which files the team found important enough to change, repeatedly, over time. That insight is only available through the graph.

What's next for OrbitOnboard

• Live integration test against a real GitLab.com project
• Area-based queries (not issue-driven): "orient me on the auth module"
• Auto-trigger on issue assignment via GitLab webhook, so the starter kit appears without any manual invocation
• MR reviewer suggestion at MR creation time

Built With

• api
• click
• gitlab
• gitlab-duo-agent-platform
• gitlab-orbit-api
• httpx
• pytest
• python-3.9
• rest