Thermo-Nuclear Code Quality Review: як працює скіл Cursor
У травні 2026 року в стрічках розробників почав вибухати скріншот з однією командою: /thermo-nuclear-code-quality-review. Люди писали, що вона крутилася по пів години на одному пул-реквесті і вертала правки, які не соромно було б показати сеньйору. Я поставив її собі, прогнав рубрику по власному проєкті і знайшов у ньому три однакові функції, які написав сам протягом трьох місяців та жодного разу не помітив.
Нижче розбір: що це насправді таке, як воно влаштоване всередині, як поставити, що воно знаходить на живому коді і де воно помиляється.
Що це таке
Це скіл із набору Cursor Team Kit, офіційного плагіна від команди Cursor. Його виклали публічно в репозиторії cursor/plugins разом з іншими внутрішніми робочими процесами команди: CI, код-рев'ю, тестування, прибирання коду.
Опис у самому файлі скіла звучить так:
Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth.
Тобто це не лінтер і не аналізатор. Це промпт. Дуже довгий, дуже конкретний промпт, який перетворює модель на прискіпливого рев'ювера з чіткою рубрикою і високою планкою.
Цікава деталь про походження. Одна з інженерок Cursor написала, що вони вагалися, чи публікувати цей скіл узагалі, бо «секретний соус тут у тому, що всередині дистильований цифровий двійник» їхнього колеги Лукаса Меллера. Простими словами: вони взяли манеру рев'ю конкретної людини, у якої найвища планка в команді, і зашили її в текст.
Головна ідея: code judo
Якщо викинути всі деталі, у скіла одна центральна вимога, і вона незвична для автоматичних рев'ю. Він шукає не помилки. Він шукає можливість переписати так, щоб складність зникла зовсім.
У тексті скіла це названо «code judo move»:
Assume there is often a "code judo" move available: a re-organization that uses the existing architecture more effectively and makes the change dramatically simpler and more elegant. If you see a path to delete complexity rather than rearrange it, push hard for that path.
Різниця принципова. Звичайне рев'ю каже «тут можна винести в змінну». Це каже «а навіщо тут узагалі ця гілка, давай перепишемо модель даних так, щоб її не існувало». Формулювання з тексту, яке мені сподобалось найбільше: перевага віддається рішенню, від якого код «здається неминучим заднім числом».
Базовий промпт
Вся рубрика будується поверх п'яти рядків, які скіл називає базовим промптом:
Perform a deep code quality audit of the current branch's changes.
Rethink how to structure / implement the changes to meaningfully improve code quality without impacting behavior.
Work to improve abstractions, modularity, reduce Spaghetti code, improve succinctness and legibility.
Be ambitious, if there is a clear path to improving the implementation that involves restructuring some of the codebase, go for it.
Be extremely thorough and rigorous. Measure twice, cut once.
Далі йдуть вісім правил, які автори називають «не обговорюваними».
Вісім правил і що вони означають на практиці
| Правило | Що це означає в реальному коді |
|---|---|
| 0. Амбіційність у спрощенні | Не зупинятися на «тут трохи чистіше». Шукати переписування, після якого цілі гілки, хелпери, режими й шари зникають повністю. |
| 1. Поріг у 1000 рядків | Пул-реквест не має права проштовхнути файл з-під тисячі рядків за тисячу без вагомої причини. Якщо перетинає, спершу питання: а розібрати цей файл не час? |
| 2. Ніякого спагеті | Нові умови, які встромили в чужий потік виконання, вважаються проблемою дизайну, а не стилю. Дослівно: «weird if statements in random places». |
| 3. Чистий дизайн важливіший за робочий код | «Воно працює» не є підставою схвалити. Якщо поведінку можна зберегти, а структуру зробити суттєво чистішою, треба робити чистіше. |
| 4. Прямо й нудно замість магії | Тонкі обгортки, наскрізні хелпери та узагальнені механізми, що ховають прості припущення про дані, позначаються як проблема. |
| 5. Чистота типів і меж | Зайва опціональність, any, unknown, рясні касти. Якщо гілка тримається на мовчазному фолбеку, який замазує незрозумілий інваріант, межу треба зробити явною. |
| 6. Логіка у своєму шарі | Фічева логіка не тече в загальні модулі, а замість власного хелпера береться канонічний, який уже є в кодовій базі. |
| 7. Оркестрація й атомарність | Незалежна робота, зашита послідовно без причини, і оновлення, які лишають стан наполовину застосованим, вважаються запахом дизайну. |
Тон, який задає скіл
Окремий розділ у файлі присвячений тому, як саме формулювати зауваження. Там прямо написані готові фрази, і вони дуже впізнавані для тих, хто працював із вимогливими рев'юерами:
this pushes the file past 1k lines. can we decompose this first?this adds another special-case branch into an already busy flow. can we move this behind its own abstraction?this refactor moves complexity around, but doesn't really delete it. is there a way to make the model itself simpler?i think there's a code-judo move here that makes this much simpler.
Інструкція щодо тону: бути прямим, серйозним і вимогливим, але не грубим. І окремо: не пом'якшувати серйозні проблеми до м'яких побажань.
Як поставити
Є три шляхи, залежно від того, чим ви користуєтесь.
У Cursor через маркетплейс. Плагіни з'явилися в Cursor 2.5 у лютому 2026 року. Відкриваєте маркетплейс, знаходите Cursor Team Kit, ставите в один клік. Скіл приїде разом з рештою набору.
У Cursor через команду. Просто наберіть /add-plugin прямо в редакторі і вкажіть cursor-team-kit. Ніяких конфігів руками правити не треба.
У Claude Code або будь-де ще. Скіл це звичайний markdown-файл. Візьміть SKILL.md з репозиторію cursor/plugins і покладіть у .claude/skills/thermo-nuclear-code-quality-review/SKILL.md у своєму проєкті. Працює так само, бо всередині немає нічого специфічного для Cursor, тільки текст рубрики.
Одна деталь, яку варто знати заздалегідь. У шапці файла стоїть disable-model-invocation: true. Це означає, що модель не запустить скіл сама, коли їй здасться доречним. Тільки ви, тільки вручну. Зроблено свідомо: рев'ю такої жорсткості не має вмикатися саме по собі посеред роботи.
Що рубрика знайшла в моєму проєкті
Тут найцікавіше. Я взяв критерії скіла і прогнав їх по своєму робочому проєкту: парсер Telegram-каналів з перекладом через LLM і публікацією на сайт та в соцмережі. Проєкт живий, писався останні місяці, 46 файлів TypeScript і TSX, 7319 рядків разом.
Правило про тисячу рядків: поки що чисто, але видно, куди все йде
Формально жоден файл поріг не перетнув. Але routes.ts на 736 рядках це вже три чверті дистанції, і саме туди за звичкою дописується кожен новий ендпоінт. Скіл тут спрацював би як рання сигналізація: наступний великий пул-реквест у цей файл він би завернув з питанням про декомпозицію. І був би правий, бо там уже лежать вперемішку роути постів, каналів, налаштувань, медіа й авторизації.
Правило про чистоту типів: 91 знахідка
Пошук по кодовій базі дав 23 приведення as any і 68 анотацій : any. Частина з них вимушена: бібліотека GramJS для Telegram має неповні типи, і без каста туди не достукатися. Але частина це чиста лінь, у тому числі моя.
Ще знайшлося чотири порожні блоки catch, які мовчки ковтають помилку. Скіл трактує саме такі мовчазні фолбеки як замазування незрозумілого інваріанту, і тут з ним важко сперечатися: коли щось ламається, у логах порожньо.
Найболючіше: три однакові функції
А ось знахідка, заради якої варто було все затівати. Правило про канонічні хелпери вивело на це:
| Файл | Рядок | Назва |
|---|---|---|
src/bot/publisher.ts | 24 | stripHtmlTags() |
src/bot/vaibecod.ts | 32 | stripHtml() |
src/bot/linkedin.ts | 111 | htmlToLinkedInText() |
Три функції в трьох сусідніх файлах однієї папки. Усі три роблять одне й те саме: replace(/<[^>]+>/g, "") і далі розкодовують ті самі HTML-сутності. Різні назви, майже ідентичне тіло.
Найгірше, що писав їх я сам, з інтервалом у кілька тижнів. Кожного разу треба було «швиденько прибрати теги», кожного разу здавалося простіше написати три рядки, ніж піти шукати, чи є вже готове. Жодне звичайне рев'ю це не спіймало б, бо кожен пул-реквест окремо виглядав нормально. Проблема видно тільки тоді, коли дивишся на всі три разом.
Ось саме це в термінології скіла і є пропущений code judo move. Правильна відповідь тут не «зробити функції однаковими», а винести одну в спільний модуль і викинути дві.
Де скіл помиляється
Тепер чесна частина, бо в захваті легко проґавити обмеження.
Тисяча рядків це довільне число. Автори самі це визнають формулюванням «за замовчуванням». Файл на 1200 рядків з чіткою структурою буває легшим для читання, ніж чотири файли по 300, розмазані по трьох папках. Скіл цього нюансу не бачить, він бачить лічильник.
Це промпт, а не аналізатор. Він не запускає тести, не перевіряє, що після запропонованого переписування поведінка збереглася, і не гарантує відтворюваності: два прогони на тому самому коді дадуть різні набори зауважень. Перевіряти правки все одно вам.
Він підштовхує до надмірного рефакторингу. Скіл прямо запрограмований бути амбіційним і не задовольнятися дрібницями. На зрілому проєкті це добре. На прототипі, який ви за тиждень викинете, це втрачений тиждень. Планка «код має здаватися неминучим» коштує часу.
Він нічого не знає про ваш контекст. Каст, який виглядає як лінь, може бути єдиним способом обійти чужу бібліотеку. Скіл про це не здогадається і напише зауваження. Половина відповідей на його претензії звучить як «так, я знаю, і ось чому».
З чим порівнювати
| Інструмент | Що ловить | Чого не вміє |
|---|---|---|
| Лінтер (ESLint і подібні) | Формальні порушення правил, миттєво й відтворювано | Не бачить архітектури: 500 рядків спагеті пройдуть без єдиної скарги |
| Звичайне AI-рев'ю | Баги, друкарські помилки, дрібні покращення | Схильне хвалити й погоджуватись, майже ніколи не каже «перепиши це інакше» |
/simplify у Claude Code |
Локальні спрощення в межах зміненого коду | Не ставить під сумнів структуру навколо |
| Thermo-nuclear | Структурні регресії, роздуті файли, дублікати хелперів, витік логіки між шарами | Не запускає тести, не відтворюваний, довгий, часто надто амбіційний |
Вірусний допис, з якого все почалося, стверджував, що скіл «у 67 разів кращий за /simplify». Цифра, звісно, взята зі стелі. Але напрямок правильний: це інструменти різного класу. Один прибирає в кімнаті, другий питає, чи правильно поставлені стіни.
Кому це варто ставити
Однозначно варто, якщо ви працюєте сам або в маленькій команді, де вас нікому по-справжньому рев'ювити. Скіл заміняє того самого прискіпливого колегу, якого у вас немає. Саме в цьому сценарії він показав себе на моєму проєкті: знайшов те, що я системно не бачив три місяці поспіль.
Варто, якщо ви багато генеруєте коду через AI. Згенерований код стабільно виглядає робочим і стабільно нарощує кількість сутностей, які треба тримати в голові. Це рівно та проблема, під яку скіл заточений.
Не варто на прототипах і одноразових скриптах. І не варто вмикати на кожен коміт: тридцять хвилин рев'ю заради виправлення одного рядка це не дисципліна, а ритуал.
Мій режим після тижня використання: раз на кілька днів на накопичену гілку перед злиттям. Не на кожну зміну, але й не раз на квартал, коли розгрібати вже пізно.