Skd Design

---
name: skd-design
description: "Используй, когда задача требует проектировать или проверять структуру и семантику отчета на СКД 1С либо изменять модель СКД или настройки: наборы данных, поля, ресурсы, итоги, роли, параметры, варианты, пользовательские настройки, расшифровки или программную компоновку. Не используй для чистого написания или изменения текста запроса — это задача query-writing."
---

# Проектирование и ревью СКД

Проектируй смысл отчета отдельно от механики его XML. Сначала определи правильную модель данных и настройки, затем подбери доступный специализированный инструмент для работы с артефактом.

## Что прочитать

| Тема задачи | Файл |
|---|---|
| Наборы, поля, ресурсы, итоги, связи и роли | [references/data-model.md](references/data-model.md) |
| Параметры, варианты и пользовательские настройки | [references/settings.md](references/settings.md) |
| Программное управление компоновкой и внешние данные | [references/programmatic.md](references/programmatic.md) |
| Ревью, RLS, производительность и проверка результата | [references/review.md](references/review.md) |

Прочитай каждый файл, относящийся к задаче, целиком. Для комплексного проектирования или ревью прочитай все четыре.

## Порядок работы

1. Зафиксируй назначение отчета, пользователей, измерения, показатели, период, детализацию и контрольные итоги.
2. Для существующей СКД сначала получи структурированное представление доступным анализатором. Читай сырой XML фрагментами только для деталей, которых нет в представлении.
3. Проверь контекст отчета: объект-владелец, существующий запрос и BSL-код, варианты, права, настройки проекта и разрешенную область изменения XML.
4. Спроектируй наборы данных, поля, вычисления, ресурсы, роли, параметры, структуру и настройки. Для текста запросов используй `query-writing`.
5. В начале инструментального этапа зафиксируй требуемые возможности и выбранные средства. Если один полноценный комплект покрывает весь цикл, используй его. Если анализ, создание или изменение и проверка разделены между средствами, собери минимальный связный набор, явно опиши границы передачи результата и не смешивай внутренние форматы без необходимости.
6. Изменяй XML только по явной задаче пользователя и только в области, разрешенной `CLAUDE.md`. Если изменение запрещено, подготовь точные инструкции для Конфигуратора или EDT.
7. После изменения выполни структурную проверку, проверку запроса и функциональную проверку сформированного отчета на характерных данных.
8. В результате укажи проектные решения, примененные инструменты, доказательства проверки и оставшиеся непроверенными риски.

## Выбор инструментальной возможности

| Потребность | Что искать среди доступных средств |
|---|---|
| Понять существующую СКД | Структурированный анализатор схемы |
| Создать СКД | Генератор или компилятор СКД |
| Изменить существующую СКД | Средство точечного редактирования |
| Проверить структуру | Валидатор СКД |
| Сравнить или существенно переработать схему | Обратное преобразование, если оно доступно и его ограничения приемлемы |
| Проверить фактическое поведение | Средства выполнения 1С и контрольные данные |

Названия и способ вызова зависят от установленного комплекта. Не выдумывай отсутствующие команды. Если специализированного средства нет, скилл все равно применяется для проектирования и ревью; отсутствие инструмента не расширяет разрешения на изменение XML.

## Граница с `query-writing`

`skd-design` определяет структуру и семантику отчета. `query-writing` отвечает за корректную и производительную реализацию текста запроса, включая запрос набора данных СКД. Для чистого написания или изменения текста запроса используй только `query-writing`; если задача затрагивает также модель или настройки СКД, используй оба скилла с этим разделением ролей.

## Формат результата

- назначение и требования к отчету;
- выбранная модель СКД и обоснование решений;
- план или факт изменения артефактов;
- результаты структурной, запросной и функциональной проверок;
- риски, ограничения и непроверенные предположения.

## Типичные ошибки

- переход к XML до определения бизнес-смысла отчета;
- универсальный порядок выбора между полем запроса, вычисляемым полем и ресурсом;
- использование вариантов вместо обычных пользовательских отборов;
- неправильные роли периодов, измерений и остатков;
- доверие только структурной валидации;
- расширение видимости данных ради отчета без отдельного решения по правам;
- привязка процесса к одному поставщику инструментов.