# Content Article Draft

> Превращает идею, серию заметок или сырой материал в драфт статьи (Habr / Medium / личный блог) — с TL;DR, структурой тезис→аргументы→пример→следствие, авторским голосом. Используй, когда «написать статью», «оформить мысли в лонгрид», «сделать пост для Habr», «черновик статьи», «article draft».

- Skill: `jtprogru/content-article-draft` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jtprogru/content-article-draft`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jtprogru/content-article-draft/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jtprogru (https://skillmd.com/u/jtprogru)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jtprogru/content-article-draft

---


<!-- СГЕНЕРИРОВАНО bin/mirror.js. Не редактировать: правки затрёт следующая генерация.
     Источник правды — domains/<домен>/. -->

# content-article-draft — Драфт статьи

Цель: превратить материал в **первый рабочий драфт** статьи 3-10 тыс. символов. Не финальную версию — её пользователь шлифует сам. Драфт должен иметь правильный скелет и тон.

Перед началом прочитай:

- `../../rules/content-voice.md`
- `../../rules/content-formatting.md` — раздел про статьи

## Шаг 1. Контекст

Спроси:

- **тема** в одно предложение
- **аудитория**: технические специалисты определённого уровня? Менеджеры? Начинающие?
- **платформа**: Habr / Medium / dev.to / личный блог / Telegraph?
- **исходник**: заметки, опыт, проект, существующий драфт?
- **цель статьи**: научить чему-то / поделиться опытом / разобрать кейс / провокация-эссе?

## Шаг 2. Сформулируй тезис

Тезис статьи — **одно утверждение**, которое автор защищает или иллюстрирует. Не тема, а утверждение.

| Тема (плохо) | Тезис (хорошо) |
|--------------|----------------|
| «Микросервисы» | «Микросервисы стоят сложности только когда у тебя реально разные циклы релизов или языки» |
| «Postgres vs Mongo» | «Для большинства стартапов Postgres покрывает 95% задач, а оставшиеся 5% не оправдывают второй БД» |
| «Опыт работы с k8s» | «Через год с k8s в проде я понял, что главный риск — не сложность, а размытие ответственности SRE vs dev» |

Покажи тезис пользователю и **попроси подтвердить или поправить**. Тезис — фундамент.

## Шаг 3. Сложи скелет

Стандартная структура:

```markdown
# <Заголовок>

> **TL;DR:** <тезис в 1-2 фразах + краткий итог>

## <Подзаголовок 1: контекст / проблема>

<Почему это интересно. Конкретный пример из жизни.>

## <Подзаголовок 2: аргумент / разбор / решение>

<Главная мысль. Код, схемы, числа.>

## <Подзаголовок 3: нюансы / контраргументы>

<Где тезис не работает. Где есть оговорки.>

## <Подзаголовок 4: применение / итог>

<Что читатель может сделать со всем этим.>

---

<подпись / автор / ссылки на ресурсы>
```

Покажи скелет (заголовок + подзаголовки + 1-фразовое описание каждой секции) и спроси, подходит ли. Не переходи к написанию текста, пока скелет не согласован.

## Шаг 4. Напиши драфт по секциям

После подтверждения скелета — пиши секцию за секцией.

Применяя `content-voice.md`:

- обращение «ты» / безличное
- авторский голос, не Wikipedia
- конкретика, цифры, код
- никаких ИИ-штампов

Применяя `content-formatting.md`:

- code blocks с языком
- картинки/схемы — alt-text
- backticks для технических терминов
- abzац — 1-4 предложения

## Шаг 5. TL;DR в начале

Для статей длиннее 5000 символов — обязательно TL;DR блоком в начале. 2-3 строки: тезис + главный вывод + кому будет полезно.

## Шаг 6. Самопроверка

- **тезис прослеживается** через всю статью, не размывается
- **есть конкретные примеры** (не только теория)
- **есть код / схемы / числа** где возможно
- **контраргумент** упомянут — иначе текст выглядит как пропаганда
- **читатель может что-то применить** после прочтения
- если убрать вступление — статья не разваливается?
- финал имеет смысл? (или это просто «таким образом»)

## Шаг 7. Покажи и спроси

Покажи драфт. Под ним:

- длина: X символов
- проверки: ✓ тезис / ✓ конкретика / ✓ контраргумент / ✓ код

Спроси:

1. Принять как первый драфт
2. Поправить конкретный раздел
3. Усилить тезис / сменить ракурс
4. Сократить (если ушёл в 12+ тыс)
5. Раскрыть какой-то аргумент глубже

## Шаг 8. Сохрани

Спроси куда сохранить. Если есть конвенция Obsidian-vault или blog repo — спроси путь. Иначе предложи `drafts/YYYY-MM-DD-<short-slug>.md` рядом с текущим рабочим контекстом.

## Чего не делать

- не делай статью без явного тезиса — это эссе, а не статья
- не цитируй случайных гуру для авторитета
- не пиши «в этой статье мы рассмотрим» — режь и переходи к делу
- не клей серию слабо связанных мыслей в одну статью — лучше серия из 3 коротких
- не финализируй статью без проверки тезиса от автора — это его текст, не твой