Your first interface idea is unlikely to be the best. Design it twice.
Paste a brief for one module - what it does, who calls it, its key operations, its constraints, what should stay hidden - and, if you have one, your own first sketch. Your browser checks the brief against the design-an-interface skill's five questions, counts the entry points and parameters of your sketch, and fills the skill's sub-agent prompts, for free. Then Designs writes three or four radically different interfaces, each under its own constraint, and the page checks that every design covers every operation and that no two are the same methods renamed. Compare weighs them in prose and synthesises the one to build.
The modules and their callers are invented. Each example comes with a saved model reply, so you can see the whole page without signing in or spending a credit.
What this does, and what it does not
"Design It Twice" is John Ousterhout's advice in A Philosophy of Software Design: the first interface you think of for a module is rarely the best, and the cheapest time to find a better one is before any code depends on it. The design-an-interface skill turns that into a procedure - gather the requirements, generate several radically different designs under deliberately different constraints, present each one, compare them in prose, then synthesise - and this page runs it on one module brief.
The free part runs in your browser: the skill's five requirement questions checked against your brief, an entry-point, parameter and boolean-flag count of your sketch or of pasted designs, the overlap between designs, and the skill's own sub-agent prompt filled in for each constraint, to run with your own agents if you prefer. The Designs lane writes one design per constraint - fewest methods, most flexible, the common case first and, optionally, one that borrows a paradigm - with its signature, a usage example, what it hides and its trade-offs. The Compare lane weighs them on interface simplicity, generality, implementation efficiency, depth (a small interface over a lot of complexity) and ease of misuse, and proposes a synthesis with each borrowed element named.
It designs interface shape only: no implementations, and no judging a design by how hard it would be to build. Counts are the page's own, from the signature text - a heuristic per language, shown so you can check them; methods of an interface the module takes as a parameter, such as an injected clock, count as what the caller implements, not as entry points - and the model is never asked to state a measurement. Derived from the agent skill @mattpocock/design-an-interface (github.com/mattpocock/skills, MIT). Sources are listed in llms.txt.