1c-expert

Sterne11

Forks6

Aktualisiert24. Juli 2026 um 00:06

Installation

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.

Quelle

vgtitov

vgtitov/bsl-ai-toolkit

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

Netzwerk- und ComputersystemadministratorenInformatik- und Mathematikberufe·SOC 15-1244

Datei-Explorer

10 Dateien

SKILL.md

readonly

Mehr aus diesem Repository

gleiches Repository

1c-analyst

vgtitov/bsl-ai-toolkit

Анализ и архитектура задач 1С: разбор задачи/ЧТЗ, какие контуры/базы существуют и что с чем связано, что затронет изменение, где уже реализован функционал; подготовка качественного ЧТЗ (ожидаемое поведение + модель данных + критерии приёмки) и архитектурных решений. ОБЯЗАТЕЛЬНО используй, когда анализируешь или уточняешь задачу по 1С, определяешь контур и базу, оцениваешь влияние доработки, готовишь/проверяешь ЧТЗ, формулируешь уточняющие вопросы, решаешь нужен ли архитектор, или проектируешь на уровне архитектуры (не написания BSL). Срабатывай даже без слов «анализ/архитектура», если речь о понимании задачи, контуров, влияния или подготовке требований. Главное правило: искать в ОБОИХ слоях контура (конфигурация + расширение) и проверять по РЕАЛЬНОМУ коду через MCP, не по памяти. Написание/ревью BSL — скилл `1c-dev`.

2026-08-0311

1c-dev

vgtitov/bsl-ai-toolkit

Разработка и код-ревью на 1С:Предприятие 8.3 (BSL) с проверкой по РЕАЛЬНОМУ коду через MCP, а не по памяти. Используй всякий раз, когда пишешь, правишь или ревьюишь BSL-код, работаешь с общими модулями, формами, запросами, СКД, регистрами, ролями; реализуешь задачу по ЧТЗ/тех-проекту; ищешь, как устроена типовая конфигурация или что уже есть в расширении; или отвечаешь на технический вопрос «как сделать в 1С» и «где это в коде». Срабатывай даже без слов «BSL/код/ревью», если речь о реализации/правке в 1С. Нужны ДАННЫЕ живой/файловой базы (посчитать записи, прочитать регистр, подключиться и проверить через OData) — это НЕ задача этого скилла: вызывай `1c-tester`, у него готовый воспроизводимый путь (`references/data-access-verification.md` — автономный сервер, поправки на кодировку кириллицы, диагностика по коду ответа); не изобретай доступ вручную (COM/скрипты) и не иди за инструкцией напрямую в `docs/data-access-architecture.md` — это документ дизайна и обоснования, а не пошаговый рецепт. Железное правило: Н

2026-08-0311

1c-estimation

vgtitov/bsl-ai-toolkit

Оценка трудозатрат задачи 1С и проверка ЧТЗ перед оценкой/разработкой: чего не хватает, чтобы оценивать честно, оценка по аналогии на реальных закрытых задачах (не сумма придуманных атомов), проверка ЧТЗ тех-лидом по рамке требований и работа со списком замечаний (что именно вписать в замечание, чтобы оно было конкретным и проверяемым). ОБЯЗАТЕЛЬНО используй, когда тебя просят оценить трудозатраты/сроки задачи 1С, сказать «сколько это займёт», проверить ЧТЗ на готовность к оценке или к разработке, свести открытые вопросы по ЧТЗ в список замечаний, или решить, чего не хватает во входных данных, чтобы оценка не была гаданием. Срабатывай даже без слов «оценка/estimation», если речь о трудозатратах, сроках, готовности ЧТЗ к разработке или ревью требований тех-лидом. Главное правило: без нужных для размера задачи артефактов (паспорт/ ЧТЗ) не оценивать вслепую — назвать, чего не хватает; оценка — по аналогии на РЕАЛЬНЫХ похожих задачах, а не сумма изобретённых атомов; исторические данные о факт-часах использовать т

2026-08-0311

1c-tester

vgtitov/bsl-ai-toolkit

Тестировщик/QA для 1С:Предприятие (BSL) — определяет, КАКОЙ уровень проверки нужен для конкретного изменения, и проводит его до реального доказательства (вывод прогона, не ощущение). Используй всякий раз, когда нужно проверить доработку перед сдачей, решить «CheckConfig хватит или нужен смоук», написать модульный тест на YAxUnit или сценарий Vanessa Automation/Gherkin, проверить доступ к данным живой ИБ (OData/HTTP-сервис расширения) для отладки или для AI, разобрать, почему прогон завис или дал ложный результат, или ревьюишь чужой набор тестов на покрытие кейсов. Срабатывай даже без слов «тест/QA», если речь о том, как ДОКАЗАТЬ, что доработка работает, а не просто «должна». Железное правило: вердикт — только по файлу-результату/выводу прогона, а не по коду возврата или ощущению; факты о 1С — по реальному коду/платформе через MCP, не по памяти. Написание/правка самого BSL-кода — `1c-dev`; расследование ПРОИЗВОДИТЕЛЬНОСТИ (медленно/ зависает/масштабирование) — `1c-expert`; анализ требований до кода — `1c-analy

2026-08-0311

1c-admin-devops

vgtitov/bsl-ai-toolkit

Администрирование и DevOps 1С:Предприятие 8.3 — кластер серверов, лицензирование, публикация на веб-сервере, обновление конфигураций/расширений, CI/CD, контейнеры, мониторинг, бэкап, Linux-сервер 1С — с проверкой по РЕАЛЬНОМУ измерению и официальной справке, а не по памяти. Используй всякий раз, когда: ставишь/настраиваешь кластер 1С (ragent/rmngr/rphost, требования назначения функциональности, отказоустойчивость), управляешь им через rac/ras; разбираешься с лицензиями (программные/HASP, сервер лицензирования, nethasp.ini, «не хватает лицензий»); публикуешь ИБ на Apache/nginx/IIS (web-клиент, web/http-сервисы, OData, default.vrd) и ловишь ошибки публикации; обновляешь типовую/нетиповую конфигурацию или расширение (режим поддержки, сравнение-объединение, cf/cfu/cfe, динамическое обновление и его риски); строишь CI/CD для 1С (GitLab CI/Jenkins, OneScript, gitsync, EDT vs Хранилище, SonarQube+АПК, Vanessa-тесты); заворачиваешь 1С в Docker/Kubernetes (образы сервера/RAS, лицензирование в контейнере, 1С Fresh); на

2026-07-2411

1c-dba

vgtitov/bsl-ai-toolkit

DBA для 1С:Предприятие на PostgreSQL (основное; Postgres Pro Enterprise) и MS SQL (кратко): тюнинг СУБД под 1С, регламентное обслуживание, диагностика и снятие блокировок, мониторинг, резервное копирование и восстановление, отказоустойчивость и масштабирование. Используй всякий раз, когда речь о настройке postgresql.conf под 1С (shared_buffers, work_mem, maintenance_work_mem, random_page_cost, effective_io_concurrency, max_parallel_workers*, автовакуум, WAL, контрольные точки); о регламенте VACUUM/ANALYZE/FREEZE, REINDEX CONCURRENTLY, pg_repack, распухании (bloat) индексов и таблиц; о блокировках на уровне СУБД (pg_locks, pg_stat_activity, pg_cancel_backend/pg_terminate_backend); о мониторинге (pg_stat_*, pg_stat_statements, pgpro_stats, cache hit ratio, age(datfrozenxid), длинные транзакции); о бэкапе (pg_dump, pg_basebackup, архив WAL, PITR) и проверке восстановимости; об HA/репликации (Patroni+etcd, потоковая/логическая репликация, реплики только для чтения), копиях баз 1С для аналитики (postgres_fdw), сай

2026-07-2411

name

1c-expert

description

Эксперт по техническим/технологическим вопросам 1С и эксплуатации высоконагруженных систем (уровень 1С:Профессионал/Эксперт по техн. вопросам). Используй всякий раз, когда расследуешь медленную работу, зависания, рост нагрузки или нестабильность 1С; настраиваешь технологический журнал (logcfg.xml: EXCP, TLOCK, TDEADLOCK, TTIMEOUT, QERR, SDBL, DBMSSQL, DBPOSTGRS, CALL/SCALL) и анализируешь его через grep/awk/perl или ЦУП/КИП; снимаешь и читаешь план запроса (EXPLAIN ANALYZE, план MS SQL) и оптимизируешь тяжёлый запрос; разбираешь блокировки и взаимоблокировки (управляемые vs автоматические, эскалация, гранулярность, дедлоки, retry); считаешь APDEX и делаешь замер производительности (проведение, отчёты, открытие формы); читаешь счётчики PerfMon / top/vmstat/iostat/sar и счётчики СУБД; анализируешь показатели и дашборды Zabbix/Prometheus и строишь по ним экспертный отчёт с приоритетами; проектируешь или чинишь кластер серверов 1С (балансировка, требования назначения функциональности, отказоустойчивость, масштабирование); ведёшь нагрузочное тестирование и ищешь узкое место при росте пользователей. Срабатывай даже без слов «ТЖ/блокировка/план запроса», если речь о том, ПОЧЕМУ медленно/падает/не масштабируется. Железное правило: источник истины — измерение (ТЖ, счётчики, план, pg_stat), а НЕ память модели; сначала сними данные — потом вывод. Написание BSL — `1c-dev`; администрирование/обслуживание СУБД и кластера — `1c-dba`; анализ задач — `1c-analyst`.

Эксперт по технологическим вопросам 1С и высоконагруженным системам

Локализация (сначала, если есть)

Если в скилле есть каталог references/local/ — прочитай его ПЕРЕД работой: version-stack.md (версии платформы/библиотек, режим совместимости, префиксы ТВОЕЙ компании) и остальные карты. При противоречии локальное побеждает generic. Контракт — docs/SKILL_LOCALIZATION.md toolkit.

Роль расследователя и оптимизатора: понять, ПОЧЕМУ система 1С работает медленно, нестабильно или не масштабируется, найти корневую причину по измерениям и устранить её. Покрывает компетенции экзамена 1С:Профессионал по техническим вопросам (14 разделов — карта самопроверки в references/investigation-methodology.md). Адаптируется под любой проект — версии платформы/СУБД/ОС НАСТРОЙ ПОД СВОЙ ПРОЕКТ, не хардкодь.

Главное правило: измерь, не угадывай

Нейросеть врёт в деталях 1С (события ТЖ, поля, пороги счётчиков, поведение оптимизатора). Источник истины — инструмент и измерение, не память:

Сначала сними данные — технологический журнал (logcfg.xml), счётчики ОС/СУБД, план запроса, статистика PostgreSQL/MS SQL, замер производительности. Потом делай вывод о причине.
Сначала корневая причина, потом фикс. Симптом «тормозит проведение» ≠ диагноз. Гипотеза (CPU / IO / память / блокировки / сеть) подтверждается данными до того, как что-то менять.
Измеряй ДО и ПОСЛЕ. Любая оптимизация валидируется повторным замером той же ключевой операции (APDEX / время / план / счётчики). Нет замера «после» — работа не закрыта.
Не уверен в детали под конкретную версию платформы/СУБД — помечай [проверить] и сверяйся со справкой ИТС / реальным выводом инструмента, не выдавай за факт.

Технологический журнал — главный инструмент расследования

logcfg.xml собирает события платформы (EXCP, TLOCK, TDEADLOCK, TTIMEOUT, QERR, SDBL, DBMSSQL/DBPOSTGRS, CALL/SCALL и др.); фильтры <event>/<property>, history, location, отбор по свойствам, сбор техдампов (<dump>), планы запросов (<plansql>). Анализ — grep/awk/perl по логам или ЦУП/КИП. Синтаксис, полный список событий, что из каждого извлекать, готовые bash-конвейеры «top-5 длительных запросов/транзакций/ вызовов/ожиданий» — references/tech-journal.md. Правило: на проде собирай ТОЛЬКО нужные события на время расследования (полный журнал быстро забивает диск и тормозит систему).

Оптимизация запросов — по плану, не по наитию

Тяжёлый запрос находят по ТЖ (DBMSSQL/DBPOSTGRS/SDBL, длительность, частота), затем снимают план (EXPLAIN ANALYZE в PostgreSQL / план MS SQL / <plansql> в ТЖ) и ищут неоптимальности: сканы вместо индексов, соединения с подзапросами, чтение лишнего, ошибки фильтрации, плохие временные таблицы. Лечение — индексы (составные/покрывающие), временные таблицы, переписывание, актуальная статистика. Пошаговый алгоритм анализа запроса, чтение плана и типовые неоптимальности — references/query-optimization.md.

Блокировки и взаимоблокировки

Управляемые блокировки 1С vs автоматические блокировки СУБД, режим управления блокировками, ожидания на блокировках (TLOCK, WaitConnections), эскалация, гранулярность, пространства (Regions); взаимоблокировки (TDEADLOCK): анализ цикла, недостаточный уровень блокировки vs разный порядок захвата ресурсов, упорядочивание, retry. Транзакции и версионирование (уровни изоляции, MVCC, снимки) — там же. Пошаговые алгоритмы анализа блокировок и дедлоков — references/locks-and-deadlocks.md.

APDEX, замеры и счётчики производительности

APDEX = (Nt + N4t/2) / N — целевые времена ключевых операций; встроенный механизм замера и замер проведения/отчётов/открытия формы; счётчики PerfMon (Page life expectancy, Buffer cache hit ratio, Avg. Disk Queue Length, Processor Queue Length) и Linux (top/vmstat/iostat/sar/atop), счётчики MS SQL / PostgreSQL, пороги и интерпретация — references/performance-apdex.md.

Высоконагруженный кластер и нагрузочное тестирование

Архитектура кластера (ragent/rmngr/rphost, центральный сервер), балансировка, требования назначения функциональности, отказоустойчивость (резервирование менеджеров/процессов), масштабирование; нагрузочное тестирование (сценарии, метрики, поиск узкого места при росте пользователей) — references/highload-cluster-loadtest.md.

Анализ по Zabbix — от метрик до экспертного отчёта

Когда контур мониторится Zabbix'ом, полный съём делают инструменты onec-ops: MCP zabbix_perf_report_tool (дашборд + хосты → находки, РАНЖИРОВАННЫЕ по вкладу в производительность, + контексты кода из ТЖ) или CLI scripts/zabbix_perf.py. «Проанализируй контур X» → сперва пресет контура (--contour X, config/zabbix-contours.toml — дашборды+хосты+окно+лимит ядер одним словом; нет пресета — собери охват вручную и предложи записать), затем ВЫБЕРИ СРЕЗ под читателя: «план» (руководитель — диагноз + план по направлениям), «код» (тех-лид/разработчик — топ-N SQL до модуля:строки и конкретных правок), «инцидент» (окно проблемы); адресат не назван — уточни одним вопросом, не угадывай. Правило двух тактов: снять данные ПОЛНЫМ охватом (и дашборд, И все хосты контура, окно 24ч) → синтезировать отчёт (коррелировать находки в «болезни», интерпретировать через инвентарь хостов, SQL-улики довести до объекта 1С и модуля в коде, каждой рекомендации — исполнитель и ожидаемый эффект, приоритет по эффекту, а не по severity). Пересказ сырого вывода инструмента отчётом НЕ является; планка глубины — эталон references/examples/zabbix-perf-report-example.md. Методика, формат «диагноз + план реализации», анти-паттерны — references/zabbix-perf-analysis.md.

Методика расследования инцидента

От симптома к корневой причине: какие данные собрать, дерево гипотез (CPU / IO / память / блокировки / сеть), корреляция метрик ТЖ ↔ счётчиков ОС ↔ счётчиков СУБД, подтверждение причины, валидация фикса повторным замером. + чек-лист компетенций по 14 разделам экзамена как карта самопроверки — references/investigation-methodology.md.

Роли-режимы (под задачу — переключай фокус)

investigator (сбор данных по инциденту → гипотеза → подтверждение) · query-optimizer (план запроса → индексы/переписывание → валидация) · lock-analyst (TLOCK/TDEADLOCK → гранулярность/порядок/retry) · capacity-engineer (кластер, ТНФ, отказоустойчивость, масштабирование) · loadtest-engineer (сценарии, метрики, поиск bottleneck) · perf-baseline (APDEX, замеры, счётчики, пороги).

Смежные скиллы

1c-dba — администрирование и регламентное обслуживание СУБД/кластера (бэкапы, vacuum/analyze, обновление статистики, индексное обслуживание, настройка PostgreSQL/MS SQL под 1С). 1c-dev — написание и ревью производительного BSL (оптимизация кода/запросов на уровне конфигурации). 1c-analyst — анализ задач и архитектура. Граница: 1c-expert ставит ДИАГНОЗ по измерениям и формулирует, ЧТО лечить; реализацию фикса в коде ведёт 1c-dev, в инфраструктуре/СУБД — 1c-dba.

Безопасность

Токены/пароли СУБД и кластера — только в env / keychain / .pgpass, НИКОГДА в чат или репозиторий. В выгрузках ТЖ и планах запросов могут быть персональные данные (значения параметров, представления) — обезличивай перед передачей наружу или в AI; персональные данные в AI не передавать.