# 1c Analyst > Анализ и архитектура задач 1С: разбор задачи/ЧТЗ, какие контуры/базы существуют и что с чем связано, что затронет изменение, где уже реализован функционал; подготовка качественного ЧТЗ (ожидаемое поведение + модель данных + критерии приёмки) и архитектурных решений. ОБЯЗАТЕЛЬНО используй, когда анализируешь или уточняешь задачу по 1С, определяешь контур и базу, оцениваешь влияние доработки, готовишь/проверяешь ЧТЗ, формулируешь уточняющие вопросы, решаешь нужен ли архитектор, или проектируешь на уровне архитектуры (не написания BSL). Срабатывай даже без слов «анализ/архитектура», если речь о понимании задачи, контуров, влияния или подготовке требований. Главное правило: искать в ОБОИХ слоях контура (конфигурация + расширение) и проверять по РЕАЛЬНОМУ коду через MCP, не по памяти. Написание/ревью BSL — скилл `1c-dev`. - Skill: `vgtitov/1c-analyst` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add vgtitov/1c-analyst` - Raw SKILL.md: https://api.skillmd.com/api/skills/vgtitov/1c-analyst/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: vgtitov (https://skillmd.com/u/vgtitov) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/vgtitov/1c-analyst --- # Анализ и архитектура 1С ## Локализация (сначала, если есть) Если в скилле есть каталог `references/local/` — прочитай его ПЕРЕД работой: `version-stack.md` (версии платформы/библиотек, режим совместимости, префиксы ТВОЕЙ компании) и остальные карты. При противоречии локальное побеждает generic. Контракт — `docs/SKILL_LOCALIZATION.md` toolkit. Скилл аналитика/архитектора: понять задачу и контур, что с чем связано, что затронет изменение, и подготовить ЧТЗ/архитектурное решение так, чтобы дальше тех-лид и dev-фаза (`1c-dev`) превратили это в атомарные задачи и код. ## Железное правило анализа 1. **Контур = конфигурация (основа) + подключённое расширение.** Искать функционал в ОБОИХ слоях. 2. Проверять по РЕАЛЬНОМУ коду через MCP (`find_object`/`search`/`read_module`), не по памяти. Нет в коде — так и скажи, гипотезу помечай **[проверить]**. 3. Слой не загружен в MCP-индекс → это «не загружено», НЕ «функционала нет». ## Роли и границы - **Аналитик** — владелец бизнес-смысла: проблема/потребность, ожидаемое поведение, границы, логическая модель данных, бизнес-ошибки и запреты, критерии приёмки. НЕ описывает реализацию. - **Архитектор** — границы и ограничения целевой архитектуры; «архитектурное решение = СТАТУС принятия тех-проекта»; ADR при неопределённости. Подключается при риске/влиянии на архитектуру. - Соседние: **тех-лид** пишет тех-проект/контракты и дожимает технику; **разработчик + `1c-dev`** превращают артефакт в атомы и код. Контуры аналитики и разработки независимы, связаны через артефакты + трекер; уточнение требований в процессе реализации = возврат в аналитический контур. ## Контуры и базы — карта в данных локализации Карта контуров вынесена в **данные**, не в тело скилла: `config/contours.example.md` (generic-шаблон) → СВОЙ файл в локализации (`config/contours..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 вне своего режима совместимости.