New: 98,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

Testing

by web-infra-dev in web-infra-dev/rstest

Testing workflow for the Rstest monorepo. An agent skill from web-infra-dev/rstest.

MITAuto-check passedTesting & QA

Install Testing

skills CLI
$ npx skills add web-infra-dev/rstest --skill testing -a claude-code

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

GitHub CLI
$ gh skill install web-infra-dev/rstest testing --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/web-infra-dev/rstest.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/testing .claude/skills/testing && 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
testing
GitHub stars
505
Token cost
~2.1k tokens
SKILL.md length
1,055 words
Files
1
Skills in repo
9
Repo updated
First seen
Licence
MIT

At a glance

Testing workflow for the Rstest monorepo. An agent skill from web-infra-dev/rstest.

  • Running unit tests
  • SKILL.md covers Running tests, Rebuild before E2E, Browser E2E and Watch-mode and long-running…, plus 8 more sections
  • Calls pnpm and npx
  • Watch-mode checks

What it does

Testing is an agent skill from web-infra-dev/rstest. Testing workflow for the Rstest monorepo. Use when running unit tests, e2e tests, browser e2e, example tests, watch-mode checks, writing test fixtures, debugging local or CI test failures, validating code changes, or reproducing bugs from external projects.

Its SKILL.md is about 2.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 End-to-end testing, Unit testing and Test data and fixtures. It works with pnpm. The repository describes itself as: The JavaScript testing framework powered by Rspack. The licence is MIT.

When your agent uses it

  • Running unit tests
  • Watch-mode checks
  • Writing test fixtures
  • Debugging local

Example prompts

  • “/testing”

Requirements

  • Node.js

What it can do on your machine

Read from SKILL.md and the folder at commit b1f3dd9. 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

    Shell commands in SKILL.md call:

    • pnpm
    • npx

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

  • Network

    No URLs in SKILL.md. Its commands use pnpm and npx, which can reach the network depending on how they are called.

    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

Testing loads about 2.1k tokens when it runs. Until then it costs about 66 tokens; SKILL.md has 1,055 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~66
When it runs · the whole SKILL.md, loaded when a task matches
~2.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 web-infra-dev/rstest at commit b1f3dd9, republished under its MIT licence (© web-infra-dev). 1,055 words, ~2,093 tokens.

