Claude Code skills QA workflows are useful when your team repeats the same review checklist every time an AI assistant edits tests. Instead of pasting a long prompt into every session, you can package the checklist as a Claude Code skill and ask Claude to run it when a Playwright, Selenium, API, or CI test change needs evidence review.

This tutorial shows a practical QA use case: create a reusable SKILL.md checklist that asks Claude Code to inspect a test automation change for failing proof, changed files, assertion quality, screenshots, logs, validation commands, and human QA sign-off. The goal is not to make Claude the final authority. The goal is to make your review process repeatable before you run deterministic tests and accept the change.

What the official docs support

Anthropic’s Claude Code skills documentation describes skills as instruction packages stored in SKILL.md files. Claude can load them when they are relevant or when you invoke them directly. The docs support project and personal skill locations, supporting files, frontmatter such as description and allowed tools, and direct invocation controls.

The same documentation recommends skills when a repeated procedure has outgrown general memory instructions. Claude Code common workflows also cover test work, debugging, planning before editing, pull request style review, and piping Claude into scripts. Hooks and settings are separate guardrails: hooks can run deterministic shell commands at lifecycle points, while settings manage permissions, hooks, skills, MCP, and plugin configuration.

When QA teams should use a skill

  • Use a skill when the checklist is repeatable, longer than a few lines, and specific to QA evidence or test review.
  • Use CLAUDE.md for short project standards such as locator style, assertion expectations, and approved test commands.
  • Use hooks when you need deterministic enforcement, such as running a formatter, lint command, or focused test command after file edits.
  • Use human review for final risk decisions, release impact, missing coverage, and whether the evidence is good enough for the bug or pull request.

Step 1: Create the skill folder

Inside a repository that uses Claude Code, create a project-level skill folder:

.claude/skills/test-evidence-review/SKILL.md

A project-level skill keeps the review checklist close to the test code. That matters for QA teams because evidence expectations differ across products. A payments application may require API logs and audit IDs, while a UI-heavy workflow may require screenshots, console errors, and browser network evidence.

Step 2: Add a QA-focused SKILL.md

Start with a small skill that Claude can understand quickly:

---
name: test-evidence-review
description: Review a test automation change for QA evidence quality before acceptance.
---

# Test Evidence Review Skill

Use this skill when reviewing AI-assisted test automation changes.

Check these items:
1. State the original failing behavior or test gap.
2. List the files changed by the proposed fix.
3. Explain whether the assertions check business behavior, not only status or visibility.
4. Identify required evidence: screenshot, trace, console log, API response, CI log, or local command output.
5. Name the exact validation command a human should run.
6. Call out missing negative cases, weak locators, test data risk, and environment assumptions.
7. End with one of these statuses: ready for human validation, needs more evidence, or reject.

Keep the first version boring and explicit. A skill that produces a consistent review table is more useful than a clever prompt that changes format every session.

Step 3: Invoke the skill on a test change

After Claude drafts or modifies a test, invoke the skill directly in Claude Code. A practical prompt can be:

Use the test-evidence-review skill on this branch. Review only the test automation changes. Do not edit files yet. Tell me what evidence is missing before I accept the change.

For a Playwright change, ask Claude to inspect the test diff, the related page object or fixture, and any captured trace or screenshot. For an API test change, ask it to inspect request data, response assertions, contract assumptions, and negative cases.

Step 4: Review the output like a QA engineer

The skill should produce a review summary you can challenge. Do not accept a vague answer such as “tests look good.” Push for evidence:

  • What failed before the change?
  • Which assertion proves the user-facing behavior?
  • What screenshot, trace, API response, or CI log supports the result?
  • Which command should be run locally or in CI?
  • What risk remains after the test passes?

Step 5: Keep deterministic validation outside the skill

A Claude Code skill can help standardize the review, but it should not be treated as test evidence by itself. Run the actual test command, capture the output, and attach the relevant screenshot, trace, or log. If your team needs automatic enforcement, use hooks or CI checks for the command execution instead of relying only on model judgment.

Screenshot checklist

  • The .claude/skills/test-evidence-review/SKILL.md file open in the editor.
  • Claude Code invocation showing the skill name and the request to review evidence before editing.
  • The test diff that Claude reviewed.
  • The generated evidence checklist with missing items highlighted.
  • The local or CI validation command output after the QA engineer runs it.

Common mistakes to avoid

  • Making the skill too broad: one skill should review one repeatable workflow. Create separate skills for API assertion review, UI evidence review, or release-risk review if needed.
  • Skipping source evidence: a summary without screenshots, traces, logs, or command output is not enough for a real defect or pull request.
  • Letting the skill approve its own work: ask Claude for a review, then run the validation yourself and decide whether the change is acceptable.
  • Confusing skills with enforcement: use hooks, CI, and permissions for deterministic control. Use skills for reusable instructions and checklists.

A reusable QA review prompt

Use the test-evidence-review skill. Review this test automation change as an SDET. Focus on assertion depth, data setup, missing negative cases, flaky locator risk, screenshots, logs, and the exact command I should run. Return a table with Evidence, Status, Risk, and Next action. Do not modify files.

Final takeaway

Claude Code skills are a good fit for repeated QA review procedures. Put the durable checklist in SKILL.md, invoke it whenever an AI-assisted test change needs evidence review, and keep final acceptance tied to deterministic test output plus human QA judgment.

Sources