--- name: reinvent-profile description: Interview someone about their re:Invent goals and write a scored profile JSON for them. Role-aware — an engineer, a manager, and a VP need different weeks. Use when there is no profile in profiles/, when the user says "set up my re:Invent profile", or when their role or mandate changed since last year. --- # Build a re:Invent attendee profile The profile is the only thing that makes ranking meaningful. A bad profile produces a confident, useless shortlist. Spend the interview. ## Rules for the interview 1. **Ask, do not assume.** A job title does not tell you what someone needs from the week. Two staff engineers on the same team can have opposite weeks. 2. **Five questions, maximum, in one pass.** Use `AskUserQuestion` with real options. People planning a conference are busy and will abandon a wall of prose. 3. **Push for the outcome, not the topic list.** "Kubernetes" is a topic. "Decide whether we adopt Karpenter in Q1" is a mission. The mission is what makes the shortlist argue with them later. 4. **Get the anti-goals.** What they want to *avoid* is as informative as what they want. Exam prep? Vendor pitches? 8am sessions after a late night? ## Questions that earn their place - **Mission** — "If the week produces exactly one outcome, what is it?" - **Seniority / how they consume content** — offer the real trade-off: hands-on depth (`ic`), team-adoption decisions (`manager`), or strategy and roadmap signal (`exec`). Do not infer this from their title; a VP who still writes code may want `tech-lead`. - **Live problems** — "Name two things currently broken or blocked that a session could unblock." These become `keywords.boost`. - **Calendar reality** — how many sessions a day is honestly sustainable, and what hours are off-limits (executive briefings, dinners, the flight home). - **Deal-breakers** — formats or topics to exclude outright. ## Then write the file Write it to `/profiles/.json` — lowercase first name, e.g. `profiles/dana.json`. That directory already exists and holds the shipped `example-*.json` templates; leave those alone. **Only `name` is required.** Everything else is optional and the tool has sensible defaults, so a short honest profile beats a padded one. In practice the sections that change the output most are `topics`, `areas`, `services`, `keywords.boost` and `constraints` — a profile with just those five is fine. Shape (full field reference in [`docs/profile-schema.md`](../../docs/profile-schema.md)): ```json { "name": "Full Name", "seniority": "ic | tech-lead | manager | director | exec", "role": "", "mission": "one sentence, outcome-shaped", "goals": ["...", "..."], "levels": { "preferred": [300, 400], "acceptable": [200] }, "topics": { "Security & Identity": 4 }, "areas": { "Kubernetes": 3 }, "services": { "AWS Organizations": 4 }, "types": { "prefer": { "Chalk talk": 3 }, "avoid": ["Exam prep"] }, "keywords": { "boost": { "multi-account": 4 }, "exclude": [] }, "constraints": { "max_sessions_per_day": 4, "laptop_ok": true, "no_before": "09:00" }, "notes": "anything a human should know when reading the shortlist" } ``` **Weights are 1–5.** Reserve 4–5 for things tied to the mission. If everything is a 5, nothing is. **Avoid filler topics.** `Architecture` and `Cloud Operations` are true of almost everyone in cloud infrastructure, so they carry no signal — a topic that would appear on every one of this person's teammates' profiles is noise, not a preference. It also does real damage on a team plan: shared filler topics inflate everyone's score on the same sessions and manufacture contention that is not real. An evaluation run gave two engineers with very different jobs — one on EKS, one on CI/CD and Terraform — identical topic lists for exactly this reason. Prefer the narrowest facet that is actually true (`Containers`, `Developer Tools`), and put the specific thing in `keywords.boost` where it belongs: `terraform`, `karpenter`, `iceberg`. That is what distinguishes two people who both work "on the platform". ## Use the catalog's own vocabulary Facet values must match the catalog exactly or they score nothing — silently. Each profile section draws from a different facet, and mixing them up is the most common way a profile ends up quietly wrong: | Profile section | Catalog facet | Check with | | --- | --- | --- | | `topics` | `topic` (18 values) | `facets --facet topic` | | `areas` | `areaofinterest` (48 values) | `facets --facet areaofinterest` | | `services` | `services` (124 values, verbose) | `facets --facet services` | | `industries` | `industry` (14 values) | `facets --facet industry` | | `role` | `role` (15 values) | `facets --facet role` | | `types.prefer` / `types.avoid` | `type` (10 values) | `facets --facet type` | | `keywords.boost` / `.exclude` | none — free text over title + abstract | no check needed | Watch the boundary between `topics` and `areas` specifically: `Migration & Modernization` is a **topic**, while `Cost Optimization` is an **area**. Both sound like either. Pull them all in one go rather than three separate calls: > **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 `/bin/reinvent ` by > absolute path, which works from anywhere. Do not tell the user to install > anything; there are no dependencies. ```bash python3 -m reinvent facets --facet topic --facet areaofinterest --facet industry --facet role --facet type python3 -m reinvent facets --facet services | grep -i -E 'kubernetes|lambda|organizations' ``` Service names are long and easy to get wrong — it is `Amazon Elastic Kubernetes Service (Amazon EKS)`, not `Amazon EKS`. Anything that is a product name, a phrase you expect in an abstract, or a problem the user is having goes in `keywords.boost` instead, which needs no facet match. Always finish with: ```bash python3 -m reinvent validate-profile --profile profiles/.json ``` Fix every term it reports. The errors tell you what to do — a misfiled value names the section it belongs in, a typo gets a "did you mean", and an abbreviation gets the full catalog name. On success it prints a count of what matched, which is your confirmation the profile will actually score against something. ## Calibrating by seniority The scorer already biases levels and formats by `seniority`, so do not double-encode it in `types.prefer`. What you *should* tune per person: | Seniority | Sessions/day that actually work | Watch for | | --- | --- | --- | | `ic` / `tech-lead` | 4–5 | Wants workshops and builders' sessions; those need a laptop and fill fastest | | `manager` | 3–4 | Needs gaps for team dinners and vendor meetings; rarely wants hands-on | | `director` / `exec` | 2–3 | Calendar is mostly briefings; sessions are for signal, not depth | ## Finish by showing your work Run a shortlist immediately and show the top five with reasons: ```bash python3 -m reinvent shortlist --profile profiles/.json --limit 10 ``` Leave `--out` off for this one. With `--out` the markdown goes to the file and only "Wrote …" comes back to you, so you cannot see what you are about to show the user. Read it on stdout first, then re-run with `--out` if they want it saved. Ask "does this look like your week?" Wrong-looking results almost always mean a weight is off, not that the tool is broken — adjust and re-run. Iterating here is cheap; iterating in Las Vegas is not.