@weavetab/skills 2.5.0-beta.4 → 2.5.0-beta.5

package/dist/bundled/weavetab-browser.md

@@ -1,10 +1,10 @@
-# Weavetab Domain Profile: BROWSER
-
-Generated for @weavetab/skills v2.5.0-beta.4
-
-
-## dom-strategy
-
+# Weavetab Domain Profile: BROWSER
+
+Generated for @weavetab/skills v2.5.0-beta.5
+
+
+## dom-strategy
+
 # DOM Strategy & Token Conservation Engine
 
 When parsing modern web applications, naive DOM dumps can consume 50,000+ tokens and cause agent degradation. Weavetab provides a high-efficiency 4-tier reading architecture.
@@ -104,11 +104,11 @@ Weavetab maps elements to ephemeral handles (`w:NN`) and visual marks (`[1]…[N
 1. **Never Construct Speculative CSS Selectors**: If an element has ref `w:14`, pass `"ref": "w:14"` to `browser_click`, `browser_fill`, `browser_type`.
 2. **Visual Mark Targeting**: On canvas or unlabelled elements from `visual: "auto"`, pass `"mark": N` directly to `browser_click({ mark: N })`.
 3. **Lifespan of Handles**: Ref IDs and marks invalidate on page navigation (`browser_navigate`) or heavy SPA re-renders. 
-4. **Recovery on Invalidation**: If an action fails with `ELEMENT_NOT_FOUND` or `MARK_NOT_FOUND`, re-run `browser_map({ visual: "auto" })` to refresh active handles.
-
-
-## form-automation
-
+4. **Recovery on Invalidation**: If an action fails with `ELEMENT_NOT_FOUND` or `MARK_NOT_FOUND`, re-run `browser_map({ visual: "auto" })` to refresh active handles.
+
+
+## form-automation
+
 # Form Automation: Atomic Multi-Field Execution
 
 Submitting complex web forms one field at a time wastes agent turns and increases the probability of layout shifts. Weavetab provides atomic multi-field batching and native dropdown selectors.
@@ -179,11 +179,11 @@ For `<select multiple>` elements, pass an array of option values:
 2. **Submit via Enter Key vs Click**:
    - If the submit button has a dynamic ref or changes during typing, send `"key": "Enter"` via `browser_key` inside the last filled text field.
    - Otherwise, locate the submit button via `browser_find` and click via `browser_click`.
-3. **Wait for Post-Submission Route**: Always follow form submission with `browser_wait` for URL changes or target DOM confirmation rather than immediately firing subsequent actions.
-
-
-## interaction-pipeline
-
+3. **Wait for Post-Submission Route**: Always follow form submission with `browser_wait` for URL changes or target DOM confirmation rather than immediately firing subsequent actions.
+
+
+## interaction-pipeline
+
 # Interaction Pipeline: Physical & Synthetic Input Engine
 
 Weavetab executes browser interactions via direct Chrome DevTools Protocol (CDP) dispatch, bypassing synthetic JavaScript event limitations and anti-automation tripwires.
@@ -374,11 +374,11 @@ Read or write system clipboard text during automation:
   "action": "write",
   "text": "AuthToken_xyz987"
 }
-```
-
-
-## tab-and-window
-
+```
+
+
+## tab-and-window
+
 # Tab & Window Lifecycle Management
 
 Multi-tab workflows (OAuth popups, payment gateways, documentation references, desktop application windows) require deterministic tab switching, window focusing, and failure recovery. `browser_tabs` controls all CDP page and window targets.
@@ -498,4 +498,4 @@ If a target page crashes or detaches due to memory limits:
 }
 ```
 
-The auto-heal routine re-establishes CDP protocol sessions, reconnects event listeners, and synchronizes the active page target.
+The auto-heal routine re-establishes CDP protocol sessions, reconnects event listeners, and synchronizes the active page target.

package/dist/bundled/weavetab-desktop.md

@@ -1,10 +1,10 @@
-# Weavetab Domain Profile: DESKTOP
-
-Generated for @weavetab/skills v2.5.0-beta.4
-
-
-## desktop-targeting
-
+# Weavetab Domain Profile: DESKTOP
+
+Generated for @weavetab/skills v2.5.0-beta.5
+
+
+## desktop-targeting
+
 # Desktop App Targeting & Multi-Window Routing
 
 Once a desktop application is detected via `browser_detect`, every standard Weavetab tool can be scoped directly to that desktop application without opening or disturbing the user's web browser.
@@ -69,11 +69,11 @@ Some Electron apps open secondary windows (e.g. popout editors, settings panels,
 
 1. Use `browser_tabs(action: "list", app: "discord")` to view all open windows and page targets for that specific app.
 2. Switch focus between windows using `browser_tabs(action: "switch", tabId: "<id>", app: "discord")`.
-3. To bring a specific native window to the foreground, use `browser_tabs(action: "focus_window", windowId: <id>, app: "discord")`.
-
-
-## electron-discovery
-
+3. To bring a specific native window to the foreground, use `browser_tabs(action: "focus_window", windowId: <id>, app: "discord")`.
+
+
+## electron-discovery
+
 # Electron Discovery & Environment Handshake
 
 Modern desktop applications (Discord, Slack, VS Code, Notion, Obsidian, Figma) are built on Chromium and Electron. Weavetab can inspect and drive these native applications through standard CDP interfaces without third-party drivers or OS-level accessibility hacks.
@@ -173,4 +173,4 @@ slack.exe --remote-debugging-port=9223
 code.exe --remote-debugging-port=9225
 ```
 
-Once launched with `--remote-debugging-port`, `browser_detect` immediately reflects the application as connectable.
+Once launched with `--remote-debugging-port`, `browser_detect` immediately reflects the application as connectable.

package/dist/bundled/weavetab-developer.md

@@ -1,10 +1,10 @@
-# Weavetab Domain Profile: DEVELOPER
-
-Generated for @weavetab/skills v2.5.0-beta.4
-
-
-## github-forensics
-
+# Weavetab Domain Profile: DEVELOPER
+
+Generated for @weavetab/skills v2.5.0-beta.5
+
+
+## github-forensics
+
 # GitHub Forensics & Repository Architecture Inspection
 
 Navigating GitHub repositories via web browsing burns massive token budgets loading HTML chrome, comment threads, and diff trees. Weavetab includes a dedicated `browser_github` tool that interacts directly with git metadata and raw endpoints.
@@ -64,4 +64,4 @@ Query repository issue trackers with state, label, and keyword filters:
   "state": "open",
   "labels": ["bug", "priority"]
 }
-```
+```

package/dist/bundled/weavetab-documents.md

@@ -1,10 +1,10 @@
-# Weavetab Domain Profile: DOCUMENTS
-
-Generated for @weavetab/skills v2.5.0-beta.4
-
-
-## canvas-and-visual-capture
-
+# Weavetab Domain Profile: DOCUMENTS
+
+Generated for @weavetab/skills v2.5.0-beta.5
+
+
+## canvas-and-visual-capture
+
 # Visual Capture, Canvas Forensics & Design Extraction
 
 Beyond textual DOM manipulation, modern web applications contain dynamic HTML5 canvas renderings (charts, maps, WebGL games), and agents often need high-fidelity visual artifacts.
@@ -87,11 +87,11 @@ Reverse-engineer UI stylesheets, active CSS custom properties (variables), typog
 }
 ```
 
-Returns structured JSON representing colors, font families, shadows, and spacing tokens.
-
-
-## office-document-ingestion
-
+Returns structured JSON representing colors, font families, shadows, and spacing tokens.
+
+
+## office-document-ingestion
+
 # Office Document Ingestion: Word, Excel & CSV Parsing
 
 Agents frequently need to parse structured spreadsheets or corporate documents downloaded during automation runs. `browser_office` parses `.docx`, `.xlsx`, `.xls`, and `.csv` files directly into clean JSON structures.
@@ -139,4 +139,4 @@ Extract semantic paragraphs, document headings, tables, and lists:
 
 ### Operational Advantages:
 - Eliminates the need for heavy external Python libraries or microservices.
-- Safely sanitizes binary formats before passing content into LLM context.
+- Safely sanitizes binary formats before passing content into LLM context.

package/dist/bundled/weavetab-memory.md

@@ -1,196 +1,196 @@
 # Weavetab Domain Profile: MEMORY
 
-Generated for @weavetab/skills v2.5.0-beta.4
+Generated for @weavetab/skills v2.5.0-beta.5
 
 
 ## selector-memory-system
 
-# Two-Tier Memory System
-
-Weavetab operates a two-tier persistent memory system. Understanding both layers prevents wasted DOM traversals and makes agents dramatically faster across sessions.
-
----
-
-## Tier 1 — Selector Confidence Cache (`~/.weavetab-system/memory/`)
-
-Per-domain JSON files (one per hostname) track individual element selectors and their interaction history.
-
-Every time an element is located and interacted with, Weavetab calculates a confidence score based on:
-1. **Attribute Stability**: Prefers `data-testid`, `id`, `aria-label`, and semantic roles over dynamic Tailwind/CSS-module class strings.
-2. **Success Count**: Selectors that successfully trigger navigation or state changes gain reinforcement.
-3. **Origin Isolation**: Learned selectors are strictly namespaced to the origin to prevent cross-site contamination.
-
-### Strike Degradation
-- **Strike 1**: Marked as degraded — falls back to secondary candidates or fuzzy label match.
-- **Strike 2**: Deprecated — immediate fallback to full DOM inspection via `browser_find` or `browser_map`.
-- **Strike 3**: Purged from memory cache to prevent stale lookups.
-
-### Agent Discipline for Tier 1
-1. **Rely on Native Tool Resolution**: When you pass a `ref`, Weavetab queries both the active volatile registry and the Tier 1 memory cache automatically.
-2. **Don't Hardcode Fragile Selectors**: Never pass brittle absolute CSS paths like `div:nth-child(3) > ul > li:nth-child(2) > button`.
-3. **Trust Heuristic Recovery**: If a button moves slightly on the page, the underlying engine re-anchors before reporting failure.
-
----
-
-## Tier 2 — Site Profiles & Workflow Patterns (`~/.weavetab-system/memory/sites/`)
-
-One JSON file per origin stores named multi-step workflow patterns, site quirks, and reliability scores. This is the **Intelligent Memory** layer — agents learn entire flows, not just individual selectors.
-
-### Checking a Site Profile at Session Start
-Always call `browser_pattern_learn` with `action: "get"` when starting an automation session on a site you may have visited before:
-
-```json
-{ "origin": "https://github.com" }
-```
-
-Response tells you:
-- `known_patterns`: named flows with reliability scores and step counts
-- `quirks`: known cookie banners, rate limits, modal popups to handle automatically
-- `framework`: detected frontend stack
-- `_hint`: compact hint string summarizing everything
-
-### Fast-Path Decision Rule
-| Reliability | Action |
-|---|---|
-| **≥ 0.8** | Use pattern steps directly via `browser_burst` — skip exploratory navigation |
-| **0.5 – 0.79** | Attempt pattern but verify success indicator before moving on |
-| **< 0.5 or strikes ≥ 3** | Ignore pattern, re-explore from scratch, then teach via `browser_pattern_learn` |
-
-### Teaching a New Pattern After Completing a Workflow
-After successfully completing a multi-step flow:
-
-```json
-{
-  "origin": "https://github.com",
-  "action": "learn",
-  "name": "login_flow",
-  "steps": [
-    { "tool": "browser_click", "target": ".btn-login" },
-    { "tool": "browser_fill", "target": "#login_field", "value": "{{username}}" },
-    { "tool": "browser_fill", "target": "#password", "value": "{{password}}" },
-    { "tool": "browser_click", "target": "[type=submit]" }
-  ],
-  "success_indicator": "a[aria-label='Homepage']"
-}
-```
-
-### Recording Execution Outcomes (Reliability Upkeep)
-After replaying a pattern, always report the outcome:
-
-```json
-{
-  "origin": "https://github.com",
-  "action": "record_execution",
-  "name": "login_flow",
-  "success": true,
-  "duration_ms": 3200
-}
-```
-
-### Recording Site Quirks
-When you discover a cookie banner or rate limit:
-
-```json
-{
-  "origin": "https://github.com",
-  "action": "record_quirk",
-  "quirk_key": "cookie_banner",
-  "quirk_data": { "selector": "#cookie-consent", "action": "click .accept-all", "appears": "first_visit" }
-}
-```
-
-On future visits, the quirk is present in the profile so you can dismiss banners before starting your main workflow — zero wasted agent turns.
-
----
-
-## File Locations (Never Write to ~/.weavetab/)
-
-| Tier | Path | Owner |
-|---|---|---|
-| Tier 1 selectors | `~/.weavetab-system/memory/<hostname>.json` | Engine (auto) |
-| Tier 2 site profiles | `~/.weavetab-system/memory/sites/<origin>.json` | Engine via `browser_pattern_learn` |
-| Knowledge hints | `~/.weavetab-system/knowledge/<hostname>.md` | Engine (auto, 20-token notes) |
+# Two-Tier Memory System
+
+Weavetab operates a two-tier persistent memory system. Understanding both layers prevents wasted DOM traversals and makes agents dramatically faster across sessions.
+
+---
+
+## Tier 1 — Selector Confidence Cache (`~/.weavetab-system/memory/`)
+
+Per-domain JSON files (one per hostname) track individual element selectors and their interaction history.
+
+Every time an element is located and interacted with, Weavetab calculates a confidence score based on:
+1. **Attribute Stability**: Prefers `data-testid`, `id`, `aria-label`, and semantic roles over dynamic Tailwind/CSS-module class strings.
+2. **Success Count**: Selectors that successfully trigger navigation or state changes gain reinforcement.
+3. **Origin Isolation**: Learned selectors are strictly namespaced to the origin to prevent cross-site contamination.
+
+### Strike Degradation
+- **Strike 1**: Marked as degraded — falls back to secondary candidates or fuzzy label match.
+- **Strike 2**: Deprecated — immediate fallback to full DOM inspection via `browser_find` or `browser_map`.
+- **Strike 3**: Purged from memory cache to prevent stale lookups.
+
+### Agent Discipline for Tier 1
+1. **Rely on Native Tool Resolution**: When you pass a `ref`, Weavetab queries both the active volatile registry and the Tier 1 memory cache automatically.
+2. **Don't Hardcode Fragile Selectors**: Never pass brittle absolute CSS paths like `div:nth-child(3) > ul > li:nth-child(2) > button`.
+3. **Trust Heuristic Recovery**: If a button moves slightly on the page, the underlying engine re-anchors before reporting failure.
+
+---
+
+## Tier 2 — Site Profiles & Workflow Patterns (`~/.weavetab-system/memory/sites/`)
+
+One JSON file per origin stores named multi-step workflow patterns, site quirks, and reliability scores. This is the **Intelligent Memory** layer — agents learn entire flows, not just individual selectors.
+
+### Checking a Site Profile at Session Start
+Always call `browser_pattern_learn` with `action: "get"` when starting an automation session on a site you may have visited before:
+
+```json
+{ "origin": "https://github.com" }
+```
+
+Response tells you:
+- `known_patterns`: named flows with reliability scores and step counts
+- `quirks`: known cookie banners, rate limits, modal popups to handle automatically
+- `framework`: detected frontend stack
+- `_hint`: compact hint string summarizing everything
+
+### Fast-Path Decision Rule
+| Reliability | Action |
+|---|---|
+| **≥ 0.8** | Use pattern steps directly via `browser_burst` — skip exploratory navigation |
+| **0.5 – 0.79** | Attempt pattern but verify success indicator before moving on |
+| **< 0.5 or strikes ≥ 3** | Ignore pattern, re-explore from scratch, then teach via `browser_pattern_learn` |
+
+### Teaching a New Pattern After Completing a Workflow
+After successfully completing a multi-step flow:
+
+```json
+{
+  "origin": "https://github.com",
+  "action": "learn",
+  "name": "login_flow",
+  "steps": [
+    { "tool": "browser_click", "target": ".btn-login" },
+    { "tool": "browser_fill", "target": "#login_field", "value": "{{username}}" },
+    { "tool": "browser_fill", "target": "#password", "value": "{{password}}" },
+    { "tool": "browser_click", "target": "[type=submit]" }
+  ],
+  "success_indicator": "a[aria-label='Homepage']"
+}
+```
+
+### Recording Execution Outcomes (Reliability Upkeep)
+After replaying a pattern, always report the outcome:
+
+```json
+{
+  "origin": "https://github.com",
+  "action": "record_execution",
+  "name": "login_flow",
+  "success": true,
+  "duration_ms": 3200
+}
+```
+
+### Recording Site Quirks
+When you discover a cookie banner or rate limit:
+
+```json
+{
+  "origin": "https://github.com",
+  "action": "record_quirk",
+  "quirk_key": "cookie_banner",
+  "quirk_data": { "selector": "#cookie-consent", "action": "click .accept-all", "appears": "first_visit" }
+}
+```
+
+On future visits, the quirk is present in the profile so you can dismiss banners before starting your main workflow — zero wasted agent turns.
+
+---
+
+## File Locations (Never Write to ~/.weavetab/)
+
+| Tier | Path | Owner |
+|---|---|---|
+| Tier 1 selectors | `~/.weavetab-system/memory/<hostname>.json` | Engine (auto) |
+| Tier 2 site profiles | `~/.weavetab-system/memory/sites/<origin>.json` | Engine via `browser_pattern_learn` |
+| Knowledge hints | `~/.weavetab-system/knowledge/<hostname>.md` | Engine (auto, 20-token notes) |
 | User config | `~/.weavetab/config.json` | Human — never written by agents |
 
 
 ## session-trail
 
-# Session Trails & Deterministic Macro Compilation
-
-When an agent executes an exploratory workflow (e.g. logging into a dashboard, navigating to analytics, setting date filters, and downloading a CSV), re-running that flow autonomously in the future should not require 15 reasoning steps.
-
-`browser_burst` with `compile_from_history: true` automatically converts recent successful session actions into a high-performance, deterministic execution script.
-
----
-
-## 1. Compiling and Replaying Recent Actions (`browser_burst`)
-
-Replay recent successful actions directly in a single turn:
-
-```json
-{
-  "compile_from_history": true
-}
-```
-
-Or pass `dry_run: true` to inspect the compiled macro steps before running them:
-
-```json
-{
-  "compile_from_history": true,
-  "dry_run": true,
-  "history_limit": 15
-}
-```
-
-### Response Example:
-```json
-{
-  "success": true,
-  "steps_completed": 0,
-  "compiled_steps": [
-    { "tool": "browser_go", "args": { "url": "https://analytics.example.com" } },
-    { "tool": "browser_fill", "args": { "ref": "w:12", "value": "metrics" } },
-    { "tool": "click_and_wait", "args": { "ref": "w:15" } }
-  ],
-  "message": "compiled 3 macro steps from history"
-}
-```
-
----
-
-## 2. Parameterizing Variable Inputs
-
-When `"parameterizeInputs": true` is passed:
-- Text inputs and dates entered during the exploratory session are replaced with named parameters.
-- Secrets entered via `browser_type_secret` are never hardcoded; they are replaced with environment variable or secret lookups.
-
----
-
-## 3. Replaying Compiled Automations
-
-Compiled macros can be executed in sub-second time without LLM inference overhead using `browser_automation`:
-
-```json
-{
-  "macroId": "macro_8f7b2c",
-  "parameters": {
-    "startDate": "2026-09-01",
-    "endDate": "2026-09-03"
-  }
-}
-```
-
----
-
-## 4. Emitting Operational Thoughts (`browser_thoughts`)
-
-Log agent rationale and internal reasoning directly to the Weavetab HUD and telemetry stream without bloating user chat responses:
-
-```json
-{
-  "thought": "Detected dynamic React hydration delay. Holding interaction until DOM mutation settles."
-}
+# Session Trails & Deterministic Macro Compilation
+
+When an agent executes an exploratory workflow (e.g. logging into a dashboard, navigating to analytics, setting date filters, and downloading a CSV), re-running that flow autonomously in the future should not require 15 reasoning steps.
+
+`browser_burst` with `compile_from_history: true` automatically converts recent successful session actions into a high-performance, deterministic execution script.
+
+---
+
+## 1. Compiling and Replaying Recent Actions (`browser_burst`)
+
+Replay recent successful actions directly in a single turn:
+
+```json
+{
+  "compile_from_history": true
+}
+```
+
+Or pass `dry_run: true` to inspect the compiled macro steps before running them:
+
+```json
+{
+  "compile_from_history": true,
+  "dry_run": true,
+  "history_limit": 15
+}
+```
+
+### Response Example:
+```json
+{
+  "success": true,
+  "steps_completed": 0,
+  "compiled_steps": [
+    { "tool": "browser_navigate", "args": { "url": "https://analytics.example.com" } },
+    { "tool": "browser_fill", "args": { "ref": "w:12", "value": "metrics" } },
+    { "tool": "click_and_wait", "args": { "ref": "w:15" } }
+  ],
+  "message": "compiled 3 macro steps from history"
+}
+```
+
+---
+
+## 2. Parameterizing Variable Inputs
+
+When `"parameterizeInputs": true` is passed:
+- Text inputs and dates entered during the exploratory session are replaced with named parameters.
+- Secrets entered via `browser_type_secret` are never hardcoded; they are replaced with environment variable or secret lookups.
+
+---
+
+## 3. Replaying Compiled Automations
+
+Compiled macros can be executed in sub-second time without LLM inference overhead using `browser_automation`:
+
+```json
+{
+  "macroId": "macro_8f7b2c",
+  "parameters": {
+    "startDate": "2026-09-01",
+    "endDate": "2026-09-03"
+  }
+}
+```
+
+---
+
+## 4. Emitting Operational Thoughts (`browser_thoughts`)
+
+Log agent rationale and internal reasoning directly to the Weavetab HUD and telemetry stream without bloating user chat responses:
+
+```json
+{
+  "thought": "Detected dynamic React hydration delay. Holding interaction until DOM mutation settles."
+}
 ```
 
 

package/dist/bundled/weavetab-network-and-perf.md

@@ -1,10 +1,10 @@
-# Weavetab Domain Profile: NETWORK-AND-PERF
-
-Generated for @weavetab/skills v2.5.0-beta.4
-
-
-## device-and-environment
-
+# Weavetab Domain Profile: NETWORK-AND-PERF
+
+Generated for @weavetab/skills v2.5.0-beta.5
+
+
+## device-and-environment
+
 # Device Emulation & Environment Simulation
 
 Auditing mobile responsive layouts, testing geographic restrictions, and simulating degraded network conditions can all be accomplished with `browser_emulate`.
@@ -76,11 +76,11 @@ To reset all overrides back to default host system parameters:
 {
   "reset": true
 }
-```
-
-
-## network-intercept-and-mock
-
+```
+
+
+## network-intercept-and-mock
+
 # Network Interception, Mocking & TLS Forensics
 
 Autonomous testing and debugging often require simulating backend error states (e.g. 500 Internal Server Error, 429 Rate Limit), stubbing third-party analytics, or verifying TLS/SSL certificates.
@@ -129,7 +129,7 @@ Extract cryptographic handshake metadata, cipher suites, expiration dates, and m
 ```json
 {
   "action": "auditTls",
-  "url": "https://weavetab.pages.dev"
+  "url": "https://weavetab.dev"
 }
 ```
 
@@ -149,11 +149,11 @@ Extract cryptographic handshake metadata, cipher suites, expiration dates, and m
     "ttfbMs": 12.8
   }
 }
-```
-
-
-## performance-and-vitals
-
+```
+
+
+## performance-and-vitals
+
 # Performance Forensics & Core Web Vitals
 
 Optimizing agent execution and auditing client performance requires objective metrics rather than arbitrary sleep timers.
@@ -220,4 +220,4 @@ Always synchronize with deterministic browser conditions:
   "selector": "[data-testid=\"checkout-complete\"]",
   "timeout": 15000
 }
-```
+```