test-master
Skill1 starsChanged 56 days agoMITView on GitHub
Generates test files, creates mocking strategies, analyzes code coverage, designs test architectures, and produces test plans and defect reports across functional, performance, and security testing disciplines. Use when writing unit tests, integration tests, or E2E tests; creating test strategies or automation frameworks; analyzing coverage gaps; performance testing with k6 or Artillery; security testing with OWASP methods; debugging flaky tests; or working on QA, regression, test automation, quality gates, shift-left testing, or test maintenance.
We split this skill into the rules it gives an agent
12 rules. 3 are common, 8 are distinctive, and 1 is very specific to this project.
3
Common
Most of the 11 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 26
If tests fail: classify the failure (assertion error vs.
- Distinctive: line 27
If tests are flaky: isolate ordering dependencies, check async handling, add retry or stabilization logic
- Distinctive: line 29
Verify coverage targets are met before closing.
- Distinctive: line 74
Test happy paths AND error/edge cases (e.g., empty input, null, boundary values)
- Very specific: line 76
Use meaningful it('…') descriptions that read as plain-English specifications
- Distinctive: line 78
Run tests in CI/CD; document and remediate coverage gaps
- Distinctive: line 82
Use production data in tests — use fixtures or factories instead
- Distinctive: line 83
Create order-dependent tests — each test must be independently runnable
- Distinctive: line 85
Test implementation details (internal method calls) — test observable behaviour
- Common: line 89
When creating test plans, provide:
- Common: line 90
Test scope and approach
- Common: line 91
Test cases with expected outcomes
“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Test Master
Comprehensive testing specialist ensuring software quality through functional, performance, and security testing.
Core Workflow
- Define scope — Identify what to test and which testing types apply
- Create strategy — Plan the test approach across functional, performance, and security perspectives
- Write tests — Implement tests with proper assertions (see example below)
- Execute — Run tests and collect results
- If tests fail: classify the failure (assertion error vs. environment/flakiness), fix root cause, re-run
- If tests are flaky: isolate ordering dependencies, check async handling, add retry or stabilization logic
- Report — Document findings with severity ratings and actionable fix recommendations
- Verify coverage targets are met before closing; flag gaps explicitly
Quick-Start Example
A minimal Jest unit test illustrating the key patterns this skill enforces:
// ✅ Good: meaningful description, specific assertion, isolated dependency
describe('calculateDiscount', () => {
it('applies 10% discount for premium users', () => {
const result = calculateDiscount({ price: 100, userTier: 'premium' });
expect(result).toBe(90); // specific outcome, not just truthy
});
it('throws on negative price', () => {
expect(() => calculateDiscount({ price: -1, userTier: 'standard' }))
.toThrow('Price must be non-negative');
});
});Apply the same structure for pytest (def test_…, assert result == expected) and other frameworks.
Reference Guide
Load detailed guidance based on context:
<!-- TDD Iron Laws and Testing Anti-Patterns adapted from obra/superpowers by Jesse Vincent (@obra), MIT License -->| Topic | Reference | Load When |
| Unit Testing | references/unit-testing.md | Jest, Vitest, pytest patterns |
| Integration | references/integration-testing.md | API testing, Supertest |
| E2E | references/e2e-testing.md | E2E strategy, user flows |
| Performance | references/performance-testing.md | k6, load testing |
| Security | references/security-testing.md | Security test checklist |
| Reports | references/test-reports.md | Report templates, findings |
| QA Methodology | references/qa-methodology.md | Manual testing, quality advocacy, shift-left, continuous testing |
| Automation | references/automation-frameworks.md | Framework patterns, scaling, maintenance, team enablement |
| TDD Iron Laws | references/tdd-iron-laws.md | TDD methodology, test-first development, red-green-refactor |
| Testing Anti-Patterns | references/testing-anti-patterns.md | Test review, mock issues, test quality problems |
Constraints
MUST DO
- Test happy paths AND error/edge cases (e.g., empty input, null, boundary values)
- Mock external dependencies — never call real APIs or databases in unit tests
- Use meaningful
it('…')descriptions that read as plain-English specifications - Assert specific outcomes (
expect(result).toBe(90)), not just truthiness - Run tests in CI/CD; document and remediate coverage gaps
MUST NOT
- Skip error-path testing (e.g., don't test only the success branch of a try/catch)
- Use production data in tests — use fixtures or factories instead
- Create order-dependent tests — each test must be independently runnable
- Ignore flaky tests — quarantine and fix them; don't just re-run until green
- Test implementation details (internal method calls) — test observable behaviour
Output Templates
When creating test plans, provide:
- Test scope and approach
- Test cases with expected outcomes
- Coverage analysis
- Findings with severity (Critical/High/Medium/Low)
- Specific fix recommendations
Other versions13 projects use a version of this.
Word for word · 2
- mimoccc/my-claude-skills★ 1100% same
- LucasGS520/Claude-Skills★ 0100% same
Edited · 9
- Jeffallan/claude-skills★ 12k96% same
- PIXARTSeu/Synapse★ 9100% same
- thesaifalitai/claude-setup★ 850% same
- megastep/codex-skills★ 444% same
- zacklecon/claude-skills★ 350% same
- herbert051281/mission-control★ 044% same
- hu465/claude-skills-★ 096% same
- skalskidaniel/agent-skills★ 077% same
- usmanmubarak1/ClaudeSkilledAgents★ 044% same
Wrote their own version · 2
- pavel-molyanov/molyanov-ai-dev★ 299same name
- stepanenkoviktor0110-boop/ai-dev-methodology★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository24 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- ai-video-generationSkill
- claude-md-improverSkill
- code-reviewerSkill
- frontend-designSkill
- heron-buildSkill
- heron-claude-dataSkill
- heron-tray-windowsSkill
- minimalist-uiSkill
- product-launch-videoSkill
- rust-engineerSkill
- secure-code-guardianSkill
- seo-auditSkill
- svelte5-initSkill
- svelte5-reviewSkill
- tauri-app-autostartSkill
- tauri-app-notificationSkill
- tauri-app-positionerSkill
- tauri-app-system-traySkill
- tauri-buildSkill
- tauri-securitySkill
- tauriSkill
- tauri-windowSkill
- typescript-proSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

