Еще год-два назад большинство разработчиков даже не задумывались о том, что будут программировать агентами с помощью обычных Markdown-файлов. Сегодня ситуация изменилась буквально за несколько месяцев.

Практически каждый современный AI-агент, будь то Claude Code, Cursor, Codex, Gemini CLI или OpenCode, предлагает один и тот же механизм расширения своих возможностей - напишите Skill, опишите процесс решения задачи, добавьте примеры, подключите документацию и агент начнет выполнять эту работу значительно лучше.

Десятилетиями мы учили разработчиков, что Markdown - это документация. Средство общения между людьми. Формат, который не исполняется и никак не влияет на поведение программы, а затем неожиданно оказалось, что один Markdown-файл способен изменить проект сильнее, чем сотни строк кода и здесь индустрия практически мгновенно наступила на старые грабли.

Первые программы тоже редко были образцом инженерной мысли. Это были небольшие скрипты, написанные "на коленке", пока задача помещалась в голове одного инженера. Только позже появились принципы проектирования, модульность, шаблоны проектирования и архитектурные стили. Со Skills сегодня происходит практически то же самое, мы все еще находимся на этапе, когда каждый пишет их так, как считает правильным: кто-то превращает Skill в длинную инструкцию, кто-то пишет чек-лист, кто-то собирает в одном файле десятки правил, примеров и исключений, кто-то вообще копирует половину внутренней документации компании, надеясь, что модель "сама разберется".

Работает ли это? - в каких-то случаях да. Работает ли это хорошо? - пока Skill решает одну небольшую задачу, чаще всего да. Но как только он начинает развиваться, происходят очень знакомые вещи: добавляется новое правило, потом еще один пример, потом появляется поддержка второго языка программирования, затем ссылка на внутренний стандарт, потом оказывается, что для одной из технологий нужны отдельные исключения, а через месяц автор Skill уже боится менять собственный промпт из-за того, что любое изменение превращается в эксперимент, так как промпт это не код и его не возможно трассировать или подебажить. Удалишь один абзац - модель перестает находить часть проблем, добавишь новый пример - неожиданно изменится стиль рекомендаций, поменяешь порядок разделов и вдруг начнут пропадать замечания по безопасности. Самое неприятное, что это происходит не потому, что модель "сломалась" и не потому, что промпт стал слишком большим, проблема значительно фундаментальнее.

Мы пишем Markdown, а агент исполняет алгоритм

Мне кажется, большинство проблем современной агентной разработки начинается с одной очень простой ошибки - мы относимся к Skills как к тексту и это кажется абсолютно естественным, в конце концов Skill действительно написан в Markdown, его можно открыть в любом редакторе, он состоит из заголовков, списков и обычных предложений. Для человека это действительно текст, но для агента - нет. Для агента Skill - это исполняемый алгоритм, не в привычном смысле, где есть переменные, циклы и условные операторы, но в инженерном - совершенно точно. Skill определяет последовательность действий, описывает правила принятия решений, управляет переходами между этапами, определяет входные и выходные данные, использует внешние зависимости, работает с состоянием. Иными словами, делает все то, что мы обычно ожидаем от алгоритма, разница лишь в языке на котором этот алгоритм написан - не на Python, Go, Java/Kotlin, TypeScript и тд, а на естественном языке.

И именно здесь, как мне кажется, происходит главный перелом в мышлении, пока мы считаем Skill обычным текстом, мы пишем и воспринимаем его как текст: добавляем новые разделы, дописываем примеры, вставляем еще один чек-лист, копируем кусок документации. Все это выглядит совершенно безобидно, но если посмотреть на тот же самый файл как на исполняемый алгоритм, вопросы становятся совсем другими:

• почему эта инструкция находится именно здесь?

• почему модель должна увидеть ее именно сейчас?

• нужно ли загружать все примеры сразу или лучше загрузить только нужные?

• можно ли разделить этот алгоритм на несколько независимых этапов?

• какие данные должны передаваться между ними?

Именно в этот момент оказывается, что для Skills начинают работать практически те же инженерные принципы, что и для обычного программного обеспечения:

• длинные процедуры хочется разбить на небольшие

• общие структуры данных - стандартизировать

• повторяющуюся логику - переиспользовать

• большие алгоритмы - декомпозировать

Attention - вычислительный ресурс LLM

