Skill: DesignCorp Core

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

• Всегда при любой задаче в контурах DesignCorp.
• Всегда перед запуском subagents и перед действиями с prod/dev инфраструктурой.

Входные данные

• Цель задачи в 1 предложении.
• Критерии приемки (3-7 пунктов).
• Затрагиваемые репозитории/домены/сервисы.
• Ограничения по безопасности и доступам.

P0

• Работать только в целевом контуре проекта, не затрагивать чужие репозитории без явного запроса.
• Любые рискованные действия (infra, deploy, security) предварять кратким планом и проверкой предпосылок.
• Команды выполнять в минимально необходимом объеме, без "широких" изменений.
• При инциденте: сначала стабилизация, затем фиксация фактов, затем восстановление.

P1

• Поддерживать единый формат ответа: P0, P1, P2, RISK, список файлов.
• При изменениях в коде всегда фиксировать выполненные проверки (lint/test/build/smoke).
• При изменениях в процессе/инфре обновлять связанную документацию в docs.

P2

• Предлагать упрощение процесса: автоматизация проверок, шаблоны задач, устранение ручных шагов.
• Уменьшать когнитивную нагрузку: короткие отчеты, четкие next steps, без лишней воды.

Multi-Agent Protocol

• Делегировать subagent только изолированную подзадачу с четкой зоной ответственности.
• Параллелить: анализ нескольких файлов, аудит разных подсистем, подготовку независимых изменений.
• Не делегировать: финальные infra-действия и команды, где нужен единый контроль выполнения.
• Формат возврата subagent:
  • что проверено;
  • найденные риски/несоответствия;
  • конкретные файлы/строки;
  • что не удалось проверить.
• Жесткие ограничения для subagents (по умолчанию):
  • запрещено делать git commit, git push, git merge, git rebase, git tag;
  • запрещено закрывать/редактировать GitHub issues/PR;
  • запрещено менять docs/runbooks без явного указания;
  • разрешено только подготовить изменения в рабочем дереве и отчет.
• Главный агент обязан:
  • перед запуском subagent передать явный ownership и список разрешенных файлов;
  • явно указать запрет на коммиты и действия в GitHub;
  • после завершения subagent вручную проверить git diff, ключевые файлы и прогнать проверки;
  • только после своей валидации делать commit/close issue.
• Протокол инцидента:
  • если subagent нарушил ограничения, немедленно остановить pipeline;
  • зафиксировать факт (коммит/файл/команда), сообщить owner и запросить решение;
  • не продолжать работу до явного подтверждения owner.
• Шаблон задания subagent (обязательные поля):
  • Ownership: зона ответственности + перечень файлов.
  • Hard rules: явный запрет git write/GitHub write.
  • Acceptance: измеримые критерии результата.
  • Deliverable: что вернуть (измененные файлы, риски, что не проверено).
  • Confirmation: в конце обязательно строка No git writes / No GitHub writes.
• Post-check перед принятием результата subagent:
  • git status --short (ожидаемые файлы, без лишнего мусора);
  • git log --oneline -n 3 (нет внеплановых коммитов);
  • запуск обязательных проверок руками главного агента (lint/test/build по задаче).

Запрещено

• Менять архитектуру или деплой-процесс без явного согласования.
• Скрывать ошибки проверок или завершать задачу без фактической валидации.
• Делать выводы без указания источника (файл/команда/лог).

Definition of Done

• Изменения ограничены целевым контуром и подтверждены проверками.
• Документация обновлена там, где изменен процесс или эксплуатационные правила.
• Ответ содержит: сделано, проверки, риски, оставшиеся ограничения.