How we match commits to the right task
A look under the hood at the matching pipeline, confidence tiers, and why it stays cheap.
When you push code or merge a pull request, the matching task moves on its own. This post is a short tour of what happens in between, and the choices that keep it accurate and inexpensive.
The short version: we decide where the work happened before we ever ask a model which task it belongs to.
We read signal, not source
A GitHub event arrives and we strip it down to the minimum we need: the branch name, the commit messages and the pull request title. We never store the contents of your files. That stripped signal is enough to recognise the work, and it keeps your code where it belongs.
Decide the status before spending a token
Where the work happened already tells us the target status. A push to a feature branch means in progress, an opened pull request means review, and a merge means done. We run this pure decision first, so events that cannot move anything, like a bot commit or a merge with no real change, never reach the model at all.
Match the task, with a confidence score
Only then do we ask which open task the work belongs to, comparing the signal against the project's open tasks and getting back a task, a confidence score from 0 to 100, and a plain reason. Status never moves backward, so finished work is safe.
Confidence decides the action
At 80 and above, we move the task for you. Between 50 and 79, we email a one-click yes or no before changing anything. Below 50, we log the attempt and leave the board untouched. Every decision lands in the AI Activity feed with its reason, so nothing happens silently.
Let your board keep up with you.
Connect a GitHub repo and watch the board start keeping itself current. Free to start, no card required.