local-verify

Reproduce and verify desktop app bugs across backend, browser, and Tauri webview hops.

31|2|Updated Feb 25, 2026
One-click install
npx skills add https://github.com/shaharia-lab/agento --skill local-verify-shaharia-lab
Or copy as Structured Prompt for Agentā–¼
Please help me install this Agent Skill.
Skill: local-verify
Source: https://github.com/shaharia-lab/agento/tree/main/.claude/skills/local-verify
Command: npx skills add https://github.com/shaharia-lab/agento --skill local-verify-shaharia-lab

SYSTEM DOCUMENTATION & REQUIREMENTS

šŸ’” This Skill includes scripts (resource) components.

What problem does it solve? Bug fixes in a Tauri desktop app are often declared done after testing only in Chrome, even though webview-specific, SSE streaming, IPC permission, and OS handoff failures only appear in the real app environment. This Skill provides an end-to-end local verification playbook that reproduces a bug before fixing it and proves the fix in the exact environment that failed. ## Core Features & Use Cases - Hop-by-hop bisection: Independently test the backend wire (curl), browser engine (Chrome via Vite), WebKitGTK engine, the real Tauri webview, Tauri IPC/ACL permissions, and OS handoffs, so multi-hop failures are isolated instead of guessed at. - Pre-flight and gate scripts: preflight.sh clears stale dev processes, frees port 1420, and syncs node_modules; check.sh runs fmt, clippy, and frontend builds plus bounded serial test linking so full test runs cannot exhaust machine memory. - Real-environment probes: Capture the chat SSE stream with an authenticated bearer token, drive the live Tauri webview through the WebKit inspector protocol, shim OS launchers to verify external opens, and probe MCP tool delivery and Slack Socket Mode against real services. - Use Case: A user reports a button that works in Chrome but does nothing in the desktop app. You run preflight, launch the app with the inspector, probe __TAURI_INTERNALS__.invoke directly to check the ACL, shim xdg-open to confirm the OS handoff, and verify the fix in the real webview before pushing. ## Quick Start Ask the AI to reproduce and verify a reported desktop app bug end-to-end using the local-verify playbook, starting with the preflight script and confirming the fix in the real Tauri webview.

Frequently Asked Questions about local-verify

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a bug fix in a Tauri desktop app?ā–¼

Reproduce the bug first, then verify the fix in the real Tauri webview rather than Chrome. Launch the app with WEBKIT_INSPECTOR_HTTP_SERVER set, drive the webview through the inspector protocol, and confirm the behavior on screen with a screenshot.

Why does my Tauri app work in Chrome but fail in the desktop app?ā–¼

Chrome and the Tauri webview are different engines with different behaviors, especially for SSE streaming and IPC permissions. Bisect the hops independently: backend wire with curl, browser engine via the Vite dev server, then the real webview through the inspector.

How do I test Tauri IPC command permissions without clicking the UI?ā–¼

Call __TAURI_INTERNALS__.invoke directly inside the real webview through the inspector protocol. This shows whether a command is permitted by the ACL separately from whether the UI calls it, settling permission questions in one evaluate call.

Why does cargo test freeze my machine on a large Rust project?ā–¼

Each integration test binary links the entire static library, and cargo test links them concurrently, exhausting memory on machines with limited RAM. Run test binaries one at a time with bounded parallelism, as check.sh does with capped -j values.

How do I verify an OS handoff like opening a browser from a desktop app?ā–¼

Shim the launcher binaries (xdg-open, gio, gnome-open, kde-open) on PATH with a script that logs invocations, then launch the app under that PATH and assert on the log. Finish with one un-shimmed run to confirm the real handoff.

How do I check if MCP tools actually reach the model?ā–¼

Inspect the SSE stream's system/init frame for mcp__<server>__<tool> entries in the tools array. If absent, check the CLI debug log for tools/list failures and validate the server's response against the MCP schema for the negotiated protocol revision.