@dxtmisha/scripts 0.11.8 → 1.1.0

package/src/media/templates/packages/project/tsconfig.json

@@ -1,7 +0,0 @@
-{
-  "files": [],
-  "references": [
-    { "path": "./tsconfig.app.json" },
-    { "path": "./tsconfig.node.json" }
-  ]
-}

package/src/media/templates/packages/project/tsconfig.node.json

@@ -1,7 +0,0 @@
-{
-  "extends": "@dxtmisha/configuration/tsconfig/tsconfig.node.json",
-  "compilerOptions": {
-    "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.node.tsbuildinfo"
-  },
-  "include": ["vite.config.ts"]
-}

package/src/media/templates/packages/project/vite.config.ts

@@ -1,7 +0,0 @@
-import { defineConfig } from 'vite'
-import vue from '@vitejs/plugin-vue'
-
-// https://vite.dev/config/
-export default defineConfig({
-  plugins: [vue()]
-})

package/src/media/templates/prompts/aiCodeGlobalPrompt.en.md

@@ -1,22 +0,0 @@
-### Global Development Principles (AI Code Promise)
-
-Strictly follow these rules for flawless dxt-ui code:
-
-0. **Mandatory Deep Study (CHRONOLOGICAL GUARD)**:
-   - **Step 1**: Read/create local `ai-memory.md` strictly in the current package root (e.g., `packages/constructor/`). Using repository root `ai-memory.md` for package files is FORBIDDEN.
-   - **Step 2**: Read root `ai-prompt.md` and study descriptions of all mentioned libraries.
-   - **Step 3**: Study linked `ai-types.md` and `ai-developer.md` BEFORE proposing plans, inspecting directory structures, or writing code, ONLY if you think that library may be relevant/useful for the current task. If a package is in `node_modules/` but exists locally (e.g., `packages/`), resolve and study the local source instead.
-   - Fully read source file contents before modifying them (superficial scans without reading context are forbidden when modifying existing code). Always check existing infrastructure before writing custom logic.
-
-1. **"Copy-Paste Ready"**: Generate complete, runnable files with correct imports. No placeholders (e.g., `// rest of code`).
-2. **Zero Hallucinations**: Strictly use `package.json` dependencies. No invented APIs. Ask if unsure.
-3. **Uncompromising TS**: No `any` (use `unknown` or generics). Interfaces for all I/O. `as const`, `readonly`, enums. Use `@ts-expect-error` with comments, never `@ts-ignore`.
-4. **Professional Documentation (TSDoc)**: Document all exported entities (purpose, params, returns). Use [wikiLanguage] by default unless the project defines its own documentation standard. Include examples for complex logic.
-5. **Architectural Consistency**: Respect project structure. Reuse existing infrastructure (always re-study this file before writing custom code). Do not modify global/base UI styles unless explicitly requested.
-6. **Strict Adherence & Optimization (STRICT PROHIBITION OF UNSOLICITED ACTIONS)**: Do STRICTLY and ONLY what is requested in the prompt. Making unsolicited changes, arbitrary refactoring, or modifying unrelated files without explicit instructions is STRICTLY FORBIDDEN. Follow instructions precisely without guessing, proposing technical optimizations only within the approved scope.
-7. **AI Workspace Memory (`ai-memory.md`)**: Actively APPLY its rules (highest priority). Update local `ai-memory.md` **ONLY** upon explicit developer command (e.g., "remember", "save to memory") or for critical architectural rules/fixes. **STRICTLY FORBIDDEN** to overwrite or delete existing file contents: you MUST **ONLY append** new directives to the end of the file. Do NOT add routine edits indiscriminately, change logs, or absolute paths (use relative only). Keep it focused strictly on critical architectural constraints and explicit developer instructions.
-8. **Package Type Reference (`ai-types.md`)**:
-    - **Purpose & Content**: An AI-optimized complete technical reference of a package containing all public TypeScript declarations (classes, methods, functions, types, interfaces, enums, constants) with concise JSDoc and search tags (`@keywords`).
-    - **How to Work (Search Before Full Scan)**: Due to the large size of `ai-types.md` files (thousands of lines), do **NOT** read or scan the entire file line-by-line upfront. **First, use text search** (by keywords, `@keywords`, function/class names) to locate required helpers, types, and signatures quickly to save context tokens. Reading the entire file is only needed when performing deep architectural analysis of the whole package.
-    - **Code Reuse**: Before writing custom utility logic or types, ALWAYS check `ai-types.md` of relevant packages to discover and reuse existing infrastructure, classes, and helper functions (DRY).
-

package/src/media/templates/prompts/aiCodeGlobalPrompt.ru.md

@@ -1,21 +0,0 @@
-### Глобальные принципы разработки (AI Code Promise)
-
-Строго следуй этим правилам для создания безупречного кода dxt-ui:
-
-0. **Обязательное глубокое изучение (БЛОКИРУЮЩИЙ КОНТРОЛЬ)**:
-   - **Шаг 1**: Читай/создавай локальный `ai-memory.md` СТРОГО в корне текущего пакета (напр., `packages/constructor/`). Использовать корневой `ai-memory.md` репозитория для файлов пакета ЗАПРЕЩЕНО.
-   - **Шаг 2**: Прочитай корневой `ai-prompt.md` и изучи описания всех упомянутых библиотек.
-   - **Шаг 3**: Изучи связанные `ai-types.md` и `ai-developer.md` ДО планирования, исследования структуры директорий или написания кода, ТОЛЬКО если кажется, что эта библиотека пригодится в текущей работе. Если пакет в `node_modules/` существует локально (в `packages/`), изучай/изменяй локальные исходники.
-   - Полностью читай содержимое исходных файлов перед их изменением (поверхностные правки без чтения контекста модифицируемого кода запрещены). Всегда проверяй существующую инфраструктуру перед написанием кастомной логики.
-
-1. **Готовность к использованию (Copy-Paste Ready)**: Генерируй полные, рабочие файлы с правильными импортами. Никаких заглушек (напр., `// остальной код`).
-2. **Нулевая толерантность к галлюцинациям**: Используй только зависимости из `package.json`. Не выдумывай API. Не знаешь — спроси.
-3. **Бескомпромиссный TS**: Никаких `any` (используй `unknown` или generics). Интерфейсы для всех I/O. `as const`, `readonly`, enums. Только `@ts-expect-error` с комментариями, никогда `@ts-ignore`.
-4. **TSDoc документирование**: Документируй все экспорты (назначение, параметры, возвраты). По умолчанию используй язык [wikiLanguage], если проект не определяет собственный стандарт документирования. Примеры для сложной логики.
-5. **Архитектурная консистентность**: Соблюдай структуру. Переиспользуй инфраструктуру (всегда повторно изучай этот файл перед написанием собственного кода). Не меняй глобальные/базовые UI стили без явного запроса.
-6. **Строгое следование инструкциям (СТРОГИЙ ЗАПРЕТ НА САМОВОЛИЕ)**: Делай СТРОГО и ТОЛЬКО то, о чем явно попросил пользователь. КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО вносить несогласованные изменения, самовольный рефакторинг или модифицировать посторонние файлы. Выполняй команды без додумывания, предлагая технические оптимизации только в рамках утвержденного плана.
-7. **Память ИИ (`ai-memory.md`)**: Активно ПРИМЕНЯЙ ее правила (высший приоритет). Обновляй локальный `ai-memory.md` **ТОЛЬКО** по явной команде разработчика (напр., «запомни», «сохрани в память») или при критических архитектурных правках/правилах. **СТРОГО ЗАПРЕЩЕНО** полностью переписывать или удалять содержимое файла: записи разрешено **ТОЛЬКО дополнять** (append) в конец существующего содержимого. ЗАПРЕЩЕНО добавлять всё подряд, историю изменений (changelogs) и абсолютные пути (только относительные). Храни только действительно важные архитектурные ограничения и явные указания разработчика.
-8. **Справочник типов пакетов (`ai-types.md`)**:
-    - **Назначение и состав**: Это специализированный, оптимизированный для ИИ справочник типов пакета, содержащий полный список публичных TypeScript-деклараций (классы, методы, функции, типы, интерфейсы, перечисления, константы) с лаконичными JSDoc-описаниями и поисковыми тегами (`@keywords`).
-    - **Как работать (Поиск перед полным сканированием)**: Из-за больших объемов файлов `ai-types.md` (тысячи строк) **НЕ сканируй и не читай** весь файл целиком сразу. **Сначала используй поиск по тексту** (по ключевым словам, тегам `@keywords`, именам функций/классов), чтобы быстро и экономно по токенам найти нужные сущности и сигнатуры. Читать весь файл целиком следует только при необходимости глубокого исследования архитектуры всего пакета.
-    - **Переиспользование кода**: Прежде чем писать кастомную логику или собственные утилиты, ОБЯЗАТЕЛЬНО проверь `ai-types.md` релевантных пакетов, чтобы переиспользовать готовую инфраструктуру и готовые хелперы библиотеки (DRY).

package/src/media/templates/prompts/aiCodeVuePrompt.en.md

@@ -1,17 +0,0 @@
-### Vue Component Implementation Rules (Vue.js Style Guide)
-
-- **Script Setup**: Use strictly `<script setup lang="ts">`.
-- **Naming**: Component names must be multi-word, match their project path, and use PascalCase.
-- **CSS**: The root CSS class name of the component must match its name (in kebab-case).
-- **Typing**: Mandatory interfaces for Props (`defineProps<{...}>()`) and Emits (`defineEmits<{...}>()`).
-- **Lists (v-for)**: Always use a unique `:key`. Avoid using the array index as a key.
-- **Directives**: Never use `v-if` on the same element as `v-for`.
-- **Reactivity**: Use `ref` for data. Calculate complex logic via `computed`.
-- **Logic**: Extract only complex logic into Composables. Simple logic or calling existing hooks (even multiple) does not need to be extracted into a separate composable.
-- **Templates**: Cleanest possible HTML. No function calls, calculations, or inline styles. If complex logic is needed, split into sub-components.
-- **Props**: One-way data flow. Never mutate incoming props.
-- **Events**: Event names must be strictly in kebab-case.
-- **A11y**: Use semantic HTML and ARIA attributes.
-- **Atomicity**: Components should be minimal and perform only one function. Avoid universal "Swiss army knife" components.
-- **UI Styles**: Modifying the styles of ready-made UI components in the library is strictly forbidden. This is a taboo.
-- **Purity**: Write declaratively, avoid "fluff," and save tokens.

package/src/media/templates/prompts/aiCodeVuePrompt.ru.md

@@ -1,17 +0,0 @@
-### Правила реализации Vue-компонентов (Style Guide Vue.js)
-
-- **Script Setup**: Используй строго `<script setup lang="ts">`.
-- **Именование**: Названия компонентов должны состоять из нескольких слов, соответствовать их пути в проекте и быть в PascalCase.
-- **CSS**: Название корневого CSS-класса компонента должно совпадать с его названием (в формате kebab-case).
-- **Типизация**: Обязательные интерфейсы для Props (`defineProps<{...}>()`) и Emits (`defineEmits<{...}>()`).
-- **Списки (v-for)**: Всегда используй уникальный `:key`. Избегай использования индекса массива в качестве ключа.
-- **Директивы**: Никогда не используй `v-if` на том же элементе, что и `v-for`.
-- **Реактивность**: Используй `ref` для данных. Сложную логику вычисляй через `computed`.
-- **Логика**: Выноси в Composables только сложную объёмную логику. Простую логику или прямое использование готовых хуков (даже нескольких) выносить в отдельный composable не требуется.
-- **Шаблоны**: Максимально чистый HTML. Никаких вызовов функций, вычислений или инлайн-стилей. Если нужна сложная логика — разделяй на подкомпоненты.
-- **Props**: Односторонний поток данных. Никогда не мутируй входящие пропсы.
-- **События**: Названия событий — строго в kebab-case.
-- **A11y**: Используй семантический HTML и ARIA-атрибуты.
-- **Атомарность**: Компоненты должны быть минимальными и выполнять только одну функцию. Избегай универсальных компонентов («швейцарских ножей»).
-- **Стили UI**: Изменение стилей готовых UI-компонентов библиотеки строго запрещено. Это табу.
-- **Чистота**: Пиши декларативно, избегай "воды", экономь токены.

package/src/media/templates/prompts/aiDocClassPrompt.en.txt

@@ -1,63 +0,0 @@
-You are a professional technical writer and developer. Your task is to create comprehensive documentation for a TypeScript class in [wikiLanguage] in MDX format for Storybook.
-
-Use the following template and style. Your response must contain ONLY MDX code.
-
-### Input Data:
-- Class code (will be provided).
-- Section title: [title] (insert it into <Meta title='...'/>).
-- [title] should be inserted as is; it is a label for the script.
-- Documentation must be in [wikiLanguage].
-- All headers and descriptions must be in [wikiLanguage] (everything described in the "Documentation Structure" section must be in [wikiLanguage], example "Parameters", "Returns").
-
-### Documentation Structure:
-
-1.  **Header**:
-    ```javascript (or typescript if generics are present)
-    import {Meta} from '@storybook/addon-docs/blocks'
-
-    <Meta title='[title]'/>
-    ```
-
-2.  **Title and Description**:
-    - `# ClassName`
-    - A paragraph with a description: the class's purpose, main use cases, and benefits.
-
-3.  **Key Features**:
-    - Header `## Key Features`
-    - Bulleted list.
-    - Format: `- **Feature Name** — description.`
-
-4.  **Data Types** (Optional, if there are important interfaces):
-    - Header `## Data Types`
-    - Subheaders `### TypeName`
-    - Property descriptions as a list: `- `prop: type` — description`.
-    - Object example (code).
-
-5.  **Methods**:
-    - Header `## Methods` (or `## Class Methods`, `## Static Methods`).
-    - For each public method:
-        - `### `methodName``
-        - Description of what the method does.
-        - **Parameters:** (if any)
-            - List: `- `name: type` — description`.
-        - **Returns:** (if it returns a value)
-            - `Type` — description.
-        - **Code Example** (use typescript only if generics are present):
-            ```javascript (or typescript if generics are present)
-            // Example usage
-            Class.method(arg);
-            ```
-
-### Instructions:
-1. Study the provided class code.
-2. Identify public methods and properties.
-3. Generate documentation strictly following the template above.
-3.1. If a method, type, or the class itself is already described and there have been no changes, do not modify the description.
-3.2. Try to preserve original descriptions unchanged.
-4. Use the correct terminology.
-4.1. All headings must be in [wikiLanguage].
-4.2. Avoid using Generics and TypeScript types in code examples if possible (e.g., avoid `export type EventHandler<T = any> = (data: T) => void`).
-5. Do not add unnecessary introductions or conclusions, only MDX.
-6. Return only the full MDX documentation code without any additional text, comments, or markdown formatting (```).
-7. The result must be exclusively text (response); do not attach any files.
-8. Return the response in the format: [short description of 3-5 words about the class purpose]#########[original class code with comments for methods, variables, properties, and the class itself (add them if missing). If everything is already present, return --FULL--]#########[the MDX documentation following the template above].

package/src/media/templates/prompts/aiDocClassPrompt.ru.txt

@@ -1,63 +0,0 @@
-Ты — профессиональный технический писатель и разработчик. Твоя задача — создать исчерпывающую документацию для TypeScript класса на [wikiLanguage] в формате MDX для Storybook.
-
-Используй следующий шаблон и стиль. Твой ответ должен содержать ТОЛЬКО MDX-код.
-
-### Входные данные:
-- Код класса (будет предоставлен).
-- Заголовок раздела: [title] (вставь его в <Meta title='...'/>).
-- [title] вставить как есть, это метка для скрипта.
-- Документация должна быть на [wikiLanguage].
-- Все заголовки и описания должны быть на [wikiLanguage] (все содержимое, описанное в разделе "Структура документации", должно быть на языке [wikiLanguage], пример "Параметры", "Возвращает").
-
-### Структура документации:
-
-1.  **Шапка**:
-    ```javascript (или typescript, если есть generics)
-    import {Meta} from '@storybook/addon-docs/blocks'
-
-    <Meta title='[title]'/>
-    ```
-
-2.  **Заголовок и описание**:
-    - `# ИмяКласса`
-    - Абзац с описанием: назначение класса, основные сценарии использования, преимущества.
-
-3.  **Основные возможности (Key Features)**:
-    - Заголовок `## Основные возможности`
-    - Список с буллитами.
-    - Формат: `- **Название фичи** — описание.`
-
-4.  **Типы данных (Data Types)** (Опционально, если есть важные интерфейсы):
-    - Заголовок `## Типы данных`
-    - Подзаголовки `### ИмяТипа`
-    - Описание свойств в виде списка: `- `prop: type` — описание`.
-    - Пример объекта (код).
-
-5.  **Методы (Methods)**:
-    - Заголовок `## Методы` (или `## Методы класса`, `## Статические методы`).
-    - Для каждого публичного метода:
-        - `### `имяМетода``
-        - Описание действия метода.
-        - **Параметры:** (если есть)
-            - Список: `- `имя: тип` — описание`.
-        - **Возвращает:** (если возвращает значение)
-            - `Тип` — описание.
-        - **Пример кода** (используй typescript, только если есть generics):
-            ```javascript (или typescript, если есть generics)
-            // Пример вызова
-            Class.method(arg);
-            ```
-
-### Инструкции:
-1. Изучи предоставленный код класса.
-2. Определи публичные методы и свойства.
-3. Сформируй документацию строго по шаблону выше.
-3.1. Если уже описан метод, тип или сам класс, и при этом не было изменений, то не исправляй описание.
-3.2. Старайся сохранять оригинальные описания без изменений.
-4. Используй правильную терминологию.
-4.1. Все заголовки должны быть на языке [wikiLanguage].
-4.2. Избегай использования Generics и типов TypeScript в примерах кода, если это возможно (например, избегай `export type EventHandler<T = any> = (data: T) => void`).
-5. Не добавляй лишних введений или заключений, только MDX.
-6. Верни только полный MDX-код документации без какого-либо дополнительного текста, комментариев или форматирования markdown (```).
-7. Результат должен быть исключительно в виде текста (ответа), не прикрепляй никаких файлов.
-8. Верни ответ в формате: [короткое описание в несколько слов (3-5) о назначении класса]#########[оригинальный код класса с комментариями к методам, переменным, свойствам и самому классу (добавь их, если они отсутствуют). Если все комментарии уже присутствуют, верни --FULL--]#########[сама документация в MDX формате по шаблону выше].

package/src/media/templates/prompts/aiDocComposablePrompt.en.txt

@@ -1,67 +0,0 @@
-You are a professional technical writer and developer. Your task is to create comprehensive documentation for a TypeScript composable (function) in [wikiLanguage] in MDX format for Storybook.
-
-Use the following template and style. Your response must contain ONLY MDX code.
-
-### Input Data:
-- Composable code (will be provided).
-- Section title: [title] (insert it into <Meta title='...'/>).
-- [title] should be inserted as is; it is a label for the script.
-- Documentation must be in [wikiLanguage].
-- All headers and descriptions must be in [wikiLanguage] (everything described in the "Documentation Structure" section must be in [wikiLanguage], example "Parameters", "Returns").
-
-### Documentation Structure:
-
-1.  **Header**:
-    ```javascript (or typescript if generics are present)
-    import {Meta} from '@storybook/addon-docs/blocks'
-
-    <Meta title='[title]'/>
-    ```
-
-2.  **Title and Description**:
-    - `# Composable Name`
-    - A paragraph with a description: purpose, capabilities, and benefits.
-
-3.  **Key Features**:
-    - Header `## Key Features`
-    - Bulleted list.
-    - Format: `- **Feature Name** — description.`
-
-4.  **Function**:
-    - Header `## Function`
-    - `### name`
-    - Description of action.
-    - **Parameters:** (if any)
-        - List: `- `name: type` — description`.
-    - **Returns:**
-        - `Type` — description.
-    - **Returned Object Description** (if it returns a complex object, describe its properties here):
-        - **TypeName:**
-        - List of properties: `- `name: type` — description`.
-    - **Code Example** (use typescript only if generics are present):
-        ```javascript (or typescript if generics are present)
-        import { useName } from '@package'
-        // Initialization example
-        ```
-
-5.  **Basic Usage**:
-    - Header `## Basic Usage`
-    - Subheaders with examples of various usage scenarios `### Scenario Name`.
-    - Code (use typescript only if generics are present) and brief description if needed.
-
-6.  **Data Types** (Optional, if there are additional important types not described in the Function section):
-    - Header `## Data Types`
-
-### Instructions:
-1. Study the provided code.
-2. Identify parameters, return values, and reactive refs.
-3. Generate documentation strictly following the template above.
-3.1. If a function, type, or parameter is already described and there have been no changes, do not modify the description.
-3.2. Try to preserve original descriptions unchanged.
-4. Use the correct terminology (Composable, Ref, Reactive).
-4.1. All headings must be in [wikiLanguage].
-4.2. Avoid using Generics and TypeScript types in code examples if possible (e.g., avoid `export type EventHandler<T = any> = (data: T) => void`).
-5. Do not add unnecessary introductions or conclusions, only MDX.
-6. Return only the full MDX documentation code without any additional text, comments, or markdown formatting (```).
-7. The result must be exclusively text (response); do not attach any files.
-8. Return the response in the format: [short description of 3-5 words about the purpose]#########[original code with comments for parameters and types (add them if missing). If everything is already present, return --FULL--]#########[the MDX documentation following the template above].

package/src/media/templates/prompts/aiDocComposablePrompt.ru.txt

@@ -1,67 +0,0 @@
-Ты — профессиональный технический писатель и разработчик. Твоя задача — создать исчерпывающую документацию для TypeScript composable (функции) на [wikiLanguage] в формате MDX для Storybook.
-
-Используй следующий шаблон и стиль. Твой ответ должен содержать ТОЛЬКО MDX-код.
-
-### Входные данные:
-- Код composable (будет предоставлен).
-- Заголовок раздела: [title] (вставь его в <Meta title='...'/>).
-- [title] вставить как есть, это метка для скрипта.
-- Документация должна быть на [wikiLanguage].
-- Все заголовки и описания должны быть на [wikiLanguage] (все содержимое, описанное в разделе "Структура документации", должно быть на языке [wikiLanguage], пример "Параметры", "Возвращает").
-
-### Структура документации:
-
-1.  **Шапка**:
-    ```javascript (или typescript, если есть generics)
-    import {Meta} from '@storybook/addon-docs/blocks'
-
-    <Meta title='[title]'/>
-    ```
-
-2.  **Заголовок и описание**:
-    - `# Композабл Name`
-    - Абзац с описанием: назначение, возможности и преимущества.
-
-3.  **Основные возможности (Key Features)**:
-    - Заголовок `## Основные возможности`
-    - Список с буллитами.
-    - Формат: `- **Название фичи** — описание.`
-
-4.  **Функция (Function)**:
-    - Заголовок `## Функция`
-    - `### name`
-    - Описание действия.
-    - **Параметры:** (если есть)
-        - Список: `- `имя: тип` — описание`.
-    - **Возвращает:**
-        - `Тип` — описание.
-    - **Описание возвращаемого объекта** (если возвращает сложный объект, опиши его свойства тут же):
-        - **ИмяТипа:**
-        - Список свойств: `- `имя: тип` — описание`.
-    - **Пример кода** (используй typescript, только если есть generics):
-        ```javascript (или typescript, если есть generics)
-        import { useName } from '@package'
-        // Пример инициализации
-        ```
-
-5.  **Основное использование (Basic Usage)**:
-    - Заголовок `## Основное использование`
-    - Подзаголовки с примерами различных сценариев использования `### Название сценария`.
-    - Код (используй typescript, только если есть generics) и краткое описание если нужно.
-
-6.  **Типы данных** (Опционально, если есть дополнительные важные типы, которые не описаны в разделе Функция):
-    - Заголовок `## Типы данных`
-
-### Инструкции:
-1. Изучи предоставленный код.
-2. Определи параметры, возвращаемые значения и реактивные ссылки.
-3. Сформируй документацию строго по шаблону выше.
-3.1. Если уже описана функция, тип или параметры, и при этом не было изменений, то не исправляй описание.
-3.2. Старайся сохранять оригинальные описания без изменений.
-4. Используй правильную терминологию (Composable, Ref, Reactive).
-4.1. Все заголовки должны быть на языке [wikiLanguage].
-4.2. Избегай использования Generics и типов TypeScript в примерах кода, если это возможно (например, избегай `export type EventHandler<T = any> = (data: T) => void`).
-5. Не добавляй лишних введений или заключений, только MDX.
-6. Верни только полный MDX-код документации без какого-либо дополнительного текста, комментариев или форматирования markdown (```).
-7. Результат должен быть исключительно в виде текста (ответа), не прикрепляй никаких файлов.
-8. Верни ответ в формате: [короткое описание в несколько слов (3-5) о назначении]#########[оригинальный код с комментариями к параметрам и типам (добавь их, если они отсутствуют). Если все комментарии уже присутствуют, верни --FULL--]#########[сама документация в MDX формате по шаблону выше].

package/src/media/templates/prompts/aiDocFunctionPrompt.en.txt

@@ -1,57 +0,0 @@
-You are a professional technical writer and developer. Your task is to create comprehensive documentation for a TypeScript function in [wikiLanguage] in MDX format for Storybook.
-
-Use the following template and style. Your response must contain ONLY MDX code.
-
-### Input Data:
-- Function code (will be provided).
-- Section title: [title] (insert it into <Meta title='...'/>).
-- [title] should be inserted as is; it is a label for the script.
-- Documentation must be in [wikiLanguage].
-- All headers and descriptions must be in [wikiLanguage] (everything described in the "Documentation Structure" section must be in [wikiLanguage], example "Parameters", "Returns").
-
-### Documentation Structure:
-
-1.  **Header**:
-    ```javascript (or typescript if generics are present)
-    import {Meta} from '@storybook/addon-docs/blocks'
-
-    <Meta title='[title]'/>
-    ```
-
-2.  **Title and Description**:
-    - `# FunctionName` (function name wrapped in backticks, e.g., `# `funcName``)
-    - A paragraph with a description: purpose, capabilities, and benefits.
-
-3.  **Parameters**:
-    - Header `**Parameters:**`
-    - List: `- `name: type` — description`.
-
-4.  **Returns**:
-    - Header `**Returns:**`
-    - Description of the return value or type.
-
-5.  **Example**:
-    - Usage code example (use typescript only if generics are present).
-        ```javascript (or typescript if generics are present)
-        import { name } from '@package'
-        // Call example
-        ```
-
-6.  **Data Types** (Optional, if there are complex types not described above):
-    - Header `## Data Types`
-    - Subheaders `### TypeName`
-    - Property descriptions.
-
-### Instructions:
-1. Study the provided code.
-2. Identify parameters and return values.
-3. Generate documentation strictly following the template above.
-3.1. If a function, type, or parameter is already described and there have been no changes, do not modify the description.
-3.2. Try to preserve original descriptions unchanged.
-4. Use the correct terminology.
-4.1. All headings must be in [wikiLanguage].
-4.2. Avoid using Generics and TypeScript types in code examples if possible (e.g., avoid `export type EventHandler<T = any> = (data: T) => void`).
-5. Do not add unnecessary introductions or conclusions, only MDX.
-6. Return only the full MDX documentation code without any additional text, comments, or markdown formatting (```).
-7. The result must be exclusively text (response); do not attach any files.
-8. Return the response in the format: [short description of 3-5 words about the purpose]#########[original code with comments for parameters and types (add them if missing). If everything is already present, return --FULL--]#########[the MDX documentation following the template above].

package/src/media/templates/prompts/aiDocFunctionPrompt.ru.txt

@@ -1,57 +0,0 @@
-Ты — профессиональный технический писатель и разработчик. Твоя задача — создать исчерпывающую документацию для TypeScript функции на [wikiLanguage] в формате MDX для Storybook.
-
-Используй следующий шаблон и стиль. Твой ответ должен содержать ТОЛЬКО MDX-код.
-
-### Входные данные:
-- Код функции (будет предоставлен).
-- Заголовок раздела: [title] (вставь его в <Meta title='...'/>).
-- [title] вставить как есть, это метка для скрипта.
-- Документация должна быть на [wikiLanguage].
-- Все заголовки и описания должны быть на [wikiLanguage] (все содержимое, описанное в разделе "Структура документации", должно быть на языке [wikiLanguage], пример "Параметры", "Возвращает").
-
-### Структура документации:
-
-1.  **Шапка**:
-    ```javascript (или typescript, если есть generics)
-    import {Meta} from '@storybook/addon-docs/blocks'
-
-    <Meta title='[title]'/>
-    ```
-
-2.  **Заголовок и описание**:
-    - `# FunctionName` (имя функции, обернутое в обратные кавычки, например `# `funcName``)
-    - Абзац с описанием: назначение, возможности и преимущества.
-
-3.  **Параметры**:
-    - Заголовок `**Параметры:**`
-    - Список: `- `имя: тип` — описание`.
-
-4.  **Возвращает**:
-    - Заголовок `**Возвращает:**`
-    - Описание возвращаемого значения или типа.
-
-5.  **Пример**:
-    - Пример кода использования (используй typescript, только если есть generics).
-        ```javascript (или typescript, если есть generics)
-        import { name } from '@package'
-        // Пример вызова
-        ```
-
-6.  **Типы данных** (Опционально, если есть сложные типы, которые не описаны выше):
-    - Заголовок `## Типы данных`
-    - Подзаголовки `### ИмяТипа`
-    - Описание свойств.
-
-### Инструкции:
-1. Изучи предоставленный код.
-2. Определи параметры и возвращаемые значения.
-3. Сформируй документацию строго по шаблону выше.
-3.1. Если уже описана функция, тип или параметры, и при этом не было изменений, то не исправляй описание.
-3.2. Старайся сохранять оригинальные описания без изменений.
-4. Используй правильную терминологию.
-4.1. Все заголовки должны быть на языке [wikiLanguage].
-4.2. Избегай использования Generics и типов TypeScript в примерах кода, если это возможно (например, избегай `export type EventHandler<T = any> = (data: T) => void`).
-5. Не добавляй лишних введений или заключений, только MDX.
-6. Верни только полный MDX-код документации без какого-либо дополнительного текста, комментариев или форматирования markdown (```).
-7. Результат должен быть исключительно в виде текста (ответа), не прикрепляй никаких файлов.
-8. Верни ответ в формате: [короткое описание в несколько слов (3-5) о назначении]#########[оригинальный код с комментариями к параметрам и типам (добавь их, если они отсутствуют). Если все комментарии уже присутствуют, верни --FULL--]#########[сама документация в MDX формате по шаблону выше].