@aigne/doc-smith 0.9.10 → 0.9.11-beta

package/prompts/detail/custom/custom-components/x-cards-usage-rules.md

@@ -1,83 +0,0 @@
-<x-card-usage-rules>
-## XCard Usage Rules
-
-XCards is multiple `<x-card>` container, suitable for displaying multiple links using a card list format, providing a richer and more visually appealing presentation.
-
-### Attributes
-
-- `data-columns` (required): must be an integer ≥ 2; no upper bound.
-
-### Children
-
-- Must contain multiple `<x-card>` elements internally.
-
-### Usage Rules
-
-- **Visual Consistency**: All `<x-card>` elements within the same `<x-cards>` must maintain visual consistency:
-  - It's recommended to always provide data-icon for each card.
-  - Or all cards should have data-image.
-  - Avoid mixing (some with icons, some with only images).
-
-### Good Examples
-
-- Example 1: Two-column cards with images
-  ```md
-  <x-cards data-columns="2">
-    <x-card data-title="Card A" data-image="https://picsum.photos/id/10/300/300">Content A</x-card>
-    <x-card data-title="Card B" data-image="https://picsum.photos/id/11/300/300">Content B</x-card>
-  </x-cards>
-  ```
-
-- Example 2: Four-column cards with icons
-  ```md
-  <x-cards data-columns="4">
-    <x-card data-title="Feature 1" data-icon="lucide:rocket">Description of Feature 1.</x-card>
-    <x-card data-title="Feature 2" data-icon="lucide:bolt">Description of Feature 2.</x-card>
-    <x-card data-title="Feature 3" data-icon="material-symbols:rocket-outline">Description of Feature 3.</x-card>
-    <x-card data-title="Feature 4" data-icon="lucide:star">Description of Feature 4.</x-card>
-  </x-cards>
-  ```
-
-- Example 3: Replace markdown format multiple links
-  ```md
-  For more detailed information on specific features, please refer to the following sections:
-
-  <x-cards data-columns="3">
-    <x-card data-title="Using Discussions" data-href="/discussions">Introduce how to use discussions</x-card>
-    <x-card data-title="Using the Blog" data-href="/blog">Introduce how to use the Blog</x-card>
-    <x-card data-title="Using Chat" data-href="/chat">Introduce how to use Chat</x-card>
-  </x-cards>
-  ```
-
-### Bad Examples
-
-- Example 1: Using a single-column layout (`data-columns="1"`) is not allowed
-  ```md
-  <x-cards data-columns="1">
-    <x-card data-title="Feature 1" data-icon="lucide:rocket">Description of Feature 1.</x-card>
-    <x-card data-title="Feature 2" data-icon="lucide:bolt">Description of Feature 2.</x-card>
-  </x-cards>
-  ```
-
-- Example 2: Contains only one `<x-card>` (must include multiple cards)
-  ```md
-  <x-cards data-columns="2">
-    <x-card data-title="Card A" data-image="https://picsum.photos/id/10/300/300">Content A</x-card>
-  </x-cards>
-  ```
-
-- Example 3: Markdown format multiple links
-  ```md
-  For more detailed information on specific features, please refer to the following sections:
-  - [Using Discussions](./discussions.md)
-  - [Using the Blog](./blog.md)
-  - [Using Chat](./chat.md)
-  ```
-
-- Example 4: Missing `data-columns` attribute (required)
-  <x-cards>
-    <x-card data-title="Feature 1" data-icon="lucide:rocket">Description of Feature 1.</x-card>
-    <x-card data-title="Feature 2" data-icon="lucide:bolt">Description of Feature 2.</x-card>
-  </x-cards>
-  
-</x-card-usage-rules>

package/prompts/detail/custom/custom-components/x-field-desc-usage-rules.md

