New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Test Discovery

by EmeaAppGbb in EmeaAppGbb/spec2cloud

Catalog existing tests — discover test frameworks, count tests by type, parse coverage reports, and map test-to-feature relationships.

MITAuto-check passedTesting & QA

Install Test Discovery

skills CLI
$ npx skills add EmeaAppGbb/spec2cloud --skill test-discovery -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install EmeaAppGbb/spec2cloud test-discovery --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/EmeaAppGbb/spec2cloud.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.github/skills/test-discovery .claude/skills/test-discovery && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
test-discovery
GitHub stars
100
Token cost
~3.1k tokens
SKILL.md length
1,162 words
Files
1
Skills in repo
39
Repo updated
First seen
Licence
MIT

At a glance

Catalog existing tests — discover test frameworks, count tests by type, parse coverage reports, and map test-to-feature relationships.

  • Works in 7 steps: Detect Test Frameworks → Locate Test Files → Classify Tests by Type → …
  • You need a factual inventory of the testing landscape before migration
  • SKILL.md covers Role, Inputs, Process and Output Format, plus 2 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Test Discovery is an agent skill from EmeaAppGbb/spec2cloud. Catalog existing tests — discover test frameworks, count tests by type, parse coverage reports, and map test-to-feature relationships. Pure discovery — no gap analysis, no recommendations for new tests, no assessment of test quality. Use when you need a factual inventory of the testing landscape before migration or modernization planning.

Its SKILL.md is about 3.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering Test coverage, Unit testing and Legacy modernization. It works with Playwright, Jest, Cypress and pytest. The licence is MIT.

When your agent uses it

  • You need a factual inventory of the testing landscape before migration
  • Modernization planning

Example prompts

  • “/test-discovery”

Requirements

  • Python 3

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. Detect Test Frameworks
  2. Locate Test Files
  3. Classify Tests by Type
  4. Count Test Cases
  5. Parse Coverage Reports
  6. Map Tests to Features/Components
  7. Document Test Infrastructure

What it can do on your machine

Read from SKILL.md and the folder at commit 8e76618. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Test Discovery loads about 3.1k tokens when it runs. Until then it costs about 89 tokens; SKILL.md has 1,162 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~89
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from EmeaAppGbb/spec2cloud at commit 8e76618, republished under its MIT licence (© EmeaAppGbb). 1,162 words, ~3,101 tokens.

