Menü
Правила использования RLM tools для проектного поиска и навигации по 1C/BSL
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
When writing or reviewing BSL, apply 1C standards
При написании или ревью BSL применять стандарты 1С
Orchestrator: routing work and agent phases
Оркестратор: маршрутизация работы и фаз агентов
BSL LSP navigation: definitions, refs, call graph
Rules for using RLM tools for project search and navigation in 1C/BSL
| name | rlm-bsl-search |
| description | Правила использования RLM tools для проектного поиска и навигации по 1C/BSL |
Используй этот навык, когда работаешь с 1C/BSL и для ответа нужна проектная разведка по исходникам конфигурации, даже если пользователь явно не просил "поиск".
| Ситуация | Первый инструмент |
|---|---|
| Найти реализацию процедуры, функции, обработчика, подписки, регламентного задания | rlm_start |
| Понять, где используется объект метаданных, реквизит, табличная часть, форма, роль, запрос | rlm_start |
| Найти похожую реализацию перед изменением BSL-кода | rlm_start |
| Разобраться в бизнес-механизме или цепочке вызовов по проекту | rlm_start |
| Исследовать XML/MDO/forms/rights/query и связи с BSL-кодом | rlm_start |
| Оценить blast radius изменения в 1C-конфигурации | rlm_start, затем точечная проверка через BSL LS |
Главное правило: для широкого 1C/BSL поиска используй RLM до Grep, Glob, широкого Read, Bash rg, grep, find и ручного рекурсивного чтения файлов.
| Если тебе нужно... | Используй |
|---|---|
| Найти, где в проекте живёт механизм, похожая реализация или бизнес-цепочка | RLM first |
| Найти все проектные связи объекта: BSL, запросы, XML/MDO, формы, права, подписки, регламентные задания | RLM first |
| Понять blast radius до выбора конкретного файла/символа | RLM first |
| Перейти к definition/references уже известного символа в конкретном месте | BSL LS first |
| Получить hover, signature, completion, diagnostics, code actions, rename | BSL LS first |
| Проверить изменённый BSL-файл после правки | BSL LS diagnostics, затем финальная проверка через v8-runner |
| Быстро прочитать один известный файл/фрагмент | Read / LSP file tool |
Модель работы: RLM отвечает на вопрос “где и что искать по проекту?”, BSL LS отвечает на вопрос “что точно означает этот символ/тип/позиция?”. Если задача начинается с неясной бизнес-потребности или широкого поиска по 1C-исходникам — начинай с RLM. Если задача уже позиционная — начинай с BSL LS.
| Ситуация | Инструмент |
|---|---|
| Нужны diagnostics, hover, signature, completion | BSL LS/LSP tools |
| Нужны definition/references/rename/formatting/code actions по уже известной позиции | BSL LS/LSP tools |
| Нужно прочитать один уже известный файл или маленький фрагмент | Read или LSP file tool |
| Поиск не относится к 1C/BSL исходникам | обычные инструменты поиска |
| RLM недоступен, индекс сломан или явно не подходит | fallback на Grep/rg, зафиксировав причину |
| Инструмент | Когда использовать | Подводные камни |
|---|---|---|
rlm_start | Открыть сессию проектной разведки по 1C/BSL исходникам | path должен указывать на source root 1C, а не на произвольный root репозитория |
rlm_execute | Выполнить батч поиска/навигации через helper'ы RLM | Печатай компактный результат, не большие тела файлов |
rlm_help | Выбрать helper/recipe перед нетривиальной разведкой | Вызывать до rlm_execute, если стратегия из rlm_start недостаточна |
rlm_end | Закрыть RLM-сессию | Закрывай после завершения разведки |
rlm_index | Проверить состояние индекса (info) или администрировать индекс | Build/update обычно делает контейнер, не агент |
rlm_projects | Работать с registry проектов RLM | Не нужен для обычной сессии, если известен path |
rlm_start.query передай короткую рабочую цель разведки. Это не промпт во внутреннюю LLM: query помогает RLM выбрать effort, strategy и business recipe.path передай каталог исходников 1C-конфигурации, обычно <project-root>/src, или точный root конфигурации, где лежит Configuration.xml. Не передавай root git-репозитория, если он не является root исходников 1C.rlm_start: session_id, warnings, index status, extension context, strategy, available functions.rlm_help до rlm_execute.rlm_execute: пиши компактный Python, используй helper'ы RLM и печатай только полезный результат.rlm_end, когда разведка закончена.path должен указывать на каталог, где RLM сможет найти дерево исходников 1C:
<project-root>/src
<project-root>/src/xml
<project-root>/src/cf
Допустим и точный каталог конфигурации, содержащий Configuration.xml.
MCP proxy может нормализовать относительные, host и container paths, но это только техническое преобразование пути. Семантика не меняется: путь должен вести к исходникам 1C, а не к произвольному каталогу проекта.
rlm_start.query сам по себе не вызывает LLM. Он задает цель сессии и влияет на:
rlm_execute.Опциональные llm_query и llm_query_batched доступны только внутри rlm_execute, если сервер RLM настроен с LLM provider. Без LLM RLM остается deterministic index/search/navigation tool.
Предпочитай один содержательный rlm_execute вместо множества мелких Grep/Read.
Для сложной разведки разделяй работу на фазы:
rlm_execute — только discovery: найти и дедуплицировать кандидатов (объекты, методы,
регистры, формы), вывести компактную таблицу name/category/path/count и следующий шаг.rlm_execute — профиль 3-5 выбранных production-кандидатов (get_object_profile,
get_object_full_structure, extract_queries), без callers по всем найденным методам.rlm_execute — точечный trace/callers/usages только для методов, выбранных после профиля.Не смешивай в первом батче discovery + профили объектов + callers/call hierarchy. Такой вывод быстро
становится шумным, попадает в лимиты max_output_chars и теряет хвост результата.
Выводи компактно:
Не печатай большие тела файлов без необходимости. Сначала найди кандидатов и только потом читай точные фрагменты.
Дедуплицируй варианты регистра и языка поисковых терминов (PnL/PNL/Pnl, OKX/okx,
русские падежи), а также исключай тестовые расширения/модули из production-вывода, если задача не про
тесты. Если тестовые находки нужны как evidence, печатай их отдельной секцией с лимитом.
Обычно агент не строит индекс руками. Контейнер сам запускает RLM build/update:
rlm_index используй в основном для диагностики info. Ручные build, update, drop применяй только когда явно нужно администрировать индекс или исправлять его состояние.
rlm_start(query="найти существующую реализацию <механизм>", path="<project-root>/src")rlm_help(category="discovery").rlm_execute: сначала search(...) / search_methods(...), затем точечно read_file(...) или helper для usages/callers.rlm_end.rlm_start(query="оценить использования объекта метаданных <Объект>", path="<project-root>/src")rlm_execute: найти code usages, формы, запросы, права, подписки, регламентные задания.rlm_end.rlm_index(action="info", path="<project-root>/src").build/update/drop делай только если это явно нужно для восстановления индекса.Правильно:
Нужно понять, где рассчитывается скидка.
1. rlm_start(query="найти расчет скидки и связанные вызовы", path="<project-root>/src")
2. rlm_execute: search("скидк"), search_methods("Скид"), get_callers(...)
3. Read/BSL LS только по найденным конкретным файлам/позициям.
Почему: RLM использует индекс и helper'ы, не тащит в контекст тысячи файлов.
Неправильно:
Grep("Скид", glob="**/*")
Read десятков найденных файлов
Bash rg по всему src
Почему: широкий raw search по большой 1C-конфигурации медленнее, шумнее и теряет связи метаданных, форм, прав, запросов и графа вызовов.
RLM first:
BSL LS first:
Raw search fallback: