agentsclimarketplace

Test quality maintenance

Skill Nick2bad4u/codex-skills/skills/test-quality-maintenance

Personal multi-skill repository for reusable Codex workflows.

Install
npx -y skills add Nick2bad4u/codex-skills --skill test-quality-maintenance

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generates, repairs, and improves tests and coverage. Use when writing unit tests, fixing failures, improving meaningful coverage, testing error handling, adding Playwright E2E tests, or creating focused benchmarks.

SKILL.md

2.3 KB, 403 tokens by cl100k_base, as published. Nobody here has run it

Test Quality Maintenance

Use this skill for test work where the goal is behavior confidence, not line-count padding.

Shared Workflow

  1. Inspect the implementation, public API, existing tests, fixtures, mocks, helpers, and project conventions.
  2. Reproduce failing output when available.
  3. Fix root causes rather than updating assertions to match broken behavior.
  4. Add tests for real behavior: normal cases, edge cases, invalid input, async paths, failure paths, cleanup/rollback, integration boundaries, fixers, public API contracts, and user-facing messages.
  5. Keep mocks faithful to real behavior and avoid brittle sleeps or snapshots unless the project intentionally uses them.
  6. Run targeted tests first, then broader test, coverage, lint, typecheck, or build commands when warranted.

Coverage Work

Use coverage reports to prioritize high-risk and under-tested files. Aim for configured thresholds, but do not add empty assertions or tests that only execute lines. Document any intentional untested paths with a clear reason.

Playwright E2E

Inspect app structure, existing Playwright config, fixtures, selectors, auth helpers, and CI constraints. Cover the user journey end to end with stable selectors and deterministic setup. Include meaningful failure, loading, permission, and responsive states when they are part of the workflow.

Error Handling

Cover validation errors, external service failures, filesystem or network failures, auth failures, cleanup/rollback, retry behavior, logging, UI error boundaries, and user-facing messages. Assert that sensitive data is not logged or exposed.

Performance

Only add benchmarks when the project already supports them or the user explicitly wants a benchmark harness. Reuse existing thresholds and CI patterns. Measure latency, allocation, scaling, render time, I/O count, or query count as appropriate. Avoid noisy CI blockers unless the project already has stable budgets.

Output

Finish with scenarios covered, bugs fixed, files changed, commands run, coverage result when relevant, and any remaining test gaps.

Gives 0 of the 12 instructions most e2e browser skills give in 403 tokens

Counted across 407 of the 410 authors here whose files we hold, read 2026-08-06

  • use page object model patternin 35 of 407, across 25 files
  • Snapshot to get element refsin 24 of 407, across 14 files
  • keep tests independentin 23 of 407, across 18 files
  • Interact using refs from the latest snapshotin 23 of 407, across 11 files
  • clean up test data after each testin 21 of 407, across 15 files
  • test user behavior not implementationin 20 of 407, across 14 files
  • quarantine flaky tests explicitlyin 19 of 407, across 10 files
  • wait for specific network conditionsin 18 of 407, across 8 files
  • re-snapshot after navigation or dom changesin 17 of 407, across 10 files
  • Detect running dev servers before writing test codein 17 of 407, across 7 files
  • use web-first assertionsin 17 of 407, across 14 files
  • capture screenshots or videos on test failurein 17 of 407, across 14 files

Said here and by no other author read

  • inspect implementation tests fixtures and project conventions
  • reproduce failing output when available
  • fix root causes rather than updating assertions
  • add tests for real behavior and edge cases
  • keep mocks faithful to real behavior
  • run targeted tests then broader tests

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.