ZipZip

Inspiration

The name ZipZip (and thank you TriVista!) came to me immediately when thinking about fast variations. I wanted a /zipzip command inside Codex that could look through a project, identify a section of code or creative target that could be iterated on, and quickly create many different variations. I had already been using creative lenses to approach tasks from different perspectives. ZipZip turns that into a repeatable process: give several Codex agents the same task, augment each prompt with a different task-agnostic perspective, and bring the results together so they can be explored quickly. It was important to me that ZipZip was built as a Codex skill. I wanted to invoke it naturally with /zipzip or refer to it directly with @ZipZip while working inside a project.

The idea is simple: use Codex to see more directions before committing to one.

What it does

ZipZip creates parallel variations of almost any project target. The target could be an SVG logo, front-end component, CSS treatment, interface, document, function, or something completely new. It can iterate on an existing project target:

/zipzip make 16 variations of the official logo

It can also create a new artifact by combining a model, lens, format, and natural-language request:

/zipzip use Luna light fast and the poets lens to create a 5×3 SVG with just the text of a proverb and no other text

ZipZip works out the intended target from the request, selected file, project, or conversation. It then gives each Codex agent the same task and requirements with a different creative perspective. As the agents finish, their results appear in a progressive local gallery. I can expand or open each artifact, inspect the exact prompt and provenance behind it, copy that prompt, and decide which direction to continue. The model, reasoning level, speed, lens, and number of variations can all be configured. ZipZip favors lower-cost capable models for creative fan-out by default, while allowing stronger models when the task or user calls for them.

How I built it

ZipZip is a repository-local Codex skill supported by a Node.js runner. The skill instructions teach Codex how to interpret natural-language requests, resolve the intended target, gather the necessary project context, and construct the prompts. For every variation, the runner combines:

• One task-agnostic creative lens.
• The user's request.
• The relevant project context.
• The exact target source when one exists.
• A dedicated output location.

The runner starts the selected Codex agents simultaneously. Each worker writes only its assigned artifact. ZipZip then collects the returned files and creates a gallery that can be opened directly from disk. The skill includes its own lens libraries, model configuration (or should discover it), gallery resources (for showing the variations), and presentation asset in the form of my SVG logo. Building it as a skill was an important part of the project. ZipZip is not a separate application that happens to call Codex. It becomes part of the Codex experience and can be used naturally while I am already working inside another project. Codex is its reference environment, but the core concept is broader. The skill instructs other capable AI environments to adapt the fan-out workflow using the models and tools available there. If anyone uses it in other environments I'd like to hear!

Challenges I ran into

The hardest part was iterating on the actual experience of using ZipZip in Codex optimally.

An early version of ZipZip included an evaluation stage. Every candidate was supposed to be tested before it appeared in the gallery. This did not work well for a general creative tool because different outputs required completely different testing systems. Failures are not the end of the world and waiting for evals slowed everything down considerably.

I removed evaluation, retries, ranking, and repair. ZipZip now focuses on generating variations quickly and showing what returned. The person using it makes the creative decision.

Prompt tuning will probably never be finished -- the creative perspectives needed to influence style and judgment without changing the task, and I think people will make their own and the provided lens are simply a few possibilities.

I spent a lot of time simplifying the structure, separating the task from the lens, and tuning language prevent agents returning similar results.

I've redone the gallery quite a few times, and hope the current version will balance the need for broad visibility across different types of targets -- and it now progressively reveals completed artifacts, supports larger previews, preserves sandboxing for generated HTML, and embeds prompt provenance without requiring a local server.

Accomplishments that I'm proud of

The accomplishment I am most proud of is that ZipZip is fun to use. I keep finding reasons to use it while working on other projects. It does not feel like a demonstration that I built for a single submission. It has become something I actually reach for when I want to see more possibilities quickly. I am also proud that it became a general workflow rather than a tool built around one specific example. It can work with an existing target or create something completely new. It supports different models, reasoning levels, speeds, lenses, file types, and numbers of variations without requiring a rigid command format. I made ZipZip open source so other people can use and adapt it in their own projects, I hope people find the lens part interesting as well!

What I learned

The biggest thing I learned was how to create a skill inside Codex and how much the experience depends on the skill instructions. Building the runner was only part of the work. I had to iterate on how /zipzip understands natural language, selects a target, decides what it can infer, determines when a question is necessary, handles model settings, and presents its results. I already understood that creative results are sensitive to prompt framing, but this project gave me a chance to refine that understanding through repeated real runs. Removing unnecessary stuff seems to be a growing art when we have such capable tools, thankfully Codex was helpful at slimming everything down just like it helped build it.

What's next for ZipZip

I'm using ZipZip throughout my projects, so I will continue that. I have lots of plans for lens as well -- most of these examples use an MBTI variation but there are many more ways. The long-term idea is for ZipZip to become a lightweight creative exploration layer inside Codex or anywhere. If it gives people a project to look at where they make their own version, that's a success to me too. Enjoy everyone and thanks for the support!

Built With

• codex
• grit
• trivista