Issue sources

Open Integrations → Integration catalog (/team/<namespace>/integrations) to find Jira, Shortcut, Linear, and GitHub Issues as individual cards. Add integration opens the selected tracker’s setup; Manage opens existing settings. Connected trackers also offer Add another. Shortcut and advanced Linear settings support multiple workspace connections, each with its own credential and repository review settings. Jira uses one shared project credential across its mappings.

Without the catalog, open Integrations → Issue sources, Google Workspace, or Tailnet directly from the sidebar.

Google Workspace and Tailscale support multiple independent connections. For Google Workspace, use Add another in the catalog, give the new connection a name, and authorize its Google account. Each saved connection has its own Reconnect and Disconnect controls; adding another does not replace existing accounts. Reviews try the connected Google accounts to read each linked document.

Issue sources (/team/<namespace>/issue-sources) connects Linear, Shortcut, Jira Cloud, and GitHub Issues so a hosted review can read the work a pull request claims to do.

You can connect trackers before hosted reviews are enabled. GitHub Issues uses the GitHub App you already installed. The other trackers use a project-level credential. Credentials are encrypted and are never shown again. Replacing a credential means pasting a new one.

Owners and admins add, edit, and remove mappings. Members can see which trackers are connected and which repositories they apply to. Fetched issue text is stored with the pull request snapshot and is visible to project members.

Connecting a tracker does not edit the tracker or link the pull request for you.

Add a tracker

Choose Add your first issue tracker (or add another). New mappings apply to all repositories until you narrow them.

For Shortcut, connect a workspace with an API token. Doomer verifies the workspace and loads named teams, projects, and labels. Refresh workspace details reloads those choices; Credential settings replaces the token for the same workspace. Add a separate connection for another workspace. Existing Shortcut credentials and repository settings are preserved automatically.

Use Add review settings to choose repositories and searchable teams, projects, included labels, and excluded labels. The choice lists are searchable. Empty filters cover the whole workspace. Teams and projects match any selected value; any included label is enough, and excluded labels always win. Linked stories use the workspace credential even when they fall outside the search filters.

Turn Find stories for PRs without a linked story on to discover unlinked work. Search related stories when a story is linked supplies supporting context for linked work. These controls are independent, and all matching Shortcut repository rules compose across workspaces.

Jira uses a shared credential. To change its site or email, remove the Jira mappings and connect again.

Which repositories use a tracker

Open Applies to on a mapping. The repository filter is one of:

• All repositories
• Repositories in one GitHub organization
• Selected repositories (hosted repositories already listed, plus any owner/name you add)

Shortcut and advanced Linear review settings compose: every matching rule applies. For basic tracker mappings, a narrower mapping overrides a broader one, and mappings at the same specificity can both apply.

Only trackers mapped to the repository are fetched for that pull request.

Changing a mapping or credential marks saved snapshots stale. Refresh intent sources on the review page to fetch again. See Intent and provenance.

What gets linked

On each hosted run, and when someone refreshes sources, Doomer reads issue URLs from the pull request title and body. You can also add an issue URL on the review page.

Supported links:

• Linear issues
• Shortcut stories
• Jira Cloud issues whose URL contains /browse/
• GitHub issues in the reviewed repository

With Linear mapped and a usable credential, a bare uppercase id such as DOO-18 in the title or body is fetched too. Doomer stores the canonical Linear URL. If the credential is missing or unreadable, bare-id discovery is skipped. An explicit Linear link still appears, with a source gap if it cannot be read.

Linear and Jira bare ids look the same. When both are mapped to the repository, put an explicit URL in the pull request so the intended tracker is used.

Shortcut story tasks are included with the linked story. Retrieval also asks for a bounded description, discussion excerpt, and parent or child context. Partial failures are labeled. Previously fetched text is kept with its original fetch time when a later fetch fails.

A fetch error is a source gap. It does not stop the code review. Reviews with no linked issue still use the pull request title, description, and diff.

Search for unlinked stories

Search for unlinked stories is separate from the repository filter. Turn it on in the connection form or under Applies to. Doomer does not guess a workspace from the GitHub owner, the project name, or a ticket prefix.

A connection with no search identity can still fetch explicit links. Coverage on the review page says search needs configuration. A wrong workspace or unreadable credential is an explicit search gap. It does not search a guessed workspace.

For a tracker that has no usable linked issue, Doomer searches from the pull request title, description, and changed paths, then from up to two phrases taken from the diff. Up to nine candidates are saved apart from the requirements used in the review. Suggestions do not become requirements by being retrieved.