Здесь появляется еще одна особенность, которая отличает алгоритмы для агента от привычных нам программ. У классической программы есть процессор, который последовательно выполняет инструкции, у языковой модели такого процессора нет, ее главный вычислительный ресурс - внимание (Attention). Именно механизм внимания определяет, какие части контекста окажутся наиболее значимыми при генерации следующего ответа. Это не означает, что модель "читает только последние строки" или "забывает начало промпта", современные трансформеры устроены значительно сложнее, но означает другое, внимание модели - это ресурс и как любой ограниченный ресурс, им необходимо управлять. Именно поэтому хороший Skill - это не тот, который содержит больше инструкций, хороший Skill - это тот, который в каждый момент времени помогает модели сосредоточиться только на тех знаниях, которые действительно нужны для решения текущей задачи. Именно отсюда рождается большинство архитектурных решений современной агентной разработки, именно поэтому большие Skills постепенно распадаются на маленькие, именно поэтому оркестраторы начинают подгружать Skills "лениво" по мере выполнения workflow, а не все сразу.

Паттерн №1. Декомпозиция.

Если попросить опытного разработчика объяснить принцип декомпозиции, он, скорее всего, ответит что-нибудь вроде:

Один модуль - одна ответственность.

Эта идея настолько привычна, что кажется очевидной. Мы применяем ее к функциям, классам, пакетам, сервисам и микросервисам. Поэтому неудивительно, что первой реакцией при проектировании Skills становится перенос того же принципа в мир построения агентного flow, один Skill - одна задача, но здесь есть важный нюанс. Для обычного программного кода декомпозиция - это прежде всего вопрос удобства сопровождения, а для агента - это вопрос качества результата. Именно поэтому этот паттерн оказывается настолько фундаментальным.

Монолитный Skill

Представим типичный Skill для code review.

Steps:
- Analyze architecture
- Check security
- Validate API design
- Review naming
- Detect code smells
- Evaluate performance
- Review tests
- Validate documentation
- Suggest fixes
- Produce final report

На первый взгляд выглядит вполне разумно, все ведь относится к code review, но попробуем посмотреть на него глазами модели. Фактически мы просим ее одновременно играть роли:

• архитектора

• специалиста по безопасности

• performance-инженера

• ревьюера

• технического писателя

• иногда даже разработчика

Причем постоянно переключаться между ними, каждая новая роль требует собственного набора эвристик, собственного способа анализа, собственного критерия качества. Именно здесь начинает происходить самое интересное.

Конфликт инструкций

Большинство современных LLM умеют прекрасно выполнять сложные задачи, но значительно хуже они справляются с большим количеством разных задач одновременно и это очень важное различие. Например.

Представим два запроса.

Первый:

Проанализируй архитектуру сервиса.

Второй:

Проанализируй архитектуру, безопасность, производительность, API, документацию, тесты, стиль кода, предложи исправления и оформи всё в Markdown-отчет.

Во втором запросе вычислительной сложности почти не прибавилось, зато резко выросло количество независимых целей, а значит выросла вероятность конфликта между инструкциями. Модель начинает постоянно выбирать, чему уделить больше внимания - это и есть то, что я называю конфликтом инструкций. Не потому, что инструкции противоречат друг другу буквально, а потому, что они конкурируют за ограниченный ресурс внимания модели, это очень похоже на ситуацию, когда одному инженеру одновременно говорят:

• найди архитектурные проблемы

• но не забудь проверить безопасность

• и обязательно оцени производительность

• ах да, еще оформи красивый отчет

Каждая задача разумна, но все вместе уже значительно сложнее.

Промпт этропия

Есть еще одна проблема, которая редко обсуждается, назовем ее промпт энтропия, звучит она так

Чем больше различных обязанностей появляется у одного Skill, тем менее предсказуемым становится его поведение.

Добавление нового раздела может неожиданно изменить ответы в совершенно другой части промпта, новый пример способен повлиять на стиль рекомендаций, изменение формата отчета иногда уменьшает количество найденных проблем. Практически каждый, кто долго работал с большими промптами, хотя бы раз сталкивался с ситуацией: добавил двадцать строк про формат Markdown и почему-то ухудшился анализ архитектуры. С точки зрения классического программирования это выглядит абсурдно, но для LLM это вполне ожидаемое поведение.

Чем больше независимых инструкций сосуществует в одном контексте, тем выше вероятность неожиданных взаимодействий между ними.

Именно поэтому большие Skills становятся хрупкими, не из-за размера, а из-за внутренней связности инструкций.

Что происходит после декомпозиции

Теперь разделим предыдущий Skill.

review/

├── review.md
├── review-security.md
├── review-performance.md
├── review-api.md
├── review-architecture.md
├── review-testing.md
└── review-style.md

Каждый дочерний Skill получает только одну ответственность.

Например:

review-security.md

Responsibilities:

- Detect vulnerabilities
- Validate authentication
- Detect secret leakage
- Check insecure dependencies

Никаких архитектурных рекомендаций, никаких рассуждений про производительность, никаких требований к отчету, только безопасность. Теперь модель не вынуждена постоянно переключать стратегию анализа, она может сосредоточиться на одной компетенции, именно поэтому специализированные Skills почти всегда работают стабильнее универсальных.

Оркестратор - не исполнитель

В этот момент возникает закономерный вопрос, если каждый Skill отвечает только за одну задачу, кто управляет всем процессом? Ответ - отдельный Skill оркестратор.

И здесь многие совершают вторую распространенную ошибку - начинают переносить бизнес-логику в оркестратор.

Получается примерно так:

Review

↓

Analyze Security

↓

Если найдено больше пяти проблем —
запустить дополнительную проверку

↓

Самостоятельно оценить риск

↓

Изменить найденные findings

↓

Запустить Performance

На первый взгляд всё логично, но постепенно оркестратор начинает знать слишком много, а через некоторое время оказывается, что именно в нем сосредоточена половина логики всей системы и мы снова получили монолит просто другого размера. Хороший оркестратор должен делать только одну вещь - организовывать процесс. Не анализировать код, не исправлять результаты, не спорить с дочерними Skills, не принимать экспертные решения, его работа удивительно скучна - запустить нужный Skill, передать контекст, получить результат, запустить следующий. Именно поэтому мне нравится аналогия с дирижером. Дирижер не играет вместо скрипача, если он начинает это делать, оркестр заканчивается.

Резюмируем:

Декомпозиция позволяет структурировать алгоритмы и управлять вниманием модели. Декомпозиция не про responsobility, декомпозиция про attention.

Паттерн №2. Агрегация.

После того как мы разбили систему на десятки специализированных Skills, возникает новый вопрос - что делать с результатами их работы если каждый Skill производит собственный результат?

Первое решение, которое приходит в голову

Представим, что мы написали пять специализированных Skills.

review-security
review-performance
review-api
review-style
review-testing

Каждый из них возвращает собственный Markdown-отчет.

Например.

# Security Review

...

Другой возвращает

# Performance Review

...

Третий пишет таблицу, четвертый список, пятый вообще решил оформить всё в JSON. После чего оркестратор получает пять документов и начинает их объединять. Именно в этот момент начинается маленькая инженерная трагедия.

Появляются функции:

• смерджи отчеты

• нормализуй заголовки

• удали дубли

• сортируй итоговый список проблем

• сделай итоговый отчет в указанном формате

• предложи фиксы

• и тд

Если посмотреть внимательно, становится понятно, что мы неожиданно начали писать ETL-конвейер, только вместо баз данных мы преобразуем Markdown и, как любой ETL, он постепенно начинает жить собственной жизнью.

• Добавился новый Skill? - нужно обновить merge

• Изменился формат заголовков? - нормализация работает как-то не так

• Один Skill решил использовать таблицы вместо списков? - добро пожаловать в очередной if

На самом деле проблема возникла значительно раньше, мы выбрали неправильную единицу обмена.

Не обменивайтесь отчетами

Самая распространенная ошибка при проектировании агентных workflow - заставлять Skills обмениваться готовыми документами.

Документ - это представление и как правило конечный артефакт который нужен человеку или агенту в новом контекстном окне для того чтобы продолжить/принять работу, представление плохо подходит для передачи данных между Skills в рамках одного workflow.

Представьте обычное приложение: один сервис возвращает HTML, второй пытается из него извлечь данные и превратить в JSON, третий снова превращает их в HTML - звучит странно. Но именно это часто происходит в агентных системах, Skill пишет красивый Markdown, оркестратор его "парсит", после чего снова собирает новый Markdown.

Общий контракт

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

Оркестратор заранее объявляет структуру данных, с которой будут работать все Skills.

