<< All versions
Skill v1.0.1
Automated scan100/100steelmorgan/1c-agent-based-dev-framework/code-verification
+1 new
──Details
PublishedJune 21, 2026 at 11:17 AM
Content Hashsha256:3248c395cc7047eb...
Git SHAf0ac1fdfcab1
Bump Typepatch
──Files
Files (1 file, 9.2 KB)
SKILL.md9.2 KBactive
SKILL.md · 133 lines · 9.2 KB
version: "1.0.1" name: code-verification description: "MUST use WHEN BSL-код изменён перед коммитом или передачей на ревью. Provides трёхслойную проверку: LSP-диагностику, VALIDATE_BSL через Напарника и верификацию платформенного API через bsl-platform-context." uses_capabilities:
- get_diagnostics
- ask_ai_assistant
- search_syntax_reference
- getMembers
- getMember
- getConstructors
- get_hover_info
alwaysApply: false
Верификация кода (Code Verification)
Навык описывает порядок проверки BSL-кода после внесения правок. Три слоя проверки, каждый ловит свой класс ошибок.
Когда применять
| Триггер | Действие | |
|---|---|---|
| После изменения BSL-кода | Полный цикл (все 3 слоя) | |
| Ревью чужого кода | Слой 2 + Слой 3 | |
| Вопрос пользователя «проверь синтаксис» | Полный цикл |
Слои проверки
Слой 1 — LSP-диагностика (быстрая)
Цель: немедленная обратная связь по изменённому файлу.
get_diagnostics(uri)— получить ошибки/предупреждения от BSL Language Server.- Если есть
error-уровень — исправить до перехода к слою 2. - Если LSP недоступен — перейти к слою 2, отметив что LSP-проверка пропущена.
Слой 2 — Напарник (VALIDATE_BSL)
Цель: проверка синтаксиса, стандартов, поиск аналогов в БСП.
Что передавать: целиком процедуры/функции, в которых были правки. Не фрагменты, не отдельные строки — полные тела методов.
Вызов: ask_ai_assistant с шаблоном VALIDATE_BSL из buddy-prompting.
Как интерпретировать результат:
| Ситуация | Действие | |
|---|---|---|
| Напарник нашёл ошибки | Проанализировать каждую. Ложные «необъявленная переменная» на глобальные методы — фильтровать. Остальное — исправить или обосновать. | |
| Напарник не нашёл ошибок | НЕ считать доказательством корректности. У Напарника ограниченный контекст — он не видит проект. Перейти к слою 3. | |
| Напарник рекомендует замену на БСП | Проверить через search_ssl_functions, что рекомендованная функция существует. |
Слой 3 — Верификация платформенного API
Цель: подтвердить, что каждый используемый в коде платформенный объект, метод, свойство и конструктор реально существует на указанном типе.
Алгоритм:
- Извлечь из изменённого кода все обращения к платформенному API:
Новый <Тип>(...)— создание объектов<Объект>.<Метод>(...)— вызовы методов<Объект>.<Свойство>— чтение/запись свойств- Обращения к менеджерам, перечислениям, предопределённым значениям
- Для каждого обращения — верифицировать:
| Что в коде | Как проверить | Capability | |
|---|---|---|---|
Новый <Тип> | Тип существует? | search_syntax_reference → get_type_info | |
Новый <Тип>(парам1, парам2) | Конструктор с такими параметрами? | getConstructors | |
Объект.Метод() | Метод есть на этом типе? | getMember | |
Объект.Свойство | Свойство есть на этом типе? | getMember | |
| Тип неясен | Поиск по имени | search_syntax_reference → getMembers | |
| Тип переменной/выражения неизвестен | Вывести тип значения под курсором | get_hover_info |
- Особое внимание — коллекционные типы. API
Структура,Соответствие,ТаблицаЗначений,Массивразличается. Не предполагать одинаковые методы — проверять на конкретном типе.
- Определение типа переменной. Когда непонятно, какой тип у переменной (а значит — какой API на ней допустим),
get_hover_info(uri, line, character)по имени переменной возвращает выведенный BSL LS тип значения (Type System v2). Это вывод типа конкретного значения в этой точке, а не справка по всем типам платформы. Затем верифицировать члены полученного типа черезgetMember/getMembers. Еслиget_hover_infoнедоступен — определить тип по месту объявления/присваивания черезnavigate_symbol.
Иерархия доверия
v8-runner syntax … (компилятор) ← формальная проверка, финальный вердикт> get_diagnostics (LSP) ← быстрая диагностика> bsl-platform-context ← авторитетный справочник API> ask_ai_assistant ← совещательный голос (не доверять отсутствию ошибок)
При расхождении — побеждает источник выше по иерархии.
Формат отчёта
По итогам проверки — структурированный вывод:
- LSP: ошибки / предупреждения (или «LSP чист / недоступен»).
- Напарник: найденные проблемы + рекомендации (или «замечаний нет — НО это не гарантия»).
- Платформенный API: подтверждённые / неподтверждённые обращения.
- Итог: тип каждой проблемы —
синтаксис/ошибка API/нарушение стандарта/рантайм-риск.
Ошибки и ограничения
| Проблема | Обходной путь | |
|---|---|---|
| LSP недоступен | Пропустить слой 1, перейти к слою 2. Отметить в отчёте. | |
| Напарник недоступен | Пропустить слой 2. Усилить слой 3. | |
bsl-platform-context не знает тип | Тип из проекта (не платформенный) — проверить через navigate_symbol. | |
| Ложная «необъявленная переменная» от Напарника | Нормально для глобальных методов — фильтровать. | |
search_syntax_reference пустой | Уточнить имя типа (русское/английское написание), проверить версию. | |
| Напарник рекомендует несуществующую функцию БСП | Проверить через search_ssl_functions. |
Capabilities
| Capability | Слой | Назначение | |
|---|---|---|---|
get_diagnostics | 1 | LSP-диагностика файла | |
ask_ai_assistant | 2 | VALIDATE_BSL через Напарника | |
search_ssl_functions | 2 | Проверка рекомендаций по БСП | |
search_syntax_reference | 3 | Поиск платформенного типа | |
get_type_info | 3 | Информация о типе | |
getMembers | 3 | Список членов типа | |
getMember | 3 | Проверка конкретного члена | |
getConstructors | 3 | Проверка конструктора | |
get_hover_info | 3 | Вывод типа значения переменной/выражения под курсором | |
navigate_symbol | 3 | Определение типа переменной по объявлению (fallback к get_hover_info) | |
v8-runner syntax … | * | Финальная проверка компилятором (CLI; см. навык v8-runner) |
depends_on: [syntax-checking, buddy-prompting, code-navigation]