Pokayoke: как защитить репозиторий от ошибок и при этом понравиться AI-агентам

Японский инженер Сигео Синго придумал слово pokayoke ещё в 1960-х. Задача была простая: сделать так, чтобы ошибки невозможно было совершить — или хотя бы сразу заметить.

Принцип понятный. Вместо того чтобы надеяться на человеческую аккуратность, система сама ловит отклонения. Вилка, которую не получится вставить неправильно. Датчик, который останавливает конвейер при малейшем сбое. На заводе так не допускают брака до покупателя. В разработке — не допускают хаоса до продакшена.

Pokayoke.codes переносит эту философию в ваш репозиторий. Инструмент заточен под эпоху, где код пишут не только люди, но и AI-помощники.

Не только линтеры: политики как документация

Линтеры есть почти у всех. ESLint ругается на неиспользуемые переменные. Prettier выравнивает форматирование. TypeScript ловит ошибки типов. С инструментами всё хорошо, но они не передают негласные знания команды.

Может, ваши API-эндпоинты следуют определённому паттерну именования. Или в проекте есть правила о том, какие пакеты можно использовать в конкретных контекстах. Возможно, кто-то когда-то договорился о структуре файлов, но это нигде не зафиксировано.

Вот этот пробел pokayoke и закрывает. Инструмент превращает репозиторийные инварианты в код, который можно проверять автоматически.

Создан для агентов

Главная фишка — pokayoke изначально ориентирован на AI-агентов.

Современные ассистенты умеют читать код, писать фичи, рефакторить. Но удержать их в рамках ваших conventions — до сих пор ручная работа. Можно добавить правила в системный промпт, но агенты забывают, галлюцинируют или просто не знают, что для вас важно.

Pokayoke решает это, делая политики полноценными участниками рабочего процесса. Команда pokayoke agent SKILL.md запускает агента с нужными настройками, а правила написаны так, чтобы их понимал и поддерживал AI — а не только люди.

Если вы строите Vibe Coding workflow, где AI делает основную работу — pokayoke даёт способ донести стандарты так, чтобы они реально соблюдались.

Встраивается в ваш стек

Новое tooling часто создаёт хаос. У вас уже есть ESLint, Prettier, Husky и целый зоопарк утилит. Pokayoke ничего не заменяет — он дополняет ваш пайплайн.

Документация подчёркивает: pokayoke не пытается быть умным во всём. Форматирование? Это Prettier. Общее качество кода? Это ESLint. Задача pokayoke — проверять проектно-специфичные инварианты, которые известны только вашей команде.

TypeScript-правила живут локально в репозитории и проверяют то, что важно для конкретного проекта. Своего рода кастомный слой валидации поверх стандартного набора инструментов.

Как попробовать

Установка элементарная:

npx skills add rorz/pokayoke

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

Зачем это всё

Pokayoke отражает важный сдвиг в мышлении о code quality tooling. Классические линтеры следят за синтаксисом и стилем. Статические анализаторы ловят баги. Но когда AI-ассистенты становятся основными соавторами кода, нужны инструменты нового типа — те, которые доносят намерения в формате, понятном агентам.

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

В этом смысле pokayoke — один из первых инструментов, purpose-built под то, как мы все будем работать через несколько лет. Однозначно стоит попробовать.