Agents & Pipelines — набор агентов и pipeline-воркфлоу для Claude Code

Agents & Pipelines — это набор из 18 узкоспециализированных агентов и трёх pipeline-воркфлоу для Claude Code (и других совместимых харнесов) от автора блога Automated Doubt. 49 звёзд на GitHub, 4 коммита в main — проект молодой, но идея в нём взрослая: каждая фаза разработки должна проходить через отдельную «линзу», а не через один общий взгляд.

Главная мысль простая. Вместо одного здоровенного промпта, который пытается делать всё сразу, автор предлагает набор маленьких агентов. У каждого — своя роль и своя оптика. Хочешь проверить дизайн до того, как начнёшь кодить — запусти Pre-Implementation Architect. Хочешь найти, что ты забыл описать в доке — Docs Validator. Хочешь услышать, что твой код сломан не там, где компилятор ругается, а там, где компилятор молчит — Code Auditor. А Anxiety Reader прочитает твой текст с позиции человека, который боится, что всё провалится.

Это не «ещё один набор скиллов». Это попытка превратить AI-кодинг в последовательность явных, воспроизводимых шагов с разных точек зрения.

Структура репозитория

agents/     # определения агентов — системные промпты с узкой линзой
commands/   # slash-команды для Claude Code, оборачивающие агентов
pipelines/  # цепочки агентов для многошаговых процессов

В agents/ лежат сами определения — markdown-файлы, в которых расписано, что агент делает, на что смотрит и в каком формате выдаёт результат. В commands/ — по одному slash-команде на агент, чтобы их можно было удобно вызывать из Claude Code. В pipelines/ — собранные последовательности, которые прогоняют несколько агентов по очереди.

Как вызывать

В Claude Code агенты доступны как slash-команды:

/agents:assumption-excavator
/agents:code-validate
/agents:anxiety-reader

Пайплайны вызываются точно так же, через косую черту:

/pipelines:pre-implementation
/pipelines:post-implementation
/pipelines:ship

Никакой отдельной установки не нужно — кладёте репозиторий в свою рабочую директорию, Claude Code подхватывает определения, и они становятся доступны в сессии.

Три фазы работы

Весь жизненный цикл задачи разбит на три фазы, и под каждую есть свой pipeline.

Design — pre-implementation

До того, как писать код, дизайн нужно проверить. В этом pipeline три агента:

• Pre-Implementation Architect — смотрит на дизайн с точки зрения архитектурной целостности: подходит ли выбранный подход, не выходит ли задача за разумные рамки, насколько качественно само решение.
• Docs Validator — проверяет, что документация полная и согласована. Если дизайн описан, но половина решений нигде не зафиксирована — он это поймает.
• Assumption Excavator — выкапывает скрытые допущения, на которых стоит дизайн, и оценивает их хрупкость. Любой спорный выбор в архитектуре — это допущение, и его стоит назвать вслух.

Цель фазы — остановить плохое решение до того, как оно превратится в плохой код.

Development — post-implementation

После того, как код написан, его нужно проверить. Здесь пять агентов:

• Code Validator — общая проверка качества: структура, соответствие стандартам, покрытие тестами, лучшие практики.
• Type Safety Validator — для TypeScript-кода ловит то, что компилятор не ловит: any-злоупотребления, небезопасные ассерты, неявные дыры в типах.
• Test Architect — проверяет, что тесты проверяют именно поведение, а не реализацию. Хорошо написанный тест должен пережить рефакторинг.
• Code Optimizer — ищет безопасные рефакторинги для производительности, структуры и поддерживаемости. Только те, что не меняют наблюдаемое поведение.
• Public Interface Validator — смотрит на код глазами потребителя: достаточно ли документации, не сломан ли контракт, удобно ли этим пользоваться.

Каждый агент отвечает за свой аспект. Никто не пытается объять всё сразу.

Ship — финальный прогон

Перед релизом прогоняется самый длинный pipeline. В нём восемь агентов:

Code Validator → Type Safety Validator → Test Architect →
Code Auditor → Public Interface Validator → Security Analyst →
Anxiety Reader → API Contract Validator → Release Readiness

Добавляются три новых линзы:

