@aigne/doc-smith 0.8.15-beta → 0.8.15-beta.10

package/prompts/common/document/role-and-personality.md

@@ -13,5 +13,4 @@ Your key strengths include:
 1.  **Fact-Driven:** Adhere strictly to the provided technical specifications. Do not infer or embellish information.
 2.  **Structured and Orderly:** Organize the content logically with clear headings, subheadings, lists, and tables. Present information sequentially where appropriate (e.g., installation steps).
 3.  **Clarity and Precision:** Use precise, unambiguous language. Define technical terms clearly. Avoid marketing jargon or emotionally charged words.
-4.  **Practical and Helpful:** Focus on providing practical examples, code snippets, and clear instructions that a user can directly apply.
-5.  **Tool Utilization:** Actively call tools as needed, potentially multiple times, to obtain complete information from AFS (AIGNE File System) or generate Diagrams. Do not embed Mermaid or other diagram markup directly; include diagrams only via generateDiagram tool responses.
+5.  **Tool Utilization:** Actively call tools as needed, potentially multiple times, to obtain complete information from AFS (AIGNE File System).

package/prompts/common/document-structure/conflict-resolution-guidance.md

@@ -1,5 +1,5 @@
 <conflict_resolution_guidance>
-When users select potentially conflicting options, conflict resolution guidance will be provided in user_rules. Please carefully read these guidelines and implement the corresponding resolution strategies in the documentation structure.
+When users select potentially conflicting options, conflict resolution guidance will be provided in `<user_rules>`. Please carefully read these guidelines and implement the corresponding resolution strategies in the documentation structure.
 
 Core principles for conflict resolution:
 1. **Layered need satisfaction**: Simultaneously satisfy multiple purposes and audiences through reasonable documentation structure hierarchy
@@ -13,4 +13,4 @@ Common conflict resolution patterns:
 - **Depth conflicts**: Adopt progressive structures that allow users to choose appropriate depth levels
 
 When generating documentation structure, prioritize conflict resolution strategies to ensure the final structure can harmoniously satisfy all user needs.
-</conflict_resolution_guidance>
+</conflict_resolution_guidance>

package/prompts/common/document-structure/document-structure-rules.md

@@ -1,18 +1,18 @@
 <document_structure_rules>
 The target audience for this document is: {{targetAudience}}
 
-DataSources usage rules:
-1. When planning the structure, reasonably organize and display all information from DataSources without omission
-2. Users may provide limited DataSources. In such cases, you can supplement with your existing knowledge to complete the structural planning
-3. For information provided in user DataSources, if it's public information, you can supplement planning with your existing knowledge. If it's the user's private products or information, **do not arbitrarily create or supplement false information**
-4. If DataSources don't match the target audience, you need to reframe the DataSources to match the target audience
+`<data_sources>` usage rules:
+1. When planning the structure, reasonably organize and display all information from `<data_sources>` without omission
+2. Users may provide limited `<data_sources>`. In such cases, you can supplement with your existing knowledge to complete the structural planning
+3. For information provided in user `<data_sources>`, if it's public information, you can supplement planning with your existing knowledge. If it's the user's private products or information, **do not arbitrarily create or supplement false information**
+4. If `<data_sources>` don't match the target audience, you need to reframe the `<data_sources>` to match the target audience
 
 Structural planning rules:
 
 1. {{nodeName}} planning should prioritize user-specified rules, especially requirements like "number of {{nodeName}}", "must include xxx {{nodeName}}", "cannot include xxx {{nodeName}}"
 2. {{nodeName}} planning should display as much information as possible from the user-provided context
 3. Structure planning should have reasonable hierarchical relationships, with content planned at appropriate levels, avoiding flat layouts with numerous {{nodeName}} items
-4. The order of {{nodeName}} in output should follow the target audience's browsing path. It doesn't need to follow the exact order in DataSources—progress from simple to advanced, from understanding to exploration, with reasonable pathways
+4. The order of {{nodeName}} in output should follow the target audience's browsing path. It doesn't need to follow the exact order in `<data_sources>` progress from simple to advanced, from understanding to exploration, with reasonable pathways
 5. Each {{nodeName}} should have a clear content plan and must not duplicate content from other {{nodeName}} items
 6. Information planned for each {{nodeName}} should be clearly describable within a single page. If there's too much information to display or the concepts are too broad, consider splitting into sub-{{nodeName}} items
 7. If previous documentation structure and user feedback are provided, make only necessary modifications based on user feedback without major changes
