dev-skills/av-dev-code/skills/resolve/SKILL.md

name, description

name

description

resolve

Решить одну задачу от постановки до закрытия. На входе путь к файлу задачи, её слаг или просто текст. Обычная задача идёт циклом Spec Driven Development: opsx propose → разметка → ревью дизайна → чекпоинт с объяснением человеческим языком → opsx apply → ревью кода → archive → синк документации → коммит → закрытие. Исследовательская (тип research, сырая идея, мутная постановка) начинается раньше: opsx explore и чекпоинт вариантов — два-четыре способа решить, с ценой каждого и рекомендацией; выбор оседает по адресу, который назвала сама задача. Между чекпоинтами работа идёт без согласований. Использовать, когда просят взять, сделать или решить задачу, довести идею до реализации, разобраться с записью из беклога.

Решение одной задачи

Проводит одну задачу от постановки до закрытия. Между плановыми остановками — без согласований: механику не обсуждаем, делаем.

Тонкая обёртка над каноническими скиллами opsx:explore / opsx:propose / opsx:apply / opsx:archive — зови их через Skill, не переизобретай их шаги. Ревью — скилл av-dev-code:review; он же держит правило выбора метки, а называет её агент review-scope — один раз на задачу, для обеих стадий ревью.

Предпосылки

