docs: document required --author-name/--author-handle for plugin create

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 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, create a main-repo plugin with `webcmd plugin create <site> --dir plugins/<site> --author-name "<Your Name>" --author-handle <your-github-handle>` (both author flags are required outside an interactive TTY), 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.**

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

@@ -18,11 +18,14 @@ This scaffolds `~/.webcmd/clis/<site>/<name>.js` with a `Strategy.PUBLIC` placeh
 Promote a community CLI to the main repo as a plugin:
 
 ```bash
-webcmd plugin create <site> --dir plugins/<site> --description "<site> commands for Webcmd"
+webcmd plugin create <site> --dir plugins/<site> --description "<site> commands for Webcmd" \
+  --author-name "<Your Name>" --author-handle <your-github-handle>
 cp ~/.webcmd/clis/<site>/*.js plugins/<site>/
 rm plugins/<site>/hello.ts plugins/<site>/greet.ts 2>/dev/null || true
 ```
 
+`--author-name` and `--author-handle` are required outside an interactive TTY (non-interactive/agent runs fail with `Invalid author.name`/`Invalid author.handle` if omitted); `--author-handle` must be a valid GitHub username.
+
 Then add `<site>` to the root `webcmd-plugin.json` `plugins` map:
 
 ```json