---
name: weekly-engineering-retro
description: "Turns a week of commits and incidents into a short retro: what shipped, what hurt, and the single change to try next week. Use when an engineering lead needs a short weekly retrospective built from commit history and incident records instead of from memory. Do not use for post-incident reviews for a single outage or annual performance reviews. Related topics: productivity, coding."
---

# Weekly Engineering Retro

Turns a week of commits and incidents into a short retro: what shipped, what hurt, and the single change to try next week.

## When to use

Use this skill when an engineering lead needs a short weekly retrospective built from commit history and incident records instead of from memory. Do not use it for post-incident reviews for a single outage or annual performance reviews.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Group the week's commits into themes and write what shipped in plain language.
3. Compare the results with last week's goals and mark each as met, partly met, or missed.
4. List what hurt, with numbers for incidents, review waits, and rework, and name the likely root cause of the biggest pain.
5. Choose exactly one change for next week with an owner and a success signal.
6. Keep the retro under 400 words and finish with next week's proposed goals.

## Inputs

- **Week covered** (free text, e.g. "Date range")
- **Commit log or merged PRs** (longer free text)
- **Incidents and alerts** (longer free text)
- **Goals set last week** (longer free text)
- **Team mood or blockers** (longer free text)
- **Audience** (choose one: Team only, Team and manager, Wider company)

## Output

A retro under 400 words with sections for shipped work, goals status, what hurt, one change with owner and signal, and next week's goals.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Weekly Engineering Retro

Write this week's engineering retro from the evidence.

- Week covered: {{Week covered}}
- Commit log or merged PRs: {{Commit log or merged PRs}}
- Incidents and alerts: {{Incidents and alerts}}
- Goals set last week: {{Goals set last week}}
- Team mood or blockers: {{Team mood or blockers}}
- Audience: {{Audience}}

Group the commits into themes and write what shipped in plain language, tied to the goals set last week; say which goals were met, partly met, or missed. Next, list what hurt: incidents with their duration and cause, slow reviews, flaky tests, and work that was redone. Use numbers where the data has them, such as merged PRs, average review wait, and incident minutes. Name the most likely root cause behind the biggest pain rather than listing symptoms. Pick exactly one change for next week, with an owner and a way to tell whether it worked. Keep the whole retro under 400 words, blame no individual, and end with the goals proposed for next week.

## Pitfalls

- Proposing five improvements, so none of them happens.
- Naming individuals in the 'what hurt' section, which turns a retro into blame.
- Listing commits one by one instead of summarising by theme.