@aigne/doc-smith 0.8.14 → 0.8.15-beta.1

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

@@ -913,6 +913,28 @@ Ensure that the shape names used in connections are accurate and match the actua
 - **Good Practice:**
   ```d2
   shape: sequence_diagram
+  User: { 
+    shape: c4-person 
+  }
+
+  App: {
+    label: "Your Application"
+    shape: rectangle
+
+    ResumeSubscription: {
+      label: "ResumeSubscription Component"
+    }
+  }
+
+  Payment-API: {
+    label: "Payment Backend API"
+    shape: rectangle
+  }
+
+  DID-Wallet: {
+    label: "DID Wallet"
+    icon: "https://www.arcblock.io/image-bin/uploads/37198ddc4a0b9e91e5c1c821ab895a34.svg"
+  }
 
   User -> App.ResumeSubscription: "1. Triggers resume action"
 
@@ -922,12 +944,16 @@ Ensure that the shape names used in connections are accurate and match the actua
   App.ResumeSubscription.t1 -> User: "4. Display confirmation dialog"
   User -> App.ResumeSubscription.t1: "5. Clicks 'Confirm'"
 
-  App.ResumeSubscription.t1 -> DID-Wallet: "6a. Open 're-stake' session"
-  User -> DID-Wallet: "7a. Approve in wallet"
-  DID-Wallet -> App.ResumeSubscription.t1: "8a. Send success callback"
+  "If Re-Staking is Required": {
+    App.ResumeSubscription.t1 -> DID-Wallet: "6a. Open 're-stake' session"
+    User -> DID-Wallet: "7a. Approve in wallet"
+    DID-Wallet -> App.ResumeSubscription.t1: "8a. Send success callback"
+  }
 
-  App.ResumeSubscription.t1 -> Payment-API: "6b. Call recover endpoint\n(PUT /recover)"
-  Payment-API -> App.ResumeSubscription.t1: "7b. Return success"
+  "If No Staking is Required": {
+    App.ResumeSubscription.t1 -> Payment-API: "6b. Call recover endpoint\n(PUT /recover)"
+    Payment-API -> App.ResumeSubscription.t1: "7b. Return success"
+  }
 
   App.ResumeSubscription.t1 -> Payment-API: "9. Fetch updated subscription details"
   Payment-API -> App.ResumeSubscription.t1: "10. Return latest subscription"
@@ -1086,12 +1112,12 @@ Ensure that the shape names used in connections are accurate and match the actua
   Blocklet-Service -> Application.Auth-Middleware: "4. Return permissions"
   Application.Auth-Middleware -> Application.Auth-Middleware: "5. Evaluate all rules"
 
-  "If Authorized" {
+  "If Authorized": {
     Application.Auth-Middleware -> Application.Protected-Route: "6a. next()"
     Application.Protected-Route -> Client: "7a. 200 OK Response"
   }
 
-  "If Forbidden" {
+  "If Forbidden": {
     Application.Auth-Middleware -> Client: "6b. 403 Forbidden Response"
   }
   ```

package/prompts/detail/generate/detail-example.md

@@ -80,7 +80,9 @@ Here are some high-quality documentation details for your reference:
 
   **Returns**
 
-  <x-field data-name="product" data-type="TProductExpanded" data-desc="The newly created product object, including expanded details"></x-field>
+  <x-field-group>
+    <x-field data-name="product" data-type="TProductExpanded" data-desc="The newly created product object, including expanded details"></x-field>
+  </x-field-group>
 
   **Example**
 
@@ -130,11 +132,15 @@ Here are some high-quality documentation details for your reference:
 
   **Parameters**
 
-  <x-field data-name="id" data-type="string" data-required="true" data-desc="The unique identifier of the product to retrieve."></x-field>
+  <x-field-group>
+    <x-field data-name="id" data-type="string" data-required="true" data-desc="The unique identifier of the product to retrieve."></x-field>
+  </x-field-group>
 
   **Returns**
 
-  <x-field data-name="product" data-type="TProductExpanded" data-desc="The retrieved product object, including expanded details."></x-field>
+  <x-field-group>
+    <x-field data-name="product" data-type="TProductExpanded" data-desc="The retrieved product object, including expanded details."></x-field>
+  </x-field-group>
 
   **Example**
 
@@ -176,7 +182,9 @@ Here are some high-quality documentation details for your reference:
 
   **Returns**
 
-  <x-field data-name="product" data-type="TProductExpanded" data-desc="The updated product object."></x-field>
+  <x-field-group>
+    <x-field data-name="product" data-type="TProductExpanded" data-desc="The updated product object."></x-field>
+  </x-field-group>
 
   **Example**
 
@@ -341,11 +349,15 @@ Here are some high-quality documentation details for your reference:
 
   **Parameters**
 
-  <x-field data-name="id" data-type="string" data-required="true" data-desc="The unique identifier of the product to archive."></x-field>
+  <x-field-group>
+    <x-field data-name="id" data-type="string" data-required="true" data-desc="The unique identifier of the product to archive."></x-field>
+  </x-field-group>
 
   **Returns**
 
-  <x-field data-name="product" data-type="TProduct" data-desc="The archived product object."></x-field>
+  <x-field-group>
+    <x-field data-name="product" data-type="TProduct" data-desc="The archived product object."></x-field>
+  </x-field-group>
 
   **Example**
 
@@ -380,11 +392,15 @@ Here are some high-quality documentation details for your reference:
 
   **Parameters**
 
-  <x-field data-name="id" data-type="string" data-required="true" data-desc="The unique identifier of the product to delete."></x-field>
+  <x-field-group>
+    <x-field data-name="id" data-type="string" data-required="true" data-desc="The unique identifier of the product to delete."></x-field>
+  </x-field-group>
 
   **Returns**
 
-  <x-field data-name="product" data-type="TProduct" data-desc="The deleted product object."></x-field>
+  <x-field-group>
+    <x-field data-name="product" data-type="TProduct" data-desc="The deleted product object."></x-field>
+  </x-field-group>
 
   **Example**
 

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

@@ -7,18 +7,17 @@ Documentation Generation Rules:
 - 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
+- **Markdown Syntax Constraint**: Use only GitHub Flavored Markdown (GFM) syntax by default. Prohibited extensions include: custom blocks `:::`, footnotes `[^1]: notes`, math formulas `$$ LaTeX`, highlighted text `==code==`, and other non-GFM syntax unless explicitly defined in custom component rules
 - 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 documentation structure**—use absolute paths from the documentation structure
 - 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
 - Maintain content completeness and logical flow so users can follow the documentation seamlessly
 - Provide comprehensive explanations for configuration options and parameters. When parameters accept multiple values, explain each option's purpose and include code examples where applicable
-- Use the `<x-field>` custom component only for displaying structured object data such as API parameters, return values, network request body/query/headers, and complex object properties (e.g., ContextType). This component does not exist independently but represents complete object structures
-- Do not use `<x-field>` for individual field descriptions (e.g., name or version in package.json, logo or appUrl in config.yaml) - use regular Markdown text instead
-- Wrap the outermost `<x-field>` elements with `<x-field-group>` when describing multiple properties of the same object, even if there's only one `<x-field>` element
-- Use recursive `<x-field>` structures to fully express complex object type hierarchies, decomposing all nested properties into more fundamental types. Limit nesting to 5 levels maximum
 - All interface and method documentation must include **response data examples**
-- For simple list data, use Markdown tables to present information clearly and improve readability
+- **Use `<x-field-group>` for all structured data**: Represent objects with nested `<x-field>` elements, and expand each structure to the **deepest relevant level**.
+- **Enhance field descriptions with example values**: For structured data defined using `<x-field-group>`, extract example values from type definitions, comments, or test cases to make documentation more practical and user-friendly.
+- **Use Markdown tables** for predefined values (e.g., status types, options) or term definitions to improve clarity and allow side-by-side comparison.
 - Validate output Markdown for completeness, ensuring tables are properly formatted
 - **Content Integrity**: Generate complete, syntactically correct code blocks (JSON, etc.). Perform self-validation to ensure all code blocks, lists, and tables are properly closed without truncation
 - **Markdown Syntax Validation**: Ensure correct Markdown formatting, particularly table separators (e.g., `|---|---|---|`) that match column counts

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

@@ -27,6 +27,43 @@
 
 </datasources>
 
+{% if openAPISpec %}
+<openapi>
+
+**Goal:** Use the provided OpenAPI (Swagger) specification, align it with the current page objective, and leverage it to refine this document.
+
+**OpenAPI File Content:** 
+<openapi_doc>
+
+{{ openAPISpec }}
+
+</openapi_doc>
+
+---
+
+### **Documentation Requirements and Constraints**
+
+1.  **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.
+        * Responses: at least the key status codes (e.g., 200, 201, 400, 500) and their schemas.
+
+2.  **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.
+
+</openapi>
+{% endif %}
+
 
 {% include "./detail-example.md" %}
 

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

@@ -12,6 +12,40 @@
 {{ datasources }}
 </datasources>
 
+{% if userContext.openAPISpec %}
+<openapi>
+
+**Goal:** Use the provided OpenAPI (Swagger) specification to design how the OpenAPI content and the overall document should be structured together.
+
+**OpenAPI File Content:** 
+<openapi_doc>
+
+{{ userContext.openAPISpec }}
+
+</openapi_doc>
+
+---
+
+### **Documentation Requirements and Constraints**
+
+1.  **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"**.
+
+2.  **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`.
+
+3.  **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>
+{% endif %}
+
 
 {% if originalDocumentStructure %}
 <last_document_structure>

package/prompts/translate/code-block.md

@@ -1,16 +1,23 @@
 <code_block_rules>
 The following formats are considered Code Blocks:
-  - Wrapped with ```
-  - Supports configurations: language, title, icon, where title and icon are optional
-  - content can be code, command line examples, text or any other content
+
+- Wrapped with ```
+- Supports configurations: language, title, icon, where title and icon are optional
+- content can be code, command line examples, text or any other content
 
 <code_block_sample>
+
 ```{language} [{title}] [icon={icon}]
 {content}
 ```
+
 </code_block_sample>
 
-Code Block Translation: 
-- For D2 code blocks, only translate labels
-- For other language code blocks, **only translate comments starting with #, keep all other content unchanged without translation**
-</code_block_rules>
+Code Block Translation Rules:
+
+- For D2 code blocks, translate **labels only**; leave all variable names, component names, and syntax unchanged.
+- Translate **comments only** using the language-specific comment syntax; **preserve** all code, variables, functions, and syntax.
+- **Do not translate** command examples, terminal/log outputs, or runtime output.
+- **Preserve** all formatting, indentation, and code block structure.
+
+</code_block_rules>

package/prompts/translate/translate-document.md

@@ -9,6 +9,7 @@ Core Mandates:
 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.**
+
 </role_and_goal>
 
 <translation_rules>
@@ -19,11 +20,12 @@ Translation Requirements:
 - Strictly Protect Markdown Syntax: All Markdown syntax characters, including but not limited to `|` and `-` in tables, `*` and `-` in lists, `#` in headings, `` ` `` in code blocks, etc., must be **copied exactly**, with no modification, addition, deletion, or merging. Table separators (e.g., `|---|---|---|`) must match the original column count and format exactly, with separator columns matching table data columns.
 - Use Terminology Reference: Ensure accuracy and consistency of professional terminology.
 - Preserve Terms: Retain specific terms in their original form, avoiding translation.
+- Maintain tone consistency: use a neutral tone for developer/DevOps docs, a polite tone for end-user/client docs, and do not mix address styles (e.g., **"you"** vs **"您"**).
+- Translate Descriptions Only in <x-field>: All `<x-field>` component attributes must maintain the original format. Only translate the description content within `data-desc` attribute or `<x-field-desc>` elements.
 
 {% include "./code-block.md" %}
 </translation_rules>
 
-
 {% if feedback %}
 <translation_user_feedback>
 {{ feedback }}
@@ -41,10 +43,11 @@ Translation Requirements:
 {{userPreferences}}
 
 User preference guidelines:
+
 - User preferences are derived from feedback provided in previous user interactions. When generating translations, consider user preferences to avoid repeating issues mentioned in user feedback
 - User preferences carry less weight than current user feedback
-</user_preferences>
-{% endif %}
+  </user_preferences>
+  {% endif %}
 
 {% include "./glossary.md" %}
 
@@ -58,7 +61,7 @@ Terms to preserve (do not translate):
 
 <example>
 <example_item>
-**Special Note**: Keep table separators `|---|---|---|` unchanged from the original
+Table Translation - Demonstrates how to translate table content while preserving markdown structure and separators.
 
 <before_translate>
 | Name | Type | Description |
@@ -77,7 +80,8 @@ Terms to preserve (do not translate):
 </example_item>
 
 <example_item>
-**Special Note**: All x-field component attributes must maintain the original format. Only translate the description content within data-desc attributes or x-field-desc elements
+XField Component Translation - Shows how to translate only description content within x-field components while preserving all attributes.
+
 <before_translate>
 
 <x-field data-name="teamDid" data-type="string" data-required="true" data-desc="The DID of the team or Blocklet managing the webhook."></x-field>
@@ -96,9 +100,10 @@ Terms to preserve (do not translate):
 </example_item>
 
 <example_item>
-**Special Note**: In code blocks, only translate comments while keeping all other code content (variables, functions, syntax) unchanged
+Code Block Translation - Illustrates translating only comments in code blocks while keeping all code content unchanged.
 
 <before_translate>
+
 ```xxx
 // Initialize the API client
 const client = new APIClient({
@@ -125,9 +130,11 @@ async function getUserData(userId) {
   }
 }
 ```
+
 </before_translate>
 
 <after_translate>
+
 ```xxx
 // 初始化 API 客户端
 const client = new APIClient({
@@ -154,13 +161,15 @@ async function getUserData(userId) {
   }
 }
 ```
+
 </after_translate>
 </example_item>
 
 <example_item>
-**Special Note**: **Command execution and log printing** should untranslated
+Command and Log Preservation - Demonstrates preserving command execution and log output without translation.
 
 <before_translate>
+
 ```text Timeout Error Message
 Blocklet Server failed to stop within 5 minutes
 You can stop blocklet server with blocklet stop --force
@@ -171,9 +180,11 @@ $ cli log
 
 Cache for server cleared: [list of cleared cache keys]
 ```
+
 </before_translate>
 
 <after_translate>
+
 ```text 超时错误消息
 Blocklet Server failed to stop within 5 minutes
 You can stop blocklet server with blocklet stop --force
@@ -184,6 +195,99 @@ $ cli log
 
 Cache for server cleared: [list of cleared cache keys]
 ```
+
+</after_translate>
+</example_item>
+
+<example_item>
+D2 Diagram Translation - Shows how to translate only labels in D2 diagrams while preserving all syntax and structure.
+
+<before_translate>
+
+```d2 High-Level Architecture
+direction: down
+
+User: {
+  shape: c4-person
+}
+
+Your-Application: {
+  label: "Your Application"
+  shape: rectangle
+
+  PaymentProvider: {
+    label: "PaymentProvider"
+    shape: rectangle
+
+    Payment-Components: {
+      label: "Payment Components"
+      shape: rectangle
+      grid-columns: 2
+
+      CheckoutForm: { label: "CheckoutForm" }
+      CheckoutTable: { label: "CheckoutTable" }
+      CheckoutDonate: { label: "CheckoutDonate" }
+      CustomerInvoiceList: { label: "CustomerInvoiceList" }
+    }
+  }
+}
+
+Payment-Kit-Backend: {
+  label: "Payment Kit Backend"
+  shape: cylinder
+}
+
+User -> Your-Application.PaymentProvider.Payment-Components: "Interacts with UI"
+Your-Application.PaymentProvider -> Payment-Kit-Backend: "Handles API Communication"
+Payment-Kit-Backend -> Your-Application.PaymentProvider: "Returns Data"
+Your-Application.PaymentProvider.Payment-Components -> User: "Renders UI Updates"
+
+```
+
+</before_translate>
+
+<after_translate>
+
+```d2 高层架构
+direction: down
+
+User: {
+  shape: c4-person
+}
+
+Your-Application: {
+  label: "您的应用程序"
+  shape: rectangle
+
+  PaymentProvider: {
+    label: "PaymentProvider"
+    shape: rectangle
+
+    Payment-Components: {
+      label: "支付组件"
+      shape: rectangle
+      grid-columns: 2
+
+      CheckoutForm: { label: "CheckoutForm" }
+      CheckoutTable: { label: "CheckoutTable" }
+      CheckoutDonate: { label: "CheckoutDonate" }
+      CustomerInvoiceList: { label: "CustomerInvoiceList" }
+    }
+  }
+}
+
+Payment-Kit-Backend: {
+  label: "Payment Kit 后端"
+  shape: cylinder
+}
+
+User -> Your-Application.PaymentProvider.Payment-Components: "与 UI 交互"
+Your-Application.PaymentProvider -> Payment-Kit-Backend: "处理 API 通信"
+Payment-Kit-Backend -> Your-Application.PaymentProvider: "返回数据"
+Your-Application.PaymentProvider.Payment-Components -> User: "渲染 UI 更新"
+
+```
+
 </after_translate>
 </example_item>
 

package/utils/file-utils.mjs

@@ -8,6 +8,8 @@ import { isBinaryFile } from "isbinaryfile";
 import { encode } from "gpt-tokenizer";
 import { fileTypeFromBuffer } from "file-type";
 import { gunzipSync } from "node:zlib";
+
+import { debug } from "./debug.mjs";
 import { isGlobPattern } from "./utils.mjs";
 import { INTELLIGENT_SUGGESTION_TOKEN_THRESHOLD } from "./constants/index.mjs";
 import { uploadFiles } from "./upload-files.mjs";
@@ -284,6 +286,11 @@ export async function loadFilesFromPaths(sourcesPath, options = {}) {
         continue;
       }
 
+      if (checkIsRemoteFile(dir)) {
+        allFiles.push(dir);
+        continue;
+      }
+
       // First try to access as a file or directory
       const stats = await stat(dir);
 
@@ -313,7 +320,13 @@ export async function loadFilesFromPaths(sourcesPath, options = {}) {
             : [];
 
           finalIncludePatterns = [...defaultIncludePatterns, ...userInclude];
-          finalExcludePatterns = [...defaultExcludePatterns, ...userExclude];
+          finalExcludePatterns = [
+            ...defaultExcludePatterns,
+            ...userExclude.map((x) => {
+              const prefix = `${dir}/`;
+              return x.startsWith(prefix) ? x.slice(prefix.length) : x;
+            }),
+          ];
         } else {
           // Use only user patterns
           if (includePatterns) {
@@ -374,6 +387,10 @@ export async function loadFilesFromPaths(sourcesPath, options = {}) {
  * @returns {Promise<boolean>} True if file appears to be a text file
  */
 async function isTextFile(filePath) {
+  if (checkIsRemoteFile(filePath)) {
+    return checkIsHttpTextFile(filePath);
+  }
+
   try {
     const isBinary = await isBinaryFile(filePath);
     return !isBinary;
@@ -383,6 +400,53 @@ async function isTextFile(filePath) {
   }
 }
 
+export function checkIsRemoteFile(filepath) {
+  if (filepath.startsWith("http://") || filepath.startsWith("https://")) {
+    return true;
+  }
+  return false;
+}
+
+export async function checkIsHttpTextFile(fileUrl) {
+  try {
+    const res = await fetch(fileUrl, {
+      method: "HEAD",
+    });
+    const contentType = res.headers.get("content-type") || "";
+    const textMimeTypes = [
+      "application/json",
+      "application/ld+json",
+      "application/graphql+json",
+      "application/xml",
+      "application/xhtml+xml",
+      "application/javascript",
+      "application/ecmascript",
+      "application/x-www-form-urlencoded",
+      "application/rss+xml",
+      "application/atom+xml",
+    ];
+    if (contentType.startsWith("text/") || textMimeTypes.includes(contentType)) {
+      return true;
+    }
+    return false;
+  } catch (error) {
+    debug(`Failed to check HTTP file content type: ${fileUrl} - ${error.message}`);
+    return null;
+  }
+}
+
+export async function getHttpFileContent(file) {
+  if (!file) return null;
+  try {
+    const res = await fetch(file);
+    const text = await res.text();
+    return text;
+  } catch (error) {
+    debug(`Failed to fetch HTTP file content: ${file} - ${error.message}`);
+    return null;
+  }
+}
+
 /**
  * Read and parse file contents from an array of file paths
  * @param {string[]} files - Array of file paths to read
@@ -405,12 +469,24 @@ export async function readFileContents(files, baseDir = process.cwd(), options =
       }
 
       try {
-        const content = await readFile(file, "utf8");
-        const relativePath = path.relative(baseDir, file);
-        return {
-          sourceId: relativePath,
-          content,
-        };
+        if (checkIsRemoteFile(file)) {
+          const content = await getHttpFileContent(file);
+          if (content) {
+            return {
+              sourceId: file,
+              content,
+            };
+          }
+
+          return null;
+        } else {
+          const content = await readFile(file, "utf8");
+          const relativePath = path.relative(baseDir, file);
+          return {
+            sourceId: relativePath,
+            content,
+          };
+        }
       } catch (error) {
         // If reading as text fails (e.g., binary file), skip it
         console.warn(`Failed to read file as text: ${file} - ${error.message}`);

package/utils/openapi/index.mjs

@@ -0,0 +1,24 @@
+import { parse } from "yaml";
+
+export function isOpenAPISpecFile(content) {
+  const trimmedContent = content.trim();
+  try {
+    const parsed = parse(trimmedContent, {
+      logLevel: "silent",
+    });
+    if (parsed.openapi || parsed.swagger) {
+      return true;
+    }
+  } catch {
+    //
+  }
+  try {
+    const parsed = JSON.parse(trimmedContent);
+    if (parsed.openapi || parsed.swagger) {
+      return true;
+    }
+  } catch {
+    //
+  }
+  return false;
+}