docs: make CLI-promotion confirmation an explicit, hard-to-read-past gate

skills/webcmd-adapter-author/SKILL.md

@@ -263,7 +263,7 @@ Check these off step by step:
 - **The `browser:` field determines the `func` signature:** `browser:false -> (args)`, `browser:true -> (page, args)`. If this is reversed, `args` may actually be a debug flag and all external parameters can silently fall back to defaults.
 - Throw the correct typed error for known failures according to [`references/typed-errors.md`](./references/typed-errors.md). **Do not** silently `return []`, **do not** silently `return [{sentinel}]`, and **do not** silently clamp external parameters with `Math.max/min`.
 - **Persistent site sessions keep stale DOM between commands.** `siteSession: 'persistent'` shares one tab per site; leftover modals/drawers from the previous command leak into the next one. State-sensitive write commands (checkout flows) should add `freshPage: true` (new tab, same lease — cookies/login/location survive). Verify session-scoped context (login, selected city/date) *before* side effects, and embed such context in URLs/IDs your command emits for sibling commands. See `references/adapter-template.md` and "Persistent Site Sessions and State Hygiene" in `docs/authoring.mdx`.
-- For private iteration, write `~/.webcmd/clis/<site>/<name>.js` to avoid a build. Use `webcmd adapter override <site>/<command>` to fork an existing plugin command. When the user says to promote a CLI, keep the `webcmd plugin create <site> --dir plugins/<site>` step for packaging a new plugin, then register it in root `webcmd-plugin.json`, install the plugin, and run `webcmd validate <site>` and smoke commands. See `references/adapter-template.md` for details.
+- For private iteration, write `~/.webcmd/clis/<site>/<name>.js` to avoid a build. Use `webcmd adapter override <site>/<command>` to fork an existing plugin command. Building, testing, and verifying the adapter under private iteration fully satisfies a request to "build a working adapter" on its own. **Do not run `webcmd plugin create` or otherwise 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).** A general instruction to build or ship an adapter is not that confirmation — state the checkpoint out loud ("The adapter works under private iteration — want me to promote it into `plugins/<site>/` now?") and wait for a yes before promoting. Once confirmed, keep `webcmd plugin create <site> --dir plugins/<site>` for packaging a new plugin, then register it in root `webcmd-plugin.json`, install the plugin, and run `webcmd validate <site>` and smoke commands. See `references/adapter-template.md` for details.
 - After `webcmd plugin update`, check the reported overrides needing reconciliation and merge `yours` with `upstream`, using `base` as the common ancestor for a three-way merge. Only overrides are reported; a user-authored adapter has no upstream.
 - Write site memory every round: no memory -> use skill -> produce memory -> next time becomes a five-minute task.
 - **After a site's first command passes verify, stop and ask the user for their use cases before recommending next set of commands.** See Runbook Step 13.

skills/webcmd-adapter-author/references/adapter-template.md

@@ -15,7 +15,7 @@ webcmd browser init <site>/<name>
 
 This scaffolds `~/.webcmd/clis/<site>/<name>.js` with a `Strategy.PUBLIC` placeholder — `init` takes no flags, so set the real `strategy:` value (and the other `TODO` fields) by hand once the file exists.
 
-Promote a community CLI to the main repo as a plugin:
+Promote a community CLI to the main repo as a plugin — **only after the user has explicitly confirmed they want it pushed into the repo**; a general instruction to build a working adapter is not that confirmation (see `SKILL.md`'s Key Conventions):
 
 ```bash
 webcmd plugin create <site> --dir plugins/<site> --description "<site> commands for Webcmd"