[Docs index](/docs.md) / [Agent Skills](/docs/agent-skills/overview.md) / Playbook: Build a Department AI Rollout Skill

---

# Playbook: Build a Department AI Rollout Skill

You have an approved Agent Skill. Maybe it is a Support Escalation Summary that took three rounds of review to get right. Maybe it is a Weekly Operations Update workflow you standardized from four different ChatGPT histories. Approval is the moment everyone wants to declare victory — and the moment most companies recreate the exact problem they were trying to solve. Approving the skill is not the same as putting it into team use. If you attach it to the wrong agent, or skip validation, or upgrade silently to a new version next month, you just moved the scattered AI problem from prompt docs into Assist.

This playbook walks you through building a rollout skill: a reusable Agent Skill that helps a department owner deliberately put an approved workflow into team use. Validate the workflow on real work. Attach it to the right operational agent with a readable mount path. Announce the change to the team. Upgrade versions intentionally instead of silently. The goal is for rollout to feel boring — controlled, predictable, owned — because boring is what shared company infrastructure should feel like.

## What you will build

By the end of this playbook, you will have:

- A workspace Agent Skill named **Department AI Rollout** with a `SKILL.md`, a rollout-readiness checklist, a manager review template, a team announcement template, validation prompts, and a versioning policy.
- An approved version attached to an Operations or AI Enablement agent.
- A repeatable rollout process: each time you have a new approved workflow to put into team use, the rollout agent helps the department owner decide where it goes, validates it, attaches it, and tracks the upgrade path.
- An explicit upgrade pattern so newly approved versions of any skill move into team use deliberately, not automatically.

## What you need before you start

- An Assist workspace where you can create workspace-scoped Agent Skills.
- A workspace admin who can review and approve versions.
- At least one approved Agent Skill that is ready for real team use (the output of the [Team Prompt Standardization](playbook-prompt-standardization.md) playbook is the natural starting point).
- The operational agent that should ultimately receive the approved skill — the support agent, sales agent, operations agent, or whichever agent the team actually uses for that workflow.
- A department lead who owns the workflow on the business side and will agree to validate the rollout before the team uses it.

## Step 1: Create the draft skill

Open Assist and go to **Workspace > Agent Skills**. Click **New Skill** and set:

- **Name:** Department AI Rollout
- **Slug:** department-ai-rollout
- **Scope:** Workspace
- **Description:** Helps a department owner deliberately put an approved Agent Skill into team use: validate the workflow, attach it to the right operational agent, announce the change, and manage future upgrades.

Or drive it from chat:

> "Create a workspace Agent Skill called Department AI Rollout. Slug: department-ai-rollout. It helps an owner roll out an approved Agent Skill to a department's operational agent without recreating scattered AI usage. Start a draft `SKILL.md` and folders for `checklists`, `templates`, `examples`, and `policies`."

The skill is created as a draft. You can author every file without affecting any live agent.

## Step 2: Write the main procedure

Open `/SKILL.md`. The first line tells Assist when to use the skill:

> Use this skill when a user asks to prepare, validate, or roll out an approved Assist Agent Skill to a department or operational agent.

Then write the rollout process. A useful procedure for this skill looks like this:

1. Confirm the Agent Skill being rolled out has an approved version. Refuse to proceed with a draft or pending version — rollout is a production step, not a preview.
2. Ask the operator: which department owns this workflow on the business side, and which operational agent should receive the skill?
3. Apply the rollout-readiness checklist in `/checklists/rollout-readiness.md`. Block rollout if any required check fails.
4. Confirm the target agent has the tools and context needed for the workflow. A "Support Escalation Summary" skill rolled out to an agent that cannot see the ticket history is a setup for bad output.
5. Propose a mount path using the company convention (`/skills/<slug>`). Reject vague paths like `/skills/v2`, `/skills/final`, or `/skills/new-process`.
6. Run validation prompts against the agent before attaching. Validation belongs to the rollout, not to the approval review — approval verifies the skill files, rollout verifies the skill plus the agent plus the target environment.
7. Capture manager sign-off using the template in `/templates/manager-review.md`.
8. Attach the skill. Optionally send the announcement in `/templates/team-announcement.md` to the people whose work is about to change.
9. Apply the upgrade policy in `/policies/upgrade-rules.md` whenever a newer approved version becomes available.

The procedure is what stops rollout from becoming a checkbox. Each step has a refusal condition — a reason the rollout does not happen if something is missing. That is the point.

## Step 3: Add the supporting files

The rollout files are where the discipline lives. Create:

