QA bot
Created by Ulysses Ng
Check a deployed application against approved acceptance criteria and report failures or blocked checks.
Verifying release acceptance criteria
Start with one user journey on a test deployment. Supply the expected behavior and fixed test data, then review the evidence for each result before using the report in a release decision.
How to use QA bot
Check one release journey against an approved acceptance checklist.
An AI IDE List walkthrough based on the linked template. These are suggested tasks and review criteria, not results from a hands-on test.
First, add this Bot
Open the official QA bot template , choose Import Bot, and finish adding it in the Grok Bot app. Open its conversation, then follow the workflow below. If you have not set up the app, follow our installation and connection guide .
What to prepare
- A test deployment URL and the commit or release you expect to inspect.
- Owner-approved acceptance criteria, with blocking checks identified.
- A stable fixture location and a test account signed in through the app, without sharing credentials here.
Confirm the target release
Check that the deployment matches the intended release. If the version cannot be established, record the uncertainty before testing.
Review the acceptance pack
Agree on each expected result and the fixed fixtures. Missing criteria or empty fixtures block the affected checks.
Run the approved checks
Begin with a read-only walkthrough. Ask for a separate test plan before any form submission or data change.
Inspect the verdict
Review each result with its reproduction steps and evidence. Keep unresolved blocking checks open even when CI passes.
Prepare your first task
Fill in your project details. Values stay in this page and are cleared when you leave. Use file names or links; connect accounts in Grok Bot.
Fields left to replace: 5. You can also edit the bracketed values after copying.
What you should get
Use this checklist to review the first result and request anything missing.
- The inspected release and fixture set, with any verification gaps.
- A result for every criterion, supported by steps and evidence.
- Blocking failures and unavailable checks listed separately from warnings.
For the next run
After accepting the manual result, configure and test the optional PR-merge listener. Verify the deployed commit before reusing the same checklist.
If the first run gets stuck
If access, fixtures, or criteria are missing, resolve that dependency and rerun the affected checks. A clean CI run cannot replace acceptance evidence.
What the template includes
Official sourceSummarized from the public listing. The labels below describe capabilities; exact installed skill and connector names are not always published.
Integrations & inputs
- GitHub (for post-merge checks)
- Deployment host (for post-merge checks)
Skills & playbooks
No separate skills documented in the public listing.
Routines
An optional PR-merge listener checks the deployed commit before running acceptance checks. Configure the repository and deployment host first.
What to consider
Passing CI does not prove product acceptance. Missing criteria or unavailable fixtures must be reported as blocked, not treated as a pass.