CtrlK
BlogDocsLog inGet started
Tessl Logo

qa-testing

Skill do QA Engineer para testes unitarios, integracao e E2E. Use quando precisar escrever testes, validar regressao, revisar cobertura, configurar estrategia de QA, ou evidenciar qualidade antes de release. Trigger em: "teste", "test", "QA", "Playwright", "Vitest", "Jest", "E2E", "coverage", "mock", "fixture", "regressao", "teste de integracao", "testing library".

76

1.16x
Quality

67%

Does it follow best practices?

Impact

85%

1.16x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No known issues

Fix and improve this skill with Tessl

tessl review fix ./skills/05-qa-testing/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

35%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This skill attempts to cover a broad QA domain but suffers from verbosity and lack of concrete executable examples. The mutation testing section, while informative, dominates the document and includes explanatory content Claude doesn't need (what mutation testing is, why it matters). The core QA responsibilities are described at a checklist level without actionable code templates for writing actual tests.

Suggestions

Move the mutation testing tools table and detailed workflow to a separate reference file (e.g., docs/mutation-testing.md) and keep only a 3-line summary with a link in the main SKILL.md

Add concrete, executable test examples for each test type (unit, integration, E2E) using the mentioned frameworks (Vitest/Jest/Playwright) — even one example per type would dramatically improve actionability

Remove explanatory content Claude already knows (what mutation testing is, why coverage matters, the Anti-Rationalization table) to cut token usage by ~40%

Add an explicit unified workflow with validation checkpoints: e.g., '1. Run existing tests → 2. If failing, fix first → 3. Write new tests for uncovered ACs → 4. Verify coverage threshold → 5. If below, add tests → 6. Generate evidence report'

DimensionReasoningScore

Conciseness

The skill is excessively verbose at ~200+ lines. It explains concepts Claude already knows (what mutation testing is, what coverage means, what PDF-like analogies are), includes lengthy tables of tools per language that could be a reference file, and has significant padding like the 'Anti-Rationalization' table and philosophical explanations about why tests matter. Much of this content doesn't earn its token cost.

1 / 3

Actionability

There is one concrete code example (SQLite WAL cleanup pattern) and some specific commands (e.g., `npx stryker run`), but most guidance is abstract checklists and general principles rather than executable code. The mutation testing workflow uses numbered prose steps rather than concrete commands, and the core QA sections (unit, integration, E2E) lack any executable test examples or templates.

2 / 3

Workflow Clarity

The mutation testing workflow has a reasonable sequence but lacks explicit validation checkpoints and error recovery loops. The main QA workflow is scattered across multiple sections (checklist, coverage, handoff) without a clear unified sequence. There's no explicit 'if tests fail, do X' feedback loop for the core testing workflow, and the checklist is more of a gate than a process.

2 / 3

Progressive Disclosure

References to external files exist (personas/test-engineer.md, docs/skill-guides/qa-testing.md, various policies), which is good. However, the main SKILL.md itself is monolithic with too much inline content that should be in reference files (the entire mutation testing tools table, the anti-rationalization table). The mutation testing section alone is nearly half the document and could be a separate reference. No bundle files were provided to verify reference accuracy.

2 / 3

Total

7

/

12

Passed

Description

100%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This is a strong skill description that covers all key dimensions well. It clearly defines the scope (QA testing across unit, integration, and E2E), provides explicit trigger guidance with both Portuguese and English terms, and names specific tools. The explicit trigger term list is a particularly effective pattern for skill selection disambiguation.

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions: writing tests, validating regression, reviewing coverage, configuring QA strategy, and evidencing quality before release. Also specifies test types (unit, integration, E2E).

3 / 3

Completeness

Clearly answers both 'what' (QA engineer skill for unit, integration, and E2E tests) and 'when' (explicit 'Use quando' clause with specific trigger scenarios and a dedicated trigger term list).

3 / 3

Trigger Term Quality

Excellent coverage of natural trigger terms users would say, including both Portuguese and English variants ('teste', 'test', 'QA', 'Playwright', 'Vitest', 'Jest', 'E2E', 'coverage', 'mock', 'fixture', 'regressao', 'teste de integracao', 'testing library'). These are terms users would naturally use.

3 / 3

Distinctiveness Conflict Risk

Clearly occupies a distinct niche around QA/testing with specific tool names (Playwright, Vitest, Jest) and testing-specific terminology that would not easily conflict with other skills like general coding or documentation skills.

3 / 3

Total

12

/

12

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
felvieira/claude-skills-fv
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.