skills-ecc: двадцать навыков для агента, которого надо чинить, мерить и выкатывать

Кирилл открыл README пакета и первым делом спросил то же, что спросил бы ты: «двадцать навыков — это что, двадцать команд, которые мне придётся выучить?»

Нет. Навык — это файл SKILL.md с методикой, который твой агент подгружает сам, когда твоя задача совпадает с его триггерными фразами. Это и есть автоактивация: ты пишешь ассистенту «проверь архитектуру моего агента» — и он включает agent-architecture-audit, потому что в шапке этого файла записано, на какие формулировки он откликается. Кирилл не набирал ни одной команды: он описал задачу словами, и навык пришёл сам.

Что лежит в пакете @dzhechkov/skills-ecc (исходники — в репозитории dz-harness):

• 20 навыков, привезённых из проекта ECC (лицензия MIT) командой dz import-ecc;
• у каждого в шапке стоит trust_tier: 0 — «Community (imported from ECC)»: пакет честно помечает, что это привозной материал, а не написанный автором харнеса;
• темы — агентные приложения, автономные петли, тестирование и DevOps: от аудита агента до Docker и git.

Ставится одной командой: dz install @dzhechkov/skills-ecc. Нужны только два навыка — dz init --target claude-code --select docker-patterns,autonomous-loops. Хочешь увидеть точные триггеры навыка — dz info <skill-id>; найти навык по слову — dz registry search <term>.

Компромисс: автоактивация избавляет от заучивания, но триггеры — это текст в шапке файла: если твоя формулировка не совпала с фразами автора навыка, навык промолчит. Тогда Кирилл просто называет навык по имени — и это нормальный, а не аварийный путь.

💬 Просто попроси. Весь курс построен так: ты будешь видеть, ЧТО делает каждый навык, чтобы понимать, что происходит под капотом. Но включать их можно словами — «сравни двух агентов на моей задаче», «посмотри, почему тест плавает».

«Модель стала тупее», — сказал Кирилл в понедельник. К среде выяснилось, что модель ни при чём.

Навык agent-architecture-audit начинается с неудобной мысли: в приложении на LLM ответ проходит через двенадцатислойный стек, и испортить его может любой слой — а винить принято только модель. Один из явных сигналов для аудита прямо в навыке: ты отлаживаешь поведение агента больше 15 минут и не нашёл причину. Кирилл отлаживал три дня.

Вот эти двенадцать слоёв — от входа к выходу:

1. системный промпт — противоречивые инструкции, раздувание;
2. история сессии — устаревший контекст из прошлых ходов;
3. долговременная память — загрязнение между сессиями;
4. дистилляция — сжатые пересказы возвращаются как «факты»;
5. активный пересказ — лишние слои повторного суммирования;
6. выбор инструмента — не тот маршрут, пропущен обязательный вызов;
7. выполнение инструмента — «сказал, что вызвал», а не вызвал;
8. чтение результата инструмента — вывод прочитан не так или проигнорирован;
9. форма ответа — сломанный формат на выходе;
10. отрисовка платформой — UI, API или CLI сами меняют верный ответ;
11. скрытые петли починки — молчаливый второй проход LLM;
12. персистентность — просроченное состояние считается живым.

Навык сводит это к пяти повторяющимся картинам отказа: регрессия обёртки (в песочнице модель отвечает верно, в твоём приложении — нет), загрязнение памяти, провал дисциплины инструментов («обязан вызвать X» написано в промпте, но кодом не проверяется), порча при отрисовке и скрытые слои агентов. У Кирилла оказалась третья: правило «сначала запроси базу знаний» жило только в тексте промпта, и после обновления модель стала его пропускать.

Аудит идёт четырьмя фазами — рамка, сбор улик (код, логи, конфиги, файлы памяти), карта отказов (симптом → механизм → слой → корень → улика file:line → уверенность), стратегия починки. И порядок починки задан жёстко: сначала код, потом промпт — обязательность инструмента закрепляют в коде, скрытые починочные агенты убирают или делают явными, дубли контекста режут.

