Wardn HubTrusted MCP server directory.

Registry

  • MCP Servers
  • Skills
  • Categories

Resources

  • API docs
  • Score method

Contribute

  • Submit server
  • Advertise
© 2026 Wardn Hub
Wardn Hub
MCP ServersSkillsCategoriesAPI docsSubmit server
Submit server
skills/mohitagw15856/pm-claude-skills/engineering-weekly-report

engineering-weekly-report

1
mohitagw15856/pm-claude-skills·Audit passed·Snapshot 91c848bd812d

Summary

This source did not publish a separate summary. Review SKILL.md before using the skill.

SKILL.md

Engineering Weekly Report

Produce a weekly engineering status report that a team can send to stakeholders, their engineering manager, and the team itself. The format is fixed week-over-week so readers know exactly where to look — shipping progress at the top, decisions in the middle, risks and next steps at the bottom. The report must be readable in under 2 minutes. Avoid prose walls: use bullet points, status tags, and short tables. If metrics are not provided, leave the metrics section with [data needed] markers rather than fabricating numbers.

Required Inputs

Ask for these if not already provided:

  • Team name and report period — team name plus week number or date range (e.g., "Platform Team, Week 21, May 12–16")
  • Work items shipped this week — what was completed and released or merged
  • Work items in progress — what is actively being worked on, with rough percent-complete if known
  • Blocked items — what is blocked, who owns the block, and what is needed to unblock
  • Key decisions made — any architecture, process, or priority decisions made this week
  • Decisions needed next week — any decisions that need to be made soon and who needs to make them
  • Risks and escalations — anything that threatens next week's commitments or needs leadership visibility
  • Next week's top priorities — the 3–5 things the team plans to accomplish next week

Optional but useful:

  • Key metrics — reliability (error rate, p99 latency), velocity (story points completed), or other health indicators
  • Team health notes — PTO, new joins, attrition, morale signals worth noting
  • Sprint or iteration number — if the team runs sprints

Output Format


Engineering Weekly Report — [Team Name]

Week: [Week Number] | [Date Range, e.g., May 12–16, 2025] Author: [Name or Team Lead] Distribution: [e.g., Eng leadership, Product, Team]


Shipping Progress

Shipped This Week

ItemDescriptionImpact
[Feature / Fix / Infra change][One-line description][Who benefits / what it unblocks]
[Feature / Fix / Infra change][One-line description][Who benefits / what it unblocks]
[Feature / Fix / Infra change][One-line description][Who benefits / what it unblocks]

In Progress

ItemOwnerStatusTarget Ship
[Work item][Name][~40% / On Track / At Risk][Date or Sprint]
[Work item][Name][~70% / On Track / At Risk][Date or Sprint]
[Work item][Name][~20% / On Track / At Risk][Date or Sprint]

Blocked

ItemBlocked SinceBlocker DescriptionOwnerNeeded To Unblock
[Work item][Date][What is blocking progress][Name][Specific ask — decision, resource, dependency]

If no items are blocked: No active blockers.


Key Metrics

Metrics reported as of [Date]. Prior week in parentheses.

MetricThis WeekLast WeekTrendTarget
Error rate (5xx)[X%][X%][↑ / ↓ / →]< [threshold]
p99 latency[Xms][Xms][↑ / ↓ / →]< [threshold]
Deployment frequency[X deploys][X deploys][↑ / ↓ / →][target]
Story points completed[X][X][↑ / ↓ / →][sprint target]
On-call page volume[X pages][X pages][↑ / ↓ / →]< [threshold]

Metrics notes: [Any context that makes the numbers meaningful — e.g., "Error rate spike on Tuesday tied to downstream dependency outage, resolved by EOD."]

If metrics are not provided: replace table rows with [data needed — provide metric values for this section].


Decisions

Made This Week

DecisionRationaleOwnerStakeholders Informed
[Decision description][Why — 1 sentence][Name][Yes / No — who]
[Decision description][Why — 1 sentence][Name][Yes / No — who]

If no decisions were made: No major decisions this week.

Needed Next Week

DecisionContextDeadlineDecision Owner
[What needs to be decided][Why it matters, what happens if delayed][Date][Name or role]

If no decisions are pending: No decisions pending.


Risks and Escalations

RiskLikelihoodImpactMitigationEscalate To
[Risk description][High/Med/Low][High/Med/Low][What we're doing about it][Name/role if escalation needed]

Escalations this week: [Any item that needs immediate leadership attention — call it out explicitly here, do not bury it in a table row. If none: "None."]


Team Health

ItemStatus
Team capacity this week[X of Y people at full capacity]
PTO / out of office[Names and dates, or "None"]
New joins / departures[Name, role, and date, or "None"]
On-call this week[Name]
On-call next week[Name]

Team notes: [Any morale, workload, or team dynamic signals worth surfacing — keep this factual and constructive. If nothing to note: omit this line.]


Next Week's Priorities

The [3–5] things this team will ship or meaningfully advance next week.

  1. [Priority item] — [One sentence: what done looks like and who owns it]
  2. [Priority item] — [One sentence: what done looks like and who owns it]
  3. [Priority item] — [One sentence: what done looks like and who owns it]
  4. [Priority item] — [One sentence: what done looks like and who owns it]
  5. [Priority item] — [One sentence: what done looks like and who owns it]

Capacity risk: [If the team is at reduced capacity next week (PTO, incidents, etc.), note it here so stakeholders calibrate expectations.]


Appendix: Sprint Scorecard (if applicable)

SprintCommittedCompletedCompletion RateCarried Over
Sprint [N-1][X pts][X pts][X%][X pts]
Sprint [N] (current)[X pts][X pts — partial][X% at midpoint]TBD

Questions or corrections: [Slack channel or email] | Next report: [Date]


Quality Checks

  • Every blocked item names a specific owner and states what is concretely needed to unblock it — not just "waiting on X"
  • Decisions-needed table includes a deadline and a named decision owner, not a vague "TBD"
  • Metrics table is either populated with real numbers or explicitly marked [data needed] — no fabricated metrics
  • Next week's priorities are written as outcomes ("ship X", "complete Y migration") not as activities ("work on X")
  • Escalations that need leadership attention are called out explicitly in the Risks section — not just buried in a table row
  • The entire report is readable in under 2 minutes — if it is longer than one printed page, trim it
  • Report period (week number and date range) is clearly stated in the header

Anti-Patterns

  • Do not fabricate metrics — if data is not available, mark the field as [data needed] rather than estimating; stakeholders making decisions on invented numbers is actively harmful
  • Do not write next week's priorities as activities ("work on X") — they must be outcomes ("ship X", "complete Y migration") so stakeholders can evaluate whether the team delivered
  • Do not bury escalations inside a risk table row — anything needing leadership attention must be called out explicitly in the Escalations section
  • Do not list blocked items without naming a specific owner and a concrete unblocking action — "waiting on X" is not a blocker entry, it is a placeholder
  • Do not write a report that exceeds two printed pages — length signals the author has not done the editorial work of deciding what matters to stakeholders

Related skills

capacity-planningcompetitor-teardowncontext-engineering-reviewrunbook-writerreceipts-audit