--- name: take-task description: | Взять задачу в работу и запустить полный цикл разработки. Определяет размер (S/M/L), запускает агентов по пайплайну, проверяет quality gates. Use when: «возьми задачу», «давай делать», «начни работу над», «следующая задача», «take task» user-invocable: true disable-model-invocation: false argument-hint: "[task-id]" allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Agent, WebSearch --- # Взять задачу и запустить цикл разработки Аргумент: `$ARGUMENTS` — ID задачи (опционально). Если не указан — покажи доступные. ## Шаг 0. Checkpoint (восстановление после обрыва) 1. Прочитай `dev-infra/memory/checkpoint.yml` 2. Если `active: true` — предложи восстановление: ``` Обнаружен незавершённый checkpoint: - Задача: [task_id] — [task_title] - Последний шаг: [current_step] - Прогресс: [completed_steps / total_steps] Продолжить с [current_step] или начать заново? ``` 3. При продолжении — перейди к текущему шагу, загрузив контекст из checkpoint 4. При начале заново — очисти checkpoint (active: false) ## Если ID не указан 1. Прочитай `dev-infra/tasks/tasks.json` 2. Покажи задачи для текущего milestone со статусом `todo`, отсортированные по приоритету 3. Проверь зависимости: не предлагай задачу, если её dependencies не в статусе done 4. Для каждой: ID, название, приоритет, wave, дедлайн 5. Спроси, какую задачу взять ## Определение размера | Критерий | S (Small) | M (Medium) | L (Large) | |----------|-----------|------------|-----------| | Файлы | 1-2 | 3-5 | >5 или новый модуль | | AC | Нет или простые | Есть AC | Несколько AC + ПМИ | | Зависимости | 0-1 | 1-2 | 3+ | | Тип | Фикс, правка, конфиг | Новая функция | Новый модуль, архитектура | ``` Задача [ID]: [название] Размер: [S / M / L] — [обоснование] Пайплайн: [N шагов] ``` ## Обновить статус и создать план - tasks.json: статус -> `in_progress`, updated -> сегодня - active-context.md: обновить «Что делаем сейчас» - checkpoint.yml: ```yaml active: true task_id: [ID] task_title: [название] feature_size: [S/M/L] current_step: start started_at: [ISO-8601] steps: {} ``` - Создать прогресс-бар через TaskCreate по размеру **Для S (6 шагов):** ``` TaskCreate(subject="[ID] Реализация кода") TaskCreate(subject="[ID] Тесты + Inspector") TaskCreate(subject="[ID] Quick Review") TaskCreate(subject="[ID] Tech-debt проверка") TaskCreate(subject="[ID] Фиксация результата") ``` **Для M (8 шагов):** ``` TaskCreate(subject="[ID] Анализ требований") TaskCreate(subject="[ID] TDD — failing тесты (RED)") TaskCreate(subject="[ID] Реализация + тесты (GREEN)") TaskCreate(subject="[ID] Inspector — качество тестов") TaskCreate(subject="[ID] Код-ревью") TaskCreate(subject="[ID] Tech-debt проверка") TaskCreate(subject="[ID] Фиксация результата") ``` **Для L (10 шагов):** ``` TaskCreate(subject="[ID] Анализ требований") TaskCreate(subject="[ID] Архитектура + ревью плана") TaskCreate(subject="[ID] Reality Check (skeptic)") TaskCreate(subject="[ID] TDD + Код + Тесты (per-feature)") TaskCreate(subject="[ID] Inspector — качество тестов") TaskCreate(subject="[ID] Код-ревью") TaskCreate(subject="[ID] Tech-debt проверка") TaskCreate(subject="[ID] Фиксация результата") ``` --- ## Шаги пайплайна ### [1] Анализ требований (M, L) **Перед вызовом analyst:** 1. Прочитай tasks.json — извлеки задачу (description, acceptance_criteria, pmi_scenarios, risks) 2. Прочитай `dev-infra/tests/acceptance/` — найди конкретные метрики для AC 3. Прочитай `dev-infra/memory/tech-debt.md` — найди связанные TD-записи 4. Прочитай `dev-infra/memory/decisions.md` — найди связанные ADR ``` Agent(subagent_type="analyst", prompt=" Проанализируй задачу [ID]. Описание: [description] AC: [AC-X.X-XX — полная метрика, не только ID] PMI: [pmi-XX — описание] Риски: [R-XXX — описание, приоритет] Tech-debt: [TD-NNN — если связан] Решения: [ADR-NNN — если связан] ") ``` **Обработка verdict:** - `COMPLETE` -> показать результат пользователю, перейти к следующему шагу - `NEEDS_DISCOVERY` -> показать вопросы пользователю, дождаться ответа, зафиксировать в decisions.md, повторить analyst Checkpoint: `steps.analysis = {status: done, verdict: ..., key_findings: [...]}` ### Discovery (если NEEDS_DISCOVERY) 1. Покажи вопросы из analyst в формате: ``` Вопрос 1: [текст] Варианты: a) [вариант] — [trade-off] b) [вариант] — [trade-off] ``` 2. Дождись ответа пользователя 3. Зафиксируй решение в `dev-infra/memory/decisions.md` (формат ADR) 4. Повторно вызови analyst с дополненным контекстом ### [2] Архитектура + ревью плана (L) Запусти параллельно: ``` Agent(subagent_type="architect", prompt=" Спроектируй [модуль]. Требования от аналитика: [результат analyst]. Верни: структуру файлов, API-контракты, модели, стратегию контроля доступа. Раздели на features для per-feature loop (с порядком по зависимостям). ") Agent(subagent_type="reviewer", prompt=" mode: plan_review Проверь план архитектора на полноту. Требования: [результат analyst]. AC: [полные метрики] Риски: [R-XXX с описанием] ") ``` **Обработка verdict (комбинация):** - architect(READY) + reviewer(APPROVE) -> показать пользователю, ждать подтверждения - architect(READY) + reviewer(REQUEST_CHANGES) -> architect исправляет -> повторить оба - architect(NEEDS_INPUT) -> запросить данные -> повторить Checkpoint: `steps.architecture = {status: done, plan_summary: "...", files: [...]}` ### [3] Reality Check (L) ``` Agent(subagent_type="skeptic", prompt=" Проверь спецификацию на миражи: [план от architect]. Кодовая база: <%= srcDir %> ") ``` **Обработка verdict:** - `PASS` -> продолжить - `PASS_WITH_WARNINGS` -> передать warnings developer'у в prompt - `FAIL` -> вернуть architect, показать issues Checkpoint: `steps.skeptic = {status: done, verdict: ..., warnings: [...]}` ### [4] TDD — failing тесты, RED (M, L) Для M-задач — один вызов. Для L — per-feature. ``` Agent(subagent_type="tester", prompt=" mode: tdd Создай failing тесты для [фича/задача]. TDD-якоря: [tdd_anchors из tasks.json] Директория тестов: <%= testDir %> Фреймворк: <%= testFramework %> Тесты должны FAIL (код ещё не написан). ") ``` Проверь: тесты действительно fail. Если pass — значит якоря некорректны. ```bash <%= testCommand %> ``` Checkpoint: `steps.tdd = {status: done, failing_tests: [...]}` ### [5] Реализация + тесты (per-feature) **Для S-задач:** один цикл developer -> tester -> inspector. **Для M-задач:** developer -> tester(GREEN) -> inspector. **Для L-задач:** per-feature loop из плана architect. Per-feature loop (L): ``` features = план architect -> details.features (упорядочены по зависимостям) for feature in features: # 1. Developer реализует Agent(subagent_type="developer", prompt=" Реализуй [feature]. План: [план]. Warnings от skeptic: [если есть]. TDD: сделай failing тесты GREEN. Failing тесты: [список из шага TDD]. Запусти: <%= testCommand %> ") # Проверка verdict developer if developer.verdict == BLOCKED: -> показать пользователю, разобрать блокировку # 2. Tester проверяет Agent(subagent_type="tester", prompt=" level: unit Проверь [конкретные файлы feature]. Убедись: failing тесты теперь GREEN. Добавь edge cases сверх TDD-якорей. Покрытие >=80%. Фреймворк: <%= testFramework %> Запусти: <%= testCommand %> ") # Проверка verdict tester if tester.verdict == FAIL: -> передать developer для исправления -> повторить tester # 3. Inspector проверяет качество тестов Agent(subagent_type="inspector", prompt=" Проверь качество тестов для [feature]. Файлы: [тестовые файлы от tester]. ") # Проверка verdict inspector if inspector.verdict == REQUEST_CHANGES: -> передать tester для исправления -> повторить inspector Checkpoint: steps.developer.features_done += 1 ``` Checkpoint: `steps.developer = {status: done, files_changed: [...], features_done: N, features_total: N}` ### [6] Ревью (S. quick, M/L. full) **S-задачи (quick review):** ``` Agent(subagent_type="reviewer", prompt=" mode: quick Проверь: [файлы от developer]. Только: security, контроль доступа, критические баги. 1 раунд, MEDIUM/LOW -> tech-debt. ") ``` **M/L-задачи (full review):** ``` Agent(subagent_type="reviewer", prompt=" Проверь код: [файлы от developer]. AC: [полные метрики из tasks.json — НЕ только ID] Риски: [R-XXX с описанием] Раунд: 1/3. ") ``` **Обработка verdict:** - `APPROVE` -> перейти к tech-debt - `REQUEST_CHANGES` (раунд 1-2) -> developer исправляет -> reviewer повторяет (раунд N+1) - `ESCALATE` (раунд 3) -> показать пользователю все findings -> 3 варианта: - (a) Принять как tech-debt -> TD-NNN - (b) Исправить вручную -> повторить ревью - (c) Отменить задачу -> rollback Checkpoint: `steps.review = {status: done, round: N, verdict: ..., findings_count: N}` ### [7] Tech-debt проверка (ВСЕ размеры) Team Lead проверяет 3 источника: 1. **Reviewer findings** — MEDIUM/LOW не исправленные в этой задаче 2. **Implementation deviations** — ищи в коде: mock, simplified, workaround, deferred, TODO, FIXME, HACK 3. **Skeptic warnings** (L) — не адресованные в коде Если найдено -> добавить TD-NNN в `dev-infra/memory/tech-debt.md`. Если нет -> `tech_debt: none` в checkpoint. ### [8] Фиксация 1. Покажи пользователю итог: что сделано, файлы, тесты, ревью, tech-debt 2. Обнови tasks.json: status -> done, updated -> сегодня 3. Обнови progress.md: пересчитать прогресс milestone 4. Обнови active-context.md: убрать задачу, добавить результат 5. Очисти checkpoint: `active: false` 6. Предложи коммит ## Linear Sync > Non-blocking. Если Linear MCP недоступен или linear-mapping.json не настроен — пропустить. 1. Проверь наличие `dev-infra/config/linear-mapping.json` и что `linear.team` заполнен 2. Если задача имеет `linear_id` — обнови issue: - State → «In Progress» (через status_map) 3. Если задача не имеет `linear_id` — пропустить (будет создан при полном sync)