How PRs are classified

When a PR is merged into a tracked release branch, VEKTIS reads its labels and title, assigns it a type, and decides whether to surface it as a Dev Item suggestion. This page documents the rules.

The decision in one sentence

VEKTIS suggests PRs typed as feature, improvement, or bugfix. PRs typed as infrastructure or docs are not suggested — they typically don’t have a customer-facing outcome worth measuring.

How the type is decided

The classification runs in a fixed priority order. The first rule that matches wins.

1. Labels (highest priority)

If the PR has any of these labels (case-insensitive), VEKTIS uses the matching type. Multiple labels are checked in order; the first match wins.

Label on the PR	Assigned type	Surfaces as a suggestion?
`feature` or `enhancement`	feature	Yes
`bugfix`, `bug`, or `fix`	bugfix	Yes
`infrastructure`, `chore`, or `infra`	infrastructure	No
`docs` or `documentation`	docs	No

If none of the recognized labels are on the PR, VEKTIS falls through to the next rule.

2. Conventional commit prefix on the title

If the PR title starts with one of these prefixes (with or without a scope, e.g. feat: or feat(auth):), VEKTIS uses the matching type:

Title prefix	Assigned type	Surfaces as a suggestion?
`feat:`	feature	Yes
`fix:`	bugfix	Yes
`chore:`	infrastructure	No
`docs:`	docs	No

The prefix is stripped from the title before the suggestion is created — so a PR titled feat: Redesigned pricing page becomes a suggestion titled Redesigned pricing page.

3. Default

If neither a recognized label nor a conventional prefix matches, VEKTIS classifies the PR as improvement and surfaces it as a suggestion. This is the catch-all for general work that’s neither clearly a new feature, a bug fix, nor obviously infrastructure or documentation.

Worked examples

PR title	PR labels	Assigned type	Suggestion?
`Redesigned the pricing page`	`feature`	feature	Yes
`feat(checkout): one-click reorder`	(none)	feature	Yes
`fix: timezone offset bug`	(none)	bugfix	Yes
`Tighten copy on the empty state`	(none)	improvement (default)	Yes
`Bump dependency versions`	`chore`	infrastructure	No
`chore: rotate signing key`	(none)	infrastructure	No
`Update README with new examples`	`docs`	docs	No
`feat: rebuild the search engine`	`infrastructure`	infrastructure (label wins)	No

The last row shows how priority resolves a conflict: a feat: prefix would normally make this a feature, but the explicit infrastructure label takes precedence.

Linked tickets pulled from the PR description

When VEKTIS creates a suggestion, it scans the PR description for ticket URLs and attaches them automatically. Up to ten URLs can be linked.

Recognized formats:

Linear — https://linear.app/your-team/issue/ABC-123/short-slug
Jira — https://your-domain.atlassian.net/browse/ABC-123

These appear on the suggestion as Linked tickets and carry forward to the Dev tickets field on the promoted Dev Item.

Why these rules?

The split exists because not every change worth merging is a change worth measuring. Infrastructure work and documentation changes usually don’t move a customer-facing metric, so surfacing them as Dev Item suggestions would dilute the list and add review noise. By contrast, features, improvements, and bug fixes are the work where measurement actually pays off.

If your team’s labeling conventions don’t fit this scheme — for example, you label everything enhancement regardless of size, or you don’t use labels at all — the conventional commit prefix and the catch-all default usually still produce the right outcome. If they don’t, see the troubleshooting page for what to do when a PR ends up the wrong type.