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

Test Guard

by amElnagdy in amElnagdy/guard-skills

Reviews newly written or edited tests against nine rules that cut test bloat, such as mock-heavy checks and near-duplicate cases, before they are committed.

MITAuto-check passedTesting & QA

Install Test Guard

skills CLI
$ npx skills add amElnagdy/guard-skills --skill test-guard -a claude-code

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

GitHub CLI
$ gh skill install amElnagdy/guard-skills test-guard --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/amElnagdy/guard-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/test-guard .claude/skills/test-guard && 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-guard
GitHub stars
1.3k
Used in
2 other repos
Token cost
~2.1k tokens
SKILL.md length
1,045 words
Files
6 (incl. references)
Skills in repo
5
Repo updated
First seen
Licence
MIT

At a glance

Reviews newly written or edited tests against nine rules that cut test bloat, such as mock-heavy checks and near-duplicate cases, before they are committed.

  • Works in 4 steps: Check the project's own agent… → Identify the test stack, then read the… → If the project calls LLM APIs, uses… → …
  • Reviewing tests an agent just generated before presenting or committing them
  • SKILL.md covers When this skill activates, Adapt to the project first, What to do and The Nine Rules, plus 4 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Test Guard acts as a quality gate after an agent writes, edits or refactors tests. It targets three habits it says agents fall into: unit tests packed with mocks that assert implementation details, near-identical tests that differ by a single value, and tests that merely re-check the framework instead of the project's own logic.

Before judging anything, it reads the project's own agent instructions and testing docs, which win over its rules, then identifies the test stack and loads the matching reference for pytest, PHPUnit and Pest, or Jest and Vitest. A fourth reference covers projects that call LLM APIs. Findings are reported briefly with the rule number, location, reason and a suggested fix, and the skill can also guide test writing when invoked up front. It is not meant for reviewing production code, CI setup or running tests.

When your agent uses it

  • Reviewing tests an agent just generated before presenting or committing them
  • Checking a pull request diff that adds or changes test files
  • Trimming a bloated suite full of mock-heavy or duplicate tests
  • Writing new tests with the rules applied from the start

Example prompts

  • “Review the tests you just added for the invoice service and flag anything redundant.”
  • “Check this PR diff for test bloat before I merge it.”
  • “Add tests for the retry helper in utils/http.py, keeping to the test-guard rules.”

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Check the project's own agent instructions (CLAUDE.md, AGENTS.md) and testing docs. Project-specific testing rules win over this skill…
  2. Identify the test stack, then read the matching reference for concrete patterns
  3. If the project calls LLM APIs, uses agent frameworks, or wires up observability/telemetry, also read references/llm-app-testing.md — it…
  4. Map the project's system boundaries: network calls, databases, filesystem, clock and randomness, third-party SDKs, LLM APIs. Existing…

What it can do on your machine

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

    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 Guard loads about 2.1k tokens when it runs, and up to ~4.6k if it reads all its reference files. Until then it costs about 207 tokens; SKILL.md has 1,045 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~207
When it runs · the whole SKILL.md, loaded when a task matches
~2.1k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~4.6k

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 amElnagdy/guard-skills at commit ffa2603, republished under its MIT licence (© amElnagdy). 1,045 words, ~2,131 tokens.

