На GitHub опубликован Markdown Gatekeeper — локальный CLI-инструмент для проектов, где люди, Claude, Codex и другие AI-агенты создают пересекающиеся Markdown-документы. Идея проекта простая: документ не должен становиться «текущим источником истины» только потому, что агент назвал его authoritative.
Репозиторий появился в ленте Hacker News как Show HN. По описанию проекта, это первая dogfood-реализация: инструмент уже используется как демонстрация собственного подхода, но релиз выглядит ранним — в частности, установка из npm пока описана как будущий сценарий, а сейчас предлагается ставить CLI напрямую из GitHub.
Что выпущено
Markdown Gatekeeper позиционируется как local-first authority layer для Markdown-документации. Он не заменяет обычные .md-файлы и не требует переезда в отдельную облачную систему: проект сохраняет обычный Markdown и локальный Git, а поверх добавляет протокол определения того, какие документы считаются актуальными.
На текущем этапе установка заявлена через:
npm install -g github:nanlogic/markdown-gatekeeper
После публикации в npm команда должна стать стандартной:
npm install -g markdown-gatekeeper
Также предусмотрены команды настройки под конкретные agent host:
mdg setup codex
mdg setup claude
mdg setup status
По описанию, для Codex и Claude Code инструмент управляет отдельными skill/launcher/bootstrap-файлами в соответствующих конфигурационных директориях. Важная деталь: лаунчеры используют абсолютные пути к Node и пакету, чтобы GUI-сессии не зависели от того, попал ли глобальный npm bin в PATH.
Как это должно работать
Главная команда для существующего проекта — mdg init . Она описана как zero-touch и должна выполнять discovery, review, безопасную публикацию высокоуверенных результатов, архивирование, фиксацию Evidence и проверки целостности без дополнительных подтверждений.
В обычных сессиях агента Gatekeeper должен работать «тихо»: если проект уже управляется инструментом, bootstrap автоматически возобновляет adoption-сценарий при нулевой ревизии registry или наличии старых entrypoint-документов. Пользовательский review, согласно описанию, появляется только когда текущая задача реально зависит от неразрешенного продуктового намерения.
Отдельно заявлен режим –preview: он выполняет классификацию и отчет по риску архивирования без review и публикации. Есть и –setup-only, если нужно установить только протокол без полного прохода по проекту.
Почему это важно
Подтвержденный факт из описания проекта: Markdown Gatekeeper решает проблему не генерации текста, а управления статусом документов. Это актуальная боль для команд, которые подключают LLM-агентов к репозиториям: агент может создать новый plan.md, architecture.md или requirements.md, частично продублировать старые файлы и тем самым запутать следующий запуск.
Практическая ценность подхода — в попытке сохранить привычный Git/Markdown workflow, но добавить слой «кто сейчас главный источник по теме». Это особенно полезно в agentic-разработке, где контекст быстро устаревает, а документы начинают конкурировать между собой.
Это уже интерпретация: если инструмент окажется устойчивым, он может стать не столько «документационным менеджером», сколько частью гигиены AI-разработки — рядом с проверками кода, тестами и политиками доступа.
Ограничения и риски
Проект пока выглядит ранним. В предоставленном описании нет данных о стабильном npm-релизе, широком использовании, аудите безопасности или сравнительных тестах. Также заявленная интеграция прямо описана для Codex и Claude Code; о полноценной поддержке других сред из этого фрагмента делать вывод нельзя.
Еще одно ограничение — зависимость от качества review-процесса. В описании упоминается изолированный Codex CLI, трехминутный timeout reviewer и fallback на текущую Codex/Claude-сессию при специальных флагах. Это полезно как защитный механизм, но не доказывает, что инструмент всегда корректно определит продуктовый intent или безопасно архивирует спорные документы.
Наконец, отсутствие облака и MCP-зависимости — плюс для локального контроля, но одновременно означает, что командам придется самим встраивать Gatekeeper в свои процессы, CI и правила работы с репозиторием.
Источники