CREATE a paperbanana prompt engine that can take a collection of code and design documents and create multiple paperbanana prompts to generate quality artifacts for visually representing the architecture, design decisions, executive, summary, components and their data flows
You want a prompt engine that ingests code + design docs and emits a set of PaperBanana prompts covering architecture views, decisions, flows, and exec summaries.12
Below is a concrete design plus ready-to-use system/user prompts you can drop into your own agents.
1. High-level architecture of the prompt engine
Treat this as a meta-PaperBanana pipeline: you are not generating images directly, you are generating PaperBanana-ready prompts.
Phases:
- Document ingestion
- Inputs: repo paths, ADRs, RFCs, architecture docs, design specs, API schemas.1
- Normalize into chunks with metadata: component, layer, concern (arch, data, runtime, etc.).
- View-plan generator (your “Planner” analog)
- Infer a canonical set of views:
- Each view becomes a “prompt spec”: title, intent, audience, key entities/flows.
- Diagram-style template builder (your “Stylist” analog)
- Prompt generator (your “Visualizer prompt author”)
- Critic loop (optional)
2. Canonical schema for a PaperBanana prompt
Use a strict JSON-like internal schema and then render to natural language:
type DiagramPromptSpec = {
id: string;
diagramType: "exec_summary" | "context" | "container" | "component" | "data_flow" | "deployment" | "decision_rationale";
title: string;
audience: "executive" | "architect" | "developer" | "stakeholder";
primaryQuestion: string;
entities: Array<{
id: string;
label: string;
category: "user" | "system" | "service" | "database" | "queue" | "external_api" | "process" | "data_store" | "ui" | "infra";
layer?: "client" | "edge" | "backend" | "data" | "infra";
description: string;
}>;
relations: Array<{
from: string;
to: string;
label: string;
direction: "uni" | "bi";
channel?: "http" | "grpc" | "event" | "batch" | "internal";
critical?: boolean;
}>;
styleProfileId: string;
constraints: {
maxPanels?: number;
emphasizeDataFlow?: boolean;
emphasizeControlFlow?: boolean;
showNonFunctionalConcerns?: boolean; // latency, compliance, resilience
};
notesForModel: string[];
};
Your engine converts a DiagramPromptSpec + StyleProfile to a PaperBanana textual prompt.
3. Core system prompt for the “Prompt Planner” agent
You can use this as the system prompt for a planning agent that takes raw docs and emits DiagramPromptSpec objects:
SYSTEM: You are an architecture view planner for a multi-agent image generation system inspired by PaperBanana.32 Input:
- A collection of software artifacts: code snippets, architecture documents, RFCs, ADRs, design notes. Task:
- Infer the key components, services, data stores, external dependencies, and user roles.
- Propose a minimal but complete set of diagrams that, together, communicate:
- The executive architecture summary.
- System context and main subsystems.
- Component decomposition and deployment topology.
- Critical data and control flows for major use cases.
- Key design decisions and tradeoffs (security, compliance, scalability, resilience).
- For each diagram, emit a
DiagramPromptSpecJSON object (no prose around it).- Use
diagramTypein {exec_summary,context,container,component,data_flow,deployment,decision_rationale}.- Faithfulness is the top priority: never invent components not reasonably implied by the docs, and flag any assumptions in
notesForModel.3 Output:
- A JSON array of
DiagramPromptSpecobjects that can later be rendered into PaperBanana textual prompts.
4. Style profile and “Stylist” system prompt
Define a reusable style profile for a family of diagrams (e.g., “enterprise SaaS microservices in cloud”):
{
"id": "enterprise-saas-v1",
"colorPalette": {
"client": "#4F46E5",
"edge": "#0EA5E9",
"backend": "#22C55E",
"data": "#F97316",
"infra": "#6B7280",
"external": "#A855F7"
},
"shapeByCategory": {
"user": "rounded-rectangle",
"system": "rectangle",
"service": "rectangle",
"database": "cylinder",
"queue": "hexagon",
"external_api": "dashed-rectangle",
"process": "rounded-rectangle",
"data_store": "cylinder",
"ui": "rectangle",
"infra": "rectangle"
},
"globalRules": [
"Group components by layer with subtle background bands (client, edge, backend, data, infra).",
"Use left-to-right primary data flow where possible.",
"Use solid arrows for synchronous calls, dashed arrows for async or event-driven flows.",
"Label all arrows with verbs describing the action or data (e.g., 'POST /orders', 'publish OrderCreated').",
"Include a minimal legend if more than three visual conventions are used.",
"Prefer concise labels over long sentences inside boxes."
]
}
Stylist system prompt:
SYSTEM: You are a diagram stylist for an agentic illustration framework similar to PaperBanana.54 Input:
- A
DiagramPromptSpecJSON object.- A
StyleProfileJSON object with palette, shapes, and layout rules. Task:- Produce a single natural-language block that:
- Describes the desired diagram in detail.
- Explicitly encodes visual grouping, colors, shapes, arrow styles, and legend requirements.
- Remains concise and readable while being fully specified.
- Do not output JSON, only a natural-language instruction suitable for a system like PaperBanana or Nano Banana Pro.67 Constraints:
- Never reference the existence of JSON or internal IDs in the output.
- Use explicit phrases like “use a cylinder shape for databases and orange color for data stores” when helpful. Output:
- One paragraph of detailed diagram instructions, no explanations.
5. Template: from DiagramPromptSpec to concrete PaperBanana prompt
Below is a prompt template you can use inside your “Visualizer Prompt Author” agent.
USER (template): “Create a publication-ready software architecture diagram for the following system. The target audience is {audience} (e.g., executives, architects, developers). The diagram type is {diagramType}, with the title ‘{title}’.
Overall goal:
- Answer the question: {primaryQuestion}.
Content to include:
- Entities (each should be a clearly labeled node): {for each entity}
{label}: category{category}, layer{layer}, described as: {description}. {end}- Relationships (each should be rendered as a directional arrow): {for each relation}
- From
{fromLabel}to{toLabel}, label the arrow as{label}, direction{direction}, channel{channel}, {if critical}mark as visually important.{end}Visual style and layout:
- Apply this style profile:
- Use colors by layer: client = blue, edge = teal, backend = green, data = orange, infra = gray.
- Use shapes by category: users and processes as rounded rectangles, services and systems as rectangles, databases and data stores as cylinders, queues as hexagons, external APIs as dashed rectangles.
- Group nodes by layer into horizontal bands from top (clients) to bottom (infrastructure).
- Use solid arrows for synchronous calls, dashed arrows for asynchronous flows and events.
- Place key data stores centrally relative to services that depend on them.
- Include a compact legend explaining colors, shapes, and arrow styles.
Additional constraints:
- Focus on faithfully representing the described components and flows; do not add speculative services or data stores.3
- Maximize readability: avoid clutter, keep node labels short yet unambiguous.23
- Maintain conciseness and aesthetic coherence, similar to NeurIPS/ICLR paper methodology diagrams.892
Notes and assumptions: {for each notesForModel item}
- {note} {end}
Generate the final diagram accordingly.”
Your engine simply fills {...} from the DiagramPromptSpec + style profile.
6. Example: Exec summary + data-flow prompts from a monorepo
Assume your planner emits two specs:
- Executive summary diagram
- Data flow for “user uploads a document, it gets processed, and metadata is stored”
You’d generate two prompts:
A. Executive summary
USER: “Create a publication-ready executive summary architecture diagram for a multi-tenant SaaS platform that ingests user documents, runs AI-based analysis, and exposes results via a web console and APIs. The target audience is executives and non-technical stakeholders. … [insert entities/relations + style block as per template] … Focus on showing:
- Tenant-specific isolation boundaries.
- Data lifecycle from ingress to analytics.
- Third-party dependencies (LLM provider, object storage, identity provider). Avoid low-level implementation details such as specific class names or internal microservice frameworks.”
B. Data flow for “document ingestion pipeline”
USER: “Create a publication-ready data-flow diagram showing the end-to-end pipeline when a user uploads a document. Emphasize the sequence from upload, storage, asynchronous processing, AI analysis, enrichment, and final indexed search. … [insert entities/relations + style block] … Use a left-to-right flow starting from the browser and ending in the search index. Show all asynchronous steps with dashed arrows and queue icons, and highlight any components responsible for PII handling or compliance checks.”
These are ready to send to PaperBanana / NanoBanana Pro.
7. Critic / refinement prompt for iterating on the prompts (meta-loop)
To mirror PaperBanana’s Critic agent and improve prompt quality itself:45
SYSTEM: You are a Prompt Critic for an agentic illustration framework. Input:
- The original architecture/design documents (or a summary).
- A candidate PaperBanana diagram prompt. Task:
- Evaluate the prompt along four axes: faithfulness, conciseness, readability, aesthetics (as they relate to the resulting diagram).23
- Point out missing components, incorrect relationships, ambiguous labels, or unnecessary verbosity.
- Emit:
- A short bullet list of issues.
- A revised version of the prompt that fixes these issues, preserving the original intent. Constraints:
- Do not change business semantics without clear justification.
- Do not add speculative components not grounded in the input documents.
8. Suggested “next prompts” you can use with me
You said you’ll iterate; here are focused follow-ups to drive where you’re going:
- “Given this repo structure and these ADR snippets, generate
DiagramPromptSpecJSON objects for all key diagrams.” - “Using the following
DiagramPromptSpecobjects, produce final PaperBanana prompts ready for image generation.” - “Design a modular TypeScript implementation of the prompt engine with agents for Planner, Stylist, PromptAuthor, and PromptCritic, including interfaces and function signatures.”
- “Given this example PaperBanana prompt, act as a Prompt Critic and produce a refined version that improves faithfulness and readability.”
- “Propose an evaluation harness to score diagram faithfulness/coverage automatically using the underlying design docs as reference, similar to PaperBananaBench.”23
If you paste a concrete codebase layout or a design doc snippet, I can generate actual DiagramPromptSpec instances and their rendered PaperBanana prompts tailored to your system.
Examples of generated prompts for a microservices diagram
Here are concrete, copy‑pasteable examples you can adapt for PaperBanana or Nano Banana Pro to get microservices architecture diagrams.1718
1. High-level microservices system (exec/arch view)
“Create a clean, publication‑ready system architecture diagram for a cloud‑native microservices platform used by web and mobile clients.
Show the following main elements:
- Users: ‘Web User’ and ‘Mobile User’ at the far left, each connecting to a Web App and Mobile App respectively.
- Edge tier: a single API Gateway that all client requests go through; place it to the right of the clients.
- Core backend microservices (each as its own labeled box): Auth Service, User Service, Product Service, Order Service, Payment Service, Notification Service.
- Data layer: each service has its own database: Auth DB, User DB, Product DB, Order DB, Payment DB, Notification DB, all shown as cylinder icons aligned at the bottom.
- Async backbone: a central Event Bus / Message Broker (e.g., Kafka) between services for pub/sub, drawn in the middle with fan‑out arrows.
- External integrations: Payment Provider, Email/SMS Provider, and Identity Provider, drawn as dashed boxes on the right side as third‑party services.
Visual rules and layout:
- Use horizontal bands: Clients (top/left), Edge/API Gateway (center‑top), Backend services (middle), Data stores (bottom), External services (far right).
- Color each layer consistently: clients in blue, gateway in teal, backend services in green, databases in orange, external systems in purple.
- Use solid arrows for synchronous HTTP/gRPC calls (clients → gateway → services), dashed arrows for asynchronous event flows (services → event bus → other services).
- Label arrows with concise verbs or endpoints such as ‘login’, ‘GET /products’, ‘publish OrderCreated’, ‘charge payment’.
- Include a compact legend explaining the meaning of colors, shapes (boxes vs cylinders vs dashed boxes), and arrow styles.
Optimize for faithful representation of a typical microservices architecture, readable layout, and concise labels suitable for an executive or system‑design slide.”
2. Order processing microservice flow (data/control flow view)
“Draw a publication‑quality end‑to‑end data‑flow diagram for an e‑commerce order processing microservices architecture.
Show the main sequence when a user places an order:
- A User interacts with the Web UI or Mobile App.
- The app calls an API Gateway, which forwards the request to an Order Service.
- The Order Service synchronously calls Inventory Service to reserve items, then Payment Service to charge the customer.
- On success, Order Service persists the order in Order DB, publishes an OrderCreated event to the Event Bus, and responds back through the API Gateway to the client.
- Notification Service subscribes to OrderCreated and sends confirmation emails/SMS via an external Email/SMS Provider.
- Analytics Service also subscribes to OrderCreated and writes data into an Analytics Warehouse.
Visual style and layout:
- Arrange the components left‑to‑right in chronological order of the request: User → UI → API Gateway → Order Service → Inventory/Payment → Event Bus → Notification/Analytics.
- Represent microservices as green rounded rectangles, databases as orange cylinders, external providers as purple dashed rectangles, and the event bus as a central horizontal pill shape.
- Use numbered, solid arrows for the synchronous call chain (1. PlaceOrder, 2. ReserveInventory, 3. ChargePayment, 4. SaveOrder, 5. Response) and dashed arrows for asynchronous events (OrderCreated → Notification Service, OrderCreated → Analytics Service).
- Add brief text annotations near important steps, such as ‘saga or orchestration logic’, ‘idempotent consumers’, or ‘at‑least‑once delivery’.
The diagram must clearly distinguish synchronous request/response from asynchronous, event‑driven processing, and should be visually suitable for inclusion in a technical design document or architecture whitepaper.”
3. Multi-tenant microservices with shared platform services
“Generate a detailed multi‑tenant microservices architecture diagram for a B2B SaaS platform.
Include these elements:
- On the left, multiple Tenant Organizations (Tenant A, Tenant B, Tenant C), each with its own users and client applications (Admin UI, End‑User UI).
- A shared Edge Layer: Global DNS, CDN, WAF, and an API Gateway that handles all tenants but includes tenant routing and rate limiting.
- Core platform microservices (shown as green boxes in the middle): Tenant Management Service, Auth/SSO Service, Billing Service, Usage/Telemetry Service, Document Service, Search Service, Notification Service.
- Data isolation model:
- A Tenant Metadata DB (multi‑tenant, shared).
- Per‑tenant Document Storage (e.g., separate buckets or logically isolated prefixes) and Search Indexes.
- Cross‑cutting infrastructure services: Service Discovery / Service Registry, Config Service, Centralized Logging, Metrics/Tracing, Feature Flag Service.
- External providers: IdP (OIDC/SAML) for SSO, Payment Gateway, Email/SMS Provider, shown as dashed purple boxes on the right.
Visual conventions:
- Use subtle, semi‑transparent containers to group components by concern: ‘Edge & Routing’, ‘Core Platform Services’, ‘Observability & Operations’, ‘External Providers’.
- Clearly indicate tenant isolation boundaries with dotted rectangles or bands labeled ‘Tenant A logical boundary’, etc., especially around data stores and tenant‑scoped resources.
- Use consistent color coding: edge in teal, platform services in green, shared infra in gray, data stores in orange, tenants in blue, externals in purple.
- Arrows from tenant UIs always first hit the Edge Layer, then route into the backend services; avoid direct UI→service connections.
- Add a compact legend and keep labels short but unambiguous (e.g., ‘TenantMgmtSvc’, ‘UsageSvc’, ‘IdP’).
The final diagram should make it obvious how tenants share platform services while maintaining logical data isolation, and be suitable for inclusion in an enterprise architecture review deck.”
4. Service decomposition from monolith to microservices
“Create a side‑by‑side architecture transformation diagram that shows splitting a monolithic application into microservices.
Left side (Before):
- A single large ‘Monolith API’ box connected to a Web Client and Mobile Client.
- One shared Monolith DB beneath it.
Right side (After):
- Replace the monolith with multiple microservices: User Service, Catalog Service, Order Service, Payment Service, Recommendation Service, each with its own database (cylinders) aligned below them.
- Add an API Gateway in front of the microservices, connecting to the same Web and Mobile clients.
- Optionally include an Event Bus and show events like ‘UserCreated’, ‘OrderPlaced’, ‘PaymentCompleted’ flowing between services.
Layout and styling:
- Use a vertical dashed line down the middle labeled ‘Before’ on the left and ‘After’ on the right.
- Keep the client layer consistent across both sides to highlight that the change is in the backend.
- Color the monolith in a single solid color, and the microservices as distinct, evenly spaced boxes in a grid.
- Use concise annotations near the ‘After’ side explaining benefits like ‘independent deployability’, ‘database per service’, and ‘bounded contexts’.
Aim for a clear, educational diagram that visually explains the migration from monolith to microservices for an architecture document or conference slide.”
5. Operations-focused microservices view (observability, resilience)
“Produce a runtime and operations‑focused microservices diagram emphasizing observability, resilience, and platform components.
Required elements:
- Core microservices (Auth, User, Product, Order, Payment, Notification) connected through an API Gateway and optionally an Event Bus.
- Service Mesh sidecar pattern around each microservice (e.g., Envoy/ISTIO), shown as small proxy icons next to each service box.
- Shared platform services: Centralized Logging, Metrics/Monitoring, Tracing, Alerting, Circuit Breaker / Rate Limiter, Configuration Service, Feature Flags, Secrets Manager.
- Infrastructure: Kubernetes Cluster with multiple Pods per service, a Load Balancer, and Ingress Controller.
Visual composition:
- Group all microservices inside a large ‘Kubernetes Cluster’ boundary.
- Show the service mesh as a consistent visual motif: for each service, a tiny proxy box side‑by‑side, with traffic passing through the proxy.
- Draw arrows from services and proxies to logging, metrics, and tracing systems, highlighting that every request is observed.
- Use icons or colors to differentiate runtime concerns (mesh and infra in gray, services in green, observability stack in orange, external clients in blue).
The diagram should be suitable for a SRE or platform engineering audience, focusing less on business domains and more on traffic flow, reliability patterns, and observability.”
If you want, next step I can: take a concrete description of your system (service list, queues, DBs, external deps) and emit a set of 3–5 prompts like these, fully tailored to your architecture and ready to drop into PaperBanana.
do web research and find more paperbanana prompt examples
Here are additional prompt examples and templates aligned with how PaperBanana and Nano Banana Pro are used for structured, publication‑ready diagrams, adapted from available resources and prompt guides.3334353637
1. Methodology / pipeline diagram (PaperBanana style)
“Create a publication‑ready methodology diagram for a machine learning pipeline.
Content:
- Show the pipeline as a left‑to‑right flow with four main stages: Data Collection, Preprocessing, Model Training, Evaluation & Deployment.
- Under Data Collection, include icons for ‘User Logs’, ‘External APIs’, and ‘Batch Imports’.
- Under Preprocessing, show ‘Cleaning’, ‘Feature Engineering’, and ‘Train/Validation/Test Split’.
- Under Model Training, show ‘Baseline Model’, ‘Hyperparameter Search’, and ‘Ensemble’.
- Under Evaluation & Deployment, show ‘Metrics Dashboard’, ‘Canary Release’, and ‘Monitoring & Alerts’.
Visual style:
- Use clean, minimal, conference‑paper style: white background, thin lines, flat colors.
- Represent each stage as a labeled rounded rectangle, connected with thick arrows.
- Group related operations inside each stage in smaller boxes or bullet‑like sub‑nodes.
- Use a consistent color for each stage and show a small legend mapping colors to stages.
Optimize the layout for clarity and faithfulness to the described steps, with short, legible labels suitable for a NeurIPS/ICLR methodology figure.”
2. Model architecture diagram (transformer‑like, adapted from examples)
“Draw a detailed model architecture diagram for a Transformer‑based sequence model.
Include:
- On the left, an input token sequence ‘x₁ … xₙ’ embedded into Token Embeddings plus Positional Encodings.
- A stack of Encoder Layers (e.g., 6 layers) with each layer showing ‘Multi‑Head Self‑Attention’ and ‘Feed‑Forward Network’, plus residual connections and layer normalization.
- A stack of Decoder Layers with masked self‑attention, encoder‑decoder attention, feed‑forward, and residual paths.
- At the end, a Linear + Softmax head producing output token probabilities ‘y₁ … yₙ’.
Visual style:
- Use a consistent color palette: encoders in one color family, decoders in another, attention blocks in a third.
- Represent residual connections as thin dashed arrows that bypass sub‑blocks.
- Label each sub‑block (‘Multi‑Head Attention’, ‘FFN’, ‘LayerNorm’) with concise text.
- Make arrows directional and clearly show information flow from inputs to outputs.
The diagram should look like a polished, camera‑ready figure for a deep learning paper, prioritizing readability, concise labeling, and accurate structure.”
3. System diagram for an AI research tool (PaperBanana‑style “from text to figure”)
“Generate a system overview diagram for an AI‑powered academic illustration tool.
Components:
- On the left, a User providing ‘Raw Text Description’ and optional ‘Reference Figures’.
- A central Agentic Orchestrator coordinating five agents: Retriever, Planner, Stylist, Visualizer, Critic.
- The Retriever connects to a ‘Reference Figure Library’ and returns a small set of similar examples.
- The Planner outputs a structured ‘Diagram Plan’ that lists nodes, groups, and connections.
- The Stylist applies ‘Design Guidelines’ (color palette, layout, typography).
- The Visualizer calls an underlying Image Generation Model to render the diagram.
- The Critic inspects the result, compares to the plan and text, and either ‘Approve’ or ‘Send Revision Request’ back to the Planner/Stylist.
- On the right, output: ‘Publication‑Ready Diagram’.
Visual layout:
- Arrange agents horizontally or in a flow from left to right: Retriever → Planner → Stylist → Visualizer → Critic.
- Use icons or colors to differentiate agent types (retrieval, planning, styling, generation, critique).
- Show feedback loop arrows from Critic back to Planner and Stylist, clearly labeled as ‘Refinement Iterations’.
- Include a minimal legend to explain the meaning of solid vs dashed arrows (forward vs feedback).
Aim for a clean, academic style figure suitable for inclusion in a systems paper, emphasizing the generate‑critique‑refine loop.”
4. Nano Banana Pro diagram prompt with explicit layout constraints
Adapted from Nano Banana Pro prompt guides emphasizing layout, structure, and interpretation.3537
“Create a high‑resolution software architecture diagram for a cloud‑native microservices system.
Surface and layout:
- Canvas: white background, 16:9 aspect ratio, 4K resolution.
- Divide the diagram into clear horizontal layers: Clients, Edge, Services, Data, External Integrations.
- Use a neat grid layout so that boxes and arrows are aligned; no overlapping labels.
Structure and components:
- Top layer: ‘Web Client’, ‘Mobile Client’ on the left, both connecting into a single ‘API Gateway’.
- Middle layer: 6–8 microservices in a row (Auth, User, Product, Order, Payment, Notification), each a labeled box.
- Bottom layer: one database per service as labeled cylinder icons, vertically aligned under each service.
- Center: a horizontal ‘Event Bus’ line that multiple services publish to and consume from.
- Right side: external systems (Payment Provider, Email/SMS Provider, Identity Provider) as dashed boxes.
Constraints and interpretation:
- All text must be sharp and legible, using a clean sans‑serif font.
- Use solid arrows for synchronous calls, dashed arrows for asynchronous events.
- Label every arrow with either an API endpoint or event name.
- Do not add decorative elements or photos; keep the style minimal and professional, like a conference slide.
Generate the diagram so that an engineer can immediately understand the system architecture and data flows.”
5. Multi-panel figure (overview + detail zoom)
“Design a two‑panel academic figure explaining a microservices architecture.
Panel A (left):
- A high‑level architecture overview with clients, API gateway, a group of microservices, and databases.
- Use simple boxes and cylinders, minimal labels, and emphasize the separation of concerns (API, services, data).
Panel B (right):
- A zoom‑in on the ‘Order Service’ internals.
- Show sub‑components: ‘REST Controller’, ‘Command Handler’, ‘Domain Model’, ‘Outbox Table’, ‘Event Publisher’.
- Show how a ‘PlaceOrder’ request flows through these layers and produces an ‘OrderCreated’ event.
Visual design:
- Panels should be side‑by‑side, each with its own title (‘A. System Overview’, ‘B. Order Service Internals’).
- Use the same color scheme and typography in both panels.
- Highlight the ‘Order Service’ in Panel A using a subtle outline or accent color, matching the zoomed‑in panel.
The final figure should look like a polished, camera‑ready multi‑panel figure for a software architecture or distributed systems paper.”
6. “Surface‑first” prompt template you can reuse
Heavily inspired by Nano Banana Pro prompt strategy: define surface, structure, components, constraints, interpretation.3735
“Generate a [SURFACE TYPE: e.g., architecture diagram, flowchart, pipeline figure] that explains [TOPIC].
Surface & layout:
- Canvas: [size/aspect], clean white background.
- Organize content into [layers/columns/panels]: [list layers].
Components to include:
- [list key entities and groups].
- Draw each entity as [shape + color], with short, clear labels.
- Show [types of relationships] with arrows or connectors, labeled with [verbs/events/API endpoints].
Constraints:
- All text sharp and legible, sans‑serif font, consistent size hierarchy.
- No decorative art, photos, or gradients; prioritize clarity and professionalism.
- Do not invent entities outside the list; keep the diagram faithful to the description.
Interpretation:
- The viewer should quickly understand [primary question the diagram answers].
- Arrange elements to minimize crossing lines and visual clutter.
Generate the final diagram accordingly.”
Fill [SURFACE TYPE], [TOPIC], layers, entities, and relationships from your system description or your DiagramPromptSpec.
If you’d like, send me a short, structured description of one of your real services (names, queues, DBs, external APIs), and I’ll generate 3–4 concrete PaperBanana/Nano‑Banana‑style prompts tailored specifically to that system, ready for you to test.