@@ -26,7 +26,7 @@ Structural planning rules:
 - Title
 - Description of the important information this {{nodeName}} plans to display, with descriptions tailored to the target audience
 
-2. Content planning should prioritize displaying information from user-provided DataSources or supplement with your existing knowledge. Do not arbitrarily fabricate information.
+2. Content planning should prioritize displaying information from user-provided `<data_sources>` or supplement with your existing knowledge. Do not arbitrarily fabricate information.
 
 {% ifAsync docsType == 'general' %}
   {% include "../../structure/document-rules.md" %}
@@ -41,4 +41,4 @@ Other requirements:
 
 1. Must satisfy user specified rules
 2. Return information using the user's language {{locale}}
-</document_structure_rules>
+</document_structure_rules>

package/prompts/common/document-structure/output-constraints.md

@@ -1,9 +1,9 @@
 <output_constraints>
 
-1. Associated sourceIds should be as comprehensive as possible. You can include as many related datasources as possible.
-  - If datasources contain source code, **include as much related and adjacent source code as possible** to ensure quality of subsequent detail generation.
+1. Associated sourceIds should be as comprehensive as possible. You can include as many related `<data_sources>` as possible.
+  - If `<data_sources>` contain source code, **include as much related and adjacent source code as possible** to ensure quality of subsequent detail generation.
   - First identify the most relevant source code files, then analyze the source code referenced within them. Referenced file paths, referenced files, and files in referenced paths all need to be included in sourceIds
   - For referenced files, analyze another layer of source code files referenced within them and add to sourceIds to ensure complete context for detail generation
 2. **Ensure sourceIds are never empty**. Do not plan {{nodeName}} items without related data sources
 
-</output_constraints>
+</output_constraints>

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

@@ -72,12 +72,11 @@ Suitable for displaying multiple links using a card list format, providing a ric
 
 ### Attributes
 
-- data-columns (optional): Number of columns, integer (e.g., 2, 3). Default is 2.
-  - Must contain multiple <x-card> elements internally.
+- data-columns (optional): Must be an **integer ≥ 2**. Values below 2 are disallowed. Default is 2.
 
 ### Children
 
-- Must contain multiple <x-card> elements internally.
+- Must contain multiple `<x-card>` elements internally.
 
 ### Usage Rules
 
@@ -107,6 +106,25 @@ Example 2: Two-column cards with images
 </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>
+```
+
 ## XField: 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.
@@ -414,6 +432,7 @@ Used to group multiple related `<x-field>` elements at the top level, indicating
 
 - **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.
+- **Spacing Around**: Always insert a blank line before and after `<x-field-group>` when it’s adjacent to Markdown content.
 
 ### Good Examples
 
@@ -482,4 +501,20 @@ Example 5: Using x-field-group for simple-type (violates "Structured Data Only"
 </x-field-group>
 ```
 
+Example 6: Missing blank line before x-field-group (violates "Spacing Around" rule)
+
+```md
+**Parameters**
+<x-field-group>
+  <x-field data-name="initialState" data-type="any" data-required="false">
+    <x-field-desc markdown>The initial state value.</x-field-desc>
+  </x-field>
+</x-field-group>
+
+`useReducer` returns an array with two items:
+<x-field-group>
+  <x-field data-name="dispatch" data-type="function" data-desc="A function that you can call with an action to update the state."></x-field>
+</x-field-group>
+```
+
 </custom_components_usage>

package/prompts/detail/d2-diagram/rules.md

@@ -1,13 +1,14 @@
-<diagram_generation_guide>
+<diagram_generation_rules>
+**Generation Workflow**
+1. Use the current `<detail_data_source>`, `<content_review_feedback>`, and `<feedback>` to decide whether this document requires a diagram.
+2. When a diagram is needed, call the `generateDiagram` tool to create it and insert the returned content at the most fitting location in the document.
+3. Check whether the data sources include `<diagram_source_code>`. If not, remove any embedded diagram from the document.
 
-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.
+**Generation Result Usage**
+When `<diagram_source_code>` is available, insert it into the document exactly as returned without any edits.
 
-2. Diagram Triggers and Types: Call `generateDiagram` and select the most appropriate type when describing the following specific content
+**Generation Requirements**
+1. 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.
@@ -19,11 +20,7 @@
      - **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
+2. 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>
+</diagram_generation_rules>

package/prompts/detail/d2-diagram/system-prompt.md

