Back
Explore EventsExplore ProjectsMy Projects
Pull Guard — screenshot 1
Pull Guard — screenshot 2
Pull Guard — screenshot 3
Pull Guard — screenshot 4

Pull Guard

Pull Guard deslopifies the open-source PR queue: an ML triage engine that clusters duplicate work, flags mislabeled issues, detects junk patches, ranks contributor trust, and recommends the PR maintainers should actually choose.

Codex Community Hackathon - Pune

Links

Repository

github.com/divagr18/triage

Website

Not set

Demo video

youtu.be/qpCjg8Rj8V4

Additional info

How was your experience building with Codex?

Building with Codex was excellent. It gave me the speed of an AI coding assistant without losing the feeling of control over the product and architecture. For Triage, I was able to rapidly prototype ML-powered PR clustering, patch analysis, contributor trust signals, and maintainer-facing review flows while still keeping the implementation grounded in the actual repo. Codex was especially useful for turning vague product ideas into working code quickly, which made the whole build process feel much faster, cleaner, and more ambitious.

Describe your experience using Loops House as the hackathon platform. What worked well, what challenges (if any) did you face, and what improvements would you like to see?

My experience using Loops House as the hackathon platform was very smooth. The platform made the submission process easy to manage, and I especially liked that it preserved all the information entered in the form instead of making us repeatedly refill details. That made the process feel reliable and reduced friction while submitting and updating the project. Overall, it worked well as a centralized place to manage the hackathon flow, project details, and submission requirements. I did not face any major challenges. The main improvement I would suggest is adding even clearer progress indicators or section-wise completion status so teams can quickly see what is pending before final submission.

Tell us about your overall experience at Codex Community Hackathon Pune.

My overall experience at the Codex Community Hackathon Pune was extremely positive. It was a well-organized, high-energy environment with a strong builder community, and the event made it easy to focus on shipping something meaningful. I really enjoyed the opportunity to build with Codex, meet other ambitious developers, and push an idea from concept to demo in a short amount of time. The hackathon felt genuinely engaging and productive, and the support from the organizers made the experience smooth throughout.

What could Codex Community improve to create a better experience for participants?

The experience was already very positive overall. One improvement that could make it even better would be to provide a slightly clearer timeline and checklist for participants, especially around submissions, judging criteria, demo expectations, and key deadlines. This would help teams plan their build more effectively and avoid last-minute confusion. It would also be great to have a little more structured mentor access or short check-in slots during the hackathon, so teams can quickly validate ideas, get feedback, and stay aligned with what the judges are looking for.

Team

1 member
  • DI

    Divyansh

    Owner

Overview

Pull Guard is a maintainer cockpit for the age of coding agents. It scans open pull requests in a GitHub repository, builds a local cache, analyzes the patch and metadata, then turns the queue into something maintainers can actually reason about. Instead of showing a flat list of PRs, Triage groups similar contribution attempts into semantic clusters, detects AI-flood patterns, ranks the strongest candidate in each cluster, estimates contributor trust based on past PR history, and flags patch-text mismatches where the PR description says one thing but the diff does another. It also highlights low-value patterns like README-only noise, generic descriptions, dependency changes without usage, lockfile churn, untested core changes, and repeated shallow edits across many contributors. The product is CLI-first with a visual report for demos and day-to-day review. Maintainers can run a scan, inspect duplicate clusters, compare two PRs, ask for an explanation of a specific change, review AI-flood waves, and use the dashboard to decide where their attention is most valuable. Pull Guard stays read-only by default: it does not label, close, or comment unless a maintainer explicitly asks for a dry-run plan. At its best, PUll Guard gives maintainers what GitHub does not: a way to see intent, duplication, trust, patch quality, and review priority across the entire queue.

ExploreProjectsMine