Documentation
Ribix: product overview
Ribix adds structured bug intelligence to GitHub Issues as a comment on the issue itself. Your team keeps the same workflow; enrichment shows up where people already triage.
Overview
When a new issue is opened, Ribix analyzes the report (errors, stack traces, paths, and context) and combines that with git history signals to produce a single comment: likely cause, similar past issues, severity, and a suggested owner. The goal is to shorten time-to-triage without adding another tool to open.
Who it's for
Teams that file bugs in GitHub Issues and want faster, more consistent triage, especially when many reporters are not the engineers who know the codebase best. Ribix is meant to help on-call, tech leads, and maintainers who read dozens of issues per week.
What each comment includes
- Likely cause: Git blame and history signals pointed at the most plausible causal commit(s) and a short explanation of what changed.
- Related issues: Semantically similar closed issues so you don't repeat past fixes.
- Severity: A P1/P2/P3-style label with plain-English rationale (paths, impact, patterns in your repo).
- Suggested owner: Who last meaningfully changed the affected area, not necessarily the last drive-by commit.
End-to-end workflow
- A new issue is opened in GitHub Issues.
- Ribix receives the event via the GitHub App integration.
- The issue body is parsed for errors, stack traces, and affected paths.
- Git metadata (blame, log) is used to infer likely causal commits and ownership.
- Similar issues are retrieved from your issue history (vector search over issue text).
- Severity and owner signals are merged into one structured comment on the issue.
Integrations
GitHub Issues is the first supported integration (GitHub App). Linear and GitLab are on the roadmap; we prioritize the waitlist and design partners for what ships next. Messaging on the marketing site matches this: GitHub first, others planned.
Permissions & access
The GitHub App installs with a defined set of OAuth scopes and repository access. Before you install in an org, review the permission list shown in the GitHub App installation flow and your org's security policies. You should treat Ribix like any automation that posts to issues: least privilege, audit who installed it, and revoke access when projects wind down.
Data handling
Ribix is designed to work from issue text plus git metadata needed for blame and history, not to clone your repository for arbitrary browsing or to bulk-store full source code for unrelated purposes. What is stored and for how long depends on the deployed product configuration; see the Privacy Policy for this website and waitlist, and expect future product-specific documentation as the GitHub App reaches general availability.
If you need a formal DPA, subprocessors list, or retention schedule for your company, contact us through the support channel you use once it is published on this site.
Accuracy & limits
Enrichments are probabilistic. They can be wrong when the issue is underspecified, when the stack trace points at the wrong layer, or when history is noisy. Use Ribix as a triage accelerator, not a replacement for code review, reproduction, or incident command. When feedback mechanisms (e.g. thumbs-down on the comment) are available, use them so the model can improve for your repo over time.
Setup & rollout
The intended experience is: install the GitHub App, select repositories, and start filing issues. Rollout tips: start with one team or repo, compare enrichment quality on real issues, and agree on how your team will treat severity labels before automating anything downstream.
Legal & support
Site usage and waitlist data are covered by our Privacy Policy and Terms of Service. For product questions, see the FAQ on the home page or join the waitlist for updates.