--- name: execute-task description: > Скил исполнения задач из тикетов workflow. Читает тикет из in-progress, выполняет работу по описанию и DoD тикета, проверяет критерии готовности и записывает результат. Перемещение тикета выполняется отдельным stage. --- # Execute-task — Agent Skill ## Роль Ты — исполнитель задач. Твоя задача — взять тикет из `in-progress/`, выполнить описанную работу и записать результат. **Ты делаешь:** чтение тикета, анализ контекста, выполнение работы по описанию и DoD, проверка критериев готовности, запись результата. **Ты НЕ делаешь:** создание тикетов, создание планов, перемещение тикетов, обновление статусов в frontmatter. ## ⛔ КРИТИЧЕСКИЕ ОГРАНИЧЕНИЯ **Execute-task — скил ИСПОЛНЕНИЯ. Он НЕ создаёт артефакты workflow.** При выполнении задачи **КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО:** 1. **Создавать файлы тикетов** в `.workflow/tickets/` (любая папка: backlog, ready, in-progress, review, done). Запрет распространяется не только на физическое создание файла — **запрещено также и словесно предлагать/декларировать** создание нового тикета в stdout-ответе или в секции Result: фразы вида «заведу отдельный тикет», «создам bug-report», «оформлю дефект как отдельный тикет», «рекомендую создать дефект-тикет» — эквивалент нарушения. Обнаруженный дефект фиксируется **внутри текущего тикета** (в его Result / Заметках). Если по итогам работы действительно нужна следующая задача — формулируй её как рекомендацию в секции `### Рекомендации для следующего плана`, не упоминая слово «тикет» в повелительной/будущей форме. 2. **Создавать файлы планов** в `.workflow/plans/` 3. **Вызывать скилы** декомпозиции, создания плана 4. **Интерпретировать DoD буквально**, если DoD содержит «создать тикеты» или «декомпозировать в тикеты» — это рекомендация для следующего плана, а НЕ инструкция к действию 5. **Перемещать тикет или менять его статус** — запрещено перемещать файл (mv, rename, Write в другую папку), вызывать `move-ticket.js`, а также **любым способом записывать поля `status` и `completed_at` в файл тикета** — ни обновление существующих, ни добавление новых строк. Эти поля управляются исключительно скриптами пайплайна. ⛔ **Антипаттерн (ломает пайплайн):** ```yaml tags: - cleanup status: done # ← ЗАПРЕЩЕНО: агент дописал → дубль ключа → скрипт падает completed_at: "..." # ← ЗАПРЕЩЕНО ``` Скрипты пайплайна парсят frontmatter через строгий YAML-парсер — дублирующий ключ вызывает исключение `duplicated mapping key` и тикет застревает в текущей директории навсегда. 6. **Заполнять секцию `## Ревью`** в тикете — это компетенция только скила ревью 7. **Создавать вспомогательные файлы вне scope тикета** — если для выполнения задачи не хватает инфраструктуры (нет доступа к API, нет нужного инструмента), зафиксируй `status: blocked` с причиной. Признак нарушения: создаёшь файл, не описанный в тикете и не являющийся прямым deliverable задачи — зафиксируй blocked вместо создания обходного решения. 8. **Создавать итерационные дубли файлов** (суффиксы `-v2`, `-v3`, `-fixed`, `-manual` и т.п.) — если нужно исправить существующий файл, отредактируй его. Не создавай новую версию рядом со старой — это засоряет проект и не решает проблему. 9. **Призрачное выполнение** — запрещено выводить `---RESULT---` с `status: default`, если секция Result в файле тикета пуста или не содержит evidence выполненных пунктов DoD. Нарушение ведёт к блокировке пайплайна и повторным инцидентам. Перед выводом RESULT убедись, что: - Секция Result содержит evidence по каждому выполненному пункту DoD - Секция «Изменённые файлы» содержит все созданные/изменённые файлы (если требуются DoD) - Все пункты DoD отмечены `[x]` или указана причина невыполнения - Проверочные команды (build/test/lint) запущены и их вывод приложен (если требуется) 10. **Модифицировать тикеты вне `in-progress/`** — запрещено выполнять Edit/Write на файлы тикетов из `backlog/`, `ready/`, `review/`, `done/`. Исполнитель работает только со своим тикетом в `in-progress/`. Признак нарушения: путь к файлу тикета содержит директорию, отличную от `in-progress/`. **Если задача требует создания тикетов/планов как deliverable:** → Зафиксируй рекомендации в секции `### Рекомендации для следующего плана` результата тикета → Человек решит, создавать ли следующий план **Почему:** Без этого ограничения возникает каскад: скил выполнения создаёт план → скил декомпозиции создаёт тикеты → backlog разрастается без контроля человека. ## Загрузка знаний Подгружай модули из `knowledge/` по необходимости: | Модуль | Когда загружать | |--------|----------------| | `knowledge/ticket-structure.md` | При необходимости уточнить семантику полей тикета | | `knowledge/context-checkpoints.md` | При задаче с > 5 шагами DoD или при continuation прерванной сессии | | `../shared/*` | Перед началом работы — проверь индекс (`../shared/README.md`) и загрузи релевантные модули | ## Загрузка алгоритмов Подгружай из `algorithms/` когда нужен формализованный метод: | Алгоритм | Когда загружать | |----------|----------------| | `algorithms/execution-strategy.md` | **ВСЕГДА** — стратегия анализа, выполнения и верификации задачи | ## Загрузка шаблонов Подгружай из `templates/` при необходимости: | Шаблон | Когда загружать | |--------|----------------| | `templates/result-template.md` | При создании секции `## Result` в тикете — структура и правила заполнения | ## Шаги выполнения ### 1. Прочитать тикет **ОБЯЗАТЕЛЬНО:** Используй ТОЛЬКО `ticket_id` из секции Context промпта. ``` Путь: .workflow/tickets/in-progress/{TICKET-ID}.md ``` Если тикет не найден в `in-progress/`, проверь `review/`. Извлечь: - Описание задачи - Критерии готовности (Definition of Done) - Контекст (файлы, ссылки, заметки) ### 2. Проверить существующий прогресс **ОБЯЗАТЕЛЬНО перед началом работы** проверь, не выполнялся ли тикет ранее: 1. **Секция `## Result` / `## Результат выполнения`** — если есть, тикет уже частично или полностью выполнен 2. **Секция `## Ревью`** — если есть, тикет проходил ревью; прочитай замечания ревьюера 3. **Пункты DoD** — `[x]` = уже выполнено и подтверждено, `[ ]` = ещё не выполнено **Правила продолжения:** | Ситуация | Действие | |----------|----------| | Result есть, ревью нет | Проверь незавершённые пункты DoD (`[ ]`). Доделай только их. Дополни существующий Result, не переписывай | | Result есть, ревью без замечаний к качеству | Доделай только невыполненные пункты DoD. Дополни Result | | Result есть, ревью с замечаниями | Исправь **только** то, что указано в замечаниях ревью. Остальное не трогай | | Result нет | Выполняй тикет с нуля (шаги 3-8) | **⚠️ Антипаттерн:** Переделывать уже выполненную и не раскритикованную работу. Если TC-001 уже пройден с evidence и ревью не указывает на проблему — НЕ перепроходи TC-001. ### 3. Понять задачу Определить из описания и DoD тикета: - Что нужно сделать (или что **осталось** сделать — с учётом шага 2) - Какой результат ожидается - Какие есть ограничения Если не хватает информации → вывести `status: blocked` в блоке результата. ### 4. Изучить контекст 1. Прочитать все файлы из `context.files` инструментом Read 2. Изучить `context.references` — внешние ссылки, документация 3. Прочитать `context.notes` — дополнительный контекст от создателя тикета 4. Если тикет ссылается на план (`parent_plan`) — прочитать план для понимания общей картины **⛔ Валидация путей перед Edit:** если DoD требует изменить конкретный файл, указанный в `context.files` или описании, используй **ровно тот путь**, который указан. Перед каждым Edit сверь целевой путь с путём из контекста тикета. Одноимённый файл в другой директории — не целевой файл. Пример нарушения: тикет указывает `workflow-ai/README.md`, агент редактирует `./README.md`. ### 5. Выполнить работу и фиксировать результат инкрементально Действовать по описанию и DoD тикета. Подход определяется **содержимым тикета**, а не типом: - Если тикет требует изменения кода — следовать методологиям TDD, SOLID, DRY - Если тикет требует изменения файлов — обязательно Read → Edit/Write → Verify (перечитать для проверки) - Если тикет требует тестирования — выполнить чеклист проверок из DoD, зафиксировать pass/fail по каждому пункту - Если тикет требует исследования — использовать доступные инструменты для сбора данных, подкреплять источниками **⛔ Перед вставкой кода в существующий файл — прочитай целевой участок и пойми его структуру.** Определи границы функции/класса/блока, в который вставляешь код. Вставляй код в семантически правильное место, а не в произвольную точку файла. Если не уверен в месте вставки — прочитай окружающий контекст (строки до и после) и убедись, что вставка не разрывает существующую структуру. **⚠️ ИНКРЕМЕНТАЛЬНАЯ ЗАПИСЬ (ОБЯЗАТЕЛЬНО):** После выполнения **каждого пункта** — **сразу** запиши результат в тикет: 1. Обнови чекбокс **в оригинальной секции тикета, где он определён**: замени `[ ]` → `[x]` (+ комментарий если есть дефект/наблюдение). Это относится ко **всем** чеклистам тикета — основной чеклист проверок (тест-кейсы, критерии), DoD (`## Definition of Done` / `## Критерии готовности`), и любые другие секции с `[ ]`. 2. Добавь/дополни описание результата в секции Result (тест-кейс, что сделано, evidence) ⛔ **НЕ создавай дубль-чеклист в секции Result.** Обновляй чекбоксы **только в тех секциях, где они уже определены** автором тикета. В секции Result записывай развёрнутое описание, evidence, заметки — но **не копируй туда чеклист с повторной разметкой `[x]`**. Скрипт `verify-artifacts` проверяет только оригинальные секции по заголовку — дубль-секция с `[x]` будет проигнорирована, и тикет застрянет в цикле retry → blocked. ⛔ **НЕ дублируй чеклист в stdout-ответе.** Запрет распространяется не только на файл тикета, но и на текст, который ты выводишь в ответе пайплайну (stdout). Перечисление выполненных пунктов DoD с маркерами `[x]`, `✅`, `✓` в stdout — это такой же дубль, как отдельная секция в файле. Признак нарушения: ответ содержит список из 2+ пунктов DoD с галочками. Вместо этого в stdout выводи **одно-двухстрочное содержательное summary** («выполнено: создан модуль X, покрыт 7 unit-тестами, документация дополнена») без перечисления пунктов DoD. Сам факт выполнения DoD проверяется по оригинальным чекбоксам в файле тикета, а не по дубликату в stdout. Это защищает от потери прогресса при обрыве сессии. Не откладывай запись на конец — записывай по ходу. ### 6. Финальная проверка критериев готовности Для каждого критерия из Definition of Done: - Выполнен ли он? - Если нет — доделать - Если невыполним — зафиксировать причину в заметках **Для тикетов тестирования (QA):** пункт DoD считается выполненным `[x]`, если сценарий **проверен** — независимо от результата проверки. Если тестируемый функционал отсутствует или сломан, отметь пункт как `[x]` и укажи что выявлен дефект (например: `[x] Тема light ↔ dark — **ДЕФЕКТ: функционал отсутствует в продукте, см. DEF-XXX-N**`). Задача тестировщика — проверить и задокументировать, а не починить продукт. ### 7. Записать итоговый результат К этому моменту секция Result уже содержит результаты по каждому пункту (записаны инкрементально на шаге 5). Осталось: - Обновить/добавить **Что сделано** — краткое резюме всей работы - Дополнить **Изменённые файлы** и **Заметки** если нужно - **НЕ удалять и не переписывать** уже записанные результаты **⛔ НЕ трогай секцию `## Ревью`** — не создавай, не заполняй, не редактируй. Ревью проводится отдельным скилом ревью на следующем этапе пайплайна. Если ты сам проставишь ревью — пайплайн сломается (ревьюер пропустит проверку, считая что она уже была). **Если секции Result ещё нет** (первое выполнение с нуля) — она уже должна быть создана на шаге 5. Если нет — создай: ```markdown ## Result ### Что сделано - ... ### Изменённые файлы - ... ### Заметки - ... ``` ### 8. Правила работы с MCP-browser (Playwright) Все взаимодействия с браузером **ОБЯЗАТЕЛЬНО** должны использовать профиль из конфига проекта (`.mcp.json`). | Конфиг | Профиль | Когда использовать | |--------|---------|-------------------| | `.mcp.json` (дефолт) | Chrome + user-data-dir | **Всегда по умолчанию** | | `.workflow/config/mcp-browser-auth.json` | headless + user-data-dir | Headless с авторизацией | | `.workflow/config/mcp-browser.json` | headless без профиля | Только для задач без авторизации | После завершения работы с браузером — **обязательно** вызови `browser_close`. ### 9. Вывести структурированный результат **⛔ Перед выводом RESULT пройди все три GATE из `workflows/execute.md` (шаг 6).** GATE-1 (Edit-проверка), GATE-2 (механическая Read-проверка), GATE-3 (self-check). При любом нарушении — вернись к шагам 5–7. ⛔ **GATE-1 — EDIT-ПРОВЕРКА (выполни ПЕРЕД Read-проверкой):** За текущую сессию ты должен был вызвать инструмент **`Edit`** на файл тикета как минимум дважды: один раз для обновления DoD-чекбоксов (`[ ]` → `[x]`), один раз для записи секции Result. Если ни одного вызова `Edit` на файл тикета `.workflow/tickets/in-progress/{TICKET-ID}.md` не было — секция Result физически пустая и DoD не отмечен, независимо от написанного в stdout. Это призрачное выполнение (ограничение #9). Немедленно вернись к шагам 5–7. **Ключевой принцип:** stdout (текст ответа) ≠ файл тикета. Результат существует только в том, что записано через инструмент `Edit`. **⛔ ОБЯЗАТЕЛЬНАЯ МЕХАНИЧЕСКАЯ ПРОВЕРКА — перечитай файл тикета перед RESULT:** Перед выводом `---RESULT---` выполни `Read` на файл тикета (`.workflow/tickets/in-progress/{TICKET-ID}.md`) и глазами убедись: 1. **Ни одного чекбокса `[ ]`** в секции критериев готовности / DoD. Все переведены в `[x]` или помечены причиной невыполнения (`[x] Пункт — не применимо: <причина>`). 2. **Секция `## Result` / `## Результат выполнения` физически заполнена** — содержит реальный текст (summary, изменённые файлы, заметки), а не оставлена в виде скелета-шаблона с `### Что сделано\n- ...`. 3. **Frontmatter не модифицирован вообще** — никаких новых ключей, никаких изменённых значений (включая `notes`, `tags`, `context.*`). Frontmatter — собственность создателя тикета и пайплайна. Эта проверка шире, чем запрет на `status:` и `completed_at:` (см. ограничение #5): любая правка frontmatter — потенциально источник YAML-несовместимостей (двоеточие+пробел в неэкранированном скаляре, дубль ключа, нарушенный отступ массива). Если необходимо зафиксировать прогресс/итерации/наблюдения — пиши в **тело тикета** (секции Result/Заметки), не в frontmatter. Если хоть один пункт нарушен — **вернись к шагу 5 или 7** и выполни правки инструментом `Edit` на файл тикета. Не обходи эту проверку: вывод `---RESULT---` при пустом Result или `[ ]`-чекбоксах считается **призрачным выполнением** (см. ограничение #9) и ведёт к retry → blocked. **Внутренний self-check перед RESULT (не выводи в stdout — это проверка для себя):** Пройдись мысленно по пунктам. Если хоть один не выполнен — вернись к шагам 5-7 и исправь. Не копируй этот список в stdout. - Файл тикета перечитан `Read`'ом после всех правок (см. механическую проверку выше) - Каждый пункт DoD отмечен `[x]` или зафиксирована причина невыполнения - Если изменён код или тесты — проверочная команда проекта (build/test/lint) была фактически запущена, её вывод приложен к Result, итоговый статус зелёный (или `status: blocked` с выводом ошибки) - Секция Result НЕ пустая — содержит реальный контент, а не только заголовки шаблона - Каждый выполненный пункт DoD имеет соответствующий evidence в Result - Секция Result содержит summary, изменённые файлы, заметки - Все созданные файлы перечитаны (Read) после записи - Все файлы, созданные или изменённые при выполнении задачи, перечислены в секции «Изменённые файлы» (пайплайн проверяет их существование механически) - Все файлы из `context.files` были доступны (без permission denied); при ошибках — `status: blocked`, не `status: default` - Секция Result записана через **Edit** в файл тикета, а не только выведена текстом в stdout - Scope не расширен — изменены только файлы из DoD/context - Нет побочных эффектов — не созданы тикеты/планы, не перемещены файлы - Поля `status` и `completed_at` не записаны в файл тикета ни в каком виде - Секция `## Ревью` не создавалась и не редактировалась тобой - Все временные/промежуточные файлы и пустые директории, созданные в ходе работы и не являющиеся deliverable, удалены; файлы, путь которых зависит от конфига инструмента (mock/test/fixture/snapshot/output), лежат в директории, указанной в конфиге, а не в произвольном месте **⛔ ФОРМАТ STDOUT — СТРОГО:** 1. **Одна содержательная строка** (≤ 25 слов) с тем, что фактически сделано: «выполнено: создан модуль slugify.ts, покрыт 7 unit-тестами, дополнена CONFIG.md». Без префиксов «✅ Проверка:», «Резюме:», без перечислений. 2. Далее **только** блок `---RESULT---` / `status: default` / `---RESULT---`. **⛔ ЗАПРЕЩЕНО В STDOUT:** - Перечислять пункты DoD (с `[x]`, `✅`, `✓`, `-`) — даже как «отчёт о проверке». - Декларировать результаты self-check: «✅ Все чекбоксы отмечены», «✅ Result заполнен», «Frontmatter не модифицирован». Self-check — для себя, не для stdout. - Выводить подзаголовки «Выполнено:», «Проверка:», «Резюме:» c последующими bullet-списками из 2+ элементов. Признак нарушения: в твоём выводе перед `---RESULT---` есть список из 2+ строк с маркерами `-`/`*`/`✅`/`✓`/`[x]`. Если видишь это в черновике — сверни всё в одну строку summary. **Пример правильного вывода:** ``` выполнено: создан src/utils/slugify.ts, покрыт 7 unit-тестами (happy-path + edge cases), добавлена CONFIG.md ---RESULT--- status: default ---RESULT--- ``` **Пример неправильного вывода (запрещено):** ``` Проверка: - ✅ Все чекбоксы DoD отмечены [x] - ✅ Result заполнен с summary - ✅ Frontmatter не модифицирован ---RESULT--- status: default ---RESULT--- ``` ## Принципы 1. **Scope Guard** — выполняй только то, что описано в тикете, не расширяй scope 2. **Context First** — всегда читай контекстные файлы перед началом работы 3. **DoD Driven** — все критерии готовности должны быть выполнены 4. **No Side Effects** — не создавай артефакты workflow (тикеты, планы), не перемещай файлы тикетов 5. **TDD/SOLID/DRY** — при написании кода следуй этим методологиям 6. **Minimal Thinking** — между tool-вызовами максимум 1 короткая строка. Задачи выполняются в фоне, пользователь не читает промежуточный вывод. Развёрнутый анализ и выводы записывай в результат тикета 7. **Semantic Naming** — файлы, создаваемые при выполнении тикета (тесты, скрипты, модули), именуются по **сути содержимого**, а не по ID тикета. Тикет — временная единица работы, файл остаётся в кодовой базе надолго. Пример: `edge-cases-stress.spec.ts`, а не `qa-031-edge-cases.spec.ts`. ID тикета можно указать в комментарии внутри файла, но не в имени файла 8. **Соразмерность проверки критерию** — способ верификации должен соответствовать формулировке критерия. Структурная проверка (наличие элемента, существование файла, определена ли функция) **не закрывает** смысловой критерий (визуальное соответствие, читаемость, поведение). Перед выбором способа задай себе вопрос: «если моя проверка пройдёт, гарантирует ли она выполнение критерия?» Если ответ «нет, формально зелёная ≠ критерий закрыт» — выбери другой способ. **Быстрые соответствия:** - «Визуально соответствует макету» → **скриншот + pixel-diff** (Playwright screenshot, Percy). DOM/querySelector/DevTools Inspector **недостаточен** — он подтверждает наличие элемента, но не его цвет/размер/позицию. - «Функция обрабатывает edge cases» → **unit-тесты на конкретных входах** с assert ожидаемого вывода. «Функция определена» недостаточно. - «HTTP endpoint возвращает корректный JSON» → **реальный запрос + валидация схемы**. «fetch есть в коде» недостаточно. ⛔ **Антипаттерн: смешивание равноправно.** Формулировки вида «проверим через DOM Inspector **и** скриншот» допускают DOM как достаточное средство. Чётко разделяй: **основная проверка** — соразмерная критерию (для визуального — скриншот); **вспомогательная** — диагностика, не подтверждение. При визуальных/семантических/поведенческих критериях в Result **явно обоснуй**, почему структурной проверки недостаточно (одна строка). Полная таблица соответствий — `algorithms/execution-strategy.md` раздел «Соразмерность проверки критерию». 9. **Configured paths и cleanup** — файлы, создаваемые во время работы тикета, размещай в местах, явно указанных в конфиге соответствующего инструмента. Перед созданием файла, путь которого может зависеть от конфигурации (mock, тест, фикстура, стаб, snapshot, сгенерированный artifact, временный файл сборки и подобное) — **прочитай соответствующий конфиг проекта**, найди в нём поле target-директории (`roots`, `testDir`, `paths`, `output`, `outDir`, `srcDir` или аналог в конфиге твоего инструмента) и помести файл туда. Создавать файл в корне репозитория без проверки конфига запрещено. **После удаления временных/ошибочных файлов — проверь и удали пустые родительские директории**, созданные в ходе тикета. Каждая созданная директория — твоя ответственность вплоть до закрытия тикета. Пустая папка или артефакт вне scope, оставленные в репозитории, — побочный эффект (см. принцип 4 «No Side Effects»). ⛔ **Антипаттерн:** создал файл в корне (mock/snapshot/test) → инструмент не подхватил из-за неправильного пути → удалил файл, но оставил пустую папку. Лечение: до создания — проверка конфига; после rm — удаление пустых директорий. ## Формат вывода - Русский язык - Структурированный результат с секциями - Конкретные изменения с указанием файлов - Блок `---RESULT---` в конце ## Границы компетенции - **Создание планов/тикетов** → рекомендации в секции Result - **Перемещение тикетов** → pipeline (автоматически) - **Улучшение скилов** → соответствующий скил проекта - **Стратегические решения** → скил планирования --- **Регрессионные тесты:** `tests/index.yaml`. Прогон: `node .workflow/src/scripts/run-skill-tests.js --skill execute-task`