---
name: n-publish-telegram
description: >-
  Підготовка матеріалу з поточного контексту для публікації в Telegram-каналі команди
version: '1.0'
---

# Публікація в Telegram

Підготовка матеріалу для публікації в Telegram-каналі команди (розробники + менеджери).

## Формат Telegram

Telegram підтримує Markdown-форматування безпосередньо в клієнті:

- `**bold**` — жирний (заголовки, мітки секцій)
- `_italic_` — курсив (акценти)
- `` `inline code` `` — inline-код, команди, назви файлів/пакетів
- ` ```block``` ` (потрійні backticks) — блок коду, коли є реальний код
- `~~strikethrough~~` — закреслення (опціонально)

Секції (Проблема:, Рішення: тощо) виділяй `**жирним**`. Технічні терміни (назви файлів, пакетів, команди) — в `` `inline code` ``.

## Workflow

1. **Визнач контекст** — проаналізуй поточну розмову: яка проблема вирішувалась, що було зроблено, який результат.

2. **Сформуй пост** за шаблоном нижче.

3. **Виведи готовий текст** — користувач копіює його в Telegram.

## Шаблон посту

```
#тег

📌 **<Короткий заголовок>**

**Проблема:**
<1-3 речення — що було не так / яке завдання>

**Рішення:**
<2-5 речень — що зробили, який підхід>

**Деталі:**
• <ключовий момент 1>
• <ключовий момент 2>
• <ключовий момент 3>

**Результат:**
<1-2 речення — що отримали, яка вигода>
```

Тег (один хештег першим рядком поста) — підбір за темою:

- якщо публікація стосовно AI, то `#ai`
- якщо публікація стосовно npm модуля, то `#npm`
- якщо публікація стосовно розробки, то `#dev`
- якщо публікація стосовно інфраструктури, скриптів, налаштувань, ефективності коду чи безпеки, то `#sre`

## Правила

- Мова: українська, технічні терміни — англійською
- Обсяг: 500–1500 символів (оптимально для Telegram)
- Без зайвих вступів і водянистих фраз
- Конкретика: назви файлів, бібліотек, команд — якщо доречно
- Тег: рівно 1 хештег першим рядком поста (#devops, #frontend, #bugfix, #refactoring, #CI, #performance тощо)
- Emoji: лише структурні (📌 для заголовка, • для списку), не перевантажувати
- Цільова аудиторія: розробники та менеджери — тому пояснюй простою мовою, без надмірного жаргону
- Назви файлів, пакетів, команди — у `` `inline code` ``
- Блок коду (потрійні backticks) — лише якщо є реальний код/конфіг, не для всього тексту

## Приклад

```
#dev

📌 **Міграція з Prettier на oxfmt**

**Проблема:**
Prettier повільно форматував великі файли і конфліктував з ESLint при роботі з Vue SFC.

**Рішення:**
Замінили Prettier на `oxfmt` — нативний форматер від OXC. Оновили VS Code settings, видалили prettier-конфіги, додали `.oxfmtrc.json`.

**Деталі:**
• `oxfmt` працює в 10-50x швидше за Prettier
• Єдиний конфіг `.oxfmtrc.json` у корені
• CI перевіряє форматування через `lint-js`

**Результат:**
Форматування працює миттєво при збереженні, зникли конфлікти між форматером і лінтером.
```