[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MX2P8RFYPV4EXRMVW6KAN7":3,"skill-same:01M6MX2P8RFYPV4EXRMVW6KAN7":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":24,"linkOnly":25,"markdownContent":26,"markdownBody":27,"frontMatter":28,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":33,"repositoryHtmlUrl":34,"repositoryHomepageUrl":6,"ownerHtmlUrl":35,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":36,"install":37,"resources":50},"01M6MX2P8RFYPV4EXRMVW6KAN7","solve",null,"Solve — полный цикл решения задачи из YouTrack: preflight → анализ → план → реализация → ревью → коммит. Используй при любой YouTrack-задаче (`\u002Fsolve PLF-819`); флаг `--fast` сокращает HITL для тривиальных багфиксов.","vmkteam\u002Fclaude-plugins","vmkteam","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F55537877?v=4","01M6MWYAFDCD63N1M8MBJA6T0S","01M6MWYAKHK0QCPR0Y7AW5SH0R",7,"MIT","https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Fsolve\u002FSKILL.md",[],[5,18,19,20,21,22,23],"fast","preflight","task","hitl","id","youtrack","2026-11-10 10:12:30",false,"---\nname: solve\ndescription: \"Solve — полный цикл решения задачи из YouTrack: preflight → анализ → план → реализация → ревью → коммит. Используй при любой YouTrack-задаче (`\u002Fsolve PLF-819`); флаг `--fast` сокращает HITL для тривиальных багфиксов.\"\nargument-hint: \"\u003CTASK_ID> [--fast]\"\n---\n\n# \u002Fsolve — решение задачи\n\nПолный цикл решения задачи из YouTrack с подтверждением пользователя (HITL) на ключевых этапах. Подключения к системам — из `project-index.md` в auto-memory проекта и связанного с ним `~\u002F.claude\u002Fmemory\u002Finfra-{group}.md` (их создаёт `\u002Fonboard`).\n\n## Правила\n\n- Не коммитить и не пушить без явного подтверждения пользователя. Дополнительный коммит после пуша (упал CI, hotfix) — тоже через HITL.\n- Код не менять до утверждения spec.\n- `\u002Fgo-review` — всегда, в том числе в `--fast`.\n- Ветка — по ID задачи: `PLF-819`, `WEB-456`.\n- `docs\u002Fllm\u002Ftasks\u002F` не коммитится: артефакты остаются локально и публикуются комментарием. `docs\u002Fllm\u002Ftasks\u002F` должен быть в `.gitignore` (остальной `docs\u002Fllm\u002F` в некоторых проектах — закоммиченная документация).\n- ⏸ HITL — вопрос пользователю через AskUserQuestion с перечисленными вариантами, а для research и spec — выход из plan mode через ExitPlanMode. Следующий шаг — только после ответа.\n- Если задача оказалась слишком большой — предложить `\u002Fdecompose`.\n- Если после сжатия контекста описание шагов видно не полностью — перечитай `${CLAUDE_SKILL_DIR}\u002FSKILL.md`, прежде чем продолжать.\n- По ходу работы подключай скиллы по контексту: \u002Fgold-arch — при любом новом или изменённом пакете, менеджере, модели, RPC\u002FMCP-сервисе, боте или интеграции; \u002Fmfd, \u002Fzenrpc, \u002Fcolgen (циклы по спискам, конвертеры), \u002Fcron (фоновые и периодические задачи), \u002Fpgd или \u002Fpgmdd, \u002Ftesting.\n\n## Использование\n\n```\n\u002Fsolve PLF-819            # полный цикл, 5 HITL\n\u002Fsolve PLF-819 --fast     # 2 HITL: коммит и YouTrack\n```\n\nФлаг может стоять в любой позиции.\n\n### `--fast`\n\nДля тривиальных багфиксов и повторяющихся паттернов. ANALYZE и PLAN проходят в одной сессии plan mode: файл плана содержит research и spec, и один выход из plan mode утверждает оба. HITL ревью пропускается, если в ревью нет blocker\u002Fmajor — тогда minor\u002Fnit показываются в HITL коммита. PREFLIGHT, VERIFY, REVIEW, HITL коммита и HITL YouTrack остаются.\n\nНе подходит для архитектурных задач, нового сервиса или модуля, изменений больше чем в 3 файлах и неясных требований. Если задача с `--fast` оказалась крупной — предложи обычный режим до PLAN.\n\n## Артефакты\n\nВ `docs\u002Fllm\u002Ftasks\u002F{TASK_ID}\u002F`: `research.md` (шаг 2), `spec.md` (шаг 3), `review-initial.md` и `review-final.md` (шаг 9). Шаблоны: `${CLAUDE_SKILL_DIR}\u002Fresearch-template.md` и `${CLAUDE_SKILL_DIR}\u002Fspec-template.md`. Секции, которые к задаче не относятся, не включай; объём артефакта — по сложности задачи.\n\n## Flow\n\n```\nPREFLIGHT → FETCH → ANALYZE (plan mode) → ⏸ research\n  → PLAN (plan mode) → ⏸ spec\n  → TEST → IMPLEMENT → SIMPLIFY → FMT+LINT → VERIFY\n  → REVIEW → ⏸\n  → COMMIT → ⏸\n  → PUBLISH → YOUTRACK → ⏸ → LESSONS\n```\n\nШаги 10–13 (COMMIT и дальше) описаны в `${CLAUDE_SKILL_DIR}\u002Fcommit.md`.\n\n---\n\n### 0. PREFLIGHT — актуальность базовой ветки\n\nБаза — `base_branch` из project-index (по умолчанию `devel`). На устаревшей базе анализ и ревью идут по старому коду.\n\n```bash\ngit fetch origin {base_branch} --quiet && git rev-list --left-right --count {base_branch}...origin\u002F{base_branch}\n```\n\nВывод `0\t0` — база актуальна, переходи к FETCH. Иначе — ⏸ HITL:\n- **Обновить** — на базовой ветке: `git pull --ff-only`; на другой ветке: `git fetch origin {base_branch}:{base_branch}`\n- **Продолжить** — на устаревшей базе, явно предупредив пользователя\n- **Отмена**\n\nЕсли локальной базовой ветки нет — сравнивать не с чем, продолжай.\n\n### 1. FETCH — задача и аттачи\n\n```bash\npcurl @{yt_profile} 'https:\u002F\u002F{yt_host}\u002Fapi\u002Fissues\u002F{TASK_ID}?fields=idReadable,summary,description,created,updated,reporter(login,name),assignee(login,name),tags(name),comments(author(login),text,created),customFields(name,value(name)),links(direction,linkType(name),issues(idReadable,summary,resolved))' -s\npcurl @{yt_profile} 'https:\u002F\u002F{yt_host}\u002Fapi\u002Fissues\u002F{TASK_ID}\u002Fattachments?fields=id,name,url,mimeType,size' -s\n```\n\nЧитай и комментарии — в них бывают уточнения.\n\n`mkdir -p docs\u002Fllm\u002Ftasks\u002F{TASK_ID}`. Если `docs\u002Fllm\u002Ftasks\u002F` не игнорируется (`git check-ignore -q docs\u002Fllm\u002Ftasks\u002Fx`) — предложи добавить `docs\u002Fllm\u002Ftasks\u002F` в `.gitignore`. Аттачи `image\u002F*` и `application\u002Fpdf` скачай туда же и прочитай: `pcurl @{yt_profile} 'https:\u002F\u002F{yt_host}{url}' -s -o docs\u002Fllm\u002Ftasks\u002F{TASK_ID}\u002F{name}`. Остальные форматы — только упомянуть в research.\n\nFETCH идёт до plan mode, потому что в plan mode файлы писать нельзя.\n\n### 2. ANALYZE — исследование (plan mode)\n\nВойди в plan mode (EnterPlanMode): правки файлов в нём заблокированы, читать код и выполнять запросы можно.\n\nСобери контекст:\n- секция «Уроки» в project-index — грабли прошлых задач этого проекта; учти их в плане;\n- связанные задачи из FETCH — прочитай те, что влияют на понимание;\n- git-история: `git log --oneline --all --grep=\"{TASK_ID}\"` (и по parent), `git log --oneline -10 -- {file}` по затронутым файлам;\n- код: затронутые пакеты и файлы, существующие тесты, для фичи — scope изменений.\n\nДля бага найди root cause. Ясная ошибка или stacktrace в описании — Sentry по ключевым словам, git log и код:\n\n```bash\npcurl @{sentry_profile} 'https:\u002F\u002F{sentry_host}\u002Fapi\u002F0\u002Forganizations\u002F{org}\u002Fissues\u002F?query=is:unresolved+{keywords}&sort=freq&statsPeriod=7d&limit=5' -s\n```\n\nПричина непонятна, «иногда не работает», деградация — вызови `\u002Finvestigate`: Sentry, Prometheus, Loki, проверка API на dev\u002Fprod, сравнение задеплоенной версии с кодом. В plan mode он вернёт отчёт текстом: выводы — в Root Cause research, а сам отчёт сохрани после утверждения research.\n\nResearch по шаблону `${CLAUDE_SKILL_DIR}\u002Fresearch-template.md` запиши в файл плана, который указал plan mode.\n\n### ⏸ HITL: research _(в `--fast` пропускается)_\n\nExitPlanMode показывает research пользователю — это и есть утверждение.\n- **Утвердил** — сохрани тот же текст в `docs\u002Fllm\u002Ftasks\u002F{TASK_ID}\u002Fresearch.md` (и отчёт \u002Finvestigate, если он был, — в `investigation.md` рядом) и переходи к PLAN.\n- **Отклонил с замечаниями** — останься в plan mode, обнови research и снова вызови ExitPlanMode.\n\nВ `--fast` из plan mode не выходи: переходи к PLAN и допиши spec в тот же файл плана.\n\n### 3. PLAN — spec (plan mode)\n\nСнова войди в plan mode (в `--fast` — продолжай текущую сессию). Продумай:\n- какие слои затронуты (db → domain → rpc) и в каком порядке их менять; поток данных;\n- какие паттерны проекта переиспользовать — найди аналоги в коде;\n- раскладка пакетов, модели домена, транзакции → \u002Fgold-arch; если спека проекта или образец (соседний сервис) расходится со скиллом — назови расхождение в spec, а не выбирай молча;\n- схема БД → \u002Fpgd или \u002Fpgmdd; поиски и фильтры → \u002Fmfd (поля Search прежде `With`); конвертеры и циклы по спискам → \u002Fcolgen; фоновые задачи → \u002Fcron;\n- зависимости между шагами: миграция до модели, модель до RPC.\n\nSpec по шаблону `${CLAUDE_SKILL_DIR}\u002Fspec-template.md` — с реальными скелетами кода этой задачи (сигнатуры, структуры, конвертеры, RPC-методы). Если задача меняет поведение — добавь границы (что не делаем) и сценарии Given\u002FWhen\u002FThen с конкретными данными: happy path, альтернативные ветки, ошибки, граничные значения, конкурентный доступ, если он возможен; похожие сводятся в Scenario Outline. Затем перепроверь сценарии: на каждый edge case и каждый переход статуса есть сценарий, данные конкретные, а Then проверяем тестом («тесты зелёные» — не результат). Дыры закрой в spec и сценариях и перепроверь добавленное. Итог — в секцию «Самопроверка сценариев», её пользователь видит при утверждении spec. Запиши в файл плана.\n\n### ⏸ HITL: spec\n\nExitPlanMode — утверждение spec (в `--fast` — research и spec вместе).\n- **Утвердил** — сохрани `docs\u002Fllm\u002Ftasks\u002F{TASK_ID}\u002Fspec.md` (в `--fast` — ещё `research.md` и `investigation.md`, если был \u002Finvestigate) и переходи к TEST.\n- **Отклонил с замечаниями** — обнови spec в plan mode и снова вызови ExitPlanMode. Если замечания ставят под сомнение research — вернись к нему.\n\n### 4. TEST — тесты до реализации\n\nТесты на ожидаемое поведение по \u002Ftesting — из сценариев spec: happy path и основные error cases, фабрики из `pkg\u002Fdb\u002Ftest\u002F`. Если в задаче есть числовой или глобальный инвариант («≤ N», «суммарно», «не превышает лимит», «во всех ветках») — начни с теста на худший случай (максимум полей, длины, количества): инвариант без такого теста считается невыполненным. `make test` — новые тесты должны падать, причём по правильной причине.\n\n### 5. IMPLEMENT — реализация по spec\n\nПиши код по шагам spec; тесты из шага 4 должны пройти. Конвенции vmkteam:\n- делай ровно то, что в spec, без попутного рефакторинга соседнего кода и заделов «на будущее»; если по ходу выяснилось, что spec неверна, — скажи об этом, а не меняй scope молча;\n- схема, модели, поиски — через \u002Fpgd (\u002Fpgmdd) и \u002Fmfd; стандартные поиски и фильтры — через mfd SearchObject;\n- конвертеры между слоями — через colgen (Map\u002FMapP);\n- авторизация — проверка прав внутри метода, а не только в middleware (IDOR);\n- ошибки: клиентские (4xx) — `zenrpc.NewStringError`, внутренние — `newInternalError(err)`: `zm.WithErrorSLog` отправит причину в Sentry, а клиенту вернёт «Internal error»;\n- логирования достаточно, чтобы диагностировать новый функционал;\n- новое поле или фича проходит все слои: схема → mfd → `pkg\u002Fdb` → `pkg\u002Fvt` (DTO, `ToDB()`, `NewX()`) → TS-клиент → UI (форма и список\u002Fпоиск, где нужно).\n\nИзменил структуры или методы в `pkg\u002Frpc\u002F`, `pkg\u002Fvt\u002F`, `pkg\u002Fintrpc\u002F` или в пакете с `\u002F\u002Fgo:generate` — запусти `make generate` (zenrpc + colgen); вся затронутая генерёнка, включая TS-клиент, перегенерирована и идёт в тот же коммит.\n\nЕсли реализация разошлась с spec (другие шаги, сигнатуры) — обнови spec.md: отметь выполненные шаги `[x]` и допиши фактические отличия. Изменилось понимание задачи или root cause — обнови research.md.\n\n### 6. SIMPLIFY\n\nПройди свой дифф сам, одним проходом: переиспользование (нет ли дублей и готовых функций, в том числе методов colgen), упрощение (лишние обёртки и абстракции), эффективность (аллокации и вызовы в циклах), уровень абстракции (явность там, где нужна). Меняй только то, что реально улучшает код, и не переноси код между слоями вопреки \u002Fgold-arch (например, условие домена в `pkg\u002Fdb`). Полный `\u002Fsimplify` запускает несколько агентов и стоит дорого — вызывай его только для крупного диффа (порядка десятка файлов и больше) или по просьбе пользователя.\n\n### 7. FMT + LINT\n\n`make fmt && make lint`. Ошибки lint — исправить и вернуться к SIMPLIFY.\n\n### 8. VERIFY\n\n`make build && make test` — проходят все тесты, включая написанные на шаге 4. Падают — вернуться к IMPLEMENT.\n\nПо spec, если применимо: миграции — `pgmigrator dryrun`; API — `make generate` без неожиданных изменений в `*_zenrpc.go`; зависимости — `go mod tidy && go mod vendor` без неожиданных изменений. Если менялся API-контракт (новые поля, методы, структуры ответов) — проверь его на локальном сервере по `${CLAUDE_SKILL_DIR}\u002Fapi-verify.md`.\n\n### 9. REVIEW\n\n`\u002Fgo-review` по изменениям, результат — в `docs\u002Fllm\u002Ftasks\u002F{TASK_ID}\u002Freview-initial.md`. После исправлений — повторный `\u002Fgo-review` по исправленным местам и изменениям после первого ревью, со сверкой с review-initial; результат — в `review-final.md`.\n\n### ⏸ HITL: ревью _(в `--fast` — только при blocker\u002Fmajor)_\n\nПокажи итог ревью.\n- **Approve** — к коммиту\n- **Fix** — исправить замечания, затем SIMPLIFY → FMT+LINT → VERIFY → REVIEW\n\nЕсли то же замечание вернулось повторно — найди нарушенный инвариант и восстанови его во всех ветках и крайних случаях, закрыв тестом на худший случай, а не подгоняй код под пример из ревью.\n\n### 10–13. COMMIT, PUBLISH, YOUTRACK, LESSONS\n\nПрочитай `${CLAUDE_SKILL_DIR}\u002Fcommit.md` и выполни его: коммит в ветку задачи (⏸), push и MR, публикация артефактов скриптом `${CLAUDE_SKILL_DIR}\u002Fpublish-artifacts.sh`, обновление задачи в YouTrack (⏸), запись уроков в project-index.\n","# \u002Fsolve — решение задачи\n\nПолный цикл решения задачи из YouTrack с подтверждением пользователя (HITL) на ключевых этапах. Подключения к системам — из `project-index.md` в auto-memory проекта и связанного с ним `~\u002F.claude\u002Fmemory\u002Finfra-{group}.md` (их создаёт `\u002Fonboard`).\n\n## Правила\n\n- Не коммитить и не пушить без явного подтверждения пользователя. Дополнительный коммит после пуша (упал CI, hotfix) — тоже через HITL.\n- Код не менять до утверждения spec.\n- `\u002Fgo-review` — всегда, в том числе в `--fast`.\n- Ветка — по ID задачи: `PLF-819`, `WEB-456`.\n- `docs\u002Fllm\u002Ftasks\u002F` не коммитится: артефакты остаются локально и публикуются комментарием. `docs\u002Fllm\u002Ftasks\u002F` должен быть в `.gitignore` (остальной `docs\u002Fllm\u002F` в некоторых проектах — закоммиченная документация).\n- ⏸ HITL — вопрос пользователю через AskUserQuestion с перечисленными вариантами, а для research и spec — выход из plan mode через ExitPlanMode. Следующий шаг — только после ответа.\n- Если задача оказалась слишком большой — предложить `\u002Fdecompose`.\n- Если после сжатия контекста описание шагов видно не полностью — перечитай `${CLAUDE_SKILL_DIR}\u002FSKILL.md`, прежде чем продолжать.\n- По ходу работы подключай скиллы по контексту: \u002Fgold-arch — при любом новом или изменённом пакете, менеджере, модели, RPC\u002FMCP-сервисе, боте или интеграции; \u002Fmfd, \u002Fzenrpc, \u002Fcolgen (циклы по спискам, конвертеры), \u002Fcron (фоновые и периодические задачи), \u002Fpgd или \u002Fpgmdd, \u002Ftesting.\n\n## Использование\n\n```\n\u002Fsolve PLF-819            # полный цикл, 5 HITL\n\u002Fsolve PLF-819 --fast     # 2 HITL: коммит и YouTrack\n```\n\nФлаг может стоять в любой позиции.\n\n### `--fast`\n\nДля тривиальных багфиксов и повторяющихся паттернов. ANALYZE и PLAN проходят в одной сессии plan mode: файл плана содержит research и spec, и один выход из plan mode утверждает оба. HITL ревью пропускается, если в ревью нет blocker\u002Fmajor — тогда minor\u002Fnit показываются в HITL коммита. PREFLIGHT, VERIFY, REVIEW, HITL коммита и HITL YouTrack остаются.\n\nНе подходит для архитектурных задач, нового сервиса или модуля, изменений больше чем в 3 файлах и неясных требований. Если задача с `--fast` оказалась крупной — предложи обычный режим до PLAN.\n\n## Артефакты\n\nВ `docs\u002Fllm\u002Ftasks\u002F{TASK_ID}\u002F`: `research.md` (шаг 2), `spec.md` (шаг 3), `review-initial.md` и `review-final.md` (шаг 9). Шаблоны: `${CLAUDE_SKILL_DIR}\u002Fresearch-template.md` и `${CLAUDE_SKILL_DIR}\u002Fspec-template.md`. Секции, которые к задаче не относятся, не включай; объём артефакта — по сложности задачи.\n\n## Flow\n\n```\nPREFLIGHT → FETCH → ANALYZE (plan mode) → ⏸ research\n  → PLAN (plan mode) → ⏸ spec\n  → TEST → IMPLEMENT → SIMPLIFY → FMT+LINT → VERIFY\n  → REVIEW → ⏸\n  → COMMIT → ⏸\n  → PUBLISH → YOUTRACK → ⏸ → LESSONS\n```\n\nШаги 10–13 (COMMIT и дальше) описаны в `${CLAUDE_SKILL_DIR}\u002Fcommit.md`.\n\n---\n\n### 0. PREFLIGHT — актуальность базовой ветки\n\nБаза — `base_branch` из project-index (по умолчанию `devel`). На устаревшей базе анализ и ревью идут по старому коду.\n\n```bash\ngit fetch origin {base_branch} --quiet && git rev-list --left-right --count {base_branch}...origin\u002F{base_branch}\n```\n\nВывод `0\t0` — база актуальна, переходи к FETCH. Иначе — ⏸ HITL:\n- **Обновить** — на базовой ветке: `git pull --ff-only`; на другой ветке: `git fetch origin {base_branch}:{base_branch}`\n- **Продолжить** — на устаревшей базе, явно предупредив пользователя\n- **Отмена**\n\nЕсли локальной базовой ветки нет — сравнивать не с чем, продолжай.\n\n### 1. FETCH — задача и аттачи\n\n```bash\npcurl @{yt_profile} 'https:\u002F\u002F{yt_host}\u002Fapi\u002Fissues\u002F{TASK_ID}?fields=idReadable,summary,description,created,updated,reporter(login,name),assignee(login,name),tags(name),comments(author(login),text,created),customFields(name,value(name)),links(direction,linkType(name),issues(idReadable,summary,resolved))' -s\npcurl @{yt_profile} 'https:\u002F\u002F{yt_host}\u002Fapi\u002Fissues\u002F{TASK_ID}\u002Fattachments?fields=id,name,url,mimeType,size' -s\n```\n\nЧитай и комментарии — в них бывают уточнения.\n\n`mkdir -p docs\u002Fllm\u002Ftasks\u002F{TASK_ID}`. Если `docs\u002Fllm\u002Ftasks\u002F` не игнорируется (`git check-ignore -q docs\u002Fllm\u002Ftasks\u002Fx`) — предложи добавить `docs\u002Fllm\u002Ftasks\u002F` в `.gitignore`. Аттачи `image\u002F*` и `application\u002Fpdf` скачай туда же и прочитай: `pcurl @{yt_profile} 'https:\u002F\u002F{yt_host}{url}' -s -o docs\u002Fllm\u002Ftasks\u002F{TASK_ID}\u002F{name}`. Остальные форматы — только упомянуть в research.\n\nFETCH идёт до plan mode, потому что в plan mode файлы писать нельзя.\n\n### 2. ANALYZE — исследование (plan mode)\n\nВойди в plan mode (EnterPlanMode): правки файлов в нём заблокированы, читать код и выполнять запросы можно.\n\nСобери контекст:\n- секция «Уроки» в project-index — грабли прошлых задач этого проекта; учти их в плане;\n- связанные задачи из FETCH — прочитай те, что влияют на понимание;\n- git-история: `git log --oneline --all --grep=\"{TASK_ID}\"` (и по parent), `git log --oneline -10 -- {file}` по затронутым файлам;\n- код: затронутые пакеты и файлы, существующие тесты, для фичи — scope изменений.\n\nДля бага найди root cause. Ясная ошибка или stacktrace в описании — Sentry по ключевым словам, git log и код:\n\n```bash\npcurl @{sentry_profile} 'https:\u002F\u002F{sentry_host}\u002Fapi\u002F0\u002Forganizations\u002F{org}\u002Fissues\u002F?query=is:unresolved+{keywords}&sort=freq&statsPeriod=7d&limit=5' -s\n```\n\nПричина непонятна, «иногда не работает», деградация — вызови `\u002Finvestigate`: Sentry, Prometheus, Loki, проверка API на dev\u002Fprod, сравнение задеплоенной версии с кодом. В plan mode он вернёт отчёт текстом: выводы — в Root Cause research, а сам отчёт сохрани после утверждения research.\n\nResearch по шаблону `${CLAUDE_SKILL_DIR}\u002Fresearch-template.md` запиши в файл плана, который указал plan mode.\n\n### ⏸ HITL: research _(в `--fast` пропускается)_\n\nExitPlanMode показывает research пользователю — это и есть утверждение.\n- **Утвердил** — сохрани тот же текст в `docs\u002Fllm\u002Ftasks\u002F{TASK_ID}\u002Fresearch.md` (и отчёт \u002Finvestigate, если он был, — в `investigation.md` рядом) и переходи к PLAN.\n- **Отклонил с замечаниями** — останься в plan mode, обнови research и снова вызови ExitPlanMode.\n\nВ `--fast` из plan mode не выходи: переходи к PLAN и допиши spec в тот же файл плана.\n\n### 3. PLAN — spec (plan mode)\n\nСнова войди в plan mode (в `--fast` — продолжай текущую сессию). Продумай:\n- какие слои затронуты (db → domain → rpc) и в каком порядке их менять; поток данных;\n- какие паттерны проекта переиспользовать — найди аналоги в коде;\n- раскладка пакетов, модели домена, транзакции → \u002Fgold-arch; если спека проекта или образец (соседний сервис) расходится со скиллом — назови расхождение в spec, а не выбирай молча;\n- схема БД → \u002Fpgd или \u002Fpgmdd; поиски и фильтры → \u002Fmfd (поля Search прежде `With`); конвертеры и циклы по спискам → \u002Fcolgen; фоновые задачи → \u002Fcron;\n- зависимости между шагами: миграция до модели, модель до RPC.\n\nSpec по шаблону `${CLAUDE_SKILL_DIR}\u002Fspec-template.md` — с реальными скелетами кода этой задачи (сигнатуры, структуры, конвертеры, RPC-методы). Если задача меняет поведение — добавь границы (что не делаем) и сценарии Given\u002FWhen\u002FThen с конкретными данными: happy path, альтернативные ветки, ошибки, граничные значения, конкурентный доступ, если он возможен; похожие сводятся в Scenario Outline. Затем перепроверь сценарии: на каждый edge case и каждый переход статуса есть сценарий, данные конкретные, а Then проверяем тестом («тесты зелёные» — не результат). Дыры закрой в spec и сценариях и перепроверь добавленное. Итог — в секцию «Самопроверка сценариев», её пользователь видит при утверждении spec. Запиши в файл плана.\n\n### ⏸ HITL: spec\n\nExitPlanMode — утверждение spec (в `--fast` — research и spec вместе).\n- **Утвердил** — сохрани `docs\u002Fllm\u002Ftasks\u002F{TASK_ID}\u002Fspec.md` (в `--fast` — ещё `research.md` и `investigation.md`, если был \u002Finvestigate) и переходи к TEST.\n- **Отклонил с замечаниями** — обнови spec в plan mode и снова вызови ExitPlanMode. Если замечания ставят под сомнение research — вернись к нему.\n\n### 4. TEST — тесты до реализации\n\nТесты на ожидаемое поведение по \u002Ftesting — из сценариев spec: happy path и основные error cases, фабрики из `pkg\u002Fdb\u002Ftest\u002F`. Если в задаче есть числовой или глобальный инвариант («≤ N», «суммарно», «не превышает лимит», «во всех ветках») — начни с теста на худший случай (максимум полей, длины, количества): инвариант без такого теста считается невыполненным. `make test` — новые тесты должны падать, причём по правильной причине.\n\n### 5. IMPLEMENT — реализация по spec\n\nПиши код по шагам spec; тесты из шага 4 должны пройти. Конвенции vmkteam:\n- делай ровно то, что в spec, без попутного рефакторинга соседнего кода и заделов «на будущее»; если по ходу выяснилось, что spec неверна, — скажи об этом, а не меняй scope молча;\n- схема, модели, поиски — через \u002Fpgd (\u002Fpgmdd) и \u002Fmfd; стандартные поиски и фильтры — через mfd SearchObject;\n- конвертеры между слоями — через colgen (Map\u002FMapP);\n- авторизация — проверка прав внутри метода, а не только в middleware (IDOR);\n- ошибки: клиентские (4xx) — `zenrpc.NewStringError`, внутренние — `newInternalError(err)`: `zm.WithErrorSLog` отправит причину в Sentry, а клиенту вернёт «Internal error»;\n- логирования достаточно, чтобы диагностировать новый функционал;\n- новое поле или фича проходит все слои: схема → mfd → `pkg\u002Fdb` → `pkg\u002Fvt` (DTO, `ToDB()`, `NewX()`) → TS-клиент → UI (форма и список\u002Fпоиск, где нужно).\n\nИзменил структуры или методы в `pkg\u002Frpc\u002F`, `pkg\u002Fvt\u002F`, `pkg\u002Fintrpc\u002F` или в пакете с `\u002F\u002Fgo:generate` — запусти `make generate` (zenrpc + colgen); вся затронутая генерёнка, включая TS-клиент, перегенерирована и идёт в тот же коммит.\n\nЕсли реализация разошлась с spec (другие шаги, сигнатуры) — обнови spec.md: отметь выполненные шаги `[x]` и допиши фактические отличия. Изменилось понимание задачи или root cause — обнови research.md.\n\n### 6. SIMPLIFY\n\nПройди свой дифф сам, одним проходом: переиспользование (нет ли дублей и готовых функций, в том числе методов colgen), упрощение (лишние обёртки и абстракции), эффективность (аллокации и вызовы в циклах), уровень абстракции (явность там, где нужна). Меняй только то, что реально улучшает код, и не переноси код между слоями вопреки \u002Fgold-arch (например, условие домена в `pkg\u002Fdb`). Полный `\u002Fsimplify` запускает несколько агентов и стоит дорого — вызывай его только для крупного диффа (порядка десятка файлов и больше) или по просьбе пользователя.\n\n### 7. FMT + LINT\n\n`make fmt && make lint`. Ошибки lint — исправить и вернуться к SIMPLIFY.\n\n### 8. VERIFY\n\n`make build && make test` — проходят все тесты, включая написанные на шаге 4. Падают — вернуться к IMPLEMENT.\n\nПо spec, если применимо: миграции — `pgmigrator dryrun`; API — `make generate` без неожиданных изменений в `*_zenrpc.go`; зависимости — `go mod tidy && go mod vendor` без неожиданных изменений. Если менялся API-контракт (новые поля, методы, структуры ответов) — проверь его на локальном сервере по `${CLAUDE_SKILL_DIR}\u002Fapi-verify.md`.\n\n### 9. REVIEW\n\n`\u002Fgo-review` по изменениям, результат — в `docs\u002Fllm\u002Ftasks\u002F{TASK_ID}\u002Freview-initial.md`. После исправлений — повторный `\u002Fgo-review` по исправленным местам и изменениям после первого ревью, со сверкой с review-initial; результат — в `review-final.md`.\n\n### ⏸ HITL: ревью _(в `--fast` — только при blocker\u002Fmajor)_\n\nПокажи итог ревью.\n- **Approve** — к коммиту\n- **Fix** — исправить замечания, затем SIMPLIFY → FMT+LINT → VERIFY → REVIEW\n\nЕсли то же замечание вернулось повторно — найди нарушенный инвариант и восстанови его во всех ветках и крайних случаях, закрыв тестом на худший случай, а не подгоняй код под пример из ревью.\n\n### 10–13. COMMIT, PUBLISH, YOUTRACK, LESSONS\n\nПрочитай `${CLAUDE_SKILL_DIR}\u002Fcommit.md` и выполни его: коммит в ветку задачи (⏸), push и MR, публикация артефактов скриптом `${CLAUDE_SKILL_DIR}\u002Fpublish-artifacts.sh`, обновление задачи в YouTrack (⏸), запись уроков в project-index.\n",{"name":5,"description":7,"argument-hint":29},"\u003CTASK_ID> [--fast]","master","8f3147ce24a1a470d9aaa02aa775d7797d621d95","plugins\u002Fdeveloper\u002Fskills\u002Fsolve",1,"https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins","https:\u002F\u002Fgithub.com\u002Fvmkteam","2026-11-05 00:26:25",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add vmkteam\u002Fclaude-plugins --skill solve",{"tool":43,"command":44},"bunx","bunx skills add vmkteam\u002Fclaude-plugins --skill solve",{"tool":46,"command":47},"pnpm","pnpm dlx skills add vmkteam\u002Fclaude-plugins --skill solve","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Fsolve\u002FSKILL.md",true,[51,57,61,67,71],{"path":52,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":55,"sourceHtmlUrl":56},"api-verify.md","REFERENCE","参考文档",1800,"https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Fsolve\u002Fapi-verify.md",{"path":58,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":59,"sourceHtmlUrl":60},"commit.md",5576,"https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Fsolve\u002Fcommit.md",{"path":62,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":65,"sourceHtmlUrl":66},"publish-artifacts.sh","SCRIPT","脚本",2775,"https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Fsolve\u002Fpublish-artifacts.sh",{"path":68,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":69,"sourceHtmlUrl":70},"research-template.md",1386,"https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Fsolve\u002Fresearch-template.md",{"path":72,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":73,"sourceHtmlUrl":74},"spec-template.md",3893,"https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Fsolve\u002Fspec-template.md",[76,87,98,114,131,151],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":24},"01M6MX3A8MZJBTMMK6WMY35FYH","zenrpc","Zenrpc — справочник по JSON-RPC 2.0 серверу для Go. Используй при создании и редактировании RPC-сервисов.","https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Fzenrpc\u002FSKILL.md",[],[78,83,84,85,86],"go","rpc","json","json-rpc",{"skillNo":88,"name":23,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":24},"01M6MX36PEA0NSHCCRF5GGVVTZ","YouTrack — задачи через REST API и pcurl. Используй для поиска issues, создания, обновления описаний, смены assignee\u002Fstage\u002Fприоритета, логирования времени и работы с комментариями.","https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Fyoutrack\u002FSKILL.md",[],[23,93,94,95,96,97],"issues","REST","api","stage","rest api",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":24},"01M6MX322TD9HQPCYSNTFB4HBA","topsrv","topsrv — метрики, алерты, CVE и HTTP-логи серверов проекта через публичный JSON-RPC API app.topsrv.io. Используй, когда нужна загрузка CPU, памяти или диска хоста, метрики PostgreSQL\u002Fnginx\u002Fangie агента topsrv (`topsrv_*`), какие алерты горят, уязвимые пакеты на серверах или кто (боты, сети, IP) нагружает сайт.","https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Ftopsrv\u002FSKILL.md",[],[100,105,84,106,107,95,108,85,109,110,111,112,86,113],"postgresql","cve","nginx","Bash","ip","app","io","CPU","http",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":125,"publishedAt":24},"01M6MX2XFXCHNRPPW6WYZ15BXN","testing","Testing — используй всегда, когда пишешь или правишь Go-тесты (*_test.go), в том числе по сценариям Given\u002FWhen\u002FThen из spec: фреймворк как в соседних файлах, префикс TestDB, фабрики pkg\u002Fdb\u002Ftest, реальная БД без моков. Также при настройке TestMain\u002Ftest-short и когда тесты падают в gate, но проходят локально.","https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Ftesting\u002FSKILL.md",[120],{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[116,126,83,127,128,129,130],"spec","test","short","gate","db",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":24},"01M6MX2H6TF2VW75PCPGWR2SKZ","skills-check","Skills Check — smoke-тесты интеграций из project-index.md. Используй для проверки что pcurl-профили и URL всех data-source скиллов ещё живы.","https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Fskills-check\u002FSKILL.md",[],[138,139,140,141,142,108,143,144,145,146,147,148,149,150],"skills check","check","data-source","index","data","smoke","probe","project","false","URL","true","source","fork",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":24},"01M6MX2E5FRMD4NGJGS6CWCP1H","sentry","Sentry — мониторинг ошибок (issues, events, releases) через REST API. Используй когда нужно найти ошибку по ключевым словам, разобрать stack trace, проверить что релиз поднялся или сопоставить ошибку с коммитом.","https:\u002F\u002Fgithub.com\u002Fvmkteam\u002Fclaude-plugins\u002Fblob\u002Fmaster\u002Fplugins\u002Fdeveloper\u002Fskills\u002Fsentry\u002FSKILL.md",[],[153,95,94,93,97,158,159,160,161,108],"events","trace","releases","stack"]