Why I built ConfIT

I wrote the first version of ConfIT in 2022, after watching the same thing happen on every API-heavy team I worked on: a component test and an integration test are nearly identical in structure, described twice. A developer writes one, running in-process against mocks, gated in CI before merge. QA writes the other against a real, deployed environment: same endpoint, same request shape, same kind of assertion, but usually in a completely different tool, a Postman collection, a separate framework, sometimes a separate repository. Two people solve the same problem twice, and the two versions drift the moment either one changes.

So I pulled the part that's identical, method, path, headers, body, expected response, how to match it, out of code and into a file. A JSON test definition, and now YAML too, is the same DSL whether WireMock is standing behind the endpoint or the real service is. The two suites still live apart; what they share now is one format, not two different ways of writing the same behavior.

That was the pitch in 2022: stop reinventing the same test-writing problem on both sides. It's a sharper pitch now, for a different reason. A skill that understands the DSL can read your OpenAPI spec, or just the controller, and write the JSON or YAML directly, no code, nothing to hand-maintain, a file that's easy to read in review. That's a fundamentally cheaper problem to solve than asking an AI to generate and maintain imperative test code, where there's scaffolding to get subtly wrong and assertion logic to hallucinate.

And the code being tested is increasingly agent-written too, which changes what a test is even for. A unit test written by the same model, in the same pass, that wrote the implementation isn't an independent check: a wrong assumption baked into the code tends to get baked into the test verifying it, so the two agree with each other while being wrong together. A black-box API test doesn't know or care how the endpoint is implemented, or even what language it's written in, only what the contract says should happen. That independence is worth more when the code on the other side of the wire was written by something that can be confidently, fluently wrong.

That's what the three agent skills in this repository are for: confit-suite-setup wires up a suite, confit-component-tests reads a controller and the mocks behind it and writes the developer-side spec, confit-integration-tests reads a spec, a collection, or a live endpoint and writes the QA-side one. Same DSL, two personas, because, as the skills doc puts it, the same lifecycle scenario comes out to 89 lines as a component test and 64 as an integration test, different only by a mock: block. Writing that by hand, twice, in two different frameworks, was already wasted effort in 2022. Having a skill write each version directly, from the controller on one side and the spec or a live endpoint on the other, is what makes fixing that finally cheap enough to stick.