1t1sCooL /aif-task — Full Task Lifecycle
Полный цикл от таски до готового коммита в одном флоу: ветка → план → реализация → verify → review → qa → changelog → squash-коммит
Шаг 0 — Получить имя таски
Если имя таски передано аргументом — использовать его.
Если не передано — спросить:
AskUserQuestion: Как называется таска? (имя станет названием ветки, например: DEV-204 или feature/my-task)
Имя таски = название ветки без изменений (не добавлять префиксов автоматически).
Шаг 1 — Получить описание таски
Спросить:
AskUserQuestion: Опиши задачу — что нужно сделать? (можно коротко или подробно)
Сохранить описание — оно станет входными данными для /aif-plan.
Шаг 2 — Создать ветку
Создать ветку с именем таски от текущей ветки:
git checkout -b <task-name>
Если ветка уже существует — переключиться на неё и продолжить:
git checkout <task-name>
Сообщить пользователю: Ветка <task-name> создана. Начинаем планирование.
Шаг 3 — Планирование (/aif-plan)
Запустить /aif-plan в fast режиме с описанием из Шага 1.
При вопросах aif-plan о настройках:
- Тесты: спросить пользователя
- Логирование: verbose по умолчанию
- Docs: warn-only
- Roadmap: skip
План сохраняется в .ai-factory/PLAN.md.
Шаг 4 — Реализация (/aif-implement)
Запустить /aif-implement для выполнения всех задач из плана.
Выполнять задачи последовательно. Не останавливаться без причины.
Шаг 5 — Verify (/aif-verify) — ОБЯЗАТЕЛЬНО
Запустить /aif-verify.
Если verify упал — исправить найденные проблемы и повторить verify. Не переходить к следующему шагу пока verify не пройдёт.
Шаг 6 — Review (/aif-review) — ОБЯЗАТЕЛЬНО
Запустить /aif-review на изменениях ветки.
Если review нашёл критические issues — исправить и перезапустить review. Стилистические замечания — задокументировать, но не блокируют переход.
Шаг 7 — QA-приёмка (/qa) — ОБЯЗАТЕЛЬНО
Запустить скилл /qa (глобальный, ~/.claude/skills/qa/SKILL.md): приёмка
реализации против исходного описания таски (Шаг 1) и ТЗ, если оно есть.
Что проверяет qa (сверх verify/review): SSR HTML через view-source (не DOM), HTTP-коды и редиректы, sitemap/robots, живой рендер в браузере (Playwright) на отдельном порту, computed-styles diff с эталоном.
Если qa нашёл FAIL — исправить, добавить регресс-тест на каждый баг и перезапустить qa. QUESTION-пункты (расхождения с ТЗ, решаемые автором ТЗ) — задокументировать в итоговой сводке, кодом не чинить, переход не блокируют.
Шаг 8 — Changelog (/aif-changelog) — ОБЯЗАТЕЛЬНО
Запустить /aif-changelog.
Changelog обновляется автоматически на основе коммитов в текущей ветке.
Шаг 9 — Squash и финальный коммит (/aif-commit) — ОБЯЗАТЕЛЬНО
Все коммиты ветки сквошить в один перед финальным коммитом.
Процедура squash:
- Найти точку ветвления (первый коммит, отличающий эту ветку от базовой):
git log --oneline
Определить количество коммитов сделанных в этой ветке (N).
Выполнить soft reset до точки ветвления:
git reset --soft HEAD~N
- Запустить
/aif-commit— он сформирует один финальный conventional commit message по всем staged изменениям.
Правила финального коммита:
- Один коммит покрывает всю работу по таске
- Сообщение по Conventional Commits:
type(scope): subject - Никакого
Co-Authored-Byи любых AI-трейлеров — запрещено
Шаг 10 — Итог
Вывести итоговую сводку:
✅ Таска <task-name> завершена
Ветка: <task-name>
Коммит: <hash> <message>
Verify: ✅ пройден
Review: ✅ пройден
QA: ✅ пройден (N багов починено, M вопросов к автору ТЗ)
Changelog: ✅ обновлён
Следующий шаг: создай MR из <task-name> → <base-branch>
Правила
- verify, review и qa обязательны — нельзя пропустить или проигнорировать
- changelog обязателен — всегда обновлять перед финальным коммитом
- один squash-коммит — вся работа по таске в одном коммите
- без AI-трейлеров в коммитах
- имя ветки = имя таски — без авто-префиксов