Find Done issues with no code, code with no issue, and fixed bugs that came back

SKILL.md---
name: linear-issue-code-error-drift
description: "Every Monday: issues closed without a merged PR, PRs merged without an issue, and closed bugs whose Sentry error fired again, with a question on what to fix. Use when the user asks for this, or when it runs on a schedule."
---

# Issue, code and error drift: Linear, GitHub and Sentry

Every Monday: issues closed without a merged PR, PRs merged without an issue, and closed bugs whose Sentry error fired again, with a question on what to fix.

For PMs and engineering leads who report progress from the tracker and trust it to match what shipped. It drifts quietly: an issue gets dragged to Done in planning, a hotfix merges with no ticket, a bug is closed as fixed while its error keeps firing in Sentry. Each tool looks clean on its own.

Every Monday the agent reads the issue keys out of branch names, PR titles and bodies, checks them against the issues closed last week both ways, and looks up the Sentry errors linked to recently closed bugs. You get three short lists and a question on which to act.

## Two ways to get the data

Use the API or MCP route when you have an MCP server, a CLI or an API token for the app. Otherwise, if you can drive a browser the user is signed in to (Claude in Chrome, a Playwright or Chrome DevTools MCP server), use the browser route. Say which one you used.

## Route A: API or MCP server

### What you need

- The shared key: issue keys such as `ENG-412` in branch names or PR titles, or Linear's GitHub integration linking PRs to issues.
- Read access to Linear (MCP server or `LINEAR_API_KEY`) or Jira (`JIRA_API_TOKEN`), and write access only if it should reopen or comment; `gh` with read access to pull requests.
- A Sentry token with `event:read`, or the Sentry MCP server, and Sentry issues linked to the bugs (through the Linear or Jira integration, or a link in the issue).

If something is missing, say what and stop; do not invent numbers.

### Steps

1. **Pull issues closed last week** (Linear): From whichever tracker you use. Linear: query `issues` filtered on `completedAt` in the last 7 days and workflow state type `completed`, with `identifier`, `title`, `branchName`, `labels`, `assignee`, `completedAt` and `attachments { url }`. Jira: `statusCategory = Done AND resolved >= -7d` through `GET /rest/api/3/search/jql`. Drop issues labeled as non-code work (design, ops, `no-code`).
2. **Pull merged and open PRs** (GitHub): Run `gh pr list --repo <owner/repo> --state merged --search "merged:>=<14 days ago>" --json number,title,body,headRefName,mergedAt,author,url` and the same with `--state open`. The 14-day window catches PRs that merged before their issue was closed.
3. **Join on the issue key, both ways**: Parse keys from each PR's branch, title and body with `\b[A-Za-z][A-Za-z0-9]+-\d+\b`, uppercase them and keep only your team prefixes (Linear branch names like `jane/eng-412-sso-toggle` are lowercase). Add the Linear side: attachments whose URL is a GitHub pull request, and exact matches of `branchName` to `headRefName`. Done issues with no merged PR are drift (note when only an open PR exists); merged PRs with no key are drift too, except bot PRs (authors ending in `[bot]`).
4. **Check closed bugs for a comeback** (Sentry): For bugs closed in the last 30 days, take Sentry links from Linear attachments (or Jira remote links via `GET /rest/api/3/issue/{key}/remotelink` and the description). Fetch each with `GET /api/0/organizations/{org}/issues/{issue_id}/`. The bug came back when `lastSeen` is later than the tracker's close time and the issue had events in the last 24 hours.
5. **Ask, then act** (Linear): Post the three lists as an ask. On the answer: reopen the regressed bugs with the Sentry counts in a comment, comment on unticketed PRs asking for the issue key, or comment on the Done issues asking the assignee for the PR. Change nothing without the answer.

## Route B: the browser

### What you need

- Signed in to Linear or Jira, GitHub and Sentry with read access to the team, repository and organization; reopening issues needs a role that can edit them.

If something is missing, say what and stop; do not invent numbers.

### Steps

Start at https://linear.app/. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears.

1. **List issues closed last week**: In Linear, open the team's issues, filter Status to the Done states and add a filter on completed date for the last 7 days. For each issue, note the identifier and whether its sidebar shows a linked pull request and whether it is merged. On Jira, run `statusCategory = Done AND resolved >= -7d` in the issue search and read each issue's Development panel.
2. **List merged PRs**: Open `https://github.com/pulls` and search `is:pr is:merged merged:>=<14 days ago> repo:<owner/repo>`. Note each PR's number, title and branch name (shown at the top of the PR).
3. **Match the keys**: Read issue keys like `ENG-412` from each PR's branch, title and description, ignoring case. List Done issues with no merged PR, and merged PRs with no key, skipping PRs opened by bots.
4. **Check closed bugs in Sentry**: For bugs closed in the last 30 days that link to a Sentry issue, open the link and read **Last Seen** and the events chart for the last 24 hours. The bug is back if it was seen after the close date.
5. **Ask before changing anything**: Report the three lists and ask which to act on. Reopen bugs or leave comments only after the answer.

