---
name: gost-lab-report
description: >
  Оформление студенческих работ по ГОСТ 7.32: лабораторные, курсовые,
  ВКР, отчёты по практике, рефераты, контрольные.
  Используй когда: отчёт, лабораторная, курсовая, курсач, ВКР, диплом,
  практика, реферат, контрольная, ГОСТ, оформить работу, оформление,
  lab report, coursework, thesis.
---

# Оформление студенческих работ по ГОСТ 7.32

## Обзор

Скилл автоматизирует оформление студенческих работ: LLM генерирует Markdown, скрипт собирает .docx с правильными стилями и титульным листом. Покрываются все текстовые типы работ — лабораторные, курсовые, ВКР, отчёты по практике, рефераты, контрольные. Оформление тела едино (ГОСТ 7.32), титульники подключаемые (вуз × тип работы).

Сопутствующие файлы (читать по необходимости):
- **PROFILES.md** — детальные профили типов работ (структуры разделов, шаблон реферата ВКР, конвенции приложений). Читать перед аутлайном.
- **WIZARD.md** — подключение титульника нового вуза из .docx-бланка пользователя + реестр существующих шаблонов. Читать, когда нужного титульника нет в `templates/title_pages/`.
- **REVIEW.md** — финальная проверка собранного отчёта: verify-скрипт + визуальный осмотр рендера + чек-лист ГОСТ 7.32. Читать после сборки, перед сдачей пользователю.
- **ENVIRONMENTS.md** — проверенные окружения и версии зависимостей. Читать при сетапе или проблемах окружения.

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

1. **Анализ контекста.** Изучить всё, что предоставил пользователь: методичку, скриншоты, устные указания, тему. Определить тип работы и прочитать его профиль в PROFILES.md.
2. **Аутлайн.** Предложить полный outline отчёта: перечень разделов, что будет в каждом. Согласовать с пользователем.
3. **Уточнения.** Запросить недостающее: номер варианта, скриншоты (если требуются, но не предоставлены), конкретные параметры/данные, неоднозначности из методички. Можно совместить с аутлайном, если вопросов немного. Если контекста достаточно — пропустить.
4. **Генерация.** После согласования — генерировать Markdown и собирать .docx.
5. **Ревью.** Проверить собранный .docx по REVIEW.md (в идеале — независимым субагентом с чистым контекстом) и устранить замечания до сдачи пользователю.

Принцип: не генерировать вслепую, сначала синхронизироваться с пользователем. Но и не превращать в допрос.

## Окружение и установка

Быстрая проверка: `python scripts/check_env.py`. Зависимости слоями (детали и проверенные версии — ENVIRONMENTS.md):

- **Слой 0 (обязательный):** `pandoc` (2.17–3.10 проверено), pip-пакеты `python-docx`, `docxcompose`. Без него сборки нет — ставить сразу.
- **Слой 1 (опциональный):** LibreOffice + python-uno — только для авто-СОДЕРЖАНИЯ и `{{PAGES}}`. **Перед установкой спросить пользователя** (~700 МБ; альтернатива — обновить содержание в Word: Ctrl+A → F9). Это правило общее: тяжёлое/платное/требующее прав не ставим молча, sudo-команды отдаём пользователю.
- **Шрифты:** Times New Roman (mscorefonts) — желателен для локального рендера; сам .docx корректен и без него.

На Windows/macOS работает слой 0 (нативно); полный путь с авто-TOC на Windows — через WSL.

## YAML-метаданные

Каждый отчёт начинается с YAML front matter:

```yaml
---
title_page: "guap_lab"  # id шаблона из реестра templates/title_pages/registry.yaml; по умолчанию guap_lab
teacher_title: "должность, уч. степень, звание"
teacher_name: "И.И. Фамилия"
lab_number: "N"
lab_title: "Название лабораторной работы"
discipline: "Название дисциплины"
group: "Номер группы"
student_name: "И.И. Фамилия"
department: "Название кафедры"
add_toc: "true"  # автоматическое поле СОДЕРЖАНИЕ (обновляется в Word по F9); ставить для курсовых/ВКР/практики
number_headings: "true"  # нумерация разделов по ГОСТ 7.32: «1 Название», «1.1 …» (без точки после номера); для лаб не ставить
sections_new_page: "true"  # каждый раздел (H1) с новой страницы; для лаб не ставить
---
```

С `number_headings` заголовки в Markdown пишутся **без номеров** — номера проставит сборка (структурные элементы и приложения не нумеруются). С `sections_new_page` ручные `\newpage` перед разделами не нужны.

