---
name: reinvent-debrief
description: Turn re:Invent session notes into a trip report with decisions, owned action items, and what to stop doing. Use during or after the event when the user says "write up my notes", "trip report", "debrief", "what did we learn", or a manager needs the readout that justified the trip.
---

# Write the re:Invent debrief

Most of the value of a conference leaks out in the two weeks after it. The
debrief is how you keep it — and for a manager or VP, it is the artifact that
justifies next year's budget.

## Inputs

Whatever the user has: raw notes, a shortlist, an agenda file, photos of chalk
talk boards, Slack messages to themselves. Pull the session metadata for
context:

> **Where to run these.** Every command below needs the planner repo on the
> Python path. If there is no `reinvent/` directory in the current working
> directory, you are not in it — resolve this skill's own base directory (printed
> when the skill loaded, and usually a symlink), then go two levels up: that is
> the repo root. `cd` there first, or call `<repo>/bin/reinvent <command>` by
> absolute path, which works from anywhere. Do not tell the user to install
> anything; there are no dependencies.

```bash
python3 -m reinvent search --code SEC301 --code NET313 --limit 20
```

That gives real titles, levels, formats and abstracts, so the write-up cites
sessions accurately instead of from memory.

## The shape that gets read

```markdown
# re:Invent 2026 — <name or team>

## Bottom line
Three sentences. What we now believe that we did not believe before.

## Decisions this changes
- <decision> — <what we heard, which session> — <who decides, by when>

## Adopt
- <thing> — why, rough effort, who would own it

## Stop or defer
- <thing we were going to do> — why the trip changed our mind

## Action items
- [ ] <action> — <owner> — <date>

## Sessions worth your hour (with codes)
- CODE — Title — one line on why, and a link if it is recorded

## What I got wrong going in
Where the plan or our assumptions did not survive contact.

## Sources
Session codes, speaker names, links to recordings and repos.
```

Lead with **Bottom line** and **Decisions**. A VP reads two sections; make them
the ones that matter.

## Rules that keep it honest

- **Every action item has a named owner and a date.** An unowned action item is
  a wish. If the user will not name someone, mark it `unowned` explicitly rather
  than quietly leaving it blank.
- **Cite the session.** "AWS said X" is unverifiable six months later; "SEC301
  chalk talk, AWS said X" can be checked.
- **Separate what AWS shipped from what AWS previewed.** Preview features slip.
  Building a Q1 plan on a preview is how teams get burned — label them.
- **Keep the "what I got wrong" section.** It is the most useful section for
  planning next year and the first one people cut. Do not cut it.
- **Do not invent content for a session the user did not attend.** If notes are
  thin, say the notes are thin.

## Team debriefs: one agent per attendee

A team trip produces several people's raw notes, and pulling all of them into one
context makes the synthesis worse, not better. Dispatch one subagent per
attendee, all in a single message, each given only that person's notes and asked
for a structured extract: decisions this changes, claims with the session code
behind each, action items with a proposed owner, and anything they flagged as
preview-not-GA.

Then synthesize the extracts yourself. The parent conversation holds the merged
picture; the raw notes stay out of it.

Two constraints for those agents: every claim must carry the session code it came
from, and **thin notes must be reported as thin**, not padded from general AWS
knowledge. A confident summary of a session nobody took notes on is the worst
possible output here. See
[`docs/parallel-research.md`](../../docs/parallel-research.md).

Verifying session titles and levels is a single fast local command
(`python3 -m reinvent search --code ...`) — do not spawn an agent for that.

## Team debriefs

If the trip used `reinvent-team`, the coverage report's *contested* list is the
debrief agenda — those are the sessions multiple people wanted and one person
saw. Structure it as: 10 minutes per attendee on their two highest-value
sessions, then one collective pass on decisions.

Send the write-up within a week. Later than that and nobody acts on it.

## Feed it back into the tooling

Close the loop so next year starts smarter:

- Update the attendee's profile: weights that produced good sessions go up,
  weights that produced duds go down. Note it in the profile's `notes`.
- Record which session *types* actually delivered for this person. Someone who
  found every breakout forgettable and every chalk talk useful should have that
  reflected in `types.prefer` before next year.