old-coder — скилл
Скилл разработки под доказательства: агент окружает код спецификацией и набором проверок, чтобы построчное ревью стало необязательным
- 759 ★ репозитория
- Последний коммит
- MIT
Расширенный доступ
Почему такой уровень
- Запускает тесты, типы и мутационные проверки над кодом проекта
- Устанавливает и выполняет инструменты набора проверок
Установка
- Работает в
В терминале, через SkillFoxx CLI
npx skillfoxx add skills/old-coderОпределит агенты на машине, покажет уровень доступа и зафиксирует версию.
Другие способы установки
Доступ и проверки
Как мы проверяемРасширенный доступИнструмент запускает код или ходит в сеть, а внешние данные только читает.
- Запускает тесты, типы и мутационные проверки над кодом проекта
- Устанавливает и выполняет инструменты набора проверок
Это чужой код. Посмотрите файлы в репозитории перед установкой.
Что делает
Скилл задает агенту рабочий цикл, где доверие строится на двух артефактах вместо чтения кода. Сначала агент пишет исполнимую спецификацию с конкретными примерами того, что код должен и не должен делать, и вы утверждаете именно ее. Затем код проходит набор проверок: тесты, типы, покрытие, мутационное тестирование, а результат сводится в отчет с доказательствами. В комплекте отдельный скилл old-coder-api для контрактов HTTP и JSON и демо-проект с готовым набором проверок.
Для кого. Для разработчиков, которым нужны высокая надежность и доказуемое качество кода.
Подходит, если
- Нужна доказательная разработка по TDD с исполнимой спецификацией
- Изменение затрагивает деньги, авторизацию, потерю данных или конкурентность
- Хочется, чтобы значение слова готово подтверждалось проверками
Не подходит, если
- Рутинная правка, где достаточно обычных тестов
- Нет возможности запускать тесты, типы и мутационные проверки
Пример запроса к агенту
Сделай эту фичу по доказательному циклу: сначала спецификация на утверждение, потом код с отчетом о проверкахОграничения
Набор проверок подтверждает то, что выражено в спецификации, но не гарантирует, что спецификация учла все важное, поэтому ключевой шаг это утверждение спецификации человеком. Полный цикл требует времени и настроенного инструментария тестов, типов и мутационного тестирования. Отчет дает слоистую, проверяемую уверенность, а не абсолютное доказательство.
Как отключить. Удалите папку old-coder из каталога skills вашего агента, например ~/.claude/skills/old-coder.
Частые вопросы
Что я утверждаю?
Спецификацию, а не код. Это единственный шаг, где решение принимает человек, и он разрывает связку, где все написано одним агентом.
Чем полезен old-coder-api?
Это отдельный скилл для контрактов HTTP и JSON: совместимость, авторизация, идемпотентность, пагинация и лимиты запросов.
Обсуждение
Вопросов и отзывов пока нет.
Похожие
СкиллыСкилл находит в коде мусор от ИИ-агентов: дубли хелперов, пустые абстракции, слабые тесты. Чистит по одному шаблону за коммит.
Скилл чистки кода после агентов: находит лишние тесты, самопроверки и запасные ветки и удаляет их, сохраняя поведение
Скиллы-контроли для кодовых агентов: второй проход по диффу, который ловит типичные ошибки в коде, тестах и документации от ИИ
Скиллы разработки по спецификации: брейншторм, план, ревью в формате дебатов и допрос идеи до первого коммита.
Скилл запускает полный рефакторинг, после которого агентам проще читать код: ищет скрытые связи и лишние зависимости.
Скилл с рабочими правилами для агента: диагноз по коду, проверка в запущенном продукте, повторные замечания в ограничения.
Коротко о README
README описывает подход, где человек не читает реализацию, а доверяет двум артефактам: утвержденной спецификации и отчету о прохождении проверок. Цикл идет от спецификации к красным и зеленым тестам, рефакторингу, набору проверок и отчету с доказательствами. В репозитории есть основной скилл, спутник old-coder-api и демо-проект rate-limiter с инструментами набора проверок. Установка через npx skills add или копированием папки. Лицензия MIT.
Бейдж для README
Исходный SKILL.md
--- name: old-coder description: Evidence-first development, surround the implementation with an executable spec and a gauntlet of constraints (tests, types, coverage, mutation) so line-by-line review becomes optional. Use when the user explicitly asks for high-assurance or evidence-first work (reliable, TDD, prove it works, I won't read the code), or when the change touches high-stakes domains (money, auth, data loss, concurrency, public API). For routine changes where the user just wants normal tests, write good tests directly instead of invoking this loop. --- # Old Coder: Reliable Coding Under Constraint and Test The human will NOT read your implementation. Their confidence comes entirely from two artifacts you produce: (1) an executable specification they approve before you write code, and (2) an evidence report proving the code ran the gauntlet. ## The Loop SPEC to (human approves spec, not code) to RED to GREEN to REFACTOR to GAUNTLET to EVIDENCE, repeat per behavior.