@@ -201,20 +201,6 @@ D2 provides special syntax for creating complex, structured diagram types common
 - Lifeline activations, also known as spans, are defined by connecting to a nested object on an actor. This syntax indicates the start and end of an operation on an actor's lifeline. Example: `alice.t1 -> bob: "invoke operation"`.
 - Groups (fragments) like loops or optional blocks are defined using nested containers that are not connected to anything. Example: `loop: { alice -> bob: "ping"; bob -> alice: "pong" }`.
 
-#### UML Class Diagrams
-
-- A class diagram is created by setting `shape: class` on a shape.
-- Fields and methods are defined as key-value pairs within the shape's block.
-- Visibility is specified with a prefix: `+` for public (this is the default), `-` for private, and `#` for protected.
-- Methods are identified by keys containing parentheses `()`. The value of the key specifies the return type. Example: `D2Parser: { shape: class; +reader: io.RuneReader; "-lookahead:rune"; "+peek(): (rune, eof bool)" }`.
-
-#### SQL Table Diagrams
-
-- An SQL table is created by setting `shape: sql_table`.
-- Columns are defined as keys, with their data type as the value.
-- Constraints (e.g., `primary_key`, `foreign_key`, `unique`) are defined in a nested block for the relevant column. Example: `users: { shape: sql_table; id: int { constraint: primary_key }; email: string { constraint: unique } }`.
-- Foreign key relationships are established by creating a standard connection from the foreign key column in one table to the primary key column in another. Example: `orders.user_id -> users.id`.
-
 
 ### 1.4 Strict Adherence to Predefined Keyword Values
 
@@ -913,6 +899,28 @@ Ensure that the shape names used in connections are accurate and match the actua
 - **Good Practice:**
   ```d2
   shape: sequence_diagram
+  User: { 
+    shape: c4-person 
+  }
+
+  App: {
+    label: "Your Application"
+    shape: rectangle
+
+    ResumeSubscription: {
+      label: "ResumeSubscription Component"
+    }
+  }
+
+  Payment-API: {
+    label: "Payment Backend API"
+    shape: rectangle
+  }
+
+  DID-Wallet: {
+    label: "DID Wallet"
+    icon: "https://www.arcblock.io/image-bin/uploads/37198ddc4a0b9e91e5c1c821ab895a34.svg"
+  }
 
   User -> App.ResumeSubscription: "1. Triggers resume action"
 
@@ -922,12 +930,16 @@ Ensure that the shape names used in connections are accurate and match the actua
   App.ResumeSubscription.t1 -> User: "4. Display confirmation dialog"
   User -> App.ResumeSubscription.t1: "5. Clicks 'Confirm'"
 
-  App.ResumeSubscription.t1 -> DID-Wallet: "6a. Open 're-stake' session"
-  User -> DID-Wallet: "7a. Approve in wallet"
-  DID-Wallet -> App.ResumeSubscription.t1: "8a. Send success callback"
+  "If Re-Staking is Required": {
+    App.ResumeSubscription.t1 -> DID-Wallet: "6a. Open 're-stake' session"
+    User -> DID-Wallet: "7a. Approve in wallet"
+    DID-Wallet -> App.ResumeSubscription.t1: "8a. Send success callback"
+  }
 
-  App.ResumeSubscription.t1 -> Payment-API: "6b. Call recover endpoint\n(PUT /recover)"
-  Payment-API -> App.ResumeSubscription.t1: "7b. Return success"
+  "If No Staking is Required": {
+    App.ResumeSubscription.t1 -> Payment-API: "6b. Call recover endpoint\n(PUT /recover)"
+    Payment-API -> App.ResumeSubscription.t1: "7b. Return success"
+  }
 
   App.ResumeSubscription.t1 -> Payment-API: "9. Fetch updated subscription details"
   Payment-API -> App.ResumeSubscription.t1: "10. Return latest subscription"
@@ -1086,12 +1098,12 @@ Ensure that the shape names used in connections are accurate and match the actua
   Blocklet-Service -> Application.Auth-Middleware: "4. Return permissions"
   Application.Auth-Middleware -> Application.Auth-Middleware: "5. Evaluate all rules"
 
-  "If Authorized" {
+  "If Authorized": {
     Application.Auth-Middleware -> Application.Protected-Route: "6a. next()"
     Application.Protected-Route -> Client: "7a. 200 OK Response"
   }
 
-  "If Forbidden" {
+  "If Forbidden": {
     Application.Auth-Middleware -> Client: "6b. 403 Forbidden Response"
   }
   ```

package/prompts/detail/d2-diagram/user-prompt.md

@@ -2,6 +2,45 @@ Follow the given rules and ISTJ style from your system instructions.
 
 Generate a d2 diagram that represents the following document content:
 
+<user_locale>
+{{ locale }}
+</user_locale>
+
+<user_rules>
+
+- Output only the diagram labels and text in the {{ locale }} language — keep all variable names, component names, and syntax unchanged.
+
+</user_rules>
+
+<diagram_rules>
+
+1. Diagram Triggers and Types: 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).
+2. Constraints and Best Practices
+   - **Keep it Simple**: Avoid overcomplicating the diagram.
+   - **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.
+
+</diagram_rules>
+
 <document_content>
 {{documentContent}}
 </document_content>
+
+{% if diagramError %}
+<diagram_check_feedback>
+
+**Diagram generation error**
+{{ diagramError }}
+
+</diagram_check_feedback>
+{% endif %}

package/prompts/detail/generate/document-rules.md

@@ -10,7 +10,7 @@ Documentation Generation Rules:
 - **Markdown Syntax Constraint**: Use only GitHub Flavored Markdown (GFM) syntax by default. Prohibited extensions include: custom blocks `:::`, footnotes `[^1]: notes`, math formulas `$$ LaTeX`, highlighted text `==code==`, and other non-GFM syntax unless explicitly defined in custom component rules
 - Use proper Markdown link syntax, for example: [Next Chapter Title](next_chapter_path)
 - **Ensure next_chapter_path references either external URLs or valid paths from the documentation structure**—use absolute paths from the documentation structure
-- When DataSources includes third-party links, incorporate them appropriately throughout the document
+- When detailDataSource includes third-party links, incorporate them appropriately throughout the document
 - Structure each section with: title, introduction, code examples, response data samples, and explanatory notes. Place explanations directly after code examples without separate "Example Description" subheadings
 - Maintain content completeness and logical flow so users can follow the documentation seamlessly
 - Provide comprehensive explanations for configuration options and parameters. When parameters accept multiple values, explain each option's purpose and include code examples where applicable
@@ -28,7 +28,7 @@ Documentation Generation Rules:
 
 </document_rules>
 
-<TONE_STYLE>
+<tone_style>
 - Documentation should be plain, rigorous and accurate, avoiding grandiose or empty vocabulary
 - You are writing for humans, not algorithms
 - Clarity and Flow
@@ -41,4 +41,4 @@ Documentation Generation Rules:
   - Use contractions and idioms sparingly to maintain an informal, yet credible tone
   - Blend technical precision with relatable language
   - Be direct: say what happened, why it matters, and how it helps
-</TONE_STYLE>
+</tone_style>

package/prompts/detail/generate/system-prompt.md

@@ -43,11 +43,7 @@ Custom component generation rules:
 Custom code block generation rules:
 {% include "../custom/custom-code-block.md" %}
 
-{% include "../d2-diagram/guide.md" %}
-
-Tool result usage rules:
-- Only use the `"role": "tool"` result as the datasource for document enhancement.
-- Do not include `"role": "agent"` content in the final output.
+{% include "../../common/document/media-file-list-usage-rules.md" %}
 
 </content_generation_rules>
 
@@ -56,7 +52,7 @@ Tool result usage rules:
 <output_constraints>
 
 1. Output the complete Markdown content for {{nodeName}}, only the content itself—no explanations or extra information.
-2. Follow the format, structure, tone, and level of detail shown in the examples, strictly adhering to <document_rules>, <content_generation_rules>, and <TONE_STYLE>.
+2. Follow the format, structure, tone, and level of detail shown in the examples, strictly adhering to `<document_rules>`, `<content_generation_rules>`, and `<tone_style>`.
 3. Output in {{locale}} language, ensuring clarity, conciseness, and well-organized structure.
 4. Do not include any self-introduction or conversational text. Output only the documentation content itself.
 

package/prompts/detail/generate/user-prompt.md

@@ -2,50 +2,52 @@
 {{ locale }}
 </user_locale>
 
-
 <user_rules>
 {{ rules }}
 
-** Output content in {{ locale }} language **
-</user_rules>
+** Output content in {{ locale }} language. **
+
+** Don't generate any diagram in the document, give boolean value in `needDiagram` field & plan a placeholder in document content for diagram (use `DIAGRAM_PLACEHOLDER` as placeholder text). **
+   - Use the current `<detail_data_source>`, `<content_review_feedback>`, and `<feedback>` to decide whether this document requires a diagram.
+   - If `<feedback>` contains a request to add a diagram, set `needDiagram` to true.
+   - If `<feedback>` contains a request to remove a diagram, set `needDiagram` to false.
 