Например:

context:
  findings: []

После этого каждый дочерний Skill знает одно простое правило.

Нашел проблему? - добавь ее вfindings.

findings:
  - category: security
    severity: high
    file: auth.py
    message: SQL Injection

Другой Skill добавляет:

findings:
  - category: performance
    severity: medium
    file: api.py
    message: N+1 Query

Еще один:

findings:
  - category: architecture
    severity: low
    file: payment.py
    message: Large Service

Обратите внимание, ни один Skill не знает, как будет выглядеть финальный отчет, это вообще не его ответственность, он производит данные переключая внимание модели по ходу подгрузки workflow в контекстное окно.

Blackboard Architecture для LLM

Если посмотреть на этот паттерн со стороны классической архитектуры, он покажется знакомым, очень похожая идея использовалась еще задолго до появления моделей и агентов.

Например, в Blackboard Architecture, несколько независимых экспертных систем работают не напрямую друг с другом, а через общую рабочую область, каждый эксперт читает текущее состояние, добавляет свои знания, передает управление дальше. Skills делают практически то же самое, общий контекст становится своеобразной "доской", на которой постепенно появляется всё больше информации и именно поэтому Skills перестают зависеть друг от друга напрямую, а связываются единым контрактом через оркестратор. По сути мы можем пересобрать весь workflow с другим набором проверок, подключить другие Skills, поменять последовательность и тд, нужно будет сделать новый оркестаратор и объявить в нем workflow.

Почему это лучше

На первый взгляд кажется, что мы всего лишь заменили Markdown на YAML, на самом деле изменилось гораздо больше. Во-первых, появляется единый контракт, каждый Skill возвращает данные одинаковой структуры. Во-вторых, исчезает необходимость понимать ответы других Skills и security не читает performance, performance не анализирует Testing и тд. Каждый Skill забирает внимание на себя для решения задачи. В-третьих, становится возможным настоящее параллельное выполнение, можно каждый Skill запустить в отдельном subagent и потом агрегировать findings в оркестаторе.

Именно поэтому большинство современных agentic runtime стремятся к моделям с разделяемым состоянием, а не с передачей готовых текстовых ответов между агентами.

Агрегация - это не про список или массив

Здесь есть одна мысль, которую легко упустить, многие воспринимают агрегацию как обычный массив.

findings: []

Но это слишком поверхностное понимание, на самом деле агрегация - это архитектурный контракт.

Мы заранее договариваемся:

• какие структуры данных существуют

• кто имеет право их изменять

• какие поля обязательны

• какие изменения допустимы

Другими словами, мы проектируем не Skills, мы проектируем состояние и контекст и это очень важный сдвиг мышления при работе с Skills. Хорошая агентная система обычно строится вокруг контекста, а если контекст структурирован и имеет своих consumer-ов и producer-ов, то и агенту (модели) будет проще работать с ссылками, а не с горой текста в документах. Skills становятся лишь функциями реализующими алгоритмы, которые постепенно расширяют контекст.

К примеру, усложним структуру:

context:
  findings: []
  attention_files: []

И теперь скажем, что Skill может не только расширятьfindings, но и слушать attention_files

consume:
  - attention_files
produce:
  - findings

В этом случаи, мы сможем объяснить Skill алгоритму, что нужно придать больше внимания проблемным файлам и он по ссылке найдет их в контексте, а проблемные файлы может запродюсить другой Skill(s) ранее.

Резюмируем:

Агрегация позволяет задать общий контракт и систематизировать ссылочную связанность контекста для LLM в рамках одного контекстного окна, а работу с наполнением контракта делегировать.

Паттерн №3. Расширение

Декомпозиция разбивает сложную задачу на независимые части, агрегация позволяет собрать результаты этих частей в единое состояние. Кажется, что теперь можно построить практически любой workflow, но довольно быстро появляется категория задач, для которых оба подхода вместе начинают работать плохо. Представьте, что агенту нужно не искать проблемы, а написать ADR или сформировать техническое задание, а может даже спроектировать архитектуру нового сервиса или составить план миграции. Что произойдет, если мы попробуем использовать уже знакомую агрегацию? - каждый Skill начнет писать собственную часть документа:

• Один - цели

• Другой - требования

• Третий - архитектуру

• Четвертый - ограничения

