aif-task

# /aif-task — Full Task Lifecycle Полный цикл от таски до готового коммита в одном флоу: **ветка → план → реализация → verify → review → qa → changelog → squash-коммит** ## Шаг 0 — Получить имя таски Если имя таски передано аргументом — использовать его. Если не передано — спросить: ``` AskUserQuestion: Как называется таска? (имя станет названием ветки, например: DEV-204 или feature/my-task) ``` Имя таски = название ветки без изменений (не добавлять префиксов автоматически). ## Шаг 1 — Получить описание таски Спросить: ``` AskUserQuestion: Опиши задачу — что нужно сделать? (можно коротко или подробно) ``` Сохранить описание — оно станет входными данными для `/aif-plan`. ## Шаг 2 — Создать ветку Создать ветку с именем таски от текущей ветки: ```bash git checkout -b <task-name> ``` Если ветка уже существует — переключиться на неё и продолжить: ```bash 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: 1. Найти точку ветвления (первый коммит, отличающий эту ветку от базовой): ```bash git log --oneline ``` 2. Определить количество коммитов сделанных в этой ветке (N). 3. Выполнить soft reset до точки ветвления: ```bash git reset --soft HEAD~N ``` 4. Запустить `/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-трейлеров** в коммитах - **имя ветки = имя таски** — без авто-префиксов