| name | 1c-analyst |
| description | Анализ и архитектура задач 1С: разбор задачи/ЧТЗ, какие контуры/базы существуют и что с чем связано, что затронет изменение, где уже реализован функционал; подготовка качественного ЧТЗ (ожидаемое поведение + модель данных + критерии приёмки) и архитектурных решений. ОБЯЗАТЕЛЬНО используй, когда анализируешь или уточняешь задачу по 1С, определяешь контур и базу, оцениваешь влияние доработки, готовишь/проверяешь ЧТЗ, формулируешь уточняющие вопросы, решаешь нужен ли архитектор, или проектируешь на уровне архитектуры (не написания BSL). Срабатывай даже без слов «анализ/архитектура», если речь о понимании задачи, контуров, влияния или подготовке требований. Главное правило: искать в ОБОИХ слоях контура (конфигурация + расширение) и проверять по РЕАЛЬНОМУ коду через MCP, не по памяти. Написание/ревью BSL — скилл `1c-dev`.
|
Анализ и архитектура 1С
Локализация (сначала, если есть)
Если в скилле есть каталог references/local/ — прочитай его ПЕРЕД работой: version-stack.md
(версии платформы/библиотек, режим совместимости, префиксы ТВОЕЙ компании) и остальные карты.
При противоречии локальное побеждает generic. Контракт — docs/SKILL_LOCALIZATION.md toolkit.
Скилл аналитика/архитектора: понять задачу и контур, что с чем связано, что затронет изменение, и подготовить
ЧТЗ/архитектурное решение так, чтобы дальше тех-лид и dev-фаза (1c-dev) превратили это в атомарные задачи и код.
Железное правило анализа
- Контур = конфигурация (основа) + подключённое расширение. Искать функционал в ОБОИХ слоях.
- Проверять по РЕАЛЬНОМУ коду через MCP (
find_object/search/read_module), не по памяти. Нет в коде — так и
скажи, гипотезу помечай [проверить].
- Слой не загружен в MCP-индекс → это «не загружено», НЕ «функционала нет».
Роли и границы
- Аналитик — владелец бизнес-смысла: проблема/потребность, ожидаемое поведение, границы, логическая модель
данных, бизнес-ошибки и запреты, критерии приёмки. НЕ описывает реализацию.
- Архитектор — границы и ограничения целевой архитектуры; «архитектурное решение = СТАТУС принятия тех-проекта»;
ADR при неопределённости. Подключается при риске/влиянии на архитектуру.
- Соседние: тех-лид пишет тех-проект/контракты и дожимает технику; разработчик +
1c-dev превращают
артефакт в атомы и код. Контуры аналитики и разработки независимы, связаны через артефакты + трекер; уточнение
требований в процессе реализации = возврат в аналитический контур.
Контуры и базы — карта в данных локализации
Карта контуров вынесена в данные, не в тело скилла: config/contours.example.md (generic-шаблон) → СВОЙ файл
в локализации (config/contours.<org>.md). Там: какие конфигурации/базы, какие слои (конфигурация + расширения),
что с чем связано, риски переноса, слепые зоны, незагруженные слои. Заполняется по РЕАЛЬНОМУ коду (оба слоя) и
держится согласованным со scope-группами из config/layers.*.toml (машинная раскладка слоёв для поиска). Так
локализация под организацию = обновить данные, а не править скилл/движок. Шаблон конвенций слоёв для dev — в 1c-dev
(references/conventions-template.md).
Трекер задач и база знаний — достать контекст и связать с кодом
Часть функционала НЕ в git (внешние обработки, обмены, настройки в данных) — «в коде не нашёл» без проверки базы
знаний неполно. Обезличенный CLI scripts/atlassian.py (stdlib, без MCP) достаёт постановку из трекера и знания из
вики в стиле Jira/Confluence; свой домен и токен — через env (JIRA_URL/JIRA_PAT, CONFLUENCE_URL/CONFLUENCE_PAT),
ничего в коде не меняя. Паттерн «связать воедино» задача→код→база знаний, команды и слепые зоны —
references/tracker-and-knowledge-base.md. Карта разделов базы знаний (id, «когда смотреть») — org-данные:
каркас references/knowledge-base-map-template.md → заполнить в Team-слое локализации, не в публичном ядре.
Артефакты-спеки и правило «поведение, не реализация»
Операционный цикл аналитика, что внутри артефактов и чек-лист «хорошего ЧТЗ для dev-цикла» —
references/analysis-workflow.md. Ядро: ЧТЗ описывает ОЖИДАЕМОЕ ПОВЕДЕНИЕ, а НЕ способ реализации. В ЧТЗ
нельзя DTO/сигнатуры/имена модулей/серверный-клиентский контекст/стиль кода — это тех-проект тех-лида. Размер→
глубина: S минимум, M light-ЧТЗ, L/XL полное ЧТЗ + тех-проект.
- Структура и качество требований, канон-разделы ЧТЗ, уровни требований, INVEST, логическая модель данных —
references/requirements-and-chtz.md.
- Рамки документов (document frames) — реестр типов документов (бриф/паспорт, ЧТЗ, тех-проект, контекст-заметка,
карточка инцидента, страница сопровождения), у каждого: состав блоков, правила (что можно/нельзя), владелец-роль,
критерии готовности, дефолтные шаблоны мирового уровня (29148/INVEST/EARS, arc42/ADR, ISO/IEC 25010) —
references/document-frames.md. Перед написанием любого документа определи его рамку, загрузи её (локализация
заказчика переопределяет generic поблочно), пиши строго по блокам и соблюдай правила; сессионный оверрайд состава
допустим, при подтверждении закрепляется в локализацию.
- Архитектурный артефакт «Архитектура решения», C4, нотации (BPMN/IDEF/UML/ER) —
references/architecture-design.md.
Фаза уточнения (/clarify) до передачи
Прежде чем гнать задачу дальше — структурированный gap-анализ: что неясно, границы, данные/откуда, сложные кейсы,
бизнес-ошибки/запреты, критерии приёмки. Конкретные вопросы, не «непонятно». Шаблон — в analysis-workflow.
Как готовить вход для dev-цикла
Хороший ЧТЗ + тех-проект — это то, что 1c-dev декомпозирует на атомы и код. Дай: чёткие границы, логическую модель
данных, измеримые критерии приёмки, бизнес-ошибки/запреты, контуры/влияние. Чем точнее вход, тем чище атомы и код.
Анализ влияния
find_object + чтение модулей + search по ОБОИМ слоям контура. Учесть слепые зоны (что зашито в данных/настройках,
а не в коде) и незагруженные слои. Интеграционная часть (перечень потоков данных, контракты, выбор REST/событийной
модели, чек интеграции) — references/integration-and-api-design.md.
Когда подключать архитектора
Меняются архитектурные принципы/домены/слои? Влияет на несколько подсистем/контуров? Новый/нетиповой паттерн?
Правила не дают ответа? → архитектурное решение. Иначе → архитектурное согласование. При сомнении — в пользу архитектора.
Артефакт «Архитектура решения» и его разделы, C4, нотации — references/architecture-design.md.
Чек-листы качества
Готовность к разработке (DoR/INVEST), готовность результата (DoD), чек-листы качества требования и архитектурного
решения, этапы внедрения и приёмка — references/quality-checklists.md.
Роли-режимы
explorer (найти, как устроено) · analytic (требования, модель данных, критерии) · planner (границы, влияние) ·
architect (границы/ограничения, ADR, «Архитектура решения») · arch-reviewer (проверить тех-проект на соответствие архитектуре).
Версионный стек
Настрой под свою конфигурацию (версия платформы, режим совместимости, версии библиотек) и не предлагай API вне
своего режима совместимости.
