A reviewer for the shared library

Now build the agent the whole act needs. shared-lib has a rule that every change lives or dies by, and it’s not written down anywhere a stranger could find it — it’s in the heads of the people who maintain it. The rule is: you may add surface, but you must never change or remove what existing consumers already depend on. A new audit-event type is fine; a new optional validation rule is fine. Renaming an exported function, tightening a signature, changing what an existing call returns — those ripple out to twelve services and break code you can’t see. That’s the line library-reviewer exists to hold.

The persona is the rule, written down once

Without a custom agent, you’d enforce that rule by hand. Every session you’d open with “remember, this library has a dozen consumers, so additive-only, no breaking changes to exported surface, watch for…” — and you’d phrase it slightly differently each time, and some day you’d be tired and skip it, and that’s the day a breaking change slips through. The whole reason this lesson is the second one in the chapter is that the rule is too important to depend on your memory.

So put it in the agent. Create .github/agents/library-reviewer.agent.md — use /create-agent and describe it, or write it directly. The body is where the rule lives, in plain prose: this agent reviews proposed changes to a shared library that roughly twelve services depend on; its job is to catch anything that changes or removes existing exported behavior; additive changes are acceptable, breaking changes are not; when it finds a breaking change it should name exactly what would break and suggest the additive alternative.

That paragraph is the entire value. You wrote the library’s compatibility contract once, and now a persona carries it into every review without you re-typing a word.

Scope its tools to its job

A reviewer reviews. It reads code, reasons about compatibility, and reports — it doesn’t need to be rewriting files while it’s supposed to be judging them. So scope its tools to what review actually requires: the ability to read and search the codebase, not the full builder’s toolkit. A narrow tool list isn’t a formality here. It’s what makes the agent trustworthy on a repo where you care most about not changing things by accident. You can summon library-reviewer, hand it a diff or a plan, and know its lane is judgment, not edits.

Set its description to capture what it’s for in the one line the dropdown shows — something a teammate skimming the agent list reads as “the thing that checks shared-lib changes for breakage.” Give it a name you’ll recognize. Leave model to a later chapter. You now have a reusable reviewer: any time anyone on the squad touches shared-lib, they summon the same persona, applying the same rule, instead of improvising the review from scratch.

Why a persona beats a prompt here

You might ask why this isn’t 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. The library review isn’t one prompt — it’s a posture you hold across a whole conversation: reading a file, asking a follow-up, checking a second file, weighing a tradeoff, all under the same “additive-only” lens. The persona keeps that lens on for the entire session. That’s the move that earns its keep when the stakes are twelve consumers deep.

A reviewer judges your change. But to actually ship the shared-lib update you need the inverse question answered too: does the change break any of the twelve consumers as they exist today? That’s not one review — it’s twelve, and you don’t want to run them one at a time. Next: fan subagents out across the consumers.