# Agent Rollout

> Use when shipping an agent to other people, or when the user says "nobody uses it", "roll this out", "how do I distribute this", "adoption", "train the team on it", "package this as a plugin", "version it". Handles packaging, distribution, the first-run experience, accountability, and the adoption metrics that decide whether the build succeeded. Writes workspace/agents/<name>/rollout.md.

- Skill: `guerrilla2799/agent-rollout` (Agent Skill)
- Install (CLI): `npx skillmds@latest add guerrilla2799/agent-rollout`
- Raw SKILL.md: https://api.skillmd.com/api/skills/guerrilla2799/agent-rollout/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: guerrilla2799 (https://skillmd.com/u/guerrilla2799)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/guerrilla2799/agent-rollout

---


# Agent Rollout

Most agent builds fail at rollout, not at quality. This skill exists because a working thing nobody uses scores zero.

## When to use
- An agent works and needs to reach other people
- Adoption is low on something already shipped
- Packaging for distribution
- Versioning and update strategy

## Inputs
- Reads: `workspace/agents/<name>/brief.md`, `guardrails.md`
- Needs from user: who the intended users are, what tools they already have open all day, and who their manager is

## Workflow

### 1. Understand the three reasons adoption fails

In order of frequency, and none of them is quality.

**It lives somewhere they do not already work.** Adoption of a tool requiring a new window, a new login, or a new habit is a fraction of adoption of one inside an existing workflow. Ship into the surface they already have open.

**The first run failed.** An API key they do not have, a file that does not exist, a permission prompt they do not understand. Most people do not attempt a second time.

**Nobody asked whether they used it.** With no accountable person and no weekly check, usage decays to zero inside a month regardless of value.

### 2. Engineer the first run to under fifteen minutes

Time to first useful output is the adoption metric. Over roughly fifteen minutes and most users never return.

```
[ ] Zero setup steps in the first run, or one at most
[ ] Works with no config file present, using sensible defaults
[ ] Every missing file degrades gracefully, never errors
[ ] First run produces something the user would keep
[ ] Credentials, if needed, are set up by the installer, not the user
```

**Degrade, never error.** A skill that stops because an optional context file is absent has failed its first user. Fall back to house style and note it.

### 3. Package for the audience you actually have

| Audience | Package as | Update mechanism |
|---|---|---|
| Just you | A directory in your own config | Edit in place |
| Technical teammates | Repo or plugin from git | Pull or plugin update |
| Non-technical users | Zip, or a preinstalled setup on their machine | You send a new version |
| An organization | Plugin with a version number and a changelog | Marketplace or internal distribution |

Start with whichever has the lowest friction for the actual person, then upgrade. A technically superior distribution path that the user cannot complete is worse than a zip file.

### 4. Version from the first external user

The moment it leaves your machine it needs a version number, a README, and a changelog. Without a version, you cannot tell which behavior somebody is describing when they report a problem.

```
version:     semver, bumped on every change that reaches a user
README:      what it does, how to run it, what it will refuse to do
CHANGELOG:   dated, one line per change, written for the user not for you
```

The README must state the refusals. Users need to know what it will not do, or they will interpret a guardrail as a bug.

### 5. Assign accountability, not enthusiasm

One named person whose work visibly changes, plus their manager asking about it weekly for the first month. Not "the team is excited about it."

```
Accountable user:     <name>
Their manager:         <name>
Weekly check:          <day>, for the first 4 weeks
Success threshold:     <from the brief>
Kill criterion:        <from the brief>
```

### 6. Measure the four numbers at week four

| Metric | Healthy at week 4 |
|---|---|
| Weekly active users ÷ intended users | Over 60% |
| Runs per active user per week | Over 5 |
| Correction rate | Under 30% |
| Time to first useful output | Under 15 minutes |

Under 30% weekly active at week four means the rollout failed. Diagnose against the three reasons in step 1 before touching the agent itself, because the agent is usually not the problem.

### 7. Apply the kill criterion honestly

At the review date, compare against the threshold written in the brief. If it missed, either fix the specific named cause or retire it.

**Retiring is a success.** A repo full of unused skills degrades selection for the ones that work, because every stale description is a chance for the wrong thing to load.

## Output
- Writes: `workspace/agents/<name>/rollout.md`, plus README and CHANGELOG in the agent's own directory
- Uses: `templates/rollout-plan-template.md`
- Prints: the first-run checklist result, the packaging decision, the accountability assignment, and the week-four numbers when available

## Rules & quality bar
- **Ship into a surface they already have open**
- **Time to first useful output under fifteen minutes**
- **Degrade gracefully on every missing input.** Never error on an optional file
- **Version, README, and changelog from the first external user**
- **The README states what it refuses to do**
- **A named accountable user and a weekly check for four weeks**
- **Diagnose low adoption against surface, first run, and accountability before blaming quality**
- **Apply the kill criterion.** Retiring an unused skill is maintenance, not failure

## Related skills
- Requires: `agent-guardrails`, `skill-authoring`
- Feeds: `agent-observability` for the ongoing numbers
- See also: `docs/metrics.md` on agent-plane metrics, `docs/field-notes.md` story 6