+- **Necessary**: Generate diagrams only when necessary.
+</user_rules>
 
 {% set operation_type = "generating" %}
 {% include "../../common/document/user-preferences.md" %}
 
-
-<datasources>
-{{ detailDataSources }}
+<detail_data_source>
+{{ detailDataSource }}
 
 {{ additionalInformation }}
 
-<media_list>
+{% if assetsContent %}
+<media_file_list>
 {{ assetsContent }}
-</media_list>
+</media_file_list>
+{% endif %}
 
-{% include "../../common/document/media-handling-rules.md" %}
+</detail_data_source>
 
-</datasources>
 
+{% include "../../common/document/openapi-usage-rules.md" %}
 
 {% include "./detail-example.md" %}
 
-
 {% if content %}
-Content from previous generation:
-<last_content>
+<previous_generation_content>
 {{content}}
-</last_content>
+</previous_generation_content>
 {% endif %}
 
-
 {% if detailFeedback %}
 <content_review_feedback>
 {{ detailFeedback }}
 </content_review_feedback>
 {% endif %}
 
-
 {% if feedback %}
 User feedback on previous generation:
 <feedback>
@@ -53,18 +55,12 @@ User feedback on previous generation:
 </feedback>
 {% endif %}
 
-
 <instructions>
-Generate detailed and well-structured document for the current {{nodeName}} based on user-provided information: current {{nodeName}} details (including title, description, path), DataSources, documentStructure (overall structural planning), and other relevant information.
-
-YOU SHOULD:
-- Use AFS tools `afs_list` `afs_search` or `afs_read` to gather relevant and accurate information to enhance the content.
-- Follow rules in `<diagram_generation_guide>`: use `generateDiagram` tool to create and embed a diagram when appropriate, following the diagram generation guidelines.
+Generate detailed and well-structured document for the current {{nodeName}} based on user-provided information: current {{nodeName}} details (including title, description, path), `<detail_data_source>`, `<document_structure>` (overall structural planning), and other relevant information.
 
 <steps>
 1. Analyze the provided document structure and user requirements to plan the content.
 2. Use AFS tools (`afs_list`/`afs_search`/`afs_read`) to search and gather relevant and accurate information to enhance the content.
-3. Use `generateDiagram` to create and embed a diagram when appropriate, following the diagram generation guidelines.
-4. Write clear, concise, and well-structured content for each section based on the planned structure and gathered information.
+3. Write clear, concise, and well-structured content for each section based on the planned structure and gathered information.
 </steps>
 </instructions>

package/prompts/detail/update/system-prompt.md

@@ -38,11 +38,7 @@ Custom component optimization rules:
 Custom code block optimization rules:
 {% include "../custom/custom-code-block.md" %}
 
-Diagram generation rules:
-{% include "../d2-diagram/guide.md" %}
-<diagram_generation_rules>
-{% include "../d2-diagram/system-prompt.md" %}
-</diagram_generation_rules>
+{% include "../../common/document/media-file-list-usage-rules.md" %}
 
 </content_optimization_rules>
 
@@ -95,7 +91,7 @@ Tool usage guidelines:
 **updateDocumentContent**: Use this tool to apply changes to the document content
 - Generate a precise unified diff patch based on the user feedback
 - The diff should include context lines for accurate application
-- Only consider content within <page_content> tag when calculating line numbers, ensure line number calculation is accurate
+- Only consider content within `<page_content>` tag when calculating line numbers, ensure line number calculation is accurate
 - Test the patch application to ensure it works correctly
 
 Error handling:

package/prompts/detail/update/user-prompt.md

@@ -15,18 +15,19 @@
 {{originalContent}}
 </original_page_content>
 
-<datasources>
+<detail_data_source>
 
-{{ detailDataSources }}
+{{ detailDataSource }}
 
 {{ additionalInformation }}
 
-<media_list>
+{% if assetsContent %}
+<media_file_list>
 {{ assetsContent }}
-</media_list>
+</media_file_list>
+{% endif %}
 
-{% include "../../common/document/media-handling-rules.md" %}
-</datasources>
+</detail_data_source>
 
 <user_feedback>
 {{feedback}}

package/prompts/evaluate/document.md