Подстановка генерическая: **любой** YAML-ключ доступен титульнику как `{{KEY}}` (и `{{KEY_UPPER}}` — капсом), поэтому набор полей определяется шаблоном титульника. Список шаблонов, их поля и специфика — в реестре `templates/title_pages/registry.yaml` (титульник выбирается по вузу и типу работы). Если указанного шаблона нет, build.py выведет список доступных. Незаполненные плейсхолдеры вычищаются с предупреждением — смотри вывод сборки.

**Важно:** поле `subtitle` не использовать — стиль Subtitle не настроен в шаблоне и даст непредсказуемое форматирование.

## Входной контекст

LLM может получить от пользователя:
- Методичку / задание на лабораторную (PDF, текст, скриншоты)
- Скриншоты выполнения работы
- Устные указания
- Или минимум контекста (только тема)

**Правила:**
- Если есть методичка — цель работы берётся оттуда дословно, структура разделов определяется заданием
- Если методички нет — LLM формулирует цель самостоятельно на основе темы, использует типовую структуру
- Если номер варианта неясен из контекста — запросить у пользователя

## Приоритет требований

1. **Контентный вход пользователя** — методичка, положение вуза, содержательные ГОСТы (ЕСПД 19.x, комплекс 34.x и т.п.), устные требования. Правило обработки: прочитать целиком → структуру диктует документ → требования, неприменимые к конкретной теме, сворачивать формально (кратким разделом, а не игнорировать). Сюда же относятся вузовские правила порядка списка источников (по алфавиту, с группировкой, секциями) — список пишется в Markdown сразу в требуемом порядке.
2. **Профиль типа работы** (ниже) — дефолт, когда входа нет или он неполный.
3. **Не покрывается скиллом**: вузовская типографика, отличная от ГОСТ 7.32 (свои поля, межстрочный интервал, отступы). Базовые стили фиксированы; если вуз требует иного — честно сказать пользователю, что это правится вручную в `templates/reference.docx`.

## Профили типов работ

**Перед аутлайном прочитай раздел своего типа работы в PROFILES.md** — там структуры разделов, YAML-флаги, шаблон реферата ВКР, конвенции приложений и детальные правила лабораторного отчёта. Титульник выбери по вузу и типу работы из реестра `templates/title_pages/registry.yaml`.

## Конвенции Markdown

### Заголовки

- `#` — разделы верхнего уровня
- `##` — подразделы
- `###` — пункты внутри подразделов
- Заголовки пишутся **без номеров** — нумерация отключена в шаблоне
- Капитализация: только первая буква с заглавной

### Таблицы

- Подпись таблицы **перед** таблицей в формате: `: Таблица N — Название`
- Используй pipe tables с выравниванием через `:`
- Колонки с числами выравнивай по центру разметкой `:---:` (дефолт — по левому краю, для чисел смотрится хуже)
- Для сложных таблиц с объединением ячеек — grid tables (ограниченная поддержка merge) или ручная правка в docx

### Изображения

- Формат: `![Рисунок N — Подпись](images/NN_описание.png){width=80%}`
- Перед рисунком — описательный абзац
- Файлы изображений в папке `images/`, именование: `NN_краткое-описание.png`
- Если есть файлы изображений — прочитай их через Read для генерации точных описаний

### Разрывы страниц

- `\newpage` — разрыв страницы (обрабатывается Lua-фильтром)
- Обязателен перед разделом «Выводы»

### Текст

- Обычные абзацы — просто текст, без специальной разметки
- Нумерованные списки: `1.`, `2.`, `3.`
- Маркированные списки: `-`

### Список использованных источников

Раздел `# Список использованных источников`, нумерованный список. Дефолт: **в порядке цитирования**, записи по ГОСТ 7.0.100-2018 (вузовский порядок — алфавит, группировка — имеет приоритет через контентный вход). В тексте ссылки в квадратных скобках: `[1]`, `[2, 3]` — каждый источник из списка должен быть процитирован.

Образцы записей:

```markdown
1. Дейт К. Дж. Введение в системы баз данных / К. Дж. Дейт. — 8-е изд. — Москва : Вильямс, 2019. — 1328 с.
2. Иванов И. И. Название статьи / И. И. Иванов, П. П. Петров // Название журнала. — 2025. — № 3. — С. 45–52.
3. Название материала // Название сайта : [сайт]. — URL: https://example.com/page (дата обращения: 10.07.2026).
4. ГОСТ 7.32-2017. СИБИД. Отчёт о научно-исследовательской работе. Структура и правила оформления. — Москва : Стандартинформ, 2017. — 27 с.
```

Правила: авторы «Фамилия И. О.», город полностью (Москва, Санкт-Петербург), между областями описания — тире (писать «—», сборка нормализует), у электронных ресурсов обязательны URL и дата обращения.

