docs: fix community plugin promotion workflow

skills/webcmd-adapter-author/SKILL.md

@@ -253,7 +253,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 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.
+- For private iteration, write `~/.webcmd/clis/<site>/<name>.js` to avoid a build. When the user says to promote a CLI, determine the plugin name (default to `<site>`) and collect any missing author display name and GitHub handle before scaffolding. Create the main-repo plugin with `webcmd plugin create <plugin-name> --dir plugins/<plugin-name> --author-name "<author-name>" --author-handle "<github-handle>"`, copy the real command files into it, delete scaffold sample commands, remove the local `~/.webcmd/clis/<site>` shadow, install the plugin, then run `webcmd validate <site>` and smoke commands. Do not hand-edit the root `webcmd-plugin.json` or generated README catalog: the community-plugin sync discovers `plugins/*/webcmd-plugin.json` and updates both after merge. 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, `clis/<site>/`, or the current working directory.**

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

@@ -18,28 +18,25 @@ Write the working file at:
 
 Promote a community CLI to the main repo as a plugin:
 
+Determine the plugin name (default to `<site>`) and collect the author's display name and GitHub handle if they are not already known.
+
 ```bash
-webcmd plugin create <site> --dir plugins/<site> --description "<site> commands for Webcmd"
-cp ~/.webcmd/clis/<site>/*.js plugins/<site>/
-rm plugins/<site>/hello.ts plugins/<site>/greet.ts 2>/dev/null || true
+webcmd plugin create <plugin-name> \
+  --dir plugins/<plugin-name> \
+  --description "<site> commands for Webcmd" \
+  --author-name "<author-name>" \
+  --author-handle "<github-handle>"
+cp ~/.webcmd/clis/<site>/*.js plugins/<plugin-name>/
+rm plugins/<plugin-name>/hello.ts plugins/<plugin-name>/greet.ts 2>/dev/null || true
 ```
 
-Then add `<site>` to the root `webcmd-plugin.json` `plugins` map:
-
-```json
-"<site>": {
-  "path": "plugins/<site>",
-  "version": "0.1.0",
-  "description": "<site> commands for Webcmd",
-  "webcmd": ">=0.2.0"
-}
-```
+Do not hand-edit the root `webcmd-plugin.json` or the generated community-plugin section in `README.md`. After merge, the community-plugin sync discovers `plugins/*/webcmd-plugin.json`, validates the author metadata, and updates both generated catalogs.
 
 Before handing off, remove the private shadow and prove the plugin path works:
 
 ```bash
 rm -rf ~/.webcmd/clis/<site>
-webcmd plugin install file://$PWD/plugins/<site>
+webcmd plugin install file://$PWD/plugins/<plugin-name>
 webcmd validate <site>
 webcmd <site> <command> --help
 ```

skills/webcmd-usage/SKILL.md

@@ -117,9 +117,9 @@ Storage paths:
 
 - Private: `~/.webcmd/clis/<site>/<command>.js`
 - Public (official bundle): `clis/<site>/<command>.js`
-- Public (community PRs): `plugins/<site>/` plus root `webcmd-plugin.json` registration
+- Public (community PRs): `plugins/<site>/` with its own `webcmd-plugin.json`
 
-The main Webcmd repo is itself a plugin monorepo: promoted community CLIs belong under `plugins/<site>/` and must be registered in the root `webcmd-plugin.json`.
+The main Webcmd repo is itself a plugin monorepo: promoted community CLIs belong under `plugins/<site>/`. Do not hand-edit the root `webcmd-plugin.json` or generated README catalog; after merge, the community-plugin sync discovers each plugin manifest and updates both automatically.
 
 Scaffolding and checks: