Test strategy

Skill Chrike/coding-agent-skills/skills/test-strategy

Lightweight Claude Code skills for daily AI-assisted development workflows.

Install

npx -y skills add Chrike/coding-agent-skills --skill test-strategy

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.
1 stars1 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

Use when the primary problem is test design, test seams, regression coverage, mocks, assertions, fixtures, or timing and wait strategy, or when a requested change needs a non-obvious test level, seam, regression signal, or acceptance proof.

SKILL.md

3.1 KB, 599 tokens by cl100k_base, as published. Nobody here has run it

Test Strategy

Choose tests that prove behavior without turning every task into strict TDD.

First Decision

If the user asks for strict TDD, use TDD mode.
If the product behavior or root cause is still unclear and a failing or flaky test is only the symptom, use debug-systematically first.
If adding regression coverage for a bug, choose the narrowest seam that reproduces the real failure pattern.
If the needed test level, seam, regression signal, fixture/mocking boundary, or acceptance proof is non-obvious, use this skill to settle it.
If improving or adding tests, prefer observable behavior through public interfaces without forcing unnecessary implementation coupling.
If the task is ordinary implementation and tests are not central, do not force a test-first workflow.

Testing Defaults

Test what the system does, not how internal collaborators are called.
Choose the test level with the best evidence-to-cost ratio for the stated behavior, acceptance criteria, and concrete risk.
Prefer the most direct proof available. Escalate to broader or more realistic boundaries only when a narrower check cannot cover the behavior, contract, or risk being claimed.
Use unit, property, type, benchmark, stress, integration, or end-to-end checks according to the evidence each claim requires.
Keep each test focused on one behavior or one regression.
Use existing project test tools, fixtures, naming, and setup patterns.
Run the fastest high-signal test command that covers the changed behavior first; widen when affected surface, risk, acceptance criteria, or remaining evidence gaps require broader proof.
Prefer vertical slices: one behavior, one proving test or small group, then implementation. Do not write all tests first and all code later.

Read good-tests.md when the test shape itself is the main question.

TDD Mode

When the user asks for TDD, red-green-refactor, or test-first work:

Pick one behavior.
Write one failing test.
Run it and confirm it fails for the expected reason.
Write only enough implementation to pass.
Run the focused test green.
Refactor after green, keeping tests green.

Read tdd-mode.md for stricter details.

Mocks

Mock system boundaries such as external APIs, time, randomness, slow services, or filesystem access when using the real thing is costly or unreliable.

Do not mock internal collaborators by default. Do not assert that a mock component or mock function exists unless that is the behavior the user cares about.

Read mocking.md when mocks, test doubles, or mock-heavy failures are involved.

Flaky Tests

For timing, async, or intermittent failures, wait for the condition that proves progress instead of sleeping for a guessed duration. Read flaky-tests.md.