Формально всё выглядит правильно, но очень быстро выясняется, что части документа начинают противоречить друг другу, раздел "требования" использует одну терминологию, архитектура другую, критерии приемки ссылаются на сущности, которых вообще нет в описании. Каждый раздел написан хорошо, но документ плохой. Причина проста - мы снова выбрали неправильную единицу композиции.

Документ - это не набор независимых частей

Попробуем посмотреть на техническое задание глазами разработчика. Когда архитектор пишет документ, он редко начинает сразу с деталей, сначала появляется идея, потом каркас, затем уточняются требования, после этого появляются ограничения, потом модели данных, потом API, потом сценарии ошибок и только в самом конце документ начинает шлифоваться.

Другими словами, хороший документ не собирается из независимых фрагментов, он постепенно развивается, каждая новая мысль опирается на предыдущую, именно поэтому попытка писать разные главы независимо почти всегда приводит к логическим противоречиям.

Документ как живой объект

Вместо того чтобы создавать отдельные части, можно изменить саму модель работы.

Представим, что первый Skill создает минимальный каркас.

# Сервис платежей

## Цель

## Требования

## Архитектура

## API

## Ограничения

Это еще не документ, скорее заготовка.

Теперь второй Skill берет этот документ целиком и начинает его развивать.

↓

Добавить бизнес-требования.

Следующий.

↓

Добавить модели данных.

Еще один.

↓

Добавить REST API.

Далее.

↓

Добавить обработку ошибок.

Еще один.

↓

Добавить нефункциональные требования.

Обратите внимание, никто не пишет документ заново, каждый Skill продолжает существующее состояние, получается своеобразная эволюция артефакта.

Почему это работает

На первый взгляд может показаться, что этот паттерн отличается от агрегации лишь тем, что Skills работают с одним объектом вместо массива, но на самом деле различие намного глубже. При агрегации каждый Skill независим, если поменять местами security и performance, итог практически не изменится, да и в целом можно менять оркестраторы и собирать разные workflow добавляя и заменяя Skills для наполнения findings. При расширении порядок становится частью алгоритма, нельзя описать API раньше, чем станет понятна предметная модель, сложно написать критерии приемки до появления требований, практически невозможно сформулировать ограничения безопасности до определения архитектуры. Каждый следующий шаг зависит от предыдущего, причем не только технически, но и семантически, мы как бы множим результат и этим множителем управляет последовательный алгоритм.

Эффект накопления контекста

Есть еще одна причина, по которой этот паттерн особенно хорошо работает с LLM - модель получает не пустой лист, она получает уже сформированный контекст.

Например:

• первый Skill решил использовать термин domain

• следующий автоматически начинает использовать тот же термин (а не, к примеру, component)

• первый описал сервис как event-driven

• следующий уже не будет предлагать синхронную архитектуру без веской причины

Появляется эффект накопления знаний, документ постепенно начинает согласовываться сам с собой и как результат - лучше attention. Именно этого почти невозможно добиться, если разные разделы создаются независимо.

Как в этом случаи представить орекестратор? - проще всего, использовать последовательный алгоритм с набором фаз.

Например:

### Phase 1. Intake
- Invoke: **my-intake-skill** with arguments $ARGUMENTS
- Output: [INTAKE_REPORT]
- STOP if: <you expresion>

### Phase 2. Project Context
- Invoke: **my-project-context-skill**
- Reads: [INTAKE_REPORT]
- Output: [PROJECT_CONTEXT_REPORT]
- STOP if: <you expresion>

...

В такой структуре мы даем агенту четкую, пофазную инструкцию работы, каждый invoke будет попадать в контекстное окно по мере необходимости, агент будет понимать ссылки Reads и Output. Опционально можно докинуть всяких условий, типа STOP if.

Где проходит граница

Очень важно понимать, что расширение - не универсальный паттерн. Например, представим code review, можно ли последовательно расширятьfindings? Технически да, но архитектурно это будет ошибкой, каждый анализ независим, безопасность не должна зависеть от проверки производительности, performance не должен зависеть от анализа документации - такие задачи лучше агрегировать.

Теперь представим написание ADR. Можно ли независимо создать контекст с разделами "Архитектурное решение" и "Компромиссы"? Тоже можно, но почти наверняка они будут плохо согласовываться, и тут уже выигрывает расширение.

Поэтому очень простой вопрос помогает выбрать нужный паттерн:

Может ли следующий Skill начать работу, не читая результат предыдущего?

Если ответ "да" - скорее всего перед нами агрегация.

Если ответ "нет" - почти наверняка это расширение.

Три паттерна - три разных способа думать

После знакомства со всеми тремя паттернами становится заметно, что они отвечают на совершенно разные вопросы.

Декомпозиция отвечает на вопрос:

Как разделить ответственность между Skills?

Агрегация отвечает на вопрос:

Как объединить результаты независимых Skills?

Расширение отвечает на вопрос:

Как постепенно построить один общий артефакт?

Если после прочтения предыдущих глав у вас возникло желание выбрать "правильный" паттерн и использовать только его - значит, я недостаточно хорошо объяснил основную идею, потому что выбирать, как правило, не приходится. В реальных агентных системах эти паттерны почти никогда не существуют по отдельности, они часто работают одновременно. Более того, каждый отвечает за свой уровень архитектуры.

Давайте посмотрим на типичный workflow для code review.

                 Review
                    │
        ┌───────────┼───────────┐
        │           │           │
   Security      Performance    API
        │           │           │
        └───────────┼───────────┘
                    │
             findings[]
                    │
                    ▼
          Build Final Report

Что здесь происходит?

Верхний уровень - это декомпозиция. Оркестратор разбивает одну большую задачу на несколько специализированных.

Средний уровень - агрегация. Каждый Skill независимо наполняет общий контейнер findings.

Последний этап - отдельный Skill, который превращает структурированные данные в документ для человека.

Обратите внимание: даже финальная генерация отчета не смешивается с анализом. Она является самостоятельной ответственностью. Это небольшое решение часто кажется незначительным, но именно оно избавляет модель от необходимости "разбирать Markdown, чтобы снова написать Markdown".

Теперь посмотрим на совершенно другую задачу - проектирование новой системы.

             Design
                │
      Create Skeleton
                │
                ▼
      Add Requirements
                │
                ▼
      Add Architecture
                │
                ▼
          Add API
                │
                ▼
      Add Acceptance Criteria

Здесь нет массива findings, нет независимых результатов, каждый следующий Skill берет нужные ему ссылки из "прошлого" и делает итоговый документ богаче - это уже расширение.

Как выбрать правильный паттерн

За время проектирования агентных систем у меня появилось несколько простых вопросов, которые помогают выбрать подход практически безошибочно.

Первый вопрос:

Нужно ли разбивать workflow на более мелкие шаги?

Если да - нужна декомпозиция.

Второй вопрос:

Можно ли выполнить Skills независимо друг от друга?

Если да и нужно итоговое состояние - используйте агрегацию. Каждый Skill производит собственные данные, никто их не переписывает.

Третий вопрос:

Каждый следующий Skill обязан понимать результат предыдущего?

Если да - перед вами расширение. Каждый шаг становится продолжением предыдущего.

На практике, верхнеуровнево, этого оказывается достаточно для большинства архитектурных решений.

На самом деле мы уже знаем эти паттерны

Есть интересная закономерность, когда рассказываешь про эти паттерны разработчикам, многие сначала воспринимают их как что-то принципиально новое, все таки перед нами что-то новое - агентная разработка, но проходит несколько минут и появляется мысль: "подождите... ведь это уже где-то было". И действительно, декомпозиция очень напоминает принцип единственной ответственности, агрегация похожа на Blackboard Architecture, MapReduce и событийные конвейеры, а расширение - на пошаговое построение сложного артефакта, которое давно используется в компиляторах, генераторах кода и системах проектирования.

Получается любопытная картина, Agent Skills не требуют новой инженерии, они требуют заново посмотреть на старую и просто правильно применить ее в новой реальности.

Вместо заключения

Интересное наблюдение - если "три паттерна" написать слитно, как "трипаттерна", то это прозвучит, как название какого-то заболевания =)

Желаю чтобы ваши проекты как можно меньше болели и всегда были здоровы! =)

В качестве примеров, у нас есть проект Goga который представляет из себя полноценную платформу для разработки на AI, которая включает в себя целую экосистему и SDD фрэймворк. Так же, будем рады видеть в нашем ТГ канале про разработку и тестирование с AI.

В Goga проекте можно найти примеры реализации описанных паттернов:

• Декомпозиция + расширение - Skill для построения архитектуры

• Декомпозиция + агрегация - Skill для ревью промптов