QUALITY.md
- title
- QUALITY.md
- type
- toolbox
- summary
- Формат корневого файла, задающий критерии качества проекта, и CLI для проверки кода по ним
- tags
- typescript, software-quality, ai-agents, spec-driven-development, file-format, watchlist
- language
- TypeScript
- license
- MIT
- created
- 2026-07-23
- updated
- 2026-07-23
- lang
- ru
- translation_of
- quality-md
- source_updated
- 2026-07-23
- translated
- 2026-09-01
- translator
- lllm/antigravity/gemini-3.7-flash-medium
QUALITY.md - это файл в корне репозитория, где описано, что значит качество для конкретного проекта: какие характеристики важны (безопасность, поддерживаемость, качество тестов и спецификаций и так далее), каковы требования по каждой из них, а также контекст - миссия, потребности заинтересованных сторон, риски, - объясняющий этот выбор. Исходная посылка такова: и агенты, и люди одинаково плохо работают с задачей "сделай лучше" без записанных критериев, и эти критерии должны лежать в репозитории, а не в чьей-то голове.
Проект состоит из трёх компонентов. Сам формат представляет собой спецификацию, не зависящую от поставщиков и инструментов. CLI qualitymd и навык для агентов /quality служат эталонной реализацией: они читают файл, оценивают кодовую базу на соответствие ему и записывают отчёт об оценке вместе с приоритезированным списком рекомендаций по улучшению в каталог .quality/:
.quality/
└── evaluations/
└── 0001-full-eval/
├── report.md
└── recommendations.md
Нумерация оценок позволяет накапливать историю проверок, а не перезаписывать один и тот же снимок состояния, а файл рекомендаций специально оформлен для передачи дальше - проверяющему-человеку или агенту в качестве следующей порции задач. Авторы называют получающийся цикл "петлёй качества" (quality loop): объявить, оценить, исправить, переоценить.
В каком ряду стоит
Идея принадлежит к целому семейству. llms-txt предложил корневой markdown-файл с описанием сайта для LLM; CLAUDE.md и AGENTS.md делают то же самое для правил внутри репозитория; QUALITY.md - тот же приём, применённый к критериям оценки. Отличительная ставка здесь в том, что качество специфично для конкретного проекта и должно быть явно объявлено, поэтому формат содержит контекст и потребности заинтересованных сторон, а не фиксированный чек-лист, - вариантом без необходимости в отдельной спецификации была бы просто конфигурация линтера.
Подход также пересекается с инструментами разработки на основе спецификаций (spec-driven development), не дублируя их. acceptance-criteria-ids, как это используется в acai, нумерует отдельные требования, чтобы написанный агентом код мог ссылаться на закрываемый пункт спецификации; это делается на уровне отдельных возможностей и коммитов. QUALITY.md работает уровнем выше - со свойствами всей кодовой базы, которые не покрываются отдельными критериями приёмки. Они совместимы, и главный практический вопрос - захочет ли проект, ведущий одно, тратить силы на поддержание второго.
Раздел о философии на сайте - поддерживать что-то значит заботиться о нём, а забота о вещи, которая кому-то служит, есть забота об этом человеке, - формулировка куда более приятная, чем у большинства инструментов для контроля качества. Она также обходит более сложный вопрос, поднятый в notes-on-software-quality, где качество определяется как отсутствие проблем и утверждается, что качество не выдерживает масштабирования организации. Явно заданный свод критериев этой проблемы не решает; он лишь делает разрыв между декларируемыми и реальными стандартами наглядным, что является гораздо более скромным заявлением.
Ограничения
На момент написания проекту шесть недель, один разработчик, 29 звёзд. Ценность формата целиком зависит от его распространения - открытая спецификация, которую читает только собственный CLI, оказывается усложнённым конфигурационным файлом, - а сторонних реализаций пока не видно. Оценка выполняется LLM, читающей критерии, поэтому результат наследует все особенности суждений LLM: он правдоподобен, нестабилен от запуска к запуску и непроверяем без самостоятельного чтения кода. Написать хороший QUALITY.md - самая трудная часть, и инструмент не сделает этого за вас; абстрактное описание приведёт к таким же абстрактным рекомендациям.
Находится в watchlist - имеет смысл вернуться и проверить, начали ли формат использовать проекты, не связанные с авторами, появилась ли вторая реализация спецификации, и представляют ли отчёты об оценке собой что-то большее, чем просто хорошо структурированный код-ревью.
Репозиторий: github.com/qualitymd/quality.md - ~29 звёзд, MIT, TypeScript. Сайт: getquality.md.