How to Write a Great Prompt for AI Schematic Generation

AI schematic capture moves the starting line. Instead of placing your first symbol and drawing your first net, you describe the circuit in plain English and get an editable, manufacturable schematic back. That is the 'step zero' before you ever open a layout tool.

The catch is that the model can only draw what you actually specified. It does not know your bench history, the regulator you always reach for, or the connector that matches your enclosure. A loose prompt forces it to guess, and guesses are where wrong rails and missing pull-ups creep in.

The good news: prompting a schematic is not mysterious. It follows the same order you would use to brief a junior engineer. State the brain, list what hangs off it, say how it is powered, and call out the house rules. Do that consistently and the first draft gets close enough that refining is fast.

Every good schematic prompt covers five things, in roughly this order. Skipping one is the most common reason a draft comes back wrong.

1. Core IC or MCU. Name the part that everything else connects to: 'ESP32-S3', 'STM32G031', 'RP2040'. This anchors the pin budget and the supply voltage.

2. Peripherals and interfaces. List each device and how it talks: 'BME280 temperature/humidity sensor on I2C', 'W25Q128 SPI flash', 'USB-C for power and data'. The interface matters as much as the part.

3. Power. State the input and the rails you want, plus the regulator type: 'input is 5V from USB-C, generate a 3.3V rail with an LDO'. Buck versus LDO is a real decision; say which.

4. Constraints. Decoupling caps, pull-ups, test points, connector types, ESD protection. These are the details that separate a sketch from something you can build.

5. Real part numbers, where you care. If a specific regulator or sensor matters, name it (an LCSC C-number or a manufacturer part number) so the symbol and footprint come from the real component, not a generic placeholder.

Vague prompt: 'Make me an ESP32 board with a sensor.' This compiles, but you are at the mercy of defaults: which ESP32 variant, which sensor, what bus, what power input. You will spend more time correcting it than you saved.

Specific prompt: 'ESP32-S3-WROOM-1 module. Add a BME280 environmental sensor on I2C with 4.7k pull-ups on SDA and SCL. Power input is 5V over USB-C; add a 3.3V LDO to supply the module and sensor. Include decoupling caps on the module rails and two test points on 3V3 and GND.'

The second prompt yields a draft where the bus, pull-ups, rail, and test points are already in place. You are reviewing a circuit, not reconstructing one from a hint. Everything you named is something you can check against the datasheet in minutes.

Vague prompt: 'STM32 board that can drive a motor.' The model has no idea whether you mean a brushed DC motor over a single half-bridge or a three-phase BLDC stage, what current, or how the MCU connects to the driver. The draft will be a coin flip.

Specific prompt: 'STM32G431 MCU. Add a DRV8313 three-phase gate driver connected to the MCU timer outputs for a small BLDC motor. Power input is 12V; add a buck converter to 3.3V for the MCU. Add bulk and decoupling capacitance on the 12V rail, and a 3-pin motor connector plus a 2-pin power connector.'

Here the buck (not an LDO) is the right call because you are stepping 12V down to 3.3V and an LDO would burn that drop as heat. Saying 'buck' in the prompt is the difference between a sensible power tree and a regulator that cooks itself.

Vague prompt: 'RP2040 board with USB.' You will likely get a bare MCU and a connector, missing the support parts an RP2040 actually needs to boot.

Specific prompt: 'RP2040 MCU with its required QSPI boot flash (W25Q128). USB-C connector for power and data, with CC pull-down resistors and the data lines routed to the RP2040 USB pins. Power input is 5V from USB-C; add a 3.3V LDO. Include the crystal, decoupling caps, a BOOTSEL button to GND, and a reset button.'

Naming the boot flash, the crystal, and BOOTSEL is what turns this from a block diagram into a board that comes up. These are easy to forget in a vague prompt and obvious to include once you are listing constraints deliberately.

The first draft is a conversation starter. When something is missing, add it with a short, specific instruction rather than rewriting the whole prompt. The tool edits the existing schematic instead of starting over.

Good refinements read like bench notes: 'add 4.7k I2C pull-ups on SDA and SCL', 'add a 3.3V LDO from the 5V USB input', 'change the regulator to a buck converter', 'add a 100nF decoupling cap per VDD pin', 'add a test point on the 3.3V rail'.

Each follow-up is a small, reviewable change. This is far easier to verify than a giant regenerated schematic, and it keeps the parts you already approved intact. Iterating one constraint at a time is the fastest path to a clean draft.

An AI draft is a hypothesis about your circuit, not a verified design. Two checks catch most issues before they reach layout.

First, run ERC and DRC. Electrical rule checks flag unconnected pins, conflicting outputs, and power nets with no driver. These are exactly the mistakes a generated schematic can introduce, and they take seconds to surface.

Second, import real parts. Swapping a generic placeholder for an actual LCSC, DigiKey, or Mouser component pulls in the real pinout and footprint. If a connection was made against an assumed pinout that does not match the real part, this is where you find out, before the board is fabbed.

When the schematic checks out, export to KiCad and move on to layout and routing in your usual flow. ProtoFlow handles schematic capture; it does not route boards or run SPICE, so layout, simulation, and signal integrity stay in the tools you already use.

Fill in the brackets and delete what does not apply. It maps directly onto the five-part structure above.

'Core: [MCU/IC, e.g. ESP32-S3-WROOM-1]. Peripherals: [device + interface, e.g. BME280 on I2C; W25Q128 SPI flash; USB-C for data]. Power: input is [voltage + source, e.g. 5V from USB-C]; generate [rail, e.g. 3.3V] using [LDO or buck]. Constraints: [decoupling on all supply pins; pull-ups on I2C; test points on 3V3 and GND; ESD protection on USB; connectors: ...]. Use these specific parts where noted: [part numbers / LCSC C-numbers].'

Keep it as a snippet and adapt it per project. Once the structure is muscle memory, you will write prompts that produce buildable drafts on the first or second try, then let ERC, DRC, and real-part import do the final confirming.