Every release, someone checks the same things: migrations reversible, feature flags defaulted off, no secrets in the diff, rollback documented. You explain it to each new engineer, and to the agent, every single time. Three mechanisms can carry that knowledge, and choosing wrongly is the usual mistake.

​
Which mechanism holds what

None of these grant permission. A skill or agent shapes behavior; neither adds connector access nor removes a tool approval. An agent instructed to “always push to main” still stops at the approval card. Guidance and permission are separate systems, and that separation is what makes them safe to share.

​
Write the release checklist as a skill

Open Capabilities, choose Skills, and select New skill. The dialog asks for three things: a name, a description, and a scaffold. The description is how an agent decides the skill applies, so write it as a trigger condition rather than a title: “Use when reviewing a change for release readiness.” You have 160 characters; spend them on when, not what. Open the skill after creating it and write the actual procedure in its SKILL.md. This is where the skill earns its place: specify an output contract, not just a topic. “Return a table with one row per check, a pass/fail, and the evidence line that justifies it. If evidence is missing, mark it Unknown rather than Pass.” That last clause is what stops a checklist from becoming a rubber stamp.
Deleting a skill is permanent: agents stop applying it immediately, and its SKILL.md goes with it.

​
Give the reviewer a point of view

In Capabilities, choose Agents, and select New agent. The dialog asks for a handle, a one-line role, instructions, and visibility. The handle is how it is summoned: @release-captain. The instructions should say what the agent refuses, not only what it does. “Do not approve a release with an irreversible migration and no rollback note. Say so and stop.” An agent with no refusals is a summarizer. The handle is fixed once the agent is created; role and instructions stay editable.

​
Use them together on a real change

“@release-captain /release-check Review IS-12 for release readiness. Use the repository as evidence. Mark anything you could not verify as Unknown.” The mention supplies judgment, the skill supplies the procedure, and the issue supplies the subject. Each is doing a different job.

​
Review the output before you trust the system

The first few runs are testing the skill, not the change. Check that Unknown is being used honestly: a skill that never returns Unknown has learned to please you rather than to check. Tighten the wording and run it again.

​
What good looks like

  • The checklist exists once, not in four people’s heads.
  • The skill specifies an output contract, including how to report missing evidence.
  • The agent has at least one explicit refusal.
  • New teammates are told to type / and @ in a composer, because that is where the full inventory shows up.