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 Quality

by techygarg in techygarg/lattice

Apply test quality principles when generating or reviewing test code.

MITAuto-check passedTesting & QA

Install Test Quality

skills CLI
$ npx skills add techygarg/lattice --skill test-quality -a claude-code

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

GitHub CLI
$ gh skill install techygarg/lattice test-quality --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/techygarg/lattice.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/test-quality .claude/skills/test-quality && 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-quality
GitHub stars
198
Token cost
~2.1k tokens
SKILL.md length
1,107 words
Files
2 (incl. references)
Skills in repo
33
Repo updated
First seen
Licence
MIT

At a glance

Apply test quality principles when generating or reviewing test code.

  • Works in 6 steps: Read .lattice/config.yaml in the repo… → If found, check paths.test_quality for a… → If a custom document exists at that… → …
  • Reviewing test code
  • SKILL.md covers Config Resolution, Self-Validation Checklist, Active Anti-Pattern Scan and Class-Level Review, plus 2 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Test Quality is an agent skill from techygarg/lattice. Apply test quality principles when generating or reviewing test code. Enforces Arrange-Act-Assert structure, one behavior per test, assertion quality, test isolation, meaningful naming, and test data management. Use when writing tests, reviewing test code, or when the user mentions 'write tests', 'test this', 'test quality', 'test review', 'improve tests', or 'test structure'. Loaded automatically by the code-generating molecules (code-forge, refactor-safely, bug-fix). This skill governs the craft of writing…

