메뉴
Spec-first процесс для существенных фич — оркестратор: PRODUCT.md до реализации, TECH.md когда оправдан, реализация по утверждённым спекам. Использовать при старте значимой фичи, планировании агентной реализации или когда спеки нужно хранить в репозитории.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Когда нужна короткая демонстрация Agent Skill или проверка команд /skill: в этом проекте.
Реализация утверждённой фичи по PRODUCT.md и TECH.md с поддержанием спек и кода синхронными в одном PR. Использовать после утверждения спек, когда следующий шаг — сборка фичи. Канонический источник правил «спеки и код в одном PR» и «держи спеки актуальными».
Разрешение Git-конфликтов через компактные выжимки (хвосты ours/base/theirs и diff) вместо загрузки целых файлов в контекст. Использовать, когда merge, rebase, cherry-pick или stash pop остановились на конфликтах, git status показывает unmerged paths или в файлах есть маркеры конфликтов.
Ревью diff'а pull request с записью структурированного результата в review.json для публикации workflow'ом. Использовать при ревью выкачанного PR по локальным артефактам pr_diff.txt и pr_description.txt; в GitHub напрямую ничего не постится.
Исполняемый плейбук автономных прогонов roadmap — механика порций, процедура defer/отката, гигиена коммитов, критерии hard stop. Принципы и активация — в .vibe/rules/roadmap-autopilot.mdc.
Создание и обновление скиллов — генерация, правка и доводка SKILL.md. Использовать при авторинге новых скиллов или ревизии структуры, фронтматтера и инструкций существующих.
| name | spec-driven-implementation |
| description | Spec-first процесс для существенных фич — оркестратор: PRODUCT.md до реализации, TECH.md когда оправдан, реализация по утверждённым спекам. Использовать при старте значимой фичи, планировании агентной реализации или когда спеки нужно хранить в репозитории. |
Оркестратор spec-first процесса. Сам спеки не пишет — решает, нужны ли они, и ведёт по цепочке дочерних скиллов: write-product-spec → write-tech-spec → implement-specs.
specs/<id>/PRODUCT.md и specs/<id>/TECH.md, где <id> — номер тикета (PROJ-1234), GitHub issue с префиксом (gh-4567) или короткое kebab-case имя фичи.specs/ напрямую — только id-каталоги. Без подпапок по именам инженеров и без свободных слагов рядом с тикетами.Решительно за спеки, когда изменение существенное:
Спеки обычно не нужны: мелкие локальные багфиксы, прямолинейные рефакторинги, узкие UI-правки без неоднозначности. Для чисто UI-изменений продуктовая спека часто полезна, а техническая — нет.
write-product-spec → PRODUCT.md: проблема, желаемый пользовательский опыт, инварианты и edge cases. Есть UI — спросить про дизайн-мок до написания.write-tech-spec, если реализация затрагивает несколько подсистем, важна архитектура/расширяемость, есть осмысленные trade-off'ы или ревьюерам полезнее план, чем сырой код. Допустимо писать TECH.md после сквозного прототипа, если так план точнее; не выдавливать преждевременную спеку из неопределённости.implement-specs — сборка фичи по утверждённым спекам. Там же канонические правила: «спеки и код в одном PR», поддержание спек актуальными, опциональные PROJECT_LOG.md / DECISIONS.md, верификация против спек.write-product-spec, write-tech-spec, implement-specs