слияние: три плагина стали одним av-dev, скиллы получили префиксы

Каталоги, агенты и общие дома переехали в av-dev/; скиллы названы по прежнему плагину — doc-*, task-*, code-*, с двумя смысловыми именами вместо тавтологии: doc-sync вместо docs, task-track вместо tasks. Манифесты сведены к двум плагинам. Пространства имён вызовов и пути внутри дерева переписаны машинно; проза, которая называет прежние плагины отдельными, идёт следующим шагом.
2026-08-13 10:10:51 +03:00
parent 142659bfd1
commit de12a4d8a3
68 changed files with 222 additions and 248 deletions
@@ -6,19 +6,9 @@
  },
  "plugins": [
    {
-      "name": "av-dev-docs",
+      "name": "av-dev",
-      "source": "./av-dev-docs",
+      "source": "./av-dev",
-      "description": "Документация проекта: канон раскладки (CLAUDE.md плюс docs/ — паспорт, архитектура, схема БД, безопасность, конвенции, разведка, ADR, журнал ревью), роли документов и правило единственного дома. Три операции одной машиной сравнения — check, adopt, upgrade — со скриптом docs.py; заведение нового проекта интервью по брифу; ведение содержимого по ходу разработки: синк после сделанной задачи, ADR промоутом из архивного design.md, записка разведки, запись дефекта в журнал ревью. Смысловое, чего скрипт не видит, судит скилл healthcheck двумя агентами разом — doc-consistency (документы между собой и с openspec) и doc-code-drift (факты против кода); язык документов вычитывает агент doc-wording. Задач не ведёт — это плагин av-dev-tasks, и он опционален."
+      "description": "Личный процесс разработки одним плагином: документы проекта, учёт работ и работа по задачам. Документы — канон раскладки (CLAUDE.md плюс docs/: паспорт, архитектура, схема БД, безопасность, конвенции, разведка, ADR, журнал ревью), три операции одной машиной сравнения в doc-canon (check, adopt, upgrade) со скриптом docs.py, заведение нового проекта интервью в doc-init, ведение содержимого по ходу разработки в doc-sync, суд о смысловом здоровье в doc-healthcheck двумя агентами разом. Учёт — задачи и цели каталогом markdown-файлов в task-track, у записи тип (goal, feature, fix, chore, research), и тип решает её схему; приоритет расставляет интерактивный task-groom порядком строк. Работа — одна задача от постановки до закрытия скиллом code-resolve: точка входа одна, сценария три (решение циклом SDD с чекпоинтом, разведка без кода, обслуживание без change), и выбирает сценарий сам скилл, прочитав постановку; плюс конвейер ревью code-review с детерминированным гейтом, сверкой со спеками и обязательным триажем, плюс code-openspec, который заводит и проверяет openspec/. Версия раскладки и настройки живут в .av-dev.toml в корне репозитория. Части включаются следом в проекте, а не установкой: нет docs/ — документы не ведутся, нет каталога задач — учёт остаётся владельцу, нет openspec/ — его заводит сценарий решения. Коммиты — отдельный плагин av-dev-git."
    },
    {
      "name": "av-dev-tasks",
      "source": "./av-dev-tasks",
      "description": "Задачи и цели каталогом markdown-файлов: одна запись — файл в items/ плюс строка ровно в одном индексе, у записи тип (goal, feature, fix, chore, research), и тип решает, каких разделов она требует и что с ней можно делать. Заведение из диалога с фильтром и дедупом, разбор находок ревью в задачи, декомпозиция на независимо полезные части, гигиена полей, согласованность индексов скриптом tasks.py. Приоритет — явный порядок строк в беклоге, и расставляет его скилл groom: интерактивный разбор на два вопроса, что сейчас самое важное и что перестало быть важным. Готовность записи к работе проверяет команда ready. Записи вычитывают два прохода: task-form (форма записи) и task-wording (язык). Канон документов ведёт плагин av-dev-docs, он опционален. Задач не выполняет — этим занимается конвейер проекта."
    },
    {
      "name": "av-dev-code",
      "source": "./av-dev-code",
      "description": "Одна задача от постановки до закрытия скиллом resolve: точка входа одна, сценария три, и выбирает сценарий сам скилл, прочитав постановку. Сценарий решения — полный цикл Spec Driven Development с плановым чекпоинтом после ревью дизайна: объяснение человеческим языком, повод скорректировать ход решения. Сценарий разведки (тип research, сырая идея, мутная постановка) кода не пишет и change не заводит: его чекпоинт вариантов стоит до первого написанного требования, а исход уезжает в документы канона и в задачи; выбранный способ реализуется следующим прогоном, который запускает человек. Сценарий обслуживания (тип chore: тулчейн, зависимости, сборка, гит-хуки, перенос, чистка) change не заводит и планового стопа не имеет: спека там не меняется по построению, поэтому цикл SDD остаётся без входа, а ревью идёт фиксированным планом без метки. Смена сценария по ходу — событие с названным исходом, а не тихий поворот. Плюс конвейер ревью с детерминированным гейтом, сверкой со спеками, враждебными постановками, эксплуатационным постмортемом и обязательным триажем. OpenSpec нужен сценарию решения, и плагин сам его заводит скиллом openspec; разведка обходится без него. Задача принимается и обычным текстом. Плагины av-dev-docs и av-dev-tasks опциональны: первый даёт документы канона, из которых проходы читают проектную конкретику, второй — учёт задач; без них прогон деградирует поразрядно и называет это строкой."
    },
    {
      "name": "av-dev-git",
@@ -128,10 +128,10 @@ flowchart TB
 ```
 Зависимости **взаимные, но каждая мягкая**. `av-dev-code` зовёт обоих соседей;
-обратные вызовы тоже есть — `av-dev-docs:init` и `av-dev-docs:canon` заводят
+обратные вызовы тоже есть — `av-dev:doc-init` и `av-dev:doc-canon` заводят
-OpenSpec скиллом `av-dev-code:openspec`, `av-dev-docs:docs` берёт у
+OpenSpec скиллом `av-dev:code-openspec`, `av-dev:doc-sync` берёт у
-`av-dev-code:review` форму записи журнала дефектов и процедуру промоута,
+`av-dev:code-review` форму записи журнала дефектов и процедуру промоута,
-`av-dev-docs:canon` и `av-dev-docs:healthcheck` зовут `av-dev-tasks:tasks`.
+`av-dev:doc-canon` и `av-dev:doc-healthcheck` зовут `av-dev:task-track`.
 **Мягкая** значит, что у любого вызова есть ветка «не разрешился»: соседа в
 проекте нет — вызывающий называет строкой, чего теперь не делает никто, и работу
 не останавливает. Как именно зовут соседа и что делают, когда вызов не
@@ -147,7 +147,7 @@ OpenSpec скиллом `av-dev-code:openspec`, `av-dev-docs:docs` берёт у
 `docs/` (паспорт, архитектура, база, безопасность, конвенции, разведка, ADR,
 ревью, задачи) и `openspec/` — **раскладка целиком, роли документов и правило
 единственного дома живут одним домом**:
-[canon.md](av-dev-docs/skills/canon/references/canon.md). Здесь она не
+[canon.md](av-dev/skills/doc-canon/references/canon.md). Здесь она не
 пересказывается: копия перечня путей уже расходилась с домом, и как раз в
 обязательных — в ней не хватало путей, чьё отсутствие `docs.py check` считает
 нарушением.
@@ -163,17 +163,17 @@ OpenSpec скиллом `av-dev-code:openspec`, `av-dev-docs:docs` берёт у
 Отдельного файла-брифа при этом нет — проходы читают документы напрямую; карта
 «тема → её дом → что оттуда берётся» —
-[project-facts.md](av-dev-code/skills/review/references/project-facts.md).
+[project-facts.md](av-dev/skills/code-review/references/project-facts.md).
-Прийти в старый проект и перевести его на канон — `/av-dev-docs:canon`. Канон
+Прийти в старый проект и перевести его на канон — `/av-dev:doc-canon`. Канон
 версионируется, и проекты повышаются по [журналу
-версий](av-dev-docs/skills/canon/references/changelog.md); версия проекта живёт в
+версий](av-dev/skills/doc-canon/references/changelog.md); версия проекта живёт в
 `docs/.docs.json`.
 **Версий две, и они независимы.** У каталога задач своя — ключ `tasks` в
 `<каталог задач>/.tasks.json`, свой [журнал
-версий](av-dev-tasks/skills/tasks/references/changelog.md) и своё повышение
+версий](av-dev/skills/task-track/references/changelog.md) и своё повышение
-скиллом `/av-dev-tasks:tasks`. Плагины ставятся порознь: у проекта, взявшего учёт
+скиллом `/av-dev:task-track`. Плагины ставятся порознь: у проекта, взявшего учёт
 работ без канона документов, `docs/` нет вовсе, и общее число оказалось бы домом,
 которого у половины проектов не существует. Имя служебного файла при этом
 называет владельца — `.docs.json`, `.tasks.json`, `openspec/config.yaml`.
@@ -362,7 +362,7 @@ python3 scripts/frontmatter.py    # 0 в порядке, 1 расхождени
  а не «имя не то»;
 - **цвет charter'а, не отвечающий его модели.** Цвет кодирует модель, а не роль
  прохода — раскладка живёт в
-  [review/SKILL.md](av-dev-code/skills/review/SKILL.md),
+  [review/SKILL.md](av-dev/skills/code-review/SKILL.md),
  разделе «Модель по проходу», здесь только её механизация. Держаться вниманием
  правило не может: цвет ставится один раз при заведении charter'а, а модель
  потом меняется калибровкой;
@@ -95,7 +95,7 @@ check` сверяет версию, но не то, что миграционн
 **Форма ADR при пересмотре решения.** Парный статус («старая запись получает
 `заменено на`») судит агент `doc-consistency` — правило 6 его устава. Охват был
 открытым вопросом, пока агент звался пачкой, отобранной работой; переезд вызова
-в `av-dev-docs:healthcheck` с пачкой «весь канон» его снял. Остаётся зазор до
+в `av-dev:doc-healthcheck` с пачкой «весь канон» его снял. Остаётся зазор до
 ближайшего прогона `healthcheck` и отсутствие механической проверки — то есть
 пересмотр, сделанный сегодня, судится тогда, когда позовут сверку, а не в момент
 правки.
@@ -5,7 +5,7 @@
 - **риски, открытые вопросы и принятые пределы** — [REMAINING.md](REMAINING.md);
 - **почему решено так** — [DECISIONS.md](DECISIONS.md), записи датированы;
 - **шаги повышения проекта с версии канона на версию** — журнал версий
-  ([changelog.md](av-dev-docs/skills/canon/references/changelog.md)). Пересказ их
+  ([changelog.md](av-dev/skills/doc-canon/references/changelog.md)). Пересказ их
  сюда был бы вторым домом, и прежний план на этом уже разъезжался: он повторял
  записи версий 3, 4 и 5 построчно, и половина повторов протухла молча.
@@ -42,7 +42,7 @@
 - [ ] удалить проектные копии: `.claude/skills/healthlog-{task,review}-pipeline`
      и девять `.claude/agents/healthlog-review-*.md`. Они прошлого поколения и
      после переезда указывают на документы, которых уже не будет
- [ ] `av-dev-docs:canon` в режиме `adopt` — он приведёт проект к канону 14
+- [ ] `av-dev:doc-canon` в режиме `adopt` — он приведёт проект к канону 14
      сразу, картой и с подтверждением. Файл-в-файл здесь не расписан: раскладку
      знает скилл, и второй перечень разошёлся бы с ним
 - [ ] каталог задач — в `tasks/` корня (канон 11), не в `docs/tasks/`, без
@@ -84,7 +84,7 @@
 ## 4. Конвейер: что осталось после `resolve`
-Сам скилл написан (`av-dev-code:resolve`, три сценария — разведка, решение и
+Сам скилл написан (`av-dev:code-resolve`, три сценария — разведка, решение и
 обслуживание; чекпоинт есть у первых двух, у обслуживания планового стопа нет),
 `task-batch` удалён. Осталось то, что на бумаге не проверяется:
@@ -1,8 +0,0 @@
 {
  "name": "av-dev-code",
  "description": "Одна задача от постановки до закрытия скиллом resolve: точка входа одна, сценария три, и выбирает сценарий сам скилл, прочитав постановку. Сценарий решения — полный цикл Spec Driven Development с плановым чекпоинтом после ревью дизайна: объяснение человеческим языком, повод скорректировать ход решения. Сценарий разведки (тип research, сырая идея, мутная постановка) кода не пишет и change не заводит: его чекпоинт вариантов стоит до первого написанного требования, а исход уезжает в документы канона и в задачи; выбранный способ реализуется следующим прогоном, который запускает человек. Сценарий обслуживания (тип chore: тулчейн, зависимости, сборка, гит-хуки, перенос, чистка) change не заводит и планового стопа не имеет: спека там не меняется по построению, поэтому цикл SDD остаётся без входа, а ревью идёт фиксированным планом без метки. Смена сценария по ходу — событие с названным исходом, а не тихий поворот. Плюс конвейер ревью с детерминированным гейтом, сверкой со спеками, враждебными постановками, эксплуатационным постмортемом и обязательным триажем. OpenSpec нужен сценарию решения, и плагин сам его заводит скиллом openspec; разведка обходится без него. Задача принимается и обычным текстом. Плагины av-dev-docs и av-dev-tasks опциональны: первый даёт документы канона, из которых проходы читают проектную конкретику, второй — учёт задач; без них прогон деградирует поразрядно и называет это строкой.",
  "author": {
    "name": "Anton Vakhrushev",
    "email": "anwinged@gmail.com"
  }
 }
@@ -1,8 +0,0 @@
 {
  "name": "av-dev-docs",
  "description": "Документация проекта: канон раскладки (CLAUDE.md плюс docs/ — паспорт, архитектура, схема БД, безопасность, конвенции, разведка, ADR, журнал ревью), роли документов и правило единственного дома. Три операции одной машиной сравнения — check, adopt, upgrade — со скриптом docs.py; заведение нового проекта интервью по брифу; ведение содержимого по ходу разработки: синк после сделанной задачи, ADR промоутом из архивного design.md, записка разведки, запись дефекта в журнал ревью. Смысловое, чего скрипт не видит, судит скилл healthcheck двумя агентами разом — doc-consistency (документы между собой и с openspec) и doc-code-drift (факты против кода); язык документов вычитывает агент doc-wording. Задач не ведёт — это плагин av-dev-tasks, и он опционален.",
  "author": {
    "name": "Anton Vakhrushev",
    "email": "anwinged@gmail.com"
  }
 }
@@ -1,8 +0,0 @@
 {
  "name": "av-dev-tasks",
  "description": "Задачи и цели каталогом markdown-файлов: одна запись — файл в items/ плюс строка ровно в одном индексе, у записи тип (goal, feature, fix, chore, research), и тип решает, каких разделов она требует и что с ней можно делать. Заведение из диалога с фильтром и дедупом, разбор находок ревью в задачи, декомпозиция на независимо полезные части, гигиена полей, согласованность индексов скриптом tasks.py. Приоритет — явный порядок строк в беклоге, и расставляет его скилл groom: интерактивный разбор на два вопроса, что сейчас самое важное и что перестало быть важным. Готовность записи к работе проверяет команда ready. Записи вычитывают два прохода: task-form (форма записи) и task-wording (язык). Канон документов ведёт плагин av-dev-docs, он опционален. Задач не выполняет — этим занимается конвейер проекта.",
  "author": {
    "name": "Anton Vakhrushev",
    "email": "anwinged@gmail.com"
  }
 }
@@ -0,0 +1,8 @@
 {
  "name": "av-dev",
  "description": "Личный процесс разработки одним плагином: документы проекта, учёт работ и работа по задачам. Документы — канон раскладки (CLAUDE.md плюс docs/: паспорт, архитектура, схема БД, безопасность, конвенции, разведка, ADR, журнал ревью), три операции одной машиной сравнения в doc-canon (check, adopt, upgrade) со скриптом docs.py, заведение нового проекта интервью в doc-init, ведение содержимого по ходу разработки в doc-sync, суд о смысловом здоровье в doc-healthcheck двумя агентами разом. Учёт — задачи и цели каталогом markdown-файлов в task-track, у записи тип (goal, feature, fix, chore, research), и тип решает её схему; приоритет расставляет интерактивный task-groom порядком строк. Работа — одна задача от постановки до закрытия скиллом code-resolve: точка входа одна, сценария три (решение циклом SDD с чекпоинтом, разведка без кода, обслуживание без change), и выбирает сценарий сам скилл, прочитав постановку; плюс конвейер ревью code-review с детерминированным гейтом, сверкой со спеками и обязательным триажем, плюс code-openspec, который заводит и проверяет openspec/. Версия раскладки и настройки живут в .av-dev.toml в корне репозитория. Части включаются следом в проекте, а не установкой: нет docs/ — документы не ведутся, нет каталога задач — учёт остаётся владельцу, нет openspec/ — его заводит сценарий решения. Коммиты — отдельный плагин av-dev-git.",
  "author": {
    "name": "Anton Vakhrushev",
    "email": "anwinged@gmail.com"
  }
 }
@@ -1,6 +1,6 @@
 ---
 name: doc-code-drift
-description: "Сверка документов канона с кодом по закрытому перечню проверяемых фактов: имя основной ветки и команды из CLAUDE.md, запреты с путями, testdata и временный каталог, путь миграций из .docs.json, внешние зависимости поимённо в architecture.md против манифеста, настройки с числовым значением в database.md против конфига и кода, единые точки проекта против реального числа реализаций, capability против существующих модулей. Отвечает на «этот факт ещё верен», а не «эта архитектура правильная». Читает весь репозиторий, гоняет только читающие команды. Отдаёт готовые формулировки и ничего не правит сам. Согласованность документов между собой смотрит агент doc-consistency. Зовётся скиллом av-dev-docs:healthcheck — на весь канон разом; он же зовётся шагом adopt и шагом upgrade. Только чтение."
+description: "Сверка документов канона с кодом по закрытому перечню проверяемых фактов: имя основной ветки и команды из CLAUDE.md, запреты с путями, testdata и временный каталог, путь миграций из .docs.json, внешние зависимости поимённо в architecture.md против манифеста, настройки с числовым значением в database.md против конфига и кода, единые точки проекта против реального числа реализаций, capability против существующих модулей. Отвечает на «этот факт ещё верен», а не «эта архитектура правильная». Читает весь репозиторий, гоняет только читающие команды. Отдаёт готовые формулировки и ничего не правит сам. Согласованность документов между собой смотрит агент doc-consistency. Зовётся скиллом av-dev:doc-healthcheck — на весь канон разом; он же зовётся шагом adopt и шагом upgrade. Только чтение."
 tools: Read, Grep, Glob, Bash
 model: sonnet
 color: green
@@ -1,6 +1,6 @@
 ---
 name: doc-consistency
-description: "Сверка документов канона между собой и с openspec: один факт, живущий в двух домах, прямое противоречие между документами (периметр, зависимости, обратимость), поведение системы, осевшее в architecture.md вместо спек, capability без обзора или с пересказом требований, число без провенанса в research, ADR без ссылки на источник (архивный design.md либо записка разведки) и без парного статуса при замене, заглушка вместо честной строки в пустом слоте. Читает docs/ и openspec/, кода не читает. Отдаёт готовые формулировки и ничего не правит сам. Соответствие документов коду смотрит агент doc-code-drift, язык — doc-wording. Зовётся скиллом av-dev-docs:healthcheck — на весь канон разом; он же зовётся шагом adopt и шагом upgrade. На отдельной задаче и на синке документации не звать. Только чтение."
+description: "Сверка документов канона между собой и с openspec: один факт, живущий в двух домах, прямое противоречие между документами (периметр, зависимости, обратимость), поведение системы, осевшее в architecture.md вместо спек, capability без обзора или с пересказом требований, число без провенанса в research, ADR без ссылки на источник (архивный design.md либо записка разведки) и без парного статуса при замене, заглушка вместо честной строки в пустом слоте. Читает docs/ и openspec/, кода не читает. Отдаёт готовые формулировки и ничего не правит сам. Соответствие документов коду смотрит агент doc-code-drift, язык — doc-wording. Зовётся скиллом av-dev:doc-healthcheck — на весь канон разом; он же зовётся шагом adopt и шагом upgrade. На отдельной задаче и на синке документации не звать. Только чтение."
 tools: Read, Grep, Glob
 model: opus
 color: yellow
@@ -15,11 +15,11 @@ color: yellow
 машина, а что человек», и её правая колонка — твой устав дословно.
 Карта домов, по которой ты судишь о правиле 1, — дословная копия канона; дом её
-`av-dev-docs/skills/canon/references/canon.md`, раздел «Правило единственного
+`av-dev/skills/doc-canon/references/canon.md`, раздел «Правило единственного
 дома», и правится она там. Здесь она стоит потому, что ты работаешь в
 репозитории проекта, где плагина может не быть вовсе.
-<!-- копия: карта-домов из av-dev-docs/skills/canon/references/canon.md -->
+<!-- копия: карта-домов из av-dev/skills/doc-canon/references/canon.md -->
 | Факт | Дом |
 | --- | --- |
 | поведение системы | `openspec/specs/<capability>/spec.md` |
@@ -1,6 +1,6 @@
 ---
 name: doc-wording
-description: "Вычитка языка документов проекта по информационному стилю — паспорт, архитектура, конвенции, безопасность, решения ADR, записки разведки, CLAUDE.md. Смотрит отглагольные существительные и страдательный залог, оценку без факта, стоп-слова и канцелярит, «одна мысль — одно предложение», англицизм при живом русском слове, жаргон и метафоры вместо прямого называния, термин, которого нет в документах проекта, транслит в имени файла. Отдаёт готовые формулировки на замену и ничего не правит сам. Записи каталога задач вычитывает отдельный агент task-wording, их форму — task-form. Зовётся по названной пачке правленных документов, а не на весь канон: последним шагом синка документации (av-dev-docs:docs), шагом заведения проекта (av-dev-docs:init), шагами adopt и upgrade скилла av-dev-docs:canon. Скилл healthcheck его не зовёт — там сверка утверждений, а не языка. Только чтение."
+description: "Вычитка языка документов проекта по информационному стилю — паспорт, архитектура, конвенции, безопасность, решения ADR, записки разведки, CLAUDE.md. Смотрит отглагольные существительные и страдательный залог, оценку без факта, стоп-слова и канцелярит, «одна мысль — одно предложение», англицизм при живом русском слове, жаргон и метафоры вместо прямого называния, термин, которого нет в документах проекта, транслит в имени файла. Отдаёт готовые формулировки на замену и ничего не правит сам. Записи каталога задач вычитывает отдельный агент task-wording, их форму — task-form. Зовётся по названной пачке правленных документов, а не на весь канон: последним шагом синка документации (av-dev:doc-sync), шагом заведения проекта (av-dev:doc-init), шагами adopt и upgrade скилла av-dev:doc-canon. Скилл healthcheck его не зовёт — там сверка утверждений, а не языка. Только чтение."
 tools: Read, Grep, Glob
 model: sonnet
 color: green
@@ -34,7 +34,7 @@ color: green
 Дом — `shared/language.md` в репозитории плагинов, и там же объяснено, зачем
 стиль вообще нужен. Здесь только то, что нужно тебе для работы.
-<!-- копия: язык-правила из shared/language.md -->
+<!-- копия: язык-правила из av-dev/shared/language.md -->
 У каждого правила названа причина: она же говорит, где правило **не**
 применяется.
@@ -184,7 +184,7 @@ color: green
 **Машинной проверке — вообще ничего.** Всё, что ловит `docs.py check` (пути
 канона, файлы вне канона, имена файлов, битые ссылки, версия канона, нетронутые
 плейсхолдеры, маркеры долга) и что ловит `openspec.py check` скилла
-`av-dev-code:openspec` (форма `openspec/config.yaml`), **не пиши даже
+`av-dev:code-openspec` (форма `openspec/config.yaml`), **не пиши даже
 строкой**: это не потерянная находка, а уже проверенное. Повторять машинную
 проверку словами — заводить второй дом для одного правила.
@@ -197,7 +197,7 @@ color: green
 ## Порог вмешательства
-<!-- копия: порог-правки из shared/language.md -->
+<!-- копия: порог-правки из av-dev/shared/language.md -->
 **Правка без нарушенного правила не делается.** Текст, переписанный «чтобы
 звучало лучше», обесценивает список замечаний: когда половина из них вкусовая,
@@ -218,7 +218,7 @@ color: green
 ## Доклад
-<!-- копия: вычитка-доклад из shared/language.md -->
+<!-- копия: вычитка-доклад из av-dev/shared/language.md -->
 Находки по одной, в порядке важности: залог и оценки → жаргон и англицизмы →
 стоп-слова. Первые меняют, **что** читатель понимает; последние — только сколько
@@ -152,7 +152,7 @@ color: yellow
 **Молча отменённое решение ADR больше не проверяет никто, и это сознательно.**
 Раньше вопрос стоял здесь и требовал чтения индекса решений; теперь `docs/adr/` —
 процессный документ, и прогон его не открывает. Расхождение изменения с записанным
-решением ловит сверка документации — скилл `av-dev-docs:healthcheck`. Строка об
+решением ловит сверка документации — скилл `av-dev:doc-healthcheck`. Строка об
 этом обязательна в твоих границах покрытия.
 **Карты проекта и графа зависимостей у тебя нет** — они стоят широкого входа, то
@@ -195,7 +195,7 @@ color: green
 **Ты меряешь изменение по двум независимым осям и называешь обе.** Метка — не
 ответ на один вопрос, а максимум по двум измерениям.
-Ниже рабочая выжимка. Дом правила — скилл `av-dev-code:review`,
+Ниже рабочая выжимка. Дом правила — скилл `av-dev:code-review`,
 `references/review-levels.md`: там разобрано, почему оси именно эти, чем `small`
 дешевле `medium` и какие доли служат проверкой правила. Открывай его, когда
 метка **спорная или оспорена**; на обычной задаче хватает того, что здесь.
@@ -207,7 +207,7 @@ severity:
 1. **Решения проекта не сверялись.** `docs/adr.*` — процессный документ, прогон
   его не открывает. Расхождение изменения с записанным решением ловит сверка
-   документации — скилл `av-dev-docs:healthcheck`, а не ревью.
+   документации — скилл `av-dev:doc-healthcheck`, а не ревью.
 2. **Записанные наблюдения проекта не использовались.** `docs/research.*` — тоже
   процессный. Всякое число в находках снято проходом на этом прогоне; числа без
   приложенной команды замера в отчёте быть не должно.
@@ -148,7 +148,7 @@ color: green
 ## Порог вмешательства
-<!-- копия: порог-правки из shared/language.md -->
+<!-- копия: порог-правки из av-dev/shared/language.md -->
 **Правка без нарушенного правила не делается.** Текст, переписанный «чтобы
 звучало лучше», обесценивает список замечаний: когда половина из них вкусовая,
@@ -42,7 +42,7 @@ color: green
 Дом — `shared/language.md` в репозитории плагинов, и там же объяснено, зачем
 стиль вообще нужен. Здесь только то, что нужно тебе для работы.
-<!-- копия: язык-правила из shared/language.md -->
+<!-- копия: язык-правила из av-dev/shared/language.md -->
 У каждого правила названа причина: она же говорит, где правило **не**
 применяется.
@@ -209,7 +209,7 @@ color: green
 ## Порог вмешательства
-<!-- копия: порог-правки из shared/language.md -->
+<!-- копия: порог-правки из av-dev/shared/language.md -->
 **Правка без нарушенного правила не делается.** Текст, переписанный «чтобы
 звучало лучше», обесценивает список замечаний: когда половина из них вкусовая,
@@ -230,7 +230,7 @@ color: green
 ## Доклад
-<!-- копия: вычитка-доклад из shared/language.md -->
+<!-- копия: вычитка-доклад из av-dev/shared/language.md -->
 Находки по одной, в порядке важности: залог и оценки → жаргон и англицизмы →
 стоп-слова. Первые меняют, **что** читатель понимает; последние — только сколько
@@ -36,8 +36,8 @@
 Плагины `av-dev` ставятся порознь, и ни один не вправе считать, что сосед на
 месте.
-**Чужой скилл зовётся полным именем** — `av-dev-docs:canon`, `av-dev-tasks:tasks`,
+**Чужой скилл зовётся полным именем** — `av-dev:doc-canon`, `av-dev:task-track`,
-`av-dev-code:review`. Короткое имя может разрешиться в устаревшую проектную копию
+`av-dev:code-review`. Короткое имя может разрешиться в устаревшую проектную копию
 из `.claude/skills/`, и подмены не будет видно ни в докладе, ни в поведении.
 **Путь в дерево чужого плагина не пишется никогда.** `$CLAUDE_PLUGIN_ROOT` ведёт
@@ -1,5 +1,5 @@
 ---
-name: openspec
+name: code-openspec
 description: "Завести и настроить OpenSpec в проекте — openspec init --tools claude, замена закомментированного примера в openspec/config.yaml на настройку канонической формы (язык, правила именования capability, придирки валидатора, адреса паспорта и CLAUDE.md), проверка формы своим скриптом openspec.py (имя файла, схема, незаменённый пример, адреса документов, ключи rules против артефактов схемы) и сверка слепка с живой версией инструмента. Использовать, когда в проекте нет каталога openspec/, когда config.yaml остался примером из коробки, когда заводят новый проект или переводят чужой и дошли до шага OpenSpec, а также когда конвейер отказался работать без источника требований. Каталог openspec нужен именно конвейеру: без него не работают ни opsx:propose, ни ревью дизайна, ни сверка требований."
 ---
@@ -44,7 +44,7 @@ openspec init --tools claude
 проекта.
 Сюда же — **требования к форме `proposal` и `design`**, на которых стоит чекпоинт
-скилла `av-dev-code:resolve`: объяснение человеку собирается из этих двух
+скилла `av-dev:code-resolve`: объяснение человеку собирается из этих двух
 артефактов, и требование к ним обязано применяться в момент, когда их пишут, а не
 вспоминаться шагом позже. Образец их содержит.
@@ -116,10 +116,10 @@ python3 $os form                   # слепок формы против жив
 ## Кто зовёт этот скилл
- `av-dev-docs:init` — шагом заведения нового проекта, до первого документа;
+- `av-dev:doc-init` — шагом заведения нового проекта, до первого документа;
- `av-dev-docs:canon` в режиме `adopt` — если на переводимом проекте каталога нет
+- `av-dev:doc-canon` в режиме `adopt` — если на переводимом проекте каталога нет
  или `config.yaml` остался примером;
- `av-dev-code:resolve` и `av-dev-code:review` — не вызовом по ходу, а отсылкой:
+- `av-dev:code-resolve` и `av-dev:code-review` — не вызовом по ходу, а отсылкой:
  OpenSpec у обоих жёсткая предпосылка, и на проекте без каталога оба посылают
  сюда вместо того, чтобы заводить его руками;
 - человек — когда конвейер отказался работать без источника требований.
@@ -127,13 +127,13 @@ python3 $os form                   # слепок формы против жив
 **Копия.** Дом правила — `shared/plugin-boundary.md` в репозитории плагинов.
 Правится дом, а не этот файл.
-<!-- копия: граница-плагинов из shared/plugin-boundary.md -->
+<!-- копия: граница-плагинов из av-dev/shared/plugin-boundary.md -->
 Плагины `av-dev` ставятся порознь, и ни один не вправе считать, что сосед на
 месте.
-**Чужой скилл зовётся полным именем** — `av-dev-docs:canon`, `av-dev-tasks:tasks`,
+**Чужой скилл зовётся полным именем** — `av-dev:doc-canon`, `av-dev:task-track`,
-`av-dev-code:review`. Короткое имя может разрешиться в устаревшую проектную копию
+`av-dev:code-review`. Короткое имя может разрешиться в устаревшую проектную копию
 из `.claude/skills/`, и подмены не будет видно ни в докладе, ни в поведении.
 **Путь в дерево чужого плагина не пишется никогда.** `$CLAUDE_PLUGIN_ROOT` ведёт
@@ -44,7 +44,7 @@ context: |
  первым молча, и заметно это становится в предложении, которое уже написано.
  Ревью: правило выбора метки и состав проходов здесь не пересказываем — их дом
-  скилл av-dev-code:review, проектная настройка — docs/review.md.
+  скилл av-dev:code-review, проектная настройка — docs/review.md.
  Конвенции кода: механизированное проверяет гейт, прозой остаётся
  docs/conventions/. Ни состав шагов гейта, ни перечень конвенций здесь не
@@ -78,7 +78,7 @@ rules:
 узнаёт их падением `openspec validate --strict`.
 **Правила для `proposal` и `design` держат чекпоинт скилла
-`av-dev-code:resolve`.** Там работа останавливается и человеку объясняют, в
+`av-dev:code-resolve`.** Там работа останавливается и человеку объясняют, в
 чём проблема и как её решают, — а объяснение **собирается из этих двух
 артефактов**, а не сочиняется заново: третий пересказ одного и того же разошёлся
 бы с обоими. Требование поэтому стоит здесь, в момент порождения артефакта, а не
@@ -114,7 +114,7 @@ def rules_keys(live: str) -> list[str]:
    Идём от строки `rules:` до следующего ключа нулевой колонки, а не ищем
    отступ по всему файлу: блок `context: |` — литеральный скаляр, внутри него
-    строки вида «Language: Russian» и «av-dev-code:review» выглядят
+    строки вида «Language: Russian» и «av-dev:code-review» выглядят
    ключами и дали бы находку на ровном месте. Проверено на живом конфиге,
    который так и падал.
    """
@@ -1,5 +1,5 @@
 ---
-name: resolve
+name: code-resolve
 description: "Взять одну задачу и довести её до закрытия. Одна точка входа, три сценария, и выбирает сценарий сам скилл, прочитав постановку. Способ известен и меняется поведение — сценарий решения: цикл Spec Driven Development (opsx propose → разметка → ревью дизайна → чекпоинт с объяснением человеческим языком → opsx apply → ревью кода → archive → синк документации → коммит → закрытие). Способ известен, а спека не меняется (тип chore: тулчейн, зависимости, сборка, гит-хуки, перенос, чистка) — сценарий обслуживания: правка → гейт со сверкой состава проверок → ревью фиксированным планом без change (autotests, operations, плюс conventions, если тронут код) → синк документации → коммит → закрытие; планового стопа нет, change не заводится. Нашлась дельта-спека — задача оказалась шире своего типа: стоп с объяснением простым языком и двумя решениями человека, переформулировать запись в fix или feature и решать её процессом того типа следующим прогоном либо прекратить работу. Способа нет, постановка мутная, тип research — сценарий разведки: вопрос и рамки → чтение документов, кода и внешних источников (можно opsx:explore) → чекпоинт вариантов: 2–4 способа решить, цена каждого, что становится невозможным, рекомендация → ответ уезжает в документы канона, исход — в задачи → вычитка написанного → коммит → закрытие. Разведка кода не пишет и change не заводит, а выбранный способ реализуется следующим прогоном. На входе путь к файлу задачи, её слаг или просто текст. Использовать, когда просят взять, сделать или решить задачу, обновить зависимости или сборку, разобраться, изучить, сравнить подходы, проработать сырую идею, ответить на вопрос из беклога."
 ---
@@ -36,9 +36,9 @@ description: "Взять одну задачу и довести её до за
  `openspec validate --strict`). **Проект без OpenSpec этим скиллом не ведётся** —
  подключай OpenSpec, а не вырождай цикл сценария; почему ветка деградации здесь
  не
-  пишется, сказано в `av-dev-code:review`, раздел «Предпосылки», и дом у этого
+  пишется, сказано в `av-dev:code-review`, раздел «Предпосылки», и дом у этого
  довода там. Заводить руками не надо: каталог и настройку в `config.yaml`
-  делает скилл `av-dev-code:openspec`. **Сценариям разведки и обслуживания
+  делает скилл `av-dev:code-openspec`. **Сценариям разведки и обслуживания
  OpenSpec не нужен** — они не заводят change; `opsx:explore` берётся разведкой,
  если плагин есть.
 - **Проектные копии этих скиллов и агентов удаляются при установке плагина**
@@ -54,13 +54,13 @@ description: "Взять одну задачу и довести её до за
 общее для всех, кто зовёт чужое, и ни один плагин им не владеет. Правится дом, а
 не этот файл.
-<!-- копия: граница-плагинов из shared/plugin-boundary.md -->
+<!-- копия: граница-плагинов из av-dev/shared/plugin-boundary.md -->
 Плагины `av-dev` ставятся порознь, и ни один не вправе считать, что сосед на
 месте.
-**Чужой скилл зовётся полным именем** — `av-dev-docs:canon`, `av-dev-tasks:tasks`,
+**Чужой скилл зовётся полным именем** — `av-dev:doc-canon`, `av-dev:task-track`,
-`av-dev-code:review`. Короткое имя может разрешиться в устаревшую проектную копию
+`av-dev:code-review`. Короткое имя может разрешиться в устаревшую проектную копию
 из `.claude/skills/`, и подмены не будет видно ни в докладе, ни в поведении.
 **Путь в дерево чужого плагина не пишется никогда.** `$CLAUDE_PLUGIN_ROOT` ведёт
@@ -81,8 +81,8 @@ description: "Взять одну задачу и довести её до за
 <!-- /копия: граница-плагинов -->
-Скилл зовёт `av-dev-code:review`, `av-dev-docs:docs` и
+Скилл зовёт `av-dev:code-review`, `av-dev:doc-sync` и
-`av-dev-tasks:tasks`. Чем оборачивается отсутствие каждого — на самих шагах и в
+`av-dev:task-track`. Чем оборачивается отсутствие каждого — на самих шагах и в
 разделе «Границы».
 Перед стартом прочитай `CLAUDE.md` проекта и то, на что он ссылается, если ещё
@@ -91,7 +91,7 @@ description: "Взять одну задачу и довести её до за
 карта «что где» — `references/project-facts.md` конвейера ревью.
 **Документов канона нет — проект к нему не приведён.** Скажи это строкой и
-предложи скилл `av-dev-docs:canon`: одна операция на проект против поразрядной
+предложи скилл `av-dev:doc-canon`: одна операция на проект против поразрядной
 деградации на каждой задаче. Работу при этом не останавливай.
 ## Вход
@@ -101,7 +101,7 @@ description: "Взять одну задачу и довести её до за
 лезь и приоритеты не интерпретируй: что делать дальше, решает не этот скилл.
 **Запись из каталога сперва проверяется на готовность, и проверяет её машина.**
-Вызови Skill `av-dev-tasks:tasks` и попроси прогнать `ready <слаг>`: он смотрит
+Вызови Skill `av-dev:task-track` и попроси прогнать `ready <слаг>`: он смотрит
 тип, цель у `feature`, пустой ли раздел вопросов и собраны ли разделы схемы
 типа. Судить это глазами нельзя — ровно тот случай, где машина дешевле и точнее,
 а цена ошибки отложенная: недостающие критерии приёмки обнаружатся на приёмке,
@@ -172,7 +172,7 @@ description: "Взять одну задачу и довести её до за
  запись и решать процессом того типа следующим прогоном** либо **прекратить
  работу**. Третьего — «доделать как обслуживание» — нет. Исход в обоих случаях
  «меняется спека»; сделанное остаётся в рабочем дереве незакоммиченным, тип
-  меняет `av-dev-tasks:tasks` и только после ответа. Подробно —
+  меняет `av-dev:task-track` и только после ответа. Подробно —
  [maintain.md](references/maintain.md), раздел «Дельта нашлась по ходу»;
 - **обслуживание → разведка**: форма правки неизвестна (мажорное обновление,
  смена сборщика). **Стоп** с исходом «нужна разведка», по тому же основанию,
@@ -195,7 +195,7 @@ description: "Взять одну задачу и довести её до за
 ```mermaid
 flowchart TD
    in["вход: файл, слаг или текст"]
-    ready["ready: готовность записи<br/>av-dev-tasks:tasks"]
+    ready["ready: готовность записи<br/>av-dev:task-track"]
    fork{"есть очевидный<br/>способ решения?"}
    fork2{"меняется ли<br/>спека?"}
    solve["сценарий решения<br/>references/solve.md<br/>код, ревью, архив, коммит"]
@@ -259,7 +259,7 @@ flowchart TD
   что успели узнать, где остановились и почему.
 **Что остатком не является — правило живёт не здесь.** Канонический текст с обеими
-оговорками — в плагине `av-dev-tasks`, скилл `av-dev-tasks:groom`, раздел
+оговорками — в плагине `av-dev-tasks`, скилл `av-dev:task-groom`, раздел
 `## Вопрос, блокер, необратимое`, подраздел «Отличать вопрос от застревания».
 Правило принадлежит управлению задачами, потому что решает **сделана задача или
 вышла**, — это исход планирования, а не исполнения. **Ссылайся, не
@@ -295,10 +295,10 @@ flowchart TD
 - **Беклогом, целями и приоритетами.** Задача приходит извне. Скилл её не
  выбирает, не приоритизирует, не заводит и не переоценивает.
 - **Форматом задач и документов.** Индексы и документы канона руками не правятся,
-  путь к чужому скрипту не выдумывается: этим владеют `av-dev-tasks:tasks` и
+  путь к чужому скрипту не выдумывается: этим владеют `av-dev:task-track` и
-  `av-dev-docs:docs`. Закрытие — работа этого скилла, и это осознанное решение с
+  `av-dev:doc-sync`. Закрытие — работа этого скилла, и это осознанное решение с
  названной ценой: **приёмщик и исполнитель совпали**. Закрытие поэтому **не окончательно** — человек на
-  груминге (`av-dev-tasks:groom`) возвращает задачу `reopen` с причиной, а доклад
+  груминге (`av-dev:task-groom`) возвращает задачу `reopen` с причиной, а доклад
  по критериям приёмки становится единственным, по чему приёмка вообще возможна.
 - **Определением ценности.** «Нужна ли эта функциональность» — не вопрос этого
  скилла ни на одном шаге и ни в одном сценарии. Чекпоинт решения спрашивает «так
@@ -89,7 +89,7 @@
 - **переформулировать запись** — тип меняется на названный, и дальше задача идёт
  **процессом своего типа**: сценарием решения, следующим прогоном. Формат записи
-  правит `av-dev-tasks:tasks`, а не ты: у нового типа своя схема разделов, и
+  правит `av-dev:task-track`, а не ты: у нового типа своя схема разделов, и
  готовность её проверит `ready` — той же машиной, что и на входе. Прогон
  обслуживания на этом кончается, исход — «меняется спека»;
 - **прекратить работу** — человек не готов расширять задачу сейчас. Исход тот
@@ -113,7 +113,7 @@
 Как и разведке, обслуживанию OpenSpec не нужен: оно не заводит change, не пишет
 дельта-спек и не архивирует. Ни один из проходов его плана ревью на дельта-спеки
-не завязан — это сказано и в `av-dev-code:review`, раздел «Прогон без change».
+не завязан — это сказано и в `av-dev:code-review`, раздел «Прогон без change».
 Каталога в проекте нет — обслуживание идёт целиком, и деградацией это не
 является.
@@ -145,10 +145,10 @@ flowchart TD
    s1["1. прочитать задачу<br/>критерии приёмки и границы"]
    s2["2. сделать правку<br/>гейт тронут — сверить состав, не цвет"]
    s3["3. гейт проекта до зелёного"]
-    s4["4. ревью фиксированным планом<br/>av-dev-code:review, без change"]
+    s4["4. ревью фиксированным планом<br/>av-dev:code-review, без change"]
-    s5["5. синк документации — av-dev-docs:docs"]
+    s5["5. синк документации — av-dev:doc-sync"]
    s6["6. коммит работы — av-dev-git:commit"]
-    s7["7. закрыть задачу — av-dev-tasks:tasks,<br/>вторым коммитом учёта"]
+    s7["7. закрыть задачу — av-dev:task-track,<br/>вторым коммитом учёта"]
    out["исход назван"]
    in --> s1 --> s2 --> s3 --> s4 --> s5 --> s6 --> s7 --> out
@@ -214,7 +214,7 @@ ADR: список источников канон закрыл двумя — а
 **Проверка на «заодно».** Обслуживание любит склеиваться в пачку — обновить
 зависимости, переписать сборку и убрать мёртвый код одной задачей. Не мерджится
 порознь — это несколько задач: объявляй исход **не доведена** с причиной «задача
-не одна» и останавливайся. Нарезкой владеет `av-dev-tasks:tasks`, а не ты, и
+не одна» и останавливайся. Нарезкой владеет `av-dev:task-track`, а не ты, и
 делать её по ходу нельзя — получится один коммит, в котором обновление
 зависимости не отделить от чистки.
@@ -247,7 +247,7 @@ ADR: список источников канон закрыл двумя — а
 ### 4. Ревью — план фиксирован сценарием
-Вызови Skill **`av-dev-code:review`**, дав базу диффа, режим и **план сценария**.
+Вызови Skill **`av-dev:code-review`**, дав базу диффа, режим и **план сценария**.
 Change ты не передаёшь — его нет.
 **Разметчик здесь не зовётся, и это правило, а не пропуск.** Обе оси, по которым
@@ -302,11 +302,11 @@ Change ты не передаёшь — его нет.
 Отработка — как в решении: помеченное `инлайн` чини сам и не логируй, `развилка`
 — вопросом в запись. После правок снова гейт. Отложенные находки собери в секцию
-доклада `Урожай`; задачи из него заводит `av-dev-tasks:tasks`, не ты.
+доклада `Урожай`; задачи из него заводит `av-dev:task-track`, не ты.
 ### 5. Синк документации — главный шаг этого сценария
-**Вызови Skill `av-dev-docs:docs`.** Правило то же и такое же жёсткое:
+**Вызови Skill `av-dev:doc-sync`.** Правило то же и такое же жёсткое:
 **принуждённое отрицание** — каждый документ канона либо назван обновлённым, либо
 получает «не требуется, потому что…». Нетронутые группируются одной строкой.
@@ -331,7 +331,7 @@ Change ты не передаёшь — его нет.
 «ничего не решали, поменяли оснастку».
 Список документов и их триггеров здесь не дублируется — он в чек-листе скилла
-`av-dev-docs:docs`; копия уже однажды разошлась с оригиналом. Плагина в проекте
+`av-dev:doc-sync`; копия уже однажды разошлась с оригиналом. Плагина в проекте
 нет — иди за перечнем в свой reference,
 [references/project-facts.md](../../review/references/project-facts.md) конвейера
 ревью, добавь `adr/` руками и скажи строкой, что синк сделан по перечню
@@ -348,7 +348,7 @@ Change ты не передаёшь — его нет.
 ### 7. Закрыть задачу — после коммита, не раньше
-**Вызови Skill `av-dev-tasks:tasks`** и попроси закрыть задачу как реализованную.
+**Вызови Skill `av-dev:task-track`** и попроси закрыть задачу как реализованную.
 Порядок обязателен: закрытие удаляет файл задачи, и сделанное до коммита оно
 оставило бы задачу закрытой без следа работы, если шаг 6 упадёт.
@@ -363,13 +363,13 @@ Change ты не передаёшь — его нет.
  сценария, у которой есть проверяемый признак, и она же единственная, которую
  выгодно нарушить молча.
 - **Не переписывает запись задачи сам.** Тип ты **предлагаешь** с причиной,
-  меняет его `av-dev-tasks:tasks` и только после ответа человека: исполнитель,
+  меняет его `av-dev:task-track` и только после ответа человека: исполнитель,
  переклеивший тип на ходу, назначает себе другой процесс и другую глубину
  проверки.
 - **Не решает, нужна ли работа.** Как и оба соседних сценария: «надо ли» —
  вопрос человека.
 - **Не нарезает пачку на задачи.** «Обновить зависимости и переписать сборку» —
-  это `av-dev-tasks:tasks` и его правила нарезки.
+  это `av-dev:task-track` и его правила нарезки.
 - **Не выбирает форму правки, когда она незнакома, и не принимает решений с
  ценой.** Мажорное обновление, смена инструмента, намеренный отказ идут
  разведкой: там есть чекпоинт вариантов и законный источник для ADR, здесь нет
@@ -26,13 +26,13 @@
 ## Кого зовёт этот сценарий
-`av-dev-docs:docs` (ответ уезжает в документы канона), `av-dev-tasks:tasks`
+`av-dev:doc-sync` (ответ уезжает в документы канона), `av-dev:task-track`
 (задачи заводятся и уточняются), `av-dev-git:commit`. Правило обращения к соседям
 и ветка «вызов не разрешился» — общие, они в [SKILL.md](../SKILL.md).
 **Отсутствие канона бьёт по разведке сильнее, чем по решению**, и сказать об этом
 строкой мало: без документов у ответа нет дома, и знание осядет в переписке.
-Назови исход и предложи `av-dev-docs:canon`; работу не останавливай, но адрес
+Назови исход и предложи `av-dev:doc-canon`; работу не останавливай, но адрес
 ответа тогда выбираешь сам и говоришь об этом вслух.
 ## Что этот сценарий требует от входа
@@ -47,7 +47,7 @@
 причиной «запись это сырьё»: у неё нет вопроса, а разведка без вопроса
 превращается в чтение всего подряд с отчётом «интересно, но неприменимо».
 Дописывать вопрос за автора не твоя работа — этим занят штурм сырья в
-`av-dev-tasks:tasks`. Назови, чего не хватает, и остановись.
+`av-dev:task-track`. Назови, чего не хватает, и остановись.
 **Разведка пришла текстом — сформулируй вопрос сам одной фразой и покажи
 формулировку в первой же реплике.** Разведка, чей вопрос не назван вслух,
@@ -61,11 +61,11 @@ flowchart TD
    s1["1. вопрос и рамки<br/>сырьё без «Вопроса» — отказ"]
    s2["2. разведка: документы, код,<br/>внешние источники, opsx:explore"]
    s3(["3. ЧЕКПОИНТ: варианты<br/>2–4 способа, цена каждого,<br/>что становится невозможным"])
-    s4["4. ответ в документы канона<br/>av-dev-docs:docs"]
+    s4["4. ответ в документы канона<br/>av-dev:doc-sync"]
-    s5["5. задачи: завести и уточнить<br/>av-dev-tasks:tasks"]
+    s5["5. задачи: завести и уточнить<br/>av-dev:task-track"]
    s6["6. вычитка написанного:<br/>документы и записи задач"]
    s7["7. гейт проекта, затем коммит<br/>av-dev-git:commit"]
-    s8["8. закрыть разведку — av-dev-tasks:tasks,<br/>вторым коммитом учёта"]
+    s8["8. закрыть разведку — av-dev:task-track,<br/>вторым коммитом учёта"]
    out["исход назван: знание, задачи,<br/>отказ или «не доведена»"]
    in --> s1 --> s2 --> s3
@@ -103,11 +103,11 @@ git и читается диффом, а второй стоп на каждой
  **читающий** прогон (запрос, замер, скрипт в песочнице), чей результат уезжает
  в ответ с провенансом и который ничего не оставляет в репозитории.
 - **Приоритетом.** Заведённая задача встаёт в конец своей секции; где ей стоять
-  в очереди, решает человек на груминге (`av-dev-tasks:groom`). Разведка, сама
+  в очереди, решает человек на груминге (`av-dev:task-groom`). Разведка, сама
  ставящая свой исход первым в беклоге, назначает приоритет тому, что только что
  придумала.
 - **Форматом задач и документов.** Индексы и документы руками не правятся: их
-  ведут `av-dev-tasks:tasks` и `av-dev-docs:docs`. Твоё — содержание ответа, их —
+  ведут `av-dev:task-track` и `av-dev:doc-sync`. Твоё — содержание ответа, их —
  форма и дом.
 - **Определением ценности.** «Нужно ли это делать вообще» — вопрос человека.
  Разведка отвечает «как это можно сделать и чего каждый способ стоит».
@@ -243,7 +243,7 @@ git и читается диффом, а второй стоп на каждой
 ### 4. Ответ в документы канона
-**Вызови Skill `av-dev-docs:docs`**: он владеет содержимым документов канона.
+**Вызови Skill `av-dev:doc-sync`**: он владеет содержимым документов канона.
 Передай ему ответ, адрес из шага 1 и провенанс каждого числа — писать содержание
 за тебя он не будет, но дом и форму держит он. Вычитка языка — тоже его агент, но
 момент её назван отдельно, шагом 6: пачка собирается из шагов 4 и 5 и до конца
@@ -275,7 +275,7 @@ git и читается диффом, а второй стоп на каждой
 ### 5. Задачи: завести и уточнить
-**Вызови Skill `av-dev-tasks:tasks`.** Он владеет форматом, дедупом и индексами;
+**Вызови Skill `av-dev:task-track`.** Он владеет форматом, дедупом и индексами;
 путь к его скрипту не выясняй и индексы руками не правь.
 Что просишь сделать:
@@ -305,11 +305,11 @@ git и читается диффом, а второй стоп на каждой
 Пачка **собирается только сейчас**, и поэтому шаг стоит здесь: раньше пятого шага
 она не полна, а после коммита вычитка уже правит закоммиченное.
- **Документы** — агент `doc-wording`, владеет им `av-dev-docs:docs` (раздел
+- **Документы** — агент `doc-wording`, владеет им `av-dev:doc-sync` (раздел
  «Вычитка»). Пачка — адреса, названные на шаге 4, включая `docs/adr/` и
  `docs/research/`.
 - **Записи задач** — два прохода, сперва `task-form`, затем `task-wording`;
-  владеет ими `av-dev-tasks:tasks` (раздел «Вычитка: два прохода»). Пачка —
+  владеет ими `av-dev:task-track` (раздел «Вычитка: два прохода»). Пачка —
  заведённые и уточнённые на шаге 5 записи. Заголовок и «зачем» правятся **не
  молча**: покажи предложенное вместе с тем, что было.
@@ -319,7 +319,7 @@ git и читается диффом, а второй стоп на каждой
 раз тот же файл не гоняй.
 **Судей канона — `doc-consistency` и `doc-code-drift` — здесь не зови.** Они
-идут на весь канон разом, стоят дорого, и владеет ими `av-dev-docs:healthcheck`,
+идут на весь канон разом, стоят дорого, и владеет ими `av-dev:doc-healthcheck`,
 момент вызова которого выбирает человек. Нужно суждение о согласованности — скажи
 строкой и предложи `healthcheck`, а не зови агентов сам.
@@ -351,7 +351,7 @@ git и читается диффом, а второй стоп на каждой
 ### 8. Закрыть разведку — после коммита, не раньше
-**Вызови Skill `av-dev-tasks:tasks`** и попроси закрыть запись: ответ записан —
+**Вызови Skill `av-dev:task-track`** и попроси закрыть запись: ответ записан —
 `close --implemented`, ушла без ответа — `close --reason`, и строка уезжает в
 кладбище.
@@ -16,7 +16,7 @@
 Тонкая обёртка над каноническими скиллами `opsx:propose` / `opsx:apply` /
 `opsx:archive` — зови их через Skill, не переизобретай их шаги. Ревью — скилл
-`av-dev-code:review`; он же держит правило выбора метки, а называет её агент
+`av-dev:code-review`; он же держит правило выбора метки, а называет её агент
 `review-scope` — один раз на задачу, для обеих стадий ревью.
 ## Ход работы
@@ -32,9 +32,9 @@ flowchart TD
    s6["6. opsx:apply — код, гейт,<br/>поведенческая верификация"]
    s7["7. ревью кода, та же метка<br/>+ отработка замечаний"]
    s8["8. opsx:archive"]
-    s9["9. синк документации — av-dev-docs:docs"]
+    s9["9. синк документации — av-dev:doc-sync"]
    s10["10. коммит работы — av-dev-git:commit"]
-    s11["11. закрыть задачу — av-dev-tasks:tasks,<br/>вторым коммитом учёта"]
+    s11["11. закрыть задачу — av-dev:task-track,<br/>вторым коммитом учёта"]
    in --> s1
    s1 --> s2 --> s3 --> s4 --> s5 --> s6 --> s7 --> s8 --> s9 --> s10 --> s11
@@ -144,7 +144,7 @@ flowchart TD
 ### 4. Ревью дизайна — ДО кода, состав по метке
-Вызови Skill **`av-dev-code:review`**, дав ссылку на change `<id>`,
+Вызови Skill **`av-dev:code-review`**, дав ссылку на change `<id>`,
 **план разметки с шага 3** и указание, что это ревью дизайна.
 Состав приходит планом, а не решается здесь:
@@ -231,7 +231,7 @@ flowchart TD
 ### 7. Ревью кода — та же метка
-Вызови Skill **`av-dev-code:review`**, дав ссылку на change `<id>`,
+Вызови Skill **`av-dev:code-review`**, дав ссылку на change `<id>`,
 базу диффа, **план разметки с шага 3** и режим запуска.
 **Метку ты не выбираешь, и это правило, а не упрощение.** Её назвал
@@ -239,7 +239,7 @@ flowchart TD
 оси. Причина в разведённости: ты только что написал этот код, и решать, насколько
 глубоко его проверять, тебе нельзя — под давлением «я почти закончил» решение
 известно заранее. Правило выбора живёт в скилле конвейера —
-`av-dev-code:review`, `references/review-levels.md`; проектные
+`av-dev:code-review`, `references/review-levels.md`; проектные
 триггеры — в `docs/review.*`, подраздел «Триггеры метки».
 **Метка не пересматривается по факту диффа.** Дифф может выйти крупнее, чем
@@ -298,7 +298,7 @@ flowchart TD
 **Урожай — списком, не задачами.** Отложенные находки (реальный `major` не для
 этого мерджа, развилка, решённая «потом», пачка `nit`) собери в секцию доклада
 `Урожай`: формулировка, оракул, провенанс. Задачи из него **заводит не этот
-скилл** — их заводит `av-dev-tasks:tasks` своим сценарием «задачи из ревью и
+скилл** — их заводит `av-dev:task-track` своим сценарием «задачи из ревью и
 аудита»: своя нарезка, свой формат, свои правила дублей. Твоя обязанность — не
 потерять и передать.
@@ -319,7 +319,7 @@ flowchart TD
 ### 9. Синк документации
-**Вызови Skill `av-dev-docs:docs`**: он владеет содержимым документов канона и
+**Вызови Skill `av-dev:doc-sync`**: он владеет содержимым документов канона и
 ведёт чек-лист синка.
 **Правило одно и оно жёсткое: принуждённое отрицание.** Доклад обязан назвать
@@ -329,7 +329,7 @@ flowchart TD
 работает только обязательное отрицание.
 **Список документов и их триггеров здесь не дублируется** — он в чек-листе скилла
-`av-dev-docs:docs`, и копия уже однажды разошлась с оригиналом, потеряв два
+`av-dev:doc-sync`, и копия уже однажды разошлась с оригиналом, потеряв два
 триггера.
 **Плагина `av-dev-docs` в проекте нет** — путь в его дерево не разрешится ниоткуда,
@@ -346,7 +346,7 @@ flowchart TD
 (записку разведки, предшествовавшей задаче, пишет не этот сценарий).
 Триггеры при этом ты знаешь хуже, и это называется в докладе строкой: «синк
 сделан по перечню документов, без списка триггеров — плагина `av-dev-docs` нет».
-Канона в проекте тоже нет — назови это исходом и предложи `av-dev-docs:canon`.
+Канона в проекте тоже нет — назови это исходом и предложи `av-dev:doc-canon`.
 ### 10. Коммит
@@ -360,7 +360,7 @@ flowchart TD
 ### 11. Закрыть задачу — **после коммита, не раньше**
-**Вызови Skill `av-dev-tasks:tasks`** и попроси закрыть задачу как реализованную —
+**Вызови Skill `av-dev:task-track`** и попроси закрыть задачу как реализованную —
 он владеет форматом и двигает строку индекса сам. Путь к его скрипту не выясняй и
 индексы руками не правь: мост между плагинами — вызов скилла, а не путь.
@@ -404,7 +404,7 @@ flowchart TD
  написал код, план сверяется по темам, непокрытое называется строкой, а
  расхождение с одобренным — отдельным пунктом доклада.
 - **Заведение задач из урожая ревью — не твоя работа.** Отложенные находки
-  отдаются **списком**; превращает их в задачи `av-dev-tasks:tasks`, у него на
+  отдаются **списком**; превращает их в задачи `av-dev:task-track`, у него на
  этот вход отдельный сценарий «задачи из ревью и аудита». Плагина нет — урожай
  остаётся списком в докладе, и это говорится строкой.
 - **Способ решения ты не выбираешь.** Он приходит известным: из постановки, из
@@ -1,5 +1,5 @@
 ---
-name: review
+name: code-review
 description: "Конвейер ревью изменения, устроенный по темам: документ проекта либо заводит тему ревью, либо питает чужую тему источником, либо процессный и в ревью не читается вовсе. Ядро тем — requirements, autotests, conventions, architecture, security, operations; список тем открытый, свои темы проект заводит документом. Разметка задачи идёт один раз, после propose: агент review-scope выводит размер и сложность, из их максимума — метка, и раздаёт темы проходам обеих стадий. Метка правит и ревью дизайна (small — только specs; medium — плюс rubric; large — плюс architecture), и ревью кода (small — гейт, спеки, код, триаж; medium — плюс приёмник тем; large — плюс доказательство: враждебные постановки, эксплуатационный постмортем, архитектурный проход на широком входе). Триаж обязателен всегда. Порядок прогона — граф зависимостей: гейт открывает проходы с мнением, проходы с пометкой «держит машину» идут цепочкой, триаж — единственный сток. Проектная специфика приходит из документов канона av-dev-docs. Вызывается из скилла resolve — двумя стадиями: ревью дизайна до кода и ревью кода после apply. Третий вызов идёт от сценария обслуживания: без change и без метки, фиксированным планом (autotests, operations, плюс conventions, если тронут код), разметчик при этом не запускается."
 ---
@@ -44,7 +44,7 @@ description: "Конвейер ревью изменения, устроенны
 - **OpenSpec — жёсткая предпосылка, а не опция.** Ревью дизайна, проход
  `review-specs` и
-  вызывающий скилл `av-dev-code:resolve` завязаны на дельта-спеки
+  вызывающий скилл `av-dev:code-resolve` завязаны на дельта-спеки
  (`openspec/changes/<id>/specs/*/spec.md`), на актуальные спеки
  (`openspec/specs/`) и на `openspec validate --strict`. В проекте без OpenSpec
  шаги, зовущие `opsx:explore` / `opsx:propose` / `opsx:apply` / `opsx:archive`,
@@ -52,9 +52,9 @@ description: "Конвейер ревью изменения, устроенны
  требований. **Проект без OpenSpec этим конвейером не проверяется** — подключай
  OpenSpec, а не понижай прогон: ветка деградации здесь не пишется, потому что
  непроверенная ветка деградации хуже честного отказа. Заводить руками не надо:
-  этим владеет скилл `av-dev-code:openspec` — он заводит каталог и заменяет
+  этим владеет скилл `av-dev:code-openspec` — он заводит каталог и заменяет
-  пример в `config.yaml` настройкой. Его же зовут `av-dev-docs:init` на новом
+  пример в `config.yaml` настройкой. Его же зовут `av-dev:doc-init` на новом
-  проекте и `av-dev-docs:canon` в режиме `adopt` — на переводимом.
+  проекте и `av-dev:doc-canon` в режиме `adopt` — на переводимом.
  **Предпосылка эта — про изменение поведения, а не про всякий прогон:**
  сценарий обслуживания зовёт конвейер без change и без дельта-спек, и ни один
  проход его плана на них не завязан. См. «Прогон без change».
@@ -71,13 +71,13 @@ description: "Конвейер ревью изменения, устроенны
 **Копия.** Дом — `shared/plugin-boundary.md` в репозитории плагинов. Правится
 дом, а не этот файл.
-<!-- копия: граница-плагинов из shared/plugin-boundary.md -->
+<!-- копия: граница-плагинов из av-dev/shared/plugin-boundary.md -->
 Плагины `av-dev` ставятся порознь, и ни один не вправе считать, что сосед на
 месте.
-**Чужой скилл зовётся полным именем** — `av-dev-docs:canon`, `av-dev-tasks:tasks`,
+**Чужой скилл зовётся полным именем** — `av-dev:doc-canon`, `av-dev:task-track`,
-`av-dev-code:review`. Короткое имя может разрешиться в устаревшую проектную копию
+`av-dev:code-review`. Короткое имя может разрешиться в устаревшую проектную копию
 из `.claude/skills/`, и подмены не будет видно ни в докладе, ни в поведении.
 **Путь в дерево чужого плагина не пишется никогда.** `$CLAUDE_PLUGIN_ROOT` ведёт
@@ -98,8 +98,8 @@ description: "Конвейер ревью изменения, устроенны
 <!-- /копия: граница-плагинов -->
-Своих скиллов это касается ровно так же: `av-dev-code:review`,
+Своих скиллов это касается ровно так же: `av-dev:code-review`,
-`av-dev-code:resolve`, `av-dev-code:openspec` — подменяется короткое имя,
+`av-dev:code-resolve`, `av-dev:code-openspec` — подменяется короткое имя,
 а не чужое.
 ## Темы, источники и процессные документы
@@ -126,7 +126,7 @@ description: "Конвейер ревью изменения, устроенны
 критерий, по которому судит изменение. `adr.*`, `research.*` и `tasks/` не
 открывает никто.
-Дом канона этой раскладки — скилл `av-dev-docs:canon`, раздел «Три категории
+Дом канона этой раскладки — скилл `av-dev:doc-canon`, раздел «Три категории
 документов». Конвейер её **читатель**: категории и имена тем он берёт
 оттуда и своих не заводит.
@@ -158,7 +158,7 @@ description: "Конвейер ревью изменения, устроенны
 читал решения, а эксплуатационный и `specs` — числа. Цена решения записана в
 каноне и повторяется здесь, потому что платит её конвейер: **расхождение
 изменения с записанным решением прогоном не ловится**, это работа сверки
-документации — скилл `av-dev-docs:healthcheck`.
+документации — скилл `av-dev:doc-healthcheck`.
 Строка об этом обязательна в границах покрытия каждого прогона.
 **Своя тема проекта бывает двух происхождений, и обе законны:** документ, который
@@ -185,7 +185,7 @@ description: "Конвейер ревью изменения, устроенны
 дом для тех же фактов разошёлся бы и выглядел актуальным.
 **Документов канона нет вовсе** — проект не приведён к канону. Скажи это строкой
-и предложи скилл `av-dev-docs:canon`: одна операция на проект против деградации на
+и предложи скилл `av-dev:doc-canon`: одна операция на проект против деградации на
 каждой задаче. Прогон при этом не останавливается.
 ## Что получает каждый проход
@@ -643,7 +643,7 @@ flowchart TD
 ## Прогон без change — сценарий обслуживания
-Третий вызывающий конвейера — сценарий обслуживания скилла `av-dev-code:resolve`
+Третий вызывающий конвейера — сценарий обслуживания скилла `av-dev:code-resolve`
 (тулчейн и сборка, зависимости, гит-хуки, перенос, чистка). Он приходит **без
 change**: у работы, не меняющей поведения, дельта-спек нет по построению.
@@ -672,7 +672,7 @@ change**: у работы, не меняющей поведения, дельт
 метке `small`. Все три обязаны быть названы в границах покрытия, а **сигнал о
 заниженной метке на таком прогоне не работает**: поднимать нечего.
-Дом плана — сценарий, а не этот скилл: `av-dev-code:resolve`,
+Дом плана — сценарий, а не этот скилл: `av-dev:code-resolve`,
 `references/maintain.md`, раздел «Ревью — план фиксирован сценарием».
 **Правило гейта на таком прогоне работает жёстче обычного.** Правка, которая
@@ -898,7 +898,7 @@ change»: сверять исход с планом триаж обязан и
 ## Ревью дизайна — до кода
 Запускается на первой стадии ревью (шаг 4 скилла
-`av-dev-code:resolve`), когда change уже имеет `proposal.md` и
+`av-dev:code-resolve`), когда change уже имеет `proposal.md` и
 дельта-спеки, но кода ещё нет. Разметка задачи к этому моменту уже прошла — она
 шагом раньше, и метка известна.
@@ -941,7 +941,7 @@ change»: сверять исход с планом триаж обязан и
 **Граф этой стадии свой, и он плоский.** Гейта нет — кода ещё нет, запускать
 нечего; метка уже названа разметкой задачи; машину не держит ни один проход;
-сток — не триаж, а шаг скилла `av-dev-code:resolve`, где замечания
+сток — не триаж, а шаг скилла `av-dev:code-resolve`, где замечания
 отрабатываются правкой спек. Триаж здесь не нужен: находок единицы, и каждая
 либо правит спеку, либо
 становится развилкой.
@@ -993,7 +993,7 @@ flowchart TD
 - Находка не для этого мерджа, но реальная (отложенный `major`, развилка,
  решённая «потом»), — не теряется, но **и не заводится здесь**. Конвейер отдаёт
  её **списком урожая** в отчёте: формулировка, оракул, провенанс (какой проход,
-  какой change). Заведение задач принадлежит `av-dev-tasks:tasks` — зови его со
+  какой change). Заведение задач принадлежит `av-dev:task-track` — зови его со
  списком урожая, у него на этот вход отдельный сценарий «задачи из ревью и
  аудита»: свой формат, кластеризация по причине, дедуп против беклога и
  кладбища. Плагина нет — урожай остаётся списком в отчёте, и это говорится
@@ -1010,7 +1010,7 @@ flowchart TD
  заведено: нулевой урожай при непустом отчёте виден сразу.
  **Вместе с изменением он и переезжает:** после `opsx:archive` его адрес —
  `openspec/changes/archive/<id>/review/`. Кто ищет отчёт после архивации
-  (приёмщик на груминге `av-dev-tasks:groom`, разбор дефекта), смотрит **оба**
+  (приёмщик на груминге `av-dev:task-groom`, разбор дефекта), смотрит **оба**
  пути; «отчёта нет» объявляется, только когда пуст и архивный, иначе самый
  дорогой сценарий «состав ревью неизвестен, гоняем заново» срабатывает на
  каждой доведённой задаче.
@@ -1107,7 +1107,7 @@ flowchart TD
  и где это лежит в документах проекта; таблица поразрядной деградации.
 - [references/review-levels.md](references/review-levels.md) — дом правила выбора
  метки: две оси, спорное вниз, чем `small` дешевле, доли как проверка правила.
- Skill `av-dev-docs:canon` — приведение проекта к канону документов.
+- Skill `av-dev:doc-canon` — приведение проекта к канону документов.
 - [references/finding-contract.md](references/finding-contract.md) — контракт находок.
 - [references/promote.md](references/promote.md) — промоут находка → конвенция → правило → удаление.
 - [references/calibration.md](references/calibration.md) — калибровка инъекцией, вердикты keep/retune/drop.
@@ -8,7 +8,7 @@
 `av-dev-docs`, и проход читает их напрямую: пути жёсткие, посредник не нужен, а
 второй дом для тех же фактов разошёлся бы и выглядел актуальным.
-Определение канона держит скилл `av-dev-docs:canon`. Здесь только карта «тема →
+Определение канона держит скилл `av-dev:doc-canon`. Здесь только карта «тема →
 её дом → что оттуда берётся».
 ## Карта тем
@@ -118,7 +118,7 @@
 строка неотличима от «мы просто не стали» и перестаёт читаться на третьей задаче.
 **Документов канона нет вовсе** — проект не приведён к канону. Это не повод
-работать вслепую: скажи об этом строкой и предложи `av-dev-docs:canon`. Одна
+работать вслепую: скажи об этом строкой и предложи `av-dev:doc-canon`. Одна
 операция на проект против деградации на каждой задаче.
 ## Правило чтения
@@ -41,7 +41,7 @@
 ## Форма записи
 **Это дом формы, и у него есть копия.** Скелет `docs/review.md`, который кладёт
-в проект `av-dev-docs:canon`, повторяет её дословно — он уезжает в репозиторий и обязан там что-то говорить. Правка формы
+в проект `av-dev:doc-canon`, повторяет её дословно — он уезжает в репозиторий и обязан там что-то говорить. Правка формы
 здесь **обязана** тянуть правку скелета и запись в журнал версий канона; иначе
 проекты продолжат писать по старой форме, а конвейер — ждать поля, которого нет.
 Дословность сверяет `scripts/copies.py` маркетплейса по маркерам ниже — но
@@ -95,7 +95,7 @@
 остаются в одной метке, значит заплатить костяк дважды за ту же проверку.
 Резать стоит там, где разрез **снимает доказательство с большей части диффа**.
 Шов и правило нарезки живут у того, кто ведёт задачи, — скилл
-`av-dev-tasks:tasks`, его раздел о нарезке. Пути туда конвейер не выносит: за
+`av-dev:task-track`, его раздел о нарезке. Пути туда конвейер не выносит: за
 пределы своего плагина он ходит вызовом скилла, а не файлом.
 Разметка в костяк не входит — она платится один раз на задачу, а не один раз на
@@ -1,5 +1,5 @@
 ---
-name: canon
+name: doc-canon
 description: Привести проект к канону документов av-dev и держать его в соответствии — три операции одной машиной сравнения. check — что разошлось с текущей версией канона; adopt — перевод проекта из любой прежней раскладки (docs/specs, drafts, backlog, BRIEF.md, review-brief) в канон с переносом файлов; upgrade — повышение проекта с версии канона N до текущей по журналу версий. Использовать, когда просят проверить документацию проекта, перевести проект на канон, обновить его под новую версию канона или когда пришли в старый проект и надо понять, что в нём не так. Заведение нового проекта с нуля — скилл init.
 ---
@@ -52,7 +52,7 @@ python3 $ds version --dir <корень>                # версия кано
 ```
 **Формы `openspec/config.yaml` здесь больше нет.** Каталог принадлежит конвейеру,
-и форму смотрит его скрипт — скилл `av-dev-code:openspec`, команда
+и форму смотрит его скрипт — скилл `av-dev:code-openspec`, команда
 `openspec.py check`. Проект работает по OpenSpec, а плагина конвейера нет — форму
 не проверяет никто, и это надо сказать строкой доклада, а не считать, что она
 верна.
@@ -89,20 +89,20 @@ capability: незаполненный канон это переходное с
 ## Обращение к соседним плагинам
-`adopt` зовёт двоих: `av-dev-code:openspec` (шаг 4, пункт 3) и
+`adopt` зовёт двоих: `av-dev:code-openspec` (шаг 4, пункт 3) и
-`av-dev-tasks:tasks` (шаг 4, пункт 5). Каталоги `openspec/` и `tasks/` каноном не
+`av-dev:task-track` (шаг 4, пункт 5). Каталоги `openspec/` и `tasks/` каноном не
 ведутся, и трогать их этому скиллу нечем, кроме вызова.
 **Копия.** Дом правила — `shared/plugin-boundary.md` в репозитории плагинов.
 Правится дом, а не этот файл.
-<!-- копия: граница-плагинов из shared/plugin-boundary.md -->
+<!-- копия: граница-плагинов из av-dev/shared/plugin-boundary.md -->
 Плагины `av-dev` ставятся порознь, и ни один не вправе считать, что сосед на
 месте.
-**Чужой скилл зовётся полным именем** — `av-dev-docs:canon`, `av-dev-tasks:tasks`,
+**Чужой скилл зовётся полным именем** — `av-dev:doc-canon`, `av-dev:task-track`,
-`av-dev-code:review`. Короткое имя может разрешиться в устаревшую проектную копию
+`av-dev:code-review`. Короткое имя может разрешиться в устаревшую проектную копию
 из `.claude/skills/`, и подмены не будет видно ни в докладе, ни в поведении.
 **Путь в дерево чужого плагина не пишется никогда.** `$CLAUDE_PLUGIN_ROOT` ведёт
@@ -130,7 +130,7 @@ capability: незаполненный канон это переходное с
 1. `docs.py check`, при наличии базы диффа — с `--base`.
 2. **Судей документов на каждом `check` не зови.** Ими владеет отдельный скилл —
-   `av-dev-docs:healthcheck`, — и там же записано, когда его звать: он дорог, и
+   `av-dev:doc-healthcheck`, — и там же записано, когда его звать: он дорог, и
   прогон по каждому `check` не окупается. `check` отвечает на «сходится ли
   форма», `healthcheck` — на «не разошлись ли утверждения».
 3. Доклад: вывод скрипта строкой исхода и **граница покрытия** — что смотрели и
@@ -182,13 +182,13 @@ capability), `openspec/config.yaml`.
 2. каталоги канона и скелет **по [references/skeletons.md](references/skeletons.md)**:
   незаполненное — одной честной информативной строкой, а не «TBD»;
 3. **OpenSpec, если его нет или `config.yaml` остался примером** — **вызови
-   Skill `av-dev-code:openspec`**. Каталог принадлежит конвейеру, и команда
+   Skill `av-dev:code-openspec`**. Каталог принадлежит конвейеру, и команда
   заведения с формой файла живут там. Пересказ инвариантов, конвенций и правил
   ревью из `context` вычисти ссылкой на дом — на переводимом проекте он там
   почти наверняка есть. Вызов не разрешился — `docs.py` о каталоге тогда тоже
   молчит, и форму `config.yaml` не проверяет никто; скажи это строкой;
 4. переносы содержимого;
-5. каталог задач — **вызови скилл `av-dev-tasks:tasks`**, сценарий адаптации: он
+5. каталог задач — **вызови скилл `av-dev:task-track`**, сценарий адаптации: он
   владеет форматом задач. Он же переименует транслитные слаги в английские и
   тем же проходом починит перекрёстные ссылки;
 6. починка ссылок на перенесённое во всём репозитории — `docs/`, `openspec/`,
@@ -222,7 +222,7 @@ capability), `openspec/config.yaml`.
   его отчёт идёт в доклад отдельной строкой, и пункт «задачи без цели» в нём
   зелёным не станет: цели не сочиняются адаптацией (запрет записан у того, кто
   ведёт задачи), их проставляет человек порциями переоценки на первом груминге —
-   скилл `av-dev-tasks:groom`.
+   скилл `av-dev:task-groom`.
 ### 5. Объяви переходное состояние
@@ -241,7 +241,7 @@ capability), `openspec/config.yaml`.
 проекте обычно самый урожайный — правило единственного дома до адаптации никто не
 проверял.
-Вызови Skill **`av-dev-docs:healthcheck`** — он зовёт обоих судей на весь канон
+Вызови Skill **`av-dev:doc-healthcheck`** — он зовёт обоих судей на весь канон
 разом и держит разбор урожая порциями.
 **Передай им объявленное переходное состояние из шага 5** — иначе честная строка
@@ -269,7 +269,7 @@ capability), `openspec/config.yaml`.
   применяются по порядку.
 4. Подними `canon` в `docs/.docs.json` до текущей.
 5. `docs.py check`.
-6. **Позови судей** — Skill `av-dev-docs:healthcheck`.
+6. **Позови судей** — Skill `av-dev:doc-healthcheck`.
 7. **Позови вычитку** — агент `doc-wording`, но **только по тем документам,
   которых записи журнала коснулись**, и только если правка была текстовой, а не
   переименованием файла. Записи журнала пишутся руками в проектной прозе, и
@@ -284,7 +284,7 @@ capability), `openspec/config.yaml`.
 двигать чужое число: две версии, которые ходят по одному журналу, разъезжаются
 на первом же проекте, поставившем один плагин без другого. Отстал каталог
 задач — это скажет `tasks.py check` своей строкой гейта, а повысит скилл
-`av-dev-tasks:tasks`.
+`av-dev:task-track`.
 **Шаг 6 обязателен, и вот почему.** `check` сверяет **число** в `.docs.json` с
 версией скрипта — и только его. Применена ли запись журнала **по существу**, он
@@ -32,7 +32,7 @@
 делят роадмап, архитектура и тема ревью `operations`, то есть три плагина,
 и ни один из трёх им не владеет. Правится дом, а не этот файл.
-<!-- копия: сопровождение-словарь из shared/operations.md -->
+<!-- копия: сопровождение-словарь из av-dev/shared/operations.md -->
 Одна тема живёт в трёх местах, и путать их слова нельзя.
@@ -188,7 +188,7 @@ kebab-case.** Причина не эстетическая: имя файла с
 какую тему питает. **Кто именно закрывает тему, здесь не указано намеренно**: это
 зависит от метки прогона и меняется вместе с конвейером, а документ живёт
 дольше. Раскладку «тема → проход → глубина» держит скилл
-`av-dev-code:review`.
+`av-dev:code-review`.
 **Общего словаря у канона с конвейером ровно три вида имён: имена категорий,
 имена тем и имена меток.** Категорий три — `тема`, `источник`, `процессный`;
@@ -375,7 +375,7 @@ kebab-case.** Причина не эстетическая: имя файла с
 задач не проверяет. Проект, поставивший только канон документов, задач не ведёт
 вовсе, и отказом это быть не может.
-Раскладку, форму записи и команды держит скилл `av-dev-tasks:tasks`. Ниже — то,
+Раскладку, форму записи и команды держит скилл `av-dev:task-track`. Ниже — то,
 от чего зависит, читается ли проект как продукт: канон высказывается об этом
 потому, что роадмап отвечает на вопрос о **системе**, а не о работах.
@@ -400,7 +400,7 @@ kebab-case.** Причина не эстетическая: имя файла с
 | 🔬 `research` | исход — знание, а не изменение |
 **Схемы записи здесь нет намеренно.** Какие разделы тип требует, нужна ли ему
-цель и берётся ли он в работу — скилл `av-dev-tasks:tasks`, раздел «Тип
+цель и берётся ли он в работу — скилл `av-dev:task-track`, раздел «Тип
 записи», подробно — по файлу на тип в его `references/task-<тип>.md`. Ссылки в
 дерево того плагина здесь нет намеренно: он ставится отдельно, и путь наружу
 разрешился бы не всегда. Канон фиксирует **словарь**, потому что
@@ -418,7 +418,7 @@ kebab-case.** Причина не эстетическая: имя файла с
 работу не берётся и лежит в конце своей категории.
 Раскладку, форму записи и алгоритм работы над каждым типом держит скилл
-`av-dev-tasks:tasks`.
+`av-dev:task-track`.
 ### `CLAUDE.md`
@@ -440,7 +440,7 @@ kebab-case.** Причина не эстетическая: имя файла с
  шкала ранжирования триажа и право проходов на `critical`;
 - **что считается сломанным** — красная проверка, обгоняющая развитие;
  **ориентир по размеру порции**, если он замерялся. Оба слота читает скилл
-  `av-dev-tasks:groom`, и имена их — его; названы они здесь потому, что дом
+  `av-dev:task-groom`, и имена их — его; названы они здесь потому, что дом
  содержимого `CLAUDE.md` один и он тут.
 ### `openspec/config.yaml`
@@ -448,7 +448,7 @@ kebab-case.** Причина не эстетическая: имя файла с
 **Файл канону не принадлежит, и проверяет его тоже не канон.** Каталог
 `openspec/` — предпосылка конвейера: без него не работают ни `opsx:propose`, ни
 ревью дизайна, ни сверка требований. Заводит его, настраивает и **проверяет
-форму** скилл `av-dev-code:openspec`: там образец файла, там же скрипт
+форму** скилл `av-dev:code-openspec`: там образец файла, там же скрипт
 `openspec.py check`. `docs.py` о файле не говорит ничего.
 Канон называет его здесь по одной причине: `openspec/specs/` — **дом темы
@@ -537,7 +537,7 @@ kebab-case.** Причина не эстетическая: имя файла с
 **Форма `openspec/config.yaml` в левой колонке отсутствует не по забывчивости.**
 С канона 10 `docs.py` о файле не говорит ничего: имя, `schema`, незаменённый
 пример, адреса паспорта и `CLAUDE.md`, ключи `rules` и сторож версии OpenSpec —
-всё это смотрит `openspec.py check` скилла `av-dev-code:openspec`. Плагина
+всё это смотрит `openspec.py check` скилла `av-dev:code-openspec`. Плагина
 конвейера в проекте может не быть; тогда форму не проверяет никто, и это строка
 доклада.
@@ -546,7 +546,7 @@ kebab-case.** Причина не эстетическая: имя файла с
 читающие команды. Слитый агент делал бы одну половину поверхностной; тот же
 разрез, что между `task-form` и `task-wording`.
-**Зовутся оба одинаково и одним скиллом — `av-dev-docs:healthcheck`, на весь
+**Зовутся оба одинаково и одним скиллом — `av-dev:doc-healthcheck`, на весь
 канон разом; шагом `adopt` и шагом `upgrade` его зовёт `canon`.** Не на синке
 документации: `doc-consistency` на
 `opus` по каждой сделанной задаче не окупается, а расхождение между двумя документами по
@@ -4,7 +4,7 @@
 документов канона и для задач, и потому не принадлежит ни одному плагину.
 Правится дом, а не этот файл: расхождение ловит `copies.py` на гейте коммита.
-<!-- копия: язык-доктрина из shared/language.md -->
+<!-- копия: язык-доктрина из av-dev/shared/language.md -->
 Правила — для всего, что пишется словами: задачи и цели, документы канона,
 решения ADR, записки разведки, сообщения коммитов. Не для кода и не для
@@ -70,7 +70,7 @@
 ## Правила
-<!-- копия: язык-правила из shared/language.md -->
+<!-- копия: язык-правила из av-dev/shared/language.md -->
 У каждого правила названа причина: она же говорит, где правило **не**
 применяется.
@@ -193,7 +193,7 @@
 ## Порог правки
-<!-- копия: порог-правки из shared/language.md -->
+<!-- копия: порог-правки из av-dev/shared/language.md -->
 **Правка без нарушенного правила не делается.** Текст, переписанный «чтобы
 звучало лучше», обесценивает список замечаний: когда половина из них вкусовая,
@@ -209,7 +209,7 @@
 Верно одно из трёх:
-<!-- копия: adr-когда-заводить из av-dev-docs/skills/canon/references/canon.md -->
+<!-- копия: adr-когда-заводить из av-dev/skills/doc-canon/references/canon.md -->
 - **дорогой откат** — переделка стоит дороже переписывания одного файла;
 - **намеренный отказ** от очевидного подхода;
 - **пересмотр прежнего решения** — тогда у старой записи обязателен статус
@@ -345,7 +345,7 @@
 Форма:
-<!-- копия: журнал-дефектов-форма из av-dev-code/skills/review/references/review-journal.md -->
+<!-- копия: журнал-дефектов-форма из av-dev/skills/code-review/references/review-journal.md -->
 ## ГГГГ-ММ-ДД — <краткое последствие> [проскочил|пойман]
 - **Где:** путь:строка либо «конвейер, а не код»
@@ -429,12 +429,12 @@ severity стоит здесь, а не выводится каждым прох
 ## `openspec/config.yaml`
 **Образец переехал.** Файл заводит и заполняет плагин конвейера — скилл
-`av-dev-code:openspec`, — потому что по OpenSpec работает он, а не канон
+`av-dev:code-openspec`, — потому что по OpenSpec работает он, а не канон
 документов. Проект без конвейера каталога `openspec/` не имеет вовсе, и образец
 файла, которого у него нет, в скелетах канона лежал бы мёртвым грузом.
 **Форму не проверяет и `docs.py`** — с канона 10 он о файле молчит вовсе.
-Проверяет её тот же владелец: скилл `av-dev-code:openspec`, команда
+Проверяет её тот же владелец: скилл `av-dev:code-openspec`, команда
 `openspec.py check`. Плагина конвейера в проекте может не быть — тогда форму не
 смотрит никто, и это строка доклада, а не поломка. Что канон о файле всё же
 говорит (единственный дом, а не форма) — [canon.md](canon.md), раздел
@@ -595,7 +595,7 @@ def report(rep: Report) -> int:
        "\nМашина проверила раскладку, имена файлов, ссылки, версию и две\n"
        "сверки с кодом. Форму openspec/config.yaml она не проверяет: каталог\n"
        "принадлежит конвейеру, и форму смотрит его скрипт\n"
-        "(`av-dev-code:openspec`, команда `openspec.py check`). Согласованность\n"
+        "(`av-dev:code-openspec`, команда `openspec.py check`). Согласованность\n"
        "документов между собой и с кодом — тоже не её: это суждение агентов\n"
        "`doc-consistency` (документ ↔ документ ↔ openspec) и `doc-code-drift`\n"
        "(документ ↔ код)."
@@ -1,5 +1,5 @@
 ---
-name: healthcheck
+name: doc-healthcheck
 description: "Проверка здоровья документации проекта судом, а не машиной: не разошлись ли документы между собой и с кодом. Зовёт двух агентов на весь канон разом — doc-consistency (один факт в двух домах, прямое противоречие, поведение в architecture.md вместо спек, ADR без парного статуса, число без провенанса) и doc-code-drift (протухший факт: имя ветки, команды, пути, зависимости поимённо, настройки с числом, единые точки, capability). Разбирает урожай порциями: строка на замену идёт в документ сразу, работа больше абзаца становится задачей. Использовать, когда с прошлой сверки сделан десяток задач, когда вернулись к проекту после перерыва, перед тем как опереться на документ в решении, а также шагом adopt и upgrade. Дорого — не на каждой задаче. Раскладку и версию канона проверяет скилл canon, язык документов — агент doc-wording."
 ---
@@ -40,13 +40,13 @@ check` и его скрипт; здесь начинается там, где к
 **Копия.** Дом — `shared/plugin-boundary.md` в репозитории плагинов. Правится
 дом, а не этот файл.
-<!-- копия: граница-плагинов из shared/plugin-boundary.md -->
+<!-- копия: граница-плагинов из av-dev/shared/plugin-boundary.md -->
 Плагины `av-dev` ставятся порознь, и ни один не вправе считать, что сосед на
 месте.
-**Чужой скилл зовётся полным именем** — `av-dev-docs:canon`, `av-dev-tasks:tasks`,
+**Чужой скилл зовётся полным именем** — `av-dev:doc-canon`, `av-dev:task-track`,
-`av-dev-code:review`. Короткое имя может разрешиться в устаревшую проектную копию
+`av-dev:code-review`. Короткое имя может разрешиться в устаревшую проектную копию
 из `.claude/skills/`, и подмены не будет видно ни в докладе, ни в поведении.
 **Путь в дерево чужого плагина не пишется никогда.** `$CLAUDE_PLUGIN_ROOT` ведёт
@@ -67,7 +67,7 @@ check` и его скрипт; здесь начинается там, где к
 <!-- /копия: граница-плагинов -->
-Здесь сосед один: `av-dev-tasks:tasks`, когда находка тянет на задачу. Его нет —
+Здесь сосед один: `av-dev:task-track`, когда находка тянет на задачу. Его нет —
 находки остаются списком в докладе, и это говорится строкой.
 ## Пачка — весь канон, и это не расточительство
@@ -109,7 +109,7 @@ check` и его скрипт; здесь начинается там, где к
 1. **Строка на замену** — правь документ сразу. Формулировка уже готова, спорить
   не с чем, и откладывание превращает её в задачу дороже самой правки.
 2. **Работа больше чем на абзац** — задача типа `chore`. Заводит её **не этот
-   скилл**: вызови Skill `av-dev-tasks:tasks`, у него свой формат, дедупликация
+   скилл**: вызови Skill `av-dev:task-track`, у него свой формат, дедупликация
   против беклога и кладбища. Плагина нет — отдай списком в докладе и скажи это
   строкой.
 3. **Не находка** — агент ошибся, документ прав. Скажи это прямо: неразобранная
@@ -126,18 +126,18 @@ check` и его скрипт; здесь начинается там, где к
  идёт из его собственного отчёта — перечень фактов у него закрытый, и он
  называет, какие из них проверить было нечем.
 - Канона в проекте нет вовсе — это исход, а не пустой прогон: скажи строкой и
-  предложи `av-dev-docs:canon`.
+  предложи `av-dev:doc-canon`.
 ## Чего этот скилл не делает
 - **Не проверяет раскладку, версию и ссылки** — это `canon check`, там машина.
 - **Не судит язык** документов: залог, англицизмы, жаргон, термин без дома — это
  агент `doc-wording`, и зовут его отдельно, по пачке правленных документов.
-  Звонящие у него названные — последний шаг синка в `av-dev-docs:docs`, шаг 9
+  Звонящие у него названные — последний шаг синка в `av-dev:doc-sync`, шаг 9
-  `av-dev-docs:init` и шаг вычитки в обоих режимах `canon`, — просто ни один из
+  `av-dev:doc-init` и шаг вычитки в обоих режимах `canon`, — просто ни один из
  них не здесь. У него другой ритм: он нужен там, где текст только что писали, а
  не там, где он год лежал. Оркестровать его нечем — он один и работает по
  названному списку.
 - **Не правит документы за агентов** — они возвращают формулировки, решение
  подставить принимает человек или ты по его правилу.
- **Не заводит задачи** — этим владеет `av-dev-tasks:tasks`.
+- **Не заводит задачи** — этим владеет `av-dev:task-track`.
@@ -1,6 +1,6 @@
 ---
-name: init
+name: doc-init
-description: "Завести новый проект — сессия вопросов и ответов по свободному описанию замысла, из которой рождается первичная документация по канону av-dev: паспорт, CLAUDE.md с инвариантами и командами, модель угроз с периметром и скелет остальных документов; первые цели собирает интервью, а записывает их вызовом скилла av-dev-tasks:tasks — роадмап принадлежит плагину задач. OpenSpec заводит не сам, а вызовом скилла av-dev-code:openspec — каталог принадлежит конвейеру; плагина конвейера нет — шаг пропускается строкой доклада. Использовать, когда начинают новый проект с нуля, когда есть только текст «что мне нужно и почему» и надо превратить его в рабочую документацию, когда просят провести стартовое интервью по брифу. Проект, где документация уже как-то ведётся, переводит скилл canon."
+description: "Завести новый проект — сессия вопросов и ответов по свободному описанию замысла, из которой рождается первичная документация по канону av-dev: паспорт, CLAUDE.md с инвариантами и командами, модель угроз с периметром и скелет остальных документов; первые цели собирает интервью, а записывает их вызовом скилла av-dev:task-track — роадмап принадлежит плагину задач. OpenSpec заводит не сам, а вызовом скилла av-dev:code-openspec — каталог принадлежит конвейеру; плагина конвейера нет — шаг пропускается строкой доклада. Использовать, когда начинают новый проект с нуля, когда есть только текст «что мне нужно и почему» и надо превратить его в рабочую документацию, когда просят провести стартовое интервью по брифу. Проект, где документация уже как-то ведётся, переводит скилл canon."
 ---
 # Заведение нового проекта
@@ -34,7 +34,7 @@ description: "Завести новый проект — сессия вопро
 **`tasks/ROADMAP.md` в таблице нет намеренно.** Первые цели `init` собирает
 интервью (блок 6), но записывает их не он: каталогом задач и формой целей владеет
-`av-dev-tasks:tasks`, и это шаг 7. Плагина нет — цели остаются списком в докладе,
+`av-dev:task-track`, и это шаг 7. Плагина нет — цели остаются списком в докладе,
 роадмапа в проекте не появляется, и это говорится строкой.
 ## Порядок интервью — зависимость, а не удобство
@@ -77,13 +77,13 @@ description: "Завести новый проект — сессия вопро
 **Копия.** Дом правила — `shared/plugin-boundary.md` в репозитории плагинов.
 Правится дом, а не этот файл.
-<!-- копия: граница-плагинов из shared/plugin-boundary.md -->
+<!-- копия: граница-плагинов из av-dev/shared/plugin-boundary.md -->
 Плагины `av-dev` ставятся порознь, и ни один не вправе считать, что сосед на
 месте.
-**Чужой скилл зовётся полным именем** — `av-dev-docs:canon`, `av-dev-tasks:tasks`,
+**Чужой скилл зовётся полным именем** — `av-dev:doc-canon`, `av-dev:task-track`,
-`av-dev-code:review`. Короткое имя может разрешиться в устаревшую проектную копию
+`av-dev:code-review`. Короткое имя может разрешиться в устаревшую проектную копию
 из `.claude/skills/`, и подмены не будет видно ни в докладе, ни в поведении.
 **Путь в дерево чужого плагина не пишется никогда.** `$CLAUDE_PLUGIN_ROOT` ведёт
@@ -111,7 +111,7 @@ description: "Завести новый проект — сессия вопро
 1. Прочитай бриф целиком. Выпиши, на какие блоки интервью ответ уже есть.
 2. Проведи интервью итерациями по ≤3 вопроса.
-3. **OpenSpec — вызови Skill `av-dev-code:openspec`.** Он заводит каталог и
+3. **OpenSpec — вызови Skill `av-dev:code-openspec`.** Он заводит каталог и
   заменяет пример в `config.yaml` настройкой. Делается это **до первого
   документа**: без `openspec/` не работают ни `opsx:propose`, ни ревью дизайна,
   ни сверка требований. Каталог принадлежит конвейеру, а не канону, поэтому
@@ -126,7 +126,7 @@ description: "Завести новый проект — сессия вопро
   первом же уточнении.
 6. Заведи скелет остальных по [скелетам](../canon/references/skeletons.md) —
   каждый с честной строкой.
-7. Каталог задач и первые цели — **вызови скилл `av-dev-tasks:tasks`**: он владеет
+7. Каталог задач и первые цели — **вызови скилл `av-dev:task-track`**: он владеет
   форматом целей и задач. Не разрешился — учёт задач остаётся владельцу, и это
   тоже строка доклада.
 8. `docs.py check` из скилла `canon` — до отсутствия дрейфа. Замечания о
@@ -1,5 +1,5 @@
 ---
-name: docs
+name: doc-sync
 description: Вести содержимое документов канона по ходу разработки — синк после сделанной задачи с построчным отчётом по каждому документу, заведение ADR промоутом из архивного design.md или из записки разведки, запись наблюдения в research, запись дефекта и настройки конвейера в review.md, чистка architecture.md от поведения с маркерами долга. Использовать, когда задача сделана и надо обновить документацию, когда просят завести ADR или записать решение, занести находку о внешних данных, записать проскочивший дефект, разгрузить разросшуюся архитектуру. Раскладку и соответствие канону проверяет скилл canon.
 ---
@@ -55,7 +55,7 @@ description: Вести содержимое документов канона
 - passport, security, conventions, review — не требуется: изменение внутреннее
 ```
-## Сверка — не здесь, а в `av-dev-docs:healthcheck`
+## Сверка — не здесь, а в `av-dev:doc-healthcheck`
 Синк правит документы поодиночке, а расходятся они **между собой**: факт,
 дописанный в `architecture.md`, уже живёт в `CLAUDE.md`; периметр в
@@ -63,7 +63,7 @@ description: Вести содержимое документов канона
 и судит это агент `doc-consistency`.
 **Но синк его не зовёт.** Обоими судьями документов владеет скилл
-`av-dev-docs:healthcheck`, и зовут их на весь канон разом, а не на пачку,
+`av-dev:doc-healthcheck`, и зовут их на весь канон разом, а не на пачку,
 отобранную работой. Причина в цене: `doc-consistency` на `opus` по каждой
 сделанной задаче — самая дорогая церемония процесса, а `doc-code-drift` хоть и на
 `sonnet`, но читает репозиторий целиком. К тому же расхождение между двумя
@@ -88,7 +88,7 @@ description: Вести содержимое документов канона
 термин. Находки он отдаёт готовыми формулировками, подставляешь их ты.
 **Условие вызова — правка, а не синк.** Синк самый частый вызывающий, но не
-единственный: разведка (`av-dev-code:resolve`, сценарий разведки) пишет ответ по
+единственный: разведка (`av-dev:code-resolve`, сценарий разведки) пишет ответ по
 одному адресу и синком себя не считает намеренно — вычитка ей нужна ровно та же.
 Признак один и читается буквально: **документы правились — зови, ничего не правил
 — не зови**.
@@ -103,7 +103,7 @@ description: Вести содержимое документов канона
 сочиняет заново.
 **Второй законный источник — записка разведки**, и приходит он от скилла
-`av-dev-code:resolve`, сценарий разведки: решение, принятое разведкой (намеренный отказ, выбор
+`av-dev:code-resolve`, сценарий разведки: решение, принятое разведкой (намеренный отказ, выбор
 подхода, «проверили и не делаем»), `design.md` не имеет по построению — change по
 нему не будет никогда. Промоут при этом тот же: цитата и ссылка, но на записку.
 Перечень источников закрыт и живёт в [каноне](../canon/references/canon.md),
@@ -151,13 +151,13 @@ description: Вести содержимое документов канона
 **Копия.** Дом правила — `shared/plugin-boundary.md` в репозитории плагинов.
 Правится дом, а не этот файл.
-<!-- копия: граница-плагинов из shared/plugin-boundary.md -->
+<!-- копия: граница-плагинов из av-dev/shared/plugin-boundary.md -->
 Плагины `av-dev` ставятся порознь, и ни один не вправе считать, что сосед на
 месте.
-**Чужой скилл зовётся полным именем** — `av-dev-docs:canon`, `av-dev-tasks:tasks`,
+**Чужой скилл зовётся полным именем** — `av-dev:doc-canon`, `av-dev:task-track`,
-`av-dev-code:review`. Короткое имя может разрешиться в устаревшую проектную копию
+`av-dev:code-review`. Короткое имя может разрешиться в устаревшую проектную копию
 из `.claude/skills/`, и подмены не будет видно ни в докладе, ни в поведении.
 **Путь в дерево чужого плагина не пишется никогда.** `$CLAUDE_PLUGIN_ROOT` ведёт
@@ -187,7 +187,7 @@ description: Вести содержимое документов канона
 конвейера. **Что в каком и в какой форме — в
 [каноне](../canon/references/canon.md), раздел `review.md`**; подробности формы
 записи и выбор адреса, куда она ведёт, — у конвейера ревью проекта (при
-`av-dev-code` — `Skill av-dev-code:review`, его
+`av-dev-code` — `Skill av-dev:code-review`, его
 `references/review-journal.md`). **Конвейера в проекте нет** — пиши по форме из
 скелета `review.md`, которую положил канон, и скажи в докладе, что подробностей
 формы взять негде.
@@ -201,7 +201,7 @@ description: Вести содержимое документов канона
 Находка → конвенция → правило линтера → **удаление из прозы**. Процедура целиком
 принадлежит конвейеру ревью проекта (при `av-dev-code` — его
-`references/promote.md`, читается через `Skill av-dev-code:review`);
+`references/promote.md`, читается через `Skill av-dev:code-review`);
 роль каталога конвенций — в [каноне](../canon/references/canon.md). **Конвейера
 нет** — три шага всё равно твои, просто без его процедуры: сформулируй правило,
 поищи, чем оно механизируется, и вычеркни прозу, если механизировалось.
@@ -1,5 +1,5 @@
 ---
-name: groom
+name: task-groom
 description: "Груминг беклога — интерактивный разбор, отвечающий на два вопроса: что сейчас самое важное и что перестало быть важным. Ответ записывается порядком строк в беклоге: первая строка — то, что делают следующим. Разбирает накопившиеся вопросы, переоценивает задачи порциями по 5–8 (сделано попутно, отменено решением, слилось с соседней, подешевело, разрослось, стало сырьём), закрывает отжившее с причиной и расставляет очередь. Использовать, когда просят разобрать беклог, расставить приоритеты, решить «что делать дальше», провести груминг или переоценку, а также когда вернулись к проекту после перерыва и надо понять, где остановились. Формат и содержимое записей — скилл tasks; выполнение задачи — конвейер проекта."
 ---
@@ -164,7 +164,7 @@ flowchart TD
 Но повод назвать это здесь есть: беклог и документы протухают от одного и того
 же — от сделанной работы. Пришёл на груминг и видишь, что с прошлого раза сделан
 десяток задач, — скажи строкой, что документы стоит сверить
-(`av-dev-docs:healthcheck`), и иди дальше. Плагина в проекте нет — сверять нечем,
+(`av-dev:doc-healthcheck`), и иди дальше. Плагина в проекте нет — сверять нечем,
 и это тоже строка.
 ## Интерактив
@@ -1,5 +1,5 @@
 ---
-name: tasks
+name: task-track
 description: Ведение задач и целей как каталога markdown-файлов (одна запись = один файл в items/ + строка в одном из индексов). У каждой записи есть тип (goal, feature, fix, chore, research), и тип решает, каких разделов она требует и что с ней можно делать. Заведение записи из диалога, разбор находок аудита/ревью, декомпозиция на независимо полезные части, штурм сырья, гигиена полей и проверка согласованности индексов. Использовать, когда просят добавить задачу/идею/цель, превратить находки ревью в задачи, разбить задачу, проработать идею, поправить формат или проверить беклог. Он же повышает каталог до текущей версии формата по своему журналу версий, когда tasks.py check говорит, что каталог отстал. Расстановка приоритетов и разбор накопившегося — скилл groom. Не реализует задачи — этим занимается скилл решения задачи.
 ---
@@ -581,7 +581,7 @@ python3 $tk adopt scan --from … | apply --plan …   # разовая адап
 **одним проходом вместе с починкой перекрёстных ссылок**, а не по одному слагу.
 Если переводить надо не только задачи, а весь `docs/` — это скилл
-`av-dev-docs:canon`, и он зовёт этот сценарий сам на своём шаге.
+`av-dev:doc-canon`, и он зовёт этот сценарий сам на своём шаге.
 ### Декомпозиция и штурм сырья
@@ -626,7 +626,7 @@ python3 $tk adopt scan --from … | apply --plan …   # разовая адап
 Зовутся они **пачкой, а не на каждую запись**: после заведения нескольких задач,
 после разбора находок ревью, после того как чужая работа уточнила записи (так
-делает разведка в `av-dev-code:resolve`), и на переоценке. Передаётся список файлов и — если
+делает разведка в `av-dev:code-resolve`), и на переоценке. Передаётся список файлов и — если
 есть — паспорт, архитектура и конвенции проекта: по ним отличается неизвестный
 термин от известного.
@@ -686,7 +686,7 @@ python3 $tk adopt scan --from … | apply --plan …   # разовая адап
 - **Каталог задач — `tasks/` в корне, жёстко**, и `--dir` передаётся явно всегда:
  раскладка канона одинакова во всех проектах, и искать больше нечего. Каталога
  нет — код 3 и вопрос человеку; `init` заводит его **только** когда проект
-  действительно новый, а перевод чужой раскладки делает `av-dev-docs:canon`.
+  действительно новый, а перевод чужой раскладки делает `av-dev:doc-canon`.
  У скрипта поиск вверх по дереву ещё жив — он для непереведённых проектов, и
  полагаться на него скилл не должен: молча найденный чужой каталог это дрейф.
 - **Версия формата и настройки живут в `<каталог задач>/.tasks.json`** — свой
@@ -713,7 +713,7 @@ python3 $tk adopt scan --from … | apply --plan …   # разовая адап
 переменной не дотянутся. Мост — **вызов скилла через пространство имён**, а не
 путь:
-> Чужой контекст зовёт `Skill av-dev-tasks:tasks` и называет, что нужно сделать
+> Чужой контекст зовёт `Skill av-dev:task-track` и называет, что нужно сделать
 > («закрой задачу `<слаг>`, реализована»). Скилл разрешает свой
 > `$CLAUDE_PLUGIN_ROOT` сам. Путь наружу не выносится вовсе.
@@ -5,7 +5,7 @@
 после неё проект живёт скиллами `tasks` и `groom`.
 **Это часть приведения проекта к канону.** Раскладку `docs/` целиком ведёт скилл
-`av-dev-docs:canon`; он же зовёт этот сценарий на шаге «каталог задач», потому что
+`av-dev:doc-canon`; он же зовёт этот сценарий на шаге «каталог задач», потому что
 форматом задач владеет `tasks`, а не `canon`. Отдельно сценарий вызывается,
 когда переводить надо **только** задачи.
@@ -12,7 +12,7 @@
 не файл-на-находку.** Если у ревью был триаж — половина работы уже сделана, бери
 его выход. Если нет — триажируй сам, прежде чем заводить.
-**Штатный отправитель — `av-dev-code:review`** (и `av-dev-code:resolve`, который
+**Штатный отправитель — `av-dev:code-review`** (и `av-dev:code-resolve`, который
 его вызывает): задач он не заводит сам, а отдаёт отложенные находки **списком
 урожая** — формулировка, оракул, провенанс — и хранит отчёт триажа вместе с
 изменением. Приходит и любой другой разбор, вплоть до пересказа человеком; тогда
@@ -4,7 +4,7 @@
 документов канона и для задач, и потому не принадлежит ни одному плагину.
 Правится дом, а не этот файл: расхождение ловит `copies.py` на гейте коммита.
-<!-- копия: язык-доктрина из shared/language.md -->
+<!-- копия: язык-доктрина из av-dev/shared/language.md -->
 Правила — для всего, что пишется словами: задачи и цели, документы канона,
 решения ADR, записки разведки, сообщения коммитов. Не для кода и не для
@@ -70,7 +70,7 @@
 ## Правила
-<!-- копия: язык-правила из shared/language.md -->
+<!-- копия: язык-правила из av-dev/shared/language.md -->
 У каждого правила названа причина: она же говорит, где правило **не**
 применяется.
@@ -193,7 +193,7 @@
 ## Порог правки
-<!-- копия: порог-правки из shared/language.md -->
+<!-- копия: порог-правки из av-dev/shared/language.md -->
 **Правка без нарушенного правила не делается.** Текст, переписанный «чтобы
 звучало лучше», обесценивает список замечаний: когда половина из них вкусовая,
@@ -8,7 +8,7 @@
 на «что приложение будет уметь», а на «чем его держат», и путать эти два вопроса
 нельзя.
-<!-- копия: сопровождение-словарь из shared/operations.md -->
+<!-- копия: сопровождение-словарь из av-dev/shared/operations.md -->
 Одна тема живёт в трёх местах, и путать их слова нельзя.
@@ -113,7 +113,7 @@ PM_CONFIG_REL = "../.pm.json"     # прежний дом настроек: docs
 # Версия формата задач — **своя, а не канона документов**. Число живёт ключом
 # `tasks` в `.tasks.json`, журнал версий — references/changelog.md рядом со
-# скриптом, повышает его операция `upgrade` скилла `av-dev-tasks:tasks`.
+# скриптом, повышает его операция `upgrade` скилла `av-dev:task-track`.
 #
 # Число именно своё, потому что плагин ставится в одиночку: проект, взявший учёт
 # работ без канона документов, каталога `docs/` не имеет вовсе, а значит не имеет
@@ -515,7 +515,7 @@ def _validate_config(data: dict, path: Path) -> dict:
    if "plan" in unknown:
        raise Env(f"{path}: ключ «plan» переименован в «roadmap»,"
                  f" а PLAN.md — в ROADMAP.md. Повысь проект скиллом"
-                  f" av-dev-docs:canon (upgrade), а не правь ключ в одиночку:"
+                  f" av-dev:doc-canon (upgrade), а не правь ключ в одиночку:"
                  f" файл и ссылки на него переезжают вместе с ним")
    if unknown:
        known = sorted({*DEFAULTS, VERSION_KEY})
@@ -588,7 +588,7 @@ def version_problems(lay: Layout) -> list[str]:
    if not path.is_file():
        return [f"нет {path} — версия формата задач не объявлена."
                f" Заведи файл с «{VERSION_KEY}»: {FORMAT_VERSION} (журнал версий —"
-                f" references/changelog.md скилла av-dev-tasks:tasks)"]
+                f" references/changelog.md скилла av-dev:task-track)"]
    # Что число целое, уже проверил `_validate_config` — иначе сюда не дошли бы
    # вовсе (код 3). Здесь `isinstance` значит ровно «ключ есть».
    got = lay.cfg.get(VERSION_KEY)
@@ -598,7 +598,7 @@ def version_problems(lay: Layout) -> list[str]:
    if got < FORMAT_VERSION:
        return [f"каталог приведён к формату версии {got}, текущая —"
                f" {FORMAT_VERSION}: нужно повышение по журналу"
-                f" (скилл av-dev-tasks:tasks, операция upgrade)"]
+                f" (скилл av-dev:task-track, операция upgrade)"]
    if got > FORMAT_VERSION:
        return [f"каталог приведён к формату версии {got}, а скрипт знает"
                f" {FORMAT_VERSION}: устарел плагин, обнови маркетплейс"]
@@ -56,9 +56,9 @@ quote-style = "double"
 [tool.pyrefly]
 project-includes = [
-    "av-dev-tasks/skills/tasks/scripts/tasks.py",
+    "av-dev/skills/task-track/scripts/tasks.py",
-    "av-dev-docs/skills/canon/scripts/docs.py",
+    "av-dev/skills/doc-canon/scripts/docs.py",
-    "av-dev-code/skills/openspec/scripts/openspec.py",
+    "av-dev/skills/code-openspec/scripts/openspec.py",
    "scripts/addresses.py",
    "scripts/copies.py",
    "scripts/diagrams.py",
@@ -49,15 +49,15 @@ SKIP_DIRS = {".git", ".venv", "node_modules", "__pycache__", "tmp"}
 # Владельцы: префикс адреса → скрипт, который этим каталогом и владеет.
 OWNERS = {
-    "docs": "av-dev-docs/skills/canon/scripts/docs.py",
+    "docs": "av-dev/skills/doc-canon/scripts/docs.py",
-    "tasks": "av-dev-tasks/skills/tasks/scripts/tasks.py",
+    "tasks": "av-dev/skills/task-track/scripts/tasks.py",
 }
 # Журналы: описывают прошлые состояния и задним числом не переписываются.
 # Адрес, верный на момент записи, здесь останется навсегда, и это не дрейф.
 JOURNALS = {
-    "av-dev-docs/skills/canon/references/changelog.md": "журнал версий канона",
+    "av-dev/skills/doc-canon/references/changelog.md": "журнал версий канона",
-    "av-dev-tasks/skills/tasks/references/changelog.md": "журнал версий формата задач",
+    "av-dev/skills/task-track/references/changelog.md": "журнал версий формата задач",
    "DECISIONS.md": "журнал решений",
    "HISTORY.md": "журнал работ",
    "NOTES.md": "рабочие заметки",
@@ -66,9 +66,9 @@ JOURNALS = {
 # Файлы, где упразднённый адрес назван по делу: карта переездов и сценарии
 # перевода чужой раскладки. Неизвестные адреса в них проверяются как везде.
 RETIRED_OK = {
-    "av-dev-docs/skills/canon/references/canon.md": "карта упразднённых слотов",
+    "av-dev/skills/doc-canon/references/canon.md": "карта упразднённых слотов",
-    "av-dev-docs/skills/canon/SKILL.md": "adopt: что где искать в чужой раскладке",
+    "av-dev/skills/doc-canon/SKILL.md": "adopt: что где искать в чужой раскладке",
-    "av-dev-tasks/skills/tasks/references/adopt.md": "перевод чужого каталога задач",
+    "av-dev/skills/task-track/references/adopt.md": "перевод чужого каталога задач",
 }
 # Адрес в прозе: начало токена, префикс владельца, остаток пути. Отрицательный
@@ -21,7 +21,7 @@
 **Цвет, не отвечающий модели.** Цвет charter'а кодирует **модель**, на которой
 идёт проход, а не его роль: раскладка — в
-`av-dev-code/skills/review/SKILL.md`, раздел «Модель по проходу».
+`av-dev/skills/code-review/SKILL.md`, раздел «Модель по проходу».
 Правило существует ровно затем, чтобы стоимость прогона читалась взглядом по
 списку агентов, и держаться вниманием оно не может: цвет ставится один раз при
 заведении charter'а, а модель потом меняется калибровкой.
@@ -49,7 +49,7 @@ from pathlib import Path
 OK, DRIFT, USAGE, ENV, INTERNAL = 0, 1, 2, 3, 4
-# Дом раскладки — «Модель по проходу» в av-dev-code/skills/review/SKILL.md; здесь её
+# Дом раскладки — «Модель по проходу» в av-dev/skills/code-review/SKILL.md; здесь её
 # механизация. Порядок цветов — порядок стоимости прогона.
 PALETTE = {"sonnet": "green", "opus": "yellow"}