Its SKILL.md is about 2.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/defaults.md`).

It sits in Testing & QA, covering Test generation, Test data and fixtures and Debugging. The repository describes itself as: Install engineering discipline into any AI coding assistant. Composable skills for design, implementation, review, and team standards. Better process, not just better prompts. The licence is MIT.

When your agent uses it

  • Reviewing test code
  • The user mentions write tests

Example prompts

  • “write tests”
  • “test this”
  • “test quality”
  • “/test-quality”

Workflow steps

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

  1. Read .lattice/config.yaml in the repo root.
  2. If found, check paths.test_quality for a custom document path.
  3. If a custom document exists at that path, read it and check its YAML frontmatter for mode
  4. If a custom path is configured but no document exists at it → tell the user which configured path is missing, then fall back to…
  5. If there is no config file or no paths.test_quality key, read ./references/defaults.md.
  6. Language adaptation: if paths.language_idioms is set in the config and the document exists, read its "Testing Patterns" section and adapt…

What it can do on your machine

Read from SKILL.md and the folder at commit 4d6c35f. 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 Quality loads about 2.1k tokens when it runs, and up to ~6.4k if it reads all its reference files. Until then it costs about 171 tokens; SKILL.md has 1,107 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~171
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
~6.4k

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 techygarg/lattice at commit 4d6c35f, republished under its MIT licence (© techygarg). 1,107 words, ~2,113 tokens.

Download SKILL.mdSave it as .claude/skills/test-quality/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
test-quality
description
Apply test quality principles when generating or reviewing test code. Enforces Arrange-Act-Assert structure, one behavior per test, assertion quality, test isolation, meaningful naming, and test data management. Use when writing tests, reviewing test code, or when the user mentions 'write tests', 'test this', 'test quality', 'test review', 'improve tests', or 'test structure'. Loaded automatically by the code-generating molecules (code-forge, refactor-safely, bug-fix). This skill governs the craft of writing individual test cases -- not what to test (that is driven by the code being implemented) but how to write tests that are reliable, readable, and maintainable.

Test Quality

Config Resolution

Projects can customize this skill's standards. Resolution order:

  1. Read .lattice/config.yaml in the repo root.
  2. If found, check paths.test_quality for a custom document path.
  3. If a custom document exists at that path, read it and check its YAML frontmatter for mode:
    • mode: override: the custom document has full control. Use it instead of the embedded defaults. It must be complete -- treat it as the sole reference.
    • mode: overlay (or no mode field): read the embedded ./references/defaults.md first, then apply the custom document on top. A custom section replaces the matching default section (matched by exact heading); new sections append after the defaults.
  4. If a custom path is configured but no document exists at it → tell the user which configured path is missing, then fall back to ./references/defaults.md.
  5. If there is no config file or no paths.test_quality key, read ./references/defaults.md.
  6. Language adaptation: if paths.language_idioms is set in the config and the document exists, read its "Testing Patterns" section and adapt §5 (Test Naming Conventions), §4 (Test Isolation Techniques), and §6 (Test Data Builders and Factories) to the language's test-framework idioms. Language idioms take precedence over the pseudocode defaults.

Self-Validation Checklist

STOP after generating each test. Verify ALL checks before continuing. Fix every failed check. If a check is ambiguous (see Ambiguity Signals), flag it -- present options and reasoning.

  1. AAA STRUCTURE: Are arrange, act, and assert visually separate (blank lines)? Is there any logic (if/loop/try) inside arrange or assert?
  2. SINGLE BEHAVIOR: Does the test verify one behavior per the loaded doc (default: one behavior per test; a name that needs "and" → split it)?
  3. ASSERTION QUALITY: Does it assert observable behavior rather than implementation? Is it specific enough to catch a regression?
  4. ISOLATION: Does the test depend on another test's output or effects? Is all mutable state created per-test?
  5. TEST NAME: Does the name follow the team convention per the loaded doc (default: describe the behavior, not the method)? Is the failure message clear?
  6. TEST DATA: Does complex arrange use builders/factories? Are magic values promoted to named constants? (Inline literals are fine for trivial tests.)
  7. MOCK BOUNDARIES: Are mocks placed per the loaded doc (default: only at architectural boundaries -- I/O, external services -- not between internal collaborators)?
  8. TEST CODE AS FIRST-CLASS: Is the test structured like production code? Shared constants at top, helpers extracted, no dead code, clear file organization?

Project-specific checks: if the loaded doc (from Config Resolution) contains a validation checklist section, apply those checks after the base checklist.

All checks pass → state "Passes test-quality. [next step]."

Active Anti-Pattern Scan

After the checklist, scan for each of these. Any box you can check → fix before presenting.

  • Test-per-Method: one test per method regardless of behaviors → one test per scenario, named for the behavior.
  • Assertion Roulette: multiple unrelated assertions; unclear which one broke → split to one behavior per test.
  • Shared Mutable State: tests pass alone but fail together → isolate state; per-test setup; no static mutable data.
  • Testing Implementation Details: test breaks on a refactor that preserves behavior; mocks assert call counts → assert observable behavior, not method calls.
  • Mystery Guest: test depends on an external file/db/env var not visible in the test → inline the data or use builders; make all preconditions visible.
  • Slow Tests by Default: the unit suite takes minutes; tests hit db/network/filesystem → mock or fake I/O; use in-memory implementations.
  • Conditional Test Logic: a test contains if/loop/try -- a test that needs its own tests → remove the logic; use parameterized tests; let assertions fail naturally.
  • Copy-Paste Tests: near-identical tests with small changes → extract shared setup into builders; parameterize.

Class-Level Review

Fires when: (1) all tests for a class are complete -- new or existing; (2) any test in an existing class is added or edited.

STOP before presenting. The per-test checks verify individual quality; this review verifies that the test suite covers the class's contract.

Show full SKILL.md (461 more words)Show less
Full review (new class or significant additions)
  1. Behavior inventory — list every public method/behavior of the class under test. If the class is not available, ask the user to enumerate them.
  2. Coverage matrix — map each test to the behavior it covers. Any behavior with zero tests → blocking. Do not present until the user closes the gap or explicitly accepts it.
  3. Error path check — scan the class under test for explicit throws, conditional error branches, and edge guards. For each one found: does a test exercise this path? If not → flag it by name. Zero-coverage error paths are blocking unless the user explicitly accepts them.
  4. Behavioral duplication — compare the "then" clauses across all tests. The same observable outcome regardless of structural differences → flag as likely duplication; name both tests.
  5. Balance signal — any behavior that has tests but none covering a failure or edge case → surface as a question, not a hard failure: "deleteUser has 1 test (happy path only) -- does it have error cases?"
Edit-scoped review (adding or changing one test in an existing class)

Run steps 3–5 only, scoped to the changed test:

  • Does this test duplicate the observable outcome of any existing test?
  • Does it cover a behavior or error path not previously covered?

Ambiguity Signals

Multiple valid outcomes exist. Present the options rather than silently choosing. If framework:collaborative-judgment is loaded, use its presentation format. See ./references/defaults.md for resolution guidance.

  • Unit vs Integration: a service coordinates several components -- test it in isolation (mocked) or with real collaborators? Depends on the coupling and what the test must verify.
  • Mock Depth: mock direct dependencies or let calls pass through? Over-mocking tests the implementation; under-mocking creates slow, flaky tests.
  • Test Granularity: one test with multiple assertions vs multiple tests with one assertion each? When the assertions verify facets of the same behavior, grouping is fine.

Test Code as First-Class Code

Treat test files like production classes:

  • Shared constants and boundary values at the top of the file (named, not magic)
  • Shared builders/factories extracted to helpers -- not copy-pasted per test
  • Setup methods or fixtures for repeated arrange patterns
  • Logical grouping: related behaviors together (by feature, by scenario type)
  • Dead tests removed, not commented out
  • Refactoring applies: extract a method when arrange is long, rename when intent is unclear, move shared setup when duplicated

Refactoring opportunities to surface proactively:

  • Multiple tests repeat the same arrange → extract a builder or shared fixture
  • The same assertion pattern across tests → extract a custom assertion helper
  • A test file grows beyond ~300 lines → split by behavior group
  • Constants scattered inline → collect at the top with descriptive names
  • Deeply nested test structures → flatten with clear naming

See ./references/defaults.md for AAA structure examples, assertion patterns, isolation techniques, naming conventions, test data builder patterns, and pyramid distribution guidance.

© techygarg, 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 1 other file (references) in skills/test-quality of techygarg/lattice.

  • SKILL.md
  • references/defaults.md

Open the folder on GitHubat commit 4d6c35f

Compare with similar skills

Test Quality 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 Quality compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Test Quality this skilltechygarg/lattice198—~2.1kAutomated safety check: PassMIT
Skill Doli Test InteractiveDolibarr/dolibarr7.7k1 repos~5.5kAutomated safety check: PassGPL-3.0
Ue Test AuthoringJasonMa0012/MooaToon749—~2.1kAutomated safety check: NotesCustom licence
Generating Test Reportsforyourhealth111-pixel/Vibe-Skills3.6k—~352Automated safety check: PassMIT
Test BlindspotsNeeeophytee/finding-unknowns-skills343—~676Automated safety check: PassMIT
Counterexample To Test GeneratorArabelaTso/Skills-4-SE253—~1.6kAutomated safety check: PassApache-2.0

Similar skills

  • Skill Doli Test Interactive

    Dolibarr/dolibarr

    Create interactive PHP test case scripts for Dolibarr ERP/CRM that allow users to setup test data, view results via direct links, and tear down (clean up) the data.

    7.7k GitHub starsUsed in 1 repo~5.5k tokens
    Testing & QAAuto-check passed

  • Ue Test Authoring

    JasonMa0012/MooaToon

    A skill your agent uses when writing or modifying UE automated tests (Automation, CQTest, Functional, Gauntlet, LowLevel) with Rider MCP available.

    749 GitHub stars~2.1k tokensUpdated 19 days ago
    Testing & QAAuto-check: notes

  • Generating Test Reports

    foryourhealth111-pixel/Vibe-Skills

    Generate structured test reports with pass/fail rollups, coverage summaries, and test artifacts.

    3.6k GitHub stars~352 tokensUpdated 1 mo ago
    Testing & QAAuto-check passed

  • Test Blindspots

    Neeeophytee/finding-unknowns-skills

    Find consequential behavior that a passing test suite does not establish, using focused exploratory checks.

    343 GitHub stars~676 tokensUpdated 9 days ago
    Testing & QAAuto-check passed

  • Counterexample To Test Generator

    ArabelaTso/Skills-4-SE

    Automatically generates executable test cases from model checking counterexample traces.

    253 GitHub stars~1.6k tokensUpdated 1 mo ago
    Testing & QAAuto-check passed

  • OpenROAD Bug Fixer

    The-OpenROAD-Project/OpenROAD

    Fixes an OpenROAD bug from a GitHub issue or error code: finds the root cause, implements the fix, adds a regression test and prepares a signed-off commit.

    3.2k GitHub stars~784 tokensUpdated yesterday
    DevelopmentAuto-check passed

More from techygarg/lattice

All 33 skills in this repo

  • Architecture Compass

    techygarg/lattice

    Architectural thinking partner for an existing repository — scans the codebase, conducts a structured interview, agrees on current architectural state and recommended direction, and produces a…

    198 GitHub stars~4.4k tokensUpdated yesterday
    Auto-check passed

  • Lattice Init

    techygarg/lattice

    Guided setup and upgrade-check experience for Lattice projects -- scans the repository, detects existing configuration and outdated conventions, suggests refiners and available upgrades in priority…

    198 GitHub stars~3.3k tokensUpdated yesterday
    Auto-check passed

  • Skill Align

    techygarg/lattice

    Audit and fix all Lattice documentation, README, docs/, PROJECT.md, GitHub issue templates, and CLAUDE.md to ensure they are fully aligned with the current skill inventory.

    198 GitHub stars~2k tokensUpdated yesterday
    Auto-check passed

  • Skill Validate

    techygarg/lattice

    Validate any Lattice SKILL.md against all tier conventions — atoms, molecules, and refiners.

    198 GitHub stars~1.5k tokensUpdated yesterday
    Auto-check passed

  • Architecture Refiner

    techygarg/lattice

    Facilitate a structured conversation to define architecture principles for a repository.

    198 GitHub stars~3.7k tokensUpdated yesterday
    Auto-check passed

  • Clean Code Refiner

    techygarg/lattice

    Facilitate a structured conversation to define clean code principles for a repository.

    198 GitHub stars~3k tokensUpdated yesterday
    Auto-check passed

Categories

Questions about Test Quality

What does Test Quality do?

Apply test quality principles when generating or reviewing test code. Test Quality is an agent skill from techygarg/lattice. Apply test quality principles when generating or reviewing test code.

When should I use Test Quality?

Test Quality fits situations like: reviewing test code; the user mentions write tests.

How do I install Test Quality in Claude Code?

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

How do I install Test Quality in Codex?

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

Can I use Test Quality 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 techygarg/lattice --skill test-quality -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-quality, .gemini/skills/test-quality, .github/skills/test-quality and .opencode/skills/test-quality in your project.

What does Test Quality need to run?

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

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

Test Quality 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 Quality 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 4.3k tokens, read only when the agent opens those files.

What are the alternatives to Test Quality?

Skills that share tags, products or a category with Test Quality: Skill Doli Test Interactive (Dolibarr/dolibarr, 7.7k stars), Ue Test Authoring (JasonMa0012/MooaToon, 749 stars), Generating Test Reports (foryourhealth111-pixel/Vibe-Skills, 3.6k stars) and Test Blindspots (Neeeophytee/finding-unknowns-skills, 343 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Test Quality?

techygarg (a GitHub user) maintains it in techygarg/lattice, which has 198 GitHub stars. The repository holds 33 skills in this directory. The repository was last updated on October 6, 2026.

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