guerrilla2799 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-observabilityfor the ongoing numbers - See also:
docs/metrics.mdon agent-plane metrics,docs/field-notes.mdstory 6