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. This playbook puts the procedure in a skill and the judgment in an agent, then runs both on a real change. Open Bright → The New skill dialog open over the Capabilities skills list, before anything is typed

​
Choose which mechanism holds what

Pick the mechanism by what you want it to carry.
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

  1. Open Capabilities, choose Skills, and select New skill.
  2. Fill in the dialog. It asks for a scaffold (Start from), a name, a description, and visibility. Name it release-check: lowercase letters, numbers, and hyphens, up to 48 characters. Visibility is Organization or Private, and defaults to Organization.
  3. Write the description 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. The description is how an agent decides the skill applies.
  4. Create the skill, then open it and write the actual procedure in its SKILL.md.
  5. 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.”
The SKILL.md is where the skill earns its place. 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

  1. In Capabilities, choose Agents, and select New agent.
  2. Fill in the dialog. It asks for a handle, a one-line role, instructions, and visibility.
  3. Choose the handle carefully. It is how the agent is summoned: @release-captain. The handle is fixed once the agent is created; role and instructions stay editable.
  4. Write instructions that 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.

​
Use them together on a real change

Mention the agent, invoke the skill, and name the issue in one message:
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.

​
Good to know

  • A skill description has 160 characters. Write it as a trigger condition, since it is how an agent decides the skill applies.
  • A skill name is a slug: lowercase letters, numbers, and hyphens, up to 48 characters. Visibility is Organization or Private.
  • A skill or agent shapes behavior only. Neither adds connector access nor removes a tool approval.
  • An agent handle is fixed once the agent is created. Its role and instructions stay editable.
  • Deleting a skill is permanent. Agents stop applying it immediately, and its SKILL.md goes with it.
  • Type / and @ in a composer to see the full inventory of skills and agents.

​
Next step

See the same surfaces carry a whole launch in Build a documentation portal from a product brief.