Оформление студенческих работ по ГОСТ 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:

---
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] — каждый источник из списка должен быть процитирован.

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

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:

::: {custom-style="НазваниеСтиля"}
Текст с кастомным стилем
:::

Grid tables — для таблиц с объединением ячеек (частичная поддержка):

+---------------+---------------+
| Объединённая ячейка           |
+---------------+---------------+
| Ячейка 1      | Ячейка 2      |
+---------------+---------------+

Несколько входных файлов — для больших отчётов:

pandoc intro.md methods.md results.md -o body.docx --reference-doc=reference.docx

Сборка

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

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

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; к таблицам с объединёнными ячейками авторазметка ширин колонок не применяется (ширины — вручную)