eng-consolidate-test-suites

Guides test placement by identifying invariants, owning layers, and canonical suites before changing coverage.

2.7k|171|Updated Mar 28, 2026
One-click install
npx skills add https://github.com/compozy/compozy --skill eng-consolidate-test-suites
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: eng-consolidate-test-suites
Source: https://github.com/compozy/compozy/tree/main/.agents/skills/eng/eng-consolidate-test-suites
Command: npx skills add https://github.com/compozy/compozy --skill eng-consolidate-test-suites

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Engineering teams often accumulate redundant, low-signal, or misplaced tests that inflate coverage metrics without proving real behavior. This Skill enforces a disciplined decision process so every test change is tied to a named invariant, a single owning layer, and an existing canonical suite.

Core Features & Use Cases

  • Invariant-First Test Decisions: Requires naming the rule that must stay true before adding, moving, or reviewing any test, and stops work when no durable invariant exists.
  • Owning Layer Selection: Chooses exactly one primary layer (unit, integration, end-to-end, static analysis, codegen, visual QA, documentation build, or manual QA) using the bundled test placement rules reference.
  • Canonical Suite Reuse: Searches existing suites with ripgrep before creating files, rejects low-signal tests like snapshots and literal CSS assertions, and records the decision with a verification command.
  • Use Case: When a reviewer asks for a regression test on a bug fix, use this Skill to reproduce the bug, name the invariant, find the suite that already owns that layer, and add the narrowest case there instead of creating a new file.

Quick Start

Use the eng-consolidate-test-suites skill to decide where the regression test for this bug fix should live before writing any test code.

Frequently Asked Questions about eng-consolidate-test-suites

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

FAQPage Schema
How do I decide where a new test should go?

Name the invariant the test must prove, then pick the single lowest owning layer that can prove it, such as unit, integration, or end-to-end. Search existing suites for that layer first and add the case to the canonical suite rather than creating a new file.

How to avoid writing redundant or duplicate tests?

Check whether another suite already proves the same failure mode before adding coverage. Only duplicate an invariant across layers when each layer proves a distinct failure mode, and name that failure mode explicitly.

What kinds of tests should be rejected as low-signal?

Reject tests that freeze implementation details, CSS literal values, snapshots, prose strings, config shape, or file existence. Static artifact tests are allowed only when the artifact itself is the product contract and no stronger gate exists.

When is it acceptable to create a new standalone test file?

Create a new file only when no existing suite owns the invariant, such as a new public API, a new boundary, a security or data-loss corpus, or an established file-level contract pattern. Document why existing suites could not own the case.

What should I do when a coverage target conflicts with test placement?

Do not add filler tests to raise coverage numbers. Report the coverage gap and add behavior-bearing tests only where a named invariant exists, since coverage padding is explicitly rejected.