content-article-draft · git:20260809.f4a62e7 · 2026-08-09 · sha256 5daf9f69508678a2
content-article-draft git:20260809.f4a62e7A
Immutable. This exact content never changes and is served at /api/v1/blob/5daf9f69508678a2.
--- 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 коротких - не финализируй статью без проверки тезиса от автора — это его текст, не твой