Test It

Make behavior provable with the repo’s real test stack — in the right quality regime, against the quality trace.

What it is

Make the intended behavior provable with automated and/or explicit manual evidence. Discover the repo’s real harness; do not invent a new framework unless asked. Prefer DocSlime TESTING.md, issue BDD completion scenarios, and existing tests as the oracle. A green suite that measures the wrong thing is still a vibe.

Why it works

Automated tests are the safety net for CI and refactoring — but what to prove comes from lightweight BDD (Dan North; GivenWhenThen) and DocSlime’s scenario→evidence map, shaped by system type (Quality regimes):

Deterministic compute — invariants, golden/property tests, pipeline correctness.
Interactive products — behavior + critical journeys, a11y, performance budgets.
Generative / high-input — datasets, layered graders; prefer Langfuse (or repo OTel eval stack) for experiment scores.

Prefer the repo’s existing runner over inventing a framework. Cucumber/.feature only if already house style.

When to use it

After naming the regime and locating (or proposing) the BDD/requirement definition — when verification is missing before readiness/merge, or when DocSlime TESTING.md shows gaps.

Do

Name regime A / B / C (or hybrid); pull scenarios from DocSlime / issue / existing tests
Map each scenario → evidence (test, eval, manual, doc-only, or explicit out-of-scope)
Invoke the skill; one write owner; hand off to check-readiness / document-it / DocSlime fill as needed

Don’t

Treat unit-test green as proof of chat/agent quality
Invent parallel scenarios when REQUIREMENTS/TESTING already define them
Require a new BDD framework for vocabulary alone
Skip orientation when you’re lost
Spawn overlapping agents to “go faster”

13-quality-trace, 04-evidence-over-vibes, 11-quality-regimes, 12-bugs-and-debt

Agent skill

test-it