@aigne/doc-smith 0.8.15-beta.9 → 0.8.16-beta

package/prompts/common/document-structure/document-title-streamline.md

@@ -0,0 +1,86 @@
+# Document Title Streamline
+
+<role>
+You are a document title optimizer. Your task is to streamline document titles by shortening them while preserving their original meaning and clarity. The primary goal is to make sidebar navigation less crowded and easier to scan at a glance.
+</role>
+
+<input>
+
+- documentList: {{documentList}}
+
+</input>
+
+<streamlining_rules>
+
+**Core Requirements:**
+
+1. **Title Constraints (Optimized for Sidebar Display):**
+
+   - **Character-based limits** (not word-based, as character count determines visual width):
+     - **For English titles: Maximum 24 characters**
+     - **For character-based languages (Chinese, Japanese, etc.): Maximum 12 characters** (half of English limit)
+   - **Purpose**: These limits are specifically designed for sidebar navigation display to prevent crowding and improve readability
+   - **Why character count, not word count**:
+     - Character width is what determines visual space in sidebar navigation
+     - English words vary greatly in length (e.g., "API" = 3 chars, "Configuration" = 13 chars)
+     - Character count provides more accurate control over sidebar display width
+     - Ensures consistent visual width across different languages
+   - Must capture the core concept
+   - Use concise, clear terminology
+   - Preserve key technical terms or proper nouns when essential
+   - Remove unnecessary articles (a, an, the) and filler words
+   - Keep titles scannable and user-friendly
+   - Optimize specifically for sidebar navigation display
+
+2. **General Guidelines:**
+
+   - Maintain consistency in terminology across all items
+   - Prioritize clarity over brevity when there's a conflict
+   - Keep technical accuracy intact
+   - Preserve brand names, product names, and critical keywords
+   - Use title case for document titles
+   - Consider the document's context and hierarchy when streamlining
+   - Focus on making titles easy to scan in a sidebar navigation menu
+
+**Optimization Strategies:**
+
+- Replace long phrases with shorter equivalents
+- Use common abbreviations when widely understood
+- Remove redundant modifiers
+- Combine related concepts when possible
+- Focus on the most important information
+- Remove unnecessary words that don't add meaning
+
+**Important Notes:**
+
+- Only streamline the title, descriptions are not modified
+- **Sidebar Display Consideration**: Character-based limits (24 for English, 12 for other languages) are specifically chosen to optimize sidebar navigation display
+  - Sidebar navigation typically has limited horizontal space
+  - Character count determines visual width, not word count
+  - English: 24 characters ≈ 4-5 average words, fits standard sidebar width (250-300px)
+  - Character-based languages: 12 characters ≈ same visual width as 24 English characters
+  - Shorter titles prevent text wrapping and improve visual scanning
+  - These limits ensure titles remain readable and don't crowd the navigation menu
+- The goal is to make sidebar navigation less crowded and more readable
+- Titles should be immediately understandable without reading the full description
+- **Language detection**: Determine the primary language of the title and apply the appropriate character limit
+
+</streamlining_rules>
+
+<output_rules>
+
+Return a JSON object with:
+
+- `documentList`: array of streamlined document items, each containing:
+  - `path`: the same path from input (for mapping purposes)
+  - `title`: shortened title (maximum 24 characters for English, 12 characters for character-based languages, optimized for sidebar display)
+
+Ensure each streamlined item:
+- Preserves the exact `path` value from the corresponding input item
+- Maintains the original intent and meaning
+- Uses clear, scannable language
+- Fits within the word/character count constraints
+- Provides enough context for users to understand the document's purpose at a glance
+- Is optimized for sidebar navigation display
+
+</output_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-code-block.md

@@ -18,6 +18,11 @@ The following are the available enhanced attributes and their descriptions:
   * `language` and `title` are written directly after \`\`\`, separated by spaces.
   * Other attributes (`icon`) must be provided in **key=value** format, separated by spaces.
 
+### Special Rules
+- If the language is a shell (includes `sh`, `bash`, `zsh`, etc.):
+  - Executable shell code blocks must be a single-line command to make copying and running easier.
+  - Do not include comments inside executable shell code blocks; place explanatory comments outside the code block.
+
 ### Examples
 
 <code_block_good_examples>
@@ -70,9 +75,26 @@ class ShoppingCart {
   }
 }
 ```
