test-first-change

Discover and run tests before code edits with coverage enforcement.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/benreceveur/claude-workflow-engine --skill test-first-change
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-first-change
Source: https://github.com/benreceveur/claude-workflow-engine/tree/main/skills/test-first-change
Command: npx skills add https://github.com/benreceveur/claude-workflow-engine --skill test-first-change

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

Force-testing before coding to reduce regressions by discovering tests, running them, then editing code.

Core Features & Use Cases

  • Test discovery
  • Run tests baseline
  • Edit code and re-run
  • Log changes to memory

Quick Start

Before editing any code, run the tests for the target module.

Frequently Asked Questions about test-first-change

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent regressions by running tests before code changes?

Test-first workflow prevents regressions by discovering and executing tests baseline before editing code, then re-running them after changes. This catches breaks immediately and enforces quality gates like 80% coverage thresholds on modified code.

Can I enforce test coverage requirements in my CI and pull request workflows?

Yes. Enforce at least 80% coverage on code changes across CI, pull requests, and local development by discovering tests, running suites with coverage reporting, and quarantining flaky tests to maintain reliable baselines.

What's the best way to integrate test discovery and execution into my development workflow?

Apply test discovery and baseline runs before any code edits, log all changes to memory for traceability, then re-execute tests after modifications. This pattern applies consistently across local, CI, and pull request stages to catch regressions early.

How do I handle flaky tests when running baseline test suites?

Quarantine flaky tests separately during baseline runs so they don't mask real regressions. This isolates unreliable test behavior from genuine failures caused by code changes.

Why should I run tests before editing code instead of after?

Running tests first establishes a clean baseline and ensures test infrastructure works, so failures after code changes are definitively caused by your edits. This dramatically reduces debugging time and catches regressions immediately.