New

Risk Red-Flagging

Catch the risky change before it ships, using your own incident history.

How it works

History that changes the score

Red-flagging uses the same per-file history as Collective Memory, but instead of displaying it, it feeds it into the risk score. When a file has a documented incident history, PRs that touch it are weighted accordingly.

Incident history

When a pull request touches a file that has been hotfixed or reverted before, Pullminder raises the risk, weighted by how recently it last broke and whether the change repeats the same kind of problem.

Author context

A first-time change to fragile code, or a large change from a single author with no second reviewer, raises the score so the right people take a closer look before it ships.

Warn or block, your call

Low risk is advisory. High risk can fail the check and block the merge — tuned per repository, with a one-label override that is recorded in your audit log.

Unlike Collective Memory, red-flagging actively changes the risk score and can block a merge when the threshold is met.

Override

One label to unblock, recorded forever

When a flagged PR needs to merge anyway, add the pullminder-risk-ack label. The check passes, and the override is written to your audit log with the actor and timestamp.

Thresholds per repository

Low risk is advisory by default. Raise the blocking threshold per repository when you are ready — no global toggle required.

Audit trail

Every override is logged: who applied the label, when, and which PR it unlocked. Filterable from the dashboard audit log.

Advisory by default

Red-flagging is off-by-blocking out of the box. Red flags surface in the PR comment as context until you raise the threshold.

Requires Collective Memory

Red-flagging reads the history that Collective Memory builds. Enable Collective Memory for a repository and red-flagging has what it needs.

FAQ

Questions you probably have

How is this different from Collective Memory?
Collective Memory only shows context next to the score. Red-flagging uses that same history to change the score and, when you want, to fail the check before a risky change merges.
Will it block every risky-looking PR?
No. It is off-by-blocking by default: red flags are advisory until you raise the threshold. Only changes to files with real prior incidents reach the blocking tier, and any PR can be overridden with the pullminder-risk-ack label.
Does it need extra setup?
It reads the same per-file history as Collective Memory, so enabling Collective Memory for a repository is all it needs.
How does it detect repeating problems?
When the kind of problem a file had before shows up again (for example, SQL injection findings in a file whose past incidents were SQL injection), Pullminder raises the score. On paid plans, it also asks a model whether the specific change risks repeating a prior incident on a troubled file, and shows the reason in the Red-Flag block.

Stop repeat incidents before they merge

Enable Collective Memory for a repository and red-flagging starts working. No extra configuration needed.