+
+**Example 5: Shell code block should in one line**
+
+```sh Install aigne deps icon=lucide:terminal
+npm i -g @aigne/cli @aigne/doc-smith @aigne/websmith-smith
+```
+
+**Example 6: Shell code block use `\` to split multiple lines**
+```bash Deploying with Access Keys icon=lucide:terminal
+blocklet deploy . \
+  --endpoint https://my-server.arcblock.io \
+  --access-key 'your_access_key_id' \
+  --access-secret 'your_access_key_secret' \
+  --app-id z2qa9sD2tFAP8gM7C1i8iETg3a1T3A3aT3bQ
+```
+
 </code_block_good_examples>
 
 <code_block_bad_examples>
+
 **Example 1**
 
 There are two errors in this example:
@@ -97,5 +119,18 @@ fn main() -> Result<(), Box<dyn std::error::Error>> {
 }
 ```
 
+**Example 2: shell code block have multiple lines**
+```sh
+npm i -g @aigne/cli
+npm i -g @aigne/doc-smith
+npm i -g @aigne/websmith-smith
+```
+
+**Example 3: shell code block comments**
+```sh
+# add aigne deps
+npm i -g @aigne/cli
+```
+
 </code_block_bad_examples>
-</enhanced_code_block_rules>
+</enhanced_code_block_rules>

package/prompts/detail/custom/{custom-components.md → custom-components-usage-rules.md}

@@ -1,4 +1,4 @@
-<custom_components_usage>
+<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: Individual link display card
@@ -48,11 +48,11 @@ Example 1: Inline Markdown formatting in card content
 
 Example 2: Code block inside card content
 
-```md
+````md
 <x-card data-title="ctrl_break()" data-icon="lucide:keyboard">
   Creates a listener for "ctrl-break" events.
 
-\`\`\`rust
+```rust
 use tokio::signal::windows::ctrl_break;
 
 #[tokio::main]
@@ -62,10 +62,11 @@ stream.recv().await;
 println!("got ctrl-break");
 Ok(())
 }
-\`\`\`
-</x-card>
 ```
 
+````
+
+
 ## XCards: Multiple cards container
 
 Suitable for displaying multiple links using a card list format, providing a richer and more visually appealing presentation.
@@ -80,7 +81,7 @@ Suitable for displaying multiple links using a card list format, providing a ric
 
 ### Usage Rules
 
-- **Visual Consistency**: All <x-card> elements within the same <x-cards> must maintain visual consistency:
+- **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).
@@ -106,6 +107,18 @@ Example 2: Two-column cards with images
 </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
@@ -125,6 +138,15 @@ Example 2: Contains only one `<x-card>` (must include multiple cards)
 </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)
+```
+
 ## 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.
@@ -517,4 +539,4 @@ Example 6: Missing blank line before x-field-group (violates "Spacing Around" ru
 </x-field-group>
 ```
 
-</custom_components_usage>
+</custom_components_usage_rules>

package/prompts/detail/d2-diagram/pre-check.md

@@ -0,0 +1,23 @@
+<document_content>
+{{documentContent}}
+</document_content>
+
+{% if feedback %}
+<feedback>
+{{feedback}}
+</feedback>
+{% endif %}
+
+{% if detailFeedback %}
+<content_review_feedback>
+{{ detailFeedback }}
+</content_review_feedback>
+{% endif %}
+
+{% if previousGenerationContent %}
+<previous_generation_content>
+{{ previousGenerationContent }}
+</previous_generation_content>
+{% endif %}
+
+{% include "./rules.md" %}

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

@@ -1,26 +1,44 @@
 <diagram_generation_rules>
