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".
73
66%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/05-qa-testing/SKILL.mdQuality
Discovery
89%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 well-structured skill description that excels in trigger term coverage and completeness, with explicit 'Use quando' and 'Trigger em' clauses providing clear selection guidance. The bilingual trigger terms (Portuguese/English) are a strength for the target audience. The main weakness is that the capability descriptions could be more specific about concrete actions rather than listing broad categories of testing activities.
Suggestions
Add more specific concrete actions to improve specificity, e.g., 'gerar mocks de API', 'configurar test suites', 'criar snapshots', 'analisar relatorios de coverage' instead of broad categories like 'validar regressao'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (QA/testing) and some actions like 'escrever testes', 'validar regressao', 'revisar cobertura', 'configurar estrategia de QA', but these are somewhat general categories rather than deeply specific concrete actions (e.g., doesn't mention specific patterns like mocking APIs, snapshot testing, or generating test data). | 2 / 3 |
Completeness | Clearly answers both 'what' (writing tests, validating regression, reviewing coverage, configuring QA strategy, evidencing quality before release) and 'when' with an explicit 'Use quando...' clause and a dedicated 'Trigger em:' list of keywords. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms 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 when requesting testing help. | 3 / 3 |
Distinctiveness Conflict Risk | The description carves out a clear niche around QA and testing with specific tool names (Playwright, Vitest, Jest) and testing-specific terminology (E2E, coverage, mock, fixture) that would be unlikely to conflict with other skills like general coding or deployment skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill functions primarily as a governance/policy document and checklist rather than an actionable testing guide. Its biggest weakness is the complete absence of concrete code examples — no Vitest/Jest/Playwright snippets, no test patterns, no commands. The progressive disclosure is well-structured with clear references to external files, but the core content lacks the executable specificity that would make it useful for actually writing tests.
Suggestions
Add concrete, executable code examples for each test type (unit with Vitest/Jest, component with Testing Library, E2E with Playwright) — even minimal 5-line examples would dramatically improve actionability.
Add specific commands for running tests, checking coverage, and common CLI flags (e.g., `npx vitest run --coverage`, `npx playwright test`).
Replace or supplement the abstract 'Padroes de Teste' bullets with a concrete before/after example showing a well-structured test vs a poorly-structured one.
Add an explicit numbered workflow with validation checkpoints: write test → run → check coverage report → identify gaps → iterate, including what to do when tests fail.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains several sections that are organizational boilerplate rather than actionable content (Governanca Global, Quando Usar/Nao Usar, Entradas/Saidas Esperadas, Persona references). The Anti-Rationalization table adds value but some entries state obvious testing wisdom. The content could be significantly tightened. | 2 / 3 |
Actionability | The skill provides no executable code examples, no concrete test patterns, no specific commands for running tests, and no framework-specific syntax. It reads as a policy/checklist document rather than actionable guidance. Statements like 'escrever testes unitarios para hooks, stores e utils' describe what to do but never show how. | 1 / 3 |
Workflow Clarity | There is a checklist before approval and a handoff section with numbered steps, providing some sequence. However, the overall workflow for writing and validating tests lacks explicit sequencing with validation checkpoints — there's no 'run tests → check coverage → fix gaps → re-run' feedback loop. | 2 / 3 |
Progressive Disclosure | The skill appropriately references external files for detailed content (docs/skill-guides/qa-testing.md, personas/test-engineer.md, multiple policies) with clear one-level-deep signaling. The main file stays as an overview and delegates depth well. | 3 / 3 |
Total | 8 / 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.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
d87ad31
Table of Contents
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.