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

package/prompts/common/document-structure/document-icon-generate.md

@@ -1,116 +0,0 @@
-# Document Icon Generation
-
-<role>
-You are an icon selection specialist. Your task is to generate appropriate Iconify icon names for document structure root nodes based on their title and description. The icon should semantically match the document's purpose and content to provide better visual identification.
-</role>
-
-<input>
-
-- documentList: {{documentList}}
-
-</input>
-
-<icon_generation_rules>
-
-**Core Requirements:**
-
-1. **Icon Format:**
-   - Must be a valid **Lucide icon name** in the format: `lucide:icon-name`
-   - Examples: `lucide:book`, `lucide:rocket`, `lucide:code`, `lucide:settings`
-   - **Only Lucide icons are supported** - do not use other icon collections
-
-3. **Icon Selection Guidelines:**
-   - Choose icons that **semantically match** the document's purpose and content based on both title and description
-   - Analyze the combined meaning of title and description to understand the document's purpose
-   - Consider the **target audience** and **document type** when selecting icons
-
-4. **Icon Categories and Suggestions:**
-
-   **General Documentation:**
-   - `lucide:book` - General documentation, guides
-   - `lucide:file-text` - Text documents, articles
-   - `lucide:book-open` - Reading materials, tutorials
-   - `lucide:library` - Reference materials
-
-   **Getting Started & Quick Start:**
-   - `lucide:rocket` - Quick start, getting started guides
-   - `lucide:play-circle` - Getting started, tutorials
-   - `lucide:zap` - Quick start, fast setup
-   - `lucide:sparkles` - Quick start, new features
-
-   **API & Code References:**
-   - `lucide:code` - API documentation, code references
-   - `lucide:file-code-2` - Code files, programming guides
-   - `lucide:terminal` - Command-line interfaces, CLI tools
-   - `lucide:git-branch` - Version control, development
-   - `lucide:brackets` - Code syntax, programming
-
-   **Configuration & Settings:**
-   - `lucide:settings` - Configuration guides, settings
-   - `lucide:cog` - Configuration, setup
-   - `lucide:wrench` - Tools, configuration
-   - `lucide:sliders` - Settings, preferences
-
-   **Tutorials & Learning:**
-   - `lucide:graduation-cap` - Learning materials, tutorials
-   - `lucide:lightbulb` - Tips, tutorials, guides
-   - `lucide:book-open` - Learning, reading
-   - `lucide:school` - Educational content
-
-   **Project & Overview:**
-   - `lucide:folder-open` - Project overview, structure
-   - `lucide:layers` - Architecture, structure
-   - `lucide:package` - Packages, modules
-   - `lucide:box` - Components, modules
-
-   **User & Community:**
-   - `lucide:users` - User guides, community
-   - `lucide:user` - User documentation
-   - `lucide:help-circle` - Help, FAQ
-   - `lucide:message-circle` - Communication, chat
-
-   **Security & Admin:**
-   - `lucide:shield` - Security, protection
-   - `lucide:key` - Authentication, access
-   - `lucide:lock` - Security, privacy
-   - `lucide:shield-check` - Security verification
-
-   **Deployment & Operations:**
-   - `lucide:cloud` - Cloud services, deployment
-   - `lucide:server` - Server, infrastructure
-   - `lucide:database` - Database, data
-   - `lucide:network` - Networking, connections
-
-5. **Selection Process:**
-   - Read both title and description carefully
-   - Identify the primary purpose and content type
-   - Match to the most appropriate icon category
-   - Select the most semantically relevant Lucide icon from that category
-   - Ensure the icon clearly represents the document's purpose
-   - **Only use Lucide icons** - format must be `lucide:icon-name`
-
-6. **Important Notes:**
-   - Only generate icons for root-level documents (where parentId is null or empty)
-   - Each document should have exactly one icon
-   - Icons should be immediately recognizable and semantically clear
-   - Avoid overly generic icons when a more specific one is available
-   - Consider cultural and language context when appropriate
-
-</icon_generation_rules>
-
-<output_rules>
-
-Return a JSON object with:
-
-- `documentList`: array of document items with generated icons, each containing:
-  - `path`: the same path from input (for mapping purposes)
-  - `icon`: Lucide icon name in the format `lucide:icon-name` (e.g., `lucide:book`)
-
-Ensure each item:
-- Preserves the exact `path` value from the corresponding input item
-- Has an `icon` field with a valid Lucide icon name (format: `lucide:icon-name`)
-- The icon semantically matches the document's title and description
-- **Only uses Lucide icons** - do not use other icon collections
-
-</output_rules>
-

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

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

@@ -1,86 +0,0 @@
-# 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/glossary.md

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

@@ -1,5 +0,0 @@
-**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/openapi-usage-rules.md

@@ -1,28 +0,0 @@
-{% if userContext.openAPISpec %}
-
-<openapi_usage_rules>
-## OpenAPI Usage Rules
-
-Use the provided OpenAPI (Swagger) specification in `<openapi_spec_content>` to design how the OpenAPI content and the overall document should be structured together.
-
-### Documentation Requirements and Constraints
-
-- Section structure and titles
-  - Create a dedicated top-level section for the OpenAPI content.
-  - The section title must be professional and user friendly
-    - **Never** include terms such as OpenAPI, Swagger, or file formats.
-    - Recommended titles include **"API Interface Reference"** or **"Interface Reference"**.
-
-- Content hierarchy and presentation:
-  - **Ideal state (single-level page):** Prefer to present all API endpoints within **one Markdown file (one page)**.
-  - **Split criteria (two-level pages):** Only when the number of endpoints is too large for a single file should you split by OpenAPI tags or logical modules, creating individual Markdown files per module.
-  - **Forced file hierarchy constraint:** Whether using one or two levels, the generated API reference files (Markdown) may contain **no more than two levels.**
-    - **Example (two-level structure):** `/api-reference.md` (index) -> `/api/user.md`, `/api/order.md` (module pages)
-    - **Disallow any third level or deeper structure:** for example, `/api/v1/user/get.md`.
-
-- Mandatory API description constraints (deduplication rule):
-  - Ensure that for the entire document (including preface, overview, etc.), any introduction to the project APIs appears only within this OpenAPI-generated "API reference" section.
-  - **Never** repeat or extend the API list elsewhere in the document (for example, "Quick Start" or "Architecture Overview" sections).
-
-</openapi_usage_rules>
-{% endif %}

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

@@ -1,18 +0,0 @@
-<output_constraints>
-
-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
-
-3. **Project Information Length Constraints:**
-   - `projectName`: Must not exceed **40 characters** (counted as character length, regardless of language - Chinese, English, Russian, etc.). Keep it concise and clear. Generate a complete, meaningful name within this limit.
-   - `projectDesc`: Must not exceed **160 characters** (counted as character length, regardless of language - Chinese, English, Russian, etc.). Provide a brief, informative description. Generate a complete, coherent description within this limit.
-   - **Character counting rules:**
-     - Count all characters equally (Chinese, English, Russian, etc. - each character counts as 1)
-     - Spaces in the middle of the text count toward the character limit
-     - Leading and trailing spaces will be automatically removed, so do not include them
-   - **Important**: These are hard limits. Ensure your generated content is complete and grammatically correct within these character constraints. Do not generate content that would need truncation.
-
-</output_constraints>

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

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

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