@@ -1,120 +0,0 @@
-<x-field-desc-usage-rules>
-## XFieldDesc Usage Rules
-
-XFieldDesc is rich field description. Used to provide rich text descriptions for `<x-field>` elements, supporting inline markdown formatting for enhanced readability.
-
-### Attributes
-
-- `markdown` (required): **MUST** be set to "markdown" . This attribute is mandatory and cannot be omitted
-  - **Validation**: `<x-field-desc>` without `markdown` attribute will be rejected
-
-### Children
-
-- Supports **bold text**, `inline code`, _italic text_, and other inline markdown
-- Description text must be provided as child content of `<x-field-desc>`, not as the value of the `markdown` attribute
-- **Inline Markdown Only**: Allow only inline Markdown (e.g., `**bold**`, *italic*, `inline code`); block elements like code blocks, headings, lists, or tables are **not allowed**.
-
-### Usage Rules
-
-- **Parent Requirement**: Must be child of `<x-field>`: `<x-field-desc>` can only appear as a child element of `<x-field>` components
-- **Avoid Redundant Information**: Do not repeat information in `<x-field-desc>` that is already expressed by the parent `<x-field>` attributes. Specifically:
-  - **Required Status**: Do not mention "required" or "optional" in descriptions since `data-required` attribute already indicates this
-  - **Default Values**: Do not repeat default values in descriptions since `data-default` attribute already shows this
-  - **Deprecated Status**: Do not mention "deprecated" in descriptions since `data-deprecated` attribute already indicates this
-  - Focus descriptions on the field's purpose, format, constraints, example values, and usage guidance instead
-
-### Good Examples
-
-- Example 1: Basic markdown description
-  ```md
-  <x-field-desc markdown>Your **API key** for authentication. Generate one from the `Settings > API Keys` section. Keep it secure and never expose it in client-side code.</x-field-desc>
-  ```
-
-- Example 2: Description with inline code
-  ```md
-  <x-field-desc markdown>**JWT token** containing user identity and permissions. Expires in `24 hours` by default. Use the `refresh_token` to obtain a new one.</x-field-desc>
-  ```
-
-### Bad Examples
-
-- Example 1: Missing markdown attribute (violates "markdown attribute required" rule)
-  ```md
-  <x-field data-name="api_key" data-type="string" data-required="true">
-    <x-field-desc>Your **API key** for authentication.</x-field-desc>
-  </x-field>
-  ```
-
-- Example 2: Incorrect markdown attribute usage (violates "markdown attribute format" rule)
-  ```md
-  <x-field data-name="api_key" data-type="string" data-required="true">
-    <x-field-desc markdown="Your **API key** for authentication."></x-field-desc>
-  </x-field>
-  ```
-
-- Example 3: Using self-closing tag (violates "opening/closing tags format" rule)
-  ```md
-  <x-field data-name="user_id" data-type="string" data-required="true">
-    <x-field-desc markdown />
-  </x-field>
-  ```
-
-- Example 4: Containing block-level elements (violates "Inline Content Only" rule)
-  ````md
-  <x-field data-name="config" data-type="object" data-required="true">
-    <x-field-desc markdown>
-      **Configuration settings** for the application.
-      
-      ## Important Notes
-      - Set debug to true for development
-      - Use production database in production
-      
-      ```javascript
-      const config = { debug: true };
-      ```
-    </x-field-desc>
-  </x-field>
-  ````
-
-- Example 5: Used outside of x-field component (violates "Parent Requirement" rule)
-  ```md
-  <x-field-desc markdown>This description is not inside an x-field component.</x-field-desc>
-  ```
-
-- Example 6: Used as child of other components (violates "Parent Requirement" rule)
-  ```md
-  <x-field-group>
-    <x-field data-name="name" data-type="string" data-required="true" data-desc="User name"></x-field>
-    <x-field-desc markdown>This description is not inside an x-field component.</x-field-desc>
-  </x-field-group>
-  ```
-
-- Example 7: Redundant required information in description (violates "Avoid Redundant Information" rule)
-  ```md
-  <x-field-group>
-    <x-field data-name="api_key" data-type="string" data-required="true">
-      <x-field-desc markdown>Your **API key** for authentication. **This field is required.**</x-field-desc>
-    </x-field>
-    <x-field data-name="timeout" data-type="number" data-required="false" data-default="5000">
-      <x-field-desc markdown>Request timeout in milliseconds. **Optional**, defaults to `5000`.</x-field-desc>
-    </x-field>
-    <x-field data-name="old_api" data-type="string" data-deprecated="true">
-      <x-field-desc markdown>Old API endpoint. **This field is deprecated.**</x-field-desc>
-    </x-field>
-  </x-field-group>
-  ```
-  **Correct approach:**
-  ```md
-  <x-field-group>
-    <x-field data-name="api_key" data-type="string" data-required="true">
-      <x-field-desc markdown>Your **API key** for authentication. Generate one from the `Settings > API Keys` section.</x-field-desc>
-    </x-field>
-    <x-field data-name="timeout" data-type="number" data-required="false" data-default="5000">
-      <x-field-desc markdown>Request timeout in milliseconds.</x-field-desc>
-    </x-field>
-    <x-field data-name="old_api" data-type="string" data-deprecated="true">
-      <x-field-desc markdown>Old API endpoint. Use the new endpoint instead.</x-field-desc>
-    </x-field>
-  </x-field-group>
-  ```
-
-</x-field-desc-usage-rules>

