ai-team-orchestration

AI Team Orchestration — навык GitHub для запуска лёгкой multi-agent команды разработки и сохранения контекста между сессиями. Он использует три устойчивые роли. Producer уточняет объём, строит пропорциональный план, координирует работу и объединяет результат. Dev реализует изменение, запускает проверки, делает self-review и готовит pull request. QA независимо проверяет поведение, когда отдельное тестирование действительно добавляет ценность. Внутри Dev могут использоваться перспективы Nova, Sage и Milo, но они не являются обязательными слоями проекта и не должны автоматически превращаться в дополнительные процессы. Базовая последовательность выглядит как plan, implement, test, при необходимости review или QA, merge и обновление состояния проекта. Workflow должен быть пропорциональным: для маленького очевидного изменения формальный план можно пропустить, для многошаговой или сквозной работы нужен короткий план, а независимый review или QA добавляются по риску, неопределённости и правилам репозитория. Политики веток, обязательные checks, permissions и merge queue должны обеспечивать правила слияния на уровне репозитория. Сам навык не требует церемонии ради церемонии: полезный результат и ясная передача работы важнее процесса, который не снижает риск. Перед началом или принятием проекта producer читает существующие инструкции и документацию репозитория, выясняет фактический стек, архитектуру, команды, deployment model и риски. PROJECT_BRIEF создаётся или обновляется только тогда, когда долговечный контекст действительно полезен для следующих сессий. Для существенной работы составляется сжатый план из подходящего шаблона, а при потенциально конфликтующих параллельных сессиях выбирается отдельная ветка или clone по Git-политике проекта. Это не разрешение выдумывать структуру: сначала нужно обнаружить действующую организацию проекта и соблюдать её правила. На этапе выполнения Dev следует локальным соглашениям и делает минимальное полное изменение. Он проверяет поведение, запускает релевантные тесты, проводит self-review и подготавливает pull request с понятным summary, verification и limitations. QA используется только там, где независимая проверка поведения оправдана; он тестирует запрошенное изменение и важные регрессии и сообщает воспроизводимые findings, а не повторяет процесс без новой информации. Producer удерживает критерии приёмки и явные исключения, выбирает нужный уровень review и затем передаёт итог в merge и обновление проектного состояния. Навык также описывает пропорциональный режим для brainstorm: формат с отдельными перспективами нужен для продуктового или архитектурного решения, которому действительно полезны конкурирующие точки зрения; обычный технический выбор Dev делает по правилам репозитория. При восстановлении после долгой или прерванной сессии нужно обновить активный план или progress note, записать существенные решения, блокеры и следующий шаг в долговечном проектном контексте, а затем использовать cold-start prompt, который снова отсылает к инструкциям репозитория, активной задаче, brief и плану. Инструменты и модели не ограничиваются искусственным machine-specific allowlist: доступные встроенные и подключённые возможности остаются доступными, если это не противоречит доверию, permissions и политике проекта. Практический сценарий применения — организовать работу над feature или bug так, чтобы каждый участник имел одну понятную ответственность, а уровень контроля соответствовал риску. Producer не обязан планировать очевидную правку, Dev не обязан создавать абстракции ради будущего, QA не обязан подключаться к низкорисковому изменению, а review и merge должны оставаться подчинены действующим branch protection и обязательным checks. Принцип навыка — предпочитать работающий код и ясные handoff-ы процессным артефактам, сохранять важные решения в проектном контексте, не выполнять разрушительные или привилегированные действия без разрешения и не терять неизвестную работу при переходе между сессиями. Таким образом, orchestration задаёт роли и контрольные точки, но оставляет команде возможность пропускать лишние этапы, когда риск этого не требует.