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

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>
 

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

@@ -90,17 +90,4 @@ Analyze the user feedback to determine the intended operation:
 </operation_output_constraints>
 </operation_execution_rules>
 
-<file_tool_usage>
-1. glob: Find files matching specific patterns with advanced filtering and sorting.
-
-2. grep: Search file contents using regular expressions with multiple strategies (git grep → system grep → JavaScript fallback).
-
-3. readFile: Read file contents with intelligent binary detection, pagination, and metadata extraction.
-
-When to use Tools:
-- During document structure update, if the given context is missing or lacks referenced content, use glob/grep/readFile to obtain more context
-- When sourceIds or file content from <file_list> is needed but not provided in DataSources, use readFile to read the file content
-</file_tool_usage>
-
-
 {% include "../../common/document-structure/output-constraints.md" %}

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

@@ -6,10 +6,11 @@
 {{allFilesPaths}}
 </file_list>
 
-<datasources>
-{{ datasources }}
-</datasources>
-
+{% if needDataSources %}
+<data_sources>
+{{ dataSourceChunk }}
+</data_sources>
+{% endif %}
 
 Initial Documentation Structure:
 <initial_document_structure>
@@ -38,5 +39,5 @@ Processing workflow:
 
 Rules:
 ** All changes must be made using Tools. **
-** Carefully check if the latest version of documentStructure data meets user requirements, must avoid duplicate Tool calls. **
+** Carefully check if the latest version of `<document_structure>` data meets user requirements, must avoid duplicate Tool calls. **
 </instructions>

package/prompts/translate/translate-document.md

@@ -5,10 +5,10 @@ You are an **Elite Polyglot Localization and Translation Specialist** with exten
 Core Mandates:
 
 1. Semantic Fidelity (Accuracy): The translation must perfectly and comprehensively convey the **entire meaning, tone, and nuance** of the source text. **No omission, addition, or distortion of the original content** is permitted.
-2. Native Fluency and Style: The resulting text must adhere strictly to the target language's **grammar, syntax, and idiomatic expressions**. The translation must **sound like it was originally written by a native speaker**, completely **free of grammatical errors** or "translationese" (literal, stiff, or unnatural phrasing).
+2. Native Fluency and Style: The resulting text must adhere strictly to the target language's **grammar, syntax, and idiomatic expressions**. The translation must **sound like it was originally written by a native speaker**, completely **free of grammatical errors**, avoid "translationese" (literal, stiff, or unnatural phrasing).
 3. Readability and Flow: The final output must be **smooth, logical, and highly readable**. Sentences must flow naturally, ensuring a pleasant and coherent reading experience for the target audience.
 4. Localization and Clarity: Where a **literal (word-for-word) translation** of a term, phrase, or idiom would be **uncommon, confusing, or ambiguous** in the target language, you must apply **localization best practices**. This means translating the **concept** into the most **idiomatic, common, and easily understandable expression** in the target language.
-5. Versatility and Scope: You are proficient in handling **any pair of requested languages** (e.g., Chinese $\leftrightarrow$ English, English $\leftrightarrow$ Japanese) and are adept at translating diverse **document types**, including but not limited to: **Technical Manuals, Business Reports, Marketing Copy/Ads, Legal Documents, Academic Papers, and General Correspondence.**
+5. Versatility and Scope: You are proficient in handling **any pair of requested languages** (e.g., Chinese <--> English, English <--> Japanese) and are adept at translating diverse **document types**, including but not limited to: **Technical Manuals, Business Reports, Marketing Copy/Ads, Legal Documents, Academic Papers, and General Correspondence.**
 
 </role_and_goal>
 
@@ -299,5 +299,5 @@ Original text as follows:
 </content>
 
 <output_constraints>
-Please **accurately** translate the content within <content> tags (excluding the outermost <content> tags) into **{{ language }}**, strictly following the translation requirements.
+Please **accurately** translate the content within `<content>` tags (excluding the outermost `<content>` tags) into **{{ language }}**, strictly following the translation requirements.
 </output_constraints>