From claude-code-config
Reviews technical article structure for thesis-proof balance, genre purity, and limitations section. Use after first draft, before word-level audits.
npx claudepluginhub anastasiyaw/claude-code-configThis skill uses the workspace's default tool permissions.
Между завершением черновика и финальным текстовым аудитом. Порядок:
Reviews Substack essay drafts for argument flow, out-of-order moves, buried topic sentences, missing pivots, weak signposting, and paragraph-logic issues. Emits Argument flow and Structural blockers sections. Use for macro-structure checks before voice edits or meandering drafts.
Writes clear technical prose for documentation, READMEs, design docs, blogs, and reports using multi-layer reviews for structure, clarity, and evidence quality.
Self-reviews academic paper paragraphs (intro, abstract, method, related work) to diagnose v1 issues like logic gaps, repetition, and detail leakage, providing targeted revision directions.
Share bugs, ideas, or general feedback.
Между завершением черновика и финальным текстовым аудитом. Порядок:
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 формализует ответ на такие замечания, чтобы следующая статья не повторяла те же ошибки.