Anatomy of one governed skill: five parts, and the complete file to steal

Vercel's CEO says their internal agent cut the entire product changelog process down to one Slack thread. Engineer posts what shipped, agent drafts the customer-readable entry, a human approves, it publishes. That's his claim, on the record, on the Agent Native podcast this month.

Operators hear claims like that and can't see the machinery. And his example is an engineering one. So here's the same machinery, translated to a workflow ops teams actually own: the deal hits closed-won, and the customer needs a kickoff email that doesn't read like your internal deal notes.

A governed skill has exactly five parts. Not four. Not "it depends."

1. The trigger. The AE posts the win in #closed-won. That post already happens (nobody skips the victory lap). A Slack event, nothing exotic. No form, no ticket, no new tool to learn.
2. The skill file. A plain markdown file that encodes how your company does this one task. Complete example below.
3. The tool, scoped. The coding agent gets draft-only access to the CRM's email tool. Not send. Not admin. Your existing permission system does the enforcing.
4. The human gate. Someone approves before anything reaches a customer. More on this below, because it's the part everyone waves at and nobody designs.
5. The log. Every draft, approval, and rejection recorded: who, what, when. Without it you can't answer "why did we send that?" six months from now.

Parts one to three get built everywhere. Parts four and five separate governed workflows from liabilities.

Here's the complete skill file, translated to a placeholder company (Acme Corp: Slack plus HubSpot). Runnable as written. Steal it and swap the specifics:

---
name: kickoff-draft
description: >
  Draft the customer kickoff email from the AE's win post in
  #closed-won and the deal record. Draft only. Never send.
trigger: slack message in #closed-won
tools: crm-draft (draft-only access to the CRM email tool)
owner: cs-ops (Dana at Acme Corp)
---

# Kickoff Email Skill

## What you do
Turn the AE's win post and the deal record into one kickoff
email the new customer can act on without decoding our sales
process.

## The formula (every email answers three questions)
1. What did you buy? Name the plan and what's in it. Nothing
   more and nothing less than the signed order form.
2. What happens in week one? One concrete first step, with a
   date and who runs it.
3. Who's your human? One name, one email address. Never a
   shared inbox as the only contact.

## Voice rules (Acme Corp)
- Second person. "Your onboarding call is Thursday."
- Numbers over adjectives: "live in 10 business days,"
  never "lightning-fast onboarding."
- Max 150 words. No exclamation marks.
- Deal-note language never reaches the customer: discount
  percentages, competitor names, internal deal codes. Drop them.

## Output format
- Subject: what they bought plus the first date, eight words max.
- Body: the three answers, in that order.
- Sign-off: the named CSM, never "The Acme Team".

## What you may not do
- Never send. Create a draft and request approval.
- No terms beyond the signed order form. No invented dates.
- No roadmap promises ("that feature is coming soon").
- Nothing from the deal notes the customer hasn't already seen.

## Approval request format (required fields)
- The full email body, not a summary.
- Recipient names and the send time.
- The deal record and the AE's original post, linked.
- One reminder line: email has no unsend. This gate is the
  rollback.

Notice what the file actually is. It's not documentation about the agent. It's your best onboarding person's judgment on one task, written down, so the task stops depending on their calendar. Rauch says he put his own product-marketing formula into Vercel's agent. Same move here: the three questions above are your CS director's formula. The agent is just the courier.

One more thing, on part four. "Human in the loop" is a saturated phrase; every vendor claims it. The difference between a real gate and a checkbox is what the reviewer sees. If the approval request shows a summary, reviewers approve things they never inspected. That's why the file forces the full email body, the recipients, and the send time into every approval request. And one honest line: a sent email has no unpublish. For customer-facing sends the gate isn't one safety layer of several. It's the only one.

Does the gate slow things down? Barely, and it's what lets the workflow ship at all. Schellman surveyed 525 US enterprise professionals in July: organizations with mature governance run agents in production at 78%, versus 22% for developing programs. Governance isn't friction. It's the ticket.

Full teardown on the blog, with the same five parts shown on the changelog workflow Vercel described, the mock Slack thread, and how to baseline the manual workflow before you build (two weeks of passive timing, or your after-number is fiction): Anatomy of one governed skill

Question for this circle: which of the five parts is missing from your current setup? My bet is four and five. Tell me where I'm wrong.