Download SKILL.mdSave it as .claude/skills/test-discovery/SKILL.md (or your agent's skills folder).
name
test-discovery
description
Catalog existing tests — discover test frameworks, count tests by type, parse coverage reports, and map test-to-feature relationships. Pure discovery — no gap analysis, no recommendations for new tests, no assessment of test quality. Use when you need a factual inventory of the testing landscape before migration or modernization planning.

Test Discovery

Role

You are the Test Discovery agent — a factual cataloger that inventories every test in the project. You find test frameworks, count test files, count test cases, parse coverage reports, and attempt to map tests to the features they exercise.

You are an archivist, not a quality auditor. You count and catalog what is on the shelves. You NEVER identify "gaps" in test coverage, suggest new tests that "should" exist, assess test quality, or recommend testing strategies. If the project has 3 unit tests and zero integration tests, you report those numbers — nothing more.

Inputs

  • The project source tree
  • Output from codebase-scanner (specs/docs/technology/stack.md) if available — to know which test frameworks to look for
  • Existing coverage reports (if present in the repository)

Process

Step 1 — Detect Test Frameworks

Identify all test frameworks in use by checking:

FrameworkDetection Method
Jestjest.config.*, jest in package.json devDependencies, describe/it/test calls with jest globals
Vitestvitest.config.*, vitest in devDependencies
Mocha.mocharc.*, mocha in devDependencies
Jasminejasmine.json, jasmine in devDependencies
Playwrightplaywright.config.*, @playwright/test in devDependencies
Cypresscypress.config.*, cypress/ directory
Testing Library@testing-library/* in devDependencies
Supertestsupertest in devDependencies
pytestpytest.ini, pyproject.toml with [tool.pytest], conftest.py, files named test_*.py
unittestFiles with class X(unittest.TestCase)
xUnitxunit NuGet reference, files with [Fact]/[Theory] attributes
NUnitNUnit NuGet reference, [Test]/[TestFixture] attributes
MSTestMSTest NuGet reference, [TestMethod]/[TestClass] attributes
JUnitjunit dependency, @Test annotations
TestNGtestng dependency, @Test from TestNG
Go testing*_test.go files, func TestX(t *testing.T)
Rust tests#[test] attributes, #[cfg(test)] modules
RSpecspec/ directory, .rspec config, Gemfile with rspec
PHPUnitphpunit.xml, phpunit in composer.json

For each detected framework, record:

  • Framework name and version
  • Configuration file path
  • Test runner command (from scripts in package.json, Makefile, etc.)
Step 2 — Locate Test Files

Find all test files using framework-specific conventions:

  1. By naming convention: *.test.ts, *.spec.ts, test_*.py, *_test.go, *Test.java, *Tests.cs, *_spec.rb
  2. By directory: __tests__/, test/, tests/, spec/, cypress/, e2e/, integration/
  3. By configuration: Test file patterns from framework config files (e.g., testMatch in Jest config, testDir in Playwright config)

For each test file, record:

  • File path
  • Framework it belongs to
  • Approximate test count (count it(), test(), [Fact], def test_, func Test occurrences)
Step 3 — Classify Tests by Type

Categorize each test file into a type based on its location, framework, and content:

TypeHeuristics
UnitTests in __tests__/, test/unit/, *.test.ts colocated with source, mocking external dependencies, testing single functions/classes
IntegrationTests in test/integration/, tests that import multiple modules, tests that use real database connections or test containers
End-to-EndPlaywright, Cypress, Selenium tests; tests that start the full application; tests in e2e/, test/e2e/
API/ContractTests using supertest, httptest; tests that make HTTP calls to the API
ComponentReact/Vue/Angular component tests using Testing Library, Enzyme, Vue Test Utils
SnapshotTests using toMatchSnapshot(), toMatchInlineSnapshot()
PerformanceLoad tests, benchmark tests (k6, Artillery, Go benchmarks)
SmokeTests tagged as smoke, tests in test/smoke/

If a test file doesn't clearly fit one category, classify it as "unclassified" and note why.

Step 4 — Count Test Cases

For each test file, count individual test cases:

JavaScript/TypeScript (Jest/Vitest/Mocha):

  • Count it(, test(, it.each(, test.each( occurrences
  • Count describe( blocks for grouping information
  • Note it.skip(, test.skip(, xit(, xtest( as skipped tests
  • Note it.todo(, test.todo( as todo tests
  • Note it.only(, test.only( as focused tests

Python (pytest):

  • Count def test_ and async def test_ functions
  • Count parametrized test expansions from @pytest.mark.parametrize
  • Note @pytest.mark.skip as skipped tests
  • Count test classes with class Test

C# (xUnit/NUnit/MSTest):

  • Count [Fact], [Theory], [Test], [TestMethod] attributes
  • Count [InlineData] for theory data rows
  • Note [Skip] as skipped tests

Go:

  • Count func Test and func Benchmark functions
  • Note t.Skip() calls

Java (JUnit/TestNG):

  • Count @Test annotations
  • Count @ParameterizedTest with @MethodSource/@CsvSource
  • Note @Disabled as skipped tests

Produce totals: active tests, skipped tests, todo tests, per framework and per test type.

Step 5 — Parse Coverage Reports

Look for existing coverage reports and artifacts:

  1. Coverage configuration: Check for coverage settings in test framework configs (e.g., collectCoverage in Jest, --cov in pytest)
  2. Coverage report files: Look for:
    • coverage/, htmlcov/, .coverage
    • lcov.info, coverage.xml, cobertura.xml
    • coverage-summary.json, coverage-final.json
  3. CI coverage: Check CI config files for coverage upload steps (Codecov, Coveralls, SonarQube)

If coverage reports are found in the repository, extract:

  • Overall line coverage percentage
  • Overall branch coverage percentage
  • Per-file or per-directory coverage (if available)
  • Coverage thresholds configured (minimum coverage requirements)

If no reports are found, record "no coverage reports found in repository". Do NOT run tests to generate coverage — only parse existing reports.

Show full SKILL.md (437 more words)Show less
Step 6 — Map Tests to Features/Components

Attempt to map each test file to the source code it exercises:

  1. Import analysis: Check what the test file imports — the imported modules are likely what it tests.
  2. Path proximity: Colocated tests (e.g., UserService.test.ts next to UserService.ts) map directly.
  3. Directory mirroring: test/services/auth.test.ts likely tests src/services/auth.ts.
  4. Explicit references: Test descriptions or file names that reference features (e.g., test_login_flow.py → authentication feature).

Produce a mapping table. If a test's target is ambiguous, record it as "mapping uncertain" — do not guess.

Step 7 — Document Test Infrastructure

Record the test infrastructure and support files:

  • Test utilities: Shared helpers, custom matchers, test factories
  • Fixtures: Test data files, mock data, seed data for tests
  • Mocking: Mock files, __mocks__/ directories, mock service workers
  • Test configuration: Environment-specific test configs, test databases
  • CI integration: How tests are run in CI (which commands, which stages)
  • Test scripts: All test-related scripts in package.json, Makefile, etc.

Output Format

Produce specs/docs/testing/coverage.md:

markdown
# Test Inventory — [Project Name]

_Extracted on [date]. Catalogs all tests that exist in the project._

## Summary

| Metric | Value |
|--------|-------|
| Test frameworks | Jest, Playwright |
| Total test files | 87 |
| Total test cases | 423 |
| Skipped tests | 12 |
| Test types | Unit (312), Integration (67), E2E (44) |
| Coverage reports available | Yes — Jest coverage |
| Overall line coverage | 74.2% |
| Overall branch coverage | 61.8% |

## Test Frameworks

| Framework | Version | Config File | Run Command | Test Count |
|-----------|---------|-------------|-------------|------------|
| Jest | 29.7.0 | jest.config.ts | npm test | 379 |
| Playwright | 1.41.0 | playwright.config.ts | npm run test:e2e | 44 |

## Tests by Type

### Unit Tests (312 tests in 64 files)

| File | Test Count | Tests Target |
|------|-----------|-------------|
| src/services/__tests__/auth.test.ts | 18 | src/services/auth.ts |
| src/utils/__tests__/validators.test.ts | 24 | src/utils/validators.ts |
| ... | ... | ... |

### Integration Tests (67 tests in 15 files)

[Same table format]

### End-to-End Tests (44 tests in 8 files)

[Same table format]

## Skipped and Todo Tests

| File | Test Name | Status | Reason (if documented) |
|------|----------|--------|----------------------|
| auth.test.ts | should handle token refresh | skipped | "flaky — needs fix" |
| ... | ... | ... | ... |

## Coverage Data

| Metric | Value |
|--------|-------|
| Line coverage | 74.2% |
| Branch coverage | 61.8% |
| Function coverage | 79.1% |
| Statement coverage | 75.0% |
| Coverage threshold configured | 70% lines |

### Coverage by Directory

| Directory | Line Coverage | Files |
|-----------|-------------|-------|
| src/services/ | 82.3% | 12 |
| src/utils/ | 91.0% | 8 |
| src/routes/ | 45.2% | 6 |
| ... | ... | ... |

## Test-to-Component Mapping

| Component/Feature | Test Files | Test Count | Types |
|------------------|-----------|------------|-------|
| Authentication | auth.test.ts, login.spec.ts | 34 | Unit, E2E |
| User Management | users.test.ts, user-api.test.ts | 28 | Unit, Integration |
| ... | ... | ... | ... |

## Test Infrastructure

### Utilities and Helpers
[List shared test utilities, custom matchers, factories]

### Fixtures and Mock Data
[List fixture files, mock directories, test data]

### CI Integration
[How tests run in CI — commands, stages, parallelization]

Rules

  1. Catalog, don't analyze. Report what exists. Every statement must be verifiable from the files.
  2. No gap analysis. Do not identify "untested" code, "missing" test types, or "insufficient" coverage. The words "gap", "missing", "insufficient", "should", and "recommend" are banned.
  3. No quality assessment. Do not comment on test quality, naming conventions, assertion patterns, or test organization quality.
  4. No recommendations. Do not suggest adding tests, improving coverage, refactoring test code, or adopting different testing strategies.
  5. Accurate counts. Test counts must be accurate. If you cannot reliably count test cases in a file (e.g., dynamically generated tests), note it as "count approximate — dynamic test generation detected".
  6. Parse, don't run. Do not execute tests. Do not run test commands to generate coverage. Only parse existing files and reports.
  7. Skipped tests matter. Skipped and todo tests are part of the inventory. Count them separately but always include them.
  8. Uncertain mappings are okay. If you cannot determine what a test file tests, say "mapping uncertain" rather than guessing. Partial information is better than fabricated information.

Mandatory Completion Checklist

The orchestrator MUST verify ALL of the following before marking test-discovery as complete:

  • specs/docs/testing/coverage.md exists with: test framework(s), total test count, pass/fail/skip breakdown
  • Every test file in the project is cataloged with its framework and approximate test count
  • Test-to-source mapping is documented where determinable (which tests cover which source files)
  • Skipped/pending/todo tests are counted separately and listed
  • Coverage reports (if they exist as files) are referenced with their location and date

BLOCKING: If any item is unchecked, the skill has NOT completed successfully. The orchestrator must loop back and complete the missing items before advancing to the next extraction step.

© EmeaAppGbb, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .github/skills/test-discovery of EmeaAppGbb/spec2cloud.

Open the folder on GitHubat commit 8e76618

Compare with similar skills

Test Discovery next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Test Discovery compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Test Discovery this skillEmeaAppGbb/spec2cloud100—~3.1kAutomated safety check: PassMIT
Unit Testingpetrkindlmann/qa-skills163—~3.9kAutomated safety check: PassMIT
Test Detectdavila7/claude-code-templates32k—~989Automated safety check: PassMIT
Playwright Testingchongdashu/vibejam-starter-pack149—~2.1kAutomated safety check: PassNone
React Testingaffaan-m/ECC274k1 repos~3.3kAutomated safety check: PassMIT
TDD Guidealirezarezvani/claude-skills28k—~3.4kAutomated safety check: PassMIT

Similar skills

  • Unit Testing

    petrkindlmann/qa-skills

    Write effective unit tests with Jest, Vitest, or pytest. An agent skill from petrkindlmann/qa-skills.

    163 GitHub stars~3.9k tokensUpdated 3 mo ago
    Testing & QAAuto-check passed

  • Test Detect

    davila7/claude-code-templates

    Auto-detect testing framework and run relevant tests. An agent skill from davila7/claude-code-templates.

    32k GitHub stars~989 tokensUpdated today
    Testing & QAAuto-check passed

  • Playwright Testing

    chongdashu/vibejam-starter-pack

    Plan, implement, and debug frontend tests: unit/integration/E2E/visual/a11y.

    149 GitHub stars~2.1k tokensUpdated 5 mo ago
    Testing & QAAuto-check passed

  • React Testing

    affaan-m/ECC

    React component testing with React Testing Library, Vitest/Jest, MSW for network mocking, accessibility assertions with axe, and the decision boundary between component tests and Playwright/Cypress…

    274k GitHub starsUsed in 1 repo~3.3k tokens
    Testing & QAAuto-check passed

  • TDD Guide

    alirezarezvani/claude-skills

    Test-driven development skill for writing unit tests, generating test fixtures and mocks, analyzing coverage gaps, and guiding red-green-refactor workflows across Jest, Pytest, JUnit, Vitest, and…

    28k GitHub stars~3.4k tokensUpdated 1 mo ago
    Testing & QAAuto-check passed

  • TDD Guide

    LeoYeAI/openclaw-master-skills

    Test-driven development skill for writing unit tests, generating test fixtures and mocks, analyzing coverage gaps, and guiding red-green-refactor workflows across Jest, Pytest, JUnit, Vitest, and…

    2.2k GitHub stars~1.4k tokensUpdated 2 mo ago
    Testing & QAAuto-check passed

More from EmeaAppGbb/spec2cloud

All 39 skills in this repo

  • Azure Deployment

    EmeaAppGbb/spec2cloud

    Provision Azure infrastructure, deploy to Azure Container Apps, and verify via smoke tests.

    100 GitHub stars~1.8k tokensUpdated 5 mo ago
    Auto-check passed

  • Contract Generation

    EmeaAppGbb/spec2cloud

    Generate API contracts, shared TypeScript types, and infrastructure resource definitions from Gherkin scenarios and test files.

    100 GitHub stars~1.6k tokensUpdated 5 mo ago
    Auto-check passed

  • Ddd Modeling

    EmeaAppGbb/spec2cloud

    Create Domain-Driven Design proposals from product specs or brownfield extraction outputs.

    100 GitHub stars~2.4k tokensUpdated 5 mo ago
    Auto-check passed

  • Implementation

    EmeaAppGbb/spec2cloud

    Write application code to make failing tests pass using contract-driven, slice-based architecture.

    100 GitHub stars~2.8k tokensUpdated 5 mo ago
    Auto-check passed

  • Spec Refinement

    EmeaAppGbb/spec2cloud

    Review PRDs and FRDs through product and technical lenses. An agent skill from EmeaAppGbb/spec2cloud.

    100 GitHub stars~2.2k tokensUpdated 5 mo ago
    Auto-check passed

  • State Management

    EmeaAppGbb/spec2cloud

    Read, write, and maintain .spec2cloud/state.json across phases and increments.

    100 GitHub stars~1.5k tokensUpdated 5 mo ago
    Auto-check passed

Works with

Categories

Questions about Test Discovery

What does Test Discovery do?

Catalog existing tests — discover test frameworks, count tests by type, parse coverage reports, and map test-to-feature relationships. Test Discovery is an agent skill from EmeaAppGbb/spec2cloud. Catalog existing tests — discover test frameworks, count tests by type, parse coverage reports, and map test-to-feature relationships.

When should I use Test Discovery?

Test Discovery fits situations like: you need a factual inventory of the testing landscape before migration; modernization planning.

How do I install Test Discovery in Claude Code?

Run `npx skills add EmeaAppGbb/spec2cloud --skill test-discovery -a claude-code`. Or copy the skill folder (.github/skills/test-discovery in EmeaAppGbb/spec2cloud) into .claude/skills/test-discovery in your project. Claude Code loads it when a task matches its description.

How do I install Test Discovery in Codex?

Run `npx skills add EmeaAppGbb/spec2cloud --skill test-discovery -a codex`. Or copy the skill folder (.github/skills/test-discovery in EmeaAppGbb/spec2cloud) into .agents/skills/test-discovery in your project. Codex loads it when a task matches its description.

Can I use Test Discovery in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add EmeaAppGbb/spec2cloud --skill test-discovery -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/test-discovery, .gemini/skills/test-discovery, .github/skills/test-discovery and .opencode/skills/test-discovery in your project.

What does Test Discovery need to run?

SKILL.md names no scripts, command-line tools or credentials: Test Discovery is instructions for the agent only. Our summary lists: Python 3.

Does Test Discovery access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Test Discovery safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Test Discovery use?

Test Discovery is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Test Discovery use?

About 3.1k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Test Discovery?

Skills that share tags, products or a category with Test Discovery: Unit Testing (petrkindlmann/qa-skills, 163 stars), Test Detect (davila7/claude-code-templates, 32k stars), Playwright Testing (chongdashu/vibejam-starter-pack, 149 stars) and React Testing (affaan-m/ECC, 274k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Test Discovery?

EmeaAppGbb (a GitHub organization) maintains it in EmeaAppGbb/spec2cloud, which has 100 GitHub stars. The repository holds 39 skills in this directory. The repository was last updated on April 16, 2026.

Source: EmeaAppGbb/spec2cloud on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.