Компромисс: аудит по двенадцати слоям дорог — надо читать код, логи и память, а не переписать промпт за пять минут. Зато он запрещает самую частую ошибку: винить модель, не опровергнув регрессию обёртки.

Починив обёртку, Кирилл захотел проверить, не пора ли сменить сам агент для кодинга. В чате команды за минуту появились три мнения. Навык agent-eval называет это честно: каждое сравнение «какой агент лучше» обычно идёт на ощущениях — а должно идти на измерении.

Что делает сравнение воспроизводимым, а не спором:

1. Задача описана в YAML — имя, репозиторий, файлы, промпт, судья и commit, закреплённый на конкретном коммите, чтобы результаты сходились через дни и недели.
2. Каждый прогон живёт в своём git worktree — без Docker; агенты не мешают друг другу и не портят базовый репозиторий.
3. Метрики фиксированы: доля прохождения, стоимость, время и постоянство — доля прохождения при повторах (3/3 = 100%).
4. Судьи трёх типов: детерминированные (pytest, команда сборки), по шаблону (grep), и модельные (LLM-судья). Навык требует хотя бы одного детерминированного на задачу — модельный судья добавляет шум.

Кирилл собрал команду agent-eval run --task tasks/add-retry-logic.yaml --agent claude-code --agent aider --runs 3, а потом agent-eval report --format table — и получил таблицу: у одного агента 3/3, у другого 2/3 и дешевле. Спор кончился.

Рядом лежит навык-близнец — benchmark-optimization-loop. Он про то же измерение, но для «сделай в 20 раз быстрее»: до оптимизации должны существовать операция, гейт корректности, метрика, базовый уровень и бюджет поиска. Дальше петля: замерить базу → найти узкое место по уликам → варианты по одной гипотезе каждый → одинаковые входы → отбросить неверные → продвинуть лучший безопасный вариант → закрепить в скрипте или тесте → перепрогнать базу и победителя, чтобы подтвердить разницу. И слова тоже измеряются: «лучший измеренный безопасный вариант», а не «глобальный оптимум», если пространство не перебрано целиком.

Компромисс: воспроизводимое сравнение стоит времени — три прогона на 3–5 задач против одного «попробовал, вроде норм». Зато решение переживает смену модели у поставщика: перепрогнал — увидел регрессию.

Кирилл готов отдать агентам большую часть кода. Навык agentic-engineering описывает, как при этом не потерять контроль: агент делает основную реализацию, а человек держит качество и риск — через четыре принципа.

Общая картина — четыре принципа:

1. определить критерий завершения ДО выполнения;
2. разбить работу на единицы «под агента»;
3. маршрутизировать уровень модели по сложности задачи;
4. мерить evals и регрессионными проверками.

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

1. определить capability-eval (что должно появиться) и regression-eval (что не должно сломаться);
2. прогнать базовый уровень и записать сигнатуры отказов;
3. выполнить реализацию;
4. перепрогнать evals и сравнить дельты.

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

Маршрутизация моделей в навыке простая: Haiku — классификация, шаблонные преобразования, узкие правки; Sonnet — реализация и рефакторинг; Opus — архитектура, поиск корня, инварианты на много файлов. Поднимать уровень — только когда нижний провалился с явным разрывом в рассуждении. И учёт на каждую задачу: модель, оценка токенов, повторы, время, исход.

Компромисс: петля eval-first требует написать проверки раньше кода — это медленный старт. Зато «готово» перестаёт быть мнением: дельта между базой и результатом либо есть, либо нет.

Кирилл хочет, чтобы агент работал ночью без него. Первая мысль — «запущу в цикле, пусть крутится». Навык autonomous-loops отвечает: сначала выбери ФОРМУ петли, потому что петли автономии образуют спектр от простого к сложному, и форма выбирается под задачу, а не под амбицию.

Шесть форм, от простой к сложной:

1. Последовательный конвейер (claude -p) — цепочка неинтерактивных вызовов: реализовать → очистить → проверить → закоммитить; у каждого шага свежий контекст; set -e останавливает цепочку при отказе.
2. NanoClaw REPL — сессия с историей в markdown-файле, для интерактивной работы.
3. Бесконечная агентная петля — много вариаций одного по спецификации.
4. Continuous Claude PR-петля — многодневная итеративная работа с гейтами CI; ограничивается --max-runs, --max-cost, --max-duration или сигналом завершения.
5. De-Sloppify — надстройка: проход очистки после каждого шага реализации (о нём вся следующая секция).
6. Ralphinho / DAG по RFC — большие фичи, параллельные единицы, очередь слияния с выселением при конфликте.

Матрица выбора из навыка умещается в три вопроса: задача — одно сфокусированное изменение? → конвейер или REPL. Есть письменная спецификация и нужна параллельность? → Ralphinho; спецификация есть, параллельность не нужна → Continuous Claude. Нужно много вариаций одного? → бесконечная петля; иначе — конвейер с очисткой.

Навык continuous-agent-loop — парадная дверь к тому же: он выбирает форму (последовательная / параллельный веер / с гейтом на PR) и составляет её из навыков харнеса, не переизобретая гейты. В шапке autonomous-loops честно записано: каноническое имя теперь continuous-agent-loop, старое оставлено на один выпуск ради совместимости.

Три ошибки, которые навык называет прямо: бесконечная петля без условия выхода (всегда --max-runs, --max-cost, --max-duration или сигнал); нет моста контекста между итерациями (каждый claude -p начинает с нуля — нужен SHARED_TASK_NOTES.md или состояние на диске); повтор той же ошибки — при отказе не перезапускать вслепую, а захватить контекст ошибки и отдать следующей попытке.

Компромисс: чем выше по спектру, тем больше можно сделать без человека — и тем дороже отказ: очередь слияния и параллельные worktree требуют стратегии конфликтов. Простая форма с явным лимитом часто выигрывает у сложной без него.

Кирилл попросил агента «реализуй с TDD» — и получил тесты на то, что typeof x === 'string' работает, защитные проверки того, что уже гарантирует система типов, и обработку ошибок для невозможных состояний. Естественная реакция — дописать в промпт: «не тестируй систему типов». Кирилл так и сделал. Стало хуже.

Вот неожиданность, ради которой существует паттерн De-Sloppify: отрицательная инструкция в промпте реализатора бьёт не по слоппу, а по всему тестированию. Навык перечисляет последствия: модель начинает осторожничать со ВСЕМИ тестами, пропускает законные краевые случаи, качество проседает непредсказуемо.

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

1. реализовать — «будь тщательным с тестами», без запретов;
2. отдельным вызовом claude -p — «просмотри изменения, убери тесты на поведение языка и фреймворка, избыточные проверки типов, защиту от невозможных состояний, console.log, закомментированный код; бизнес-тесты оставь; прогони набор тестов».

Ключевая мысль навыка: два сфокусированных агента работают лучше одного ограниченного. Отсюда же общий анти-паттерн из списка: «не говори „не делай X“ — добавь отдельный проход, который убирает X». В цикле это выглядит так: реализовать → очистить → проверить (сборка, линт, тесты) → закоммитить — и так для каждой фичи.

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

Остановись на секунду и вспомни, когда ты последний раз просил ту же модель проверить код, который она только что написала. Кирилл делал так каждый день — пока не увидел историю из навыка ai-regression-testing.

Когда одна модель пишет код и сама его проверяет, она несёт одни и те же допущения в оба шага — это слепое пятно самопроверки. Схема отказа предсказуема: модель пишет починку → модель проверяет починку → «выглядит верно» → ошибка на месте.

Навык приводит наблюдавшийся в продакшене случай с одной и той же ошибкой:

1. добавили поле notification_settings в ответ API — забыли добавить в SELECT; модель проверила и не заметила;
2. добавили в SELECT — упала сборка TypeScript: колонки нет в сгенерированных типах;
3. заменили на SELECT * — починили продакшен-путь, забыли песочницу; модель снова пропустила — четвёртый раз одна и та же ошибка;
4. тест поймал её с первого прогона.

