Stats
Actions
Tags
From claude-code-config
Reviews technical article structure for thesis-proof balance, genre purity, and limitations section. Use after first draft, before style and humanization audits.
How this skill is triggered — by the user, by Claude, or both
Slash command
/claude-code-config:article-structure-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Между завершением черновика и финальным текстовым аудитом. Порядок:
Между завершением черновика и финальным текстовым аудитом. Порядок:
jtbd-content - ПЕРЕД написанием (job statement, target state)draft-narrative-purity - во время (код/деревья в technical-examples)article-structure-review - ПОСЛЕ первого черновика ← этот skillinfostyle-audit - после структуры (усилители, zero-info)humanize-russian / humanize-english - финал (LLM-маркеры){platform}-guide - подгонка под платформуПравило: каждый значимый тезис должен сопровождаться одним из:
Антипаттерн: 3+ тезиса подряд без ни одного proof-элемента.
Взять каждую H2-секцию. Пройтись по абзацам. Для каждого:
Если отношение тезис/proof выше 2:1 в секции - пересобрать.
| Плохо (тезис без доказательства) | Хорошо (тезис + доказательство) |
|---|---|
| "Правила помогают избежать катастроф" | "Правило 'не менять localhost-адреса без контекста' появилось после того, как агент заменил SNI-proxy на реальный IP и сломал upload" |
| "Векторный поиск хуже графа" | "Эмбеддинги для карточек по 500-2000 токенов - lossy-сжатие: похожие на вектор карточки могут быть про разные домены, а operationally-adjacent карточки (Kafka + Python profiling) семантически далеки" |
| "Структура помогает" | "После ввода handoff между сессиями за 4 дня накопилось 27 переходов - ни один тупик не повторился" |
Статья обслуживает один основной жанр. Выбирается ДО написания:
| Жанр | Характер | Пример заголовка |
|---|---|---|
| Story | Хронология, от лица автора, с неудачами | "Как я сломала прод и что нашла" |
| Reference | Факты, таблицы, паттерны | "Checklist: развёртывание K8s cluster" |
| Analysis | Данные → вывод, сравнения | "3 метода context compaction: бенчмарк" |
| Rant/Opinion | Точка зрения, аргументы | "Почему RAG - это regression" |
| Tutorial | Пошаговая инструкция | "Fine-tune модели за 4 часа" |
Смешение жанров допустимо, если явно обозначить:
"Часть 1 - история как я столкнулась с проблемой. Часть 2 - разбор архитектуры."
Не обозначить = читатель теряется: "зачем это здесь? где закончилась одна тема и началась другая?"
Прочитать ТОЛЬКО первые абзацы каждой H2-секции. Читаются как одна последовательная мысль или как разрозненные блоки? Если блоки - определить где жанр сменился, обозначить явно или переписать в один жанр.
Секция "Что НЕ решено / Чего не знаю / Где сломается" - обязательна в конце любой технической статьи про собственный инструмент / подход / систему.
Правило: длины абзацев должны скакать. 1-sentence абзац ок, 5-sentence ок, но не три 3-sentence подряд.
Три абзаца одинаковой длины ~3 предложения каждый, каждый начинается с глагола или "Moreover/Также/Кроме того", каждый содержит ровно один тезис + пол-доказательства. Характерный ритм "тыры-пыры" - LLM-generated.
Взять статью, посчитать длины абзацев в основной части. Стандартное отклонение должно быть > среднего. Если "все абзацы по 3-4 предложения" - ручная пересборка: часть объединить, часть разбить, одно предложение вынести в отдельный абзац для акцента.
Симптом: в середине статьи один блок перегружен тезисами/концепциями - сложнее читать, чем начало и конец.
Причина: автор вырос в понимании темы за время написания, в середину положил самые интересные/глубокие мысли, а уровень контекста читателя не вырос.
Посчитать количество тезисов по секциям. Если середина содержит > 40% всех тезисов при 33% веса - разгружать:
technical-examples.md или в отдельную статьюПравило: если объясняешь структуру данных, архитектуру, связи - покажи визуал, не проза.
Прозой лучше: идеи, последовательности действий, личные истории, аргументация.
Визуалом лучше:
Каждую секцию которая описывает структуру - спросить "можно ли это одной картинкой показать яснее, чем абзацами?". Если да - заменить.
Сформирован по фидбеку реальных читателей на опубликованные технические статьи. Характерные замечания, которые регулярно ловят LLM-ассистированные черновики:
Этот skill формализует ответ на такие замечания, чтобы следующая статья не повторяла те же ошибки.
npx claudepluginhub anastasiyaw/claude-code-configPerforms pass-1 structural review of a Substack essay draft — argument flow, out-of-order moves, buried topic sentences, missing pivots, weak signposting, paragraph-logic issues. Use when reviewing a draft's macro-structure before addressing voice, when a draft meanders, or when the user asks whether the argument lands.
Structurally edits article drafts through an interactive section-by-section rewrite for clarity, flow, and argument strength.
Analyzes draft article structure—paragraph order, logical flow, redundancies, pacing—and returns a diagnostic report with reordering, cutting, or restructuring recommendations.