---
name: workflow-kit-implement
description: Реализация задач из tasks.json с учётом spec.md, plan.md и scope.md. По умолчанию выполняет одну следующую задачу; при явном yolo/batch-запросе может выполнять серию dependency-ready задач с батчингом проверок.
metadata:
  title: "Реализация задачи"
---

# Workflow Kit: implement

Имплементируй задачу для изменения: `$ARGUMENTS`.

Формат аргумента:

```text
{change-name} [task-id]
```

Если `task-id` не указан — в normal mode выбери первую незавершённую задачу из `tasks.json`, которую можно выполнить без нарушения зависимостей и подтверждений; в batch/yolo mode построй очередь таких задач.

Режимы исполнения:

- **Normal mode** — по умолчанию выполни одну маленькую задачу.
- **Batch / YOLO mode** — только если пользователь явно просит `yolo mode`, `batch`, `продолжай в yolo`, `делай все готовые задачи` или аналогично: выполняй цепочку dependency-ready задач до первого блокера.

Цель: сохранить соответствие `spec.md`/`plan.md`, обновить фактические статусы задач и записать проверки в `verification.md` без лишнего микрошума.

## Порядок работы

### 1. Найди workspace

Найди workspace:

- если `$ARGUMENTS` содержит путь к workspace, используй его;
- если `$ARGUMENTS` содержит `change-name`, найди `ai/specs/*_{change-name}/`;
- если совпадений несколько — выбери последний по timestamp или уточни;
- если workspace не найден — остановись и попроси путь или точный `change-name`.

В workspace должны быть:

- `tasks.json`;
- `plan.md`;
- `spec.md`;
- `scope.md`;
- `verification.md`.

Если любого из обязательных файлов нет — остановись и скажи, какой этап нужно выполнить перед implement.

### 2. Загрузи контекст до правок

Прочитай:

- `tasks.json`;
- `verification.md`;
- `scope.md`;
- `plan.md`;
- `spec.md`;
- `research.md`, если есть;
- `data-model.md`, если есть;
- project instructions, если они не были в контексте и влияют на реализацию;
- релевантные файлы текущей реализации для выбранной задачи.

Не используй старые `ai/specs/*`, `plan.md` или `tasks.json` из других workspaces как источник требований для этого change, если пользователь явно не указал связанный workspace.

### 3. Выбери задачу или batch

Перед выбором проверь, что `tasks.json` — валидный JSON.

- Если указан `Txxx` — работай только с задачей с таким `id`.
- Если `task-id` не указан и batch/yolo не запрошен — выбери первую задачу из `tasks[]` со `status: "pending"`, которую можно выполнить сейчас.
- Если явно запрошен batch/yolo — построй очередь из `pending` задач, которые dependency-ready и не требуют подтверждения; выполняй их по `execution.order` / `dependsOn`, пока не встретишь блокер.
- Проверь `dependsOn`, `confirmationRequired`, `confirmation`, `refs`, `files` и `checks` выбранной задачи или всех задач batch-очереди.
- Зависимость считается выполненной только если зависимая задача имеет `status: "done"` или обоснованный `status: "skipped"`; внутри batch зависимость может считаться выполненной после успешной реализации и проверки предыдущей задачи из той же очереди.

Остановись до правок, если:

- зависимость явно не выполнена и не будет выполнена ранее в той же batch-очереди;
- задача требует продуктового решения;
- `confirmationRequired: true`, а подтверждения ещё нет;
- задача требует файл из `Forbidden`;
- задача слишком крупная для одного прохода и требует декомпозиции.

В batch/yolo режиме не перескакивай через блокер к более поздним задачам, если это может исказить dependency chain или скрыть риск. Безопасные независимые задачи можно продолжать только если их `dependsOn` чистые и scope очевиден.

### 4. Проверь границы `scope.md`

Используй `scope.md` как границы редактирования:

- `Freely editable` — можно менять в рамках выбранной задачи;
- `Requires confirmation` — спроси перед изменением;
- `Forbidden` — не меняй;
- неуказанный файл — считай `Requires confirmation`, если изменение не очевидно локальное и напрямую не указано в `tasks.json`.

Останавливайся перед изменением public/shared surfaces: API, schema, migrations, config, generated files, shared data, если они не разрешены в `scope.md`.

Не делай «маленькую полезную правку» вне задачи. Это не инициатива, это scope creep.

### 5. Реализуй минимально

Для выбранной задачи или каждой задачи batch-очереди:

1. Уточни expected result из `tasks.json`, `plan.md`, `spec.md` и `verification.md`.
2. Прочитай существующие файлы перед изменением.
3. Внеси минимальные изменения только для текущей задачи.
4. Добавь/обнови тесты, если задача или plan это требует.
5. Запусти минимально достаточную проверку или более широкий covering-check, если он строго покрывает обязательные checks текущей задачи.
6. Запиши результат проверки в verification ledger / `verification.md`.
7. Обнови задачу в `tasks.json`: `status: "done"` только если обязательные проверки прошли или невозможность проверки явно объяснена в `verification.md`; иначе используй `blocked` или оставь `pending` с объяснением.

Не выполняй несколько независимых задач за один проход, если пользователь явно не попросил batch/yolo mode.

### 6. Обнови артефакты

После реализации обнови только нужное:

- `tasks.json` — обнови `status`, `verification.result`, `verification.evidence`, `verification.updatedAt` выбранной задачи или задач batch-очереди и не меняй смысл невыполненных задач без причины;
- `verification.md` — добавь фактический результат проверки;
- `implementation-fix.md` — создай или обнови только если обнаружен баг реализации, который не был покрыт задачами;
- `tasks.json` — добавь fix task только если это безопаснее, чем править сразу.

#### Batch artifact policy

В batch/yolo режиме можно батчить workflow updates:

- держи короткий verification ledger в памяти/черновых заметках во время выполнения;
- обновляй `tasks.json` и `verification.md` на checkpoint-ах, а не после каждого микрошага;
- checkpoint обязателен после группы связанных задач, перед рискованным переходом и в конце batch;
- после batched update один раз проверь `tasks.json` (`jq empty` или эквивалент);
- не запускай дублирующие проверки, если более поздняя/широкая команда строго покрывает предыдущую; в evidence явно пиши, чем покрыто;
- не ставь `done` задачам, чьи required checks ещё не прошли и не покрыты covering-check.

Если создаёшь `implementation-fix.md`, используй простой self-contained Markdown: контекст, баг, ожидаемое поведение, фактическое поведение, затронутые файлы, proposed fix, проверки.

Не переписывай `spec.md` или `plan.md` молча. Если они неверны или неполны — остановись и предложи обновление через соответствующий этап.

### 7. Implementation bug vs spec/plan bug

Если поведение не сходится:

- Если `spec.md` неверна или неполна — остановись и предложи вернуться к `workflow-kit-specify`.
- Если `plan.md` неверен или неполон — остановись и предложи вернуться к `workflow-kit-plan`.
- Если `tasks.json` неверен или неполон — остановись и предложи обновить tasks.
- Если spec/plan/tasks верны, но код не соответствует — исправь в рамках текущей задачи или создай `implementation-fix.md` / fix task.

Не искажай spec или plan, чтобы оправдать баг реализации.

### 8. Условия остановки

В normal и batch/yolo режимах одинаково остановись и сообщи пользователю, если:

- нужен файл из `Forbidden`;
- нужен файл из `Requires confirmation` без подтверждения;
- нужно изменить public API/schema/migration/config/generated/shared data без явного подтверждения;
- тесты падают и причина неочевидна;
- есть риск потери данных;
- нужна новая крупная зависимость;
- P1/P2 начинает пролезать в P0 без решения;
- задача слишком крупная и требует декомпозиции;
- требуется изменить `spec.md` или `plan.md`.

В batch/yolo режиме при остановке также укажи, какие задачи успели завершиться, какие проверки покрывают их `done`, и какая следующая pending-задача заблокирована.

### 9. Git и `.gitignore`

Нельзя добавлять в git файлы или директории, которые игнорируются `.gitignore`, без явного разрешения пользователя. Не используй `git add -f` для workflow artifacts.

Перед `git add`/commit проверь созданные и изменённые файлы одним из способов:

```bash
git check-ignore -v -- <path>
git status --short --ignored
```

Политика коммита:

- Не выполняй `git add`, commit или push без явного запроса пользователя.
- Если пользователь попросил подготовить commit, включай только атомарный результат выполненной задачи и обновлённые workflow artifacts, предварительно проверив `.gitignore`.
- Если workspace находится в ignored-директории, не добавляй его в git и явно скажи в финале: `workflow artifacts не закоммичены, потому что путь игнорируется .gitignore`.
- Не добавляй ignored-файлы без явного разрешения пользователя.

### 10. Результат после задачи или batch

Сообщай кратко:

```text
[T005] Завершена (`status: done`)

Файлы:
  + path/new-file
  ~ path/existing-file

Проверки:
  command — passed

Scope boundaries:
  все изменения в Freely editable / подтверждено: ...

Workflow artifacts:
  tasks.json updated
  verification.md updated

Прогресс: 5/12 done
Следующая: [T006] ...
```

Для batch/yolo результата сгруппируй задачи и проверки:

```text
Batch завершён: T002–T006 (`status: done`)

Проверки:
  ./gradlew :app:assembleDebug --quiet — passed (covers T003–T006)
  ./gradlew :app:testDevDebugUnitTest :app:testProdDebugUnitTest --quiet — passed (covers T002)

Workflow artifacts:
  tasks.json updated once after batch
  verification.md updated once after batch

Прогресс: 6/8 done
Следующая: [T007] ...
```

Если проверка не запускалась:

```text
Проверки:
  command — not run
  Причина: ...
  Риск: ...
```

Если остановилась до правок:

- назови выбранную/запрошенную задачу;
- объясни блокер;
- скажи, что нужно сделать дальше;
- явно укажи, что файлы не изменены.

## Связанные скиллы

- `workflow-kit-specify`
- `workflow-kit-plan`
- `workflow-kit-tasks`
- `workflow-kit-verify`