From 49d93408cb995d39f87d0aa3a9d2b7357e121f01 Mon Sep 17 00:00:00 2001 From: ronit-1404 Date: Sat, 8 Aug 2026 08:46:25 +0530 Subject: [PATCH] fix(skill): enforce explicit user confirmation before CLI promotion --- skills/webcmd-adapter-author/SKILL.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/skills/webcmd-adapter-author/SKILL.md b/skills/webcmd-adapter-author/SKILL.md index 6e4fbbb..5b55096 100644 --- a/skills/webcmd-adapter-author/SKILL.md +++ b/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//.js` to avoid a build. When the user says to promote a CLI, create a main-repo plugin with `webcmd plugin create --dir plugins/`, copy the real command files into it, delete scaffold sample commands, register it in root `webcmd-plugin.json`, remove the local `~/.webcmd/clis/` shadow, install the plugin, then run `webcmd validate ` and smoke commands. See `references/adapter-template.md` for details. +- **Private Iteration (default):** Build, test, and validate in `~/.webcmd/clis//` (for example `~/.webcmd/clis//.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//` 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//`, do **not** update root `webcmd-plugin.json`, and do **not** remove the local `~/.webcmd/clis/` shadow. +- **Mandatory checkpoint after private iteration:** Ask exactly: "The adapter is working under private iteration. Do you want me to promote it into `plugins//` and register it in the repo?" +- **Only after explicit confirmation:** Create a main-repo plugin with `webcmd plugin create --dir plugins/`, copy the real command files into it, delete scaffold sample commands, register it in root `webcmd-plugin.json`, remove the local `~/.webcmd/clis/` shadow, install the plugin, then run `webcmd validate ` 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//fixtures/` or `/tmp/`. Never leave `.dbg-*.html`, `raw-*.json`, `sample.*`, or similar temporary files in the repo root, `plugins//`, or the current working directory.**