A reviewer for the shared library

A shared library lives or dies by a rule that is usually nowhere in writing: you may add surface, but you must never change or remove what existing consumers depend on. A new event type is fine; a new optional parameter is fine. Renaming an exported function, tightening a signature, changing what an existing call returns - those ripple out to every importer and break code you cannot see. In this course’s scenario the library is shared-lib, and a dozen services consume it; in yours, however many consumers your library has.

Without a custom agent, you enforce that rule by hand: every session opens with “remember, this library has many consumers, additive-only, watch for…” - phrased slightly differently each time, and skippable on a tired day, which is exactly the day a breaking change slips through. The rule is too important to depend on memory. Put it in the agent.

The persona is the rule, written down once

Create .github/agents/library-reviewer.agent.md - with /create-agent, or written directly. The body is where the rule lives, as a short checklist: exported signatures must not change in breaking ways, contracts such as sort order must be documented and tested, new exports need tests, and downstream consumers must not break. The last line states the rule outright: be strict about backwards compatibility, because many services consume this library.

That body is the entire value. The library’s compatibility contract is written once, and a persona carries it into every review without you re-typing a word.

The complete file:

.github/agents/library-reviewer.agent.md

---
name: library-reviewer
description: Reviews changes to shared-lib for breaking changes and API contract violations.
tools:
  - read
  - search
---

You are a library reviewer for @acme/shared-lib.

When reviewing changes:

1. Check that exported function signatures have not changed in breaking ways.
2. Verify that sort order contracts are documented and tested.
3. Ensure money formatting uses integer cents as input.
4. Flag any new exports that lack corresponding tests.
5. Check that downstream consumers in orders-service are not broken.

Be strict about backwards compatibility. This library is consumed by multiple services.

The model field is deliberately absent. The reviewer does not need a specific pinned model to hold one rule faithfully, and model names churn; if you later find it reasoning too shallowly on gnarly diffs, the Models chapter covers pinning one deliberately.

Scope its tools to its job

A reviewer reviews. It reads code, reasons about compatibility, and reports - it does not need to rewrite files while judging them. So its tools list is exactly what review requires: the read and search tool sets to open files and explore the codebase, nothing that edits (tool-set names per the VS Code features cheat sheet, checked September 2026). That is not a formality. On a repo where the whole point is not changing things by accident, a narrow tool list is what makes the agent trustworthy. You can summon library-reviewer, hand it a diff or a plan, and know its lane is judgment.

Set its description to the one line the dropdown shows - something a teammate skimming the agent list reads as “the thing that checks library changes for breakage.” Give it a name you will recognize. Summoning it means selecting it from the agents dropdown - the same picker that selects the Ask, Plan, and Agent roles. Any time anyone touches the library, they summon the same persona applying the same rule, instead of improvising the review from scratch.

Why a persona beats a prompt here

Why not just a prompt file? A prompt file is a task you run; a custom agent is an identity you adopt for a stretch of work. A library review is not one prompt - it is a posture held across a whole conversation: reading a file, answering a follow-up, checking a second file, weighing a tradeoff, all under the same additive-only lens. What a persona adds over phrasing the same rule in a prompt: a named identity anyone on the team summons the same way, tools scoped to its lane, and one rule written once instead of re-phrased per session - which is what earns its keep when the stakes are a dozen consumers deep.

A reviewer judges your change. To ship the library update you also need the inverse question answered: does the change break any consumer as it exists today? That is not one review - it is one per consumer, and you do not want to run them serially by hand. Next: fan subagents out across the consumers.