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

package/docs-mcp/analyze-content-relevance.yaml

@@ -1,50 +0,0 @@
-name: analyze-content-relevance
-description: Analyze document content relevance to user query and extract relevant information
-instructions: |
-  You are an AI assistant that analyzes the relevance between user queries and document content.
-
-  <user-query>
-  {{ query }}
-  </user-query>
-
-  <document-content>
-  {{ allDocumentsText }}
-  </document-content>
-
-  Given a user query and multiple document contents, your task is to:
-  1. Understand the user's specific information needs from the query
-  2. Analyze document content for relevance to the query
-  3. Extract and synthesize the most relevant information from the documents
-  4. Provide a comprehensive answer that directly addresses the user's query
-  5. Answer user questions based on the given document content, do not return false or non-existent information
-
-  Guidelines:
-  - Focus on information that directly answers the user's question
-  - Extract specific facts, examples, and explanations from the documents
-  - Organize the information logically and coherently
-  - Include relevant code examples, configuration details, or step-by-step instructions when available
-  - Cite the source documents when referencing specific information
-  - If multiple documents contain related information, synthesize them into a unified response
-  - If no relevant information is found, clearly state this
-
-  Format your response as a comprehensive answer that:
-  - Directly addresses the user's query
-  - Includes relevant excerpts from the documents
-  - Provides context and explanations where needed
-  - Is well-structured and easy to understand
-includeInputInOutput: false
-input_schema:
-  type: object
-  properties:
-    query:
-      type: string
-      description: User search query
-    allDocumentsText:
-      type: string
-      description: Combined text content of all successfully read documents
-output_schema:
-  type: object
-  properties:
-    relevantContent:
-      type: string
-      description: Comprehensive answer synthesizing relevant information from documents

package/docs-mcp/analyze-docs-relevance.yaml

@@ -1,59 +0,0 @@
-name: analyze-docs-relevance
-description: Analyze which documents in the documentation structure are relevant to the user query
-instructions: |
-  You are an AI assistant that analyzes the relevance between a user query and documents in a documentation structure.
-
-  <document_structure>
-  {{ originalDocumentStructure }}
-  </document_structure>
-
-  <user-query>
-  {{ query }}
-  </user-query>
-
-  Given a user query and a documentation structure containing multiple documents, your task is to:
-  1. Understand the user's search intent from the query
-  2. Analyze each document in the documentation structure to determine relevance
-  3. Return a list of relevant documents with their paths, titles, and descriptions
-
-  Consider the following factors for relevance:
-  - Semantic similarity between query and document title/description
-  - Topic alignment
-  - User intent matching
-  - Content scope overlap
-
-  Return only the most relevant documents (top 5-10) to avoid overwhelming results.
-
-  Format your response as a JSON object with:
-  - relevantDocs: array of relevant document paths
-  - reasoning: brief explanation of why these documents were selected
-input_schema:
-  type: object
-  properties:
-    query:
-      type: string
-      description: User search query
-    originalDocumentStructure:
-      type: array
-      items:
-        type: object
-        properties:
-          path:
-            type: string
-          title:
-            type: string
-          description:
-            type: string
-      description: Documentation Structure containing all available documents
-output_schema:
-  type: object
-  properties:
-    relevantDocPaths:
-      type: array
-      items:
-        type: string
-        description: Must be selected from paths in the documentation structure, cannot be other paths
-      description: List of relevant documents
-    reasoning:
-      type: string
-      description: Brief explanation of document selection

package/docs-mcp/docs-search.yaml

@@ -1,42 +0,0 @@
-type: team
-name: docs-search
-description: Search relevant documents based on user query
-skills:
-  - url: ../agents/init/index.mjs
-    default_input:
-      skipIfExists: true
-  - ../agents/utils/load-sources.mjs
-  - analyze-docs-relevance.yaml
-  - read-doc-content.mjs
-  - analyze-content-relevance.yaml
-includeInputInOutput: false
-input_schema:
-  type: object
-  properties:
-    query:
-      type: string
-      description: User search query
-      required: true
-    config:
-      type: string
-      description: Path to the config file
-      default: ./.aigne/doc-smith/config.yaml
-output_schema:
-  type: object
-  properties:
-    relevantContent:
-      type: string
-      description: AI analyzed relevant content from documents
-    relevantDocs:
-      type: array
-      items:
-        type: object
-        properties:
-          path:
-            type: string
-          title:
-            type: string
-          description:
-            type: string
-      description: List of relevant documents from documentation structure
-mode: sequential

package/docs-mcp/get-docs-detail.mjs

@@ -1,41 +0,0 @@
-import fs from "node:fs/promises";
-import path from "node:path";
-
-const docsDir = path.join(process.cwd(), "./.aigne/doc-smith", "docs");
-
-export default async function getDocDetail({ path: docPath }) {
-  try {
-    // Flatten path: remove leading /, replace all / with - (same logic as utils.mjs)
-    const flatName = docPath.replace(/^\//, "").replace(/\//g, "-");
-    const fileFullName = `${flatName}.md`;
-    const filePath = path.join(docsDir, fileFullName);
-
-    // Read the markdown file
-    const content = await fs.readFile(filePath, "utf8");
-
-    return {
-      success: true,
-      path: docPath,
-      content,
-      filePath,
-    };
-  } catch (error) {
-    return {
-      success: false,
-      path: docPath,
-      error: error.message,
-    };
-  }
-}
-
-getDocDetail.input_schema = {
-  type: "object",
-  properties: {
-    path: {
-      type: "string",
-      description: "The path of the docs to get detail",
-    },
-  },
-};
-
-getDocDetail.description = "Get single docs detail";

package/docs-mcp/get-docs-structure.mjs

@@ -1,16 +0,0 @@
-import fs from "node:fs/promises";
-import path from "node:path";
-
-const structureDir = path.join(
-  process.cwd(),
-  "./.aigne/doc-smith",
-  "output",
-  "structure-plan.json",
-);
-
-export default async function getDocsStructure() {
-  const structure = await fs.readFile(structureDir, "utf-8");
-  return { structure };
-}
-
-getDocsStructure.description = "Get documentation structure";

package/docs-mcp/read-doc-content.mjs

@@ -1,119 +0,0 @@
-import fs from "node:fs/promises";
-import path from "node:path";
-
-const docsDir = path.join(process.cwd(), "./.aigne/doc-smith", "docs");
-
-/**
- * Remove base64 encoded images from markdown content
- * This prevents large binary data from being included in document content
- * Base64 images are completely removed (not replaced with placeholders) because:
- * 1. They significantly increase token usage without providing useful information to LLM
- * 2. Normal image references (file paths) are preserved and should be used instead
- * 3. Base64 images are typically temporary or erroneous entries
- *
- * @param {string} content - Markdown content that may contain base64 images
- * @returns {string} - Content with base64 images completely removed
- */
-function removeBase64Images(content) {
-  if (!content || typeof content !== "string") {
-    return content;
-  }
-
-  // Match markdown image syntax with data URLs: ![alt](data:image/...;base64,...)
-  const base64ImageRegex = /!\[([^\]]*)\]\(data:image\/[^)]+\)/g;
-
-  // Completely remove base64 images (including the entire markdown image syntax)
-  // This maximizes token reduction while preserving normal image references
-  const cleanedContent = content.replace(base64ImageRegex, "");
-
-  return cleanedContent;
-}
-
-export default async function readDocContent({ relevantDocPaths, docsDir: customDocsDir }) {
-  const targetDocsDir = customDocsDir || docsDir;
-  const docContents = [];
-
-  for (const docPath of relevantDocPaths) {
-    try {
-      // Flatten path: remove leading /, replace all / with - (same logic as utils.mjs)
-      const flatName = docPath.replace(/^\//, "").replace(/\//g, "-");
-      const fileFullName = `${flatName}.md`;
-      const filePath = path.join(targetDocsDir, fileFullName);
-
-      // Read the markdown file
-      let content = await fs.readFile(filePath, "utf8");
-
-      // Remove base64 encoded images to reduce token usage
-      content = removeBase64Images(content);
-
-      docContents.push({
-        success: true,
-        path: docPath,
-        content,
-        filePath,
-      });
-    } catch (error) {
-      docContents.push({
-        success: false,
-        path: docPath,
-        error: error.message,
-      });
-    }
-  }
-
-  // Combine all successful document contents into a single text
-  const allDocumentsText = docContents
-    .filter((doc) => doc.success)
-    .map((doc) => doc.content)
-    .join("\n\n---\n\n");
-
-  return {
-    docContents,
-    allDocumentsText,
-    totalDocs: relevantDocPaths.length,
-    successfulReads: docContents.filter((doc) => doc.success).length,
-  };
-}
-
-readDocContent.input_schema = {
-  type: "object",
-  properties: {
-    relevantDocPaths: {
-      type: "array",
-      items: { type: "string" },
-      description: "List of document paths to read",
-    },
-    docsDir: {
-      type: "string",
-      description: "Custom docs directory path (optional)",
-    },
-  },
-  required: ["relevantDocPaths"],
-};
-
-readDocContent.output_schema = {
-  type: "object",
-  properties: {
-    docContents: {
-      type: "array",
-      items: {
-        type: "object",
-        properties: {
-          success: { type: "boolean" },
-          path: { type: "string" },
-          content: { type: "string" },
-          filePath: { type: "string" },
-          error: { type: "string" },
-        },
-      },
-    },
-    allDocumentsText: {
-      type: "string",
-      description: "Combined text content of all successfully read documents",
-    },
-    totalDocs: { type: "number" },
-    successfulReads: { type: "number" },
-  },
-};
-
-readDocContent.description = "Read markdown content for multiple documents";

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

@@ -1,20 +0,0 @@
-Target Audience: {{targetAudience}}
-
-Content Generation Rules:
-
-- Use only information from `<detail_data_source>`, 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 `<document_structure>` to avoid duplication and highlight this {{nodeName}}'s unique value
-{% if enforceInfoCompleteness %}
-- If `<detail_data_source>` 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}}
-- Maintain a strict, sequential heading hierarchy; no skipping (e.g., no jump from level-1 to level-3).
-- 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 `<detail_data_source>` in output, your content is for user consumption, and users are unaware of detailDataSource
-- 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/markdown-syntax-rules.md

