Verifies implementation quality through rigorous, evidence-based adversarial testing.

Install

mkdir -p .claude/skills/qa-trevoke && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/11860" && unzip -o skill.zip -d .claude/skills/qa-trevoke && rm skill.zip

Installs to .claude/skills/qa-trevoke

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Use when implementation is complete and you want to verify quality through adversarial testing that writes code and provides evidence
133 chars✓ has a “when” trigger
Advanced

Key capabilities

  • Find context from requirements and design documents.
  • Run existing test suites.
  • Check acceptance criteria coverage.
  • Write missing tests for identified gaps.
  • Write adversarial tests to find edge cases.

How it works

The skill verifies quality through adversarial testing by finding context, running existing tests, checking acceptance criteria coverage, and writing new tests to uncover bugs and edge cases.

Inputs & outputs

You give it
Implemented code and requirements documentation
You get back
QA report with test results, coverage, and identified failures

When to use qa

  • Verify feature implementation
  • Write missing tests for coverage
  • Identify edge-case regressions

About this skill

/qa — Adversarial Testing

Overview

QA writes tests and runs them. It provides evidence, not opinions. Every claim is backed by a test or command output.

Core principle: Your job is to break things. Write code. Run it. Show evidence.

When to Use

  • Implementation is complete (or a chunk of work needs verification)
  • You want to check acceptance criteria coverage
  • You want adversarial edge-case testing

The Process

1. Find Context

Look for requirements and design docs in docs/plans/. Read both to understand what was built and what was promised.

2. Run the Existing Test Suite

~/bin/eldev etest -r dot

Actually run it. Report exact output: how many tests, how many pass, how many fail. If any fail, report them immediately — existing regressions are priority one.

3. Check Acceptance Criteria Coverage

Read acceptance criteria from the requirements doc. For each criterion:

  1. Search for a test that exercises it (Grep for keywords)
  2. Read the test — does it actually test what the criterion says?
  3. Report: covered or gap
| Criterion | Test | Status |
|-----------|------|--------|
| User can activate focus mode | focus-test.el:42 | COVERED |
| Calendar items always visible | (none found) | GAP |

4. Write Missing Tests

For each gap, write the test. Follow existing patterns in the codebase.

Run it. Report whether it passes or fails.

5. Write Adversarial Tests

Actively try to break things. Write actual test code, don't just describe it.

Target areas:

  • Nil/empty inputs: What happens with nil arguments, empty strings, empty lists?
  • Boundary values: 0, 1, max, min
  • Missing state: Required properties absent, buffers killed mid-operation
  • Invalid inputs: Wrong types, malformed data
  • Repeated calls: What if the function is called twice in a row?

6. Run Everything and Report

~/bin/eldev etest -r dot

Report with evidence — actual test output, not fabricated numbers:

## QA Report

**Test Suite**: [paste actual eldev output]

### Acceptance Criteria Coverage
| Criterion | Test | Status |
|-----------|------|--------|
| ... | ... | ... |

### Tests Written
- [test name]: tests [what] — [PASS/FAIL]

### Failures Found
- [test name]: [what failed]
  - **Reproduction**: [exact command or test invocation]
  - **Expected**: [what should happen]
  - **Actual**: [what happened]

Common Mistakes

MistakeFix
Describing tests without writing codeWRITE the test. Create the file. Run it.
Fabricating test resultsRUN the tests. Paste actual output.
Reporting opinions instead of evidenceEvery claim needs a test or command output.
Suggesting implementation fixesReport problems with evidence. Fixing is the implementer's job.
Categorizing tests instead of running themLess taxonomy, more eldev etest.
Skipping the existing test suiteALWAYS run the full suite first. Regressions are priority one.
Not checking requirements docCross-reference acceptance criteria. That's what "done" means.

When not to use it

  • When implementation is not complete.
  • When only opinions are required instead of evidence.
  • When suggesting implementation fixes instead of reporting problems.

Limitations

  • Requires implementation to be complete.
  • Every claim must be backed by a test or command output.
  • Does not suggest implementation fixes.

How it compares

This skill focuses on adversarial testing and evidence-backed reporting, actively writing new tests to break the code and providing concrete output, rather than just describing potential issues or relying solely on existing test suites.

Compared to similar skills

qa side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
qa (this skill)05moReviewAdvanced
python-testing-patterns772moReviewIntermediate
fix-bug117moReviewIntermediate
test-fixing19moReviewIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

Search skills

Search the agent skills registry