Specmatic is an API contract-testing platform that helps engineering teams validate APIs against their specifications and maintain compatibility as systems evolve. Specmatic needed working sample projects across dozens of stack combinations. Technogise built the generator, and the engineering went into deciding what the model would be told, what it would be left to know, and what it would deliberately not be asked to do.
Specmatic turns API specifications into executable contracts. The same specification runs as a test suite against the service that implements it and as a stub in place of a service it depends on, so both sides of an integration are checked against the contract before they meet.
Specmatic needs sample projects showing it working in the stack a developer already uses: their language, their framework, their protocol, their kind of data access. Six axes decide what a sample looks like, and every one of them multiplies the last.
Writing that library by hand does not scale, and the maintenance cost is the worse half of the problem. The product keeps shipping: a new resiliency option, a changed configuration format, a newly supported version. Each of those changes lands on every sample already written, so the library falls behind the product it exists to demonstrate.
A generator cannot treat those axes as a free cross-product. It has to settle a valid combination with the requester before it writes anything.
A plugin that runs under both Claude Code and Codex, distributed through GitHub-hosted plugin repositories. The skill is written once against a standardised structure and works in either tool, so a team adopting it is not committing to a single coding agent.
It contains a skill that walks the requester through the classification axes one at a time, confirms the combination makes sense, then generates a complete project:
One local command runs the full build.
The engineering in this project sits in the decisions about what the model was asked to do. Every one of them traces back to a single constraint: nobody would be checking the result.
Almost every skill a team installs runs inside a loop that already has a reviewer in it. A developer asks for a migration, a refactor, a test suite, and then reads what comes back. They know the codebase, they know what correct looks like in it, and they redirect the agent while the work is still cheap to change. The skill can afford to be thin, because the person is the check.
This one runs without that person. Someone reaching for the generator wants a sample in a stack they may not work in daily, demonstrating conformance to a contract-testing tool whose correct output is the thing they are trying to learn. They cannot review what they do not yet know. They will also run the generator rarely, so the cost of a single run barely registers against the cost of a wrong sample shipped as a reference and copied by whoever reads it next.
That changed the cost calculation. The skill uses the strongest model available and does not economise on token use, because there is no downstream check that would catch what a cheaper run got wrong.
The rest of the design follows from the same premise. If a person cannot check the output, the skill has to be built so the model is unlikely to get it wrong, and so the work it produces checks itself.
A general-purpose coding model already knows a great deal of what appears in these samples: REST semantics, JUnit and pytest idiom, Gradle and npm conventions, how a Spring controller or an Express route is normally written. All of that is heavily represented in training data and needs no explanation, so the skill says nothing about it.
Specmatic's own specifics sit at the other end. A contract-testing tool with a particular configuration format, particular integration modes and particular resiliency behaviour is thinly represented in training data however fluent the model is in general. Those are the parts written out explicitly.
A third category matters as much as the other two. Where an authoritative source already exists, the product's documentation and the contract schemas, the skill points at it rather than restating it. When the product ships a change, an instruction that paraphrased the docs is wrong, while an instruction that pointed at them is still correct.
Discovery is bounded differently on each side of that line. On the product, the model works only from the material the skill points it at. It does not go looking for other pages, older release notes or third-party write-ups to resolve a problem for itself, because the surface is small enough that an outdated page carries real weight once the model treats it as authoritative. On the language and framework, the instruction reverses and the model is encouraged to go and read. Those ecosystems are large, well documented and slow-moving, and the model's judgement about which source to trust in them is good.
The obvious way to build this is to close the loop. Generate a sample, run the contract tests, read the failures, fix the code, repeat until green. We did not build that loop.
The backward step is the part that does not work. The tests are not a fixed list the skill could look up. The tool works out what to generate and what to assert at run time, from the contract and from how much edge-case generation is switched on. A failure therefore arrives without the thing you would need to act on it: which rule was violated, and what the sample should have done instead. That cannot be recovered from a pass or fail result.
Closing the gap would have meant handing the skill the testing tool's own source and asking it to reason about how the tool behaves. That is a far larger surface than generating a sample, it makes every run considerably slower, and the answer at the end of it would still be inference, so that work stayed out of scope.
The skill's goal stops at the sample code. It states what to generate for the chosen combination, in detail, rather than asking the model to derive that from a test verdict. The tests still run and still decide whether a sample ships, but the model does not reason backwards from them.
The skill tells the model explicitly that it can run the generated project's build while it works, so it finds its own compile errors, missing dependencies and wiring mistakes before anyone else sees them. With no human reviewer waiting downstream, the cheapest check available is the one the project already carries.
The contract tests are treated differently. They run, and they decide whether a sample ships, but the model is not asked to loop on them. What separates the two is what each failure is about. A compiler failure is about the code in front of it: a missing import, a bad signature, a dependency that was never declared. Those are ordinary programming problems and the model resolves them without help. A contract-test failure is different. It is the testing tool's verdict on the sample, measured against assertions the tool generated at run time, and it does not carry the rule that was broken or the shape the code should have taken. Acting on it means reasoning about the tool's internals rather than about the code, which is the larger job the skill was scoped to leave alone.
Every sample implements the same business contracts, so a reader comparing the Go sample against the Kotlin one sees only what the stack changes:
Each sample is therefore both a provider and a consumer of contracts, which is the pairing contract testing has to cover.
Nobody signs a sample off by reading it. A sample ships when its GitHub Actions pipeline is green end to end:
It also has to build locally on macOS, Linux and Windows. Technogise's own verification pass covers roughly ten of the harder language, framework and protocol combinations.
One rule sits underneath all of it. Every sample must be reproducible from the finished build of the plugin, with its pipeline green. Without it, samples get hand-tweaked to keep them passing, each fix small and reasonable on its own, and after enough of them the samples work while the generator no longer produces them. Requiring reproduction from the shipped plugin forces a fix into the skill, where it applies to every future sample, rather than into one sample's working tree.
The same logic covers upkeep. When the product adds a resiliency option, the fix is to update the skill so newly generated configuration carries it. Editing the existing samples would leave the generator behind, which is the state this project exists to avoid.
The rule carries a price, and it is the sharpest constraint on the project. A skill change made to bring one combination into line invalidates every combination already verified, because those samples came out of a different generator. Each edit to the skill sends the matrix back through testing from the start.
The order of testing therefore matters more than it usually would, and we put that question to the model. Asked which combinations of language, framework and protocol were most likely to come out wrong, it reasoned about where its own generation would be weakest and named them. The predictions were good enough to steer the verification pass, and they surfaced problems that working through the matrix in an arbitrary order would have reached far later. The model is an unreliable diagnostician of a contract-test failure. Asking it where its own output is likely to be weakest is a different question, and on that one it did well.
| © 2026 Technogise