package/prompts/detail/custom/custom-components/x-field-group-usage-rules.md

@@ -1,80 +0,0 @@
-<x-field-group-usage-rules>
-## XFieldGroup Usage Rules
-
-XFieldGroup is `<x-field>` grouping container. Used to group multiple related `<x-field>` elements at the top level, indicating they belong to the same object or context. This provides better organization and visual grouping for related parameters.
-
-### Attributes
-
-- No attributes required
-
-### Children
-
-- Only `<x-field>` elements are allowed as children
-
-### Usage Rules
-
-- **Top-Level Only**: Used only at the top level for grouping related `<x-field>` elements. Cannot be nested inside other `<x-field>` or `<x-field-group>` elements
-- **Structured Data Only**: Use `<x-field-group>` for fields **other than simple types** (`string`, `number`, `boolean`, `symbol`), e.g., Properties, Context, Parameters, Return values. For simple-type fields, use plain Markdown text.
-
-### Good Examples
-
-- Example 1: Product information fields
-  ```md
-  <x-field-group>
-    <x-field data-name="name" data-type="string" data-required="true" data-desc="The name of the product."></x-field>
-    <x-field data-name="description" data-type="string" data-required="false" data-desc="An optional description for the product."></x-field>
-    <x-field data-name="type" data-type="string" data-required="false" data-desc="The type of product (e.g., 'service', 'good')."></x-field>
-    <x-field data-name="price" data-type="number" data-required="true" data-default="0">
-      <x-field-desc markdown>Product price in **USD**. Must be a positive number with up to 2 decimal places.</x-field-desc>
-    </x-field>
-  </x-field-group>
-  ```
-
-### Bad Examples
-
-- Example 1: Nested inside x-field component (violates "Top-Level Only" rule)
-  ```md
-  <x-field data-name="user" data-type="object" data-required="true">
-    <x-field-group>
-      <x-field data-name="name" data-type="string" data-required="true" data-desc="User name"></x-field>
-      <x-field data-name="email" data-type="string" data-required="true" data-desc="User email"></x-field>
-    </x-field-group>
-  </x-field>
-  ```
-
-- Example 2: Nested inside another x-field-group (violates "Top-Level Only" rule)
-  ```md
-  <x-field-group>
-    <x-field data-name="user" data-type="object" data-required="true" data-desc="User information"></x-field>
-    <x-field-group>
-      <x-field data-name="name" data-type="string" data-required="true" data-desc="User name"></x-field>
-      <x-field data-name="email" data-type="string" data-required="true" data-desc="User email"></x-field>
-    </x-field-group>
-  </x-field-group>
-  ```
-
-- Example 3: Containing non-x-field elements (violates "Only x-field elements allowed" rule)
-  ```md
-  <x-field-group>
-    <x-field data-name="name" data-type="string" data-required="true" data-desc="User name"></x-field>
-    <div>Additional information</div>
-    <x-field data-name="email" data-type="string" data-required="true" data-desc="User email"></x-field>
-  </x-field-group>
-  ```
-
-- Example 4: Empty x-field-group (violates "Must contain x-field elements" rule)
-  ```md
-  <x-field-group>
-  </x-field-group>
-  ```
-
-- Example 5: Using x-field-group for simple-type (violates "Structured Data Only" rule)
-  ```md
-  ### appName
-
-  <x-field-group>
-    <x-field data-name="appName" data-type="string" data-required="true" data-desc="specifies the name of the application"></x-field>
-  </x-field-group>
-  ```
-
-</x-field-group-usage-rules>