Отсюда правило навыка: пиши тесты для найденных ошибок, а не для кода, который работает. И вторая находка: главная регрессия, которую вносит ИИ, — расхождение путей «песочница / продакшен»: починили один путь, забыли другой.

Чтобы тесты были быстрыми, навык использует режим песочницы без базы данных: в setup.ts выставляется SANDBOX_MODE = "true", ключи базы пустые, а помощник createTestRequest собирает запрос к API-маршруту Next.js напрямую. Регрессионный тест тогда проверяет контракт — список обязательных полей ответа, включая то самое notification_settings, — и отдельно паритет песочницы и продакшена.

Кирилл теперь спрашивает себя после каждой правки: «кто проверил — та же модель или тест?» Если та же модель — проверки не было.

Компромисс: тест на каждую найденную ошибку — это медленнее, чем «модель посмотрела, всё ок». Зато он ловит четвёртое повторение с первого прогона, а модель не поймала ни одного.

Агент Кирилла обращается к внутреннему API, и это API написан в спешке: вся логика внутри обработчиков маршрутов. Два навыка пакета — backend-patterns (Node.js, Express, Next.js) и fastapi-patterns (Python) — описывают одну и ту же структуру на разных языках.

Главная идея: слой сервиса живёт отдельно от маршрута, а доступ к данным — за репозиторием. Маршрут тонкий: принять запрос, проверить схему, вызвать сервис, отдать ответ. Сервис — бизнес-логика и транзакции. Репозиторий — абстракция над хранилищем с методами findAll, findById, create, update, delete.

Что ещё оба навыка называют:

• ресурсные URL — GET /api/markets, GET /api/markets/:id, фильтры и пагинация через параметры запроса;
• промежуточный слой (middleware) — авторизация, логирование, ограничение частоты как цепочка обработки запроса до маршрута;
• предотвращение N+1 — не запрашивать создателя для каждой записи в цикле, а собрать id и сделать один пакетный запрос;
• транзакция — несколько вставок в одной функции базы, откат при ошибке;
• выбирать только нужные колонки, а не SELECT *.

FastAPI-навык добавляет свои конкретные артефакты: фабрика приложения с lifespan, настройки через pydantic-settings из .env, схемы Pydantic v2 с валидатором совпадения паролей, внедрение зависимостей (get_db, get_current_user), и жёсткий анти-паттерн: синхронный вызов базы в асинхронном маршруте блокирует цикл событий — используй асинхронное выполнение SQLAlchemy.

Кирилл переложил логику из обработчиков в сервис — и впервые смог протестировать её без HTTP вообще.

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

У команды поддержки есть старый Django-сервис, и Кирилл хочет дать агенту его дорабатывать. Навык django-tdd задаёт ритм, в котором агент не убежит вперёд тестов.

Цикл красный-зелёный-рефакторинг — ядро навыка:

1. красный — написать падающий тест (например, test_user_creation: пользователь создан, пароль проверяется, is_staff выключен);
2. зелёный — сделать минимум, чтобы тест прошёл;
3. рефакторинг — улучшить, не выходя из зелёного.

Чтобы цикл крутился быстро, навык даёт конкретную настройку pytest.ini: --reuse-db (не пересоздавать базу на каждый прогон), --nomigrations (не гонять миграции), --cov=apps с отчётом покрытия и --strict-markers. Тестовые настройки — SQLite в памяти, отключённые миграции через класс DisableMigrations, быстрый хешер паролей MD5 только для тестов, консольный почтовый бэкенд, Celery в режиме немедленного выполнения.

Второй артефакт — фабрики factory_boy вместо ручных фикстур: UserFactory с Sequence для уникальных email, Faker для имён, SubFactory для связей (ProductFactory сам создаёт категорию и автора), LazyAttribute для производных полей, fuzzy для чисел в диапазоне. В conftest.py — фикстуры user, admin_user, authenticated_client, api_client для Django REST Framework.

Кирилл собрал команду pytest --reuse-db --nomigrations --cov=apps — прогон стал занимать секунды, и красный тест перестал быть наказанием.