• Code Auditor — глубокий осмотр кода на ошибки времени выполнения, которые проходят компиляцию, линтер и тесты, но могут выстрелить в продакшене. Race conditions, edge cases, неожиданные состояния.
• Security Analyst — комплексный аудит безопасности: OWASP Top 10, CWE Top 25, специфика конкретной платформы.
• Anxiety Reader — читает артефакт с позиции человека, который боится его поломки. Ищет скрытые опасения за уверенным языком описания.
• API Contract Validator — проверяет, что контракт API согласован между документацией, типами и реализацией.
• Release Readiness — финальный гейт. Проверяет package.json, консистентность версий, документацию, экспорты, релизные артефакты.

Этот pipeline имеет смысл запускать перед публикацией пакета, перед деплоем критического изменения, перед мержем в main. Всё то, что должно быть спокойно, а не «вроде работает».

Полный список агентов

Помимо тех, что уже упомянуты в pipeline'ах, в репозитории есть ещё несколько:

• Gap Analyst — определяет, что должно быть в «правильно оформленном» артефакте данного типа, но отсутствует. Структурные и логические пробелы.
• Implied Completeness Detector — читает форму того, что артефакт содержит, и выводит, чего в нём структурно не хватает.
• Ambiguity Mapper — находит термины и фразы, которые используются в нескольких смыслах внутри одного артефакта. Там, где вы думаете, что говорите одно и то же, он покажет, что это не так.
• Chain Tracer — трассирует цепочки вызовов и коммуникаций по всей кодовой базе от начала до конца.
• Deep Explore — глубокое исследование кодовой базы с многостратегийным поиском и трассировкой связей.

Эти агенты не входят в стандартные pipeline'ы, но доступны как отдельные команды — /agents:gap-analyst, /agents:ambiguity-mapper и так далее.

Идея «Automated Doubt»

Название метода — Automated Doubt — объясняет подход лучше любого README. В традиционной разработке у вас есть ревьюер, который сомневается: «а это точно правильно? а ты проверил edge case? а что если нагрузка вырастет?». У AI-агента по умолчанию такого внутреннего сомнения нет — он оптимизирован на то, чтобы дать вам ответ, а не поставить его под сомнение.

Авторы проекта явно пытаются это починить. Anxiety Reader буквально читает с позиции испуганного человека. Assumption Excavator требует, чтобы все допущения были названы. Ambiguity Mapper ловит места, где вы сами себе противоречите, не замечая. Code Auditor ищет не «ошибки компиляции», а «ошибки продакшена».

Это не замена здравому смыслу. Это попытка зафиксировать в коде ту часть здравого смысла, которая про сомнение и проверку.

Чем это отличается от Superpowers и GSD

Если сравнивать с похожими проектами, разница в фокусе:

• Superpowers от Jesse Vincent — это методология целиком: брейншторм → планирование → TDD → ревью. Жёсткий процесс, который нельзя пропустить.
• GSD от open-gsd — система для планирования и исполнения, с акцентом на context engineering и spec-driven подход.
• Agents & Pipelines от aself101 — узкие аналитические линзы, которые накладываются на артефакт. Никакого процесса, никакого планирования. Только честный взгляд с конкретной стороны.

Они друг другу не мешают. Можно взять процесс из Superpowers, спецификации из GSD, а для финального аудита перед релизом прогнать ship pipeline от aself101.

Когда это использовать

Я бы не запускал все 18 агентов по любому поводу. Это дорого и шумно. Но три сценария выглядят разумно:

1. Перед началом большой задачи — pre-implementation pipeline. Потратить 15 минут на то, чтобы логику проверили со стороны, дешевле, чем потом переписывать.
2. После завершения фичи, перед мержем — post-implementation pipeline. Лёгкая валидация, что не наделали глупостей.
3. Перед релизом — ship pipeline. Полный прогон, включая безопасность и чтение с позиции тревоги. Особенно полезно, если в релизе меняется публичный API.

Отдельные агенты тоже удобно дёргать точечно. Написали дизайн-документ — прогнали Ambiguity Mapper. Написали статью — Implied Completeness Detector. Зарелизили API — Chain Tracer, чтобы убедиться, что нет неожиданных зависимостей.

Что в итоге

Проект молодой, README короткий, лицензия не указана явно. Но сама идея — разложить «хорошее ревью» на набор воспроизводимых шагов с разных точек зрения — заслуживает внимания. Особенно в мире, где AI-агент по умолчанию оптимизирован на согласие, а не на сомнение.

Если вам не хватает в вашем воркфлоу фазы «остановись и проверь, что ты вообще делаешь» — это, пожалуй, самый прямой способ её добавить.