Code RoomRelease notes generation
EasyPrep Room Coding #8

Release notes generation

Vibe & agenticAI agents & automationEntry–Mid~12 min

Every release, someone spends an afternoon turning merged pull requests into release notes. Design an agent to draft them. Where does it get its facts, how does it decide what's customer-visible versus internal, and who signs off before anything ships to users? Notes that oversell or invent features are worse than dry ones — how would you check the agent against past releases before using it, and how would you pitch this to the team?

Implement
route_release_note_entries(pr_records: list[str]) → list[str]
Examples
in[["feature|PR-101|adds dark mode toggle to settings","chore|PR-102|bump lockfile deps","feature||new export button"]]out["customer","internal","unsorted"]
in[["fix|PR-110|Blazing fast search fix"]]out["unsorted"]
in[[" perf | PR-7 | reduces page load time "]]out["customer"]
What a strong answer looks like

Turn the fuzzy goal into a bounded agent task. Say what the agent reads, what it may do on its own versus draft for a human, and what it must never touch. Then earn the trust: how you’d verify it before rollout, and the pitch (the problem, what you built, why it matters).

0:00 of about 12 min

Agent build: design the agent in plain language (or narrate it). The coach grades the decomposition, the guardrails, the verification plan, and the pitch.

Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.