package/prompts/detail/custom/custom-components/x-field-usage-rules.md

@@ -1,189 +0,0 @@
-<x-field-usage-rules>
-## XField Usage Rules
-
-XField is structured data field, suitable for displaying API parameters, return values, context data, and any structured data with metadata in a clean, organized format. Supports nested structures for complex data types.
-
-### Attributes
-
-- `data-name` (optional): The name of the field/parameter
-- `data-type` (optional): The data type of the field (e.g., "string", "number", "boolean", "symbol", "object", "array", "function")
-- `data-default` (optional): Default value for the field
-- `data-required` (optional): Whether the field is required ("true" or "false")
-- `data-deprecated` (optional): Whether the field is deprecated ("true" or "false")
-- `data-desc` (optional): Simple description of the field. Do not use any Markdown syntax (see `<markdown_syntax_rules>` for the full list).
-
-### Children
-
-- For simple types (string, number, boolean): children can be empty or contain exactly one `<x-field-desc>` element
-- For complex types (object, array), children contain nested `<x-field>` elements and optionally one `<x-field-desc>` element
-
-### Usage Rules
-
-- **Opening/Closing Tags Format**: `<x-field ...></x-field>` for all types
-- **Maximum Nesting Depth**: 5 levels (to avoid overly complex structures)
-- **Description Mutually Exclusive**: Use either `data-desc` attribute OR `<x-field-desc>` element, not both
-- **Single Description Rule**: Only one `<x-field-desc>` element per `<x-field>` is allowed
-- **Grouping Requirement**: Wrap the outermost `<x-field>` elements with `<x-field-group>`, even if there's only one `<x-field>` element
-- **Recursive Structure**: Use recursive `<x-field>` structures to fully express complex object type hierarchies, decomposing all nested properties into more fundamental types
-- **Fixed Value Fields**: For fields that accept a limited set of predefined values (including enums, constants, or fixed strings), use `<x-field>` with the base data type (e.g., "string", "number") in the `data-type` attribute, and list all possible values in the description.
-- **Function-Type Fields**: For fields with `data-type="function"`, nest `<x-field>` elements for parameters (`data-name="parameters"`) and return value (`data-name="returnValue"`) **whenever their types are available**.
-
-### Good Examples
-
-- Example 1: Simple field with all attributes
-  ```md
-  ### Returns
-
-  <x-field-group>
-    <x-field data-name="user_id" data-type="string" data-default="u0911" data-required="true" data-deprecated="true" data-desc="Unique identifier for the user. Must be a valid UUID v4 format."></x-field>
-  </x-field-group>
-  ```
-
-- Example 2: Field with markdown description
-  ```md
-  ### Context
-
-  <x-field-group>
-    <x-field data-name="api_key" data-type="string" data-required="true">
-      <x-field-desc markdown>Your **API key** for authentication. Generate one from the `Settings > API Keys` section. Keep it secure and never expose it in client-side code.</x-field-desc>
-    </x-field>
-  </x-field-group>
-  ```
-
-- Example 3: Nested object structure
-  ```md
-  ### Properties
-
-  <x-field-group>
-    <x-field data-name="session" data-type="object" data-required="true">
-      <x-field-desc markdown>Contains all **authentication** and **authorization** data for the current user session. This object is automatically populated after successful login.</x-field-desc>
-      <x-field data-name="user" data-type="object" data-required="true" data-desc="User basic information">
-        <x-field data-name="name" data-type="string" data-required="true" data-default="John Doe" data-desc="User name"></x-field>
-        <x-field data-name="email" data-type="string" data-required="true" data-default="john.doe@example.com">
-            <x-field-desc markdown>Primary email address used for **login** and **notifications**. Must be a valid email format.</x-field-desc>
-        </x-field>
-        <x-field data-name="avatar" data-type="string" data-required="false" data-default="https://example.com/avatars/john-doe.jpg" data-desc="User avatar URL"></x-field>
-      </x-field>
-      <x-field data-name="permissions" data-type="array" data-required="true" data-default='["read", "write", "admin"]'>
-        <x-field-desc markdown>Array of **permission strings** that determine what actions the user can perform. Common values: `"read"`, `"write"`, `"admin"`, `"delete"`.</x-field-desc>
-      </x-field>
-    </x-field>
-  </x-field-group>
-  ```
-
-- Example 4: Multiple fields for Parameters
-  ```md
-  ### Parameters
-
-  <x-field-group>
-    <x-field data-name="user_id" data-type="string" data-required="true" data-desc="Unique identifier for the user. Must be a valid UUID v4 format."></x-field>
-    <x-field data-name="include_profile" data-type="boolean" data-required="false" data-default="false" data-desc="Whether to include the user's profile information in the response"></x-field>
-    <x-field data-name="options" data-type="object" data-required="false" data-desc="Additional options for the request">
-      <x-field data-name="format" data-type="string" data-required="false" data-default="json">
-        <x-field-desc>Response format: `json` or `xml`</x-field-desc>
-      </x-field>
-      <x-field data-name="locale" data-type="string" data-required="false" data-default="en" data-desc="Language locale for localized content"></x-field>
-    </x-field>
-  </x-field-group>
-  ```
-
-- Example 5: Enum values with base type and description
-  ```md
-  ### Status
-
-  <x-field-group>
-    <x-field data-name="status" data-type="string" data-required="true" data-default="pending" data-desc="Current status of the request. Possible values: 'pending', 'processing', 'completed', 'failed'"></x-field>
-    <x-field data-name="priority" data-type="number" data-required="false" data-default="1">
-      <x-field-desc markdown>Priority level for the task. **Valid values**: `1` (low), `2` (medium), `3` (high), `4` (urgent)</x-field-desc>
-    </x-field>
-  </x-field-group>
-  ```
-
-- Example 6: Function type field with nested parameters and return value
-  ```md
-  ### API Methods
-
-  <x-field-group>
-    <x-field data-name="authenticate" data-type="function" data-required="true" data-desc="Authenticates a user with email and password">
-      <x-field data-name="parameters" data-type="object" data-desc="Function parameters">
-        <x-field data-name="email" data-type="string" data-required="true" data-desc="User's email address"></x-field>
-        <x-field data-name="password" data-type="string" data-required="true" data-desc="User's password"></x-field>
-        <x-field data-name="rememberMe" data-type="boolean" data-required="false" data-default="false" data-desc="Whether to keep user logged in"></x-field>
-      </x-field>
-      <x-field data-name="returnValue" data-type="object" data-desc="Function return value">
-        <x-field data-name="success" data-type="boolean" data-required="true" data-desc="Whether authentication was successful"></x-field>
-        <x-field data-name="token" data-type="string" data-required="false" data-desc="JWT token if authentication successful"></x-field>
-        <x-field data-name="user" data-type="object" data-required="false" data-desc="User information if authentication successful">
-          <x-field data-name="id" data-type="string" data-required="true" data-desc="User ID"></x-field>
-          <x-field data-name="name" data-type="string" data-required="true" data-desc="User's display name"></x-field>
-          <x-field data-name="email" data-type="string" data-required="true" data-desc="User's email address"></x-field>
-        </x-field>
-      </x-field>
-    </x-field>
-  </x-field-group>
-  ```
-
-### Bad Examples
-
-- Example 1: Using self-closing tag (violates "Opening/Closing Tags Format" rule)
-  ```md
-  <x-field-group>
-    <x-field data-name="user_id" data-type="string" data-required="true" data-desc="User identifier" />
-  </x-field-group>
-  ```
-
-- Example 2: Using both `data-desc` and `<x-field-desc>` (violates "Description Mutually Exclusive" rule)
-  ```md
-  <x-field-group>
-    <x-field data-name="api_key" data-type="string" data-required="true" data-desc="API key for authentication">
-      <x-field-desc markdown>Your **API key** for authentication. Keep it secure and never expose it.</x-field-desc>
-    </x-field>
-  </x-field-group>
-  ```
-
-- Example 3: Using multiple `<x-field-desc>` elements (violates "Single Description Rule")
-  ```md
-  <x-field-group>
-    <x-field data-name="config" data-type="object" data-required="true">
-      <x-field-desc markdown>Configuration object for the application.</x-field-desc>
-      <x-field-desc markdown>Contains all runtime settings and preferences.</x-field-desc>
-    </x-field>
-  </x-field-group>
-  ```
-
-- Example 4: Nesting other child elements (violates "Children" rule)
-  ```md
-  <x-field-group>
-    <x-field data-name="user" data-type="object" data-required="true">
-      <div>User information</div>
-      <x-field data-name="name" data-type="string" data-required="true" data-desc="User name"></x-field>
-    </x-field>
-  </x-field-group>
-  ```
-
-- Example 5: Missing x-field-group wrapper (violates "Grouping Requirement" rule)
-  ```md
-  <x-field data-name="apiConfig" data-type="object" data-required="true" data-desc="API configuration object">
-    <x-field data-name="baseUrl" data-type="string" data-required="true" data-desc="Base URL for API calls"></x-field>
-    <x-field data-name="timeout" data-type="number" data-required="false" data-default="5000" data-desc="Request timeout in milliseconds"></x-field>
-  </x-field>
-  ```
-
-- Example 6: Exceeding maximum nesting depth (violates "Maximum Nesting Depth" rule)
-  ```md
-  <x-field-group>
-    <x-field data-name="level1" data-type="object" data-required="true">
-      <x-field data-name="level2" data-type="object" data-required="true">
-        <x-field data-name="level3" data-type="object" data-required="true">
-          <x-field data-name="level4" data-type="object" data-required="true">
-            <x-field data-name="level5" data-type="object" data-required="true">
-              <x-field data-name="level6" data-type="string" data-required="true" data-desc="Too deep nesting"></x-field>
-            </x-field>
-          </x-field>
-        </x-field>
-      </x-field>
-    </x-field>
-  </x-field-group>
-  ```
-
-</x-field-usage-rules>

