Blog / 8 min read · 2026-09-29

Gemini PCB Design Prompts for Planning, Reviews, and Documentation

Use Gemini PCB design prompts to structure requirements, component limits, layout checks, design reviews, and accurate handoff documentation on real boards.

gemini-pcb design prompts

These Gemini PCB design prompts help turn a vague hardware idea into a requirements sheet, review checklist, and useful documentation. They are meant to expose missing decisions before layout and make reviews less dependent on memory. Gemini can help analyze supplied text, images, and files, but it cannot replace schematic review, DRC/ERC, datasheet checks, simulation, prototype testing, or compliance work.

Use Gemini as a design assistant, not a sign-off authority

The best use of Gemini in a PCB workflow is structured thinking: extracting constraints from a product brief, comparing alternatives you provide, turning a layout screenshot into review questions, and drafting handoff material.

Gemini Apps allow users to add files or images to a prompt when signed in, so a prompt can refer to a schematic PDF, a board screenshot, or a component table rather than relying on a text-only description. Google’s Gemini Apps Help also cautions users to double-check responses and not rely on Gemini Apps for professional advice. For API workflows, Google documents image and PDF/document inputs as supported prompt media. Gemini API image understanding documentation and document-processing documentation explain those input methods.

Before pasting any prompt, remove confidential customer information, unreleased part numbers, credentials, and manufacturing files that your organization is not permitted to share.

A prompt pattern that works for PCB tasks

A short request such as “review my PCB” usually produces generic advice. Give Gemini a bounded job instead:

State what the board does and its operating environment.
Supply the relevant evidence: pasted requirements, BOM rows, a schematic excerpt, net-class rules, or a readable screenshot.
Name the output format and what Gemini must flag as unknown.
Require source references for any electrical claim it makes.

Google’s prompt guidance recommends clear, specific instructions and consistent structure. Gemini prompt design strategies are a useful basis for this approach.

Use this safety line in most hardware prompts:

Do not infer values, ratings, footprints, or compliance status that are not in the supplied material. Mark missing evidence as “Needs verification.” Do not approve the design or claim it is manufacturable.

Prompt 1: Turn a product idea into a PCB requirements sheet

Use this before choosing parts or starting a schematic.

Act as a PCB project analyst. Convert the brief below into a requirements sheet for an engineer.

Product brief:
[PASTE BRIEF]

Create these sections:
1. Functional blocks and their inputs/outputs
2. Electrical requirements, separating stated facts from assumptions
3. Mechanical and environmental constraints
4. Interfaces, connectors, and user-accessible signals
5. Power-tree questions and estimated load information, only if supplied
6. Safety, regulatory, test, and manufacturing questions that need an owner
7. Risks caused by missing information

For each requirement, include: requirement ID, source sentence or source field, requirement, verification method, owner, and status.
Ask up to 10 clarification questions first if necessary. Never invent voltage, current, temperature, isolation, or certification requirements.

This prompt produces a working backlog, not an engineering specification. Review every “assumption” with the product owner, then move accepted items into the controlled design requirements document.

Prompt 2: Build a component-constraint matrix

A BOM is often incomplete when a project begins. This prompt makes gaps visible without asking Gemini to select a part blindly.

I am designing a PCB with the following known component candidates and requirements.

System requirements:
[PASTE REQUIREMENTS]

Candidate components or BOM rows:
[PASTE TABLE OR TEXT]

Create a component-constraint matrix. For each functional block, list:
- required electrical limits from the supplied information
- package, assembly, sourcing, lifecycle, and thermal constraints that are explicitly stated
- candidate parts supplied by me
- missing datasheet fields or missing decisions
- compatibility questions between connected parts
- verification actions before schematic release

Do not recommend a component unless the supplied evidence supports it. If you compare candidates, cite the exact supplied datasheet page, table, or row for each comparison. Put unsupported conclusions in a “Needs verification” column.

Attach datasheet PDFs only when they are readable and current. If Gemini summarizes a datasheet table, open the original table yourself before changing a schematic symbol, footprint, or tolerance.

Prompt 3: Create a placement plan before routing

Use this after the schematic is stable enough to identify functional blocks, connectors, heat sources, and sensitive nets.

Create a preliminary PCB placement plan from the material below.

Board constraints:
[BOARD OUTLINE, MOUNTING HOLES, HEIGHT LIMITS, CONNECTOR LOCATIONS]

Functional blocks:
[LIST BLOCKS]

Critical nets and components:
[LIST POWER, CLOCK, RF, HIGH-SPEED, ANALOG, HOT, OR HIGH-VOLTAGE ITEMS]