-**Generation Workflow**
-1. Use the current `<detail_dataSource>`, `<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 `diagramSourceCode`. If not, remove any embedded diagram from the document.
-
-**Generation Result Usage**
-When `diagramSourceCode` is available, insert it into the document exactly as returned without any edits.
-
-**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.
-   - 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
-   - **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.
+
+You must analyze the provided inputs to determine if a diagram is needed and where to insert a placeholder. You must not generate the diagram itself (e.g., no Mermaid, PlantUML, or other code). You are only deciding and placing the placeholder.
+
+## Inputs
+
+- `<document_content>`: The main body of text to be evaluated.
+- `<previous_generation_content>`: The content from the previous run, which may contain DIAGRAM_PLACEHOLDER.
+- `<feedback>`: Specific user instructions for this run (e.g., "add a diagram," "remove the diagram").
+- `<content_review_feedback>`: General automated or human feedback on the content.
+
+## Scoring conditions
+
+- `add`: If `<feedback>` explicitly requests to add a diagram, ignore other conditions, +30000
+- `remove`: If `<feedback>` explicitly requests to remove a diagram, ignore other conditions, -30000
+- `previous-exists`: If `<previous_generation_content>` contains diagram, +21000
+- `path-exclude`: If the document path or filename matches excluded patterns (e.g., `/faq/`, `CHANGELOG`, `release-notes`), -10000
+- `less-words`: If document length <= 200 words AND less than 2 headings, -10000
+- `overview`: If `<document_content>` provides a high-level overview, +3
+- `architectural`: If `<document_content>` contains an architectural description (components/services/layers/modules), +3
+- `workflow`: If `<document_content>` describes a workflow, sequence, user interactions, or data flow, +2
+- `hierarchy`: If `<document_content>` describes a clear hierarchy (linked sub-docs / deeply nested sections), +1
+- `introductory-major`: If `<document_content>` is an introductory page for a major section, +1
+
+## Output Requirements
+- `details` is an array. Each element must include:
+  - `type`: matched scoring condition's type name
+  - `score`: matched scoring condition's score
+  - `reason`: text explaining why this scoring condition is matched
+- `content`: `<document_content>` with placeholder inserted
+  - Identify the most logical insertion point in the `<document_content>`. (This is often after an introductory paragraph or before a list/section that the diagram will explain).
+  - Insert the exact placeholder string: DIAGRAM_PLACEHOLDER
+  - Crucially: Adjust the surrounding text to integrate the placeholder smoothly. Add a lead-in sentence.
+  - Good example: "The following diagram illustrates this data flow:"
+  - Good example: "This architecture is shown in the overview below:"
+  - Bad example: (Just inserting the placeholder with no context).
+  - Return the modified document content.
+    - Keep the original structure of the document, including page headings and hierarchy
+      - Only modify parts of the document text to improve the alignment between diagrams and their context
+      - The output must not include the `document_content` tag
+      - Do not provide any explanations; include only the document content itself
+
 </diagram_generation_rules>
+

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

@@ -12,26 +12,6 @@ Generate a d2 diagram that represents the following document content:
 
 </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>

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

@@ -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

@@ -37,14 +37,14 @@ Glossary of specialized terms. Please ensure correct spelling when using these t
 Documentation content generation rules:
 {% include "./document-rules.md" %}
 
-Custom component generation rules:
-{% include "../custom/custom-components.md" %}
+{% include "../custom/custom-components-usage-rules.md" %}
 
 Custom code block generation rules:
 {% include "../custom/custom-code-block.md" %}
 
 {% include "../../common/document/media-file-list-usage-rules.md" %}
 
+
 </content_generation_rules>
 
 
@@ -52,7 +52,7 @@ Custom code block generation 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

@@ -7,24 +7,24 @@
 
 ** 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). **
 
-- **Necessary**: Generate diagrams only when necessary.
 </user_rules>
 
 {% set operation_type = "generating" %}
 {% include "../../common/document/user-preferences.md" %}
 
-<detail_dataSource>
+<detail_data_source>
 {{ detailDataSource }}
 
 {{ additionalInformation }}
 
+{% if assetsContent %}
 <media_file_list>
 {{ assetsContent }}
 </media_file_list>
+{% endif %}
 
-</detail_dataSource>
+</detail_data_source>
 
 
 {% include "../../common/document/openapi-usage-rules.md" %}
@@ -51,7 +51,7 @@ User feedback on previous generation:
 {% endif %}
 
 <instructions>
-Generate detailed and well-structured document for the current {{nodeName}} based on user-provided information: current {{nodeName}} details (including title, description, path), detailDataSource, documentStructure (overall structural planning), and other relevant information.
+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.

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

@@ -32,14 +32,15 @@ Glossary of specialized terms. Please ensure correct spelling when using these t
 Documentation content optimization rules:
 {% include "../generate/document-rules.md" %}
 
-Custom component optimization rules:
-{% include "../custom/custom-components.md" %}
+{% include "../custom/custom-components-usage-rules.md" %}
 
 Custom code block optimization rules:
 {% include "../custom/custom-code-block.md" %}
 
 {% include "../../common/document/media-file-list-usage-rules.md" %}
 
+{% include "../d2-diagram/rules.md" %}
+
 </content_optimization_rules>
 
 
@@ -91,7 +92,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

@@ -11,21 +11,25 @@
 {% set operation_type = "optimizing" %}
 {% include "../../common/document/user-preferences.md" %}
 
-<original_page_content>
+<original_document_content>
 {{originalContent}}
-</original_page_content>
+</original_document_content>
 
-<detail_dataSource>
+{% if needDataSources %}
+<detail_data_source>
 
 {{ detailDataSource }}
 
 {{ additionalInformation }}
 
+{% if assetsContent %}
 <media_file_list>
 {{ assetsContent }}
 </media_file_list>
+{% endif %}
 
-</detail_dataSource>
+</detail_data_source>
+{% endif %}
 
 <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,7 +7,6 @@ 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" %}
 
 

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

@@ -1,11 +1,11 @@
-<datasources>
+<data_sources>
 Following are the partial or complete data sources provided by the user to help you design the document structure. Use these data sources to inform your structural planning.
 
-{{ datasources }}
+{{ dataSourceChunk }}
 
 
 NOTICE: There are additional data source contents not displayed. When operating on the document structure, be sure to consider these undisplayed contents and do not easily delete any nodes unless users explicitly request deletion.
-</datasources>
+</data_sources>
 
 {% if userContext.openAPISpec %}
 <openapi>
@@ -41,17 +41,22 @@ NOTICE: There are additional data source contents not displayed. When operating
 </openapi>
 {% endif %}
 
-
-<last_document_structure>
+<document_info>
 projectName: |
   {{projectName}}
+{% if projectDesc %}
 projectDesc: |
   {{projectDesc}}
+{% endif %}
+</document_info>
+
+<last_document_structure>
 
 {% if originalDocumentStructure %}
 {{ originalDocumentStructure | yaml.stringify }}
 {% elseif userContext.originalDocumentStructure %}
 {{ userContext.originalDocumentStructure | yaml.stringify }}
+{% else %}
 No previous document structure provided. generate a new structure based on the data sources!
 {% endif %}
 
@@ -96,7 +101,7 @@ The current process is planning sub-structures for the following section:
 {{parentDocument}}
 
 Sub-structures must meet the following requirements:
-- Sub-structures are planned based on DataSources and the parent document's description
+- Sub-structures are planned based on `<data_sources>` and the parent document's description
 - The parent document provides an overview of the planned content, while sub-structures directly plan the specific content to be displayed
 - Further break down and comprehensively display the content planned in the parent document
 - All sub-structures must have their parentPath value set to {{parentDocument.path}}
@@ -107,7 +112,7 @@ Sub-structures must meet the following requirements:
 Your task is to **analyze, refine, and adjust** the existing document structure (`last_document_structure`) based on the partial code repository content currently provided, generating a structural update plan.
 You are not creating a structure from scratch, but rather **performing intelligent updates based on understanding the existing structure** to make the document structure more accurately reflect the latest code content, architectural changes, and logical relationships.
 
-## When using <datasource> data sources, please note the following:
+## When using `<data_sources>` data sources, please note the following:
 
 - Fully respect the project descriptions and usage instructions in README files, as these typically summarize the project's core functionality and objectives.
 - Pay attention to comments and docstrings in source code files, as these reveal the design intent and usage methods of the code.
@@ -127,7 +132,7 @@ IMPORTANT: You should avoid duplicating existing structure items. Only include i
 ## Behavior Rules
 
 1. **Understanding and Inheritance**
-   - Fully understand the hierarchical logic, section divisions, and naming style in <last_document_structure>.
+   - Fully understand the hierarchical logic, section divisions, and naming style in `<last_document_structure>`.
    - Perform incremental updates based on this foundation, not complete rewrites.
    - Preserve existing reasonable structures, only modify or extend when there is clear justification.
 
@@ -148,7 +153,7 @@ IMPORTANT: You should avoid duplicating existing structure items. Only include i
    - Maintain clear hierarchy, avoid duplication, ensure logical coherence. Excellent documentation should allow users to quickly understand project structure and content distribution, organized by modules, functional features, and other dimensions.
 
 5. **Requirements**
-  - Follow all rules and guidelines in <document_structure_rules>.
+  - Follow all rules and guidelines in `<document_structure_rules>`.
   - Generate rich document structure where functional modules must have sub-documents, comprehensively covering the codebase's functionality and modules, ensuring users can easily get started, understand, and use various modules and main features of the project through documentation.
 
 {% include "../../common/document-structure/intj-traits.md" %}

package/prompts/structure/review/structure-review-system.md

@@ -2,13 +2,16 @@
 You are a **Documentation Structure Refiner** with the analytical mindset of an **INTJ (The Architect)**. You combine expert knowledge in technical documentation architecture and information design with strategic thinking, systematic analysis, and perfectionist attention to detail. Your core strengths are understanding complex systems, creating logically sound blueprints, and anticipating future documentation challenges.
 </role_and_goal>
 
-<document_structure>
+<document_info>
 projectName: |
   {{projectName}}
+{% if projectDesc %}
 projectDesc: |
   {{projectDesc}}
+{% endif %}
+</document_info>
 
-documentStructure:
+<document_structure>
 {{ documentStructure | yaml.stringify }}
 </document_structure>