@agentrhq/webcmd 0.2.1 → 0.2.3

package/skills/smart-search/references/sources-travel.md

@@ -0,0 +1,26 @@
+# Travel
+
+Use for destinations, attractions, hotel ideas, and travel leads.
+
+## Sites
+
+### google
+
+- Use for: broad destination, attraction, hotel, and itinerary discovery across the web
+- Before use, run: `webcmd google -h`
+
+### reddit
+
+- Use for: traveler experiences, local tips, itinerary comparisons, and community recommendations
+- Before use, run: `webcmd reddit -h`
+
+### youtube
+
+- Use for: destination walkthroughs, hotel reviews, travel vlogs, and visual checks
+- Before use, run: `webcmd youtube -h`
+
+## Routing Hints
+
+- If the user names a specific travel platform and it exists in the live registry, use that platform directly
+- If the user only asks about travel, destinations, attractions, or hotels, start with `google`
+- Add `reddit` for traveler experience and `youtube` for visual inspection

package/skills/webcmd-adapter-author/SKILL.md

@@ -194,6 +194,14 @@ Check these off step by step:
         [ ] `fixtures/<cmd>-<YYYYMMDDHHMM>.json`: save one complete endpoint response sample after removing cookies, tokens, and private user fields. Use it for later field comparison and offline replay.
         [ ] If debugging dumped temporary files in the repo or adapter directory, such as `.dbg-*.html`, `raw-*.json`, or similar, **delete them before commit**. Those belong in `~/.webcmd/sites/<site>/fixtures/` or `/tmp/`.
 
+[ ] 13. **First command for this site? Stop and ask before building more.**
+        [ ] If this was the site's first command, do not silently keep scaffolding more commands. Ask the user what use cases they have in mind for this site — who the persona is, what they're trying to accomplish end to end.
+        [ ] From the use cases, propose the full set of commands you'd recommend adding, not just the obvious next one. Cover the whole journey the use cases imply (discovery, single-item detail, comparison, account/write actions, etc.), not only what's cheapest to build.
+        [ ] If that set is small (roughly ≤6-8 commands), list it flat and ask the user to confirm or trim it.
+        [ ] If it's large, bucket the commands into named groups (e.g. "Discovery", "Single-item evaluation", "Account actions requiring login") and ask the user which bucket(s) to build first — do not dump an unbucketed wall of commands.
+        [ ] Flag any bucket that needs a capability not yet solved (login/OTP, write access, payment) as its own decision point — e.g. "these need login — how do you want to handle auth?" — separate from the command list itself.
+        [ ] Do not scaffold additional commands until the user has confirmed which ones to build.
+
 ---
 
 ## Fallback Paths
@@ -244,8 +252,10 @@ Check these off step by step:
 - **Intermediate parsing object keys must not overlap any `columns` entry.** Otherwise silent-column-drop audits can misread the adapter. Use dedicated internal names and destructure with aliases when pushing rows.
 - **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 adapters, write `~/.webcmd/clis/<site>/<name>.js` to avoid a build. Copy to `clis/<site>/<name>.js` only when preparing a PR.
 - 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.**
 - **JSDOM unit-test fixtures (`clis/<site>/__fixtures__/<command>.html`) are the exception.** They are intentional review artifacts committed to the repo, not temporary dumps. Because of that, the quality bar is higher: complete the five steps in `references/jsdom-fixture-pattern.md`, including the mandatory `awk 'NF>0'` blank-line tightening, and reverse-validate once to prove the regression guard can fail.
 

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

@@ -112,6 +112,8 @@ Rules:
 | `args` | Include type, default, and help for every external parameter. |
 | `columns` | Must exactly match row keys, including order. |
 | `pipeline` or `func` | Use the style already established by nearby adapters. |
+| `siteSession` | `'persistent'` shares one tab per site across commands (multi-step flows); `'ephemeral'` gets a fresh isolated tab per run. Persistent tabs keep leftover DOM (modals, drawers) between commands — see "Persistent Sessions and State Hygiene" in docs/authoring.mdx. |
+| `freshPage` | With `siteSession: 'persistent'`, set `true` to start the command on a newly created tab under the same lease: profile state (cookies, login, location) survives, stale DOM does not. Recommended for state-sensitive write commands such as checkout flows. |
 
 ## Strategy Enum Examples
 

package/skills/webcmd-autofix/SKILL.md

@@ -53,6 +53,14 @@ Use this skill when `webcmd <site> <command>` fails with repairable errors:
 
 Proceed only when the empty or missing-selector result is reproducible across retries and alternative entry points.
 
+## Before Repair: An Error Modal Is Not Always the Site's Verdict
+
+Persistent-session adapters (`siteSession: 'persistent'`) share one tab per site, so error text in the body may be inherited or context-scoped rather than real. Before patching code:
+
+- Check the trace screenshot and `location.href`: a modal over a blank page or the wrong URL means the tab carried stale DOM from a previous command, not that the site rejected this request.
+- Check session-scoped context: sites often scope results to a selected city, date, or account. A "closed" / "unavailable" verdict can simply mean the browser's selected context does not match the request (for example, a seat layout opened while the site's location cookie points at another city).
+- Reproduce in a clean tab (`webcmd browser open <url>`) before trusting the verdict. If it only fails in the adapter's persistent tab, fix state handling (`freshPage: true`, dismiss-and-renavigate, context preconditions) instead of selectors.
+
 ## Step 1: Collect Trace Context
 
 Run the failing command with retained trace:

package/skills/webcmd-sitemap-author/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: webcmd-sitemap-author
-description: Use when creating or maintaining Webcmd site sitemaps: agent-facing navigation, page-state, action, workflow, API-reference, pitfall, and fallback knowledge for a website. Use after browser exploration discovers durable site context, when a sitemap is stale, or when promoting local site knowledge into the repo.
+description: 'Use when creating or maintaining Webcmd site sitemaps: agent-facing navigation, page-state, action, workflow, API-reference, pitfall, and fallback knowledge for a website. Use after browser exploration discovers durable site context, when a sitemap is stale, or when promoting local site knowledge into the repo.'
 allowed-tools: Bash(webcmd:*), Read, Edit, Write, Grep
 ---