What the skill says
SKILL.md line 260 in the webcmd-adapter-author skill:
For private iteration, write ~/.webcmd/clis/<site>/<name>.js to avoid a build. When the user says to promote a CLI, create a main-repo plugin with webcmd plugin create <site> --dir plugins/<site>, copy the real command files into it, delete scaffold sample commands, register it in root webcmd-plugin.json, remove the local ~/.webcmd/clis/<site> shadow, install the plugin, then run webcmd validate <site> and smoke commands.
So the intent is clearly that promotion (turning a private, iterating CLI into a real repo plugin — i.e. pushing it into the repo, the equivalent of opening a PR) is gated on the user explicitly asking for that specific step.
What actually happens
In practice, across three separate adapter builds, an instruction along the lines of "build a real, working adapter for <university>, this will be run by the user once done" was read as authorization for the entire pipeline — private iteration and promotion and install — with no separate checkpoint asking "should this be promoted into the repo now?" The wording "when the user says to promote a CLI" is easy to satisfy implicitly (a working, tested, real adapter is what was asked for) rather than requiring an explicit, separate go-ahead for the promotion step specifically.
This matters because promotion is a meaningfully different action from private iteration: it writes into the shared repo (plugins/<site>/), touches root-level registration, and is effectively the moment the adapter becomes "shipped" rather than "drafted." Treating "build a working adapter" as implicit permission for that collapses a step the skill itself singles out as conditional.
Suggested fix
Make the gate explicit and hard to read past, rather than a single soft clause inside a longer sentence. For example:
Do not run webcmd plugin create / promote a CLI out of ~/.webcmd/clis/<site>/ until the user has explicitly confirmed they want it pushed into the repo (or a PR raised). Building, testing, and validating the CLI under private iteration fully satisfies "build a working adapter" on its own — promotion is a separate, additional step that needs its own explicit ask.
Optionally also have the agent state this explicitly before promoting ("The adapter works under private iteration — want me to promote it into plugins/<site>/ now?") so it's a visible checkpoint rather than an implicit continuation.
What the skill says
SKILL.mdline 260 in thewebcmd-adapter-authorskill:So the intent is clearly that promotion (turning a private, iterating CLI into a real repo plugin — i.e. pushing it into the repo, the equivalent of opening a PR) is gated on the user explicitly asking for that specific step.
What actually happens
In practice, across three separate adapter builds, an instruction along the lines of "build a real, working adapter for
<university>, this will be run by the user once done" was read as authorization for the entire pipeline — private iteration and promotion and install — with no separate checkpoint asking "should this be promoted into the repo now?" The wording "when the user says to promote a CLI" is easy to satisfy implicitly (a working, tested, real adapter is what was asked for) rather than requiring an explicit, separate go-ahead for the promotion step specifically.This matters because promotion is a meaningfully different action from private iteration: it writes into the shared repo (
plugins/<site>/), touches root-level registration, and is effectively the moment the adapter becomes "shipped" rather than "drafted." Treating "build a working adapter" as implicit permission for that collapses a step the skill itself singles out as conditional.Suggested fix
Make the gate explicit and hard to read past, rather than a single soft clause inside a longer sentence. For example:
Optionally also have the agent state this explicitly before promoting ("The adapter works under private iteration — want me to promote it into
plugins/<site>/now?") so it's a visible checkpoint rather than an implicit continuation.