Компромисс: быстрые тестовые настройки отличаются от продакшена (SQLite вместо Postgres, MD5 вместо настоящего хеша) — некоторые ошибки они не поймают. Зато цикл крутится десятки раз в час, а не два раза в день.

Пора упаковать агента Кирилла в контейнер. Навык docker-patterns начинает с вопроса, на который ты сейчас ответишь сам: сколько стадий должно быть в Dockerfile, чтобы разработчик получил горячую перезагрузку, а продакшен — минимальный образ без инструментов разработки? Одна? Две? Запомни ответ.

Ответ навыка — многоступенчатая сборка образа из четырёх стадий:

1. deps — npm ci по lock-файлу;
2. dev — зависимости из deps, исходники, npm run dev с горячей перезагрузкой;
3. build — npm run build && npm prune --production;
4. production — отдельный пользователь appuser, только dist и продакшен-зависимости, HEALTHCHECK, node dist/server.js.

Compose для локальной разработки берёт target: dev, а docker-compose.prod.yml — target: production с лимитами ресурсов. Сервисы в одной сети находят друг друга по имени: postgres://…@db:5432, redis://redis:6379; depends_on с condition: service_healthy ждёт, пока база ответит на pg_isready.

Три типа томов, которые навык просит различать: именованный (pgdata — переживает перезапуск), привязанный (.:/app — исходники для горячей перезагрузки) и анонимный (/app/node_modules — защищает зависимости контейнера от перекрытия хостом).

Безопасность — короткий список, который Кирилл повесил над столом:

• конкретные теги, никогда :latest;
• запуск не от root;
• cap_drop: ALL, read_only: true, no-new-privileges;
• секретов в слоях образа нет — только переменные окружения из .env (в git не попадает) или Docker secrets; ENV API_KEY=sk-… в Dockerfile — прямой анти-паттерн.

Сверь свой ответ: если ты сказал «две», ты потерял либо горячую перезагрузку, либо минимальный образ; четыре стадии дают оба.

Компромисс: четыре стадии — длиннее Dockerfile и дольше первая сборка. Зато продакшен-образ не содержит ни инструментов разработки, ни исходников, ни секретов.

Тест поиска у Кирилла проходит на ноутбуке и падает в CI через раз. Вопрос без простого ответа, с которого начинается навык e2e-testing: это тест плохой или код плохой? Кирилл три дня чинил код — а виноват был тест. Ответ навыка — сначала докажи, что тест плавающий, потом ищи причину.

Плавающий тест — тест, исход которого зависит не от кода, а от времени: гонки, сеть, анимации. Навык даёт три инструмента:

1. доказать плавание — npx playwright test tests/search.spec.ts --repeat-each=10: если из десяти прогонов падают два, это плавание, а не регрессия;
2. карантин — test.fixme(true, 'Flaky - Issue #123') или test.skip в CI с номером задачи, чтобы падение не блокировало остальных, но и не забылось;
3. три типовые причины и починки: гонка — не page.click(...), а локатор с автоожиданием page.locator(...).click(); сеть — не waitForTimeout(5000), а waitForResponse по конкретному запросу; анимация — дождаться state: 'visible' и networkidle перед кликом.

Вокруг — структура набора: Page Object Model (класс страницы с локаторами по data-testid и методами goto, search), конфигурация с retries: 2 только в CI, trace: 'on-first-retry', скриншот только при падении, четыре проекта браузеров; артефакты — скриншоты, трассы, видео.

Навык browser-qa берёт ту же автоматизацию браузера и превращает её в проверку после выкатки в четыре фазы: дымовая (ошибки консоли, нет 4xx/5xx, Core Web Vitals: LCP < 2,5 с, CLS < 0,1, INP < 200 мс), взаимодействие (все ссылки навигации, формы с верными и неверными данными, вход → защищённая страница → выход), визуальная регрессия (три ширины: 375, 768, 1440; сдвиги больше 5 px), доступность (axe-core, нарушения WCAG AA, клавиатурная навигация). Итог — отчёт с вердиктом вроде «SHIP WITH FIXES (2 issues, 0 blockers)».

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