Return:
- a block-by-block placement order
- adjacency requirements and separation requirements
- connector and service-access considerations
- likely return-path, thermal, noise, and assembly concerns
- a list of placement rules that require confirmation from the relevant datasheet, stackup, or fabrication capability
- questions that cannot be answered from the input

Treat this as a review aid. Do not claim routing, impedance, creepage, clearance, thermal performance, or EMI performance is acceptable.

If using a board screenshot, label the image in the prompt: “Image 1 is the top copper view” or “Image 2 is the assembly view.” Asking Gemini to inspect a named area is more useful than asking for a broad critique.

Prompt 4: Review a layout screenshot systematically

This is the most practical Gemini PCB design prompt for a design review meeting. Upload a high-resolution screenshot or PDF, then paste the text below.

Review the attached PCB image as a checklist exercise.

Context:
- Board purpose: [PURPOSE]
- Layer stackup known to you: [STACKUP OR “NOT PROVIDED”]
- Critical nets: [NETS]
- Power rails: [RAILS]
- Known mechanical constraints: [CONSTRAINTS]

Inspect the image only for visible evidence. Produce a table with:
1. Area or component reference
2. Observation
3. Why it may matter
4. Evidence visible in the image
5. Severity: review / investigate / likely issue
6. Exact verification needed

Focus on connector access, decoupling placement, power-current paths, return-path interruptions, sensitive-net proximity, copper bottlenecks, test access, thermal relief, silkscreen collisions, and assembly orientation.

Do not state that any spacing, trace width, impedance, current capacity, or regulatory requirement passes unless a supplied rule or source proves it. If the image is insufficient, say so.

Treat the output as a meeting agenda. The reviewer should inspect the source layout in the EDA tool, run the project’s actual rules, and check the stackup and fabrication constraints.

Prompt 5: Run a design-review question set

A review is stronger when it separates observations from decisions. Give Gemini the design notes, open issues, and a limited scope.

Prepare a PCB design-review agenda from the following project material.

Project notes:
[PASTE NOTES]

Open issues:
[PASTE ISSUES]

Review scope:
[SCHEMATIC / PLACEMENT / ROUTING / POWER / DFM / TEST]

Create:
- a one-sentence review objective
- prioritized questions for the engineer, firmware owner, mechanical owner, manufacturing owner, and test owner
- evidence needed to close each question
- decisions that must be recorded
- issues that should be deferred because the supplied evidence is insufficient

Separate confirmed facts, assumptions, and unresolved risks. Do not create a pass/fail verdict.

This avoids a common failure mode: a polished summary that hides unanswered questions.

Prompt 6: Draft handoff and manufacturing documentation

Documentation prompts are valuable after the engineering team has made the decisions. Use Gemini to assemble and normalize information, then have the responsible engineer approve it.

Draft a PCB handoff document using only the supplied project data.

Source material:
[PASTE RELEASE NOTES, BOM STATUS, ASSEMBLY NOTES, TEST NOTES, AND OPEN DEVIATIONS]

Write:
- release scope and revision identifier
- board purpose and intended use
- controlled deliverables checklist
- assembly notes
- inspection and test notes
- approved deviations and their owners
- known limitations
- open items that block release

Use concise technical language. Preserve reference designators, revision IDs, and stated values exactly. Mark any missing field as “Not provided.” Do not create fabrication instructions, substitutions, or acceptance criteria that are absent from the source material.

FAQ

Can Gemini design a PCB from a prompt?

It can help organize requirements, explain supplied material, draft checklists, and surface questions. It should not be treated as the authority for electrical correctness, manufacturability, safety, EMC, thermal behavior, or component suitability.

What should I upload for a Gemini PCB layout review?

Start with a clearly labeled board screenshot, schematic PDF, net-class summary, stackup details, and the specific review question. Do not expect a reliable clearance or impedance conclusion from an image alone.

Can Gemini choose components for my board?

Use it to build a comparison table from datasheets you provide. The engineer still needs to validate ratings, tolerances, package land patterns, availability policy, thermal conditions, and system behavior against authoritative sources.

How do I stop Gemini from making up PCB details?

Tell it to use only supplied evidence, require a “Needs verification” field, and ask it to cite the supplied page, table, or row behind every technical comparison. Unknown information is more useful than a plausible guess.

What is the final check before using Gemini-generated notes?

Compare every design-affecting statement with the controlled schematic, layout, datasheets, stackup, manufacturing rules, and test evidence. If the claim cannot be traced to one of those sources, keep it out of the release decision.