What this prompt does
This prompt turns an uploaded diagram into a working code scaffold. You tell Gemini the [diagram_type] you're sending — a whiteboard sketch, a wireframe, or a formal system architecture diagram — and it walks a ten-step pipeline: identifying every component and connection, inferring the implied tech stack, generating [output_type] per component, defining the contracts between services, and producing [infrastructure_code] for what's drawn.
The structure works because it forces the model to reason about the picture before it writes anything. Naming components and connections first means the generated stubs actually wire together. The [scale] variable shapes the resource estimates and the bottleneck analysis — asking for 10,000 concurrent users produces very different sizing than asking for a hobby project. The final ambiguity clause is what keeps it honest: instead of silently guessing at a fuzzy box on your whiteboard, it surfaces its interpretation and alternatives.
When to use it
- You've sketched an architecture on a whiteboard and want stub services to start coding against
- You need
[infrastructure_code]like Terraform or Compose generated from an existing diagram - You want a second opinion on single points of failure before you commit to a design
- You're documenting a system someone else diagrammed and need a README plus dependency graph
- You want rough resource and cost sizing for a target
[scale]early in planning - You're prototyping and want service boundaries and interface contracts defined up front
Example output
Expect a structured document, not a single file: a component inventory, an inferred stack list, code stubs grouped per service, interface definitions, an [infrastructure_code] block, a generated README, a risks section (single points of failure, bottlenecks, security gaps), suggested improvements, a dependency graph, and a resource estimate for your [scale]. Ambiguous parts of the diagram come with the model's interpretation plus alternatives.
Pro tips
- Be specific with
[diagram_type]— "AWS network diagram" yields tighter IaC than a vague "diagram," because the model maps to known service primitives - Match
[output_type]to your real stack; "Docker Compose services with stub implementations" is great for local dev, but ask for Kubernetes manifests if that's where you deploy - Treat generated
[infrastructure_code]as a scaffold, never production-ready — review IAM, networking, and secrets by hand before applying - Set
[scale]honestly; an inflated number inflates the cost estimate and over-engineers the suggested improvements - Upload a high-resolution, legible diagram — vision models misread cramped labels and faint arrows, which corrupts the component list
- Run the security-gaps section as a checklist to verify against the real diagram, not as a final audit