package/prompts/detail/custom/custom-components-usage-rules.md

@@ -1,18 +0,0 @@
-<custom_components_usage_rules>
-## Custom Components Usage Rules
-
-When generating document details, you can use the following custom components at appropriate locations based on their descriptions and functionality to enhance document presentation:
-
-### XCard Relate Component Usage Rules
-{% include "./custom-components/x-card-usage-rules.md" %}
-{% include "./custom-components/x-cards-usage-rules.md" %}
-
-### XField Relate Component Usage Rules
-
-XField-related components are designed to enhance API-related documentation and should be used only for API-type documents. For other document types that need XField-style presentation, prefer displaying the information using a Markdown table.
-
-{% include "./custom-components/x-field-usage-rules.md" %}
-{% include "./custom-components/x-field-desc-usage-rules.md" %}
-{% include "./custom-components/x-field-group-usage-rules.md" %}
-
-</custom_components_usage_rules>

package/prompts/detail/diagram/generate-image-user.md

@@ -1,81 +0,0 @@
-{% if useImageToImage and existingImage %}
-# Image-to-Image Generation Mode
-
-Your task is to **update an existing diagram** based on the current document content and user feedback.
-
-**CRITICAL INSTRUCTIONS:**
-1. **Use the existing image as the primary reference** - maintain its overall structure, layout, and visual style
-2. **Analyze the document content** to understand what changes are needed
-3. **Apply user feedback** to modify the diagram appropriately
-4. **Maintain visual consistency** - keep the same style, color scheme, and general layout unless explicitly requested to change
-5. **Make maximum changes** where needed - update content, add/remove elements, adjust relationships based on the document
-6. **Preserve what works** - keep elements that are still accurate and relevant
-
-**Task Parameters:**
-- **Diagram Type:** {{ diagramType }}
-- **Visual Style:** {{ diagramStyle }} (maintain consistency with existing image unless feedback requests change)
-- **Aspect Ratio:** {{ aspectRatio }}
-- **Language:** {{ locale }}
-
-**Existing Diagram:**
-[The existing diagram image is provided as input to the model]
-
-**Document Content:**
-{% if documentSummary %}
-{{ documentSummary }}
-{% else %}
-{{ documentContent }}
-{% endif %}
-
-**User Feedback:**
-{{ feedback if feedback else "Update the diagram to match the current document content." }}
-
-**Your responsibilities:**
-1. Analyze the existing diagram structure, style, and layout
-2. Review the document content to identify what needs to be updated
-3. Apply user feedback to modify the diagram
-4. Maintain visual consistency with the original design where appropriate
-5. Update the diagram to accurately reflect the current document content
-6. Make necessary changes while preserving the overall visual style and structure
-
-**Style Consistency:**
-- Keep the same visual style as the existing image unless user feedback explicitly requests a style change
-- Maintain color scheme, node shapes, and layout patterns
-- Preserve the overall aesthetic and design language
-
-{% else %}
-# Standard Text-to-Image Generation Mode
-
-Your task is to create a professional diagram image based on the document content below.
-
-Please follow **all global rules, styles, aspect ratio logic, and diagram-type rules** defined in the system prompt.
-
-# Task Parameters:
-- **Diagram Type:** {{ diagramType }}
-- **Visual Style:** {{ diagramStyle }}
-- **Aspect Ratio:** {{ aspectRatio }}
-- **Language:** {{ locale }}
-
-# Your responsibilities:
-1. Read and analyze the document content.
-2. Extract key concepts, steps, relationships, or flow sequences.
-3. Generate a diagram that accurately represents these elements.
-4. Apply all rules from the system prompt.
-5. Labels must be concise (2–5 words).
-6. No titles or explanations outside nodes.
-7. Maintain clarity, structure, and proper layout based on the aspect ratio.
-
-# Document Content:
-
-Now analyze the following document content to understand what should be drawn:
-
-{% if documentSummary %}
-**Document Content (comprehensive summary for diagram generation):**
-{{ documentSummary }}
-{% else %}
-**Document Content (full original content):**
-{{ documentContent }}
-{% endif %}
-
-(Use this content to determine node structure, relationships, and flow.)
-{% endif %}