Download SKILL.mdSave it as .claude/skills/test-guard/SKILL.md (or your agent's skills folder). This skill also uses 5 other files; get the full folder from GitHub.
name
test-guard
description
Review generated or changed test code against universal testing rules before it ships. Best used reactively after an agent writes, edits, generates, or refactors tests, before presenting, committing, or merging them. Use for pytest (test_*.py, *_test.py), PHPUnit/Pest (*Test.php), Jest/Vitest (*.test.ts, *.spec.js), Go (*_test.go), files under tests/, __tests__/, or spec/, and review requests like 'write tests for X', 'add tests', 'test this', 'review these tests', or PR diffs containing tests. Can also guide test writing when explicitly invoked before the work. This skill is the quality gate that prevents AI-generated test bloat. DO NOT USE for production or implementation code review (use clean-code-guard), CI or test-runner configuration, running or debugging tests, or general architecture discussion.

Test Guard

You are reviewing generated or changed test code before it ships. Enforce the rules below after the first test-writing pass and before the tests are presented, committed, or merged. Be a sharp reviewer, not a pedantic one: flag what wastes maintenance effort or hides real bugs, ignore cosmetic preferences.

These rules exist because coding agents over-generate tests. The common failure modes: mock-heavy unit tests that assert implementation details, near-duplicate test bodies that differ by one value, and tests that re-verify the framework instead of the project's logic. Each looks productive in a diff and costs maintenance forever.

When this skill activates

  • A coding agent has just written new test functions or test files, in any language
  • You are editing existing tests
  • You are reviewing a diff that contains test changes
  • The user asks you to write, add, or review tests

Adapt to the project first

These rules are universal, but their application is not. Before reviewing:

  1. Check the project's own agent instructions (CLAUDE.md, AGENTS.md) and testing docs. Project-specific testing rules win over this skill when they conflict.
  2. Identify the test stack, then read the matching reference for concrete patterns:
  3. If the project calls LLM APIs, uses agent frameworks, or wires up observability/telemetry, also read references/llm-app-testing.md — it adds three rules specific to LLM applications.
  4. Map the project's system boundaries: network calls, databases, filesystem, clock and randomness, third-party SDKs, LLM APIs. Existing fixtures and test helpers usually reveal where the project already draws these lines.

What to do

  1. Read the test code: the diff, the new file, or the section being modified.
  2. Check each test against the rules below.
  3. Report violations concisely: rule number, location, why it violates, suggested fix.
  4. If the user explicitly invokes this skill before test writing, apply the rules as you write — don't write violations and then flag them.

When writing new tests, ask for each test: "What specific bug does this catch that no other test in this suite catches?" If you can't answer clearly, don't write it.

The Nine Rules

Rule 1: Test behavior, not implementation

Test what code does from the caller's perspective. Assert return values and observable side effects. Never assert that an internal helper was called with specific arguments — that test breaks on every refactor while catching nothing.

Violation pattern: asserting a mock of an internal function was called, where that function is not a system boundary. Fix: assert the return value or the state change the caller observes.

Rule 2: Every mock must be justified

Mock only at system boundaries: network and HTTP calls, LLM APIs, databases, filesystem I/O on external files, clock and randomness, third-party SDKs. Never mock internal classes or helper functions to isolate a "unit" — the seams you create hide the integration bugs worth catching.

When you mock a boundary, assert what the caller does with the response, not that the mock received specific arguments.

Rule 3: One scenario per test, data-driven for variants

If two or more tests share identical setup and differ only in input/output values, merge them into one data-driven test (@pytest.mark.parametrize, PHPUnit #[DataProvider], Jest test.each).

When separate tests ARE correct: different setup, different assertions, different mock configurations, or genuinely different scenarios that happen to exercise the same function.

Rule 4: Every test must justify its existence

Ask: "What bug does this catch that no other test catches?" Delete tests that only catch typos, verify default values of data classes, or test trivial pass-through logic.

Common unjustified tests: constructors setting attributes, a function rejecting input the type system already forbids, string formatting of log messages, a constant equaling its literal value.

Show full SKILL.md (427 more words)Show less
Rule 5: Name tests for the scenario

Pattern: test_<scenario>_<expected_outcome>. The name should read like a requirement, not echo the function signature.

BadGood
test_parse_response_missing_fieldtest_malformed_response_falls_back_to_default
test_get_language_no_classtest_element_without_class_returns_empty_language
test_add_tags_single_stringtest_single_tag_normalizes_to_list
Rule 6: Production regression tests are sacred

Tests that reproduce a real production bug are always justified. Reference the incident (date, issue ID, or short description) in the name or a comment, and never delete them. They are exempt from Rule 4 — their justification is the incident.

Rule 7: No tests for framework guarantees

Don't test that the validation library validates, the ORM commits, the router returns 404, or the test framework's fixtures work. Test your logic that sits on top of the framework.

Violation pattern: a test that would still pass if you deleted all the project's custom code and kept only framework defaults.

Rule 8: State and value objects are real, never mocked

Never mock a data model, DTO, entity, or state object. Construct a real instance. Mocking state hides field-name typos and validation errors — exactly the bugs worth catching. If constructing the real object is painful, that is design feedback, not a reason to mock; add a small builder or factory helper.

Rule 9: Infrastructure under test gets real infrastructure

When database queries, schema behavior, or persistence logic is the subject of the test, run against a real test database with real migrations applied via fixtures. Mocking the session there tests nothing. Mocking the database is fine when persistence is only a side effect of the behavior under test.

Reporting format

When flagging violations, use this format:

**Rule N violation** in `tests/path/file.ext::<test_name>`
- What: <one sentence describing the violation>
- Fix: <one sentence describing what to do instead>

Group violations by file. If a file has no violations, don't mention it.

Severity guide

Not all violations are equal. Use judgment:

  • Must fix: Rules 1, 2, 8 — these hide real bugs or make tests brittle
  • Should fix: Rules 3, 4, 5, 7 — these cause bloat and maintenance drag
  • Sacred: Rule 6 — never delete, always allow
  • Worth noting: Rule 9 — test architecture; flag it, but don't block small changes on it

References

  • references/pytest.md — Python/pytest patterns: parametrize, fixtures, mock boundaries, real Pydantic instances
  • references/phpunit.md — PHP/PHPUnit/Pest patterns, including WordPress and WooCommerce test boundaries
  • references/jest.md — Jest/Vitest patterns: test.each, module mocks, msw, snapshot discipline
  • references/llm-app-testing.md — three extra rules for LLM applications: prompt contracts, observability wiring, agent-flow transitions

What this skill does NOT do

  • It does not run tests. Use the project's test runner for that.
  • It does not enforce code style — that's the linter's job.
  • It does not decide what to test — only how to test it.
  • It does not flag pre-existing violations in files you're not touching, unless asked to audit.

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

Files

SKILL.md and 5 other files (references) in skills/test-guard of amElnagdy/guard-skills.

  • SKILL.md
  • agents/openai.yaml
  • references/jest.md
  • references/llm-app-testing.md
  • references/phpunit.md
  • references/pytest.md

Open the folder on GitHubat commit ffa2603

Used in 2 other repositories

We found 6 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 2 other GitHub owners. This page covers the copy in amElnagdy/guard-skills, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Test Guard 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 Guard compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Test Guard this skillamElnagdy/guard-skills1.3k2 repos~2.1kAutomated safety check: PassMIT
MoAI TDD Workflowmodu-ai/moai-adk1.2k—~3.1kAutomated safety check: PassApache-2.0
Test-Driven Development Enforcerzereight/gitlab-mcp2k1 repos~904Automated safety check: PassMIT
Designing TestsCloudAI-X/claude-workflow-v21.4k1 repos~1.5kAutomated safety check: PassMIT
Validatejuliepy/AI-Engineer-from-scrach436—~500Automated safety check: PassNone
Code Testingdotnet/skills5.6k1 repos~5.4kAutomated safety check: PassMIT

Similar skills

  • MoAI TDD Workflow

    modu-ai/moai-adk

    Drives test-first development through the RED, GREEN, REFACTOR cycle, with a config switch that selects between TDD and a DDD workflow for existing code.

    1.2k GitHub stars~3.1k tokensUpdated yesterday
    Testing & QAAuto-check passed

  • Test-Driven Development Enforcer

    zereight/gitlab-mcp

    Enforces strict red-green-refactor, with a failing test first, the minimum code to pass it, then cleanup, and a quick reference for common test runners.

    2k GitHub starsUsed in 1 repo~904 tokens
    Testing & QAAuto-check passed

  • 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

  • Validate

    juliepy/AI-Engineer-from-scrach

    Run the full quality gate (ruff + mypy + pytest + tsc + vitest) and report PASS/FAIL for each command.

    436 GitHub stars~500 tokensUpdated 1 mo ago
    Testing & QAAuto-check passed

  • Code Testing

    dotnet/skills

    Official

    ALWAYS USE for test work that requires changes: write, add, generate, repair, or strengthen tests for existing code in xUnit, MSTest, NUnit, pytest, Vitest/Jest, Go, or another framework.

    5.6k GitHub starsUsed in 1 repo~5.4k tokens
    Testing & QAAuto-check passed

  • Test Patterns

    rohitg00/skillkit

    Applies proven testing patterns — Arrange-Act-Assert (AAA), Given-When-Then, Test Data Builders, Object Mother, parameterized tests, fixtures, spies, and test doubles — to help write maintainable…

    1.5k GitHub stars~1.8k tokensUpdated 4 mo ago
    Testing & QAAuto-check passed

More from amElnagdy/guard-skills

  • Clean Code Guard

    amElnagdy/guard-skills

    Reviews generated or changed production code against Clean Code, SOLID, DRY, KISS, YAGNI and LLM-specific failure modes before it ships, in any language.

    1.3k GitHub starsUsed in 2 repos~4.3k tokens
    Auto-check passed

  • Docs Guard

    amElnagdy/guard-skills

    Checks generated or edited documentation against the source code, flagging invented symbols, outdated samples and unverifiable claims before publishing.

    1.3k GitHub stars~2.1k tokensUpdated 3 mo ago
    Auto-check passed

  • WooCommerce Code Guard

    amElnagdy/guard-skills

    Reviews generated or changed WooCommerce code for HPOS safety, CRUD use, checkout validation and money handling before it ships.

    1.3k GitHub stars~2.2k tokensUpdated 3 mo ago
    Auto-check passed

  • WordPress Code Guard

    amElnagdy/guard-skills

    Reviews WordPress plugin, theme and block code after an agent writes or edits it, catching missing escaping, nonces, capability checks and unprepared queries.

    1.3k GitHub stars~2.4k tokensUpdated 3 mo ago
    Auto-check passed

Works with

Categories

Questions about Test Guard

What does Test Guard do?

Reviews newly written or edited tests against nine rules that cut test bloat, such as mock-heavy checks and near-duplicate cases, before they are committed. Test Guard acts as a quality gate after an agent writes, edits or refactors tests. It targets three habits it says agents fall into: unit tests packed with mocks that assert implementation details, near-identical tests that differ by a single value, and tests that merely re-check the framework instead of the project's own logic.

When should I use Test Guard?

Test Guard fits situations like: reviewing tests an agent just generated before presenting or committing them; checking a pull request diff that adds or changes test files; trimming a bloated suite full of mock-heavy or duplicate tests; writing new tests with the rules applied from the start.

How do I install Test Guard in Claude Code?

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

How do I install Test Guard in Codex?

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

Can I use Test Guard 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 amElnagdy/guard-skills --skill test-guard -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-guard, .gemini/skills/test-guard, .github/skills/test-guard and .opencode/skills/test-guard in your project.

What does Test Guard need to run?

SKILL.md names no scripts, command-line tools or credentials: Test Guard is instructions for the agent only.

Does Test Guard 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 Guard 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 Guard use?

Test Guard 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 Guard use?

About 2.1k tokens (SKILL.md is roughly 8.5k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2.5k tokens, read only when the agent opens those files.

What are the alternatives to Test Guard?

Skills that share tags, products or a category with Test Guard: MoAI TDD Workflow (modu-ai/moai-adk, 1.2k stars), Test-Driven Development Enforcer (zereight/gitlab-mcp, 2k stars), Designing Tests (CloudAI-X/claude-workflow-v2, 1.4k stars) and Validate (juliepy/AI-Engineer-from-scrach, 436 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Test Guard?

amElnagdy (a GitHub user) maintains it in amElnagdy/guard-skills, which has 1,260 GitHub stars. The repository holds 5 skills in this directory. The repository was last updated on July 4, 2026.

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