Skip to content
VEKTIS

Reviewing PR suggestions

Once a repository is connected, every PR your team merges into the release branch is classified and proposed as a Dev Item. You’ll find these proposals on the Suggestions page.

This page covers what you’ll see there and how to act on it.

Where suggestions appear

Section titled “Where suggestions appear”

Open Suggestions in the main navigation. A pill on the Dev Items page also shows how many suggestions are waiting, and takes you straight there.

Suggestions are grouped by how ready they are to approve:

  • Ready to track — VEKTIS already recognizes the code these PRs touch, so approving takes one step.
  • Needs a few details — approving asks you to pick a metric and an owner first.

Each suggestion shows:

  • Title — pulled from the PR title, with any conventional commit prefix (feat:, fix:, etc.) stripped off.
  • Type — feature, improvement, or bug fix. Other types don’t appear here (see How PRs are classified).
  • Repository and PR number — so you can click through to the original PR on GitHub.
  • Age — days since the PR merged.
  • Linked tickets — any Linear or Jira ticket URLs that VEKTIS detected in the PR description, up to ten.

Promoting a suggestion to a Dev Item

Section titled “Promoting a suggestion to a Dev Item”

When a suggestion is something you want to measure, approve it.

  1. Click “Approve” (or “Review & approve” for suggestions that need a few more details) on the suggestion row.

  2. Review the prefilled fields. A dialog opens with the title, description, and linked tickets already populated from the PR.

  3. Add the measurement details VEKTIS needs. These are the fields that aren’t in the PR:

    • Target metric — the metric you’re trying to move (e.g. signup conversion rate).
    • Target impact — the change you expect (e.g. +5%).
    • Target direction — whether higher or lower is better.
    • Owner — who’s accountable for measuring this Dev Item.
    • Initiatives (optional) — group this Dev Item with related work.

  4. Save. The Dev Item is created in Planning status with a link back to the original PR, and a confirmation appears. The suggestion disappears from the queue.

The new Dev Item is identical to one you’d create from scratch. From here, follow the normal flow: add baseline measurements, mark as released when ready, and start collecting post-release metrics.

Dismissing a suggestion

Section titled “Dismissing a suggestion”

Dismiss a suggestion when it’s a PR you don’t want to track — for example, an internal tooling change that wouldn’t show up as a measurable customer outcome, or a fix that’s too small to merit its own metric.

  1. Click the dismiss icon on the suggestion row.

  2. Confirm. The suggestion disappears from the queue.

What happens behind the scenes

Section titled “What happens behind the scenes”

You don’t need to think about this, but if you’re curious:

  • A merged PR appears as a suggestion within a minute or two of the merge being recorded on GitHub.
  • If the same PR is reopened and merged again, the existing pending suggestion updates with the new title and description. Already-approved or already-dismissed suggestions are not re-created.
  • Disconnecting the GitHub integration does not remove existing suggestions — they remain in your queue. Only new merges stop being added.
Section titled “Related”