@@ -1,9 +0,0 @@
-{% 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/admonition-usage-rules.md

@@ -1,94 +0,0 @@
-<admonition_syntax_rules>
-
-## Admonition Syntax Rules
-
-Admonition is a Markdown block extension used to highlight important information. Use it sparingly.
-
-### Syntax Structure
-
-```
-:::severity
-content
-:::
-```
-
-### Syntax Rules
-
-The `severity` is **required** and must be one of the following:
-
-- `success`: Positive outcome or best practice
-- `info`: General tips
-- `warning`: Cautions or potential issues
-- `error`: Critical risks or breaking operations
-
-The `content` is **required** and MUST strictly comply with the rules below:
-
-- The `content` MUST be plain text only
-- The `content` MUST be a single paragraph (no line breaks).
-- Nesting any blocks or Admonitions is forbidden.
-- Recommended length: within 200 characters.
-
-### Usage Guidelines
-
-- Use sparingly, only for messages that truly require user attention
-- Do not use Admonition if the content needs any Markdown syntax from <markdown_syntax_rules> — use regular paragraphs instead
-- Keep the text short, clear, and actionable
-- Choose the severity level according to the importance of the message
-
-### Good Examples
-
-1. All four severity types:
-
-```md
-:::success
-Your configuration is complete.
-:::
-
-:::info
-Environment variables can override this setting.
-:::
-
-:::warning
-This API will be removed in v3.0.
-:::
-
-:::error
-Never commit API keys to version control.
-:::
-```
-
-### Bad Examples
-1. Contains Markdown Syntax:
-
-```md
-:::info
-No **bold**, *italic*, or `inline code` allowed.
-:::
-
-:::warning
-No [links](https://example.com) allowed.
-:::
-
-:::info
-- No lists
-- Or bullet points
-:::
-
-:::error
-```sh
-npm i
-```
-:::
-```
-
-2. Multi-paragraph:
-
-```md
-:::warning
-No multi-paragraph.
-
-Like this.
-:::
-```
-
-</admonition_syntax_rules>

package/prompts/detail/custom/code-block-usage-rules.md

@@ -1,163 +0,0 @@
-<code_block_usage_rules>
-
-## Enhanced Attributes for Markdown Code Blocks
-
-When generating Markdown, you can add enhanced attributes to code blocks to provide richer functionality and better display effects. These attributes allow you to specify **titles**, **icons**, and more for code blocks.
-
-### Attribute Definition
-
-The following are the available enhanced attributes and their descriptions:
-
-- `language`: The language of the code block (e.g., `javascript`, `python`, `html`). This attribute is placed directly after the three backticks (\`\`\`).
-- `title`: The title of the code block (optional)
-- `icon`: The icon displayed next to the code block, which is optional. This value must be a valid **Iconify icon name** (e.g., `logos:javascript`, `mdi:folder-open`).
-
-### Attribute Usage
-
-- `language` and `title` are written directly after \`\`\`, separated by spaces.
-  - Do not add quotes around the `title` value.
-- Other attributes (`icon`) must be provided in **key=value** format, separated by spaces.
-
-### Usage Requirements
-- Use these enhanced attributes as much as possible to improve display effects.
-- 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.
-- Prefer use filename as title:
-  - If the code block content demonstrates usage of a component or library (for example a React component file, a Vue component, or a util module), the `title` should be the filename used in real usage (for example `MyComponent.jsx`, `index.ts`, `utils.js`). Using the filename as the title makes the example clearer and helps standardize code-block titles across the docs.
-  - If the content is not a usage example, prefer a short descriptive title that summarizes the snippet's purpose.
-- Ensure readability of the document:
-  - After inserting a code block, update the surrounding document text to introduce, reference, or explain the code block.
-
-### Examples
-
-#### Good Examples
-The following are some examples of Markdown code blocks using enhanced attributes:
-
-**Example 1: Code block with title and icon**
-
-```javascript shopping-cart.js icon=logos:javascript
-class ShoppingCart {
-  constructor() {
-    this.items = [];
-    this.discounts = [];
-    this.taxRate = 0.08;
-  }
-}
-```
-
-**Example 2: Code block with icon only**
-
-```javascript icon=logos:javascript
-class ShoppingCart {
-  constructor() {
-    this.items = [];
-    this.discounts = [];
-    this.taxRate = 0.08;
-  }
-}
-```
-
-**Example 3: Code block with title only**
-
-```javascript shopping-cart.js
-class ShoppingCart {
-  constructor() {
-    this.items = [];
-    this.discounts = [];
-    this.taxRate = 0.08;
-  }
-}
-```
-
-**Example 4: Basic code block**
-
-```javascript
-class ShoppingCart {
-  constructor() {
-    this.items = [];
-    this.discounts = [];
-    this.taxRate = 0.08;
-  }
-}
-```
-
-**Example 7: Component usage example with filename title**
-
-```javascript MyComponent.jsx icon=logos:react
-import React from 'react';
-
-export default function MyComponent(props) {
-  return (
-    <div className="my-component">
-      <h1>{props.title}</h1>
-    </div>
-  );
-}
-```
-
-**Example 8: Utility module example with filename title**
-
-```javascript utils.js
-// simple utility function exported from utils.js
-export function formatDate(date) {
-  return new Date(date).toLocaleDateString();
-}
-```
-
-**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
-```
-
-
-#### Bad Examples
-
-**Example 1**
-
-There are two errors in this example:
-- Language name should not include suffixes like ',no_run' in the example
-- Title does not need a key specified; just configure the value directly
-
-```rust,no_run title="main.rs" icon=logos:rust
-use tokio::runtime::Runtime;
-use tokio::net::TcpListener;
-
-fn main() -> Result<(), Box<dyn std::error::Error>> {
-    // Create the runtime
-    let rt  = Runtime::new()?;
-
-    // Spawn the root task
-    rt.block_on(async {
-        let listener = TcpListener::bind("127.0.0.1:8080").await.unwrap();
-        println!("Listening on: {}", listener.local_addr().unwrap());
-        // ... application logic ...
-    });
-    Ok(())
-}
-```
-
-**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_usage_rules>

package/prompts/detail/custom/custom-components/x-card-usage-rules.md

@@ -1,63 +0,0 @@
-<x-card-usage-rules>
-## XCard Usage Rules
-
-XCard is individual link display card, suitable for displaying individual links with a richer and more visually appealing presentation format.
-
-### Attributes
-
-- `data-title` (required): Card title.
-- `data-icon` (optional): Icon identifier (e.g., lucide:icon-name or material-symbols:rocket-outline).
-  - Icons should prioritize Lucide (lucide:icon-name). If not available in Lucide, use Iconify (collection:icon-name, e.g., material-symbols:rocket-outline).
-- `data-image` (optional): Image URL, can coexist with icon.
-  - Prefer to use image url from `<media_file_list>`.
-  - **Requirement**: At least one of `data-icon` or `data-image` must be provided.
-  - It's recommended to always provide data-icon.
-- `data-href` (optional): Navigation link for clicking the card or button.
-- `data-horizontal` (optional): Whether to use horizontal layout.
-- `data-cta` (optional): Button text (call to action).
-
-### Children
-
-- Must be written within `<x-card>...</x-card>` children.
-- Plain Text Only: Do not use any Markdown syntax (see `<markdown_syntax_rules>` for the full list).
-
-### Good Examples
-
-- Example 1: Basic card with icon and description
-  ```md
-    <x-card data-title="alarm()" data-icon="lucide:alarm-clock"> SIGALRM: Sent when a real-time timer has expired. </x-card>
-  ```
-
-- Example 2: Horizontal card layout
-  ```md
-  <x-card data-title="Horizontal card" data-icon="lucide:atom" data-horizontal="true">
-  This is an example of a horizontal card.
-  </x-card>
-  ```
-
-### Bad Examples
-
-- Example 1: Inline Markdown formatting in card content
-  ```md
-  <x-card data-title="alarm()" data-icon="lucide:alarm-clock"> `SIGALRM`: Sent when a real-time timer has expired. </x-card>
-  ```
-
-- Example 2: Code block inside card content
-  ````md
-  <x-card data-title="ctrl_break()" data-icon="lucide:keyboard">
-  Creates a listener for "ctrl-break" events.
-
-  ```rust
-  use tokio::signal::windows::ctrl_break;
-
-  #[tokio::main]
-  async fn main() -> std::io::Result<()> {
-  let mut stream = ctrl_break()?;
-  stream.recv().await;
-  println!("got ctrl-break");
-  Ok(())
-  }
-  ```
-
-  ````
-</x-card-usage-rules>