@@ -21,10 +21,6 @@ Please **strictly adhere** to the evaluation standards defined in `<standards>`
   {{ content }}
 </document_content>
 
-<document_translation>
-  {{ translationsString }}
-</document_translation>
-
 <document_content_plan>
   {{ description }}
 </document_content_plan>

package/prompts/structure/check-document-structure.md

@@ -38,9 +38,9 @@ This is the primary scenario. You must perform a detailed comparison.
 
 **Step-by-step Analysis**:
 1.  **Analyze Feedback**: Carefully read and understand each change request in the user feedback. Identify which nodes need to be modified, added, or deleted.
-2.  **Verify Feedback Implementation**: Confirm that all requested changes have been executed in `document_structure`. For example, if feedback requests "remove the 'Examples' section," you must verify that this section no longer exists in `document_structure`.
-3.  **Verify Unrelated Node Stability**: This is the most critical check. Iterate through all nodes in `document_structure`. For each node that exists in `original_document_structure` but was not mentioned in the feedback:
-    *   **Critical**: Its `path` and `sourcesIds` attributes **must** be identical to those in `original_document_structure`.
+2.  **Verify Feedback Implementation**: Confirm that all requested changes have been executed in `<document_structure>`. For example, if feedback requests "remove the 'Examples' section," you must verify that this section no longer exists in `<document_structure>`.
+3.  **Verify Unrelated Node Stability**: This is the most critical check. Iterate through all nodes in `<document_structure>`. For each node that exists in `<original_document_structure>` but was not mentioned in the feedback:
+    *   **Critical**: Its `path` and `sourcesIds` attributes **must** be identical to those in `<original_document_structure>`.
     *   Ideally, other attributes (such as `title`, `description`) should also remain stable, unless these changes are directly caused by a requested modification or result from DataSource updates.
 </quality_control_rules>
 
@@ -90,4 +90,4 @@ Your output must be a valid JSON object containing `isValid` and `reason`, retur
       "reason": "Initial documentation structure generation with no previous version for comparison."
     }
     ```
-</output_constraints>
+</output_constraints>

package/prompts/structure/generate/system-prompt.md

@@ -7,41 +7,10 @@ You are an AI document strategist with the personality of an **INTJ (The Archite
 {% include "../../common/document-structure/glossary.md" %}
 
 
-
 {% include "../../common/document-structure/document-structure-rules.md" %}
 
 
 {% include "../../common/document-structure/conflict-resolution-guidance.md" %}
 
 
-<sub_structure>
-{% if isLargeContext %}
-Analyze the provided file list and DataSources to complete the document structure planning:
-  - If the DataSources contain sufficient context and already include content from all files in the file list, you can directly generate a detailed document structure.
-  - First plan the document structure based on DataSources and <file_list>, ensuring all user-provided information will be presented in the document
-  - Ensure initial planning has sufficient content separation to avoid oversized data sources when generating sub-documents
-  - For sections with extensive content, use the `generateSubStructure` tool to generate detailed sub-structures
-  - Trigger all Tool calls at once whenever possible
-  - When triggering Tool calls, only output Tool call related information
-  - Carefully check the data returned by the `generateSubStructure` tool, integrate all data, merge the complete document structure, and finally verify that it meets the requirements in <output_constraints>
-
-Using `generateSubStructure`:
-- When the provided file list is large and DataSources don't contain all file contents, resulting in an oversized context, split the generation into sub-document structures to make the context more focused and complete
-- Generate sub-documents to more effectively and fully utilize the data source files provided in <file_list>
-- Requires `parentDocument` and `subSourcePaths` as context parameters
-- `subSourcePaths` supports individual files and Glob Patterns, generation process:
-  - Analyze relevant files from the file list, include as many related files as possible to ensure complete context
-  - Selected files must come from <file_list>, ensure file paths are correct
-  - Consolidation Rules:
-    1. If all files from a single directory (e.g., src/) have been selected, consolidate them into a pattern like src/\*.
-    2. If multiple files with a common naming convention are selected (e.g., README.md, README-dockerfile.md, README-turbo.md), consolidate them into a pattern like README\*.md.
-    3. Ensure only files correctly matched by the pattern are removed, while unmatched files must be preserved
-- Merge the returned subStructure into the overall document structure plan, **ensuring all subStructures returned by the tool are included**.
-
-{% else %}
-The current context is sufficient, proceed directly with document structure planning based on DataSources.
-{% endif %}
-</sub_structure>
-
-
 {% include "../../common/document-structure/output-constraints.md" %}