### Листинги кода

- Используй fenced code blocks с указанием языка: ` ```python ... ``` `
- В docx применяется стиль Source Code (моноширинный шрифт)
- Для лабораторных по программированию — вставляй ключевые фрагменты кода

## Продвинутые возможности

**Custom styles** — применение произвольного стиля из reference.docx:
```markdown
::: {custom-style="НазваниеСтиля"}
Текст с кастомным стилем
:::
```

**Grid tables** — для таблиц с объединением ячеек (частичная поддержка):
```markdown
+---------------+---------------+
| Объединённая ячейка           |
+---------------+---------------+
| Ячейка 1      | Ячейка 2      |
+---------------+---------------+
```

**Несколько входных файлов** — для больших отчётов:
```bash
pandoc intro.md methods.md results.md -o body.docx --reference-doc=reference.docx
```

## Сборка

```bash
python ~/.claude/skills/gost-lab-report/scripts/build.py report.md
```

Результат: `report.docx` в той же директории.

## Подключение титульника нового вуза

Если в `templates/title_pages/` нет титульника нужного вуза/типа работы — попроси у пользователя .docx-бланк (лучше — заполненный пример) и пройди сценарий из **WIZARD.md**. Это разовая настройка с обязательной финальной приёмкой пользователем; после неё шаблон доступен через YAML-поле `title_page`.

## Границы скилла

- **Титульники — только из .docx.** PDF не конвертируем и не воссоздаём по картинке.
- **Подписные бланки не генерируются**: задание, календарный план, дневник практики, отзывы, рецензии — пользователь вкладывает сам.
- **ЕСКД-рамки и печати** — вне скоупа.
- **Кастомизация базовых стилей** (шрифт, поля, интервалы, отличные от ГОСТ 7.32) — только ручная правка `templates/reference.docx`; нейросеть стили не меняет.

## Troubleshooting

Первый шаг при любой жалобе на оформление («слетела красная строка», «не тот шрифт») — детерминированная диагностика:

```bash
python ~/.claude/skills/gost-lab-report/scripts/verify.py report.docx
```

FAIL-строки укажут, что именно разъехалось. Известные грабли окружений (проверено матрицей Ubuntu 24.04 / Debian 12 / Fedora 41):

- **`pip install` отказывается ставить пакеты (PEP 668, «externally-managed-environment»)** — на свежих Ubuntu/Debian ставить `python-docx`/`docxcompose` через `pip install --break-system-packages` или в venv.
- **Старый LibreOffice (7.x, например Debian 12) переименовывает стили** при пересчёте СОДЕРЖАНИЯ (`BodyText`→`TextBody`, `TOC1`→`Contents1`) — сборка сама восстанавливает канонические id (`update_fields.py`); если verify всё же валится по `gost-styles-present` — проверь, что сборка шла текущей версией скилла.
- **Нет LibreOffice** — сборка работает, но СОДЕРЖАНИЕ остаётся полем, а `{{PAGES}}` — плейсхолдером: открыть .docx в Word → Ctrl+A → F9. Для UNO нужен пакет python-uno (Fedora: `libreoffice-pyuno`).
- **Нет Times New Roman** (голый Linux) — docx хранит имена шрифтов, файл корректен; для точного локального рендера поставить MS core fonts (Ubuntu/Debian: `ttf-mscorefonts-installer`, на Debian пакет в `contrib`) или согласиться на подстановку Liberation Serif.
- **pandoc**: диапазон 2.17–3.10 даёт идентичный результат (расхождения косметические; на ≥3.7 безвредный deprecation warning про `--highlight-style`); при странностях таблиц/листингов первым делом обнови pandoc до 3.x.
- **Windows (нативный)**: команда `python` или `py` (не `python3` — откроет Microsoft Store). Сборка docx работает полностью; **авто-пересчёт СОДЕРЖАНИЯ недоступен** (UNO-мост LibreOffice доступен только его встроенному питону) — сборка предупредит, обновить в Word: Ctrl+A → F9. LibreOffice ищется и вне PATH (стандартные пути установки).
- **macOS**: аналогично Windows — сборка работает, авто-TOC через brew-установку LibreOffice (`brew install --cask libreoffice`) может завестись, иначе F9. Для полного авто-TOC на Windows — использовать WSL (там линуксовый путь целиком).

## Известные ограничения (ручная доводка)

- Сложные таблицы (объединение ячеек) не поддерживаются в pipe tables — используй grid tables или правь в docx; к таблицам с объединёнными ячейками авторазметка ширин колонок не применяется (ширины — вручную)