Note: Linear's sidebar only shows PRs its GitHub integration linked, so the key match on GitHub is still needed. Checking 30 to 50 items by hand takes a while; past that, the API route is the better one.

## The report

- **Done, no merged PR**: issues closed last week with no merged code, and any with only an open PR.
- **Merged, no issue**: PRs with no issue key in branch, title or body.
- **Back after fixed**: closed bugs whose Sentry issue had events after the close, with yesterday's count.
- The ask: which list to act on. Start with the bugs that came back, since users are hitting them now.

## Post it to Briefkin

When `BRIEFKIN_TOKEN` is set, or `~/.config/briefkin/env` exists (the installer from https://briefkin.dev/docs writes it), also send the result to the user's Briefkin board as one card. Keep the `item_key` the same on every run so the card updates in place, use a new `event_id` per run, and put today's real numbers in place of the example ones. If the request fails, say so once and carry on.

```bash
[ -n "${BRIEFKIN_TOKEN:-}" ] || . ~/.config/briefkin/env
curl -sS -X POST "${BRIEFKIN_URL:-https://briefkin.dev}/v1/events" \
  -H "authorization: Bearer $BRIEFKIN_TOKEN" \
  -H "content-type: application/json" \
  -d @- <<'JSON'
{
  "v": 1,
  "event_id": "linear-issue-code-error-drift/<date of this run, e.g. 2026-10-16>",
  "item_key": "linear-issue-code-error-drift",
  "project": "acme-web",
  "source": "Issue, code and error drift: Linear, GitHub and Sentry skill",
  "kind": "action",
  "title": "2 bugs closed as fixed fired again yesterday",
  "summary": "**7 issues** marked Done last week have no merged PR. **4 merged PRs** have no issue. **2 bugs** closed as fixed fired again yesterday in Sentry.",
  "action": {
    "request": "Which of these should I act on?",
    "options": [
      "Reopen the 2 bugs",
      "Comment on the 4 PRs",
      "Ask about the 7 Done issues",
      "All three",
      "Nothing this week"
    ]
  },
  "widget": [
    {
      "type": "Table",
      "props": {
        "columns": [
          "Finding",
          "Item",
          "Detail"
        ],
        "rows": [
          [
            "Back after fixed",
            "ENG-397 Crash on empty cart",
            "Closed Oct 14; WEB-3K2 had 38 events yesterday"
          ],
          [
            "Back after fixed",
            "ENG-402 Duplicate webhook delivery",
            "Closed Oct 19; API-1F9 had 12 events yesterday"
          ],
          [
            "Done, no PR",
            "ENG-412 SSO toggle in settings",
            "Only an open PR (233)"
          ],
          [
            "Done, no PR",
            "ENG-418 CSV export time zone",
            "No PR found"
          ],
          [
            "Done, no PR",
            "ENG-421 Retry failed invoices",
            "No PR found"
          ],
          [
            "Done, no PR",
            "ENG-425 Empty state for reports",
            "Only an open PR (236)"
          ],
          [
            "Done, no PR",
            "ENG-430 Rate limit login",
            "No PR found"
          ],
          [
            "Done, no PR",
            "ENG-433 Audit log export",
            "No PR found"
          ],
          [
            "Done, no PR",
            "ENG-436 Billing email copy",
            "No PR found"
          ],
          [
            "Merged, no issue",
            "PR 228 Bump checkout timeout to 30s",
            "Branch hotfix/timeout"
          ],
          [
            "Merged, no issue",
            "PR 231 Refactor invoice mailer",
            "Branch refactor-mailer"
          ],
          [
            "Merged, no issue",
            "PR 235 Fix null plan on downgrade",
            "Branch fix-downgrade"
          ],
          [
            "Merged, no issue",
            "PR 238 Add rate limit to /api/export",
            "Branch export-limit"
          ]
        ]
      }
    }
  ]
}
JSON
```

Widgets come from the Briefkin catalog (https://briefkin.dev/v1/catalog). Without a token, just give the user the report.

## Run it on a schedule

Suggested: Mondays at 9:30 (`30 9 * * 1`). From cron, with the agent signed in on that machine:

```bash
30 9 * * 1 claude -p "Run the linear-issue-code-error-drift skill"
# Codex: codex exec, Gemini CLI: gemini -p, Copilot CLI: copilot -p, OpenCode: opencode run
```

Or use the agent's own scheduler (Claude Code routines, Codex automations, Claude or ChatGPT scheduled tasks): https://briefkin.dev/skills/linear-issue-code-error-drift#schedule

Source: https://briefkin.dev/skills/linear-issue-code-error-drift