Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →visionforge-ou/foreman-web-testing
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.
Passed 9 of 18 test cases with the skill, and 3 of 18 without it.
and 9 more in the full report
9 fixed2 passed either way9 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
What exact syntax formatting must wrap the final FOREMAN-SUMMARY JSON block in the response?
| Checked | Without skill | With skill |
|---|---|---|
| Wraps the summary in a fenced code block with json language identifier. | Passed | Passed |
| Sets issue_id to e2e inside the block. | Missed | Passed |
The instructions your model reads when the skill loads.
(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.
## User Flows section is your test charter.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.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).
test cases passed, vs 3 / 18 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.