---
name: cubica
description: Use only when the user explicitly invokes $cubica or explicitly asks for the Cubica autonomous workflow; then run development through a human-approved TSK plan, autonomous orchestration, bounded subagents, risk-based verification, and final acceptance.
---

# Cubica Autonomous Development

## Оглавление

- [Назначение](#назначение)
- [Явное включение](#явное-включение)
- [Полномочия и утверждение плана](#полномочия-и-утверждение-плана)
- [Обязательный контекст](#обязательный-контекст)
- [Цикл работы](#цикл-работы)
- [Задачи и делегирование](#задачи-и-делегирование)
- [Проверки по уровню риска](#проверки-по-уровню-риска)
- [Возврат к человеку](#возврат-к-человеку)
- [Завершение](#завершение)

## Назначение

Используй этот навык для сквозной разработки Cubica: от исследования и согласования общего плана до реализации, проверки и итоговой приемки.

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

Канонические правила процесса задают ADR-068, `AGENTS.md` и `docs/tasks/README.md`. Этот навык не заменяет предметные архитектурные ADR и не создает собственную параллельную систему планов.

## Явное включение

Не применяй этот навык автоматически. Он включается, только если пользователь явно назвал `$cubica` или недвусмысленно попросил применить автономный процесс Cubica.

Сходство запроса с описанием навыка, сложность задачи или желание агента использовать субагентов не считаются включением `$cubica`. Это ограничение не распространяется на остальные навыки: они, включая перенесенные или адаптированные из `agent-skills` и `superpowers`, могут включаться автоматически по собственным правилам.

Включение навыка и утверждение плана — разные решения. Команда реализовать ранее рассмотренный план подтверждает план внутри уже явно выбранного процесса, но обычная просьба изменить код сама по себе не включает `$cubica`.

## Полномочия и утверждение плана

До реализации корневая `TSK-*` должна содержать общий план и запись `Plan Approval`.

Человек утверждает:

- цель и границы;
- основные результаты;
- архитектурные решения;
- существенные риски;
- общие критерии приемки.

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

После утверждения оркестратор самостоятельно выбирает:

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

## Обязательный контекст

Перед планированием прочитай:

1. ближайший `AGENTS.md`;
2. `PROJECT_OVERVIEW.md`;
3. `PROJECT_STRUCTURE.yaml`;
4. `docs/architecture/PROJECT_ARCHITECTURE.md`;
5. `NEXT_STEPS.md`;
6. корневую `TSK-*` и относящиеся к ней ADR;
7. локальные правила затрагиваемых подсистем.

При работе с библиотеками, API, настройкой или кодогенерацией используй Context7 для актуальной документации и практик.

После полного сжатия контекста перечитай ближайший `AGENTS.md`, этот файл, корневую задачу и ее текущий `Handoff Log`.

## Цикл работы

1. Проверь состояние репозитория и соответствие задачи текущей архитектуре.
2. Если общего плана нет, подготовь его в корневой `TSK-*` и передай человеку на согласование.
3. После согласования создай внутреннюю очередь работ и выбери независимые части для параллельного выполнения.
4. Выполняй и делегируй работу без промежуточных вопросов, пока сохраняются утвержденные границы.
5. После каждого результата проверь изменения, доказательства приемки и влияние на документацию.
6. Исправляй найденные проблемы и повторяй проверку до закрытия критичных и существенных замечаний.
7. После дочерней задачи немедленно переходи к следующей незавершенной части общего плана.
8. Заверши корневую задачу только после общей проверки всех обязательных результатов.

## Задачи и делегирование

Используется только формат `TSK-*`; отдельный `PLN-*` не создается.

Дочерняя `TSK-*` допустима, если работа имеет самостоятельный результат, отдельного исполнителя или приемку, выполняется параллельно либо должна пережить текущую сессию. Она обязана:

- содержать `Parent: <TSK-ID>`;
- не дублировать общий план;
- не менять границы родителя;
- иметь собственные `Scope`, `Acceptance`, `Validation` и `Handoff Log`.

Нормативная глубина — один уровень. Более мелкая декомпозиция хранится в `.tmp/agent-workflow/<task-id>/`.

Каждое задание субагенту определяет:

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

Параллельно запускай только работы без пересекающейся записи и скрытой зависимости. Оркестратор просматривает итоговое различие и доказательства проверки; отчет субагента сам по себе не является приемкой. После получения результата явно закрой ненужного субагента.

## Проверки по уровню риска

Выбирай строгость процесса по риску изменения.

- Низкий риск: документация, локальная настройка, очевидная механическая правка. Достаточны детерминированная проверка и просмотр различия.
- Средний риск: изменение поведения в одном модуле. Используй тест до реализации, когда ожидаемое поведение можно выразить исполняемо, затем выполни затронутые проверки и саморевью.
- Высокий риск: публичные контракты, JSON Schema, миграции данных, безопасность, конкурентность, межсервисные границы, изменения нескольких модулей или широкое плохо покрытое изменение. Требуются тест до реализации, полный набор гейтов затронутой границы и независимый рецензент.

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

Независимое ревью не заменяет финальную проверку и приемку оркестратором.

## Возврат к человеку

Останови затронутую часть и запроси решение только когда:

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

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

При частичном блокере продолжай независимые части плана. Новое согласованное архитектурное решение сразу фиксируй в ADR и синхронно отражай в `PROJECT_ARCHITECTURE.md`.

## Завершение

Перед завершением:

- докажи каждый общий критерий приемки;
- выполни требуемые тесты, проверки контрактов и ручные проверки;
- просмотри итоговое различие и отсутствие выхода за границы;
- синхронизируй код, ADR, `PROJECT_ARCHITECTURE.md`, `NEXT_STEPS.md` и задачи;
- перенеси значимые выводы из `.tmp` в постоянные артефакты;
- зафиксируй остаточные риски и следующий шаг;
- закрой ненужных субагентов;
- переведи корневую задачу в `done` только при полной общей приемке.