The Problem
Every Friday afternoon, engineering leads scramble to write status reports for stakeholders. They check Jira for completed tickets, scan Slack for notable discussions, review git logs for shipped features, and try to remember what blockers came up in standup on Tuesday. The result is either a rushed bullet list too technical for executives ("merged PR #482 implementing batch endpoint for payment processing v2") or a polished document that took two hours to write — two hours that could have been a feature.
Multiply this by every team lead, and the company burns 10+ engineering hours per week on reporting. The VP of Engineering then spends another hour synthesizing three team reports into one executive summary. And the reports are still inconsistent — one lead writes a novel, another sends five bullet points, a third forgets entirely until Monday morning when the CEO asks what shipped last week.
The numbers are never quite right either. Someone reports 12 PRs merged, but the actual count is 14 because two landed after they wrote the report. Sprint velocity is an estimate from memory, not a calculation from the tracker. Last quarter, the CTO cited a velocity number in a board meeting that was 15% higher than reality — because the report it came from was based on a team lead's optimistic recollection, not actual data. The reports are a best-effort reconstruction of the week, assembled under time pressure by people who'd rather be writing code.
The Solution
Using the weekly-report, github, and report-generator skills, each team lead spends five minutes describing highlights and blockers while the agent pulls hard data from GitHub — merged PRs, releases, velocity metrics — and assembles a stakeholder-ready document. The VP gets a synthesized executive brief without reading three separate reports. Every number is verified, not recalled.
Step-by-Step Walkthrough
Step 1: Feed the Agent Your Sources
Tell the agent what to pull from and add the context that only a human knows:
Generate my weekly status report. Pull data from:
- GitHub: merged PRs in our-org/api and our-org/web repos this week
- This summary of key decisions: moved auth to JWT, postponed mobile launch to March
- Blockers: waiting on legal review for GDPR data export feature
Five minutes of input. The decisions and blockers are the pieces that can't be automated — they require human judgment about what's worth reporting and how to frame it. "We postponed mobile to March" needs context about why; "waiting on legal" needs context about what's at stake. Everything else — PR counts, release versions, velocity metrics — comes from the data.
Step 2: Data Collection and Categorization
The agent pulls GitHub activity for the week of Feb 10-14, 2026 and cross-references it with the context provided:
GitHub Activity:
our-org/api: 14 PRs merged, 3 releases (v2.14.1, v2.14.2, v2.15.0)our-org/web: 9 PRs merged, 1 release (v3.8.0)
Key PRs identified:
- #482: Implement batch payment processing (api)
- #489: Add retry logic for webhook delivery (api)
- #156: Redesign settings page with new nav (web)
- #161: Add dark mode support (web)
Not every PR makes the report. The agent distinguishes between feature PRs (stakeholder-relevant), bug fixes (worth mentioning if they affected users), and maintenance PRs (dependency updates, refactors, CI changes) and only surfaces the ones worth mentioning. Out of 23 merged PRs, maybe 6 are stakeholder-relevant. A Dependabot PR bumping lodash from 4.17.20 to 4.17.21 doesn't belong in a CEO-facing report; a PR that fixes a checkout bug affecting 2% of transactions does.
Everything gets categorized into Shipped, In Progress, Blocked, and Decisions Made — the structure stakeholders expect.
Step 3: Review the Draft Report
The agent produces a complete status report formatted for non-technical stakeholders:
Weekly Status Report — Engineering Week of February 10-14, 2026
Shipped This Week
- Batch payment processing — merchants can now process up to 500 payments in a single API call (v2.15.0)
- Webhook delivery retry logic — failed webhooks now retry 3x with exponential backoff, reducing integration failures
- Settings page redesign — new navigation structure with improved UX
- Dark mode — available to all users via settings toggle
In Progress
- GDPR data export feature — code complete, awaiting legal review (BLOCKED)
- Mobile app v2 — timeline shifted to March per team decision
Key Decisions
- Authentication migrating from session cookies to JWT tokens for API consistency
- Mobile app launch postponed to March to align with marketing campaign
Metrics
- 23 PRs merged across 2 repos
- 4 releases shipped
- Sprint velocity: 42 points (up from 38 last week)
Next Week
- Complete JWT migration (estimated 3 days)
- Begin QA cycle for data export feature once legal approves
- Start sprint planning for mobile v2
The difference between this and a manually written report: every number is pulled from actual data, not memory. The velocity metric, the PR count, the release versions — all verified against the source. No more "I think we merged about 20 PRs" when the actual number is 23. The "Shipped" items are written in business language (what it means for users) rather than technical language (what the PR did). "Merchants can now process up to 500 payments in a single API call" communicates value; "Merged PR #482 implementing batch endpoint" doesn't.
Step 4: Adjust Tone for Different Audiences
The same data can serve different readers. An executive doesn't need PR numbers; a board doesn't need sprint velocity:
Create an executive version — shorter, no technical details, focused on business impact and timelines.
The executive version strips out version tags and PR references, replacing them with business outcomes:
- "Merchants can now batch-process payments, reducing integration effort for large customers" instead of "Shipped batch payment processing endpoint in v2.15.0"
- "GDPR compliance feature delayed — pending legal review, expected resolution next week" instead of "GDPR data export feature code complete, PR #478 merged, awaiting legal sign-off on data retention fields"
Risk items and timeline changes get promoted to the top — the executive cares about what's at risk, not what shipped cleanly. Technical details disappear. What remains is a one-page brief that answers three questions: what moved forward, what's stuck, and what does the executive need to know or decide.
Here's how the same information looks in each version:
Engineering report: "GDPR data export feature — code complete, awaiting legal review (BLOCKED). PR #478 merged, data retention fields need legal sign-off per Article 17 compliance."
Executive report: "GDPR compliance feature delayed 1 week — pending legal review. No customer impact. Expected resolution by Feb 21."
Same fact, different framing. The engineering report includes the technical detail. The executive report includes the timeline and business impact.
One data collection step, two reports — each tuned to its audience. The same approach works for board-level summaries, investor updates, or cross-functional reports for the product and marketing teams.
Step 5: Build the Weekly Rhythm
A single good report is useful. A consistent weekly report is transformative. The real payoff comes from making this repeatable:
Save this report format as a template. Every Friday at 4pm, pull the latest GitHub data for the same repos, apply the same format, and draft a report for my review. I'll add decisions and blockers before sending.
The template locks in the format so reports are consistent week to week — same sections, same tone, same level of detail. The agent pre-fills everything it can from data sources, leaving placeholders for the human-only context: key decisions, blockers, and next-week priorities. A five-minute review, a few edits, and it's sent — instead of the Friday afternoon scramble.
Over time, the templates build institutional memory. Want to see what shipped last March? Pull up the March reports. Need to explain to the board why the mobile launch was delayed? The weekly reports track the decision across three weeks of updates. The reports become a timeline of the product, not just a status check.
Real-World Example
Priya is the VP of Engineering at a 40-person startup with three engineering squads. Each lead used to write their own report in their own format, and Priya spent an hour every Friday evening stitching them into an executive update. The platform team wrote a detailed technical log. The growth team sent a Slack message with three bullet points. The infrastructure team's report was two weeks old because the lead kept forgetting.
Now each squad lead spends five minutes telling the agent their highlights, blockers, and decisions. The agent pulls GitHub data for each squad's repos and generates individual team reports with consistent formatting. Priya asks the agent to combine all three into an executive summary with a risks section. Out comes a one-page brief highlighting shipped features, at-risk timelines, and resource needs — formatted the way the CEO expects it.
What used to take 3 hours across the team now takes 15 minutes total. The reports are more consistent, more data-accurate, and arrive on time every Friday — even when the infrastructure lead is out sick. The CEO stopped asking "what shipped last week?" because the answer lands in their inbox before they think to ask.
The unexpected benefit: the historical reports became a decision log. When a stakeholder asked in Q3 why the mobile launch was delayed, Priya pulled up the weekly reports from February through April showing the progressive timeline shifts and the reasons behind each one. No revisionist history, no he-said-she-said — just a factual record assembled from data every week.