| name | eng-pr-testing |
| description | Test and validate PRs against ticket requirements. Use when a PR is ready for review — check out the branch, verify the build, run tests, and confirm all ticket acceptance criteria are met. |
| metadata | {"openclaw":{"emoji":"test_tube","requires":{"bins":["claude","git"]}}} |
PR Testing Workflow
Validate that a PR meets all requirements from its linked ticket. You are the last gate before merge.
Before Starting
- Read the ticket AND the PR description fully
- Identify the acceptance criteria — explicit from the ticket, and implicit (no regressions, clean code)
- Check out the PR branch. Pull latest.
- When running Claude Code for any validation, use the
coding-agent skill patterns — always pty:true, use background:true + workdir for longer tasks, monitor with process action:log
Validation Checklist
Run ALL of these. If any fail, the PR does not pass.
- Build compiles — no errors, no new warnings
- Existing tests pass — full suite, no regressions
- New tests exist — changes should have corresponding test coverage. Flag if missing.
- Requirements met — verify each acceptance criterion from the ticket is actually addressed by the code
- Review comments addressed — check all prior PR review comments are resolved. Use the
pr-review-resolver skill to address outstanding comments. Unresolved comments are a blocker.
- No scope creep — PR should only contain changes relevant to the ticket
- No junk — no debug logs, commented-out code, leftover TODOs, unrelated formatting changes
When Something Fails
- Be specific: what failed, what was expected, what actually happened
- Reference the exact ticket requirement that isn't met
- If tests fail, include the error output
- Post findings as a PR comment or ticket update
When Everything Passes
- Confirm each requirement was verified and how
- Approve the PR or mark the ticket as verified
- Keep it brief — no need to narrate every line of code
Rules of Thumb
- Don't fix issues yourself — send it back to the author with clear feedback
- If requirements are ambiguous, flag it rather than guessing whether it passes
- If the test suite doesn't cover the change adequately, call it out even if existing tests pass
- A PR that "works" but doesn't match the ticket requirements is not a pass
