engineering-weekly-report
The engineering-weekly-report Claude Code skill generates a standardized weekly status report for engineering teams to share with stakeholders and leadership. Use it to produce team updates, sprint summaries, and standing communications that cover shipping progress, key metrics, decisions, blockers, and priorities in a scannable format designed for two-minute readability. The skill structures reports consistently week-over-week with required sections for work shipped, work in progress, blockers, decisions, risks, and next-week priorities, using tables and bullet points rather than prose to improve clarity and stakeholder comprehension.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/engineering-weekly-report && cp -r /tmp/engineering-weekly-report/plugins/pm-engineering/skills/engineering-weekly-report ~/.claude/skills/engineering-weekly-reportSKILL.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 | Item | Description | Impact | |------|-------------|--------| | [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 | Item | Owner | Status | Target 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 | Item | Blocked Since | Blocker Description | Owner | Needed 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.* | Metric | This Week | Last Week | Trend | Target | |--------|-----------|-----------|-------|--------| | 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 | Decision | Rationale | Owner | Stakeholders 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 | Decision | Context | Deadline | Decision 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 | Risk | Likelihood | Impact | Mitigation | Escalate 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 | Item | Status | |------|--------| | 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) | Sprint | Committe
Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.
Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.
Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.
Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.
Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.
Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.
Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.