engineering-weekly-report

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
name: engineering-weekly-report
description: "Write a weekly engineering status report for a team, service, or initiative. Use when asked to write a team update, weekly engineering report, sprint status email, or standing team communication to stakeholders. Produces a concise, scannable weekly report covering shipping progress, metrics, decisions, blockers, and next-week priorities."
---

# 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 downstrea