Hire an AI visual QA evidence collector

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A table that sets each spec line next to what the screenshot shows, marked pass or fail.
• A result for each button, form, menu and toggle (PASS, FAIL or NOT TESTED).
• A numbered list of issues that can be repeated. Each has a screenshot name and a priority.
• A plain rating of the design (Basic, Good or Excellent) and a status of FAILED, NOT DETERMINED or READY.
• The fixes owed and what to re-test.

How it does the job well

• Treat "zero issues", "production ready" and quality scores without a defined scope and evidence as claims to check, not facts.
• A missing test is NOT TESTED. It is never a defect in the product.
• Do not change a live site, send a message or submit a real form without the user's go-ahead. Use test data in forms.
• Keep sample wording labelled as examples. Never state an invented figure as a result.
• Read the existing code, its conventions and its tests before changing anything. Match the project's patterns.
• Make the smallest change that fully solves the request. Keep unrelated refactors out.
• Reproduce a bug before fixing it, and add a test that fails without the fix.

Mistakes it avoids

• Claiming code works without running it or its tests.
• Inventing APIs, package versions or settings instead of checking the installed ones.
• Changing behaviour outside the request, such as reformatting whole files or renaming public interfaces.

What a good result looks like

An example, not your task: A developer or agency says a site, landing page or app is done, and you want proof before you pay or launch.

• Reality check. The tools it could use and the screenshots it reviewed, so you know the scope of the test.
• Spec vs screenshot. Each spec line quoted, what the screenshot shows, and a pass or fail mark.
• Interactive tests. A result for each accordion, form, menu and toggle, with the before and after file names.
• Repeatable issues. A numbered list of problems with a screenshot, steps to repeat and a priority.
• Quality and status. A design level and a status of FAILED, NOT DETERMINED or READY.
• Next steps. Fixes owed, what to re-test and a list of everything marked NOT TESTED.

How the work is checked

• The changed files build, and the relevant tests and linters pass. The commands and results are shown.
• Each change is explained in one line with its reason, and risky areas are named.
• Any check that could not run is reported as NOT_RUN with what it needs.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

Capabilities

• Check what it can do. It says whether it can open the site and take screenshots, or only look at the ones you gave it. Anything beyond that is NOT TESTED.
• Quote the spec. It lists each requirement and quotes the exact words, so no later check drifts from what was agreed.
• Read the evidence. It looks at the screenshots at three sizes and in dark mode. It describes what it sees, not what it expects to see.
• Test each action. For an accordion, form, menu or toggle it compares a before and after pair. For a form it also looks for the reply or the saved result.
• Write up what repeats. It lists only problems that break the spec and can be repeated. It gives each one a screenshot and a priority.
• Give the status. It sets FAILED for proven blockers, NOT DETERMINED when needed proof is missing, and READY only when the agreed checks pass.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id testing-evidence-collector only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/testing-evidence-collector/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• The spec, brief or feature list the site must match. Paste the text.
• The site. Give a link your AI can open, or screenshots you took on desktop, tablet and phone.
• The pages and actions to check, such as the menu, a form, an accordion or dark mode.
• Your own pass rules, such as "the form must show a thank-you message" (optional).
• An earlier bug list or QA report, so it can check what was fixed (optional).

Helpful context (optional)

• Screenshots at three widths and one in dark mode, with clear file names.
• The staging link, if your AI can open it.

Tools and access

• Claude Code or Codex: They can open a local or staging site, run Playwright and save the screenshots for you.
• Claude, ChatGPT or Gemini: In a plain chat they can read screenshots you upload, but they cannot click for you.

Functions and deliverables

• Visual QA evidence collector: Check a website against its spec and get a QA report with screenshots, pass or fail results and a clear FAILED, NOT DETERMINED or READY call.
  • A table that sets each spec line next to what the screenshot shows, marked pass or fail.
  • A result for each button, form, menu and toggle (PASS, FAIL or NOT TESTED).
  • A numbered list of issues that can be repeated. Each has a screenshot name and a priority.
  • A plain rating of the design (Basic, Good or Excellent) and a status of FAILED, NOT DETERMINED or READY.
  • The fixes owed and what to re-test.
  Source: Michael Sitarzewski and Agency Agents contributors.
• Website fix priority planner: Share page issues and evidence. Get a ranked list of tracking problems, quick fixes, questions to investigate and changes to test.
  • Each problem in one bucket with its next step
  • Test ideas that name the number they should move
  • A ranked order with a reason for each rank
• Gift message collector: Find every gift message on your open Shopify orders. Get a gift message list with recipients and gift flags, ready for packing slips.
  • One list of gift messages by order
  • Recipient names
  • Gift flags per order
  • A file ready for packing slips
  Source: 40rty AI.
• Website speed report explainer: Share PageSpeed results. Get plain-language metric checks, a separate checklist score, likely causes and fixes supported by the report.
  • A pass, fail or cannot judge call for each page
  • A field score out of 100 with the sum
  • The element behind the slowness
  • Three fixes and when to recheck
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.

Tasks you can use it for

• A developer or agency says a site, landing page or app is done, and you want proof before you pay or launch.
• You need a bug list with screenshots and steps your developer can repeat.
• You changed a page and want to know if the menu, form or accordion still works on a phone.
• You have a written spec and want to see which lines the build misses.

Limits to check before starting

• You want a final go or no-go call that also checks earlier QA claims: use the Release acceptance evidence reviewer. Bring this agent's report to it.
• You want to check the site for screen readers and keyboard use: use the Accessibility auditor.
• You want test code that runs on every release: use the Test Automation Engineer agent.
• You want to know how fast the site loads under traffic: use the Performance benchmark planner.
• You have an online store and want a launch checklist: use the Store launch readiness reviewer.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the pack. Add it to your AI as a skill, or paste SKILL.md and then references/source-agent.md into a new chat.
• Paste your spec. Then say how your AI will see the site. In Claude Code, Codex or a browser agent, give the link and let it take screenshots. In a plain chat, upload screenshots you took and name each one.
• Say: Check this site against the spec. Do not add requirements. Mark anything you cannot see as NOT TESTED.
• Read the table of spec lines first. Fix any line it misread before you trust the issue list.
• Send the issue list to your developer. After the fixes, run it again with new screenshots and your old report.
• Save the report. Your AI does not remember it in the next chat, so paste it back for the re-test.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/testing-evidence-collector for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.