To combine Jira and GitHub into one weekly status report, match pull requests to Jira issues by the issue key in the branch, PR title, or commit message, using the same date window for both tools. Report the matched work by milestone, and list the mismatches separately: tickets marked done with no merged code, and merged code with no ticket. An AI assistant can draft the report from both sources, and you review it before your sponsor sees it.
Why does a Jira-only or GitHub-only report miss things?
A sponsor needs both views together, because a ticket can say done while its code still waits for review, and code can ship that the plan never mentioned. A combined weekly status report puts both in one place, so the sponsor sees progress against each milestone with the evidence behind it.
The jira-weekly-report repository emails the project lead three lists (Created, Resolved, Open now) from one Jira Cloud project, and it calls only the Jira REST API and SMTP. It never reads pull requests. Atlassian's Generate Status Report agent skill is another starting point from the Jira side, so check what any AI option reads before you rely on it for both sources. SyncHub does load both Jira and GitHub data into a data warehouse, but you build the report yourself. If you just need to send a weekly update, you can skip the warehouse. Follow a clear joining rule and review the result yourself.
How do you match pull requests to Jira issues?
Match pull requests to Jira issues by the issue key. The issue key is the link the integration relies on. If a branch, PR title, or commit message contains the key, the AI or the integration can connect the code to the ticket. If the key is missing, nothing connects, and that gap belongs in the report.
Jira Alternatives gives the convention, with branch names such as PAY-248-checkout-timeout, and explains that a combined view depends on consistent issue keys. Set the rules with your team before you rely on the report:
- Agree that every branch and PR title starts with the Jira issue key.
- Agree on one date window for the report, for example [start day and time] to [end day and time] in [time zone], and use the same window for both tools.
- Agree which single Jira field defines the milestone, and group the report by that field only. Write the field name into the prompt so the assistant does not guess.
- Decide how to treat work with no key: list it under "Unlinked work" rather than guessing which ticket it belongs to.
- Decide how to treat a PR that references several issues: count it under each issue, and say so in the report.
- List every repository the report covers, so a sponsor knows what is out of scope.
Be careful with automation. The same guide warns that automatic status changes can make reports misleading if they fire too early, for example when a PR is opened. Before you trust a ticket marked done, check which event moved it.
Which mismatches should the report flag?
The report should flag every place where Jira and GitHub disagree, because those disagreements point to progress risks a sponsor may need to hear about. A ticket marked done with no merged pull request means the plan is ahead of the code. A pull request open against a blocked ticket means work is waiting. Merged code with no ticket means the plan is missing something.
Use the same categories in the checklist, the template, and the prompt, so every draft lines up. Under "Mismatches to resolve", ask for these checks each week:
- Done, no code: issues resolved in the window with no merged PR linked.
- Waiting for review: PRs open longer than [your agreed limit] with no review.
- Blocked with open code: PRs open against issues in a blocked status.
- Stalled: issues in an in-progress status with no linked commits or PR activity in the window.
Merged code with no ticket goes in its own list, "Unlinked work", so nobody guesses which issue it belongs to.
Treat each mismatch as a question for the owner. Ask them about it before the report goes out, and write down their answer.
What does a combined weekly status report template look like?
The combined weekly status report template groups work by milestone and shows each item with its Jira issue and the pull requests behind it. The template puts the decisions or help you need from the sponsor near the top. Copy it into your report document, email, or Confluence page, and fill in the brackets.
Weekly status: [project name], [start date] to [end date]
Overall: [on track / at risk / off track], because [one-sentence reason]
What we need from you
- [Decision, review, or help needed] by [date]. Options: [A] / [B]. Our recommendation: [A], because [reason].
By milestone
[Milestone name], due [date], [status]
Shipped: [ISSUE-KEY] [summary], merged in [PR link]
In review: [ISSUE-KEY] [summary], [PR link] open since [date]
Blocked: [ISSUE-KEY] [summary], blocked by [cause], needs [who/what]
Next week: [ISSUE-KEY] [summary], owner [name]
Mismatches to resolve
- Done, no code: [ISSUE-KEY], [owner's explanation or "checking with owner"]
- Waiting for review: [PR link] open since [date], reviewer [name or "not recorded"]
- Blocked with open code: [PR link] against [ISSUE-KEY]
- Stalled: [ISSUE-KEY], [owner's explanation or "checking with owner"]
Unlinked work (merged code, no ticket): [PR link], [proposed issue or "needs ticket"], or "none"
Shared PRs: [PR link] listed under [ISSUE-KEY] and [ISSUE-KEY], or "none"
Scope: Jira project [key]; repositories [list]; milestone field [field name]
Put the request first so the sponsor sees it even if they read nothing else. Make the request a choice with a recommendation, rather than an open question.
What prompt should the AI assistant use?
The AI assistant prompt should tell the assistant to read Jira and GitHub, join them by issue key, and group the work by your agreed milestone field. The prompt should flag every mismatch, take dates and owners only from the source data, and return a draft for you to review. Paste the prompt below into an assistant that can read both sources.
You are drafting a weekly status report for [sponsor name or role] on [project name].
Sources: Jira project [key] and GitHub repositories [list].
Window: [start date and time] to [end date and time], [time zone].
Milestone field: [Jira field name]. Group by this field only.
1. List Jira issues created, moved, or resolved in the window, with status, owner, and milestone exactly as Jira records them.
2. List GitHub pull requests opened, reviewed, or merged in the window.
3. Match PRs to issues by the Jira key in the branch name, PR title, or commit messages. Do not match by similarity of wording.
4. If a PR references several issue keys, list it under each issue and note "shared PR".
5. Group matched work by milestone under Shipped, In review, Blocked, and Next week.
6. Under "Mismatches to resolve", list:
- Done, no code: issues resolved in the window with no merged PR.
- Waiting for review: PRs open longer than [limit] without review, with the reviewer or "not recorded".
- Blocked with open code: PRs open against issues in a blocked status.
- Stalled: issues in an in-progress status with no linked commits or PR activity in the window.
7. List merged PRs with no issue key under "Unlinked work"; do not assign them to an issue.
8. Never invent a date, owner, estimate, or cause. If a field is missing in the source, write "not recorded".
9. Draft the "What we need from you" section only from blockers and decisions recorded in Jira; if none are recorded, write "No request this week" and I will add one.
10. Mark the output DRAFT FOR LEAD REVIEW. Do not send it.
Use the template below. [paste template]
Keep step 8 even if you trim the rest. Check every date and owner against the source before sending.
How does a blocker become the sponsor request?
A blocker becomes the sponsor request when the report turns it into a decision the sponsor can make: what is blocked, what the sponsor can do, by when, and what moves if nothing happens. Lead the report with that request, and keep the blocked item in its milestone so the sponsor sees the evidence behind it.
For example, a blocked line in the milestone section becomes this request at the top: "Approve [vendor] access by [date] so [ISSUE-KEY] can start; otherwise [milestone] moves to [date]." The illustrative block below shows the blocked line it comes from. Every value is a placeholder.
[Milestone name], due [date], at risk
Blocked: [ISSUE-KEY] [summary], blocked by [cause], needs [sponsor to approve access]
Settle each "Done, no code" line with its owner before sending. If the owner confirms no code was needed, note the reason in the team's version and drop the line from the sponsor's copy; if code is still due, move the issue back to In review or Next week.
How do you run the report on a schedule?
Run the weekly status report on a fixed day and time, in a stated time zone, before your sponsor meeting. You can set it up as a GitHub Actions cron job, as a scheduled AI agent run, or as a recurring slot where you run the prompt yourself. The output comes to you as a draft.
- A GitHub Actions cron job. The jira-weekly-report repository shows the pattern for Jira alone: GitHub Actions runs it every Monday at 10:00 Berlin time, and its README has a section on schedules and daylight saving time. For a combined report, agree these settings with whoever maintains your repository's workflows:
- Day and time: [day] at [time], before [sponsor meeting].
- Time zone: [time zone], with a check on how the schedule behaves when clocks change.
- Sources: read access to both Jira project [key] and repositories [list], not Jira alone.
- Delivery: [your email or chat channel] only, never the sponsor.
- A scheduled agent run. Confirm the agent you schedule can read both Jira and GitHub, not one of them. Save the prompt above with the window and milestone field filled in, and set the run for the same day and time each week. Unblockd lists its connectors as GitHub live-certified; Jira, Asana, Monday, Linear, ClickUp, and docs tools in early availability.
- By hand. Book a recurring slot on [day] before the sponsor meeting, paste the prompt into your assistant, and update the window.
What should you check before it goes to the sponsor?
Before the weekly status report goes to your sponsor, check that every claim traces to an issue or a pull request, and that every mismatch has an owner's answer or a clear next step. Then make sure the request at the top is specific enough for the sponsor to answer in one reply.
- Open a sample of the links and confirm the status matches what you see.
- Replace every "not recorded" with the real value, or leave it and say who is finding out.
- Confirm the overall status matches the milestone detail.
- Check that the request has options, a recommendation, and a date.
- Remove engineering detail the sponsor does not need, such as commit counts or branch names.
Once those checks pass, send it.