Implementing Browser Automation for Security Testing with Playwright and OpenReverse

The reverse-skill repository provides a unified browser automation stack that routes security testing requests to either Playwright for web automation or OpenReverse for Windows desktop UI automation, orchestrated through a three-dimensional routing matrix in skills/config/routing.json.

The reverse-skill repository by zhaoxuya520 implements a platform-neutral "skill router" for security workflows. This guide covers implementing browser automation for security testing using its dual-stack approach—combining Playwright's headless browser capabilities with OpenReverse's desktop UI automation—governed by an intelligent routing system that matches user intent to the correct tool chain.

How the Routing Matrix Directs Browser Automation Requests

At the heart of reverse-skill lies the routing matrix defined in skills/config/routing.json and documented in skills/routing.md. This three-dimensional structure evaluates:

• Target type (web application, desktop binary, API endpoint)
• User intent (open webpage, fill form, capture traffic, manipulate UI)
• Toolchain availability (Playwright, Node.js, OpenReverse, PowerShell)

When a request matches patterns like "open webpage / browser automation / fill form" or "desktop automation / Windows automation" (lines 102-104 of routing.md), the master routing system in skills/MASTER-ROUTING.md resolves the path to browser-automation/SKILL.md. The master-route.ps1 script performs this resolution programmatically:

# Primary routing – resolves the skill path

powershell -NoProfile -ExecutionPolicy Bypass -File skills/scripts/master-route.ps1 `
    -Hint "open webpage / browser automation / fill form"

# Expected output: → browser-automation/

The RULES.md file imposes gating constraints on this routing—enforcing security policies such as "no ACT before auth & network profile"—ensuring browser automation executes within proper operational boundaries.

Setting Up the Browser Automation Environment

Before executing automation scripts, initialize a sandboxed case workspace that records scope and maintains evidence isolation.

Initialize a Case Workspace

The case-init.ps1 script creates the directory structure under work/<case>/ and generates a scope.md file:

# Create a new case workspace and generate scope.md

powershell -File skills/scripts/case-init.ps1 -Hint "browser-automation-demo"

Verify Tool Availability

The tool-index.md file maintains an auto-generated inventory of detected tools. Confirm Playwright and OpenReverse presence before execution. The browser-automation skill validates these dependencies through entries in skills/tool-index.md.

Implementing Web Automation with Playwright

Playwright handles headless or full-browser automation for modern web stacks—navigation, form interaction, screenshot capture, and single-page application (SPA) testing.

Installation and Basic Execution

Node-based scripts reside in browser-automation/scripts/. First-time setup requires Playwright installation:

# Install Playwright (first-time only)

npm i -D playwright

# Run a simple navigation + screenshot script

node browser-automation/scripts/playwright-demo.js \
    --url "https://example.com" \
    --output "./work/browser-automation-demo/screenshot.png"

Core Playwright Script Structure

The playwright-demo.js file in browser-automation/scripts/ implements the standard pattern:

const { chromium } = require('playwright');
const argv = require('minimist')(process.argv.slice(2));

(async () => {
  const browser = await chromium.launch({ headless: true });
  const page = await browser.newPage();
  await page.goto(argv.url);
  await page.screenshot({ path: argv.output });
  await browser.close();
})();

This pattern supports security testing workflows including:

• Authentication flow capture – programmatic login with credential injection
• DOM state extraction – harvesting form structures and hidden fields
• Network interception – capturing XHR/fetch traffic for API analysis
• Visual regression – screenshot comparison for detecting UI changes

Implementing Desktop Automation with OpenReverse

OpenReverse extends automation to Windows desktop applications through UI Automation (UIA/CUA) interfaces, with optional MITM proxying for network traffic observation.

Executing OpenReverse Automation

PowerShell wrappers in browser-automation/scripts/ drive the OpenReverse CLI:

# Launch a Windows Calculator automation via OpenReverse

powershell -File browser-automation/scripts/openreverse-demo.ps1 `
    -App "calc.exe" `
    -Actions @(
        @{ type="click"; selector="Button1" },
        @{ type="click"; selector="Button2" },
        @{ type="click"; selector="ButtonEquals" }
    )

OpenReverse Security Testing Capabilities

The openreverse-demo.ps1 script wraps OpenReverse functionality for:

• UI element manipulation – programmatic clicking, text entry, menu navigation
• Runtime state inspection – extracting control properties and window hierarchies
• Network traffic capture – MITM proxy integration for observing encrypted desktop app communications
• Binary behavior analysis – correlating UI actions with network requests

This proves essential for testing thick-client applications, legacy enterprise software, or desktop components of hybrid web-desktop systems.

Evidence Collection and Reporting

After automation execution, the ops/ contracts and docs-generator/ module produce verifiable evidence:

# After automation, produce a Markdown report

powershell -File skills/docs-generator/generate-report.ps1 `
    -Case "browser-automation-demo" `
    -Template "templates/browser-report.md"

The generator outputs:

• Timeline reconstruction – chronological automation steps with timestamps
• Evidence graph – visual relationships between network captures, screenshots, and UI states
• Structured report – Markdown/HTML documentation suitable for audit trails

CI Verification and Quality Assurance

All browser automation paths undergo continuous integration testing across Windows and Ubuntu environments:

Script	Purpose	Location
test-routing.ps1	163-case regression suite	skills/scripts/test-routing.ps1
verify-routing-coherence.ps1	Structural and supply-chain validation	skills/scripts/verify-routing-coherence.ps1
smoke.ps1	Quick health check for critical paths	Repository root

These scripts ensure routing resolution, script execution, and evidence generation remain functional across platform updates.

Key Architectural References

File	Purpose
skills/browser-automation/SKILL.md	Skill definition and workflow documentation
skills/config/routing.json	Machine-readable routing matrix
skills/routing.md	Human-readable routing tables (target × intent × toolchain)
skills/ARCHITECTURE.md	System diagram of routing core and tool index
skills/MASTER-ROUTING.md	Fast-path entry point for skill resolution
skills/tool-index.md	Auto-generated tool inventory

Summary

• reverse-skill implements browser automation for security testing through a routing matrix (skills/config/routing.json) that matches requests to Playwright or OpenReverse based on target type, user intent, and toolchain availability.
• Playwright (browser-automation/scripts/playwright-demo.js) handles web automation—navigation, form filling, screenshot capture, and SPA interaction—via Node.js scripts.
• OpenReverse (browser-automation/scripts/openreverse-demo.ps1) provides Windows desktop UI automation with UIA/CUA and optional MITM network proxying.
• Master routing (master-route.ps1) and case initialization (case-init.ps1) establish sandboxed, auditable execution environments.
• Evidence generation (docs-generator/generate-report.ps1) produces timelines, graphs, and reports for security testing documentation.
• CI verification (test-routing.ps1, verify-routing-coherence.ps1) ensures automation reliability across Windows and Ubuntu.

Frequently Asked Questions

How does reverse-skill choose between Playwright and OpenReverse?

The routing matrix in skills/config/routing.json evaluates three dimensions: target type (web vs. desktop), user intent (open webpage vs. manipulate UI), and toolchain availability. Web targets route to Playwright; Windows desktop targets route to OpenReverse. The master-route.ps1 script performs this resolution in milliseconds based on the user's hint string.

What security policies restrict browser automation execution?

The RULES.md file enforces gating logic such as "no ACT before auth & network profile"—meaning certain aggressive automation actions require authentication and network scope definition first. The routing system validates these preconditions before permitting script execution, preventing unauthorized or out-of-scope automation.

Can I extend browser-automation with custom scripts?

Yes. Each skill module follows a self-contained directory structure with SKILL.md documentation. Add Node.js scripts to browser-automation/scripts/ for Playwright extensions, or PowerShell scripts for OpenReverse workflows. The tool-index.md auto-detects new tools, and routing.md accepts new matrix entries to expose custom scripts through the master router.

How does evidence collection work for compliance requirements?

The ops/ contracts generate a structured timeline and evidence graph automatically. The docs-generator/generate-report.ps1 script produces Markdown/HTML reports with embedded screenshots, network captures, and UI state logs. All artifacts reside in the case-specific work/<case>/ directory, providing an immutable audit trail for security assessments.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}