systems-engineering

Разработка и проверка драйверов, прошивок, системных служб и приложений управления оборудованием командой Codex; API/ABI, сборка, аудит памяти и VM/HIL.

SKILL.md

GitHub

Системная разработка в Codex

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

  1. Зафиксируй целевые ОС/SDK/CPU/устройство, требования и критерии готовности. Если нет устройства/проекта, готовь только необходимый план, не генерируй догадки.
  2. Прочитай протокол для командной работы и выбери нужные роли по карте. Не запускай все роли.
  3. Проверь существующие инструменты и доступную VM/HIL. Ни профиль, ни этот навык не создают MCP, базу данных или песочницу. Не загружай драйверы/eBPF и не прошивай оборудование на хосте.
  4. Для multi-step команды используй scripts/coordinate.py: JSON-задания, зависимости, резервирование областей записи, попытки и quality gates. Контракты: references/packets.schema.json. Состояние создавай в целевом проекте, не внутри установленного skill.
  5. План/ABI согласуй по существенным решениям. Существующее поручение уже разрешает обычную реализацию; не требуй повторного утверждения для каждого шага. Основной чат назначает агентов штатными средствами и принимает JSON-результаты, передавая между ними только проверенные ссылки/факты. Если API делегирования поддерживает выбор custom role, укажи имя профиля. Иначе прочитай только выбранный ~/.codex/agents/<name>.toml и передай его инструкции обычному агенту в самодостаточном задании; не выдумывай отсутствующий параметр agent_type.
  6. Выполни нужные ворота на одной версии кода: build, static, security, а runtime — для драйверов/прошивок и иных требований целевой среды. Не заменяй runtime mock-тестом. blocked/непроведённое не равно pass. Любое изменение кода требует нового snapshot и повторения затронутых проверок; финальные обязательные gates должны совпадать с итоговым snapshot.
  7. При дефекте дай systems-bug-fixer ограниченный finding/reproducer, затем независимую проверку. При отсутствии продвижения/среды, 5 попытках одного task ID, deadline или ручной остановке заверши с отчётом. Денежный лимит без достоверной телеметрии не обещай.
  8. supervisor привлекай только при сбоях координации или по запросу; не занимай слот постоянным polling. Для наблюдения используй bounded wait, не перечитывай полные чаты.

Передавай роль, snapshot, пути записи, входные артефакты, критерии и remaining limits в каждом задании. Каждый дочерний агент получает только соответствующий task и нужные фрагменты, без всей переписки. Ответ пользователю: результат, реальные проверки, риски и необходимые внешние действия; кратко.