• OpenSpec и скиллы opsx:* — жёсткая предпосылка, а не опция. На них стоят шаги 2, 6 и 8, шаг Р2 разведки, проход review-specs и ревью дизайна (они завязаны на openspec/changes/<id>/specs/*/spec.md и на openspec validate --strict). Проект без OpenSpec этим скиллом не ведётся — подключай OpenSpec, а не вырождай цикл; почему ветка деградации здесь не пишется, сказано в av-dev-code:review, раздел «Предпосылки», и дом у этого довода там. Заводить руками не надо: каталог и настройку в config.yaml делает скилл av-dev-code:openspec.
• Проектные копии этих скиллов и агентов удаляются при установке плагина (.claude/skills/ — голые имена resolve, review, а у проектов прошлого поколения ещё task-pipeline, review-pipeline, task-batch, и с префиксом проекта: <проект>-task-pipeline, <проект>-review-pipeline; .claude/agents/<проект>-review-*.md). Две копии одного скилла расходятся, и побеждает та, что короче названа.

Обращение к соседним плагинам

Копия. Дом — shared/plugin-boundary.md в репозитории плагинов: правило общее для всех, кто зовёт чужое, и ни один плагин им не владеет. Правится дом, а не этот файл.

Плагины av-dev ставятся порознь, и ни один не вправе считать, что сосед на месте.

Чужой скилл зовётся полным именем — av-dev-docs:canon, av-dev-tasks:tasks, av-dev-code:review. Короткое имя может разрешиться в устаревшую проектную копию из .claude/skills/, и подмены не будет видно ни в докладе, ни в поведении.

Путь в дерево чужого плагина не пишется никогда. $CLAUDE_PLUGIN_ROOT ведёт только в свой плагин; вычисленный от него путь к соседу либо не откроется, либо откроет чужую установку. Нужен чужой справочник — зови владеющий им скилл, он прочитает его сам.

Вызов не разрешился — плагина в проекте нет. Это исход, а не поломка: назови строкой доклада, чего теперь не делает никто, и продолжай работу. Молчать нельзя, пропуск неотличим от сделанного; выдумывать обходной путь нельзя тоже.

Присутствие узнаётся вызовом или следом в проекте, но не объявлением. Перечня установленных плагинов проект не ведёт — он разошёлся бы с действительностью молча. Что сосед здесь работал, видно по заведённому им файлу: docs/.docs.json — канон, <каталог задач>/.tasks.json — задачи, openspec/config.yaml — конвейер. Имя файла — имя плагина, который его завёл, и держит он в том числе версию своего формата: у канона документов и у каталога задач они свои и двигаются порознь.

Скилл зовёт av-dev-code:review, av-dev-docs:docs и av-dev-tasks:tasks. Чем оборачивается отсутствие каждого — на самих шагах и в разделе «Границы».

Перед стартом прочитай CLAUDE.md проекта и то, на что он ссылается, если ещё не в контексте. Проектные факты, нужные ревью — инварианты, семантика гейта, объёмы, модель угроз, прецеденты, — живут в документах канона av-dev-docs; карта «что где» — references/project-facts.md конвейера ревью.

Документов канона нет — проект к нему не приведён. Скажи это строкой и предложи скилл av-dev-docs:canon: одна операция на проект против поразрядной деградации на каждой задаче. Работу при этом не останавливай.

Вход

Задача задаётся путём к файлу, именем файла, слагом или просто текстом. Ничего из этого не задано — попроси у вызывающего и остановись; сам в беклог не лезь и приоритеты не интерпретируй: что делать дальше, решает не этот скилл.

Запись из каталога сперва проверяется на готовность, и проверяет её машина. Вызови Skill av-dev-tasks:tasks и попроси прогнать ready <слаг>: он смотрит тип, цель у feature, пустой ли раздел вопросов и собраны ли разделы схемы типа. Судить это глазами нельзя — ровно тот случай, где машина дешевле и точнее, а цена ошибки отложенная: недостающие критерии приёмки обнаружатся на приёмке, когда сверять уже не с чем.

ready отказал — это исход, а не препятствие для тебя. Скажи, чего не хватает, и остановись: дописывать чужую запись за автора не твоя работа, а у сырья (research без раздела «Вопрос») и дописывать нечего — там сперва нужен вопрос. Исход — «не доведена», с названной причиной.

Плагина av-dev-tasks в проекте нет или задача пришла текстом — прогонять нечего. Тогда прочитай постановку сам и скажи строкой, что готовность машиной не проверялась; работу при этом не останавливай.

Две ветки

Развилка одна и стоит на входе:

• обычная задача — что делать, понятно; спорно только как. Идёт с шага 1;
• исследовательская — тип research, сырая идея, новое и незнакомое, мутная постановка. Идёт с шага Р1, и там её ждёт свой чекпоинт: варианты решения обсуждаются до того, как написано первое требование.

Признак не в объёме работы, а в том, есть ли у задачи один очевидный способ решения. Его нет — обсуждать варианты после propose поздно: предложение уже воплотило один из них, и разговор пойдёт не о выборе, а о переделке.

flowchart TD
    in["вход: файл, слаг или текст"]
    fork{"есть очевидный<br/>способ решения?"}
    r1["Р1. понять вопрос<br/>сырьё без «Вопроса» — отказ"]
    r2["Р2. opsx:explore — груминг"]
    r3(["Р3. ЧЕКПОИНТ: варианты<br/>2–4 способа, цена каждого,<br/>рекомендация"])
    rout["исход без кода:<br/>ответ записан / отказ / родились задачи"]
    s1["1. прочитать задачу<br/>критерии приёмки выписать сразу"]
    s2["2. opsx:propose — change, дельта-спеки, tasks.md"]
    s3["3. разметка — review-scope:<br/>размер, сложность, метка, план тем"]
    s4["4. ревью дизайна, состав по метке<br/>+ отработка замечаний"]
    s5(["5. ЧЕКПОИНТ: объяснение<br/>в чём проблема, как решаем,<br/>чем рискуем"])
    s6["6. opsx:apply — код, гейт,<br/>поведенческая верификация"]
    s7["7. ревью кода, та же метка<br/>+ отработка замечаний"]
    s8["8. opsx:archive"]
    s9["9. синк документации — av-dev-docs:docs"]
    s10["10. коммит работы — av-dev-git:commit"]
    s11["11. закрыть задачу — av-dev-tasks:tasks,<br/>вторым коммитом учёта"]

    in --> fork
    fork -->|"да"| s1
    fork -->|"нет"| r1
    r1 --> r2 --> r3
    r3 -->|"выбран способ"| s1
    r3 -.->|"кода не будет"| rout
    s1 --> s2 --> s3 --> s4 --> s5 --> s6 --> s7 --> s8 --> s9 --> s10 --> s11
    s3 -.->|"план задачи: та же метка"| s7
    s5 -.->|"скорректировать:<br/>меняются дельта-спеки"| s3
    s7 -.->|"находка отменяет дизайн:<br/>меняются дельта-спеки"| s3

Схема — сводка: содержание каждого шага в его разделе ниже, и при расхождении прав текст.

Автономность и два плановых стопа

Между чекпоинтами умолчание прежнее — делать, а не спрашивать. Чекпоинты не отменяют автономность, они дают развилкам плановое место, куда копиться.

Разрез простой:

• развилка найдена до ближайшего чекпоинта — она его и ждёт. Не спрашивай отдельно: чекпоинт рядом и стоит дёшево, а три вопроса подряд стоят дороже одного разговора;
• развилка найдена после последнего чекпоинта — старое правило: запиши вопрос и доведи остаток, не останавливаясь.

Запись вопроса устроена так:

1. Запиши там, где проект держит вопросы (секция беклога, файл задачи, трекер — это знает проект). Проект не сказал, куда, — отдельной секцией Вопросы в своём докладе, и это тоже исход. Тело отвечает на три вещи: что именно решить, какие есть варианты и цена каждого, что стоит, пока решения нет. Плюс твоя рекомендация — человек чаще соглашается, чем выбирает заново, и готовое суждение экономит ему весь контекст.
2. Переформулируй задачу на остаток — то, что делается без этого решения. Назови границу: докуда доводим сейчас.
3. Доведи остаток до конца и закоммить. Задача не «висит на вопросе», она сделана в объявленных границах.

Что остатком не является — правило живёт не здесь. Канонический текст с обеими оговорками — в плагине av-dev-tasks, скилл av-dev-tasks:groom, раздел ## Вопрос, блокер, необратимое, подраздел «Отличать вопрос от застревания». Правило принадлежит управлению задачами, потому что решает сделана задача или вышла, — это исход планирования, а не исполнения. Ссылайся, не пересказывай: копия, заведённая здесь, уже однажды разошлась с оригиналом и потеряла из перечня самое необратимое — запись наружу.

Коротко, чтобы знать, когда идти читать: остаток проверяется двумя порогами — материализация нерешённого (запись состояния, зависящего от неотвеченного вопроса) и пол по пользе (из остатка пропала польза, названная в постановке). Оба порога — стоп: первый поднимает решение до начала записи, второй даёт исход «не доведена».

Плагин av-dev-tasks не подключён — правило не отменяется, а становится осторожнее: прежде чем записать зависящее от нерешённого куда бы то ни было — в хранилище, в журнал, в витрину или наружу, — спрашивай человека.

Нет полезного остатка — задача заканчивается исходом «не доведена», вопрос записан, ничего не коммитится наполовину.

Когда спрашивать вне чекпоинтов

По другому основанию — не «сложное решение», а необратимое действие:

• деплой, выкладка наружу, смена публичного адреса или токенов;
• удаление или перезапись рабочих данных, включая подрезку архивов;
• всё, что уходит за пределы машины.

Здесь ошибка не откатывается коммитом, поэтому спрашиваем даже когда решение кажется очевидным.

Стиль правок — заточка под проект и конвенции, right-size, без золочения.

Границы: чем этот скилл не владеет

• Беклогом, целями и приоритетами. Задача приходит извне. Скилл её не выбирает, не приоритизирует, не заводит и не переоценивает.
• Форматом задач. Индексы руками не правятся, путь к скрипту учёта не выдумывается: этим владеет av-dev-tasks:tasks (шаг 11). Закрытие — работа этого скилла, и это осознанное решение с названной ценой: приёмщик и исполнитель совпали. Закрытие поэтому не окончательно — человек на груминге (av-dev-tasks:groom) возвращает задачу reopen с причиной, а доклад по критериям приёмки становится единственным, по чему приёмка вообще возможна.
• Заведением задач из урожая ревью. Отложенные находки отдаются списком; превращать их в задачи — работа av-dev-tasks:tasks, у него на этот вход отдельный сценарий «задачи из ревью и аудита». Плагина нет — урожай остаётся списком в докладе, и это говорится строкой.
• Определением ценности. «Нужна ли эта функциональность» — не вопрос этого скилла ни на одном шаге. Чекпоинт спрашивает «так ли решаем», а не «надо ли».

Наблюдаемые исходы

Ровно четыре, и каждый обязан быть назван в докладе прямо:

• сделана — определение сделанного выполнено целиком;
• не доведена — с причиной и с записанным вопросом; что именно сделано и до какой границы, названо явно. Сюда же попадает чекпоинт, на котором человек решение не одобрил;
• оказалась крупнее задачи — распознаётся до заведения change, иначе его придётся выбрасывать. Дальше — декомпозиция, и это не работа этого скилла;
• знание вместо изменения — только у исследовательской ветки: ответ записан по названному адресу, кода задача не потребовала. Это полноправный исход, а не недоведённая работа.

Определение сделанного

Задача сделана, когда верно всё:

1. гейт проекта зелёный;
2. ревью проведено, план прогона сверен с исходом по каждой теме, темы без отчёта и без дома названы в границах покрытия;
3. решение прошло чекпоинт и не разошлось с одобренным — либо разошлось, и чекпоинт был пройден заново;
4. change заархивирован, дельты влиты в актуальные спеки;
5. коммит сделан в текущую ветку;
6. критерии приёмки, если проект их дал, выписаны поимённо, и по каждому назван оракул и наблюдаемый исход — «прогнал вот это, увидел вот то». Это доклад, а не сертификация: приёмка — не работа этого скилла. Исполнитель, ставящий себе галочку «принято», проверяет свою работу своим же взглядом — по границе это может делать только приёмщик, разведённый с исполнителем. Критерии приходят снаружи; скилл их не сочиняет и не занижает. Расхождение «по каждому критерию исход есть, а суть задачи не достигнута» — дефект критериев, и о нём сообщается, а не молча дорабатывается.

У разведки, кончившейся знанием, определение своё и короткое: ответ записан по адресу, который назвала задача, и в нём есть провенанс у каждого числа.

Исследовательская ветка

Р1. Понять вопрос

Прочитай запись. У типа research в ней два обязательных раздела, и оба нужны тебе прямо сейчас: «Вопрос» — на что отвечаем, «Куда ляжет ответ» — по какому адресу он ляжет. Адрес назван заранее не из аккуратности: ответ, не имеющий дома, остаётся в переписке, и через квартал разведку заказывают заново.

Вопроса нет — исход «не доведена» с причиной «запись это сырьё»: назови, что нужно дописать, и остановись. Адреса нет, а вопрос есть — назначь адрес сам и скажи об этом строкой: разведка без дома для ответа хуже несделанной.

Задача не из каталога (пришла текстом) — адреса у неё нет по построению. Тогда дом ответа — design.md того change, который родится дальше; кода не будет — docs/research/, и это тоже говорится строкой.

Р2. Груминг — opsx:explore

Вызови Skill opsx:explore. Читай документы проекта, а не только запись: граница домена и «чем проект не является» из паспорта отсекают половину вариантов до того, как их начнут сравнивать. В explore не пишем код.

Развилку грумминга не записывай вопросом — она и есть предмет следующего шага. Это отличие от обычной ветки: там развилка уходит в запись, здесь она копится в чекпоинт.

Р3. Чекпоинт: варианты

Остановись и покажи человеку способы решить. Это первый из двух плановых стопов, и он существует потому, что после propose выбор уже сделан предложением.

Форма — короткая, экран текста:

• вопрос, на который отвечаем, одной фразой (он уже есть в записи);
• 2–4 варианта, не больше. Больше четырёх — это не выбор, а список: человек не сравнит, а признает свою неспособность сравнить и попросит рекомендацию. У каждого варианта: в чём суть простыми словами, что даёт, чего стоит, что становится невозможным (это ловится хуже всего и стоит дороже всего);
• рекомендация с причиной. Человек чаще соглашается, чем выбирает заново;
• что известно недостоверно и как это проверить, если проверять дёшево.

Что нельзя: приносить варианты, различающиеся только реализацией; прятать отвергнутое (отвергнутый вариант с названной причиной — половина будущего ADR); приносить один вариант и называть это выбором.

Выбор оседает по адресу. У research это раздел «Куда ляжет ответ». У остальных — design.md change, который родится на шаге 2, разделом «рассмотренные варианты». Не в переписку: разговор, из которого ничего не записано, повторяется через месяц целиком.

Три исхода чекпоинта:

• выбран способ — идёшь на шаг 1 общей ветки;
• ответ и есть исход — работа кончается знанием: запиши ответ по адресу, доложи исход «знание вместо изменения» и закрой задачу (шаг 11). Провенанс у каждого числа обязателен: число без источника проход ревью обязан читать как условие, а не как замер;
• разведка родила задачи — исход «оказалась крупнее задачи». Нарезка не твоя работа: отдай список формулировками и остановись.

Шаги

1. Прочитать задачу

Прочитай запись и связанные спеки и черновики.

Проект даёт задаче критерии приёмки — выпиши их сразу: на шаге 2 они уезжают в tasks.md change. Файл задачи может быть удалён до коммита, а критерии обязаны его пережить.

Здесь же проверка на «крупнее задачи»: видно, что одним заходом это не мерджится, — объявляй исход до заведения change.

2. Завести change — opsx:propose

Вызови Skill opsx:propose. Получаем proposal.md, дизайн, дельта-спеки (ADDED/MODIFIED/REMOVED Requirements), tasks.md. Каждое ### Requirement содержит SHALL/MUST; структурные заголовки английские, сценарии GIVEN/WHEN/THEN. Прогони openspec validate --strict <id>.

Критерии приёмки задачи, если они были, копируются в tasks.md отдельным блоком. Варианты, разобранные на чекпоинте Р3, — в design.md, с причиной отказа по каждому отвергнутому.

proposal.md пишется так, чтобы его понял человек, не читавший спек. Это не стилистическое пожелание: из него собирается чекпоинт шага 5, и переписывать его там заново значит завести второй дом для одного объяснения. Требование стоит в openspec/config.yaml, rules.proposal — то есть применяется в момент порождения артефакта, а не вспоминается после.

3. Разметка задачи — агент review-scope

Один запуск на всю задачу, и он обслуживает оба чекпоинта ревью. Запусти агента review-scope, дав ему корень проекта, идентификатор change, базу диффа и запись задачи. Кода на этот момент нет, и это условие его работы, а не помеха.

Он возвращает план задачи:

• размер (малое / среднее / крупное) и сложность (знакомое / незнакомое), каждое с обоснованием по факту;
• метку как максимум по двум осям: small, medium или large;
• состав ревью дизайна — что звать на шаге 4;
• таблицу тем «тема → дом → глубина → кто закрывает» — для шага 7;
• разнесение документов проекта по трём категориям и строку про директивы.

Метку выбираешь не ты. Раньше состав ревью дизайна называл сам оркестратор — то есть тот, кто только что довёл предложение до propose. Разведённости с автором в этой точке не было вовсе; теперь есть.

План держи в контексте до конца задачи. На диск он не пишется: файл-план стал бы четвёртым артефактом рядом с proposal.md, tasks.md и design.md, пережил бы задачу и разошёлся бы с ней молча. Прервался прогон — повтори шаг 3, это самый дешёвый его проход.

Разметка повторяется ровно в одном случае — если правки изменили сами дельта-спеки: план выведен из них, и план по отменённым требованиям назовёт не те темы. Во всех прочих случаях, включая переделку формы кода на шаге 7, метка остаётся прежней.

4. Ревью дизайна — ДО кода, состав по метке

Вызови Skill av-dev-code:review, дав ссылку на change <id>, план разметки с шага 3 и указание, что это ревью дизайна.

Состав приходит планом, а не решается здесь:

Метка	Проходы на предложении
small	specs
medium	specs, rubric
large	specs, rubric, architecture + вопрос автору о трёх формах решения

review-specs в режиме «дизайн ДО кода» идёт на каждой задаче: это самый дешёвый проход конвейера, и он ловит то, что на готовом коде уже не чинят. Остальные включаются меткой, потому что стадия стоит на каждой задаче и каждый лишний проход здесь умножается на число задач.

Смысл стадии: архитектурная находка на готовом коде стоит переписывания и потому игнорируется — та же находка здесь стоит абзаца обсуждения. Если review-rubric запускался, перенеси его рубрику в tasks.md как приёмочные критерии; там же уже лежат критерии от постановки, если они были.

Отработка замечаний, и она идёт до чекпоинта, а не после:

• мелочь и явные улучшения — правь сам в спеках и дизайне;
• развилки (компромисс, scope, инвариант) — не в запись, а в чекпоинт: он следующим шагом, и это ровно то, ради чего он поставлен здесь;
• после правок перепрогони openspec validate --strict <id>.

5. Чекпоинт: объяснение

Остановись и объясни человеку, что происходит. Второй плановый стоп и единственный обязательный для всех задач.

Он стоит после ревью дизайна намеренно. Человек читает объяснение, уже просеянное машиной: то, что поймал бы review-specs, до него не доходит, а внимание — самый дорогой ресурс процесса, и тратить его на выловимое машиной нельзя.

Объяснение не сочиняется заново — оно собирается из артефактов, proposal.md и design.md. Третий пересказ был бы третьим домом одного и того же и разошёлся бы с обоими. Что показываешь:

• в чём проблема — словами домена из паспорта, без имён модулей и функций;
• как решаем — суть одним абзацем. Не пересказ дельта-спек: спека нормирует, а здесь объясняют;
• что человек увидит иначе, когда это будет сделано;
• чего мы намеренно не делаем и почему — граница scope ловится хуже всего;
• чем рискуем и что осталось нерешённым — сюда съезжаются развилки, накопленные до этого места, и находки ревью с пометкой развилка;
• что дальше, если возражений нет.

Проверка на «простой язык» одна и механическая: в тексте нет SHALL, нет имён файлов и функций там, где вещь называется по-русски, и нет слов, которых нет в паспорте проекта. Не проходит — переписывай, а не объясняй, почему иначе нельзя.

Длина — экран. Длинное объяснение не читают, а пролистывают, и чекпоинт превращается в ритуал одобрения.

Три исхода:

• согласен — идёшь на шаг 6;
• скорректировать — правишь спеки и дизайн по сказанному. Изменились дельта-спеки — повтори шаг 3 (разметка выведена из них) и ту часть ревью дизайна, которой касается правка; затем чекпоинт заново. Правка внутри дизайна без спек — повтори только чекпоинт;
• не одобрено — исход «не доведена» с причиной. Change остаётся незаархивированным, задача не закрывается, ничего не коммитится наполовину.

6. Написать код — opsx:apply

Вызови Skill opsx:apply для реализации tasks.md. Код — по конвенциям проекта (каталог docs/conventions/). Меняешь схему — обнови её описание в документации тем же change, если проект этого требует: гейт обычно это проверяет.

Прогони гейт и добейся зелёного — он же гейт следующего шага.

Поведенческая верификация. Если задача меняет реальное поведение (новый эндпоинт, разбор входа, схема, форма ответа) — зелёных юнит-тестов мало. Подними изменение вживую командой из раздела команд CLAUDE.md и прогони сценарий. Пропусти только для чисто внутренних правок без наблюдаемого рантайма.

Сервис не оставляем лежать. Если запуск упал — почини или откати до конца шага.

7. Ревью кода — та же метка

Вызови Skill av-dev-code:review, дав ссылку на change <id>, базу диффа, план разметки с шага 3 и режим запуска.

Метку ты не выбираешь, и это правило, а не упрощение. Её назвал review-scope ещё на шаге 3 — по размеру и сложности, с обоснованием по каждой оси. Причина в разведённости: ты только что написал этот код, и решать, насколько глубоко его проверять, тебе нельзя — под давлением «я почти закончил» решение известно заранее. Правило выбора живёт в скилле конвейера — av-dev-code:review, references/review-levels.md; проектные триггеры — в docs/review.*, подраздел «Триггеры метки».

Метка не пересматривается по факту диффа. Дифф может выйти крупнее, чем ожидалось при разметке, — это не повод её поднимать: пересмотр означал бы второй запуск разметчика, ровно то, ради устранения чего он и переехал на шаг 3.

Считаешь метку заниженной — скажи это в докладе строкой, а не переспорь. Разметчик вправе и поднять, и понизить; твоё несогласие это факт для человека, а не команда конвейеру. Место, где такое несогласие превращается в изменение правил, — журнал дефектов docs/review.md, и только постфактум.

Плана нет — ревью кода не запускается. Триаж требует план обязательным входом: без него он не может сверить, все ли размеченные темы вернули отчёт, а эта сверка — единственная защита от молчащего пропуска. Потерял план (прервалась сессия, ушёл контекст) — повтори шаг 3, а не гони прогон без него.

Режим по умолчанию — по графу, и обосновывать его не надо. Конвейер сам знает свои рёбра: гейт открывает опиниативные проходы, проходы с пометкой «держит машину» идут цепочкой (иначе замеры портят друг друга и находка выглядит доказанной), триаж — сток. Просить линейно нужно только по причине, и она называется строкой: так сказал оператор; машина занята чем-то ещё; идёт разбор самого конвейера.

Скилл сам гоняет гейт, нужные проходы и обязательный триаж. Возвращает отчёт с потолком 7 пунктов, разметкой Действие: инлайн | развилка и секцией границ покрытия.

Сверь план прогона с исходом, прежде чем коммитить. Отчёт начинается планом разметчика — таблицей «тема → дом → глубина → кто закрывает», — и против каждой темы обязан стоять исход. Тема без отчёта и тема без дома — разные вещи, и обе должны быть названы. Реестр короткий (шесть тем ядра плюс свои) — сверка стоит одного взгляда.

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

Помеченное инлайн чини сам и не логируй. развилка — вопросом в запись (он уже сформулирован триажем, его остаётся перенести). После правок — снова гейт.

Находка, отменяющая одобренный дизайн, отменяет и одобрение. Признак проверяемый: меняются ли дельта-спеки.

• не меняются — находка внутри дизайна, дожимай сам, это обычная отработка;
• меняются — решение стало другим, а одобрено было прежнее. Повтори шаг 3 (разметка выведена из дельта-спек) и вернись на чекпоинт шага 5 с тем, что изменилось и почему.

Это правило старше правила о развилке. Находка класса развилка, чьё основание — «надо менять спеку», подпадает под оба; побеждает возврат на чекпоинт, а вопрос в запись при нём остаётся, но возврата не заменяет. Иначе одобренный дизайн переделывался бы записанным вопросом, то есть молча.

Тихо переделать утверждённое нельзя. Чекпоинт, который можно обойти находкой ревью, не значит ничего, а человек при этом уверен, что одобрил именно то, что уехало в коммит.

Урожай — списком, не задачами. Отложенные находки (реальный major не для этого мерджа, развилка, решённая «потом», пачка nit) собери в секцию доклада Урожай: формулировка, оракул, провенанс. Задачи из него заводит не этот скилл — их заводит av-dev-tasks:tasks своим сценарием «задачи из ревью и аудита»: своя нарезка, свой формат, свои правила дублей. Твоя обязанность — не потерять и передать.

Границы покрытия из отчёта не выбрасывай — они уезжают в финальный доклад сжатой строкой. Отчёт, из которого исчезло «что проверить было невозможно», превращается в ложное ощущение проверенности.

Отчёт триажа сохрани вместе с change (openspec/changes/<id>/review/; шаг 8 унесёт его в архив вместе с change) — это обязательно, а не «если удобно». По нему потом видно, что было найдено и что из этого осталось в урожае. И это единственный независимый артефакт о составе прогона: своей прозе здесь верить нельзя — она написана тем же, кто мог проход и пропустить.

8. Архивировать — opsx:archive

Вызови Skill opsx:archive: change уезжает в архив, дельты вливаются в актуальные спеки. Не пропускай openspec validate --strict перед этим.

9. Синк документации

Вызови Skill av-dev-docs:docs: он владеет содержимым документов канона и ведёт чек-лист синка.

Правило одно и оно жёсткое: принуждённое отрицание. Доклад обязан назвать каждый документ канона — либо чем он обновлён, либо «не требуется, потому что…». Нетронутые группируются одной строкой с общей причиной. Список триггеров прозой уже проверен на живом проекте и дал 6 записей ADR на 43 изменения; работает только обязательное отрицание.

Список документов и их триггеров здесь не дублируется — он в чек-листе скилла av-dev-docs:docs, и копия уже однажды разошлась с оригиналом, потеряв два триггера.

Плагина av-dev-docs в проекте нет — путь в его дерево не разрешится ниоткуда, поэтому за списком иди в свой reference: references/project-facts.md конвейера ревью перечисляет все документы канона с их предметом. Пройди по этому перечню — каждый документ получает строку, отрицание остаётся обязательным.

Двух домов в том перечне нет намеренно, а синку они нужны: docs/adr/ и docs/research/. Проход ревью их не открывает — процессные, — но ADR как раз главный выход синка: решение, принятое по ходу задачи, без этой строки теряется систематически. Добавь их к перечню руками: adr/ — решение с ценой, принятое в этой задаче; research/ — записка разведки, если ветка была исследовательской. Триггеры при этом ты знаешь хуже, и это называется в докладе строкой: «синк сделан по перечню документов, без списка триггеров — плагина av-dev-docs нет». Канона в проекте тоже нет — назови это исходом и предложи av-dev-docs:canon.

10. Коммит

Коммить в текущую ветку (git rev-parse --abbrev-ref HEAD), сам ветку не создавай и не переключай, ничего не пушь.

Сообщение — по-русски, скиллом av-dev-git:commit: форму сообщения держит он, и здесь она не пересказывается. Вызов не разрешился — плагина в проекте нет: напиши сообщение сам и скажи строкой доклада, что форму коммита не сверял никто. Одна задача — один осмысленный коммит.

11. Закрыть задачу — после коммита, не раньше

Вызови Skill av-dev-tasks:tasks и попроси закрыть задачу как реализованную — он владеет форматом и двигает строку индекса сам. Путь к его скрипту не выясняй и индексы руками не правь: мост между плагинами — вызов скилла, а не путь.

Порядок обязателен. Закрытие удаляет файл задачи; сделанное до коммита оно оставило бы задачу закрытой без единого следа работы, если шаг 10 упадёт.

Закрытие тоже коммитится — вторым коммитом, тут же. Удаление файла задачи и правка индексов (их имена знает av-dev-tasks, не ты) — это правки в рабочем дереве, и оставить их незакоммиченными нельзя: закрытие, не доехавшее до основной ветки, оставит задачу открытой молча, а опора «индексы под git показывают, что и когда закрыто» без коммита — пустые слова. Сообщение короткое, про учёт, а не про работу: закрыта задача <slug>. Это второй коммит осознанно: правило «одна задача — один осмысленный коммит» про работу, а учёт — не работа.

Разведка, кончившаяся знанием, закрывается так же — но перед этим убедись, что ответ записан по названному адресу и закоммичен. Закрытая разведка без записанного ответа не оставляет следа вообще: файл задачи удалён, ответ был в переписке.

Плагина в проекте нет — вызов не разрешится. Тогда ничего не выдумывай: скажи в докладе, что учёт задач остаётся за владельцем, и назови исход.

Доклад

Коротко, и в нём обязательно:

• исход одним из четырёх слов и, если не «сделана», чем ограничен результат;
• что сделано, какие вопросы записаны и куда;
• что было одобрено на чекпоинте и совпало ли с тем, что уехало в коммит — расхождение здесь называется прямо, даже если оно мелкое;
• ссылка на архивный change и хеш коммита;
• по каждому критерию приёмки, если они были: оракул и наблюдаемый исход — это доклад приёмщику, а не отметка «принято»;
• Урожай — отложенные находки списком (формулировка, оракул, провенанс);
• одна строка границ покрытия: какая метка и режим гонялись, какие проходы не запускались и что проверить было невозможно. Доклад без неё сообщает «проверено», не сообщая, что именно.

Тонкости

• Не завязывайся на основную ветку и корень репозитория. Скилл работает в текущем worktree и на текущей ветке: не делай git checkout/switch, не создавай веток, не пушь.
• Обычная задача с очевидным решением проходит один чекпоинт, и это норма, а не упрощение. Два чекпоинта — цена незнания, а не признак серьёзности задачи.
• Гейт блокирует: пока он красный, опиниативные проходы не запускаются. Чинить и перезапускать, а не «посмотреть заодно».
• Держи вызывающего в цикле короткими репликами на переходах фаз, но не проси подтверждать механику: чекпоинты — единственные места, где ждут ответа.
• Занизить метку ревью, пропустить тему или проскочить чекпоинт — самый дешёвый способ «ускориться», и он же самый дорогой по последствиям. Защита устроена так, что регулятора у тебя нет: метку выбирает разметчик до того, как ты написал код, план сверяется по темам, непокрытое называется строкой, а расхождение с одобренным — отдельным пунктом доклада.