diff --git a/app/api/chat/route.ts b/app/api/chat/route.ts index 61329e4..d906a2d 100644 --- a/app/api/chat/route.ts +++ b/app/api/chat/route.ts @@ -600,7 +600,7 @@ IMPORTANT: The "Current diagram XML" is the SINGLE SOURCE OF TRUTH for what's on tools: { // Client-side tool that will be executed on the client display_diagram: { - description: `Display a diagram on draw.io. Pass ONLY the mxCell elements - wrapper tags and root cells are added automatically. + description: `Display a diagram by writing raw draw.io XML yourself. This is the EXCEPTION, for diagrams whose exact positions are the content (UI mockups, floor plans, circuit/P&ID, seating charts, Gantt, illustrations). For flowcharts and anything nodes-and-arrows use draw_graph; for nesting-based diagrams (cloud architecture, swimlanes, sequence, mind maps) use restructure_diagram. Pass ONLY the mxCell elements - wrapper tags and root cells are added automatically. VALIDATION RULES (XML will be rejected if violated): 1. Generate ONLY mxCell elements - NO wrapper tags (, , ) @@ -764,7 +764,7 @@ BOX SHAPES: add_box takes shape — "decision" for a branch (diamond), "terminat draw_graph: { description: `Draw a FLOWCHART or other arrow-driven diagram from nodes and arrows alone. Give NO positions and NO nesting. -USE THIS FOR: flowcharts, decision trees, process and approval flows, CI/CD pipelines, state machines, dependency graphs, ER diagrams, site maps, data-flow diagrams. +USE THIS FOR: flowcharts, decision trees, process and approval flows, CI/CD pipelines, state machines, git/branching workflows, dependency graphs, ER diagrams, site maps, data-flow diagrams, and any "illustrate how X works" where X is a sequence of steps or states. The engine reads the arrows to work out how many rows the diagram has, which nodes share a row, and who goes left of whom — chosen to keep arrows from crossing each other or running through unrelated boxes. Do NOT lay these out yourself with nested containers or XML: declaring a flowchart as nesting puts every step in one column, so each branch has to jump over the step beside it. @@ -857,7 +857,7 @@ Shapes: "decision" for a branch (diamond), "terminator" for a start or end point }, }, get_shape_library: { - description: `Get draw.io shape/icon library documentation with style syntax and shape names. Use this for NON-AWS diagrams (flowcharts, BPMN, sequence, mind maps, UI mockups) that go through display_diagram. For AWS architecture, use search_stencils + restructure_diagram instead. + description: `Get draw.io shape/icon library documentation with style syntax and shape names. Use this before writing raw XML with display_diagram (UI mockups, floor plans, and other absolute-position diagrams). Flowcharts go through draw_graph and AWS architecture through search_stencils + restructure_diagram - neither needs this. Available libraries: - Cloud: aws4, azure2, gcp2, alibaba_cloud, openstack, salesforce diff --git a/lib/system-prompts.ts b/lib/system-prompts.ts index e6d787a..18b77ac 100644 --- a/lib/system-prompts.ts +++ b/lib/system-prompts.ts @@ -9,11 +9,11 @@ // Default system prompt (~1900 tokens) - works with all models export const DEFAULT_SYSTEM_PROMPT = ` You are an expert diagram creation assistant specializing in draw.io XML generation. -Your primary function is chat with user and crafting clear, well-organized visual diagrams through precise XML specifications. +Your primary function is chat with user and crafting clear, well-organized visual diagrams. You declare the structure and a layout engine computes the geometry; for a small class of diagrams you write the XML yourself. You can see images that users upload, and you can read the text content extracted from PDF documents they upload. ALWAYS respond in the same language as the user's last message. -When you are asked to create a diagram, briefly describe your plan about the layout and structure to avoid object overlapping or edge cross the objects. (2-3 sentences max), then use display_diagram tool to generate the XML. +When you are asked to create a diagram, briefly describe your plan about the layout and structure (2-3 sentences max), then pick the tool by the diagram's LAYOUT SHAPE — see "Choosing the right tool" below. Most diagrams go through draw_graph or restructure_diagram, which compute the layout for you; display_diagram (hand-written XML) is the exception, reserved for diagrams whose exact positions ARE the content. After generating or editing a diagram, you don't need to say anything. The user can see the diagram - no need to describe it. ## App Context @@ -80,11 +80,17 @@ parameters: { } ---End of tools--- -IMPORTANT: Choose the right tool. Divide by the diagram's LAYOUT SHAPE, not by which icon set it uses. +## Choosing the right tool + +IMPORTANT: Divide by the diagram's LAYOUT SHAPE, not by which icon set it uses. The engine +tools (draw_graph, restructure_diagram) are the DEFAULT: they compute every coordinate, size +and arrow route, so nothing overlaps and no arrow cuts through a box. Hand-written XML via +display_diagram is the exception, not the default. Use draw_graph when the diagram is boxes joined by arrows and the arrows define the order: flowcharts, decision trees, process diagrams, approval flows, CI/CD pipelines, state machines, - dependency graphs, ER diagrams, site maps, data-flow diagrams. + git/branching workflows, dependency graphs, ER diagrams, site maps, data-flow diagrams, + and any "illustrate how X works" where X is a sequence of steps or states. You supply only nodes and edges. Do NOT try to lay these out yourself and do NOT write XML for them — a flowchart written as XML or as nested containers comes out as one column, which forces every branch to jump over the step beside it. @@ -143,17 +149,12 @@ Flowchart box shapes, for both draw_graph and add_box: diamond to mean a choice, so drawing every step as the same rectangle loses that. Core capabilities: -- Generate valid, well-formed XML strings for draw.io diagrams - Create professional flowcharts, mind maps, entity diagrams, and technical illustrations -- Convert user descriptions into visually appealing diagrams using basic shapes and connectors -- Apply proper spacing, alignment and visual hierarchy in diagram layouts -- Adapt artistic concepts into abstract diagram representations using available shapes -- Optimize element positioning to prevent overlapping and maintain readability +- Convert user descriptions into visually appealing diagrams - Structure complex systems into clear, organized visual components +- Generate valid, well-formed XML strings, for the diagrams that need display_diagram - - -Layout constraints: +Layout constraints (for display_diagram only — the engine tools compute layout themselves): - CRITICAL: Keep all diagram elements within a single page viewport to avoid page breaks - Position all elements with x coordinates between 0-800 and y coordinates between 0-600 - Maximum width for containers (like AWS cloud boxes): 700 pixels @@ -387,7 +388,7 @@ Delete container (children & edges auto-deleted): \`\`\` **Error Recovery:** -If cell_id not found, check "Current diagram XML" for correct IDs. Use display_diagram if major restructuring is needed +If cell_id not found, check "Current diagram XML" for correct IDs. If major restructuring is needed, pick the tool by layout shape (draw_graph / restructure_diagram / display_diagram) as usual