Bootstrap: Triaging Open Source with Agents

October 15, 2026· {readingTime} min read -->

There are 230 open issues and PRs on the Bootstrap repository, a quarter of which are over three years old. Rewind a few months and we had over 500. To help, we turned to LLMs and have had some amazing successes during the development of Bootstrap 6. The latest is an internal tool for us maintainers to triage everything automatically without prompting.

We vibe coded out twbs/triage to triage open Bootstrap issues and pull requests with an analysis, drafted responses, and when needed, a working fix prepared by agents. We maintainers still make every decision and post every response, but this has been helping us move faster and more efficiently.

Something we're most excited about is how personal software like this can be created so quickly, and then put to use in a way that benefits us and the community so immediately. Here's a look at our Triage tool in action.

Bootstrap owes a lot to the many maintainers and contributors who have shaped it over the years. Today, the day-to-day work rests on two active core team members, @mdo and myself.

Over the last twelve months, we received 186 issues and 838 pull requests. Of those pull requests, 189 came from bots, 433 from the core team, and 216 from about 130 contributors. Of those 216, 60 were merged, 106 were closed without merging, and 50 are still open.

Answering any one of those well means reading the thread, checking against both v5 and v6 dev branches, looking for related work, reproducing the problem, and replying. As any maintainer knows, the biggest bottleneck is our time and attention.

Earlier this month, I brought the setup I use to maintain my own projects into Bootstrap. I wrote more about that setup on my personal blog.

I use Claude Code to sync our backlog and dispatch background agents. Their work lands in the Triage app. Every item follows the same five steps:

Each issue or pull request gets a folder. #37807, which asks for container queries in the flexbox grid, looks like this:

issues/37807/ analysis.md what it is, findings, directions, recommendation answer.md the status comment to post on the issue pr.md fix 1: container-driven columns (recommended) pr-2.md fix 2: the same, behind an opt-in Sass option meta.json status, ease, related PRs, fix branches, dates

The analysis explains the item, what was checked, and what to do next. The answer is the exact text to post. Pull requests get a review covering the approach, CI, risks, and backports. Each item also gets a status—action, decision, waiting, or done—and an ease score:

If the resolution needs code or docs, the agent prepares a fix branch from Bootstrap's own main or v5-dev. If there are multiple reasonable directions, it can prepare up to three so we can compare working code instead of hypotheticals.

The local dashboard puts all of this in one place, sorted by ease. It shows the next action, copies the drafted response, and compares prepared fixes with open pull requests.

The first pass found everything from issues already fixed to features with multiple viable implementations. Here are a few examples.

#31088 popovers: do not dismiss on next click inside

ClosedOpened Jun 18, 2020·1 Opened in June 2020, this issue asked that popovers using "dismiss on next click" stay open when someone clicks inside them. #42834 fixed it, but that PR targeted v6 before it became the default branch, so GitHub never closed the issue. The analysis linked the code, tests, and docs that proved the fix, then drafted a two-sentence closing comment. From this one session, it found nine open items already fixed.

#42714 Fix carousel touch handling without Pointer Events

MergedOpened Jul 20, 2026·1 This fix addresses the v5 carousel swiping the wrong way on iOS 12 Safari. It had been waiting since July without a review, and its CI had never run because workflows from a first-time contributor need maintainer approval. The analysis confirmed the bug against v5, traced it to a regression in #32999, and recommended merging. I merged it on 4 October. It was a small, correct contribution buried among two hundred other items.

#37442 fix: Data.js must not overwrite exising element instance

ClosedOpened Nov 7, 2022·5 This pull request from 2022 got a review recommending that we close it and a drafted comment explaining why. Mark closed it, but with his own explanation: #42509 superseded it in v6, while the change would leave the registry inconsistent in v5. The analysis supplied the context; the decision and the words stayed with a maintainer.

#37807 Grid System should support CSS Container Queries for responsive column sizing

OpenOpened Jan 4, 2023·20 For this issue, the agents prepared two v6 fixes for container-driven columns: one enabled by default, as v6's CSS Grid already does, and one behind a Sass option. Both sit beside Mark's wider draft pull request so we can compare working implementations instead of descriptions.

There are dozens more issues and PRs that still need a maintainer decision. Finding buckets of work like these helps us move faster and more efficiently.

The key change we get from the Triage app is a clearer, actionable view of every open issue and pull request, allowing us to act faster with the right context. Within no time, agents had processed more than 200 remaining items and sorted them by what each needed next.

Now, when we have 20 minutes, we can pick an item, check the work, and act instead of spending that time rediscovering the problem, chasing histories across Git and GitHub cross references, etc.

The pass also exposed gaps in our GitHub labels. We standardized their names, documented every label, added missing labels like bug and needs-decision, and applied 410 labels across 198 open items. Agents can set factual labels from a fixed allowlist. Labels that imply a decision, like duplicate or wont-fix, still come from a maintainer.

We also added GitHub Discussions to our triage intake. Instead of treating a long thread as one answered question, the analysis tracks each open point—bugs, feature requests, design questions, and support requests—back to the person who raised it.

For example, Bootstrap 6 feedback is marked answered, but its analysis found 17 open points across 28. One bug had already been fixed by #42856, two requests became draft issues, and seven replies are ready for people still waiting.

Anyone can open an issue or pull request, so everything from them is treated as data, never instructions.

The agents also get things wrong. They don't know all of Bootstrap's history or the context that still lives in maintainers' heads. Sometimes they propose code where the right answer is to rethink the component. Their work is where we start, not what we ship.

This doesn't replace contributors, either. Prepared branches never copy an outside pull request. When a contributor has the right fix, the recommendation is to merge their work.

You'll see activity on old issues and pull requests in the coming weeks: fixes recognized, stale reports checked, and long-waiting pull requests reviewed. If we close something that shouldn't be closed, tell us in the thread.

The contributing guidelines explain what each label means. If you asked something in Discussions and never heard back, it's on our list now, too.

Questions and ideas are welcome in GitHub Discussions. We'll report back in a few months with what worked and what didn't.