@@ -1,65 +0,0 @@
-<markdown_syntax_rules>
-
-## Markdown Syntax Standard
-
-### Allowed Syntax
-
-**Inline** (used within text):
-
-- Emphasis: `**bold**`, `*italic*`, `~~strikethrough~~`
-- Links: `[text](url)`
-- Images: `![alt](url)`
-- Inline Code: `` `code` ``
-
-**Block** (standalone blocks):
-
-- Headings: `#`, `##`, `###`, etc.
-- Lists: `- item`, `1. item`
-- Task Lists: `- [ ]`, `- [x]`
-- Blockquotes: `> quote`
-- Code Block: ` ```language ... ``` `
-- Tables: `| col | col |` with `|---|---|` separator
-- Horizontal Rule: `---`
-- Admonition: `:::severity ... :::`
-
-### Prohibited Syntax
-
-The following are **strictly forbidden**:
-
-- Footnotes: `[^1]: note text`
-- Math/LaTeX: `$inline$`, `$$ block $$`
-- Highlight: `==highlighted==`
-- Subscript/Superscript: `H~2~O`, `X^2^`
-- Abbreviations: `*[HTML]: Hyper Text Markup Language`
-
-### Link Rules
-
-- Links must reference valid external URLs or paths from the document structure
-- Use absolute paths from the documentation structure for internal links
-
-### Table Formatting Rules
-
-- Separator row (`|---|---|---|`) must match the exact column count of header row
-- Each row must have the same number of columns
-- Use tables for predefined values (e.g., status types, options) or term definitions
-- Validate table structure before output
-
-### Code Block Rules
-
-- Ensure code blocks are properly closed
-- Generate complete, syntactically correct code (JSON, etc.)
-- Perform self-validation to ensure all code blocks, lists, and tables are properly closed without truncation
-
-### Block-Level Elements
-
-Block-level elements are standalone content blocks that must be visually separated from surrounding content.
-
-Block-Level Element List:
-
-- Admonition: `:::severity ... :::`
-- Code Block: ` ```language ... ``` `
-- Custom Components: `<x-cards>`, `<x-card>`, `<x-field-group>`, etc.
-
-**Spacing Rule:** Always insert a blank line before and after any block-level element when it is **adjacent to** other Markdown content (headings, paragraphs, lists, etc.).
-
-</markdown_syntax_rules>

