How one skill keeps every agent's code review at the same bar
Different agents used to review PRs differently.
@api-smith checked for N+1 queries and missing indexes. @pixel checked for accessibility and design-token drift. Neither checked for the same secrets-in-diff and test-coverage rules the other did, because those rules lived in each agent's own instructions, written separately, drifting separately. We fixed it by moving the shared parts into one skill and attaching it to every agent that reviews code.
What a skill actually is
A skill is a knowledge pack for an agent — a SKILL.md plus optional supporting files that tell the agent "when you hit this kind of task, think and act like this." AACWorkflow adopts the open Agent Skills standard, so a skill isn't tied to one AI coding tool; whichever runtime an agent happens to use, the same SKILL.md applies.
The distinction that mattered for us: a skill lives at the workspace level, not inside one agent's private instructions. Attach it to five agents and all five share the exact same rules — change one line in the skill, and the next review any of them does picks up the change. No copy-pasting the same checklist into five different agent profiles, and no five slightly-different copies quietly drifting apart.
How we wired it up
We wrote one workspace skill, pr-review-checklist, with the rules that should hold no matter which layer of the codebase a PR touches: no secrets in the diff, no console.log left in, tests added or updated for behavior changes, no unreviewed dependency bumps, and a required one-line summary of why the change was made, not just what changed.
Language- and layer-specific detail stayed where it already lived — api-smith still knows to check for N+1 queries, pixel still knows to check contrast ratios — but the shared checklist runs for both, and for @mobile-agent and @docs-agent too, because we attached the same skill to all four. One skill, four agents, four different specialties, one common floor none of them can review below.
Updating it is a one-line edit. When we added "flag any migration that isn't reversible" to the checklist after a rollback went sideways, it took effect on the very next review any of the four agents did — no redeploy, no re-onboarding, no updating four separate instruction blocks by hand.
What happens on a real PR
An agent picks up a review — assigned, @-mentioned, whatever the trigger — and runs its specialty checks first, then works through the shared checklist from the skill before approving or requesting changes. If something in the shared checklist fails, the comment says so explicitly, citing the specific rule, so a human skimming the PR later can tell at a glance whether it was a specialty concern or a baseline one.
Because the skill is workspace-scoped, a new agent we add to the team inherits the same review bar on day one just by attaching the skill — there's no ramp-up period where a new reviewer's standards are looser than everyone else's.
What changed for the team
One bar, not four. Every PR gets the same non-negotiable checks regardless of which agent reviews it, on top of that agent's own specialty.
Edits propagate instantly. Fixing a gap in the review process is a one-line skill edit, not a multi-agent instruction-sync exercise.
New agents ramp instantly. Attach the skill, and a brand-new reviewer starts at the same standard as agents that have been reviewing for months.
Drift stops happening. Before this, "did we remember to check for that in every agent's instructions" was a real question. Now there's exactly one place that rule lives.
Bring a shared skill into your own workspace
Write the checklist once as a workspace skill, attach it to every agent that reviews code, and edit it in one place whenever the bar needs to move.