dev-skills/decisions/07-skills-layout-scripts.md

7. Раскладка скиллов и доставка скриптов (2026-08-03)

Решено

Р24. Пять скиллов в av-dev-pm.

av-dev-pm/skills/
  init/      интервью по брифу → канон нового проекта
  canon/     раскладка: check / adopt / upgrade
  docs/      содержимое канона: ADR из архивного design.md, промоут конвенций,
             запись в research/ и review.md, чистка architecture.md
  tasks/     формат и содержимое задач
  session/   ритуал спринта

Причина отдельного docs: правила ведения содержимого канона обязаны жить у владельца канона, а не в шаге синка чужого плагина — иначе проект без пайплайна документацию вести не может. Это работает потому, что вызов скилла через пространство имён между плагинами возможен, в отличие от $CLAUDE_PLUGIN_ROOT: task-pipeline уже зовёт opsx:propose и av-dev-pipeline:review-pipeline. Шаг синка зовёт av-dev-pm:docs, а в чужом проекте деградирует до прозаического списка.

Симметрия, по которой резалось: раскладка и содержимое разделены и для документов, и для задач — canon / docs, tasks / session.

Р25. Скрипты не копируются — живут вместе со скиллами. Три вызывающих, три способа дотянуться:

Кто зовёт	Как
скиллы tasks, canon, docs	$CLAUDE_PLUGIN_ROOT — свой плагин, работает всегда
task-pipeline, task-batch	вызов скилла av-dev-pm:tasks, а не путь
гейт проекта	путь переменной с умолчанием на канонический путь маркетплейса; пишет canon adopt, внятный красный отказ, если не найден

Слот «Команда учёта задач» всё равно исчезает — но снимает его не копия, а вызов скилла через пространство имён. Тот же приём, которым шаг синка зовёт av-dev-pm:docs (решение Р24): чужой плагин зовёт скилл, скилл разрешает свой $CLAUDE_PLUGIN_ROOT сам. Путь наружу не выносится вовсе.

Первоначально здесь было решено вендорить scripts/tasks.py и scripts/docs.py в проект. Отменено после проверки фактов:

• CI нет ни в одном проекте (ни .github, ни woodpecker, ни drone). Pre-commit есть только у jellybit — lefthook с gofmt/vet/lint/test/gitleaks — и гоняется на той же машине, где установлен плагин. Довод «не работает в CI и у человека без Claude Code» оказался гипотетическим.
• Пара «источник — копия» существует и без вендоринга. Установленный маркетплейс — git-клон; на момент разбора он стоял на 092d07c, на четыре коммита позади master, и av-dev-tasks с av-dev-pipeline в нём отсутствовали вовсе. Довод «вендоринг создаёт вторую копию» был слабее, чем подан.
• Обновление маркетплейса — одна точка на все проекты. При вендоринге каждый проект повышается отдельно, и проекты расходятся друг с другом — ровно та разнородность, против которой принято решение Р6.

Р26. Имени у процесса нет — процесс это av-dev. Маркетплейс уже av-dev-skills, плагины av-dev-*; в CLAUDE.md проекта пишется «процесс av-dev, канон версии N». Имя, которое нигде не работает, — украшение.

Что из этого следует

С32. Решение P уточняется: оркестратор закрывает задачи вызовом скилла av-dev-pm:tasks, а не запуском скрипта по пути. Плагина в проекте нет — вызов не разрешается, и пайплайн, как прежде, только докладывает исход.

С33. Слот исчезает из двух скиллов — tasks (слот 6) и session (слот 7), — и из текстов task-pipeline и task-batch, которые на него ссылаются.

С34. canon upgrade отвечает за раскладку и версию в docs/.pm.json. Скрипты обновляются обновлением маркетплейса, а не проектом.

С35. Скрипты живут в av-dev-pm/skills/{tasks,canon}/scripts/. docs.py — в canon, потому что раскладку проверяет он.

С36. canon check сверяет версию канона проекта с версией установленного плагина и говорит, кто отстал. Это нужно и без вендоринга: маркетплейс — git-клон, обновляется явно, и на момент разбора отставал на четыре коммита.

С37. Установленный маркетплейс требует обновления перед любой работой — сейчас в нём нет ни av-dev-tasks, ни av-dev-pipeline. Это первый шаг выката (тема 8), иначе проверять будет нечего.