Routes, server, and reporting

Read this before mapping changed files to routes (workflow step 3). It carries the route-mapping starting points, the port and server commands, what to check on each page, the two human-facing prompts, and the summary format.

Map changed files to routes

Map each changed file to the route(s) that render it, then build the list of URLs to test. The table below is a starting point of common patterns, not an exhaustive rule set — apply judgment for the project's actual layout:

Determine the port and verify the dev server is running

scripts/resolve-port.sh resolves the port and prints it alone on stdout, so the shell call that needs it captures the value instead of a later step re-typing a printed number. Append the explicit port as an argument when you have one.

SKILL_DIR="<absolute path of the directory containing the SKILL.md you just read>";
PORT=$(bash "$SKILL_DIR/scripts/resolve-port.sh");
if lsof -i ":${PORT}" -sTCP:LISTEN -t >/dev/null 2>&1; then
  echo "Server running on port ${PORT}";
else
  echo "Server not running on port ${PORT}";
  echo "Start your dev server, then re-run:";
  echo "  Rails: bin/dev  or  rails server -p ${PORT}";
  echo "  Node/Next.js: npm run dev";
  echo "  Custom port: run this skill again with --port <your-port>";
  exit 0;
fi

Test each affected page

For each affected route, use the selected driver to navigate and capture fresh rendered or interactive state.

Verify key elements:

• Page title/heading present
• Primary content rendered
• No error messages visible
• Forms have expected fields
• No new console errors attributable to the tested flow

Test critical interactions: derive locators or element references from the selected driver's latest inspected state, perform the click/fill/press action, then inspect the resulting state. Do not guess selectors or reuse stale references.

Take screenshots: capture viewport and full-page evidence when the selected driver supports it. Materialize screenshots as local artifacts when a later workflow or report needs file paths; otherwise in-app evidence is sufficient.

Human verification (when required)

Ask the user with the platform's question tool (the list is in SKILL.md step 6), or present numbered options and wait:

Human Verification Needed

This test touches [flow type]. Please:
1. [Action to take]
2. [What to verify]

Did it work correctly?
1. Yes - continue testing
2. No - describe the issue

Handle failures

1. Document the failure:
2. Capture a screenshot of the error state with the selected driver
3. Note the exact reproduction steps

1. Ask the user how to proceed:

``` Test Failed: [route]

Issue: [description] Console errors: [if any]

How to proceed?

1. Fix now - debug and fix the failing test
2. Skip - continue testing other pages ```

1. If "Fix now": investigate, propose a fix, apply, re-run the failing test
2. If "Skip": log as skipped, continue

Test summary

## Browser Test Results

**Test Scope:** PR #[number] / [branch name]
**Server:** http://localhost:<port>

### Pages Tested: [count]

| Route | Status | Notes |
|-------|--------|-------|
| `/users` | Pass | |
| `/settings` | Pass | |
| `/dashboard` | Fail | Console error: [msg] |
| `/checkout` | Skip | Requires payment credentials |

### Console Errors: [count]
- [List any errors found]

### Human Verifications: [count]
- OAuth flow: Confirmed
- Email delivery: Confirmed

### Failures: [count]
- `/dashboard` - [issue description]

### Result: [PASS / FAIL / PARTIAL]