@aigne/doc-smith 0.8.11-beta → 0.8.11-beta.2

package/docs/getting-started.zh.md

@@ -1,28 +1,28 @@
 # 入门指南
 
-本指南将引导您逐步完成 AIGNE DocSmith 的安装、项目配置，并从源代码生成一套完整的文档。
+本指南提供了一个分步演练，指导您安装 AIGNE DocSmith、配置项目，并从源代码生成一套完整的文档。
 
 ## 第 1 步：准备工作
 
-在开始之前，请确保您的系统中已安装 Node.js 及其包管理器 npm。DocSmith 是一个在 Node.js 环境下运行的命令行工具。
+在开始之前，请确保您的系统上已安装 Node.js 及其包管理器 npm。DocSmith 是一个在 Node.js 环境中运行的命令行工具。
 
 ### 安装 Node.js
 
 以下是在各种操作系统上安装 Node.js 的简要说明。
 
 **Windows**
-1.  从 [Node.js 官网](https://nodejs.org/) 下载安装程序。
-2.  运行 `.msi` 安装程序，并按照安装向导的步骤进行操作。
+1.  从官方 [Node.js 网站](https://nodejs.org/) 下载安装程序。
+2.  运行 `.msi` 安装程序，并按照安装向导中的步骤操作。
 
 **macOS**
 
-推荐使用 [Homebrew](https://brew.sh/) 进行安装：
+推荐的方法是使用 [Homebrew](https://brew.sh/)：
 
 ```bash Terminal icon=lucide:apple
-# Install Homebrew if you don't have it
+# 如果您没有安装 Homebrew，请先安装
 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
 
-# Install Node.js
+# 安装 Node.js
 brew install node
 ```
 
@@ -47,7 +47,7 @@ sudo yum install nodejs
 
 ### 验证
 
-安装完成后，在终端中运行以下命令，验证 Node.js 和 npm 是否可用：
+安装完成后，通过在终端中运行以下命令来验证 Node.js 和 npm 是否可用：
 
 ```bash Terminal
 node --version
@@ -56,23 +56,23 @@ npm --version
 
 ## 第 2 步：安装 AIGNE CLI
 
-DocSmith 工具包含在 AIGNE 命令行界面 (CLI) 中。使用 npm 全局安装最新版本的 AIGNE CLI：
+DocSmith 工具包含在 AIGNE 命令行界面（CLI）中。使用 npm 全局安装最新版本的 AIGNE CLI：
 
 ```bash Terminal icon=logos:npm
 npm i -g @aigne/cli
 ```
 
-安装完成后，运行文档工具的帮助命令进行验证：
+安装完成后，通过运行文档工具的帮助命令来验证安装：
 
 ```bash Terminal
 aigne doc -h
 ```
 
-该命令将显示 DocSmith 的帮助菜单，确认其已准备就绪。
+此命令将显示 DocSmith 的帮助菜单，确认其已准备就绪。
 
 ## 第 3 步：生成您的文档
 
-安装 CLI 后，您只需一个命令即可生成文档。在终端中导航到您项目的根目录并运行：
+安装 CLI 后，您可以使用单个命令生成文档。在终端中导航到您项目的根目录并运行：
 
 ```bash Terminal icon=lucide:sparkles
 aigne doc generate
@@ -80,44 +80,44 @@ aigne doc generate
 
 ### 自动配置
 
-当您首次在项目中运行此命令时，DocSmith 会检测到尚无配置，并自动启动一个交互式设置向导。
+当您首次在项目中运行此命令时，DocSmith 会检测到不存在任何配置，并自动启动一个交互式设置向导。
 
 ![运行 generate 命令会启动设置向导](https://docsmith.aigne.io/image-bin/uploads/0c45a32667c5250e54194a61d9495965.png)
 
-系统将提示您回答一系列问题，以定义文档的特性，包括：
+系统将提示您一系列问题，以定义文档的特性，包括：
 
 - 主要目的和风格。
 - 目标受众。
-- 主要语言及其他需要翻译的语言。
+- 主要语言以及用于翻译的其他语言。
 - 供 AI 分析的源代码路径。
 - 生成文档的输出目录。
 
 ![回答提示以完成项目设置](https://docsmith.aigne.io/image-bin/uploads/fbedbfa256036ad6375a6c18047a75ad.png)
 
-配置完成后，DocSmith 将开始分析您的源代码、规划文档结构并生成内容。
+配置完成后，DocSmith 将继续分析您的源代码、规划文档结构并生成内容。
 
 ![DocSmith 正在规划结构并生成文档](https://docsmith.aigne.io/image-bin/uploads/d0766c19380a02eb8a6f8ce86a838849.png)
 
-## 第 4 步：查看您的输出
+## 第 4 步：检查您的输出
 
-生成过程结束后，您的终端将显示一条确认消息。
+生成过程结束后，您的终端中将显示一条确认消息。
 
-![文档生成成功消息](https://docsmith.aigne.io/image-bin/uploads/0967443611408ad9d0042793d590b8fd.png)
+![文档生成成功的消息](https://docsmith.aigne.io/image-bin/uploads/0967443611408ad9d0042793d590b8fd.png)
 
-您的新文档现已位于您在设置过程中指定的输出目录中。默认位置是 `.aigne/doc-smith/docs`。
+您的新文档现在位于您在设置过程中指定的输出目录中。默认位置是 `.aigne/doc-smith/docs`。
 
-## 下一步？
+## 接下来做什么？
 
-既然您已经生成了第一套文档，可以探索其他功能：
+既然您已经生成了第一套文档，您可以探索其他功能：
 
 <x-cards>
   <x-card data-title="核心功能" data-icon="lucide:box" data-href="/features">
     探索主要命令和功能，从更新文档到在线发布。
   </x-card>
   <x-card data-title="配置指南" data-icon="lucide:settings" data-href="/configuration">
-    了解如何通过编辑 config.yaml 文件来微调文档的风格、受众和语言。
+    学习如何通过编辑 config.yaml 文件来微调文档的风格、受众和语言。
   </x-card>
   <x-card data-title="CLI 命令参考" data-icon="lucide:terminal" data-href="/cli-reference">
-    获取所有可用 `aigne doc` 命令及其选项的完整参考。
+    获取所有可用的 `aigne doc` 命令及其选项的完整参考。
   </x-card>
 </x-cards>

package/docs/overview.ja.md

@@ -0,0 +1,30 @@
+# 概要
+
+AIGNE DocSmithは、ソースコードから直接ドキュメントを生成するAI駆動のツールです。[AIGNE Framework](https://www.aigne.io/en/framework)上に構築されており、構造化された多言語ドキュメントの作成を自動化します。このプロセスにより、ドキュメントの作成と保守にかかる手作業が削減され、コードベースとの同期が確保されます。
+
+## AIGNEエコシステムの一部
+
+DocSmithは、AIアプリケーション開発プラットフォームである[AIGNE](https://www.aigne.io)エコシステムの主要なコンポーネントです。他のAIGNEコンポーネントと統合し、プラットフォームのAI機能とインフラストラクチャを利用します。
+
+以下の図は、DocSmithがAIGNEアーキテクチャ内でどのように位置づけられるかを示しています。
+
+![AIGNEエコシステムアーキテクチャ](https://docsmith.aigne.io/image-bin/uploads/def424c20bbdb3c77483894fe0e22819.png)
+
+## 主な機能
+
+DocSmithは、ドキュメント作成プロセスを自動化し、簡素化するための一連の機能を提供します。
+
+*   **構造計画：** コードベースを分析して、論理的なドキュメント構造を生成します。
+*   **コンテンツ生成：** 計画されたドキュメント構造に、ソースコードから生成されたコンテンツを埋め込みます。
+*   **多言語サポート：** 英語、中国語、日本語、スペイン語を含む12言語にドキュメントを翻訳します。
+*   **AIGNE Hubとの統合：** [AIGNE Hub](https://www.aigne.io/en/hub)をLLMプロバイダーとして使用し、個別のAPIキーを管理することなくモデルを切り替えることができます。
+*   **ドキュメント公開：** 公式プラットフォーム[docsmith.aigne.io](https://docsmith.aigne.io/app/)またはユーザー自身の[Discuss Kit](https://www.arcblock.io/docs/web3-kit/en/discuss-kit)インスタンスにドキュメントを公開します。
+*   **反復更新：** ソースコードの変更を検出してドキュメントを更新し、ユーザーのフィードバックに基づいて特定のドキュメントのターゲットを絞った再生成をサポートします。
+
+## 次のステップ
+
+DocSmithの使用を開始するには、インストールおよび設定ガイドに進んでください。
+
+<x-card data-title="次へ：はじめに" data-href="/getting-started" data-icon="lucide:arrow-right-circle" data-cta="ガイドを開始">
+  ステップバイステップのガイドに従って、ツールをインストールし、最初のプロジェクトを設定して、ドキュメントを生成します。
+</x-card>

package/docs/overview.zh-TW.md

@@ -0,0 +1,30 @@
+# 總覽
+
+AIGNE DocSmith 是一個由 AI 驅動的工具，可以直接從您的原始碼產生文件。它建立在 [AIGNE 框架](https://www.aigne.io/en/framework)之上，可自動建立結構化、多語言的文件。這個過程減少了撰寫和維護文件的人工工作，確保文件與程式碼庫保持同步。
+
+## AIGNE 生態系統的一部分
+
+DocSmith 是 [AIGNE](https://www.aigne.io) 生態系統的關鍵組件，該生態系統是開發 AI 應用程式的平台。它與其他 AIGNE 組件整合，以利用平台的 AI 功能和基礎設施。
+
+下圖說明了 DocSmith 如何融入 AIGNE 架構：
+
+![AIGNE Ecosystem Architecture](https://docsmith.aigne.io/image-bin/uploads/def424c20bbdb3c77483894fe0e22819.png)
+
+## 核心功能
+
+DocSmith 提供了一系列功能來自動化和簡化文件編寫過程：
+
+*   **結構規劃：** 分析程式碼庫以產生邏輯性的文件結構。
+*   **內容生成：** 用從原始碼生成的內容填充規劃好的文件結構。
+*   **多語言支援：** 將文件翻譯成 12 種語言，包括英語、中文、日語和西班牙語。
+*   **AIGNE Hub 整合：** 使用 [AIGNE Hub](https://www.aigne.io/en/hub) 作為 LLM 提供者，允許切換模型而無需管理單獨的 API 金鑰。
+*   **文件發布：** 將文件發布到官方平台 [docsmith.aigne.io](https://docsmith.aigne.io/app/) 或使用者自己的 [Discuss Kit](https://www.arcblock.io/docs/web3-kit/en/discuss-kit) 實例。
+*   **迭代更新：** 偵測原始碼變更以更新文件，並支援根據使用者回饋對特定文件進行定向重新生成。
+
+## 後續步驟
+
+要開始使用 DocSmith，請繼續閱讀安裝和設定指南。
+
+<x-card data-title="下一步：入門" data-href="/getting-started" data-icon="lucide:arrow-right-circle" data-cta="開始指南">
+  請遵循逐步指南安裝工具、設定您的第一個專案並產生文件。
+</x-card>

package/docs/overview.zh.md

@@ -1,12 +1,12 @@
 # 概述
 
-AIGNE DocSmith 是一款 AI 驱动的工具，可直接从源代码生成文档。它基于 [AIGNE 框架](https://www.aigne.io/en/framework)，可自动创建结构化的多语言文档。此过程减少了编写和维护文档的人工工作量，确保文档与代码库保持同步。
+AIGNE DocSmith 是一款 AI 驱动的工具，可直接从您的源代码生成文档。它基于 [AIGNE 框架](https://www.aigne.io/en/framework) 构建，能够自动创建结构化、多语言的文档。这一过程减少了编写和维护文档的人工工作量，并确保文档与代码库保持同步。
 
 ## AIGNE 生态系统的一部分
 
-DocSmith 是 [AIGNE](https://www.aigne.io) 生态系统的一个关键组件，该生态系统是一个用于开发 AI 应用的平台。它与其他 AIGNE 组件集成，以使用该平台的 AI 功能和基础设施。
+DocSmith 是 [AIGNE](https://www.aigne.io) 生态系统的重要组成部分，该生态系统是用于开发 AI 应用程序的平台。它与其他 AIGNE 组件集成，以利用该平台的 AI 功能和基础设施。
 
-下图说明了 DocSmith 如何融入 AIGNE 架构：
+下图说明了 DocSmith 在 AIGNE 架构中的位置：
 
 ![AIGNE 生态系统架构](https://docsmith.aigne.io/image-bin/uploads/def424c20bbdb3c77483894fe0e22819.png)
 
@@ -14,10 +14,10 @@ DocSmith 是 [AIGNE](https://www.aigne.io) 生态系统的一个关键组件，
 
 DocSmith 提供了一系列功能来自动化和简化文档流程：
 
-*   **结构规划：** 分析代码库以生成逻辑化的文档结构。
+*   **结构规划：** 分析代码库以生成逻辑清晰的文档结构。
 *   **内容生成：** 使用从源代码生成的内容填充规划好的文档结构。
-*   **多语言支持：** 将文档翻译成 12 种语言，包括英语、中文、日语和西班牙语。
-*   **AIGNE Hub 集成：** 使用 [AIGNE Hub](https://www.aigne.io/en/hub) 作为 LLM 提供商，无需管理独立的 API 密钥即可切换模型。
+*   **多语言支持：** 可将文档翻译成 12 种语言，包括英语、中文、日语和西班牙语。
+*   **AIGNE Hub 集成：** 使用 [AIGNE Hub](https://www.aigne.io/en/hub) 作为 LLM 提供商，无需管理单独的 API 密钥即可切换模型。
 *   **文档发布：** 将文档发布到官方平台 [docsmith.aigne.io](https://docsmith.aigne.io/app/) 或用户自己的 [Discuss Kit](https://www.arcblock.io/docs/web3-kit/en/discuss-kit) 实例。
 *   **迭代更新：** 检测源代码变更以更新文档，并支持根据用户反馈对特定文档进行定向重新生成。
 
@@ -25,6 +25,6 @@ DocSmith 提供了一系列功能来自动化和简化文档流程：
 
 要开始使用 DocSmith，请继续阅读安装和配置指南。
 
-<x-card data-title="下一步：开始入门" data-href="/getting-started" data-icon="lucide:arrow-right-circle" data-cta="开始阅读指南">
-  按照分步指南安装工具、配置你的第一个项目并生成文档。
+<x-card data-title="下一步：开始使用" data-href="/getting-started" data-icon="lucide:arrow-right-circle" data-cta="开始阅读指南">
+  请按照分步指南安装工具、配置您的第一个项目并生成文档。
 </x-card>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aigne/doc-smith",
-  "version": "0.8.11-beta",
+  "version": "0.8.11-beta.2",
   "description": "AI-driven documentation generation tool built on the AIGNE Framework",
   "publishConfig": {
     "access": "public"
@@ -12,23 +12,29 @@
   "author": "Arcblock <blocklet@arcblock.io> https://github.com/blocklet",
   "license": "Elastic-2.0",
   "dependencies": {
-    "@aigne/aigne-hub": "^0.9.5",
-    "@aigne/anthropic": "^0.13.4",
-    "@aigne/cli": "^1.48.1",
-    "@aigne/core": "^1.60.3",
-    "@aigne/gemini": "^0.13.4",
-    "@aigne/openai": "^0.15.4",
+    "@aigne/aigne-hub": "^0.10.0",
+    "@aigne/anthropic": "^0.14.0",
+    "@aigne/cli": "^1.49.0",
+    "@aigne/core": "^1.61.0",
+    "@aigne/gemini": "^0.14.0",
+    "@aigne/openai": "^0.16.0",
     "@aigne/publish-docs": "^0.11.0",
+    "@blocklet/payment-broker-client": "^1.20.20",
     "@terrastruct/d2": "^0.1.33",
     "chalk": "^5.5.0",
+    "cli-highlight": "^2.1.11",
     "debug": "^4.4.1",
+    "diff": "^8.0.2",
     "dompurify": "^3.2.6",
     "fs-extra": "^11.3.1",
     "glob": "^11.0.3",
     "jsdom": "^26.1.0",
+    "marked": "^15.0.12",
+    "marked-terminal": "^7.3.0",
     "mermaid": "^11.9.0",
     "open": "^10.2.0",
     "p-map": "^7.0.3",
+    "p-retry": "^7.0.0",
     "remark-gfm": "^4.0.1",
     "remark-lint": "^10.0.1",
     "remark-parse": "^11.0.0",
@@ -37,19 +43,21 @@
     "unified": "^11.0.5",
     "unist-util-visit": "^5.0.0",
     "vfile": "^6.0.3",
-    "yaml": "^2.8.0"
+    "yaml": "^2.8.0",
+    "zod": "^3.25.76",
+    "zod-to-json-schema": "^3.24.6"
   },
   "devDependencies": {
-    "@biomejs/biome": "^2.1.4"
+    "@biomejs/biome": "^2.2.4"
   },
   "scripts": {
     "test": "bun test",
     "test:coverage2": "bun test --coverage",
     "test:coverage": "bun test --coverage --coverage-reporter=lcov --coverage-reporter=text",
     "test:watch": "bun test --watch",
-    "lint": "biome check",
+    "lint": "biome lint && biome format",
     "update:deps": "npx -y taze major -r -w -f -n '/@abtnode|@aigne|@arcblock|@blocklet|@did-connect|@did-pay|@did-space|@nft-store|@nft-studio|@ocap/' && pnpm install && pnpm run deduplicate",
     "deduplicate": "pnpm dedupe",
-    "lint:fix": "biome check --write"
+    "lint:fix": "biome lint --write && biome format --write"
   }
 }

package/prompts/common/document/content-rules-core.md

@@ -0,0 +1,19 @@
+Target Audience: {{targetAudience}}
+
+Content Generation Rules:
+
+- Use only information from DataSources, never fabricate or supplement content not present in the sources
+- Combine the current {{nodeName}} title and description to create a well-structured content plan that is rich, organized, and engaging
+- Content style must match the target audience
+- Clearly differentiate content from other {{nodeName}} items in the documentStructure to avoid duplication and highlight this {{nodeName}}'s unique value
+{% if enforceInfoCompleteness %}
+- If DataSources lack sufficient information, return an error message requesting users to provide additional content. Ensure page content is sufficiently rich, don't hesitate to ask users for supplementary information
+- Display only valuable, engaging information. If information is insufficient, prompt users to provide more details
+{% endif %}
+- Output complete information including all content planned for the {{nodeName}}
+- Ensure each {{nodeName}} detail includes a markdown level-1 heading displaying the current {{nodeName}} title: {{title}}
+- Format markdown output with proper line breaks and spacing for easy reading
+- For list data with many items, prioritize using markdown table for cleaner, more readable presentation
+- Do not mention 'DataSources' in output, your content is for user consumption, and users are unaware of DataSources
+- Do not include file paths from Data Sources in output as they are meaningless to users
+- Avoid phrases like 'current {{nodeName}}'

package/prompts/common/document/media-handling-rules.md

@@ -0,0 +1,9 @@
+<media_handling_rules>
+Media resource usage rules:
+
+- When DataSources contain media resource files, incorporate them appropriately in the generated content
+- Media resources are provided in markdown format, example: ![Resource description](https://xxxx)
+- Display images in markdown format within generated results
+- Based on resource descriptions, place images strategically in contextually relevant positions to enhance the presentation
+- To ensure correct media resource paths, **only use media resources provided in media_list or remote URL media resources**
+</media_handling_rules>

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

@@ -0,0 +1,15 @@
+You are an AI technical writer with the personality of an **ISTJ (The Logistician)**. Your primary strengths are precision, factual accuracy, and a methodical, step-by-step approach. You value clarity, structure, and proven information over abstract theories. Your goal is to produce documentation that is unambiguous, reliable, and easy for a technical user to follow.
+
+Your key strengths include:
+  - Deep Analytical Understanding: You can rapidly and thoroughly analyze different data sources, identifying critical information, logical relationships, potential issues, and key points that users care about most.
+  - Information Distillation and Organization: You excel at extracting core insights from vast amounts of information and presenting them with clear logic and rigorous structure, tailored to the document's purpose and target audience.
+  - Versatile Writing Style: You're not confined to specific technical domains and can adapt your language style to meet diverse documentation needs—whether technical specifications, user guides, product descriptions, or business process documentation.
+  - Quality-Driven Approach: You consistently pursue top-tier documentation quality, ensuring accuracy, completeness, consistency, readability, and practicality. You pay attention to detail and strive for precision in every expression.
+  - User-Centric Perspective: You think from the target reader's viewpoint, anticipating their potential questions and confusion, addressing them proactively in the documentation to enhance user experience and value.
+
+**Your process must reflect ISTJ traits:**
+
+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.

package/prompts/common/document/user-preferences.md

@@ -0,0 +1,9 @@
+{% if userPreferences %}
+<user_preferences>
+{{userPreferences}}
+
+User preference guidelines:
+- User preferences are derived from feedback provided in previous interactions. Consider these preferences when {{operation_type}} content to avoid repeating issues mentioned in user feedback
+- User preferences carry less weight than current user feedback
+</user_preferences>
+{% endif %}

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

@@ -0,0 +1,16 @@
+<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 document structure.
+
+Core principles for conflict resolution:
+1. **Layered need satisfaction**: Simultaneously satisfy multiple purposes and audiences through reasonable document structure hierarchy
+2. **Clear navigation paths**: Provide clear document usage paths for users with different needs
+3. **Avoid content duplication**: Ensure content across different sections is complementary rather than repetitive
+4. **Progressive disclosure**: From high-level overview to specific details, meeting needs at different depth levels
+
+Common conflict resolution patterns:
+- **Purpose conflicts**: Create hierarchical structures
+- **Audience conflicts**: Design role-oriented sections or paths
+- **Depth conflicts**: Adopt progressive structures that allow users to choose appropriate depth levels
+
+When generating document structure, prioritize conflict resolution strategies to ensure the final structure can harmoniously satisfy all user needs.
+</conflict_resolution_guidance>

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

@@ -0,0 +1,45 @@
+<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
+
+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. Analyze user rules and provided DataSources to determine what type of content users want to structure (e.g., websites, documentation, books, etc.) and design appropriate structures for different content types
+3. {{nodeName}} planning should display as much information as possible from the user-provided context
+4. Structure planning should have reasonable hierarchical relationships, with content planned at appropriate levels, avoiding flat layouts with numerous {{nodeName}} items
+5. 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
+6. Each {{nodeName}} should have a clear content plan and must not duplicate content from other {{nodeName}} items
+7. 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
+8. If previous document structure and user feedback are provided, make only necessary modifications based on user feedback without major changes
+9. If previous document structure is provided but no feedback is given, **directly return the previous document structure**
+10. If review feedback exists, it indicates your previous generation didn't meet requirements. Optimize your output based on the review feedback
+
+{{nodeName}} planning rules:
+
+1. Each {{nodeName}} should include this information:
+
+- 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.
+
+{% ifAsync docsType == 'general' %}
+  {% include "../../structure/document-rules.md" %}
+
+{% endif %}
+
+{% ifAsync docsType == 'getting-started' %}
+  {% include "../../structure/structure-getting-started.md" %}
+{% endif %}
+
+Other requirements:
+
+1. Must satisfy user specified rules
+2. Return information using the user's language {{locale}}
+</document_structure_rules>

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

@@ -0,0 +1,7 @@
+{% if glossary %}
+<terms>
+Glossary of specialized terms. Please ensure correct spelling when using these terms.
+
+{{glossary}}
+</terms>
+{% endif %}

package/prompts/common/document-structure/intj-traits.md

@@ -0,0 +1,5 @@
+**Your thinking process must reflect INTJ traits:**
+1. **Vision First:** Start by defining the ultimate goal this document modification must achieve.
+2. **Systematic Analysis:** Break down the user feedback into logical components and analyze the interconnections.
+3. **Architectural Structure:** Design modifications that maintain the top-down, tree-like structure integrity.
+4. **Efficiency and Optimization:** Consider how the changes can improve document clarity and user comprehension.

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

@@ -0,0 +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.
+  - 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>

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

@@ -0,0 +1,10 @@
+<user_locale>
+{{ locale }}
+</user_locale>
+
+
+<user_rules>
+{{ rules }}
+
+** Output content in {{ locale }} language **
+</user_rules>

package/prompts/common/document-structure/user-preferences.md

@@ -0,0 +1,9 @@
+{% if userPreferences %}
+<user_preferences>
+{{userPreferences}}
+
+User preference guidelines:
+- User preferences are derived from feedback provided in previous user interactions. When generating structural planning, consider user preferences to avoid repeating issues mentioned in user feedback
+- User preferences carry less weight than current user feedback
+</user_preferences>
+{% endif %}

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

@@ -115,6 +115,7 @@ Nesting Rules:
 
 - **Context types must use `<x-field>` instead of tables** for consistent formatting
 - **Mandatory markdown attribute**: Every `<x-field-desc>` element must include `markdown` attribute
+- **Description text as child content**: Description text must be provided as child content of `<x-field-desc>`, not as the value of the `markdown` attribute
 
 **Error Examples:**
 
@@ -125,7 +126,14 @@ Nesting Rules:
 </x-field>
 ```
 
-✅ **CORRECT** - With required `markdown` attribute:
+❌ **INCORRECT** - Description text as attribute value:
+```
+<x-field data-name="api_key" data-type="string" data-required="true">
+  <x-field-desc markdown="Your **API key** for authentication."></x-field-desc>
+</x-field>
+```
+
+✅ **CORRECT** - Includes the required `markdown` attribute, with the description provided as child text:
 ```
 <x-field data-name="api_key" data-type="string" data-required="true">
   <x-field-desc markdown>Your **API key** for authentication.</x-field-desc>

package/prompts/detail/document-rules.md

@@ -5,9 +5,9 @@ Documentation Generation Rules:
 - When a section contains sub-documents, display only a brief overview and direct users to the sub-documents for detailed information
 - Each document section should include: a title, introductory content, multiple subsections, and a summary
 - Since API names are already specified in document titles, avoid repeating them in subheadings—use sub-API names directly
-- Include links to related documents in the introduction using markdown format to help users navigate to relevant content
-- Add links to further reading materials in the summary section using markdown format
-- Use proper markdown link syntax, for example: [Next Chapter Title](next_chapter_path)
+- Include links to related documents in the introduction using Markdown format to help users navigate to relevant content
+- Add links to further reading materials in the summary section using Markdown format
+- 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 structure plan**—use absolute paths from the structure plan
 - When DataSources 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
@@ -18,11 +18,11 @@ Documentation Generation Rules:
 - Format all types with proper opening and closing tags `<x-field ...></x-field>`—leave simple types empty, include nested fields for complex types
 - When describing multiple properties of the same object, wrap the outermost `<x-field>` elements with `<x-field-group>` elements. Note that nested `<x-field>` elements do not need wrapping
 - All interface and method documentation must include **response data examples**
-- For simple list data, use markdown tables to present information clearly and improve readability
-- Validate output markdown for completeness, ensuring tables and d2 diagrams are properly formatted
+- For simple list data, use Markdown tables to present information clearly and improve readability
+- Validate output Markdown for completeness, ensuring tables and d2 diagrams are properly formatted
 - **Content Integrity**: Generate complete, syntactically correct code blocks (d2, JSON, etc.). Perform self-validation to ensure all code blocks, lists, and tables are properly closed without truncation
 - **Code Block Atomicity**: Treat code blocks (e.g., ```d2 ... ```) as indivisible units. Generate them completely from opening marker (```d2) to closing marker (```) without interruption
-- **Markdown Syntax Validation**: Ensure correct markdown formatting, particularly table separators (e.g., `|---|---|---|`) that match column counts
+- **Markdown Syntax Validation**: Ensure correct Markdown formatting, particularly table separators (e.g., `|---|---|---|`) that match column counts
 - Use README files for reference only—extract the most current and comprehensive information directly from source code
 - Omit tag information from document headers as it's processed programmatically
 - Parse `jsx` syntax correctly when present in code samples

package/prompts/detail/generate-document.md

@@ -1,12 +1,5 @@
 <role_and_goal>
-You are a seasoned documentation expert and information architect with extensive knowledge and exceptional communication skills. Your primary mission is to transform information from various sources—whether code, configurations, design documents, user requirements, or other structured and unstructured data—into clear, accurate, comprehensive, and user-friendly documentation.
-
-Your key strengths include:
-  - Deep Analytical Understanding: You can rapidly and thoroughly analyze different data sources, identifying critical information, logical relationships, potential issues, and key points that users care about most.
-  - Information Distillation and Organization: You excel at extracting core insights from vast amounts of information and presenting them with clear logic and rigorous structure, tailored to the document's purpose and target audience.
-  - Versatile Writing Style: You're not confined to specific technical domains and can adapt your language style to meet diverse documentation needs—whether technical specifications, user guides, product descriptions, or business process documentation.
-  - Quality-Driven Approach: You consistently pursue top-tier documentation quality, ensuring accuracy, completeness, consistency, readability, and practicality. You pay attention to detail and strive for precision in every expression.
-  - User-Centric Perspective: You think from the target reader's viewpoint, anticipating their potential questions and confusion, addressing them proactively in the documentation to enhance user experience and value.
+{% include "../common/document/role-and-personality.md" %}
 
 Your task is to generate detailed content 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.
 </role_and_goal>
@@ -21,15 +14,8 @@ Your task is to generate detailed content for the current {{nodeName}} based on
 ** Output content in {{ locale }} language **
 </user_rules>
 
-{% if userPreferences %}
-<user_preferences>
-{{userPreferences}}
-
-User preference guidelines:
-- User preferences are derived from feedback provided in previous interactions. Consider these preferences when generating content to avoid repeating issues mentioned in user feedback
-- User preferences carry less weight than current user feedback
-</user_preferences>
-{% endif %}
+{% set operation_type = "generating" %}
+{% include "../common/document/user-preferences.md" %}
 
 {% if detailFeedback %}
 <content_review_feedback>
@@ -39,25 +25,7 @@ User preference guidelines:
 
 <content_generation_rules>
 
-Target Audience: {{targetAudience}}
-
-Content Generation Rules:
-
-- Use only information from DataSources, never fabricate or supplement content not present in the sources
-- Combine the current {{nodeName}} title and description to create a well-structured content plan that is rich, organized, and engaging
-- Content style must match the target audience
-- Clearly differentiate content from other {{nodeName}} items in the documentStructure to avoid duplication and highlight this {{nodeName}}'s unique value
-{% if enforceInfoCompleteness %}
-- If DataSources lack sufficient information, return an error message requesting users to provide additional content. Ensure page content is sufficiently rich, don't hesitate to ask users for supplementary information
-- Display only valuable, engaging information. If information is insufficient, prompt users to provide more details
-{% endif %}
-- Output complete information including all content planned for the {{nodeName}}
-- Ensure each {{nodeName}} detail includes a markdown level-1 heading displaying the current {{nodeName}} title: {{title}}
-- Format markdown output with proper line breaks and spacing for easy reading
-- For list data with many items, prioritize using markdown table for cleaner, more readable presentation
-- Do not mention 'DataSources' in output, your content is for user consumption, and users are unaware of DataSources
-- Do not include file paths from Data Sources in output as they are meaningless to users
-- Avoid phrases like 'current {{nodeName}}'
+{% include "../common/document/content-rules-core.md" %}
 
 
 Documentation content generation rules:
@@ -122,15 +90,7 @@ User feedback on previous generation:
 {{ assetsContent }}
 </media_list>
 
-<media_handling_rules>
-Media resource usage rules:
-
-- When DataSources contain media resource files, incorporate them appropriately in the generated content
-- Media resources are provided in markdown format, example: ![Resource description](https://xxxx)
-- Display images in markdown format within generated results
-- Based on resource descriptions, place images strategically in contextually relevant positions to enhance the presentation
-- To ensure correct media resource paths, **only use media resources provided in media_list or remote URL media resources**
-</media_handling_rules>
+{% include "../common/document/media-handling-rules.md" %}
 
 </datasources>