Run QA validation on a pull request — boots the local environment, tests acceptance criteria, and optionally posts the report as a PR comment. Standalone entry point for the qa-engineer agent.
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
Standalone QA run for any PR. Boots the local environment, validates every acceptance criterion, and produces a test report. Posting to GitHub is your choice — you are prompted at the end.
This skill targets wp-media/wp-rocket. Specs live at .TemporaryItems/Issues/wp-rocket/issues/<N>-spec.md.
Use $ARGUMENTS as the PR number or URL. If empty, resolve from the current branch:
gh pr list --head "$(git branch --show-current)" --json number,url -q '.[0] | "\(.number) \(.url)"'
If no PR is found, tell the user and stop.
Get the base branch:
gh pr view <PR_NUMBER> --json baseRefName -q .baseRefName
Invoke the qa-engineer sub-agent with:
wp-media/wp-rocketSTANDALONE MODE — two differences from the normal pipeline run:
- Skip the PR-comment posting step. Instead, output the full QA report as formatted Markdown in your response, in a section titled
## QA Report. Use the same format the pipeline would post (including the<!-- ai-pipeline:qa-report -->marker).- Skip the StructuredOutput JSON return. Output a short human-readable summary instead: overall result, pass/fail per criterion, and any blockers.
All other steps run normally — the local environment is booted, acceptance criteria are tested, and the full validation is performed.
After the agent responds, display its ## QA Report and ask:
Post this QA report to PR #<PR_NUMBER>? Reply
yesto post,noto finish here.
If yes — post with dedup: check for an existing <!-- ai-pipeline:qa-report --> comment,
update it with gh api --method PATCH repos/wp-media/wp-rocket/issues/comments/$EXISTING_ID if found, otherwise create a new comment.
If no — confirm the QA run is complete and finish.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Adversarially review a grooming spec before implementation starts. Finds hidden risks, unvalidated assumptions, and missing dependencies. Standalone entry point for the challenger agent.
The English summary is being prepared. Showing the original description.
Check a change against WordPress.org plugin rules and PHPCS standards.
The English summary is being prepared. Showing the original description.
Update developer-facing documentation to reflect code changes on the current branch. Runs as an inline skill inside backend-agent and frontend-agent (step 2.5 of the internal sequence) after implementation and before DOD. Receives the explicit list of changed files from the implementation agent. No-op if no public API changes occurred.
The English summary is being prepared. Showing the original description.
Run the Definition of Done checklist for the current wp-rocket branch and report PASS/WARN/FAIL with evidence. Two modes: layer 1 (self-correction inside backend-agent / frontend-agent — resolves FAILs before handoff) and layer 2 (independent orchestrator gate — fresh perspective after handoff). Pass layer: "1" or layer: "2" when invoking.
The English summary is being prepared. Showing the original description.
Run a basic E2E behavioral probe — one primary scenario smoke test for the grooming step.
The English summary is being prepared. Showing the original description.
Groom a single GitHub issue — produce an implementation spec and optionally post the grooming summary as a GitHub comment. Standalone entry point for the grooming-agent.
The English summary is being prepared. Showing the original description.