The disconnect between code and project management is one of engineering's oldest inefficiencies. An engineer fixes a bug, closes the PR, and then has to go open a separate app to mark the issue as done. Half the time, they forget. The issue stays open. The backlog is a lie.
Lumos's Git integration is designed to eliminate this gap entirely.
What the Integration Does
When you connect Lumos to GitHub (or GitLab, or Bitbucket), the two systems stay in sync automatically:
Branch naming → issue linking
Name your branch with the issue ID — lumos-1234-fix-auth-timeout — and Lumos automatically links that branch to the issue. No extra steps, no copy-pasting URLs.
PR creation → issue status update
Open a PR and the linked issue moves to In Review automatically. Your team lead sees the issue is being worked on without asking.
PR merge → issue closure
Merge the PR and the issue closes. Move the next one. Done.
Commit references
Include LUM-1234 in any commit message and Lumos adds that commit to the issue timeline. The full history of how an issue was addressed — every commit, PR, review comment — lives in one place.
Why This Matters
For engineers: Less context-switching. You live in your editor and terminal. Lumos updates itself.
For engineering managers: Real progress, not self-reported progress. When an issue is In Review, there's an actual PR to prove it.
For PMs: Accurate status without attending standups. The roadmap reflects reality because the reality is being updated automatically.
For on-call teams: When a production incident fires, you can see which issues are related to the affected code areas instantly. Recent changes, recent PRs, recent authors — all surfaced in the incident record.
Setting Up the Integration
# In your Lumos workspace:
Settings → Integrations → GitHub → Connect
# Or via CLI:
lumos integrations connect githubOnce connected, Lumos creates a GitHub App in your org with the minimal permissions needed: read access to branches/PRs, write access to check runs. We never read your source code.
Branch Naming Convention
The default format is:
lumos-{issue-id}-{short-description}
But you can configure your own convention. Many teams prefer:
{team-slug}/{issue-id}-{description}
# e.g. platform/LUM-892-redis-pool-refactor
Set this in Settings → Git → Branch Format.
Auto-close Triggers
By default, merging to main closes the linked issue. You can configure different behaviors:
- Merge to main: Close issue ✓ (default)
- Merge to release branch: Move to "Ready for Release"
- Merge to staging: Move to "In Testing"
This maps perfectly to teams that use GitFlow or trunk-based development with release branches.
The Bigger Picture
Individual automation steps are useful. But the real value is what happens when they compound:
A new issue gets triaged by Lumos AI → assigned automatically → picked up by an engineer → branch created → PR opened → reviewed → merged → issue closed → cycle velocity updated → engineering manager's weekly report generated.
Every step happens without a human touching a project management tool. The engineers stay in their flow. The data stays accurate. The team ships faster.
That's the loop Lumos closes.