package/prompts/common/document/media-file-list-usage-rules.md

@@ -1,18 +0,0 @@
-<media_file_list_usage_rules>
-
-## Media File List Usage Rules
-
-You must use the provided `<media_file_list>` data to determine which media files to use and where to insert them.
-
-### Usage Workflow
-
-1. Read the `<media_file_list>` data and take note of each file's `path` and `description` as references.
-2. Combine those descriptions with the current document's content to decide which images should be used and where they should be inserted.
-3. Confirm that every inserted image path comes from `<media_file_list>`. If a path is missing from that list, replace it with one that is included.
-
-### Usage Requirements
-- Insert images with Markdown syntax: `![Descriptive alt text](<path-from-media_file_list>)`.
-- Never invent, reinterpret, fabricate, normalize, or rewrite any media file path under any circumstances.
- - After inserting a media file, update the surrounding document text to introduce, reference, or describe the media, so the media is properly integrated and its purpose is clear to readers.
-
-</media_file_list_usage_rules>

package/prompts/common/document/openapi-usage-rules.md

@@ -1,189 +0,0 @@
-{% if openAPISpec %}
-<openapi_usage_rules>
-## OpenAPI Usage Rules
-
-Use the provided OpenAPI (Swagger) specification in `<openapi_usage_rules>`, align it with the current page objective, and leverage it to refine this document.
-
-### Documentation Requirements and Constraints
-
-- Extract the core content
-  - Organize the document by functional modules.
-  - For each path item, include the following elements:
-    - HTTP method and path.
-    - Concise summary.
-    - Detailed description.
-    - Request parameters: name, location (`in`), type, required flag, description.
-    - Request body: describe its structure when present.
-    - Response body: describe its structure, ignore status code layer.
-    - Response Example: provide example responses for common scenarios
-
-- Mandatory API description constraints (deduplication rule):
-  - **Ensure** that throughout the document (including preface, overview, etc.), any introduction to the project APIs appears only within this OpenAPI-generated "API reference" section.
-  - **Never** repeat or expand the interface list elsewhere in the document (for example, "Quick Start" or "Architecture Overview" sections).
-
-### Expected Output Format
-- A concise, clear, and easy-to-scan Markdown document.
-
-### Examples
-#### OpenAPI Spec Content
-```yml
-openapi: 3.0.1
-info:
-  title: DISCUSS KIT
-  description: ''
-  version: 1.0.0
-paths:
-  /api/v1/sdk/posts:
-    get:
-      summary: List posts
-      deprecated: false
-      description: 'List posts'
-      parameters:
-        - name: type
-          in: query
-          description: 'The type of the posts'
-          required: false
-          example: blog
-          schema:
-            type: string
-            enum:
-              - discussion
-              - blog
-              - doc
-        - name: locale
-          in: query
-          description: 'The locale of the posts'
-          required: false
-          example: en
-          schema:
-            type: string
-            default: en
-            examples:
-              - en
-              - zh
-        - name: page
-          in: query
-          description: 'The page number'
-          required: false
-          example: 1
-          schema:
-            type: integer
-        - name: size
-          in: query
-          description: 'The number of posts per page'
-          required: false
-          example: 20
-          schema:
-            type: integer
-        - name: sort
-          in: query
-          description: 'The sort order of the posts'
-          required: false
-          example: '-createdAt'
-          schema:
-            type: string
-            enum:
-              - createdAt
-              - '-createdAt'
-        - name: labels
-          in: query
-          description: 'The labels of the posts'
-          required: false
-          example:
-            - did
-          schema:
-            type: array
-            items:
-              type: string
-            nullable: true
-      responses:
-        '200':
-          description: succeed
-          content:
-            application/json:
-              schema:
-                type: object
-                properties:
-                  data:
-                    type: array
-                    items:
-                      type: object
-                      properties: {}
-                  meta:
-                    type: object
-                    properties:
-                      total:
-                        type: integer
-                    required:
-                      - total
-                required:
-                  - data
-                  - meta
-```
-
-#### Generate Output
-````md
-### Posts
-
-### List posts
-
-Retrieves a list of posts, which can be filtered by type, locale, and other criteria. This endpoint supports pagination.
-
-`GET` `/api/v1/sdk/posts`
-
-#### Parameters
-
-<x-field-group>
-  <x-field data-name="type" data-type="string" data-required="false" data-default="blog">
-    <x-field-desc markdown>The type of posts to retrieve. Can be `discussion`, `blog`, or `doc`.</x-field-desc>
-  </x-field>
-  <x-field data-name="locale" data-type="string" data-required="false" data-default="en">
-    <x-field-desc markdown>The locale of the posts, e.g., `en` or `zh`.</x-field-desc>
-  </x-field>
-  <x-field data-name="page" data-type="integer" data-required="false">
-    <x-field-desc markdown>The page number for pagination.</x-field-desc>
-  </x-field>
-  <x-field data-name="size" data-type="integer" data-required="false" data-default="20">
-    <x-field-desc markdown>The number of posts to return per page.</x-field-desc>
-  </x-field>
-  <x-field data-name="sort" data-type="string" data-required="false" data-default="-createdAt">
-    <x-field-desc markdown>The sort order for the posts. Use `createdAt` for ascending or `-createdAt` for descending.</x-field-desc>
-  </x-field>
-  <x-field data-name="labels" data-type="array" data-required="false">
-    <x-field-desc markdown>An array of label strings to filter posts by.</x-field-desc>
-  </x-field>
-</x-field-group>
-
-#### Responses
-
-<x-field-group>
-  <x-field data-name="data" data-type="array" data-required="true">
-    <x-field-desc markdown>An array of post objects.</x-field-desc>
-  </x-field>
-  <x-field data-name="meta" data-type="object" data-required="true">
-    <x-field-desc markdown>Metadata for pagination.</x-field-desc>
-    <x-field data-name="total" data-type="integer" data-required="true" data-desc="The total number of posts available."></x-field>
-  </x-field>
-</x-field-group>
-
-#### Response Example
-
-```json posts result
-{
-  "data": [
-    {
-      "id": "15bcb4e7-8bd9-4759-b60b-ae826534057a",
-      "title": "Example Blog Post",
-      "content": "This is the content of the blog post.",
-      "createdAt": "2023-10-27T10:00:00Z"
-    }
-  ],
-  "meta": {
-    "total": 1
-  }
-}
-```
-````
-
-</openapi_usage_rules>
-{% endif %}

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

@@ -1,16 +0,0 @@
-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.
-  - Tool Usage Capability: You can call available tools as needed based on context to query information, gather data, or generate visuals, ensuring the documentation is accurate, complete, and visually clear.
-
-**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.
-5.  **Tool Utilization:** Actively call tools as needed, potentially multiple times, to obtain complete information from AFS (AIGNE File System).

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

@@ -1,9 +0,0 @@
-{% 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

@@ -1,16 +0,0 @@
-<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.
-
-Core principles for conflict resolution:
-1. **Layered need satisfaction**: Simultaneously satisfy multiple purposes and audiences through reasonable documentation 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 documentation structure, prioritize conflict resolution strategies to ensure the final structure can harmoniously satisfy all user needs.
-</conflict_resolution_guidance>