Download SKILL.mdSave it as .claude/skills/testing/SKILL.md (or your agent's skills folder).
name
testing
description
Testing workflow for the Rstest monorepo. Use when running unit tests, e2e tests, browser e2e, example tests, watch-mode checks, writing test fixtures, debugging local or CI test failures, validating code changes, or reproducing bugs from external projects.
metadata.internal
true

Testing Workflow

This skill owns the mechanics: how to run and write tests, fixtures, and builds. Whether a change needs test work is routed by the development skill; what counts as evidence that a change works is defined by the verify skill.

Running tests

Package/unit tests from repository root (single file — preferred)
bash
pnpm rstest packages/core/tests/core/rsbuild.test.ts

Use this form for tests discovered by the root workspace config. Do not pass e2e/... paths to the root pnpm rstest command.

Package-level tests
bash
pnpm --filter @rstest/core test
pnpm --filter @rstest/core test -- tests/core/rsbuild.test.ts  # single file
E2E tests

Run e2e tests from inside the e2e/ directory. When passing the test path, strip the e2e/ prefix because the working directory is already e2e/.

bash
cd e2e && pnpm test <path-to-test>

To run tests in a fixture directory directly:

bash
cd e2e/<test>/fixtures/<fixture>/ && npx rstest

Rebuild before E2E

E2E tests and examples execute against built package output, not TypeScript sources. If you changed package source code, you must rebuild before running e2e:

bash
pnpm --filter @rstest/core build    # or whichever package was changed
cd e2e && pnpm test <path>

Forgetting this step means e2e runs against stale output — a common source of false passes/failures.

When the change may affect multiple packages, prefer a full workspace package build first:

bash
pnpm build
cd e2e && pnpm test <path>

Important:

  • Do not start e2e while any package build is still running.
  • Do not overlap pnpm build and pnpm e2e in separate sessions.
  • Wait for the build command to exit successfully before starting e2e.
  • If e2e fails immediately with a missing built file such as packages/core/dist/rstestSuppressWarnings.cjs, treat that as an incomplete build and rebuild before retrying.
  • When unsure whether the build is fully finished, verify the expected artifact exists before running e2e.

Browser E2E

  • Fixtures default to headless: true — no browser windows locally
  • Headed smoke tests are skipped locally by default (CI only)
  • To opt in locally: cd e2e && RSTEST_E2E_RUN_HEADED=true pnpm test browser-mode/basic.test.ts
Browser E2E debugging
  • Rebuild affected packages before retrying; stale dist is a common false signal.
  • Separate host/protocol/provider issues from UI issues before editing @rstest/browser-ui.
  • For flakes, check shared ports/cwd, persistent dist/.rstest-temp/, unawaited events, and order-dependent state before increasing timeouts.

Watch-mode and long-running tests

  • Use watch-mode tests only for file-change/rerun/invalidation behavior.
  • Assert stable events/final output, clean up watchers/processes, and inspect open handles before changing production code for hangs.

Test behavior, not source shape

Protect runtime invariants at the narrowest existing interface that exposes their observable result. Use integration or E2E coverage for cross-module orchestration. Do not add a production seam or abstraction solely to make an isolated unit test possible; use fakes or spies only when the code already has a natural interface for them.

  • Treat first-party implementation source text as private. Do not add tests that read it and use regexes, strings, snapshots, or counts to pin helper names, call sites, imports, or control-flow shape; comments, formatting, and behavior-preserving refactors make those assertions lie.
  • Reading source is appropriate when that source is itself the runtime input under test, such as a raw injected module or a transform fixture. Inspecting emitted bundles and generated files as product outputs is also appropriate.

Unit tests are OS-agnostic

CI runs unit tests (the ut job) on ubuntu only; OS-specific coverage lives in the e2e job's macOS/Windows rows. Enforced by the rstest/os-agnostic-tests rule in rslint.config.mts as part of pnpm lint; the rule itself is unit-tested by scripts/lint/os-agnostic-rule.test.ts (in the lint project).

  • Do not write unit tests whose behavior or expectations depend on the host OS (reading process.platform, os.platform(), etc.). CI would only ever exercise the Linux branch.
  • To cover platform-dependent code paths in a unit test, stub the platform for the test's duration so every branch runs deterministically on any host — see withPlatform in packages/core/tests/core/related.test.ts.
  • If the behavior cannot be stubbed (real filesystem case-sensitivity, native binaries, shell differences), cover it in e2e/ instead.
Show full SKILL.md (468 more words)Show less

Fixture strategy

Before adding a fixture, list existing ones in the same area (ls e2e/<area>/fixtures) and name the closest match. Prefer extending it:

  • Adding a project, config flag, or test file is additive reuse — "different config" alone does not justify a new fixture. After extending, re-run every test using that fixture to confirm none broke.
  • A new fixture is right when reuse would force an incompatible change to config other tests depend on, or contort the fixture's intent. Name the mechanism that blocks reuse; config expressible per file (environment docblocks, per-file options) does not make a difference incompatible.
  • The same rule applies inside a fixture: before adding a test file or helper module, look for one whose structure already matches — same shared module, same peer-file pairing — and extend it instead. Adding exports to an existing helper, or cases to an existing test file, is additive reuse.
  • Prefer one consolidated regression fixture that exercises the whole surface over many near-duplicate per-feature files. When several cases share a structural root cause, assert them together.

E2E rstest spawns with persistent dist/.rstest-temp/

A fixture that enables performance.buildCache (or dev.writeToDisk: true) forces rstest to persist the built bundle under <cwd>/dist/.rstest-temp/. If sibling test files share that cwd, those persistent writes race against any test asserting on the default path. Other disk writers like coverage or blob reporters land in <cwd>/coverage/ or <cwd>/.rstest-reports/ — different surfaces, not covered by this rule.

When your fixture enables persistent build output:

  • Set cwd to the fixture subdirectory, not the parent test directory.
  • In that fixture's config, drop any include referencing paths outside the fixture (e.g. './fixtures/<name>/index.test.ts'). Fixture-local globs like './*.test.ts' are fine.
  • Read dist/.rstest-temp/ assertions from that isolated fixture dir, not from a shared parent.

Snapshot policy

  • Only update snapshots when the behavioral change is intentional
  • For package/unit tests from repository root, use -u / --update: pnpm rstest -u packages/core/tests/core/rsbuild.test.ts
  • Do not use snapshot updates as a default way to silence test failures — investigate first
  • When updating, review the snapshot diff to confirm it matches expected changes

External repro projects

For external repos/fixtures: read README/scripts/deps, reproduce with the smallest command, classify the source, then port only the minimal regression case into this repo.

Performance and benchmark validation

For performance work, compare like-for-like runs: same command/fixture/env/cache policy, enough samples to separate noise, and state whether the result covers startup, execution, transform/cache, browser startup, or reporter overhead.

Validation before wrapping up

  • Do not stop at targeted tests only. Before finishing a code change, run the narrowest relevant tests first, then decide whether broader validation is needed.
  • pnpm run check-unused is part of the default validation pass for code changes in this repo. Run it before wrapping up, even when focused tests already pass.
  • Treat check-unused failures as real regressions unless you have confirmed the reported item is an intentional temporary state.

© web-infra-dev, 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 .agents/skills/testing of web-infra-dev/rstest.

Open the folder on GitHubat commit b1f3dd9

Compare with similar skills

Testing 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.

Testing compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Testing this skillweb-infra-dev/rstest505—~2.1kAutomated safety check: PassMIT
Ckeditor5 TestingTriliumNext/Trilium38k—~3.3kAutomated safety check: PassAGPL-3.0
ClickUp CLI Testingkrodak/clickup-cli121—~1.4kAutomated safety check: NotesMIT
Debug E2E Pipelinekubernetes-sigs/cloud-provider-azure294—~3.4kAutomated safety check: PassApache-2.0
Testing Patternssoftspark/ai-toolkit179—~1.6kAutomated safety check: PassApache-2.0
Verdaccio Change Testing Selectorverdaccio/verdaccio18k—~1.6kAutomated safety check: WarnMIT

Similar skills

  • Ckeditor5 Testing

    TriliumNext/Trilium

    Testing CKEditor 5 plugins in the Trilium monorepo. An agent skill from TriliumNext/Trilium.

    38k GitHub stars~3.3k tokensUpdated today
    Testing & QAAuto-check passed

  • ClickUp CLI Testing

    krodak/clickup-cli

    Explains how to run and extend the clickup-cli tests: unit tests with a mocked client, e2e tests against a real ClickUp workspace, and the fixture data they rely on.

    121 GitHub stars~1.4k tokensUpdated yesterday
    Testing & QAAuto-check: notes

  • Debug E2E Pipeline

    kubernetes-sigs/cloud-provider-azure

    Official

    Fetch and analyze Prow e2e pipeline failures for cloud-provider-azure.

    294 GitHub stars~3.4k tokensUpdated today
    Testing & QAAuto-check passed

  • Testing Patterns

    softspark/ai-toolkit

    Testing strategy: pyramid, AAA, mocks/fakes/stubs, flaky tests, coverage.

    179 GitHub stars~1.6k tokensUpdated yesterday
    Testing & QAAuto-check passed

  • Verdaccio Change Testing Selector

    verdaccio/verdaccio

    Figures out which rebuild and test suites actually cover a change in the verdaccio monorepo, instead of a scoped run that passes untested.

    18k GitHub stars~1.6k tokensUpdated yesterday
    Testing & QAAuto-check: warnings

  • Designing Tests

    CloudAI-X/claude-workflow-v2

    Designs and implements testing strategies for any codebase. An agent skill from CloudAI-X/claude-workflow-v2.

    1.4k GitHub starsUsed in 1 repo~1.5k tokens
    Testing & QAAuto-check passed

More from web-infra-dev/rstest

All 9 skills in this repo

  • Create Draft Release Notes

    web-infra-dev/rstest

    Create or update draft GitHub release notes, or output organized Markdown when draft creation is unavailable.

    505 GitHub stars~2.3k tokensUpdated today
    Auto-check passed

  • Create Release Blog

    web-infra-dev/rstest

    Generate a narrative version release blog post from commits within a tag range.

    505 GitHub stars~4.7k tokensUpdated today
    Auto-check passed

  • API Doc Sync

    web-infra-dev/rstest

    Verify hand-written API doc signatures match the exported types.

    505 GitHub stars~1.7k tokensUpdated today
    Auto-check passed

  • Typescript

    web-infra-dev/rstest

    TypeScript anti-slop guardrails. An agent skill from web-infra-dev/rstest.

    505 GitHub stars~1.3k tokensUpdated today
    Auto-check passed

  • Development

    web-infra-dev/rstest

    Feature and bug-fix development checklist for the Rstest monorepo.

    505 GitHub stars~2.8k tokensUpdated today
    Auto-check passed

  • PR Creator

    web-infra-dev/rstest

    Create a pull request using repository branch rules, title conventions, templates, and concise English descriptions.

    505 GitHub stars~560 tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Testing

What does Testing do?

Testing workflow for the Rstest monorepo. An agent skill from web-infra-dev/rstest. Testing is an agent skill from web-infra-dev/rstest. Testing workflow for the Rstest monorepo.

When should I use Testing?

Testing fits situations like: running unit tests; watch-mode checks; writing test fixtures; debugging local.

How do I install Testing in Claude Code?

Run `npx skills add web-infra-dev/rstest --skill testing -a claude-code`. Or copy the skill folder (.agents/skills/testing in web-infra-dev/rstest) into .claude/skills/testing in your project. Claude Code loads it when a task matches its description.

How do I install Testing in Codex?

Run `npx skills add web-infra-dev/rstest --skill testing -a codex`. Or copy the skill folder (.agents/skills/testing in web-infra-dev/rstest) into .agents/skills/testing in your project. Codex loads it when a task matches its description.

Can I use Testing 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 web-infra-dev/rstest --skill testing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/testing, .gemini/skills/testing, .github/skills/testing and .opencode/skills/testing in your project.

What does Testing need to run?

Going by SKILL.md and its folder, Testing needs the command-line tools its instructions call (pnpm and npx). Our summary lists: Node.js.

Does Testing access the network?

SKILL.md contains no URLs. Its commands use npx, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Testing 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 Testing use?

Testing 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 Testing use?

About 2.1k tokens (SKILL.md is roughly 8.4k 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 Testing?

Skills that share tags, products or a category with Testing: Ckeditor5 Testing (TriliumNext/Trilium, 38k stars), ClickUp CLI Testing (krodak/clickup-cli, 121 stars), Debug E2E Pipeline (kubernetes-sigs/cloud-provider-azure, 294 stars) and Testing Patterns (softspark/ai-toolkit, 179 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Testing?

web-infra-dev (a GitHub organization) maintains it in web-infra-dev/rstest, which has 505 GitHub stars. The repository holds 9 skills in this directory. The repository was last updated on October 8, 2026.

Source: web-infra-dev/rstest on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.