Claude Code пише пост про себе: мій контент-конвеєр

whitetrd · 01.03.2026 · 6 min read

claude-codeai-automationcontent-pipelineblog

Контент-конвеєр на базі Claude Code — це система, де Author Bible, Critic і Humanizer перетворюють хаотичний процес написання на відтворюваний пайплайн якості. Конкретна схема з конкретними файлами: ідея входить з одного боку, готовий текст виходить з іншого. Без натискання однієї кнопки, без магічних очікувань. Цей пост — перший результат роботи цього конвеєра, і він описує сам себе.

Парадокс першого посту

Я пишу пост про систему створення постів — і цей пост створений тією самою системою. Мета? Так. Але це найчесніший спосіб показати, що конвеєр працює: ви читаєте його вихід прямо зараз.

Що ви отримаєте: конкретну схему з файлами, командами і промптами. Робочий пайплайн, який я зібрав і прогнав вперше саме на цьому тексті. Це чесно — я ще не знаю, як він поведеться на десятому пості. Але на першому він відпрацював, і я покажу як.

Проблема: хаос і AI-пастка

Знаєте, як це буває: з’являється ідея, сідаєш писати, годину дивишся в екран, щось народжується, потім переписуєш з нуля. І десь на третьому колі приходить спокуса: “Claude, напиши пост про X”.

І Claude напише. Гладкий, структурований, з підзаголовками і переходами. Проблема в тому, що цей текст — порожній. Він нічий. У ньому є характерні AI-tells:

Є простий тест — я називаю його dead-end test: якщо перше і останнє речення абзацу можна прибрати без втрати змісту — абзац порожній. Спробуйте на будь-якому тексті від ChatGPT без конкретного промпту. На мою думку, це найпростіший спосіб відрізнити AI-текст від людського — якщо абзац тримається без обгортки, він справжній.

Промпт “напиши пост” — це перенесення хаосу з моєї голови в голову моделі. Нічого більше.

Рішення: конвеєр як система

Замість одного промпту — послідовність етапів. Кожен робить одну річ. Кожен пише файл, який читає наступний.

[Ідея] → [Research] → [Brief] → [Draft] → [Critic] → [Humanize] → [PR]

Розберу кожен елемент.

CLAUDE.md — мозок системи

CLAUDE.md — це файл у корені проєкту, який Claude Code читає автоматично при кожному запуску (функція Memory). Все, що в ньому написано, стає інструкцією для агента.

Я вшив сюди Author Bible — опис того, як я пишу:

Author Bible працює як жорсткий контракт — Claude Code дотримується цих правил на кожному етапі, бо CLAUDE.md читається завжди.

Skills: кожен етап — окрема команда

