Создание и использование Скиллов для создания артефактов MQL. Часть 2
62
0
Что мы уже сделали и что сделаем дальше
В первой части мы определили термины “Скилл”, “Ассистент” и “МСП” и описали роли каждого компонента. Кроме того, мы ответили на важный вопрос: "Зачем Скилл нужен разработчику?". Затем мы написали учебный скилл MQL-TUTOR и научили Ассистента MetaTrader генерировать простые MQL5‑скрипты по тегу Artifact: Simple Script MQL5. Мы добавили проверку входных параметров и защиту от ряда ошибок.
Мы проверили, что Скилл работает и проходит тесты. Это положительный, но крайне незначительный результат. Скрипта, который просто компилируется, определённо мало. Реальный, пригодный для работы с проектом Скилл должен уметь гораздо больше:
- создавать логи различного уровня,
- проверять свою же работоспособность и сообщать об этом пользователю,
- не только создавать новые артефакты, но и редактировать уже сделанные,
- Иметь авторский стиль.
Это минимальный список; в процессе работы мы будем его расширять и дополнять. Мы будем работать с тем же артефактом (Simple Script MQL5), что и в предыдущей статье, последовательно развивая уже разработанный Скилл MQL-TUTOR, добавляя новые инструкции, корректируя старые.
Зачем это разработчику
Мы уже отвечали на этот вопрос в первой части статьи, но сейчас дополним прошлый ответ: разработчик получает инструмент, позволяющий с минимальными затратами получать узнаваемый и корректный код. Инструмент (Скилл) может быть быстро изменён или дополнен. Такой код легко сопровождать, редактировать и писать ревью. И самое главное, Скилл может быть легко модифицирован для работы с более сложными артефактами — индикаторами и советниками.
Приступим к реализации плана. Будем использовать двух агентов: Ассистента Разработчика (Sonnet) и Ассистента Пользователя (встроенный Ассистент MetaTrader). Начнём с внедрения логирования — необязательного, но полезного инструмента контроля работы Скилла.
Добавляем логирование
Зачем это нужно? Ассистент, следуя инструкциям Скилла, будет добавлять в обычный текстовый файл записи о различных событиях. Это будут записи об ошибках, предупреждения, информационные сообщения. Например, если Ассистент не обнаружит в ТЗ обязательные параметры и будет вынужден остановиться, он запишет в лог сообщение об ошибке. Если в техническом описании будут обнаружены неправильные входные параметры, то в лог будет записано предупреждение. Также в лог могут быть записаны информационные сообщения, например время начала работы и её длительность. По лог‑файлу разработчик видит этап возникновения ошибки, полученные предупреждения и может скорректировать сгенерированный код.. Поэтому принимаем решение добавить в Скилл инструкции о необходимости писать лог.
Но предварительно нам надо ответить на несколько вопросов:
- Где создавать лог-файл?
- Лог-файл должен быть один на весь Скилл, или создавать его отдельно для каждого сгенерированного артефакта?
- Лог-файл всегда создается заново, или дописывается в конце?
- Что именно мы будем писать в лог — события какого уровня?
- Нужен ли вообще лог-файл?
Мы можем создать лог-файл в нескольких местах. Это можно сделать в папке, в которой генерируется артефакт. Или же в стандартной папке .\MQL5\Files\. Выберем первый вариант: создавать отдельный лог‑файл для каждого артефакта в папке генерации. У решения есть недостаток: мы не сможем фиксировать ошибки, возникшие до создания папки артефакта. Это, например, отсутствие "длинного имени". С другой стороны, такие ошибки делают невозможным генерацию артефакта, а лог-файл призван сопровождать эту генерацию. Поэтому нет генерации артефакта, нет лог-файла. Для таких событий мы станем ограничиваться выводом текстового сообщения пользователю о прекращении работы.
Лог-файл создается один раз с именем <длинное имя>.log и потом дописывается. Записывать мы будем только сообщения об ошибках. Такими будут инструкции по умолчанию. Изменить их можно будет во входном промпте.
В первой части мы говорили о том, что не надо создавать файлы Скилла длиннее 500 строк. Поэтому будем следить за размером этого файла с самого начала. Вынесем все, что касается логирования в отдельный файл Logging.md и сохраним его в подпапке references. В этой папке мы будем сохранять и другие модули Скилла, которые напишем в дальнейшем.
Создаем промпт и отдаем его Ассистенту (здесь и далее я не буду приводить полные тексты промптов. Они записываются в произвольной форме и потом дополняются и корректируются. Это длительный и малоинформативный процесс. Мы будем публиковать только значимые, важные абзацы):
Создай файл references/Logging.md для скилла MQL-TUTOR. Это подключаемый референс-файл, не отдельный скилл - без YAML заголовка, начинается сразу с содержательного `# Logging`. Опиши в нём полные правила логирования: --- Формат заголовка лога: === MQL-TUTOR GENERATION LOG === Long Name : <...> Short Name : <...> Start time : <...> End time : <...> Duration : <...> Status : OK | FAILED Long Name и Short Name в момент открытия лога обычно ещё не известны - пиши UNKNOWN, а не пустое значение и не догадку, и заполняй их по мере того, как они устанавливаются в ходе выполнения.
Добавим необходимые инструкции в основной файл. Нужно, чтобы Скилл понимал, когда и как подключать логирование. Создаем промпт 2 и отдаем его Ассистенту:
Внеси два изменения в SKILL.md скилла MQL-TUTOR. 1. Добавь новый раздел ## Logging сразу после раздела "4. Input Parameters" (после того места, где определена Working Directory) и перед разделом ## Technical Task Validation . Раздел короткий - однострочная ссылка, без перечисления деталей:Logging
Every run writes a log file automatically - see references/Logging.md for naming, location, level, and content rules. 2. В Step 2 ("Select and Copy the Template") добавь новым первым пунктом (перед выбором и копированием шаблона) строку о том, что лог открывается первым действием этого шага - то есть только после того, как Step 1 (Pre-flight: Tag Check, Working Directory, Long Name, Short Name, Artifact Directory) пройден без STOP - со ссылкой на раздел Logging. В Step 1 не добавляй никаких упоминаний об открытии лога: до его успешного завершения лог не существует ни в каком виде. Не трогай остальные разделы файла и не меняй существующую нумерацию шагов.
Важный момент: мы создаем "вложенный" .md-файл без YAML заголовка. Почему? Он не нужен, потому что данный "подскилл" будет использоваться только совместно с основным скиллом MQL-TUTOR. Наличие заголовка может даже помешать. Теоретически, если с таким "подскиллом" обращаться неаккуратно, то Ассистент может принять его за самостоятельную единицу и попытаться вызвать.
Файл проекта
Еще один необязательный, но полезный инструмент — файл проекта, project.md. Предположим, что мы делаем сложный артефакт, со сложной логикой, с фильтрами и прочим. Работа определенно не на один день. Файл проекта призван хранить "историю разработки": с чего началось, что сделано, что исправлено, что запланировано. Это “путевые заметки” проекта: последовательность действий, полезная в первую очередь Ассистенту. При открытии следующей сессии будет достаточно предложить ему прочитать файл проекта и ответить разработчику, что все понятно и можно будет продолжать работу. Не потребуется перечитывать историю чата и писать длинные промпты с перечислением, что сделано, а что нет. После прочтения файла проекта Ассистент будет полностью информирован о проекте и о ходе выполнения работ. Файл проекта серьезно экономит время и токены.
В конце работы, когда проект будет реализован, такой файл (вместе с лог-файлом) можно будет безболезненно удалить, либо сократить до нескольких строк, оставив самые важные места. Возможно, не стоит делать файл проекта всегда, давайте оставим эту опцию для сложных случаев. Поэтому по умолчанию такой файл создаваться не будет.
Создаем промпт 1: создание references/Project.md и отдаем его Ассистенту:
Создай файл references/Project.md для скилла MQL-TUTOR. Это подключаемый референс-файл, не отдельный скилл - без YAML заголовка, начинается сразу с содержательного `# Project File`. Опиши в нём полные правила ведения файла проекта: 1. Выключен по умолчанию. Создаётся и ведётся только если это явно запрошено в промпте задачи (например, "maintain project file" / "keep project file" / "track this project"). Без такого запроса - ни файла, ни упоминания о нём в отчёте пользователю. 2. Расположение и имя: <Working Directory>/<Long Name>.md - та же папка, что и сгенерированный .mq5-артефакт, назван по нему же. --- 5. Структура файла - три раздела в этом порядке:# <Long Name> - Project File ## Original Prompt <the verbatim task prompt that first created this artifact> ## Change Log ### <YYYY-MM-DD HH:MM:SS> - Done: <what this run generated or changed> - Decisions: <a non-obvious choice this run made and why, or "-"> - Errors: <what went wrong this run, or "None"> - Fixed: <what this run corrected that a previous entry had flagged, or "-"> ## Blocked - <item that can't proceed without something external, and what it's waiting on> ## Future Plans - <open item> - <open item>
И конечно добавляем инструкции в основной файл Скилла — сообщаем, когда и как работать с файлом проекта:
Внеси четыре изменения в SKILL.md скилла MQL-TUTOR. 1. Добавь новый раздел `## Project File` сразу после раздела `## Logging` (после того места, где определена Working Directory, до раздела `## Technical Task Validation`): ## Project File Off by default. Only when the task prompt explicitly asks for it, MQL-TUTOR also maintains `<Working Directory>/<Long Name>.md` - a living project record (original prompt, dated change log, future plans) updated across runs. See `references/Project.md` for the full rules. 2. В Step 1 ("Open the Log and Load Context") добавь пункт (после строки про открытие лога, перед проверкой Working Directory/Long Name/Short Name): если файл проекта запрошен и <Long Name>.md уже существует - прочитать его сейчас, чтобы его содержимое было доступно для Step 5; новый файл на этом шаге НЕ создаётся. 3. В Step 2 ("Select and Copy the Template") добавь пункт первым (перед выбором эталонного шаблона): если файл проекта запрошен и <Long Name>.md ещё не существует - создать его сейчас, до копирования шаблона, поскольку Step 1 уже пройден без STOP и генерация точно состоится. 4. В Step 5 ("Report") добавь пункт: если файл проекта ведётся (создан в Step 2 в этом запуске, либо уже существовал и был прочитан в Step 1) - добавить запись в Change Log и переписать Future Plans последним действием перед отчётом пользователю. Это применяется даже если Step 1 закончился STOP, но только если файл проекта уже существовал с прошлого запуска; если файла ещё не было - обновлять нечего.
Добавляем стиль
У каждого разработчика есть свой стиль. Это множество неписанных правил, которые выполняются разработчиком автоматически в процессе написания кода. Как ставить скобки, когда вставлять пустые строки, как писать комментарии и многое другие. Такой код будет легко сопровождать, он структурирован и понятен. Давайте добавим Ассистенту наш узнаваемый стиль, чтобы при написании кода он использовал наши правила. Инструкции мы оформим в отдельном файле references\Style.md. Этот файл будет, как и другие в этой папке, без YAML заголовка, потому что мы не хотим вызывать этот файл самостоятельно, в виде отдельного Скилла. Промт по созданию этого файла я приводить не буду, мы просто перечисляем набор своих правил, создаем .md-файл, потом проверяем и дополняем. Затем вносим изменения в основной файл:
## Шаг 1. Добавь секцию `## Style` в `SKILL.md` Сразу после секции `## Project File` (перед `## Technical Task Validation`), по образцу секций Logging и Project File - короткий указатель на файл: ## Style Every generated script must follow the style rules defined in **`references/Style.md`** - brace style and commenting conventions, formatting rules, and the "Unauthorized Correction Strictly Forbidden" rule. Apply the style to the generated `.mq5` during Step 3; where the etalon template's layout conflicts with the style, the style rules win. ## Шаг 2. Добавь пункт в `### Step 3: Edit the Script` Сразу после пункта про Short Name (`#define NAME`): - Apply the style rules from **`references/Style.md`** to the generated script (brace style and commenting conventions, formatting) - the style takes precedence over the etalon template's own layout ## Проверка При генерации скрипта по тегу `Artifact: Simple Script MQL5` убедись, что сгенерированный `.mq5` следует `references/Style.md` ...Мы завершили первый этап в развитии исходного Скилла и теперь предложим Ассистенту тест:
Создай артефакт Artifact: Simple Script MQL5 с длинным именем new_script10, коротким именем nscr10 в подпапке MQL-TUTOR стандартной папки метатрейдера для скриптов. Веди файл проекта. Входные параметры: bool bFlag = true;//flag. Добавь бизнес-логику: добавь локальную переменную типа string. Если bFlag истина, то эта локальная переменная = "sun", а если ложная, то "moon". Выведи значение этой переменной.
Что ожидаем: артефакт будет создан в папке \MQL5\Scripts\MQL-TUTOR\new_script10\ . в этой же папке будет создан лог-файл new_script10.log, файл проекта new_script10.md и сам скрипт. В результате мы получаем ожидаемый результат. Весь набор полученных файлов будет прикреплен к статье, а тут мы покажем генерированный скрипт:
//+------------------------------------------------------------------+ //| new_script10.mq5 | //| Copyright 2026 August, MetaQuotes Ltd. | //| https://www.mql5.com | //+------------------------------------------------------------------+ #property copyright "Copyright 2026 August, MetaQuotes Ltd." #property link "https://www.mql5.com" #property version "1.00" #property icon "tutor_script.ico" #property description "Tutor Script" #property script_show_inputs #define NAME "nscr10" //--- input parameters input bool InpFlag = true; // flag //+------------------------------------------------------------------+ //| Script program start function | //+------------------------------------------------------------------+ void OnStart() { string sValue; if(InpFlag) { sValue = "sun"; } else { sValue = "moon"; } // if(InpFlag) Print(sValue); } // void OnStart() //+------------------------------------------------------------------+
Допускаю, что многим этот стиль покажется откровенно плохим. Критик может изменить в этом стиле все - достаточно просто скорректировать набор правил в references\Style.md. В этом огромное преимущество Скиллов — его можно переписать практически полностью, сделать удобным и понятным.
Но давайте подведем некоторые промежуточные итоги. Мы развивали Скилл, многое добавили, потом убрали, исправляли. Возможно остался "мусор" и он может помешать генерации, добавить трудно обнаруживаемые ошибки. Поэтому пишем важный промпт и отдаем его Ассистенту:
Перечитай основной файл Скилла и все .md-файлы. Нет ли в них "воды", повторов? Возможно ли что-то сократить / убрать?
Может быть есть неоднозначности? Результат вполне ожидаем, Ассистент исправляет неточности, убирает повторы, делает другую работу. В результате наш Скилл суммарно сокращается на 107 строк! Это почти 20% от всего объема и данный факт демонстрирует важность и необходимость периодической уборки мусора.
Подключаем МСП
В первой части мы разобрали роль уже подключенного МСП в работе со встроенным Ассистентом. Но мы хотим подключить еще один — Context7. Я не буду занимать время и место пояснениями о предназначении данного МСП, это хорошо известный сервис. Он предоставляет самую свежую документацию. Например, если завтра Ассистенту потребуются сведения о чем-то неожиданно новом, например об Apache Kafka, то он сможет обратиться в Context7 за информацией.
Кроме того, мы пишем независимый Скилл, который должен работать с разными CLI и Ассистентами. Но им будет недоступен уже подключенный к терминалу МСП. В таком случае они смогут обращаться в Context7 за помощью в понимании MQL. Поэтому получаем API key для доступа к Context7 (необходима регистрация) и подключаем в настройках MetaEditor - эндпойнт: https://mcp.context7.com/mcp и полученный API key. Делаем рестарт и спрашиваем у Ассистента о том, какие МСП ему доступны. Ответ Ассистента:
... custommcp2 Документация (Context7) Актуальная документация по библиотекам и фреймворкам
Теперь напишем инструкции для Скилла. Мы хотим, чтобы Ассистент использовал Context7 при необходимости. Вот основные принципы, которые мы записываем в Скилл:
- В основном мы используем встроенный MetaTrader AI Assistant без Context7.
- Context7 — опциональный подраздел для МСП — совместимых Ассистентов/CLI (Claude, opencode и т.д.).
- Возможно, что в будущем потребуется подключение еще какого либо сервиса.
Мы разместим инструкции по работе с новым МСП в отдельном файле references\Documentation.md. Как и ранее, его мы тоже будем делать без YAML заголовка, потому что не считаем данный модуль самостоятельным Скиллом. Особую сложность при написании инструкций представляла необходимость изолировать знающий MQL встроенный Ассистент от ненужных запросов.
Далее вносим дополнительный раздел в основной файл Скилла, чтобы сказать Ассистенту о новом источнике информации и когда к нему обращаться:
## Documentation Lookup (MCP, optional) If an MCP documentation tool (e.g. Context7) is available, it can be used to resolve doubt about anything beyond the MQL5 language core. See **`references/Documentation.md`** for the full rules - this is optional and the skill works fully without it.
Модуль получился довольно сложный, стоит проверить, насколько хорошо его понимает Ассистент. Пишем короткий промпт и отправляем его Ассистенту:
Скажи мне, как ты понимаешь инструкции по документации. Сделай короткое резюме по новому модулю.Ассистент находит несколько несущественных противоречий, мы их устраняем, запрос повторяем до тех пор, пока у Ассистента не остается вопросов и замечаний:
Опциональный модуль, подключающий MCP-инструменты документации (например, Context7) к процессу генерации MQL5-скриптов. Скилл полностью работоспособен и без него - модуль лишь позволяет разрешать сомнения фактами вместо консервативного отказа по умолчанию. Область применения ограничена двумя точками workflow: валидацией input-параметров (проверка неизвестного типа) и, при явном запросе бизнес-логики, подтверждением поведения незнакомых функций. К Pre-flight проверкам (тег, имена, каталог) модуль не относится. Ядро - дерево решений из четырёх случаев: встроенный тип MQL5 → валиден без поиска; кастомный тип, описанный в самом задании → валиден без поиска; запрещённый тип (struct/class/union и т.п.) → пропуск без поиска; неизвестный тип → единственный случай, запускающий документационный запрос. Ключевой принцип модуля - «поиск разрешает неопределённость, но не отменяет правила». Документация может лишь подтвердить, что тип на самом деле является встроенным (которого агент не узнал), или не подтвердить его - тогда действует консервативное правило «пропустить и уведомить». Поиск не способен легализовать явно запрещённые случаи и не создаёт «третьего пути» для кастомных типов: для них единственный легальный источник - сам промпт задания. Такой подход обеспечивает предсказуемость: при любом исходе запроса агент либо включает валидный параметр, либо пропускает его с объяснением пользователю.
В настоящий момент ответ нас устраивает, но к окончательному выводу мы придем после завершения всех этапов тестирования.
Режим Edit
Мы приступаем к объемному и непростому разделу Скилла — режиму редактирования (Edit). В прошлой статье мы отнеслись к нему довольно упрощенно, считая, что этот раздел будет коротким и сделанным на основе уже готового режима Create. Действительность очень быстро нас отрезвила. Этот режим такой же непростой, как и режим Create, а в некоторых местах даже сложнее. Перечислим некоторые, наиболее важные моменты:
-
Как именно включать режим Edit. Первая версия правила выглядела просто: если папка с таким <Long Name> уже есть - редактируем. Нет —создаём и это режим Create. Все просто, никакой лишней логики. Но нас это не устраивает. Причина — обычная опечатка. Пользователь хотел создать новый скрипт ExportHistoryToCSV2, ошибся на одну цифру и наш Скилл может молча редактировать чужой, никак с этим запросом не связанный, файл. Тихая порча чужих данных без предупреждения, это то, чего в инструменте для генерации кода быть не должно. Выход очевиден — сделать вход в Edit с явным подтверждением. Реализация двухшаговая:
Первый запуск на существующей папке:
- СТОП. Ничего не пишем, ничего не логируем.
- Спрашиваем: "Редактировать файл <файл> — да или нет?"
- Edit продолжается как обычно.
- Ошибка: попытка Create поверх уже существующего скрипта. СТОП.
Целевой файл при этом определяется отдельно - по умолчанию берётся <Long Name>.mq5 , но пользователь может явно указать любой другой .mq5 или .mqh внутри той же папки. Если указанный файл не найден — это тоже повод остановиться, а не создавать его с нуля: Cкилл не знает, был ли это прерванный Create, или папка вообще принадлежит другому типу программы (индикатору, советнику).
- Редактируем только .mq5 и .mqh файлы.
- Копирайт и номер версии не редактируются. Копирайт — намеренное исключение. Дата в нём фиксирует начало работы над артефактом, а не последнюю правку, и Edit её не меняет. То же касается `#property version`. Всё остальное можно менять свободно, с оглядкой на общие правила стиля (`references/Style.md`).
- Пользовательские типы. Когда генерируется скрипт, то Ассистенту доступны сведения о типах и он сразу может валидировать локальные переменные и входные параметры. В режиме Edit ему предстоит более сложная задача: Проверить, описан ли тип в области видимости, можно ли его применять во входных параметрах. И если обнаружится ошибка, сообщить пользователю подробную информацию вида: "Тип ххх доступен, но не может быть использован...".
- Что делать, если в редактируемый файл без входных параметров добавляется хотя бы один. Или наоборот, если удаляются все входные параметры. Следует ли добавлять / удалять #property script_show_inputs, #property description и иконку?
- Проблема редактирования входных параметров. В Create список параметров из промпта заменял плейсхолдер в шаблоне. В Edit параметры в артефакте реальные и промпт может требовать самые разные действия: добавить, изменить, переименовать, удалить.
Возьмём переименование. Ищем вхождения по всем .mq5 и .mqh файлам папки проекта, и сначала спрашиваем подтверждение у пользователя. Дело в том, что переименование затрагивает файлы, для которых явного подтверждения на правку никто не давал.
Смена типа параметра устроена похоже, но зеркально: если параметр нигде в проекте не используется — меняем спокойно, только проверив совместимость нового типа со старым значением по умолчанию. А если используется — останавливаемся и просим пользователя самого решить: он лучше нас понимает, для чего служит редактируемая переменная.
Удаление. Лежащее на поверхности решение об автоматическом удалении всех использований переменной — плохая идея: Ассистент может не понять контекст правильно и сломать что-то незаметное. Поэтому итоговое правило: подтверждаем удаление самой декларации, а все места использования перечисляем пользователю (файл и номер строки), не изменяя их. - Опечатки в виде кириллических символов.
Добавляем режим Edit. Он включается только если проект уже есть. сейчас, если папка с проектом не существует, то это стоп и выход. Но это может быть переходом в режим edit. Для этого обязательно должно быть указано длинное имя, существовать папка проекта и имя файла, который редактируется. Если такого файла нет, то его надо создать. Это же относится к логу и файлам проекта. Если они есть, то дописываются. Если нет, то создаются. Как тебе?
Я привожу здесь этот промпт в самом первоначальном, наивном виде. К окончательному решению мы пришли после довольно длительной совместной работы с Ассистентом Разработчиком, в течение которой он активно предлагал свои варианты.
В конце работы мы отдаем готовый Скилл на ревью второму Ассистенту Пользователю. Предлагаем ему такой промпт:
Мы добавили в скилл mql-tutor режим Edit. Внимательно изучи все инструкции и скажи, все ли тебе понятно. Ищи неточности, противоречия, неоднозначности. Возможно, что-то нужно добавить, или удалить? Пиши свои выводы по пунктам, сразу их разберем и исправим.
Ассистент выдает приличный список замечаний, мы их обсуждаем, в конце концов разрабатывается список исправлений. Ассистент Пользователь редактирует инструкции раздела. Потом выдает положительный вердикт: "Все исправлено, можно работать". Теперь со списком исправлений возвращаемся к первому Ассистенту Разработчику, просим его посмотреть и утвердить исправления. В результате получается отдельный файл с инструкциями references/Edit.md. Как и прочие файлы в этой папке, он создан без YAML заголовка и не может быть самостоятельным Скиллом.
С этого момента мы считаем работу над разделом завершенной и готовой к тестированию.
Тестирование режима Edit
Мы подготовили 15 тестов этого режима в одном .md-файле (прикреплен к статье). Принцип простой: сначала создаём скрипт, затем пытаемся его редактировать. Отдаем файл с тестами Ассистенту Пользователю и он последовательно их выполняет. Файл с полным отчетом о тестировании находится в одном архиве с тестами. Некоторые комментарии по итогам:
- Тесты 1-4 отработали без отклонений. Это были тесты на включение режима Edit. Ни разу модель не приняла решение о входе в Edit самостоятельно, а это и было главной целью тестирования - не дать ассистенту редактировать чужой код без подтверждения. Это и подтвердилось.
- Правильно сработала инструкция про несовместимые значения по умолчанию при изменении типа. Ассистент не стал молча заменять 0 на false при смене int на bool, а остановился и спросил. Именно это консервативное поведение и заложено в инструкции.
Вот короткий отчет Ассистента Пользователя по всем пятнадцати тестам:
Итог всех 15 тестов ✅ Тест Название Итог 1 Gate: first encounter ✅ строго STOP + вопрос 2 Gate: confirmation ✅ правка без повтора тега, run-block 3 Gate: decline ✅ ошибка, ничего не записано 4 Target file not found ✅ STOP, файл/папка, ни создать 5 Add new param ✅ Symbol добавлен 6 Add matching type ✅ правка default, без дубля 7 Add type mismatch ✅ [ERROR], не изменён 8 Edit non-existent ✅ [ERROR], не создан 9 Rename ✅ подтверждение всегда 10 Type change (unused) ✅ тип сменён, default ⇔ false 11 Type change (used) ✅ тип не сменён, отчёт/ожидание 12 Remove param ✅ подтверждение, удаление, отчёт 13 No-input→with-input ✅ добавлен, без иконки/#property 14 Custom enum (#include) ✅ Mode добавлен 15 Custom struct (не enum) ✅ Config пропущен Все 15 тестов пройдены - фактические результаты совпадают с Expected. 📋
Итог нас удовлетворяет, поэтому считаем сложный этап разработки с добавлением режима Edit завершенным.
Скрипты для работы со Скиллами
Сразу надо сказать, что далее речь пойдет не о скриптах, как артефактах MQL. Мы посмотрим, как работать с .bat файлами. А если смотреть еще шире, то на примере работы с .bat файлами мы ответим на вопрос, нужно ли Скиллу, который занимается генерацией кода, запускать что-то самостоятельно? Генерация кода это работа с текстом. Прочитать шаблон, подставить параметры, записать файл. Никакого исполнения не требуется, верно?
Это верно до тех пор, пока не возникает необходимость массово копировать файлы, проверять, существуют ли папки и прочее. Скопировать / переместить два файла может и Ассистент, но если их будет несколько сотен, какое количество токенов будет затрачено на эту работу? Не говоря уже о том, что Ассистент может просто ее не выполнить, или выполнить наполовину, а пользователю заявит, что просто хотел сэкономить время и токены (это вполне реальный случай из моей практики). В этом случае реальный выход — прибегнуть к помощи операционной системы. Пишем .bat файл, выполняем его, скрипт копирует столько файлов, сколько нужно.Скрипт легко редактировать, его может написать тот же Ассистент и его могут запустить все — пользователь и сам Ассистент.
Оптимальный путь — Ассистент пишет скрипт, выполняет его и проверяет результат. Однако во встроенном Ассистенте MetaTrader это невозможно, потому что он не может запускать скрипты. Создавать .bat, или Python скрипты — да, запустить — нет. Это ограничение платформы. Но мы разрабатываем универсальное решение, которое будет работать с Claude Code, например. В таком случае выполнение скриптов возможно. Поэтому нам важно получить ответ как можно раньше — может ли Ассистент запускать скрипты? и в любом случае нам придется поддерживать два решения:
- Ассистент Разработчик пишет скрипты, которые подлежат выполнению согласно инструкциям Скилла. Ассистент Пользователь не может запускать скрипты. Он сам, своими встроенными возможностями решает задачу, предназначенную скрипту, читает и проверяет результат.
- Ассистент Разработчик пишет скрипты, которые подлежат выполнению согласно инструкциям Скилла. Ассистент Пользователь запускает скрипт, читает и проверяет отчет, созданный скриптом.
Где и как выяснить, по какому пути пойдет поток выполнения? Очень просто. Один раз за сессию нужно попытаться запустить заранее созданный Ассистентом Разработчиком .bat файл. Если получилось, то выполнение идет по второму пути, если нет — по первому. И конечно, эта проверка должна быть в самом начале Скилла. Ассистент сделает ее и запомнит результат на всю сессию.
Давайте напишем этот важный .bat, от которого так много зависит. Сделаем и сам скрипт, и результаты его выполнения полезными. Давайте поручим Ассистенту Разработчику написать .bat файл по проверке "здоровья" Скилла.
Проверка "здоровья" Скилла
Насколько важна такая проверка? Ответ довольно очевиден: Скилл — это не один файл, а набор из SKILL.md, справочных материалов в references/ и эталонных шаблонов в assets/. Стоит потерять хотя бы один из них — результат непредсказуем: то ли Скилл сломается на первом же шаге, то ли, что хуже, тихо продолжит работать с неполными правилами, не предупредив об этом никого. Поэтому ответ: да, безусловно. Причём проверка должна случиться раньше, чем что-либо ещё, включая проверку обязательного тега Artifact: Simple Script MQL5. Какой смысл сверять тег задачи, если сам Скилл, возможно, повреждён? Проверять мы будем очень просто — проверим наличие всех файлов Скилла, список которых нам хорошо известен. Разделим этот список на две части:
- Необязательные файлы, их отсутствие работу не останавливает. На текущий момент в этом списке только один файл: assets/tutor_script.ico.
- Обязательные файлы — на данный момент это все остальные. При их отсутствии продолжение работы невозможно.
=== MQL-TUTOR HEALTH CHECK === Date : 25.08.2026 0:34:20,80 Status : OK --- Files --- [OK] SKILL.md [OK] references\Documentation.md [OK] references\Edit.md [OK] references\Logging.md [OK] references\Project.md [OK] references\Style.md [OK] references\HealthCheck.md [OK] assets\etalon_no_input.mq5 [OK] assets\etalon_with_input.mq5 [OK] assets\tutor_script.ico --- Summary --- Files checked : 10 Missing : 0 Warnings : 0 === END OF REPORT ===
Как и было решено ранее, проверка выполняется двумя способами, в зависимости от того, что доступно Ассистенту. Если health_check.bat удаётся запустить — Ассистент читает отчёт, который скрипт записывает в Scripts\health_check_report.txt. Если запустить не удалось — Скилл проверяет тот же список файлов сам, своими средствами, без запущенного процесса. Результат в обоих случаях один и тот же: статус OK или FAILED.
Что будет, если статус окажется FAILED? Это будет означать, что нет необходимого для работы файла и продолжение работы невозможно. Об этом будет сообщено пользователю и Скилл работу прекратит.
Выполненная работа по добавлению скриптов и новых инструкций по проверке здоровья потребовала новых модулей Скилла и внесения изменений в основной файл, его текущий размер 355 строк. Мы записали .\MQL5\Files\SKILLS\MQL-TUTOR\references\HealthCheck.md, посвященный проверке здоровья и новую директорию: .\MQL5\Files\SKILLS\MQL-TUTOR\Scripts\ с файлом health_check.bat и файлом ScriptsForSkill.md с инструкциями касательно запуска health_check.bat и его отчета health_check_report.txt.
Как и раньше, протестируем результаты. Напишем два коротких теста:
Тест 1. script_for_check2 (с входным параметром) Создай Artifact: Simple Script MQL5 с длинным именем script_for_check2 и коротким именем scfc2 в поддиректории CHECK_HEALTH. Добавь входной параметр типа bool bFlag = false; // флаг Тест 2. script_for_check1 (без входных параметров) Создай Artifact: Simple Script MQL5 с длинным именем script_for_check1 и коротким именем scfc1 в поддиректории CHECK_HEALTH.
Кроме того, удалим tutor_script.ico из Скилла. Отдаем тесты на выполнение Ассистенту. В первую очередь нас интересует, по какому пути пойдет поток выполнения и как будет пройдена проверка "здоровья":
# MQL-TUTOR - Test Report Date: 2026-08-25 Executing agent: MetaTrader Assistant (MetaEditor built-in AI assistant) ## 1. Self Health Check (Session Health Check) This is the skill's first Pre-flight check, performed **once per session** (see `references/HealthCheck.md`). Below is exactly how it was carried out. ### 1.1. Chosen path: file-based fallback (no script execution) Per `references/HealthCheck.md` §3, the primary path is attempting to run `Scripts/health_check.bat`. However, the built-in MetaTrader assistant has no ability to run OS processes (`.bat`/Python) - a documented platform limitation, also noted in the skill's `project.md`. Therefore, per the §4 fallback, the check was performed **directly via the agent's own file access tools** - listing/reading the skill's files, without executing any scripts. ### 1.2. What was checked **Mandatory files** (any missing → Status BAD, STOP): | File | Result | |------|--------| | `SKILL.md` | OK | | `references/Documentation.md` | OK | | `references/Edit.md` | OK | | `references/Logging.md` | OK | | `references/Project.md` | OK | | `references/Style.md` | OK | | `references/HealthCheck.md` (the file itself, self-referential) | OK | | `assets/etalon_no_input.mq5` | OK | | `assets/etalon_with_input.mq5` | OK | **Optional file** (absence → only `[WARNING]`, does not affect status): | File | Result | |------|--------| | `assets/tutor_script.ico` | **WARNING - missing** | ### 1.3. Health check outcome - **Health status: OK** - all mandatory files present. - **Script-execution flag** remembered for the session as **not available** (fallback path used). No re-probe was performed. - **Note:** the missing `tutor_script.ico` was logged as a `[WARNING]` and reported to the user in the first test's report. The agent did not edit the script (removing `#property icon`) on its own - the "Unauthorized Correction Strictly Forbidden" rule from `references/Style.md` applies: warn only, never fix. ... Both tests passed the full Create workflow of the skill: Health Check → Tag Check → Project Setup Validation → log → template → generation → report.
Тестирование заканчивается успешно. Мы видим, что "здоровье" проверено, при этом выбран верный путь и оба тестовых скрипта созданы. Это говорит нам о том, что мы и дальше можем использовать скрипты, так как способ нами разработан и проверен.
Копирование файлов
При генерации Ассистенту необходимо выполнить еще одну файловую операцию. Это копирование файлов шаблона. В нашем случае это максимум два файла. Выше мы уже приводили аргументы, почему для копирования файлов стоит прибегнуть к помощи .bat файла — количество копируемых файлов может быть весьма большим. Поэтому создаем Scripts\copy_files.bat, который делает ровно это: копирует файлы по маске из одной папки в другую, попутно проверяя, что каждый файл действительно появился на месте.
Раньше мы уже разобрали, что скрипты работают только для тех исполняющих агентов, которые способны запускать процессы. Асисстент MetaEditor к их числу не относится — для него копирование файлов остаётся его собственной задачей без запущенного скрипта.
Тестировать этот раздел с помощью Ассистента мы не станем. Это уже сделано много раз, когда мы тестировали другие разделы. Поэтому считаем этот вопрос закрытым. Но мы протестируем сразу всю нашу ветку инструкций по файловым операциям с помощью Ассистента, который поддерживает запуск скриптов. Это OpenCode CLI ("Command Line Interface", "Интерфейс командной строки"). мы не будем тестировать пограничные случаи, а просто предложим ему создать обычный скрипт, мы такой уже создавали раньше:
Создай артефакт Artifact: Simple Script MQL5 с длинным именем new_script10, коротким именем nscr10 в подпапке MQL-TUTOR-OPENCODE папки f:\Program Files\Forex\RoboForex MT5\MQL5\Scripts\. Веди файл проекта. Входные параметры: bool bFlag = true;//flag. Добавь бизнес-логику: добавь локальную переменную типа string. Если bFlag истина, то эта локальная переменная = "sun", а если ложная, то "moon". Выведи значение этой переменной.
OpenCode без малейших проблем создает нам скрипт в папке, которую мы указали. При этом ведет лог и создает файл проекта:
=== MQL-TUTOR RUN 2026-08-28 20:08:00 === Long Name : new_script10 Short Name : nscr10 Start time : 2026-08-28 20:08:00 End time : 2026-08-28 20:08:30 Duration : 0m 30s Status : OK [INFO] Run started. [INFO] Run finished.
Теперь мы считаем тест пройденным и текущие задачи завершенными.
Завершение работы над Скиллом
Нам остался последний штрих, последняя инструкция в Скилл — что именно считать успешным выполнением задания, что считать результатом работы? В зависимости от режима, у нас будут два критерия успешной генерации:
- Для режимаCreate это будет созданный артефакт.
- Для режима Edit это будет сохраненный артефакт.
Это решение могло бы быть иным: успешная генерация/редактирование артефакта — скомпилированный .ex5 файл. Но на данном этапе мы считаем это преждевременным. Встроенный Ассистент сделает компиляцию и без дополнительных инструкций, а для Ассистента типа OpenCode это отдельный большой раздел, недостаточно сильно связанный с темой Скилла. Поэтому пока ограничимся теми критериями, которые мы уже привели и занесем их в раздел Result Definition нашего Скилла.
Заключение
Мы проделали довольно большую работу. Из сделанного в прошлой статье простого Скилла мы получили уже вполне работоспособный инструмент с самопроверкой, логированием и ведением проекта. Мы подключили дополнительный МСП и добавили свой стиль. И все это для того, чтобы создавать простые скрипты? Конечно же нет. В результате у нас получилась гибкая система, которую можно легко адаптировать для генерации индикаторов, советников и не только. Эту систему легко развивать, добавлять новые модули, настраивать старые, вводить новые правила. В нашем проекте восемь дополнительных модулей. Их легко можно выделить в Share блок так, чтобы ими могли пользоваться другие, еще не написанные Скиллы. Ну и конечно мы видим возможности для развития текущего проекта. Например использовать несколько Ассистентов, что потребует оркестрации, или одного, но в разных ролях. И вполне возможно мы этим займемся в дальнейшем.
Прикрепляю к статье файл проекта самого Скилла. Это последовательный поток разработки почти без редактирования. Уверен, что это будет интересно многим.
И в самом конце — немного статистики:
- Нам удалось сохранить на приемлемом уровне размер основного файла Скилла: 368 строк.
- Мы разработали дополнительно семь модулей, которые содержат 814 строк инструкций.
- Всего Скилл состоит из 15 файлов, включая отчеты и содержит 1182 строки инструкций
| # | Имя | Тип | Описание |
|---|---|---|---|
| 1 | Edit_mode_tests_EN.zip | Архив | Файл с тестовыми заданиями по режиму Edit и файл с отчетом по выполнению теста. |
| 2 | health_test_report.zip | Архив | Файлы c отчетом по выполнению тестов с проверкой "здоровья" |
| 3 | MQL-TUTOR.ZIP | Архив | Файлы Скилла MQL-TUTOR. Архив следует распаковать в папку \MQL5\Files\MQL-TUTOR |
| 4 | references.zip | Архив | Файлы модулей Скилла: Documentation.md, Edit.md, HealthCheck.md, Logging.md, Project.md, Style.md |
| 5 | project.zip | Архив | Файл проекта разработки Скилла |
| 6 | Scripts.zip | Архив | Файлы скриптов: copy_files.bat, health_check.bat, Отчет скрипта health_check.bat: health_check_report.txt и файл с инструкциями: ScriptsForSkill.md |
| 7 | MQL5.zip | Архив | Архив со всеми файлами, который можно распаковать в каталог установки терминала, и все файлы будут расположены в необходимых местах |
Предупреждение: все права на данные материалы принадлежат MetaQuotes Ltd. Полная или частичная перепечатка запрещена.
Данная статья написана пользователем сайта и отражает его личную точку зрения. Компания MetaQuotes Ltd не несет ответственности за достоверность представленной информации, а также за возможные последствия использования описанных решений, стратегий или рекомендаций.
Особенности написания Пользовательских Индикаторов
Нейросети в трейдинге: Адаптация прогноза при смене рыночного режима (Окончание)
Мультиброкерский и мультивалютный граф: симуляция арбитражной торговли
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования