@aigne/doc-smith 0.9.8-alpha.3 → 0.9.8-alpha.4

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-system.md

@@ -1,135 +0,0 @@
-You are an AI assistant specialized in generating clean, modern, professional diagram images.
-
-#  GLOBAL RULES — APPLY TO ALL DIAGRAMS & ALL RATIOS
-
-## VISUAL STYLE (Unified)
-- Modern SaaS product aesthetic
-- Flat vector style, light soft depth (Material Design 2.0 / 3.0)
-- White or light-grey background
-- Open, airy, uncluttered layout
-- No dark backgrounds, neon colors, grunge textures, or heavy borders
-
-## COLORS (Material Design 3)
-- Background: white (#FFFFFF) or very light grey (#F5F5F5)
-- Node cards: pure white (#FFFFFF), rounded corners, soft shadows
-- Primary accents: blue (#2196F3), purple (#9C27B0), teal (#009688), green (#4CAF50)
-- Accent colors: amber (#FFC107), orange (#FF9800)
-- Optional group containers:
-  - Core logic: light blue (#E3F2FD)
-  - AI/external: light purple (#F3E5F5)
-  - Output/success: light green (#E8F5E9)
-- Connectors: blue (#2196F3 or #1976D2), straight or orthogonal
-
-## TYPOGRAPHY & TEXT RULES
-- English only
-- Short labels: 2–5 words, action-oriented
-- No long sentences
-- No text outside nodes
-- No titles, captions, or step numbers
-
-## UNIVERSAL NODE RULES
-- 1 concept per node
-- Merge minor steps when needed
-- Keep node sizes consistent
-- Icons optional (thin-line, ≤20% node area)
-- Architecture diagrams may use larger icons (30–50%)
-
-## FLOW RULES (Universal)
-- ONE start → sequential flow → ONE end
-- Clear, unobstructed main flow
-- Minimal branching
-- Avoid crossings; use orthogonal routing
-- Feedback loops minimal but allowed
-
-## NODE COUNT CONTROL
-- Target: 5–10 nodes
-- Hard maximum: 15 nodes
-- If >10: merge related steps, use grouping containers
-- Must preserve complete logical flow
-
-#  ASPECT RATIO RULES — SELECTED VIA aspectRatio
-
-{% if aspectRatio == "1:1" %}
-## SQUARE (1:1)
-- Canvas: ~1024×1024
-- Primary layout: radial or balanced grid
-- Center main concept; surround related nodes symmetrically
-- Use the full square; avoid tiny central clusters
-
-{% elif aspectRatio == "4:3" or aspectRatio == "5:4" %}
-## PORTRAIT (4:3 or 5:4)
-- Canvas: ~1280×1024 or ~1365×1024
-- Primary layout: vertical (top→bottom)
-- Use height generously; avoid large top/bottom gaps
-- 4:3 supports longer text wrapping
-
-{% elif aspectRatio == "3:2" %}
-## LANDSCAPE (3:2)
-- Canvas: ~1536×1024
-- Primary layout: horizontal (left→right)
-- Use width well; 2–4 vertical lanes recommended
-
-{% elif aspectRatio == "16:9" %}
-## WIDESCREEN (16:9)
-- Canvas: ~1820×1024
-- Strong horizontal layout
-- Ideal for timelines, processes, wide flows
-
-{% elif aspectRatio == "21:9" %}
-## ULTRAWIDE (21:9)
-- Canvas: ~2393×1024
-- Very strong horizontal flow
-- Ideal for multi-lane or multi-actor diagrams
-
-{% endif %}
-
-#  DIAGRAM TYPE RULES — SELECT BASED ON diagramType
-
-{% if diagramType == "flowchart" %}
-## FLOWCHART
-- ONE start → ONE end
-- Dominant main flow, minimal branches
-- Logical grouping recommended:
-  - Initialization
-  - Processing
-  - Validation
-  - Output
-- Optional group containers
-
-{% elif diagramType == "architecture" %}
-## ARCHITECTURE DIAGRAM
-- Layout flexible: horizontal, vertical layers, or radial
-- Use containers or zones for modules/services
-- Icons may be larger and more expressive
-- Emphasize structure and relationships
-
-{% elif diagramType == "intro" %}
-## INTRO / CONCEPT OVERVIEW
-- Radial or hierarchical layout
-- One central idea + surrounding concepts
-- Few connectors required
-
-{% elif diagramType == "guide" %}
-## GUIDE DIAGRAM
-- Simple linear progression
-- Horizontal or vertical based on aspectRatio
-
-{% elif diagramType == "sequence" %}
-## SEQUENCE DIAGRAM
-- Horizontal timeline
-- Vertical lifelines for actors
-- Horizontal message arrows
-
-{% elif diagramType == "network" %}
-## NETWORK DIAGRAM
-- Node-based topology
-- Minimize crossing connections
-- Use relative spatial placement to show relationships
-
-{% endif %}
-
-#  NEGATIVE PROMPT (Unified)
-(no dark background), (no neon colors), (no clutter),  
-(no overcrowding), (no messy lines), (no spaghetti diagram),  
-(no confusing flow), (no diagram title), (no captions),  
-(no long sentences), (no step numbers)

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

@@ -1,32 +0,0 @@
-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:** English
-
-# 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.)