Slash Command

/browser-trace

Capture full browser observability for a URL — network requests, DOM snapshots, screenshots, and console logs dumped to a searchable filesystem. Use for reverse engineering, autoresearch loops, flaky test diagnosis, and pre-QA reconnaissance.

Invocation

How this command is triggered — by the user, by Claude, or both

Slash command

/engineering:browser-trace <URL> [output dir]

Model invocable

No pre-commands

Tool Access

This command is limited to the following tools:

BashReadWriteAskUserQuestion

Context Preview

The summary Claude sees in its command listing — used to decide when to auto-load this command

Capture complete browser observability for a URL using `scripts/browser_trace.py` from the quality-assurance skill. Dump network requests, DOM snapshots, screenshots, and console logs into a searchable filesystem, then interpret the findings.

## Steps

1. **Confirm the target** — If no URL was provided, ask for it. If no output directory was specified, default to `/tmp/browser-trace-<timestamp>`.

2. **Run the trace:**
   
   Add `--wait "<selector>"` if the page is a SPA that loads content asynchronously. Add `--playwright-trace` if a visual trace viewer is needed.

3. **Read the summary:...

Command Content

57 lines · ~579 tokens

Stats

LanguagePython

Parent stars0

MaintenanceGood

Last CommitMay 14, 2026

Actions

View Source View Plugin View on GitHub View README

Stats

Actions

Steps

Confirm the target — If no URL was provided, ask for it. If no output directory was specified, default to /tmp/browser-trace-<timestamp>.
Run the trace:
```
python <skill-dir>/scripts/browser_trace.py \
  --url <URL> \
  --output <output-dir> \
  [--wait "<selector>"] \
  [--playwright-trace]
```
Add --wait "<selector>" if the page is a SPA that loads content asynchronously. Add --playwright-trace if a visual trace viewer is needed.
Read the summary:
```
cat <output-dir>/summary.json
```

Search the artifacts — always run at minimum:

# API surface
grep '"/api/' <output-dir>/network/requests.jsonl | head -30

# Error responses
grep -E '"status": [45][0-9][0-9]' <output-dir>/network/responses.jsonl

# Console errors and JS exceptions
cat <output-dir>/console/errors.log

# Failed network requests
cat <output-dir>/network/failed.jsonl 2>/dev/null || echo "(none)"

Report findings — summarize:
- Total requests, responses, errors, and snapshots
- API endpoints discovered (unique /api/... paths)
- Any HTTP 4xx/5xx responses with URLs
- Console errors and page errors
- Notable DOM patterns (forms, error states, data-testid attributes)
- Screenshot paths for visual review
Next step suggestion — based on findings, suggest whether to:
- Run the full live web app QA workflow (quality-assurance → Live web app QA)
- Use BrowserTrace.attach() inline in an E2E test for flaky test diagnosis
- Diff this trace against another run to find regression
- Use the API endpoints discovered to scaffold contract tests