PRISM: Pull Request Intelligence & Selection Mechanism

• 

  Main Dashboard (Metrics, SLA Status , Currently Opened PRs, Notification Controls

• 

  Reviewer Assignment Page(Reviewer Ranking, PR info , PR Risk Info, Required Reviewers, Reviewer Assignment button.

• 

  Historical PRs( Closed PRs and Domain Experts associated with those PRs)

• 

  Notification Controls for Reminder(Choose which PR you need to send reminder to)

• 

  Notification as PR comment (Automatically sending notification to right reviewers as soon as ranking is done)

• 

  Reminder given as PR comment

Inspiration

While learning how real software teams work, I noticed that pull requests often wait too long not because teams lack skills, but because the right reviewers are not identified early. Domain specific changes, like security or backend logic, sometimes sit in review queues while general PRs move faster. This delay can be risky for both workflow and product quality. PRISM was inspired by this gap: ensuring that domain experts review the most critical pull requests first, so important changes don’t wait longer than they should.

What it does

PRISM analyzes pull requests and helps teams identify the most suitable reviewers based on code domain, risk, and team workload. It: 1) Classifies PRs into domains (like backend, frontend, security, database, Devops,etc). 2) Detects risky changes (for example, authentication or security related code). 3) Ranks reviewers by matching PR domain with team expertise. 4) Applies workload and availability penalties to avoid overloading reviewers. 5) Tracks historical ranking and review data for transparency. 6) Sends manual notifications and reminders to avoid spam and keep teams in control. PRISM does not force actions ,it provides structured intelligence to support better review decisions.

How we built it

PRISM is built on Atlassian Forge and integrates with Bitbucket. Key parts: 1) Static analysis of PR metadata (files changed, paths, extensions, titles, descriptions). 2) Domain classification using heuristic rules and pattern detection. 3) A ranking engine that prioritizes domain experts first, then full stack developers. 4) AI assistance using Groq (LLaMA 3.1) as a reasoning layer and not a decision maker. 5) Manual notification and reminder controls to prevent unnecessary noise. 6) Historical storage to track reviewer rankings, PR risk levels, and review outcomes.

Challenges we ran into

1) Designing heuristic-based domain classification that works consistently across different PRs. 2) Building a reviewer ranking system where domain expertise is always prioritized. 3) Preventing AI assisted ranking from becoming too random or unpredictable. 4) Balancing workload penalties without pushing experts too far down the ranking. 5) Calculating meaningful metrics like workload distribution and review velocity. 6) Ensuring notifications remain helpful without becoming spammy.

Accomplishments that we're proud of

1) Successfully classifying PR content and matching it with structured team expertise data. 2) Building a ranking system that stays explainable and deterministic. 3) Creating a clean, readable, and interactive UI using Forge-native components. 4) Implementing historical ranking and review tracking for transparency. 5) Designing a system that stays useful even when AI is unavailable.

What we learned

1) Reviewer selection is as important as code quality itself. 2) Explain ability matters more than pure automation in developer tools. 3) Static analysis can go a long way when designed carefully. 4) Atlassian Forge enables powerful integrations when used properly and thoughtfully. 5) AI is most effective as an assistant, not a replacement for rules.

What's next for PRISM: Pull Request Intelligence & Selection Mechanism

For the upcoming future, PRISM can further be evolved into a lightweight review intelligence layer with clearer insights, configurable workflows, and improved visibility into review bottlenecks. Some of the improvements like:- 1) Introducing a calendar-based view to help teams visualize review activity, pending PRs, and long waiting reviews over time. 2) Adding a settings page so teams can fine-tune thresholds like risk sensitivity, reminder behavior, and reviewer limits. 3) Continuing to simplify the experience by reducing complexity, improving clarity, and keeping PRISM easy to understand and use. 4) Focusing on better explain ability so teams always understand why a reviewer was ranked or a PR was marked risky.

Built With

• atlassian-forge
• bitbucket-cloud-apis
• forge
• groq
• javascript
• ui