- `/checklists/rollout-readiness.md` — the required checks before the skill gets attached. Examples: the workflow owner has reviewed the approved version; the target agent has the necessary tools; sensitive or customer-facing outputs have explicit review rules; validation prompts produce useful output on real samples.
- `/templates/manager-review.md` — the format for the department owner's sign-off. Required fields: workflow, target agent, approved version, mount path, validation results, rollout recommendation, follow-up plan.
- `/templates/team-announcement.md` — an optional internal note for the team whose work is changing. Two paragraphs is plenty: what changed, what the team should expect, who owns the workflow, and how to flag problems.
- `/examples/validation-prompts.md` — three to five validation prompts per workflow family (support escalations, sales summaries, operations updates, etc.). Validation should run prompts that reflect real work, not generic examples.
- `/policies/upgrade-rules.md` — how to handle newly approved versions of skills already in team use. The default rule should be that the existing attachment stays pinned until the workflow owner approves the upgrade. New mounts get the new version; existing mounts are upgraded deliberately.

The validation prompts file is worth extra attention. The point of validation is to prove that attaching the skill changes the agent's behavior in the intended way, not just that the agent finishes a task. Examples for a Support Escalation Summary rollout:

> "Use the support escalation format to summarize ticket #18432. The ticket is a billing dispute with three message exchanges and one prior escalation."

> "Summarize ticket #19012 for a Tier 2 handoff. The ticket involves a customer-facing outage and references one earlier ticket from a different customer."

> "Take ticket #19577 and produce an escalation summary. The ticket includes sensitive financial details — confirm the customer-data rule was applied."

The validator can compare the output before and after the skill is mounted and decide whether the skill is actually doing what it was approved to do.

## Step 4: Define the rollout-readiness checklist

The readiness checklist is the most important file in this skill. Be opinionated. A reasonable version covers:

| Check | Why it matters |
|-------|----------------|
| The workflow owner has personally reviewed the approved version | Approval covers correctness; rollout covers ownership |
| The output format matches the department's actual handoff format | A standardized output is useless if the receiving team still has to reformat it |
| Customer-facing or sensitive outputs have explicit review rules | Rollout is when those rules become real, not theoretical |
| The target agent has the tools and context needed | Skills without tools to call become decorative text |
| Validation prompts produce useful output on three real samples | "Looks good" is not validation |
| The team knows which agent should run this workflow | If the team does not know the agent name, they go back to private prompt docs |
| There is a documented plan for future version upgrades | Without it, rollout becomes "the skill that was attached and then nobody touched again" |

If any item fails, the skill is approved but not rolled out yet. That is fine. Keeping an approved skill out of team use until it is actually ready is exactly the kind of control "scattered AI under one platform" is supposed to provide.

## Step 5: Submit for review and approve

From the skill detail page, click **Submit for review**. A workspace admin walks through the files:

- Does the procedure actually require the readiness checks, or could the agent skip them?
- Are the validation prompts representative of real work, not toy examples?
- Does the upgrade policy match how the company wants version changes to land — pinned by default, deliberate upgrades only?
- Is the manager review template specific enough to capture an actual decision, not just a signature?

When the admin approves, the rollout skill is available to mount.

## Step 6: Attach the rollout skill to the right agent

Attach the approved rollout skill to your operations or enablement agent — the agent that runs internal coordination, not the agent that runs customer-facing work. The rollout skill is for the people putting workflows into team use, not for the people running the workflows themselves. Use a readable mount path:

`/skills/department-ai-rollout`

Now the rollout skill itself lives in the agent that owns rollout coordination. The agent has a procedure to follow every time someone asks to put a new approved Agent Skill into use.

## Step 7: Run a real rollout

Pick the first approved workflow ready for team use. The natural first candidate is whichever standardized workflow came out of your [Team Prompt Standardization](playbook-prompt-standardization.md) work. Open the operations agent and run the rollout:

> "Roll out the Support Escalation Summary skill (approved version 53ee959d) to the Support Agent. The workflow owner is Priya. We want to validate it on three real escalation tickets before attaching."

> "Prepare a rollout for the Weekly Operations Update skill to the Operations Agent. The department owner is Marcus. Use the operations validation prompts. I want the manager-review template filled in before we attach."

> "Plan the rollout of the Discovery Call Summary skill to the Sales Agent. The owner is Jordan. Make sure the target agent has CRM access — if not, block rollout and tell me what to add."

The agent walks the procedure. It refuses to proceed if the version is not approved, applies the readiness checklist, proposes the mount path, runs the validation prompts, collects the manager review, and only then attaches the skill. The output is a rollout summary that lives in the conversation history and in the linked manager-review document.

If the validation prompts produce weak output, the agent stops and reports — rollout is paused. That is success, not failure. The workflow goes back to the standardization team for another pass.

