| name | jtprogru-blog-style |
| description | Пиши и оформляй посты для блога jtprog.ru в авторской стилистике — разговорный «ты», сухой юмор, обращение «Привет, %username%!», стандартный Hugo-frontmatter, фирменные секции вроде «Что с этим делать на практике» и «Тонкие места», обязательный footer со ссылками на чат/канал/донаты. Используй этот скилл всегда, когда пользователь работает с репозиторием jtprog.ru или просит «написать пост», «оформить пост», «пост в блог», «черновик статьи», «новую запись для блога», «hugo post», даже если он не упоминает стилистику явно — это его личный блог и единый голос важен. |
Стилистика блога jtprog.ru
Этот скилл нужен, когда автор пишет или редактирует пост для своего блога на Hugo (репозиторий jtprog.ru). Цель — попасть в его собственный голос: разговорный, прямой, с тёплой иронией, технически плотный, без воды и без корпоративщины. Ниже — рабочая шпаргалка, не догма. Если в конкретном посте уместно отступить от шаблона (например, это короткая заметка-«быстрый рецепт», а не разбор) — отступай осознанно.
Голос и тон
- На «ты», по-мужски, как со знакомым из чата. Никаких «вы», «уважаемые читатели», «дорогие друзья». Автор обращается к одному конкретному читателю-инженеру.
- Разговорный русский с естественными англицизмами. «Бутстрап», «бэкап», «алерт», «костыль», «фигачить» — нормально. Технические термины (LBA, SLO, MBR, Burn Rate) остаются на английском, без насильственного перевода.
- Сухой юмор и лёгкий цинизм. Допустимы шутки в духе «затёр сектор и привет», «жуткий хак», «и это самая частая причина "всё работало, потом подвинул раздел и сломалось"», «лечится через X, но узнать про эту весёлую особенность обычно успеваешь уже после нескольких часов поиска». Юмор всегда про предметную область, никогда про читателя.
- Боевой опыт как аргумент. Часто всплывают мини-истории «в 3 часа ночи на боевой железке», «когда впервые столкнулся», «ловил вот такой сюрприз». Это придаёт достоверности — не сочиняй их, но если автор упоминает похожий опыт в исходных данных, оставляй и усиливай.
- Никаких эмодзи в теле поста. Совсем. Ни 🚀, ни ✅, ни 💡.
- Никакого корпоративного жаргона. «Синергия», «лучшие практики», «эффективное взаимодействие» — выкинуть. Пиши как живой человек.
- Не перебарщивай с MUST/ВАЖНО/ЗАПОМНИ. Лучше объяснить, почему что-то важно, и доверить читателю сделать вывод.
Структура поста
Перед тем как раскладывать пост по секциям, сверься с правилом проекта о структуре повествования: ../../rules/narrative-structure.md. Оно про то, чтобы пост читался как история с дугой (завязка → нарастание → кульминация → спад → развязка), а не как перечень фактов. Секции ниже — это форма; правило про повествования — про то, как наполнить эту форму так, чтобы читателя вело.
Открытие (всегда)
Первая строка тела — Привет, \%username%`!`, дальше через пробел или с новой строки идёт зацепка: краткое введение в тему, личный контекст, или провокационный тезис. Примеры:
Привет, %username%! Сегодня MBR воспринимается как что-то из музея...
Привет, %username%! В индустрии прижился термин «скорость сгорания бюджета ошибок»...
Привет, %username%! Есть такая примитивная утилита автоматизации жизни любого DevOps и SRE как make...
После открытия часто идёт второй абзац, который обещает, что именно мы разберём в посте. Не обязательно, но помогает читателю.
Основная часть
- Заголовки H2 (
##) — крупные смысловые блоки. Названия в свободной форме, разговорные: «Что такое X», «Почему Y — плохое слово?», «Что с этим делать на практике», «Чем плох Z».
- H3 (
###) — подсекции внутри H2, обычно с пронумерованными или конкретно названными темами.
- Списки — много маркированных списков. Используй их для перечисления свойств, лимитов, шагов, граблей.
- Таблицы — для структурированных данных (поля структуры, коды, сравнения «X vs Y»). Markdown-таблицы, без HTML.
- Code-блоки с указанием языка (
```bash, ```yaml, ```make, ```go). Для inline-кода и идентификаторов — обратные кавычки: \fdisk -l`, `/dev/sda5`, `0x55AA``.
- Внутренние ссылки в формате Hugo:
[GPT](/what-is-gpt/). Когда упоминаешь смежную тему, по которой у автора уже есть пост — линкуй.
- Математика (если есть) — LaTeX-блоки
$...$ и $$...$$. В этом случае в frontmatter обязательно params: math: true, иначе формулы не отрендерятся.
Фирменные секции (используй там, где уместно)
- «Что с этим делать на практике» — короткий чек-лист команд/действий, которые читатель может скопировать прямо сейчас.
- «Тонкие места, на которых легко споткнуться» — список граблей с пояснением, почему это грабли. Это сильный жанровый маркер автора, не пропускай его в технических постах.
- «Чем плох X» или «Почему Y — плохое слово» — критический разбор существующей практики/термина, обычно ведущий к следующему посту/решению.
- Сравнительная таблица — когда есть «было/стало» или «X vs Y».
Закрытие (всегда)
В самом конце поста — горизонтальный разделитель --- и стандартный футер:
---
Если у тебя есть вопросы, комментарии и/или замечания – заходи в [чат](https://ttttt.me/jtprogru_chat), а так же подписывайся на [канал](https://ttttt.me/jtprogru_channel).
О способах отблагодарить автора можно почитать на странице "[Донаты](https://jtprog.ru/donations/)".
Этот блок неизменяемый. Не сокращай, не перефразируй, не добавляй туда ничего. Тире – в первом предложении — именно en-dash с пробелами, а не дефис.
Hugo frontmatter
Полная схема (см. archetypes/posts.md в репозитории — она канон). Заполняй все поля, не оставляй TODO.
---
title: 'Заголовок поста человеческими словами, не slug'
description: "150–160 символов: что внутри поста, ключевые понятия, без воды. Идёт в meta description и превью."
keywords:
- Ключевое слово 1
- Ключевое слово 2
- 5–10 штук, смесь русского и английского
date: 2026-05-06T20:00:00+03:00
lastmod: 2026-05-06T20:00:00+03:00
tags:
- тег1
- тег2
- 3–6 штук, lower/title case как у соседних постов в той же категории
categories: ["SRE"]
cover:
image: devops.png
alt: SRE
caption: 'Illustrated by [Igan Pol](https://www.behance.net/iganpol)'
relative: false
type: post
slug: 'kebab-case-slug'
aliases:
- 'kebab-case-slug'
params:
math: false
---
Правила полей
title — в одинарных кавычках, человеческий заголовок. Не Title Case, обычная русская капитализация.description — в двойных кавычках, 150–160 символов, сжатый пересказ сути поста. Это SEO-критичное поле.keywords — 5–10 элементов, смешанный русско-английский набор. Включай и термины, и их расшифровки.date / lastmod — ISO 8601 с таймзоной +03:00 (Москва). Для нового поста оба равны. При правках старого — lastmod обновляется, date нет.tags — 3–6 штук. Подгляди существующие теги в соседних постах той же категории, чтобы не плодить дубли (linux vs Linux, SRE vs sre).categories — одна категория из устоявшегося набора: Work, OS, SRE, Opinions, DevOps и т.п. Смотри, какие уже есть в content/, не выдумывай новых.cover.image — соответствует категории: work.png для Work, OS.png для OS, devops.png для SRE/DevOps, opinions.png для Opinions. Проверь в соседних постах.cover.alt — краткое слово-метка категории (work, OS, SRE, opinions).cover.caption — строго неизменно: 'Illustrated by [Igan Pol](https://www.behance.net/iganpol)'. Это атрибуция автора иллюстраций, её ни в коем случае не убирать и не править.slug — kebab-case, латиница, без префиксов с датой (старые посты могут содержать 2026-01-05-... в aliases, но новые слаги — без даты).aliases — минимум сам slug; если переименовывал пост или мигрировал — добавляй старые URL.params.math — true только если в посте есть LaTeX. По умолчанию false.
Файловая структура поста
Каждый пост — это директория в content/<slug>/ с файлом index.md внутри. Если в посте есть локальные картинки/диаграммы, они кладутся туда же и линкуются относительно. Не создавай <slug>.md в корне content/ — это сломает шаблон.
Чего избегать
- Эмодзи — нигде, никаких.
- Markdown-«блёсток» вроде
> 💡 Совет: или > ⚠️ Внимание:. Если нужна ремарка — пиши обычным абзацем или цитатой > без эмодзи-префикса.
- Маркетинговые штампы: «революционный», «уникальный», «синергия», «лучшие практики», «в современном мире».
- Машинных оборотов: «Стоит отметить, что...», «Важно понимать, что...», «Нельзя не сказать о...» — это паразиты. Удаляй.
- Заглавных MUST/NEVER в стиле RFC. Если что-то критично — объясни почему, и читатель сам поймёт.
- Длинных вступлений «об истории вопроса». Контекст должен быть на 1–2 абзаца, дальше — мясо.
- Безличных пассивных конструкций: «Должно быть настроено», «Является рекомендуемым». Пиши активно: «Настраивается так-то», «Я бы делал вот так».
- Упоминаний ИИ-ассистентов (Claude, ChatGPT, Copilot и т. п.) в постах, коммитах и PR. Это блог живого человека, и в репозитории есть отдельная заметка об этом. Никаких подписей вроде «Generated with...» или «Co-Authored-By: Claude».
Контрольный список перед сдачей поста
Прогоняй мысленно перед тем, как считать пост готовым:
Дополнительные материалы
references/examples.md — выдержки из реальных постов автора с разбором, какие приёмы где работают. Загляни туда, если нужно вспомнить, как звучат типичные переходы между секциями или как автор формулирует выводы.
