---
name: reinvent-team
description: Plan re:Invent for a group — divide sessions so nobody duplicates coverage, find the gaps nobody is covering, and write the justification a manager or VP needs. Use when the user says "my team is going", "split this across N people", "divide and conquer", "what's our coverage", or needs to justify the trip.
---

# Plan re:Invent for a team

Five people at the same five sessions is four wasted badges. The job is
coverage, then a debrief plan.

## Needs one profile per attendee

> **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 validate-profile --profile profiles/sam.json
```

Missing profiles → run `reinvent-profile` for each person. Do not invent
teammates' goals from their titles; a 30-second ask in Slack beats a guess, and
a wrong profile sends someone to the wrong week.

If you genuinely cannot reach someone, build a profile from their role, **label
it an assumption in `notes`**, and say so when presenting.

## Run it

```bash
python3 -m reinvent coverage \
  --profile profiles/sam.json \
  --profile profiles/riley.json \
  --profile profiles/kai.json \
  --per-person 8 \
  --out coverage.md
```

Each session is assigned to whoever values it most and still has room. The
report gives per-person assignments, a contested list, topic coverage counts,
and the gaps.

**What `--per-person` actually means**, because the number matters and 8 is not a
magic value: it caps how many sessions get assigned to each attendee. This is a
research-phase split of a shortlist, not a calendar — people need more candidates
than they can attend, because sessions fill and days collapse. A useful rule:
give each person roughly **twice** what they will actually sit through.

| Attendee | Sessions they will attend | `--per-person` |
| --- | --- | --- |
| IC / engineer, 4–5 a day | ~20 across the week | 8–10 |
| Manager, 3 a day with gaps | ~12 | 5–6 |
| Exec, 2–3 a day | ~10 | 4–5 |

Mixed group? Run it at the highest number the group justifies and let the
per-person caps in each profile do the trimming later, rather than starving the
engineers to suit the exec.

## What to parallelize, and what not to

**Do not fan out the coverage assignment.** One `coverage` run scores every
session against every profile and assigns them in a single pass. Splitting it
across agents is slower and produces inconsistent weights between people, which
defeats the whole point of a shared plan.

**Do not fan out the profile interviews.** Each one needs the actual human. An
agent cannot reach your teammates, and a profile invented on someone's behalf
sends them to the wrong week. Ask them in Slack, or run `reinvent-profile` with
each person present.

**Do fan out the per-person review, after coverage exists.** One agent per
attendee, all dispatched in a single message, each given that person's assigned
list plus their mission, answering: does this list actually serve this person's
stated mission, and what is the obvious gap? That is N independent reads whose
raw material you never need again — exactly what a subagent is for.

**Do fan out session-quality research** across attendees' assigned lists, using
the recipe in `reinvent-shortlist`. For a team trip this matters more than for one
person: a sponsor pitch or a repeat-with-a-recording wastes a whole badge-day.

Cap concurrency at 4–6, give each agent a disjoint slice, and require a source URL
per claim. See [`docs/parallel-research.md`](../../docs/parallel-research.md).

## The three sections that matter

1. **Contested** — sessions more than one person wanted. One attends; that
   session goes on the debrief agenda. This is where the leverage is: it is the
   difference between three people hearing something and the whole team knowing it.

   The tool assigns these by score, which breaks ties arbitrarily. When two
   people genuinely both want one, decide it on **who will act on it**, not who
   scored higher: the person who owns the system it affects, or who has to make
   the decision it informs, should be in the room. The other gets the debrief and
   the follow-up conversation. Say out loud which rule you applied — a silent
   reassignment reads as the tool being wrong.

   If a contested session is offered more than once in the week, the honest
   answer is that both can go; check `explain <CODE>` for its repeat slots before
   you make anyone give it up.
2. **Gaps** — topics the team said it cares about with nobody attending. Either
   assign someone, or make an explicit decision to skip. An unnoticed gap is how
   a team comes home without the one answer it needed.
3. **Topic coverage counts** — if one topic has nine sessions and another has
   one, check whether that matches the team's actual priorities for next year.

## How many people should go?

Managers ask this and the honest answer is not a formula. Do not invent an ROI
number or a per-head break-even — you have no data for it, and a fabricated
figure is the fastest way to lose a VP's trust.

What you can reason about is **missions**. Send one attendee per distinct
decision the trip has to inform. Two people with the same mission mostly hear the
same content, so send one and spend the difference on making the debrief real.
Two people with genuinely different missions cover ground one person cannot,
and the coverage report shows exactly how much: topics covered, and the gaps
that remain even with everyone there.

So the useful framing for the manager is: *"here are the N decisions we need
answered, here is who owns each, here is what we still will not cover."*
If two of those N collapse into one person's week, the headcount is too high.

## For the manager or VP: the justification

A trip for N people needs a defensible case. Build it from the coverage output,
not from adjectives — and **not from invented money.**

### Never fabricate a figure

This is the one rule to get right, because it is the one that destroys the
document. An evaluation run produced a justification containing `$500k` of
"wasted engineering time", `$30–50k/year in easy cost savings`, `$20–30k` in
tooling licences, invented hotel and meal rates, and "payback in less than two
months" — when the only real number anyone had given was the trip's total cost.
A VP who spot-checks one of those and finds it was guessed stops believing the
whole page, including the parts that were true.

So:

- **Use only figures the user gave you, or ones you can cite.** The registration
  price is published and verifiable; a hotel rate you did not look up is not.
- **No ROI, payback period, or break-even claims.** You cannot know the value of
  a decision made faster, so do not put a number on it. Saying "this informs a
  Q1 decision we would otherwise make on guesswork in March" is honest and
  persuasive; "$100k saved" is neither.
- **Quantify the things you actually have.** Sessions assigned, topics covered,
  attendees, gaps accepted, decisions informed — all of these come out of the
  coverage report and none require invention.
- If the user wants a cost breakdown, ask them for their real numbers or say
  plainly that you would be guessing. `evals/check_outputs.py --allow-amount`
  exists to catch exactly this and will flag any figure you did not source.

Then the substance:

- **What decisions this trip informs.** Pull from each profile's `mission`.
  "We will decide whether to adopt X in Q1" is a reason; "team development" is
  not.
- **Coverage math.** N attendees, M sessions, K distinct topics, versus what one
  attendee could cover alone. The coverage report has these numbers.
- **The debrief commitment.** Who writes it, who it goes to, by when. A trip with
  no debrief plan is a trip you will be asked to justify again next year.

  **Do not write the debrief structure yourself — load the `reinvent-debrief`
  skill.** It ships with this pack and covers the format, the owner-and-date rule
  for action items, and how to run a team debrief off the contested list. An
  evaluation run invented its own debrief template while this skill was sitting
  next to it unread, so name it explicitly rather than assuming it gets found.
- **What is deliberately not covered.** Naming the gaps you chose to accept is
  what makes the rest credible.

Keep it under a page. Executives reading it want the decision, not the agenda.

## Coordination the tool cannot do for you

Say these out loud to the group:

- **Interactive sessions fill in minutes.** Whoever is assigned a workshop or
  builders' session needs to reserve it the hour reservations open, not that
  evening.
- **Do not all sit together.** Splitting up across rooms is the entire point of
  the plan.
- **One shared notes doc, one page per session**, written the same day. Nobody
  remembers Tuesday by Friday.
- **Book one team dinner mid-week** to compare notes while the week is still
  changeable. It is worth more than a sixth session.

## Re-run after every catalog wave

New content lands in waves and reshuffles assignments. Re-run coverage after
`reinvent-watch` reports a drop, and tell people specifically what changed for
them — not just that something changed.