lab-draft

Пользователь хочет создать черновик отчёта по лабораторной работе. Черновик — это полный текст report.md без изображений (с плейсхолдерами), для ревью перед финальной генерацией документа.

Что делать

Шаг 1. Проверка config.json

Прочитай .lab/config.json. Если файл не найден — сообщи пользователю: «Сначала запусти $lab-setup для настройки проекта.» и остановись.

Шаг 2. Чтение источников

Прочитай все необходимые файлы:

1. .lab/config.json — конфигурация (стиль, предмет, тип работы).
2. .lab/gost-content.md — правила написания текста по ГОСТ.
3. .lab/assignment.md — разобранное задание.
4. .lab/source-material.md — полный текст исходного документа. Может содержать теоретические сведения, методические указания и примеры помимо самого задания — используй их как справочный материал при написании отчёта.
5. Файлы в .lab/reference-docs/ (дополнительная теория по работе)
6. instructions.md — если существует и содержит заполненные результаты ([ВСТАВИТЬ РЕЗУЛЬТАТ СЮДА] заменены на реальные данные).

Шаг 3. Проверка правильности выполнения инструкции

Если в инструкции были плейсхолдеры вида [ВСТАВИТЬ РЕЗУЛЬТАТ СЮДА] или если их не было, но пользователь сам вставил результаты некоторых своих команд - проверь, правильно ли он выполнил инструкцию. Совпал ли ожидаемый результат с реальным. Выполнено ли задание полностью и полноценно, нет ли противоречий. Если есть проблемы - не начинай писать отчет, а доработай инструкцию (добавь дополнительные шаги, которые исправят сложившуюся у пользователя проблему и доведут выполнение задания до конца). Такие доработки помечай символом ⚠️ и дополнительно сообщи о них пользователю в чате. Пользователь выполнит все инструкции и заново запустит команду. Если все в порядке - приступай к следующему шагу.

Шаг 4. Анализ готовых изображений

Перед написанием отчёта проверь наличие папки images/ в корне проекта. Если она существует и содержит файлы:

1. Прочитай каждый файл изображения доступным инструментом просмотра изображений (в Codex CLI – view_image).
2. Проанализируй содержимое — текст на скриншотах, данные, интерфейсы, результаты команд.
3. Сопоставь изображения с шагами инструкции по СМЫСЛУ (не по имени файла и не по дате создания!). Смотри, что изображено на каждом скриншоте, и определи, какому шагу инструкции оно соответствует.
4. Используй данные с изображений при написании отчёта. На скриншотах могут быть конкретные значения, IP-адреса, результаты команд, сообщения об ошибках и т.д. — все эти детали нужно отразить в тексте отчёта. Не придумывай данные, если они видны на скриншотах.

Это критически важно: отчёт должен описывать то, что реально произошло (видно на скриншотах), а не абстрактные действия.

Шаг 5. Исследование (при необходимости)

Если для написания отчёта не хватает знаний (специфические технологии, протоколы, алгоритмы и т.д.) — выполни поиск в интернете доступным инструментом веб-поиска. Не выдумывай.

Шаг 6. Создание report.md

Создай файл report.md в корне проекта. Содержание:

Структура:

1. Цель работы — сформулировать на основе задания.
2. Ход работы — все пункты задания выполнены и описаны подробно:
   • Последовательность действий описана детально.
   • Результаты объяснены, на возникающие вопросы даны ответы.
   • Умозаключения по ходу текста (не только в конце).
   • Если в задании есть контрольные вопросы — ответы на них в соответствующих местах.
3. Плейсхолдеры [ВСТАВИТЬ РИСУНОК N ЗДЕСЬ] в местах, где нужны скриншоты/рисунки.
4. Подписи Рисунок N. Описание под каждым плейсхолдером.
5. Ссылки на рисунки и таблицы в тексте: (Рисунок N) или на Рисунке N.

НЕ включать:

• Раздел дополнительного исследования (добавляется через $lab-research).
• Итоговый вывод (добавляется через $lab-conclusion).

Стиль:

• Стиль из config.preferences.report_style:
  • first_person → «Я выполнил», «Я настроил», «Мне удалось установить»
  • impersonal → «Было выполнено», «Была проведена настройка», «Удалось установить»
  • result_only → только результат выполнения, без описания процесса. Минимальный объём, максимальная лаконичность.
• Уровень детализации из config.example.detail_level:
  • "detailed" — подробное описание каждого действия, развёрнутые пояснения к каждому шагу, абзац на каждый пункт задания, максимально подробное описание, что делали, зачем, почему это так работает и так далее.
  • "moderate" — ключевые действия описаны, краткие пояснения, без избыточной детализации.
  • "brief" — лаконичный стиль: что сделано + результат, минимум объяснений.
• Если в config.example.style_notes есть заметки о стиле примера — учитывай их (характерные обороты, структура, формат подписей и т.д.).
• Все правила из gost-content.md: ё, кавычки «», тире –, №, запятая в дробях, аббревиатуры расшифрованы.
• Избегать «Вывод: ...» → «Таким образом, ...», «Получили, что ...».

Замечание по рисункам: пользователь в инструкции мог посчитать, что ему недостаточно количество рисунков ( скриншотов), которые предложил ты, и он добавил дополнительно свои рисунки, обозначив их на подобии ДОБАВЬ СЮДА РИСУНОК или РИСУНОК или Добавил сюда рисунок. В этом случае тебе нужно понять по контексту, что будет изображено на этом рисунке (скорее всего это еще один скриншот), подписать этот рисунок в отчете и изменить нумерацию последующих рисунков с учетом добавления нового.

Шаг 7. Сообщение о следующих шагах

После создания report.md сообщи пользователю:

• Черновик создан. Просмотри его и при необходимости:
  • $lab-improve — доработать отчёт по замечаниям.
  • $lab-research — добавить раздел дополнительного исследования (если config.preferences.needs_research = true).
  • $lab-conclusion — написать итоговый вывод.
  • $lab-report — сгенерировать финальный документ (DOCX/PDF/MD).
• Не забудь положить скриншоты в папку images/.

Дополнительный контекст от пользователя

Используй сообщение пользователя, в котором вызван навык, и уже известный контекст разговора. Не ожидай отдельной подстановки аргументов.