cli-jaw 0.1.7 → 0.1.8

package/skills_ref/dev-testing/SKILL.md

@@ -1,96 +0,0 @@
----
-name: dev-testing
-description: "Testing and debugging guide for orchestrated sub-agents. Playwright-based webapp testing, reconnaissance-then-action pattern. Auto-injected during debugging phase (phase 4)."
-license: Complete terms in LICENSE.txt
----
-
-# Web Application Testing
-
-To test local web applications, write native Python Playwright scripts.
-
-**Helper Scripts Available**:
-- `scripts/with_server.py` - Manages server lifecycle (supports multiple servers)
-
-**Always run scripts with `--help` first** to see usage. DO NOT read the source until you try running the script first and find that a customized solution is abslutely necessary. These scripts can be very large and thus pollute your context window. They exist to be called directly as black-box scripts rather than ingested into your context window.
-
-## Decision Tree: Choosing Your Approach
-
-```
-User task → Is it static HTML?
-    ├─ Yes → Read HTML file directly to identify selectors
-    │         ├─ Success → Write Playwright script using selectors
-    │         └─ Fails/Incomplete → Treat as dynamic (below)
-    │
-    └─ No (dynamic webapp) → Is the server already running?
-        ├─ No → Run: python scripts/with_server.py --help
-        │        Then use the helper + write simplified Playwright script
-        │
-        └─ Yes → Reconnaissance-then-action:
-            1. Navigate and wait for networkidle
-            2. Take screenshot or inspect DOM
-            3. Identify selectors from rendered state
-            4. Execute actions with discovered selectors
-```
-
-## Example: Using with_server.py
-
-To start a server, run `--help` first, then use the helper:
-
-**Single server:**
-```bash
-python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py
-```
-
-**Multiple servers (e.g., backend + frontend):**
-```bash
-python scripts/with_server.py \
-  --server "cd backend && python server.py" --port 3000 \
-  --server "cd frontend && npm run dev" --port 5173 \
-  -- python your_automation.py
-```
-
-To create an automation script, include only Playwright logic (servers are managed automatically):
-```python
-from playwright.sync_api import sync_playwright
-
-with sync_playwright() as p:
-    browser = p.chromium.launch(headless=True) # Always launch chromium in headless mode
-    page = browser.new_page()
-    page.goto('http://localhost:5173') # Server already running and ready
-    page.wait_for_load_state('networkidle') # CRITICAL: Wait for JS to execute
-    # ... your automation logic
-    browser.close()
-```
-
-## Reconnaissance-Then-Action Pattern
-
-1. **Inspect rendered DOM**:
-   ```python
-   page.screenshot(path='/tmp/inspect.png', full_page=True)
-   content = page.content()
-   page.locator('button').all()
-   ```
-
-2. **Identify selectors** from inspection results
-
-3. **Execute actions** using discovered selectors
-
-## Common Pitfall
-
-❌ **Don't** inspect the DOM before waiting for `networkidle` on dynamic apps
-✅ **Do** wait for `page.wait_for_load_state('networkidle')` before inspection
-
-## Best Practices
-
-- **Use bundled scripts as black boxes** - To accomplish a task, consider whether one of the scripts available in `scripts/` can help. These scripts handle common, complex workflows reliably without cluttering the context window. Use `--help` to see usage, then invoke directly. 
-- Use `sync_playwright()` for synchronous scripts
-- Always close the browser when done
-- Use descriptive selectors: `text=`, `role=`, CSS selectors, or IDs
-- Add appropriate waits: `page.wait_for_selector()` or `page.wait_for_timeout()`
-
-## Reference Files
-
-- **examples/** - Examples showing common patterns:
-  - `element_discovery.py` - Discovering buttons, links, and inputs on a page
-  - `static_html_automation.py` - Using file:// URLs for local HTML
-  - `console_logging.py` - Capturing console logs during automation

package/skills_ref/dev-testing/examples/console_logging.py

@@ -1,35 +0,0 @@
-from playwright.sync_api import sync_playwright
-
-# Example: Capturing console logs during browser automation
-
-url = 'http://localhost:5173'  # Replace with your URL
-
-console_logs = []
-
-with sync_playwright() as p:
-    browser = p.chromium.launch(headless=True)
-    page = browser.new_page(viewport={'width': 1920, 'height': 1080})
-
-    # Set up console log capture
-    def handle_console_message(msg):
-        console_logs.append(f"[{msg.type}] {msg.text}")
-        print(f"Console: [{msg.type}] {msg.text}")
-
-    page.on("console", handle_console_message)
-
-    # Navigate to page
-    page.goto(url)
-    page.wait_for_load_state('networkidle')
-
-    # Interact with the page (triggers console logs)
-    page.click('text=Dashboard')
-    page.wait_for_timeout(1000)
-
-    browser.close()
-
-# Save console logs to file
-with open('/mnt/user-data/outputs/console.log', 'w') as f:
-    f.write('\n'.join(console_logs))
-
-print(f"\nCaptured {len(console_logs)} console messages")
-print(f"Logs saved to: /mnt/user-data/outputs/console.log")

package/skills_ref/dev-testing/examples/element_discovery.py

@@ -1,40 +0,0 @@
-from playwright.sync_api import sync_playwright
-
-# Example: Discovering buttons and other elements on a page
-
-with sync_playwright() as p:
-    browser = p.chromium.launch(headless=True)
-    page = browser.new_page()
-
-    # Navigate to page and wait for it to fully load
-    page.goto('http://localhost:5173')
-    page.wait_for_load_state('networkidle')
-
-    # Discover all buttons on the page
-    buttons = page.locator('button').all()
-    print(f"Found {len(buttons)} buttons:")
-    for i, button in enumerate(buttons):
-        text = button.inner_text() if button.is_visible() else "[hidden]"
-        print(f"  [{i}] {text}")
-
-    # Discover links
-    links = page.locator('a[href]').all()
-    print(f"\nFound {len(links)} links:")
-    for link in links[:5]:  # Show first 5
-        text = link.inner_text().strip()
-        href = link.get_attribute('href')
-        print(f"  - {text} -> {href}")
-
-    # Discover input fields
-    inputs = page.locator('input, textarea, select').all()
-    print(f"\nFound {len(inputs)} input fields:")
-    for input_elem in inputs:
-        name = input_elem.get_attribute('name') or input_elem.get_attribute('id') or "[unnamed]"
-        input_type = input_elem.get_attribute('type') or 'text'
-        print(f"  - {name} ({input_type})")
-
-    # Take screenshot for visual reference
-    page.screenshot(path='/tmp/page_discovery.png', full_page=True)
-    print("\nScreenshot saved to /tmp/page_discovery.png")
-
-    browser.close()

package/skills_ref/dev-testing/examples/static_html_automation.py

@@ -1,33 +0,0 @@
-from playwright.sync_api import sync_playwright
-import os
-
-# Example: Automating interaction with static HTML files using file:// URLs
-
-html_file_path = os.path.abspath('path/to/your/file.html')
-file_url = f'file://{html_file_path}'
-
-with sync_playwright() as p:
-    browser = p.chromium.launch(headless=True)
-    page = browser.new_page(viewport={'width': 1920, 'height': 1080})
-
-    # Navigate to local HTML file
-    page.goto(file_url)
-
-    # Take screenshot
-    page.screenshot(path='/mnt/user-data/outputs/static_page.png', full_page=True)
-
-    # Interact with elements
-    page.click('text=Click Me')
-    page.fill('#name', 'John Doe')
-    page.fill('#email', 'john@example.com')
-
-    # Submit form
-    page.click('button[type="submit"]')
-    page.wait_for_timeout(500)
-
-    # Take final screenshot
-    page.screenshot(path='/mnt/user-data/outputs/after_submit.png', full_page=True)
-
-    browser.close()
-
-print("Static HTML automation completed!")

package/skills_ref/dev-testing/scripts/with_server.py

@@ -1,106 +0,0 @@
-#!/usr/bin/env python3
-"""
-Start one or more servers, wait for them to be ready, run a command, then clean up.
-
-Usage:
-    # Single server
-    python scripts/with_server.py --server "npm run dev" --port 5173 -- python automation.py
-    python scripts/with_server.py --server "npm start" --port 3000 -- python test.py
-
-    # Multiple servers
-    python scripts/with_server.py \
-      --server "cd backend && python server.py" --port 3000 \
-      --server "cd frontend && npm run dev" --port 5173 \
-      -- python test.py
-"""
-
-import subprocess
-import socket
-import time
-import sys
-import argparse
-
-def is_server_ready(port, timeout=30):
-    """Wait for server to be ready by polling the port."""
-    start_time = time.time()
-    while time.time() - start_time < timeout:
-        try:
-            with socket.create_connection(('localhost', port), timeout=1):
-                return True
-        except (socket.error, ConnectionRefusedError):
-            time.sleep(0.5)
-    return False
-
-
-def main():
-    parser = argparse.ArgumentParser(description='Run command with one or more servers')
-    parser.add_argument('--server', action='append', dest='servers', required=True, help='Server command (can be repeated)')
-    parser.add_argument('--port', action='append', dest='ports', type=int, required=True, help='Port for each server (must match --server count)')
-    parser.add_argument('--timeout', type=int, default=30, help='Timeout in seconds per server (default: 30)')
-    parser.add_argument('command', nargs=argparse.REMAINDER, help='Command to run after server(s) ready')
-
-    args = parser.parse_args()
-
-    # Remove the '--' separator if present
-    if args.command and args.command[0] == '--':
-        args.command = args.command[1:]
-
-    if not args.command:
-        print("Error: No command specified to run")
-        sys.exit(1)
-
-    # Parse server configurations
-    if len(args.servers) != len(args.ports):
-        print("Error: Number of --server and --port arguments must match")
-        sys.exit(1)
-
-    servers = []
-    for cmd, port in zip(args.servers, args.ports):
-        servers.append({'cmd': cmd, 'port': port})
-
-    server_processes = []
-
-    try:
-        # Start all servers
-        for i, server in enumerate(servers):
-            print(f"Starting server {i+1}/{len(servers)}: {server['cmd']}")
-
-            # Use shell=True to support commands with cd and &&
-            process = subprocess.Popen(
-                server['cmd'],
-                shell=True,
-                stdout=subprocess.PIPE,
-                stderr=subprocess.PIPE
-            )
-            server_processes.append(process)
-
-            # Wait for this server to be ready
-            print(f"Waiting for server on port {server['port']}...")
-            if not is_server_ready(server['port'], timeout=args.timeout):
-                raise RuntimeError(f"Server failed to start on port {server['port']} within {args.timeout}s")
-
-            print(f"Server ready on port {server['port']}")
-
-        print(f"\nAll {len(servers)} server(s) ready")
-
-        # Run the command
-        print(f"Running: {' '.join(args.command)}\n")
-        result = subprocess.run(args.command)
-        sys.exit(result.returncode)
-
-    finally:
-        # Clean up all servers
-        print(f"\nStopping {len(server_processes)} server(s)...")
-        for i, process in enumerate(server_processes):
-            try:
-                process.terminate()
-                process.wait(timeout=5)
-            except subprocess.TimeoutExpired:
-                process.kill()
-                process.wait()
-            print(f"Server {i+1} stopped")
-        print("All servers stopped")
-
-
-if __name__ == '__main__':
-    main()

package/skills_ref/develop-web-game/SKILL.md

@@ -1,149 +0,0 @@
----
-name: "develop-web-game"
-description: "Use when Codex is building or iterating on a web game (HTML/JS) and needs a reliable development + testing loop: implement small changes, run a Playwright-based test script with short input bursts and intentional pauses, inspect screenshots/text, and review console errors with render_game_to_text."
----
-
-
-# Develop Web Game
-
-Build games in small steps and validate every change. Treat each iteration as: implement → act → pause → observe → adjust.
-
-## Skill paths (set once)
-
-```bash
-export CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
-export WEB_GAME_CLIENT="$CODEX_HOME/skills/develop-web-game/scripts/web_game_playwright_client.js"
-export WEB_GAME_ACTIONS="$CODEX_HOME/skills/develop-web-game/references/action_payloads.json"
-```
-
-User-scoped skills install under `$CODEX_HOME/skills` (default: `~/.codex/skills`).
-
-## Workflow
-
-1. **Pick a goal.** Define a single feature or behavior to implement.
-2. **Implement small.** Make the smallest change that moves the game forward.
-3. **Ensure integration points.** Provide a single canvas and `window.render_game_to_text` so the test loop can read state.
-4. **Add `window.advanceTime(ms)`.** Strongly prefer a deterministic step hook so the Playwright script can advance frames reliably; without it, automated tests can be flaky.
-5. **Initialize progress.md.** If `progress.md` exists, read it first and confirm the original user prompt is recorded at the top (prefix with `Original prompt:`). Also note any TODOs and suggestions left by the previous agent. If missing, create it and write `Original prompt: <prompt>` at the top before appending updates.
-6. **Verify Playwright availability.** Ensure `playwright` is available (local dependency or global install). If unsure, check `npx` first.
-7. **Run the Playwright test script.** You must run `$WEB_GAME_CLIENT` after each meaningful change; do not invent a new client unless required.
-8. **Use the payload reference.** Base actions on `$WEB_GAME_ACTIONS` to avoid guessing keys.
-9. **Inspect state.** Capture screenshots and text state after each burst.
-10. **Inspect screenshots.** Open the latest screenshot, verify expected visuals, fix any issues, and rerun the script. Repeat until correct.
-11. **Verify controls and state (multi-step focus).** Exhaustively exercise all important interactions. For each, think through the full multi-step sequence it implies (cause → intermediate states → outcome) and verify the entire chain works end-to-end. Confirm `render_game_to_text` reflects the same state shown on screen. If anything is off, fix and rerun.
-    Examples of important interactions: move, jump, shoot/attack, interact/use, select/confirm/cancel in menus, pause/resume, restart, and any special abilities or puzzle actions defined by the request. Multi-step examples: shooting an enemy should reduce its health; when health reaches 0 it should disappear and update the score; collecting a key should unlock a door and allow level progression.
-12. **Check errors.** Review console errors and fix the first new issue before continuing.
-13. **Reset between scenarios.** Avoid cross-test state when validating distinct features.
-14. **Iterate with small deltas.** Change one variable at a time (frames, inputs, timing, positions), then repeat steps 7–13 until stable.
-
-Example command (actions required):
-```
-node "$WEB_GAME_CLIENT" --url http://localhost:5173 --actions-file "$WEB_GAME_ACTIONS" --click-selector "#start-btn" --iterations 3 --pause-ms 250
-```
-
-Example actions (inline JSON):
-```json
-{
-  "steps": [
-    { "buttons": ["left_mouse_button"], "frames": 2, "mouse_x": 120, "mouse_y": 80 },
-    { "buttons": [], "frames": 6 },
-    { "buttons": ["right"], "frames": 8 },
-    { "buttons": ["space"], "frames": 4 }
-  ]
-}
-```
-
-## Test Checklist
-
-Test any new features added for the request and any areas your logic changes could affect. Identify issues, fix them, and re-run the tests to confirm they’re resolved.
-
-Examples of things to test:
-- Primary movement/interaction inputs (e.g., move, jump, shoot, confirm/select).
-- Win/lose or success/fail transitions.
-- Score/health/resource changes.
-- Boundary conditions (collisions, walls, screen edges).
-- Menu/pause/start flow if present.
-- Any special actions tied to the request (powerups, combos, abilities, puzzles, timers).
-
-## Test Artifacts to Review
-
-- Latest screenshots from the Playwright run.
-- Latest `render_game_to_text` JSON output.
-- Console error logs (fix the first new error before continuing).
-You must actually open and visually inspect the latest screenshots after running the Playwright script, not just generate them. Ensure everything that should be visible on screen is actually visible. Go beyond the start screen and capture gameplay screenshots that cover all newly added features. Treat the screenshots as the source of truth; if something is missing, it is missing in the build. If you suspect a headless/WebGL capture issue, rerun the Playwright script in headed mode and re-check. Fix and rerun in a tight loop until the screenshots and text state look correct. Once fixes are verified, re-test all important interactions and controls, confirm they work, and ensure your changes did not introduce regressions. If they did, fix them and rerun everything in a loop until interactions, text state, and controls all work as expected. Be exhaustive in testing controls; broken games are not acceptable.
-
-## Core Game Guidelines
-
-### Canvas + Layout
-- Prefer a single canvas centered in the window.
-
-### Visuals
-- Keep on-screen text minimal; show controls on a start/menu screen rather than overlaying them during play.
-- Avoid overly dark scenes unless the design calls for it. Make key elements easy to see.
-- Draw the background on the canvas itself instead of relying on CSS backgrounds.
-
-### Text State Output (render_game_to_text)
-Expose a `window.render_game_to_text` function that returns a concise JSON string representing the current game state. The text should include enough information to play the game without visuals.
-
-Minimal pattern:
-```js
-function renderGameToText() {
-  const payload = {
-    mode: state.mode,
-    player: { x: state.player.x, y: state.player.y, r: state.player.r },
-    entities: state.entities.map((e) => ({ x: e.x, y: e.y, r: e.r })),
-    score: state.score,
-  };
-  return JSON.stringify(payload);
-}
-window.render_game_to_text = renderGameToText;
-```
-
-Keep the payload succinct and biased toward on-screen/interactive elements. Prefer current, visible entities over full history.
-Include a clear coordinate system note (origin and axis directions), and encode all player-relevant state: player position/velocity, active obstacles/enemies, collectibles, timers/cooldowns, score, and any mode/state flags needed to make correct decisions. Avoid large histories; only include what's currently relevant and visible.
-
-### Time Stepping Hook
-Provide a deterministic time-stepping hook so the Playwright client can advance the game in controlled increments. Expose `window.advanceTime(ms)` (or a thin wrapper that forwards to your game update loop) and have the game loop use it when present.
-The Playwright test script uses this hook to step frames deterministically during automated testing.
-
-Minimal pattern:
-```js
-window.advanceTime = (ms) => {
-  const steps = Math.max(1, Math.round(ms / (1000 / 60)));
-  for (let i = 0; i < steps; i++) update(1 / 60);
-  render();
-};
-```
-
-### Fullscreen Toggle
-- Use a single key (prefer `f`) to toggle fullscreen on/off.
-- Allow `Esc` to exit fullscreen.
-- When fullscreen toggles, resize the canvas/rendering so visuals and input mapping stay correct.
-
-## Progress Tracking
-
-Create a `progress.md` file if it doesn't exist, and append TODOs, notes, gotchas, and loose ends as you go so another agent can pick up seamlessly.
-If a `progress.md` file already exists, read it first, including the original user prompt at the top (you may be continuing another agent's work). Do not overwrite the original prompt; preserve it.
-Update `progress.md` after each meaningful chunk of work (feature added, bug found, test run, or decision made).
-At the end of your work, leave TODOs and suggestions for the next agent in `progress.md`.
-
-## Playwright Prerequisites
-
-- Prefer a local `playwright` dependency if the project already has it.
-- If unsure whether Playwright is available, check for `npx`:
-  ```
-  command -v npx >/dev/null 2>&1
-  ```
-- If `npx` is missing, install Node/npm and then install Playwright globally:
-  ```
-  npm install -g @playwright/mcp@latest
-  ```
-- Do not switch to `@playwright/test` unless explicitly asked; stick to the client script.
-
-## Scripts
-
-- `$WEB_GAME_CLIENT` (installed default: `$CODEX_HOME/skills/develop-web-game/scripts/web_game_playwright_client.js`) — Playwright-based action loop with virtual-time stepping, screenshot capture, and console error buffering. You must pass an action burst via `--actions-file`, `--actions-json`, or `--click`.
-
-## References
-
-- `$WEB_GAME_ACTIONS` (installed default: `$CODEX_HOME/skills/develop-web-game/references/action_payloads.json`) — example action payloads (keyboard + mouse, per-frame capture). Use these to build your burst.

package/skills_ref/differential-review/.claude-plugin/plugin.json

@@ -1,10 +0,0 @@
-{
-  "name": "differential-review",
-  "version": "1.0.0",
-  "description": "Security-focused differential review of code changes with git history analysis and blast radius estimation",
-  "author": {
-    "name": "Omar Inuwa",
-    "email": "opensource@trailofbits.com",
-    "url": "https://github.com/trailofbits"
-  }
-}

package/skills_ref/differential-review/README.md

@@ -1,109 +0,0 @@
-# Differential Review
-
-Security-focused differential review of code changes with git history analysis and blast radius estimation.
-
-**Author:** Omar Inuwa
-
-## When to Use
-
-Use this skill when you need to:
-- Review PRs, commits, or diffs for security vulnerabilities
-- Detect security regressions (re-introduced vulnerabilities)
-- Analyze the blast radius of code changes
-- Check test coverage gaps for modified code
-
-## What It Does
-
-This skill performs comprehensive security review of code changes:
-
-- **Risk-First Analysis** - Prioritizes auth, crypto, value transfer, external calls
-- **Git History Analysis** - Uses blame to understand why code existed and detect regressions
-- **Blast Radius Calculation** - Quantifies impact by counting callers
-- **Test Coverage Gaps** - Identifies untested changes
-- **Adaptive Depth** - Scales analysis based on codebase size (small/medium/large)
-
-## Installation
-
-```
-/plugin install trailofbits/skills/plugins/differential-review
-```
-
-## Documentation Structure
-
-This skill uses a **modular documentation architecture** for token efficiency and progressive disclosure:
-
-### Core Entry Point
-- **[SKILL.md](skills/differential-review/SKILL.md)** - Main entry point (217 lines)
-  - Quick reference tables for triage
-  - Decision tree routing to detailed docs
-  - Quality checklist and red flags
-  - Integration with other skills
-
-### Supporting Documentation
-- **[methodology.md](skills/differential-review/methodology.md)** - Detailed phase-by-phase workflow (~200 lines)
-  - Pre-Analysis: Baseline context building
-  - Phase 0: Intake & Triage
-  - Phase 1: Changed Code Analysis
-  - Phase 2: Test Coverage Analysis
-  - Phase 3: Blast Radius Analysis
-  - Phase 4: Deep Context Analysis
-
-- **[adversarial.md](skills/differential-review/adversarial.md)** - Attacker modeling and exploit scenarios (~150 lines)
-  - Phase 5: Adversarial Vulnerability Analysis
-  - Attacker model definition (WHO/ACCESS/INTERFACE)
-  - Exploitability rating framework
-  - Complete exploit scenario templates
-
-- **[reporting.md](skills/differential-review/reporting.md)** - Report structure and formatting (~120 lines)
-  - Phase 6: Report Generation
-  - 9-section report template
-  - Formatting guidelines and conventions
-  - File naming and notification templates
-
-- **[patterns.md](skills/differential-review/patterns.md)** - Common vulnerability patterns (~80 lines)
-  - Security regressions detection
-  - Reentrancy, access control, overflow patterns
-  - Quick detection bash commands
-
-### Benefits of This Structure
-- **Token Efficient** - Load only the documentation you need
-- **Progressive Disclosure** - Quick reference for triage, detailed docs for deep analysis
-- **Maintainable** - Each concern separated into its own file
-- **Navigable** - Decision tree routes you to the right document
-
-## Workflow
-
-The complete workflow spans Pre-Analysis + Phases 0-6:
-
-1. **Pre-Analysis** - Build baseline context with `audit-context-building` skill (if available)
-2. **Phase 0: Intake** - Extract changes, assess size, risk-score files
-3. **Phase 1: Changed Code** - Analyze diffs, git blame, check for regressions
-4. **Phase 2: Test Coverage** - Identify coverage gaps
-5. **Phase 3: Blast Radius** - Calculate impact of changes
-6. **Phase 4: Deep Context** - Five Whys root cause analysis
-7. **Phase 5: Adversarial Analysis** - Hunt vulnerabilities with attacker model
-8. **Phase 6: Report** - Generate comprehensive markdown report
-
-**Navigation:** Use the decision tree in SKILL.md to jump directly to the phase you need.
-
-## Output
-
-Generates a markdown report with:
-- Executive summary with severity distribution
-- Critical findings with attack scenarios and PoCs
-- Test coverage analysis
-- Blast radius analysis
-- Historical context and regression risks
-- Actionable recommendations
-
-## Example Usage
-
-```
-Review the security implications of this PR:
-git diff main..feature/auth-changes
-```
-
-## Related Skills
-
-- `context-building` - Used for baseline context analysis
-- `issue-writer` - Transform findings into formal audit reports

package/skills_ref/differential-review/commands/diff-review.md

@@ -1,21 +0,0 @@
----
-name: trailofbits:diff-review
-description: Performs security-focused differential review of code changes
-argument-hint: "<pr-url|commit-sha|diff-path> [--baseline <ref>]"
-allowed-tools:
-  - Read
-  - Write
-  - Grep
-  - Glob
-  - Bash
----
-
-# Differential Security Review
-
-**Arguments:** $ARGUMENTS
-
-Parse arguments:
-1. **Target** (required): PR URL, commit SHA, or diff path
-2. **Baseline** (optional): `--baseline <ref>` for comparison reference
-
-Invoke the `differential-review` skill with these arguments for the full workflow.