Browse QA

Non-negotiable rules:

1. Turn the incoming spec into explicit scenarios before testing.
2. Confirm ambiguous targets or platforms before execution.
3. Use the browse skill for actual browser or simulator interaction.
4. Capture evidence for each failed or important scenario.
5. Save rerunnable flows only when they are cleanly scoped and valuable for regression.

browse-qa

Inputs

• $request: Ticket, URL, app target, acceptance criteria, or plain-language QA request

Goal

Produce a credible QA run that:

• turns a vague request into explicit scenarios
• runs those scenarios against the real target
• captures evidence for passes and failures
• saves rerunnable browse flows when appropriate
• returns a clean QA report the user can act on

Step 0: Resolve the target and spec

Work out:

• what feature is being tested
• the platform: web, iOS simulator, Android emulator, or macOS app
• the target URL, build artifact, or app identifier
• the acceptance criteria or expected outcomes

If the target or platform is ambiguous, ask before testing.

Success criteria: The QA target and acceptance criteria are explicit.

Step 1: Build the scenario list

Break the request into:

• happy path
• validation or error path
• edge cases
• exploratory probes worth trying after the stated acceptance criteria

Keep the plan small enough to execute in one session unless the user asked for a broad QA sweep.

Success criteria: There is a concrete scenario list with expected outcomes.

Step 2: Execute with the browse skill

Use Skill to invoke browse for:

• navigation
• page stabilization
• interactive element discovery
• clicks, fills, and submissions
• screenshots, console logs, and network inspection

Rules:

• keep the same browse session for one logical user journey unless isolation is intentional
• use headed or handoff mode only for real blockers like CAPTCHA, MFA, or OAuth walls
• save screenshots and flow artifacts under the browse session directories

Success criteria: Each scenario is executed against the real target with enough evidence to judge pass or fail.

Step 3: Record reusable regression flows

When the scenario is stable and worth rerunning:

• record the flow
• split unrelated user journeys into separate flow files
• give each saved flow a descriptive name

Do not save noisy or half-manual recordings as regression artifacts.

Success criteria: Saved flows are independently rerunnable and map to clear scenarios.

Step 4: Report results

For each scenario, record:

• expected result
• actual result
• pass or fail
• evidence such as screenshot path, console error, or network symptom

Also report:

• exploratory findings
• regression flow files created
• blockers that prevented full verification

Success criteria: Another engineer can understand the QA outcome without replaying the whole session first.

Guardrails

• Do not duplicate the full browse command manual inline; use the browse skill.
• Do not guess a platform when the request is ambiguous.
• Do not save low-signal flows just to say a regression asset was created.
• Do not add disable-model-invocation; QA should stay available when the user asks for it.
• Do not add context: fork; results are usually needed in the current execution flow.

Output Contract

Report:

1. target tested
2. scenarios executed
3. pass/fail result for each scenario
4. evidence captured
5. regression flow files created
6. blockers or uncovered gaps