/foreman-web-testing

name: foreman-web-testing
description: Headless end-to-end / web-app testing for the Foreman e2e stage. Derive end-to-end tests from the PRD's User Flows, drive the real application the way a user would (browser flows, screenshots, accessibility checks for web apps), make them pass via the configured e2e command, and emit the FOREMAN-SUMMARY block Foreman parses.
foreman_skill_version: 1

foreman-web-testing

(Adapted from Anthropic's `web-app-testing` skill and the e2e half of `foreman-tdd` — see NOTICE. Made stack-agnostic: the e2e runner is injected by Foreman from `config.yaml` (`commands.e2e`), not hard-coded to Playwright; for non-browser projects the same flow-driven discipline applies through whatever e2e command the project declares. Added Foreman's evidence + FOREMAN-SUMMARY contract.)

You run **headless** in the integration worktree after every issue has landed. Your job is to prove the *whole feature works end-to-end* along the journeys the PRD promised — not to re-run unit tests. Implement the e2e tests, make them pass, save evidence, then stop with exactly one FOREMAN-SUMMARY block.

Inputs (injected by Foreman in the prompt)

• The approved **PRD body** — its **`## User Flows`** section is your test charter.
• The **e2e command** for the project (`commands.e2e`, e.g. `npx playwright test` or

`pytest -m e2e`). Foreman re-runs it itself to verify, so your tests must actually pass under it.

• The **evidence directory** you must populate before claiming done.

Workflow

1. Derive flows from the PRD

Turn each user flow into a concrete end-to-end scenario: the precondition, the steps a real user takes, and the observable outcome ("given A, when B, then C"). Cover the happy path **and** the obvious failure path the flow implies (invalid input, empty state, permission denied). Do not test through internal functions — exercise the application through its real surface (the running web app, the CLI, the HTTP API).

2. Drive the real application

• **Web apps:** drive a real browser with the project's e2e tooling. Interact the way

a user does — locate elements by role/label/text, not brittle CSS nth-child paths; wait on a real condition (an element, a network response), never a fixed sleep. Check the basics a user would feel: the page renders, the primary action works, no console errors, and reasonable accessibility (labelled controls, focus order).

• **Non-web:** drive the same flow through the configured e2e command's surface (API

requests, CLI invocations), asserting on real observable output.

Capture a **screenshot (or output transcript) per flow** as you go — these are your evidence.

3. Make them pass, then verify

Run the e2e command and read its output. Iterate until every derived flow passes. A flow that can't be made to pass because the shipped feature doesn't actually deliver it is a real finding — report it (see escalation below) rather than weakening the test to go green.

4. Save evidence and summarise

Save into the evidence directory Foreman gave you: the e2e run log, and a screenshot (web) or output transcript (non-web) per flow. List every artifact in the FOREMAN-SUMMARY `evidence` array — an unbacked completion claim is rejected, and Foreman re-runs the e2e command itself regardless of what you claim.

Required output: FOREMAN-SUMMARY

End with exactly one fenced `json` block, `issue_id: "e2e"`, on Foreman's `foreman-summary/v1` schema (same shape `foreman-tdd` emits): `files_touched`, `tests_added`, `commands.e2e` (ran/passed/output_tail), `evidence`, `open_concerns`, and — if a promised flow genuinely cannot pass against the shipped feature — `escalate: true` with a one-line `escalation_question`. Set `escalate: false` when the flows pass. Nothing after the block.