Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →elianiva/architect
Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in.
Passed 7 of 18 test cases with the skill, and 7 of 18 without it.
and 4 more in the full report
5 fixed4 passed either way8 still failing5 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are designing an HTTP client wrapper for an external payment processor. Candidate A exposes 12 separate configuration and token-refresh helper methods. Candidate B hides configuration and token refreshing behind a unified request method. Which candidate is preferred under interface depth criteria?
| Checked | Without skill | With skill |
|---|---|---|
| Selects Candidate B for hiding operational complexity behind a smaller public interface. | Passed | Passed |
| Explains that a compact surface area reduces caller coupling. | Missed | Passed |
The instructions your model reads when the skill loads.
Design before implementing. Sketch types, function signatures, class shapes, and module boundaries with not implemented bodies and pseudocode. Synthesize across multiple model perspectives, then fill in code against the chosen sketch. If implementation proves the sketch wrong, throw it out and redesign.
Open a todolist with one entry per phase before starting. Autonomous mode without checkpoints needs the list to show phase position and keep phases from silently disappearing.
Build a real mental model of every system the new code touches. Run the how skill over the relevant subsystems. Critique mode if existing structure is the constraint or the design must push back on it.
Naming a file isn't grounding. Produce the traced model how prescribes. If the design redefines ownership or layering, also run the why skill on the existing shape so the rationale becomes a constraint, not a guess.
Skip Phase A only when the work is genuinely greenfield with no surrounding system to integrate.
Run the arena skill with the design-sketch task and the Phase A grounding artifacts. Pass references/runner-prompt.md as each runner's prompt. Each candidate produces a design package shaped per references/rationale-template.md: the caller's usage written first, then the type sketch, function signatures, module map, and prose rationale derived from it.
Use your configured architect runners (defaults inherit-parent, inherit-parent, inherit-parent, inherit-parent).
Design it twice. Require at least two structurally distinct candidates before synthesis, even when the first looks sufficient. This is the exhaust-the-design-space principle skill made concrete. Whole-shape alternatives, not point fixes inside one shape.
Screen every candidate against references/design-red-flags.md before synthesis. Reject or revise shallow modules, information leakage, temporal decomposition, and pass-through methods.
Compare viable candidates on interface depth. Prefer the design that hides more complexity behind a smaller, simpler public surface. A rich interface can keep call chains short by concentrating capability instead of scattering it across layers.
Arena returns one synthesized design package. The synthesis decision populates the rationale's "Synthesis decision" section.
Default: proceed directly to implementation with the synthesized design. No human checkpoint.
test cases passed, vs 7 / 18 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.