Через полгода новый разработчик спросит Кирилла: «почему у агента память в JSON-файле, а не в базе?» Кирилл вспомнит спор в чате, но не аргументы. Два навыка пакета существуют ради этого вопроса — и то, что часто считают примечанием на полях, здесь ядро материала.

Навык architecture-decision-records: запись решения живёт рядом с кодом, в docs/adr/NNNN-название.md, по лёгкому формату Найгарда:

• Контекст — какая проблема и какие силы действуют (2–5 предложений);
• Решение — что делаем (1–3 предложения);
• Рассмотренные альтернативы — у каждой плюсы, минусы и «почему нет»;
• Последствия — что стало проще, что сложнее, риски.

Навык сам замечает момент решения по сигналам вроде «давай возьмём X», «мы решили…», «компромисс того стоит, потому что…» — но никогда не создаёт файлы без явного согласия: сначала показывает черновик, пишет только после одобрения, ведёт индекс в docs/adr/README.md. Что делает ADR хорошим: конкретика («взять Prisma», а не «взять ORM»), записанное „почему“ важнее „что“, честные последствия, краткость.

Навык git-workflow закрывает второй след — историю коммитов. Формат Conventional Commits: <тип>(<область>): <тема>, где тип — feat, fix, docs, refactor, test, chore, perf, ci, revert; тело объясняет «почему», а не «что». Три стратегии веток с таблицей выбора: GitHub Flow для непрерывной выкатки, trunk-based для команд с сильным CI и флагами фич, GitFlow для релизов по расписанию. И правило, которое Кирилл однажды нарушил: никогда не делай rebase ветки, которую уже отправили в общий репозиторий или на которую опираются другие — rebase переписывает историю и ломает чужую работу; для общих веток — revert.

Компромисс: ADR и осмысленные коммиты — это минуты на каждое решение, которые кажутся лишними в моменте. Зато «почему» переживает и чат, и память автора.

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

canary-watch — наблюдение после выкатки. Он следит за развёрнутым адресом по восьми проверкам: статус HTTP, новые ошибки консоли, отказы сети, регрессия производительности относительно базы (LCP/CLS/INP), исчезновение ключевых элементов (h1, навигация, кнопка действия), здоровье критичных API в пределах SLA, статические ресурсы с ожидаемыми типами содержимого, SSE-потоки с первым событием или сердцебиением. Три режима:

1. быстрая проверка — один проход: /canary-watch https://myapp.com;
2. длительное наблюдение — --interval 5m --duration 2h на окно запуска;
3. сравнение — --compare https://staging… https://prod….

Пороги разложены по уровням: критично (статус не 200, больше 5 новых ошибок консоли, LCP > 4 с, 5xx от API, отвалившийся SSE), предупреждение (LCP вырос больше чем на 500 мс, CLS > 0,1, время ответа вдвое выше базы), информация (мелкий разброс, новые сторонние запросы). Критичный порог — уведомление на рабочий стол, по желанию Slack/Discord, лог в ~/.claude/canary-watch.log. Навык советует ставить его хуком на git push и парой к browser-qa до выкатки.

enterprise-agent-ops — что делать, когда наблюдение показало всплеск. Четыре домена: жизненный цикл (старт, пауза, стоп, рестарт), наблюдаемость (логи, метрики, трассы), предохранители (области, права, кнопки «стоп»), управление изменениями (раскатка, откат, аудит). Базовые контроли: неизменяемые артефакты, минимальные права, секреты через окружение, жёсткие бюджеты таймаутов и повторов, аудит опасных действий. Метрики — не только доля успеха, но и среднее число повторов, время восстановления, стоимость успешной задачи и распределение классов отказов.

Паттерн инцидента, шесть шагов и первый — не «чинить»: заморозить новую раскатку → собрать представительные трассы → изолировать падающий маршрут → починить наименьшим безопасным изменением → прогнать регрессию и проверки безопасности → возобновлять постепенно.

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