Skills у Claude Code — це .claude/commands/*.md файли. Кожен файл — це шаблон промпту, який викликається як /command. Наприклад, /research, /critique, /humanize.

Навіщо розбивати на окремі команди, а не один великий промпт? Кожен етап має різну задачу, різний контекст і різні критерії успіху. Research шукає факти. Critic шукає проблеми. Humanizer прибирає AI-tells. Змішати це в одному промпті — отримати посередній результат у кожному.

Файли як пам’ять між етапами

Кожен крок пише вихідний файл, наступний крок його читає:

research.md → brief.md → draft.md → critique.md → final.md

Це файлова пам’ять. Простіша за бази даних, надійніша за контекст моделі. Якщо щось пішло не так на етапі критики — я відкриваю critique.md, бачу конкретні зауваження, правлю draft.md і запускаю знову. Не треба починати з нуля.

Як це виглядає на практиці

Ось реальний промпт для дослідження:

Промпт: /research

/research "Claude Code automation pipeline for blog posts"
Read CLAUDE.md for project context.
Search for: Claude Code skills system, hooks lifecycle.
Write findings to research.md.

А ось промпт для критика — найцінніший етап у всьому конвеєрі:

Промпт: /critique

/critique draft.md
Read draft.md and author-bible.md.
Identify: hedging language, passive voice, paragraphs that fail the dead-end test,
universal claims without specifics, AI-tells.
Write critique.md: list issues by paragraph number, suggest concrete fixes.
Do NOT rewrite — only diagnose.

Зверніть увагу на останній рядок: “Do NOT rewrite — only diagnose”. Це принципово. Critic не переписує — він знаходить проблеми. Переписування — задача наступного етапу. Розділення відповідальності працює і тут.

Multi-agent схема

Claude Code підтримує sub-agents через Task tool — ізольовані агенти з власним контекстом і набором інструментів. Оркестратор розподіляє роботу:

                    ┌─────────────┐
                    │ Orchestrator│
                    │ (головний)  │
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
        ┌─────▼─────┐ ┌───▼────┐ ┌────▼────┐
        │ Researcher │ │ Critic │ │ Editor  │
        │ (read-only)│ │(read)  │ │ (write) │
        └───────────┘ └────────┘ └─────────┘

Researcher — read-only агент, він шукає інформацію і пише research.md. Critic читає чернетку і пише critique.md. Editor вносить правки. Кожен бачить тільки те, що йому потрібно.

У чому перевага ізоляції? Researcher не знає про Author Bible — йому не потрібно. Critic не має доступу до редагування файлів — він не повинен “допомагати” переписуванням. І це працює саме тому, що кожен агент обмежений своєю зоною.

Deaification: як прибрати “AI-запах”

Три механізми, і вони доповнюють один одного:

  1. Author Bible в CLAUDE.md — модель знає мій голос ще до початку роботи. Конкретні патерни заміни: не “уникай пасивного стану”, а “було створено → я створив”.

  2. Конкретика замість узагальнень — Brief містить реальні факти, команди, файли. Модель не вигадує — вона працює з тим, що я дав.

  3. Dead-end test у Critic — промпт для критика явно вимагає знайти абзаци, де перше і останнє речення можна прибрати. Це автоматичний фільтр води.

Результат: що конвеєр зробив з цим текстом

Цей пост пройшов через конвеєр. Конкретно:

Де я втрутився руками: Brief я писав сам. Це найкритичніший файл — він визначає, про що буде текст, які факти використовувати, яку структуру мати. Але є й особиста причина: Brief — це момент, коли я формулюю думку для себе. Автоматизувати його означало б пропустити єдину частину процесу, де я справді думаю, а не редагую.

Що поки що працює не ідеально: Humanizer іноді перестарається і робить текст надто “розмовним”. Critic не завжди ловить тонкі AI-tells на кшталт надто рівномірного розподілу абзаців. Це перший прогін — я чесно не знаю, які проблеми вилізуть на другому і третьому. Але що мене здивувало: Critic виявився найкориснішим етапом. Я очікував, що головну роль гратиме Humanizer, а виявилось — діагностика важливіша за лікування.

Система проти хаосу

Якість тексту — це процес, який можна розкласти на кроки. Кожен крок має чітку задачу і критерії. Талант і натхнення нікуди не діваються, але вони працюють краще всередині структури, ніж у порожнечі.

Конвеєр не пише за мене. Він організовує процес: дослідження окремо, структура окремо, написання окремо, критика окремо, полірування окремо. Як у програмуванні — декомпозиція працює і для тексту.

Що ви можете зробити завтра:

  1. Створіть файл CLAUDE.md з Author Bible — 5 пунктів про ваш голос, 5 заборон
  2. Напишіть один Skill — /critique з промптом для пошуку AI-tells
  3. Пропустіть будь-який свій текст через цей Skill
  4. Подивіться на critique.md і вирішіть, чи згодні з зауваженнями

Це займе годину. Але наступного разу, коли ви сядете писати — у вас буде система, а не порожній екран.

FAQ

Яка підписка потрібна для Claude Code?

Claude Code доступний починаючи з підписки Pro ($20/міс). Max-плани дають більше використання. Skills і CLAUDE.md доступні в базовому функціоналі.

Скільки часу пішло на цей пост?

Це перший пост через конвеєр, тому я ще калібрував процес на ходу. Від Brief до фінального тексту — кілька ітерацій з ручними правками між ними. Головне тут — не швидкість, а те, що наступний пост пройде тим самим шляхом швидше.

А якщо я використовую інший AI-інструмент?

Принцип конвеєра (етапи → файли → наступний етап) працює з будь-чим. Але Skills як .md-файли і CLAUDE.md як автоматичний контекст — це специфіка Claude Code, і саме вона робить пайплайн зручним.

Related