Integrations / Engineering
GitHub + UbiVibe
Connect GitHub so UbiVibe can reflect real engineering activity in what it builds and reports.
GitHub is a live, actively-used UbiVibe connector for teams that want engineering activity reflected in their operator’s view of the business.
Repository and activity data connect through a governed OAuth grant, scoped to what you approve.
Engineering activity is usually invisible in the operating picture. The business sees a roadmap and a weekly status update; the actual state — what merged, what is open, what has been blocked for three weeks — lives in a repository nobody outside the team reads.
The connection is scoped to the organization and repositories you approve, and repository activity becomes one input into the operator’s view of the business alongside revenue, delivery, and support.
It is deliberately one input. A merged pull request is implementation evidence, not proof that a customer outcome was delivered, and the platform is built to keep those two claims separate.
Read the repository for state; require deployment or runtime evidence before calling anything delivered. That separation is the whole design.
The practical test is whether anyone outside the engineering team can now answer a question they previously had to ask. If support can check whether a fix merged, and a quarterly review can cite what actually changed, the connection has paid for itself before anything else it enables.
Set-up stays small. A grant scoped to the repositories that matter, agreement on what your team’s conventions mean by open, reviewed, and merged, and a clear rule that delivery claims require deployment or runtime evidence rather than a merge commit.
Everything below assumes that separation holds. Repository state is treated as reliable and specific; conclusions about customer outcomes are treated as something that has to be evidenced somewhere other than the repository.
How GitHub connects
The problem
What breaks without a GitHub connection.
Without a connection, engineering status is a reporting ritual. Somebody summarizes a repository into a slide once a week — a tax on the team producing it, and stale by the time it is read. The summary also competes for attention with the work it describes, so it gets thinner exactly when the project is hardest and the reporting matters most.
Hand-written summaries drift toward optimism, not because anyone is lying but because the categories are too coarse. "In progress" covers a pull request opened this morning and one that has been waiting on review since the start of the month, and the difference between those two is the entire story.
Cross-functional work absorbs the cost. Support has no cheap way to check whether the fix for a reported issue actually merged, so the question comes back into an engineering channel as an interrupt — repeatedly, for the same issue, from different people, each of whom needs a context switch from someone who was mid-task.
The opposite failure is treating repository activity as outcome. Commit counts and merged pull requests measure motion. They do not establish that anything reached production, and they certainly do not establish that a customer’s result changed.
The useful position sits in between: treat the repository as a reliable source of state — what is open, what merged, what has been sitting untouched — while requiring separate evidence before calling any of it delivered.
The cost of not doing this is paid twice. Engineering pays it in interrupts and in hours spent writing summaries that are stale by the time they are read, and the business pays it by making decisions from a status picture that is smoothed, optimistic, and a week behind whatever is actually in the repository.
You're likely here because
- Engineering status is a weekly manual summary
- Support asks engineering whether a fix shipped
- "In progress" covers everything from a day to a quarter
- Activity metrics get mistaken for delivery
Architecture
How the GitHub connection actually works.
Repository activity is normalized into records the runtime can reason over — and kept explicitly distinct from the deployment or runtime evidence needed to claim delivery.
Step 01
Governed OAuth grant, repository-scoped
You authorize through the governed OAuth path, scoped to the organization and the repositories you approve. UbiVibe does not request access to repositories outside that grant, and the credential is stored against your tenant rather than in application code. Revoking the grant in GitHub ends access immediately, with no separate copy of the authorization left behind.
Step 02
Tenant-scoped connection record
The connection is registered against your team and resolved before every read, so repository access granted by one organization is not reachable from another organization’s workflows. The scoping happens at the connection lookup, ahead of the request — isolation is a property of the read path rather than of each workflow remembering to apply it.
Step 03
Repository permissions are inherited
Reads act within the grant. A private repository outside the approved scope is not visible, and the connector has no privileged path around GitHub’s permission model — what your team can already see is the ceiling. There is no broader credential sitting behind the scenes that a narrowly scoped workflow could end up using.
Step 04
Activity normalized into records
Pull request and repository activity is read through the provider-agnostic connector path and normalized into records the runtime can reason over, cached with a provenance stamp tied to the connection and the read time. Downstream logic works with records rather than raw API responses, so the same question is answered identically from a dashboard, from ARIA, or from a scheduled check.
Step 05
Events can trigger workflows
Repository events flowing through the connector can match configured workflow triggers, so engineering activity can start a downstream process — a notification, a checklist, a follow-up — instead of only appearing later in a report somebody has to remember to read. The trigger is configuration rather than a bespoke webhook handler written per repository.
Step 06
Code evidence stays separate from outcome evidence
The runtime treats "merged" and "delivered" as different claims on purpose. Establishing that something was delivered requires deployment or runtime evidence, which is a distinct signal the connector will not let a merge stand in for. The most common way engineering reporting misleads a business is by quietly counting implementation as delivery.
Workflow examples
What teams can connect through GitHub
Bring repository activity into operational context
Reflect engineering work in reporting and coordination
Connect implementation evidence to broader business workflows
Review-queue age and pull-request ageing reports
Repository events triggering downstream operational workflows
Implementation path
How it gets connected.
- 01
Select the repositories required for the workflow
- 02
Keep access constrained to approved organization and repository scope
- 03
Use repository evidence as one source in the operating picture rather than inferring business outcomes from commits alone
- 04
Agree what open, reviewed, and merged mean under your team’s conventions
- 05
Grant repository-level scope where possible rather than organization-wide access
Controls
Controls that matter.
Control 01
Respect repository permissions
Control 02
Separate code activity from verified production outcome
Control 03
Require deployment or runtime evidence before treating a code change as delivered
Control 04
Keep delivery claims tied to runtime evidence, never to a merge commit
Control 05
Avoid using activity counts as a measure of individual performance
Examples
What this looks like once GitHub is connected.
Shipped, blocked, and stale — without a status meeting
ARIA reports open pull requests by age, what merged since the last review, and what has been waiting on review long enough to be a problem — read from the repository rather than from a summary somebody wrote at midnight. The meeting that remains is about decisions instead of about collecting status.
Support can answer the fix question itself
"Did the fix for that issue merge?" becomes a lookup against repository activity instead of an interrupt into an engineering channel. The same question asked by four people across a week costs one lookup each rather than four context switches for whoever was unlucky enough to be online.
Engineering activity inside the operating picture
A dashboard showing revenue, delivery, and engineering activity together makes the trade-off visible: what the team actually spent the quarter building, sitting next to what the business needed during the same period. That comparison is nearly impossible to make when the two live in different tools with different owners.
A merge that starts the next step
A repository event can trigger a downstream workflow — notify the channel that owns the release, open a checklist, schedule a follow-up. The handoff after a merge stops depending on whether the person who merged it remembered what was supposed to happen next.
Review load made visible
Pull requests waiting on review, and for how long, is a specific and fixable number. Surfacing it turns a vague shared sense that things feel slow into a queue somebody can actually work down, which is a much easier conversation to have than one about velocity.
A record of what actually changed
When a quarter gets reviewed, what merged across the connected repositories is available as evidence rather than as recollection. The retrospective becomes a conversation about decisions instead of an exercise in reconstructing what happened from memory and calendar entries.
Limitations and considerations
What the GitHub integration does not do.
- Scope is bounded by the OAuth grant and GitHub’s own permissions. Repositories outside the approved organization and repository scope are not readable, and the connector does not escalate around that.
- A merged pull request is implementation evidence, not a proven customer outcome. Claims about delivery require deployment or runtime evidence that GitHub alone does not provide.
- Activity volume is a poor proxy for value. Commit and pull request counts measure motion, so the integration is built to surface state and exceptions rather than to rank people by output.
- Reads are cached and incremental, so very recent activity can lag by the configured window. For a question that turns on the last few minutes, check GitHub directly.
- GitHub API rate limits apply to the connected account or app. Broad scans across many repositories are batched and can take longer than an interactive question allows.
- Repository content is sensitive. Scope the connection to the repositories a workflow genuinely needs rather than granting organization-wide access because it is simpler at setup time.
- The scope you approve is the scope of exposure. Private repository content is readable within the grant, so grant per repository wherever the workflow allows it rather than defaulting to the whole organization.
- Branch, review, and merge conventions differ between teams. What counts as done in your repository is a convention the connector reads rather than one it defines, so reporting reflects your process rather than an assumed one.
FAQ
GitHub integration FAQ
Can UbiVibe connect to GitHub?
Yes. GitHub is a supported governed connector for approved repository and activity context.
Does a merged PR count as a proven customer outcome?
No. A merged code change is implementation evidence; production and customer outcome claims require their own runtime evidence.
Which repositories can UbiVibe read?
Only the repositories covered by the OAuth grant you approve. The connector inherits GitHub’s permission model and has no privileged path to repositories outside the approved organization and repository scope.
Can repository activity trigger a workflow?
Yes. Repository events flowing through the connector can match configured workflow triggers, so a merge or an update can start a downstream process rather than only appearing later in a report.
Does UbiVibe write to my repositories?
The integration is oriented around reading repository and activity context. Any supported action runs through the governed connector path, bounded by the grant you approved and by the workflow’s approval configuration.
What happens if the GitHub connection breaks?
Expired or revoked credentials surface as connector health rather than as silently missing activity, so a report does not quietly become incomplete without anyone noticing that the source stopped responding.
Related pages
Other integrations and related pages
How this access is governed
What ARIA is allowed to do in GitHub, and who decides.
Connecting GitHub is a permission decision, not just a setup step. These are the controls that decide what ARIA can reach, what it can change, what gets recorded, and how you take the access back.
Required permissions
ARIA works through the scopes the connection was granted, and no others. Authorization happens at the provider, so the permissions being requested are shown by the system itself before anything is connected.
What it can reach
Reachable systems are the intersection of what your organization approved in the connector registry and what the requesting identity is permitted to use. Identity resolves before execution, not after.
What it can do
Actions run through explicit execution paths with state, spend, and failure boundaries — a bounded worker path rather than an open-ended agent loop with a credential.
Credential handling
Credentials live in the governed connection layer and are resolved through canonical connection identity. They are not pasted into individual workflows, prompts, or generated artifacts.
Action logging
Execution carries state and traces: what triggered the work, which connection it used, and what came back — including an explicit failure when something did not run.
Approval and revocation
Consequential actions can be made to require a person to approve them. Access can be changed or revoked at the connection, and ARIA loses that reach without unpicking the work already completed.
Start with ARIA
Ask ARIA to work in it.
Describe what should happen in this system. ARIA connects through scoped credentials you control, takes only the actions you permit, records what it did, and can require your approval before consequential changes.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
See it connected to your github
Start on the public ARIA path before creating an account. Describe what you want built or operated, confirm ARIA’s interpretation, and continue into the right product from there.