| 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.
