fix(skill): enforce explicit user confirmation before CLI promotion

skills/webcmd-adapter-author/SKILL.md

@@ -263,7 +263,11 @@ 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 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 Sessions and State Hygiene" in `docs/authoring.mdx`.
-- 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. See `references/adapter-template.md` for details.
+- **Private Iteration (default):** Build, test, and validate in `~/.webcmd/clis/<site>/` (for example `~/.webcmd/clis/<site>/<name>.js`) to avoid a build. This fully satisfies requests like "build a working adapter." Promotion is a separate step from building.
+- **Promotion (explicitly gated):** Do **not** promote a CLI out of `~/.webcmd/clis/<site>/` unless the user has explicitly confirmed they want it added to the repository or a PR created. A request to "build a working adapter" does **not** imply permission to promote.
+- **Hard rule:** Unless the user explicitly says something like "promote this," "push to repo," "create plugin," or "open PR," do **not** run `webcmd plugin create`, do **not** write anything under `plugins/<site>/`, do **not** update root `webcmd-plugin.json`, and do **not** remove the local `~/.webcmd/clis/<site>` shadow.
+- **Mandatory checkpoint after private iteration:** Ask exactly: "The adapter is working under private iteration. Do you want me to promote it into `plugins/<site>/` and register it in the repo?"
+- **Only after explicit confirmation:** 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. See `references/adapter-template.md` for details.
 - 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.
 - **Raw dumps, packet captures, and HTML samples from debugging may only be written to `~/.webcmd/sites/<site>/fixtures/` or `/tmp/`. Never leave `.dbg-*.html`, `raw-*.json`, `sample.*`, or similar temporary files in the repo root, `plugins/<site>/`, or the current working directory.**