-
-
App Icon
-
Architecture
-
Intro
-
Github+Slack Thread
Inspiration
Open-source maintainers already have AI triage for GitHub: tools like Dosu index issues, PRs, and docs to help answer questions and catch duplicates. But a project's knowledge doesn't live only on GitHub. In active communities like vLLM's, half of it lives in Slack: bugs reported informally in #help, workarounds shared in passing, decisions made in a thread that never makes it back to the tracker. No GitHub-side tool can see that, because until now, searching a live workspace in real time wasn't something an external agent could do at all. We wanted to build the agent that closes that gap.
What it does
IssueBridge is a Slack agent that treats a project's community workspace as a first-class knowledge source, not an afterthought. When a new issue lands, it checks both halves of the project's memory: the GitHub history via MCP, and the Slack history via Slack's Real-Time Search API. It surfaces duplicates with citations on both sides, for example matching a new issue to a closed one and to a Slack thread where it was already answered. It drafts a cited reply a maintainer can post with one click, and answers ad hoc questions from maintainers directly in Slack, grounded in both sources.
How we built it
Built with Slack's Agent Kit (Python, Claude Agent SDK, Socket Mode) running in a Slack developer sandbox seeded with realistic community conversations modeled on real, closed vLLM issues. GitHub access runs through the official GitHub MCP server for live search against the real upstream vLLM repository; new issues are filed against a fork we control so the demo never touches the real project's tracker. Slack-side retrieval runs entirely through the Real-Time Search API (assistant.search.context), triggered by the action_token from message and mention events. An LLM layer ranks candidates from both sources and drafts the cited response; results render as an interactive Block Kit triage card with one-click actions.
Challenges we ran into
Real-Time Search is a brand-new API with a permissioning model unlike a standard OAuth scope: bot-token calls need an action_token pulled from a live message event rather than a static credential, which took some digging to get right. We also had to design around GitHub's default of disabling Issues on forks, and around the fact that Slack messages can't be backdated, which shaped how we built our seed data to read naturally without contradicting its own timestamps.
Accomplishments that we're proud of
A single agent reasoning across two systems that have never been bridged this way before. Not summarizing one into the other, but treating both as equally authoritative sources with equal citation weight.
What we learned
That the most valuable knowledge in an open-source project is often the least searchable, and that the newest, narrowest-seeming API (RTS) was the one that made an otherwise-crowded space (GitHub triage bots) genuinely open again.
What's next for IssueBridge
Multi-repo support, a weekly digest mode for maintainers who want a pull instead of a push, and, longer-term, a proper Marketplace-distributable version with per-workspace OAuth install, for communities that want this without running their own sandbox.
Log in or sign up for Devpost to join the conversation.