One unambiguous strong match can be adopted as inferred context before the review runs. The match has to quote real diff and story evidence. Incomplete retrieval prevents that. Several claimed exact matches stay suggestions.

The review then says one of:

• Suggested: “This story appears relevant. Consider linking it to this PR.”
• Used: “This story closely matches the changed behavior. I used it as inferred context for this review; consider linking it to confirm the intent.”

Search and model failures leave the ordinary code review in place and show up in coverage.

For the first three Linear or Shortcut links that have a connected tracker, Doomer also looks up a few related issues. GitHub and Jira links do not use those three slots. Direct tracker relationships are labeled separately from search suggestions. Only the linked story and its explicit relationships inform the review. Search hits stay on the page as optional context. A retrieved story is not proof that the work is finished. Related, parent, and child work can span pull requests.

If required story tasks and relationships exceed the intent packet limit, the review page shows an error. The code review continues from the pull request and the diff. Shorten the tracker content or unlink a story, then refresh intent sources.

What the review does with the text

Issue text is untrusted source text. The review page does not present it as a reviewed or approved intent statement. When intent capture is enabled, the worker passes a bounded, source-attributed packet into the review. Story alignment then compares linked requests with the diff and labels the result Appears aligned, Possible gap, Clear mismatch, or Unclear.

An explicitly linked story is authoritative review scope and is included regardless of a model relevance judgment. Doomer assesses its requirements and retries one transient assessment failure; if assessment still cannot complete, the review reports limited source coverage and withholds automatic approval instead of treating the story as out of scope. A completed assessment that finds no testable requirements is shown separately and does not become a coverage failure. Search suggestions remain optional context and still require a relevance judgment.

A specific possible gap can appear as a review-level comment. A direct contradiction gets a mismatch callout. These are not pinned to a line, because missing story behavior may have no honest line to comment on. A possible gap can be intentional when one story spans several pull requests.

Intent capture itself is turned on for the deployment, not by a project switch. If it is off, mappings and refreshes still work, and clarifications are saved, but reviews do not use them yet. Details are in Intent and provenance.

Additional integration cards can be enabled individually for your project: Notion, Confluence, SharePoint, OneDrive, Slack, Microsoft Teams, Figma, Datadog, Grafana, PagerDuty, AWS, Google Cloud, Kubernetes, Google Cloud Monitoring, and HackerOne. Only enabled cards appear in the catalog and its search and tag filters. These additional cards currently have no connection controls; Available to add shows integrations with connection setup.

Sentry

Enable the Sentry integration for your project, then open Integrations → Sentry. Add a Sentry Cloud organization slug, project slugs, repository names (owner/repo), an optional environment, and an auth token with org:read and event:read access. Tokens are encrypted and accessible only to the server. Project owners and admins can add, update, and remove connections.

When integration_sentry is enabled for the project, every review of a mapped repository searches both open and resolved errors, even when the PR links a Sentry issue. Search uses changed filenames and PR title terms. Explicit links are fetched independently of issue status and the configured history window. The default search history is 90 days; select 1–365 days to match your retention and regression history.

The reviewer checks whether claimed fixes address recorded failures, whether related errors supply missing runtime context, and whether changed code could reintroduce a resolved failure. Sources show issue status, first/last seen times, occurrence counts, representative event release/environment, exception text, and stack locations. Request bodies, user objects, breadcrumbs, and stack locals are omitted. A resolved status is not proof of a fix, and an old event is not evidence that an error happens in production today.

Retrieval is bounded: up to six candidates per status group and connection, eight changed filenames and four title terms, and three Sentry excerpts per review. Linked errors have priority; other candidates alternate between open and resolved errors. Coverage reports failures and truncation. Reviews continue when Sentry is unavailable. Sentry is read-only: Doomer never resolves, reopens, or otherwise changes issues. The first version supports Sentry Cloud; self-hosted instances and OAuth setup are not included.

Disabling integration_sentry blocks the Sentry settings page and connection actions, prevents credential loading and Sentry requests during refresh, and excludes previously saved Sentry evidence from new review captures and reruns. Existing completed review results remain historical records.

For GitHub Issues, add repository settings from its integration card. Linked issue URLs, #123, and owner/repo#123 in the PR title or description supply context from the reviewed repository. The App needs permission to read issues; links to pull requests are rejected as issue sources. Find issues for PRs without a linked issue and Search related issues when an issue is linked are independent controls. Search stays in the reviewed repository, and returned candidates are checked against the diff before use. Linked issues and search candidates appear in the review’s Sources tab, with retrieval failures shown in coverage notes.