package/prompts/detail/diagram/guide.md

@@ -1,29 +0,0 @@
-<diagram_generation_guide>
-
-1. Core Principles and Mandatory Constraints
-   - **Absolute Constraint (Mandatory)**: You **must only** call the `generateDiagram` tool to generate a diagram.
-     - **Do not** generate mermaid diagram.
-     - **Do not** generate base64 image.
-     - **Do not** generate fake image url.
-   - **Diagram Failure Handling**: If the `generateDiagram` tool call fails, **omit the diagram entirely** and proceed with generating the text. **Do not** attempt to describe the diagram in words as a replacement.
-
-2. Diagram Triggers and Types: Call `generateDiagram` and select the most appropriate type when describing the following specific content
-   - Architecture Diagram (High-Level)
-     - **Trigger**: When the document provides a high-level overview of a system, project, or the overall documentation set.
-     - **Content**: Must illustrate the main components, their relationships, and the overall structure.
-   - Structural Diagram (Module-Level)
-     - **Trigger**: When generating the introductory document for a major section or module.
-     - **Content**: Must show the key sub-components, files, or core concepts within that specific module.
-   - Process and Interaction Diagrams (Detailed)
-     - **Trigger**: When the document describes a workflow, a sequence of events, user interactions, or data flow.
-     - **Diagram Type Selection**:
-       - **Flowchart**: Use for step-by-step processes, algorithms, or decision-making logic.
-       - **Sequence Diagram**: Use for time-ordered interactions between different components or actors (e.g., API calls).
-3. Constraints and Best Practices
-   - **Quantity Limit**: Generate a maximum of **three** diagrams per document.
-   - **Relevance**: Ensure every diagram **directly** illustrates a concept explained in the surrounding text. Avoid generating diagrams for simple concepts that are easily understood through text alone.
-4. Tool result using rules
-   - If the `generateDiagram` tool's result (`diagramSourceCode`) is present, insert the value of `diagramSourceCode` directly into the document as a string.
-   - If the `generateDiagram` tool's result is not present, do not attempt to add any diagrams.
-
-</diagram_generation_guide>