Skip to content
OpenChipwiki

Generating a chip with AI

OpenChip ships a skill, openchip-design, that lets an AI assistant turn a description of what a chip should do into a channel network and hand you back a .openchip file, checked and ready to open. Reach for it when you know the function you want — “mix two dyes gently”, “make 50 µm droplets”, “four concentrations from two syringes” — and would rather say that than place every node by hand.

It is not a separate tool. It is your assistant — Claude, or a coding agent such as Claude Code, Codex or Cursor — with the skill installed, doing the same layout work you would do in the Draw tab and running it through the same checks as the Design checks panel before handing the file back.

Click Design with AI in the top bar, on the first card in the Library, or on an empty canvas. The dialog has three steps:

  1. Describe the chip. Say what it should do. Your printer profile is added to the prompt for you, so the assistant knows your minimum feature size.
  2. Send it to your assistant.
    • Claude app: download the skill once (Download skill (.zip)) and upload it under Settings → Skills in Claude. Then Open in Claude starts a conversation with your description already filled in, or Copy prompt puts it on your clipboard.
    • Coding agent: install the skill once with npx skills add Jujified/OpenChip, then paste the copied prompt into the agent.
  3. Bring the chip back. Drop the .openchip file the assistant made onto the dialog, or choose it. It opens as a new project; if your current one has unsaved changes, you are asked first.

OpenChip itself sends nothing. The buttons copy text, download the skill from files built into the app, or open a link — your description goes only to the assistant you choose, under that assistant’s own terms.

  1. Say what you want, in your own words. A function is a complete brief — “a serpentine mixer for two dyes” is enough to start from.
  2. Answer a question or two. First, unless you already said, it asks whether to write a short .chip source file and compile it, or the .openchip JSON directly — the DSL is easier to review and to hand-edit afterwards, and is the default when there is no one to ask. It may also ask about your printer or whether you want two-piece, glass-slide or monolithic, but only when your request leaves that open. A prompt from Design with AI already carries your printer profile.
  3. Read the check report, in plain words — every warning left in the design, and why: fixed as an accident, or kept because it is the point of the device.
  4. Open the file — drop it into step 3 of Design with AI, or use Project → Open Project. See Saving, opening, and sharing projects.

Always the .openchip file. If it was written as DSL, you also get the .chip source it compiled from — a short, readable text file that is what you edit next time you want to change the design, rather than the JSON.

The skill runs a checker that ports the app’s own validation: the same thresholds, the same loft-chain arithmetic, the same warning kinds you would see in the Design checks panel. See the Design-check catalogue for what each one means.

Finds Treated as
A duplicate id, a dangling edge, an invalid dimension marker A structural error — the file will not open. Always fixed.
channel-below-min-feature, channels-overlap, disconnected-network A risk warning — the design probably will not work as drawn. Fixed unless you said otherwise.
channels-too-close, abrupt-taper, enclosed-cavity and similar A caution or info — a judgement call. Fixed if it looks accidental, kept and explained if it looks deliberate.
Two nodes written at the same coordinates, a node no path mentions Not an OpenChip check at all — an authoring mistake that would otherwise show up three inferences downstream as a confusing dead end.

A clean report is not the goal by itself — a chip that checks clean but does the wrong thing is still wrong. The report is there so you can see what was traded off to get the geometry you asked for.

The skill knows a layout recipe for each of the mixing and separation principles behind OpenChip’s own template library — a Y-junction for gentle co-flow, a T for a compact contactor, a spiral for something that mixes better under more flow, staggered chevrons for chaotic advection, a branching tree for a concentration series, flow focusing for droplets, and a thin shared wall for heat exchange. See Templates for the same set of principles, with the physics behind each one.

Most real requests describe a natural system, not a named device — a gland, a gut, an industrial process. The skill’s method there is to write the request as a sequence of verbs (store, merge, hold, narrow, deliver), map each verb to a primitive, and chain them through shared nodes.

That composition always ends with a plain statement of what the result cannot be — because a planar channel network at a single height cannot express everything a real system does:

  • Anything happening below the channel’s own scale — floor texture, surface chemistry, a coating.
  • A membrane, filter, or anything that lets two adjacent streams exchange solute rather than only heat.
  • True sheath or annular flow — one stream wrapped inside another, rather than laid alongside it.
  • A valve, a pump, or any control that is not just the geometry and what the syringes do.
  • Chemistry or a phase change. The chip sets up contact, time and shear; it does not make a reaction happen, and OpenChip’s estimates model none of it.

This is the same honesty the app’s own template library keeps in its caveat fields — a limitation stated next to the capability it belongs to, not left for you to discover in the resin.

The skill is in the OpenChip repository at skills/openchip-design/: a plain-English brief, a reference of thresholds and layout recipes, worked examples, and a checker. The Download skill button packs exactly that folder.

The checker is a single script with no dependencies, so the assistant needs to be able to run Node to use it. One that cannot writes the .openchip file by hand and should say the file is unchecked — OpenChip runs the same design checks the moment you open it.

  • Templates — the same starting geometries, drawn by hand and already in the app’s Library tab.
  • Design checks — reading the warnings panel once the file is open.
  • Dimension markers and lofting — how a tapered throat like a droplet generator’s is actually built.
  • How this wiki is maintained — the update-wiki skill that keeps this site in sync with the app, the same way openchip-design keeps a generated chip in sync with the app’s own checks.