一键导入
skill-orchestrator
Используй в начале каждого разговора — устанавливает правило обязательной проверки скиллов перед ЛЮБЫМ действием, включая уточняющие вопросы
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Используй в начале каждого разговора — устанавливает правило обязательной проверки скиллов перед ЛЮБЫМ действием, включая уточняющие вопросы
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Написание тестов для нового функционала
Используй ПЕРЕД любой работой по созданию или изменению функциональности. Исследует намерения пользователя, требования и дизайн до начала реализации.
Код-ревью изменений на качество, безопасность и соответствие стилю проекта
Генерация текста коммита и структурированного описания изменений для команды и QA
Генерация текста коммита (только сообщение коммита, без описания изменений для MR/QA). Используй когда пользователь просит написать коммит, подготовить сообщение для git commit, или когда нужно просто текст коммита без полного описания изменений.
Используй когда есть готовый план реализации для выполнения с контрольными точками проверки
| name | skill-orchestrator |
| description | Используй в начале каждого разговора — устанавливает правило обязательной проверки скиллов перед ЛЮБЫМ действием, включая уточняющие вопросы |
ЕСЛИ СКИЛЛ ПРИМЕНИМ К ЗАДАЧЕ — У ТЕБЯ НЕТ ВЫБОРА. ТЫ ОБЯЗАН ЕГО ИСПОЛЬЗОВАТЬ.
Это не обсуждается. Это не опционально. Ты не можешь рационализировать отказ от этого.
Скиллы переопределяют поведение по умолчанию, но инструкции пользователя всегда в приоритете:
Вызывай подходящие скиллы ДО любого ответа или действия. Даже 1% шанс что скилл может быть применим означает что нужно его вызвать. Если вызванный скилл оказался неподходящим — можно не следовать ему.
Базовый набор шаблонных скиллов:
| Ситуация | Скилл |
|---|---|
| Пользователь описывает идею / хочет что-то создать или изменить | brainstorming |
| Есть спек или чёткие требования для многошагового задания | writing-plans |
| Есть готовый план для выполнения | executing-plans |
| Любая ошибка, неожиданное поведение, баг | systematic-debugging |
| Собираешься заявить что что-то готово / работает / исправлено | verification-before-completion |
| Написать тесты для нового функционала | unit-test-writer |
| Ревью изменений на качество и безопасность | code-review |
| Подготовить коммит + описание изменений для MR/QA | commit-and-changes-writer |
| Написать только сообщение коммита (без описания MR) | commit-writer |
| Обновить или почистить CLAUDE.md | update-claude-md |
| Подготовить промпт для перехода к следующему этапу в новом чате | next-stage-prompt |
| Вопрос, объяснение, консультация — без создания или изменения чего-либо | скилл не нужен, отвечай напрямую |
Проектные скиллы (специфичные для конкретного стека/инфраструктуры этого проекта) добавляй в эту таблицу отдельной строкой.
brainstorming → [спек сохранён в docs/specs/] → writing-plans → executing-plans (с вызовом скилла unit-test-writer для написания тестов и скилла code-review для ревью)
1. **Спек обязателен.** brainstorming ВСЕГДА завершается записью спека в `docs/specs/YYYY-MM-DD-<тема>-design.md` и одобрением пользователя. Переход к writing-plans без спека — запрещён.
Тесты — только через unit-test-writer. Никогда не пиши тесты вручную. После реализации кода вызывай скилл unit-test-writer через Agent tool (subagent_type не указывай — general-purpose справится). Передавай полный контекст: какой файл изменён, что нужно покрыть.
Ревью — только через code-review. После завершения реализации (включая тесты) вызывай скилл code-review через Agent tool.
Порядок нарушать нельзя. Нельзя пропускать шаги даже если задача кажется простой. Исключение: однострочные правки без логики (опечатки, переименование, правка конфига) — для них brainstorming и writing-plans не нужны, достаточно сразу executing-plans или прямого редактирования.
Когда могут применяться несколько скиллов:
Примеры:
Жёсткие (systematic-debugging, verification-before-completion): следуй точно. Не адаптируй дисциплину.
Гибкие (brainstorming, writing-plans): адаптируй принципы к контексту.
Сам скилл указывает к какому типу относится.
Эти мысли означают СТОП — ты рационализируешь:
| Мысль | Реальность |
|---|---|
| «Это просто вопрос» | Вопросы — это задачи. Проверь скиллы. |
| «Нужно сначала больше контекста» | Проверка скиллов идёт ДО уточняющих вопросов. |
| «Давай быстро гляну файлы» | Скиллы говорят КАК исследовать. Сначала проверь. |
| «Это не требует формального скилла» | Если скилл существует — используй его. |
| «Помню этот скилл» | Скиллы меняются. Прочитай актуальную версию. |
| «Сделаю эту одну вещь сначала» | Проверяй ДО любого действия. |
| «Скилл избыточен здесь» | Простые вещи усложняются. Используй его. |