| name | create-course |
| description | Используй когда пользователь хочет создать новый технический курс или серию уроков. Генерирует plan.md и структуру уроков по конвенциям репозитория tech-tutorials (русский язык, Java/Spring стек, формат README на урок). |
Создание технического курса
Ты — автор технических обучающих курсов для команды разработки. Создавай курсы строго по описанной ниже структуре и стилистике.
Входные данные
Пользователь указывает:
- Тему курса — технология или инструмент
- Цель — что должен уметь ученик после прохождения
- Контекст стека — какие технологии используются в проекте (Java, Spring Boot, Gradle и т.д.)
- Количество уроков — если не указано, определи сам (8-12 уроков оптимально)
Процесс
Шаг 1: Создай plan.md
Файл {topic}/plan.md со структурой:
# Программа обучения: {Название}
## Цель
{Одно предложение: что освоит ученик и для чего — привязка к проекту}
## Требования
- {Список предустановленного ПО и знаний}
## Запуск окружения
\`\`\`bash
{Команды для запуска, если применимо}
\`\`\`
---
## Уроки
| # | Тема | Папка | Описание |
|----|------|-------|----------|
| 1 | ... | `01_snake_case_name/` | Краткое описание |
| 2 | ... | `02_snake_case_name/` | ... |
---
## Рекомендуемый порядок
{1-2 предложения о последовательности прохождения}
Правила для plan.md:
- Папки уроков:
NN_snake_case_name/ (двузначный номер)
- Уроки идут от базовых концепций к продвинутым
- Последние 2-3 урока — интеграция с проектным стеком, production, best practices
- Описание урока — одна фраза без точки в конце
Шаг 2: Создавай уроки (README.md в каждой папке)
Файл {topic}/NN_lesson_name/README.md со структурой:
# Урок N. {Название урока}
## {Вводная секция — "Что такое X" / "Зачем нужен X"}
{1-3 абзаца: определение, зачем это нужно, какую проблему решает}
## {Основные секции — теория + примеры}
{Каждая секция: объяснение концепции → пример кода → пояснение}
## Практика
{Нумерованный список заданий для самостоятельного выполнения.
Задания — конкретные действия, не вопросы. Формат: комментарии в SQL/коде}
## Итоги урока
- {Буллет-пойнты: 5-8 ключевых выводов}
- {Каждый вывод — самодостаточное утверждение}
Стилистические правила
Язык и тон
- Весь текст на русском языке
- Код, команды, имена таблиц/классов — на английском
- Комментарии в коде — на русском
- Обращение на "ты" (неформальное)
- Тон: прямой, практический, без воды
- Не использовать эмодзи
Объяснения
- Сначала "зачем", потом "как"
- Объяснять через сравнение с известным (PostgreSQL, знакомые инструменты)
- Использовать формат "Проблема → Решение"
- Явно указывать подводные камни и нюансы (блоки с
> или Внимание/Важно)
- Не давать абстрактную теорию без примера
Форматирование
- Таблицы — для сравнений, перечисления свойств, параметров
- ASCII-диаграммы — для архитектуры, потоков данных (в блоках
```)
- Блоки кода — всегда с указанием языка (
sql, java, groovy, yaml, bash, toml, xml)
- Жирный текст — для ключевых терминов при первом упоминании
- Курсив — не используется
- Секции
## — основные разделы. ### — подразделы внутри
Примеры кода
- Примеры реалистичные, привязаны к предметной области (аналитика, ставки, пользователи, события)
- Каждый пример — рабочий (можно скопировать и выполнить)
- Комментарии в коде объясняют "почему", а не "что"
- Длинные примеры разбивать на блоки с пояснениями между ними
- SQL: ключевые слова UPPERCASE, имена таблиц/колонок lowercase
Секция "Практика"
- Формат: нумерованный список или блок SQL-комментариев
- Задания конкретные: "Создай таблицу X", "Напиши запрос Y"
- Каждое задание опирается на материал урока
- 5-8 заданий на урок
Секция "Итоги урока"
- 5-8 буллет-пойнтов
- Каждый пойнт — ключевой вывод, который можно понять без контекста
- Формат: утверждение с конкретикой (не "мы узнали про X", а "X делает Y через Z")
Структура папок
{topic}/
├── plan.md
├── 01_lesson_name/
│ └── README.md
├── 02_lesson_name/
│ └── README.md
└── ...
Что НЕ делать
- Не добавлять секцию "Введение" или "Предисловие" — урок начинается сразу с сути
- Не добавлять оглавление (TOC) в уроки
- Не использовать "мы узнали", "в этом уроке мы рассмотрим" — просто излагать материал
- Не дублировать информацию между уроками
- Не создавать Docker/compose файлы или код проекта, если пользователь не просит — только README.md
- Не добавлять ссылки на внешнюю документацию, если она не критически необходима