## Step 8: Manage future version upgrades deliberately

Eventually a new approved version of the rolled-out skill appears — the support team learned something, the cleanup got better, the customer-data rule got more specific. The default behavior in Assist is that the existing mount stays pinned to the old version. That is the right default. The new version does not silently change how the support agent behaves overnight.

Use the rollout agent to upgrade:

> "Upgrade the Support Agent's Support Escalation Summary attachment from version 53ee959d to version a217bb9c. The workflow owner is Priya. Run validation against the new version before swapping."

The rollout skill re-applies the readiness checks against the new version, re-runs validation prompts, gets a fresh manager review, and only then upgrades the attachment. The team gets a brief announcement using the announcement template: what changed, what to expect, what to flag.

This is the muscle that keeps Assist from becoming the new place where scattered AI lives. Versions advance, but always with someone owning the decision.

## What you built

You have an Agent Skill that turns rollout into a controlled, documented step instead of a checkbox after approval. The skill includes:

- A specific procedure with refusal conditions at every stage — approval, readiness, agent capability, validation, manager sign-off.
- A readiness checklist that catches the predictable failure modes: missing tools, missing review rules, missing handoff format, missing owner.
- Real validation prompts that prove the skill changes the agent's behavior in the intended way.
- An upgrade policy that pins existing mounts and forces deliberate version changes.
- A manager-review template and a team-announcement template, so the change is visible to the people who do the work.

More importantly, you have a way to put approved workflows into team use that scales. The next rollout does not invent its own checklist. The next department owner does not negotiate a new sign-off format. The next version upgrade does not silently change how the support team works overnight. The company has one rollout procedure, owned by an operational agent, applied the same way every time.

That is what bringing scattered AI use under one platform looks like at the operational level: the rollout itself is shared company infrastructure.

## Where to go from here

- **Roll out the next workflow.** Each approved Agent Skill from your standardization work goes through this rollout. Build the muscle by running it three or four times back-to-back.
- **Add scheduled validation.** For high-stakes workflows (anything customer-facing or financial), schedule the rollout agent to re-run validation prompts quarterly. Drift is real — the workflow that worked in March may behave differently in September after model updates.
- **Tie rollout to a release calendar.** If your company already announces internal changes on a cadence, slot Agent Skill rollouts into that cadence. The team experiences AI workflow changes the same way they experience other tool changes — announced, owned, expected.
- **Audit the mounts quarterly.** Use the rollout agent to produce a report of every skill attached to every operational agent, the version pinned, and the date of the last upgrade. Stale mounts are the new version of stale prompt docs.

## Related guides

- [Authoring and approving Agent Skills](authoring-and-approving-agent-skills.md)
- [Attaching skills to operational agents](attaching-skills-to-operational-agents.md)
- [Governing Agent Skill versions](governing-agent-skill-versions.md)
- [Troubleshooting](troubleshooting.md)

---

## Navigation

### In this section: Agent Skills

- [Agent Skills](/docs/agent-skills/overview.md)
- [Use Cases and Playbooks](/docs/agent-skills/use-cases.md)
- [Troubleshooting Agent Skills](/docs/agent-skills/troubleshooting.md)
- [Attaching Agent Skills to Operational Agents](/docs/agent-skills/attaching-skills-to-operational-agents.md)
- [Authoring and Approving Agent Skills](/docs/agent-skills/authoring-and-approving-agent-skills.md)
- [Creating a Managed AI Workflow Skill](/docs/agent-skills/creating-a-managed-ai-workflow-skill.md)
- [Governing Agent Skill Versions](/docs/agent-skills/governing-agent-skill-versions.md)
- [Importing a Team AI Workflow Skill](/docs/agent-skills/importing-a-team-ai-workflow-skill.md)

#### Playbooks

- **Playbook: Build a Department AI Rollout Skill** (current)
- [Playbook: Build a Team AI Usage Cleanup Skill](/docs/agent-skills/playbook-ai-usage-inventory.md)
- [Playbook: Build a Team Prompt Standardization Skill](/docs/agent-skills/playbook-prompt-standardization.md)

### Other sections

- [MCP Servers](/docs/mcp-servers/overview.md)
- [Tool Creation](/docs/tool-creation/overview.md)
- [Agent Filesystem](/docs/agent-filesystem/overview.md)
- [Chat Sharing](/docs/chat-sharing/overview.md)
- [Scheduled Triggers](/docs/scheduled-triggers/overview.md)
- [Sandcastles](/docs/sandcastles/overview.md)
- [Subagents](/docs/subagents/overview.md)
- [Workspace Permissions](/docs/workspace-permissions/overview.md)

[Back to docs index](/docs.md)