cd /news/ai-tools/jira-backfill-tickets-from-merged-pu… · home › topics › ai-tools › article
[ARTICLE · art-141639] src=perrotta.dev ↗ pub= topic=ai-tools verified=true sentiment=· neutral

JIRA: backfill tickets from merged pull requests

A developer published a local `/backfill-jira` skill for AI harnesses that reconciles recently merged pull requests against existing JIRA issues before creating any tickets, using a three-phase structure: Phase A gathers and reconciles read-only, Phase B creates backfill tickets, and Phase C confirms. The skill creates one ticket per uncovered "theme" rather than per PR, and explicitly instructs leaving genuinely routine PRs (version bumps, dependency bumps, typo fixes) uncovered and listed as "skipped (routine, no ticket)" rather than inventing a catch-all ticket. Phase B reads back status and checks sprint assignment after writing because, per the author, neither a successful create response nor an attempted status change proves the final fields stuck.

by read2 min views1 publishedSep 29, 2026

♠ Problem statement: how can I catch up JIRA when pull requests have already (been) merged without tickets?

I wrote a local /backfill-jira skill for my AI harnesses. It compares recent merged PRs with existing issues before it creates anything. This is its structure; internal projects, repositories, queries, and field IDs are omitted:

% rg -n '^### Phase' ~/.claude/skills/backfill-jira/SKILL.md
31:### Phase A — gather + reconcile (read-only)
72:### Phase B — create the backfill tickets
125:### Phase C — confirm

The unit of work is a theme, not a PR. Several PRs can implement one change; one PR can also be routine enough to need no ticket. The skill checks PR references and matching issue summaries before declaring a gap. Existing backlog issues count as coverage.

The report rule in the skill is explicit:

4. **Report.** Print a table of every PR → (existing ticket | NEW theme-N | skipped-routine) and a
   separate list of the gap themes to create. The counts must reconcile: covered + new + skipped =
   total PRs. Don't let "get every PR to a theme" pressure you into merging unrelated skipped PRs
   into a theme just to shrink the skipped list.

Phase B creates one ticket for each uncovered theme, marks work as complete, and reads the status back. It also checks the sprint assignment after writing it. Neither a successful create response nor an attempted status change is proof that the final fields stuck.

The skill deliberately leaves routine work alone:

- Don't create per-PR tickets by default — one ticket per theme keeps signal high. **Never create a
  "grab bag" / "catch-all" / "hygiene" ticket that lumps together unrelated PRs** just to get to
  zero gaps — each ticket must describe one coherent, describable piece of work. If a PR is
  genuinely routine and not worth tracking on its own (a version bump, a dependency bump, a typo
  fix) and doesn't fit an existing theme, leave it **uncovered**: list it in the report as *skipped
  (routine, no ticket)* rather than inventing a ticket to absorb it.

A second pass over the same window checks whether the new tickets now cover the gaps. Zero new gaps matters more than zero skipped PRs. ∎

— § —

Reply via email

── more in #ai-tools 4 stories · sorted by recency
── more on @jira 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/jira-backfill-ticket…] indexed:0 read:2min 2026-09-29 · —