От гигантского промпта к project ops: Claude Code в длинном монорепозитории

Разработчик restofstack на Dev.to рассказывает, как ушёл от схемы «один раздутый промпт» к обвязке вокруг Claude Code, которая помогает не терять контекст между сессиями: guardrails в репозитории, сопровождающая документация, лёгкая рабочая память и повторяемые сценарии вроде стендапа и отчёта. https://dev.to/restofstack/i-stopped-using-claude-code-as-a-giant-prompt-and-started-using-it-as-project-ops-ec9

Материал опубликован 13 мая 2026 года (на площадке указано время 03:54 UTC); в карточке поста — примерно пять минут чтения, три комментария и ноль публичных реакций. По тегам ai, productivity, devtools материал попадает в тематические ленты — рядом с практиками вокруг ИИ‑ассистентов в работе разработчика.

Задача долгоживущего монорепо без «пересборки головы» в каждой сессии

В длинном монорепозитории языковая модель часто хороша в режиме «здесь и сейчас», но каждая новая сессия с ассистентом снова требует восстановить картину проекта. В своём случае автор использовал Claude Code не только для кода: разбор очереди (triage бэклога), аккуратные репорты по багам, планирование, недельные сводки и фиксация решений между заходами в чат. Вывод простой по форме: улучшить один промпт мало — нужен тонкий слой project ops вокруг инструмента.

Короткий CLAUDE.md: guardrails для каждой сессии

В примере репозитория лежит компактный CLAUDE.md: он задаёт только правила уровня репозитория для каждой сессии Claude Code. Архитектурные простыни, runbooks и «огромный дамп» контекста о проекте к этому файлу не относятся — их выносят в другое место вместе с остальной долговечной документацией.

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

docs/maintainers/: куда девается долгий контекст

«Долгоживущий» материал сосредоточен в docs/maintainers/. В описанной структуре участвуют README.md и ветки вроде overview/ и development/.

К типам текстов для maintainer‑документации он относит обзоры систем, границы сервисов, заметки по локальной разработке, runbooks и release notes. Для Claude Code это прямой способ, чтобы ассистент подхватывал нить между днями, а не жил только в памяти одного чата.

Лёгкая память: локальный JSON и команда /reflect

Lightweight memory здесь — не отдельный сервис и не «ещё одна база продукта», а маленький локальный JSON‑файл под подвижную рабочую память.

В примере фигурирует путь .workspace-temp/context-db.json. Внутри, среди прочего, фиксируется, что недавно ушло в поставку, контекст ветки или PR, решения, которые стоит помнить, и паттерны оценок.

Пополнять память без ручного редактирования файла можно командой /reflect — она добавляет небольшие записи.

Повторяемые сценарии в .claude/commands/

Повторяемые сценарии оформлены как команды в каталоге .claude/commands/. В тексте названы файлы standup.md, bug.md, rfe.md, reflect.md, weekly-report.md.

К публичному стартеру добавлены сценарии /checkpoint, /sanitize, /docs-sync, /release-notes, /root-cause.

Кратко по ролям: /standup сводит память, состояние git, PR, бэклог и maintainer‑документы и предлагает следующие шаги; /bug собирает аккуратный баг‑репорт без превращения всей сессии в полноценную отладку; /weekly-report превращает сигналы проекта в сохраняемый отчёт, а не разовый ответ в канале или чате.

MCP, внешние системы и вынесенный стартер

В своей связке автор держит Jira MCP для бэклога, Confluence для уже опубликованных отчётов, локальную JSON‑«context DB» как рабочую память, maintainer‑доки как стойкий контекст и команды вроде /standup, /bug, /rfe. Переносимая часть вынесена в публичный стартер без приватных деталей.

Публичный пример упакован в репозиторий restofstack/claude-project-ops-starter (полный адрес страницы с материалом — в блоке источников ниже). В исходной публикации отдельные метрики этого репозитория не указаны — поэтому цифры звёзд, форков и тому подобного здесь не приводятся.

Spec Kit не конкурирует: два разных слоя

К Spec Kit автор относится как к инструменту, который продолжает использовать. Стартер не позиционируется как замена: Spec Kit прокатывает фичу или изменение в сторону спека и реализации продукта, а описанная обвязка закрывает другой контур — рабочая память, maintainer‑доки, стендапы, захват багов и RFE, отчёты, handoff и повторяемые репозиторные workflow, чтобы Claude Code можно было «продолжить завтра».

Если стек другой

В тексте упомянуты адаптеры под альтернативные связки: Jira плюс Confluence; GitHub Issues плюс документация в репозитории; локальный JSON плюс только markdown. Это не лицензионный или ToS‑разбор — такие темы в исходном посте не раскрыты; переносить юридические выводы без нового первоисточника нельзя.

Короткая выжимка из рекомендаций автора

Итоговый чек‑лист в оригинале разворачивается в пять шагов: держать CLAUDE.md коротким; переносить долговечный контекст в maintainer‑документацию; начать с крошечного локального файла памяти; формализовать от трёх до пяти частых workflow; держать фактические данные бэклога и релизов в доверенных внешних системах учёта.

Источники

• restofstack. I Stopped Using Claude Code as a Giant Prompt and Started Using It as Project Ops — Dev.to: Dev.to (дата доступа: 2026-05-13, 12:00 UTC).