git:20260808.e616f6d to git:20260809.f4a62e7

+ ---

+ name: content-article-draft

+ description: >

+ Превращает идею, серию заметок или сырой материал в драфт статьи (Habr / Medium /

+ личный блог) — с TL;DR, структурой тезис→аргументы→пример→следствие, авторским

+ голосом. Используй, когда «написать статью», «оформить мысли в лонгрид»,

+ «сделать пост для Habr», «черновик статьи», «article draft».

+ ---

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

+

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

+

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

+

+ - `~/.claude/rules/content-voice.md`

+ - `~/.claude/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 коротких

+ - не финализируй статью без проверки тезиса от автора — это его текст, не твой