Огород  ·  ogorodush

Рабочая среда для проектов с ИИ-агентом

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

Огород экономит с обеих сторон: markdown-хранилище становится внешней памятью агента, документация — его дешёвым онбордингом, а тиринг моделей отдаёт простые задачи младшей модели.

И всё это — через простые файлы в git: ничего не заперто в чужом облаке.

Зачем это  ·  🚀 Быстрый старт  ·  👀 Как это выглядит  ·  📚 Документация

🌱 Вам нужен Огород, если

• вы ведёте несколько проектов с ИИ-агентом и теряете контекст между сессиями;
• хотите системность — приоритеты, статусы, «что я вообще сделал» — но без Jira и без ручного трекинга;
• замечаете, что агент дорожает: на всё уходит топ-модель, хотя половина работы — механика;
• не хотите вендор-лока: данные должны оставаться простыми файлами, которые переживут любой инструмент;
• готовы, чтобы рутину беклога вёл агент, а вы — только подтверждали закрытие.

✨ Что внутри

🧠 Внешняя память агента

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

📖 Документация, которая окупается в токенах

В Огороде документация — обязательный, но лаконичный артефакт, и существует он по правилу APC (Audience · Purpose · Collaboration). Внутренняя дока пишется под машинное чтение — открытый AGENTS.md-формат, структурно, кратко. Это контракт проекта для любого агента: он читает архитектуру и решения вместо того, чтобы выводить их из кода заново. Прямое следствие — экономия токенов и вендор-независимость; косвенное — вы сами через месяц вспоминаете проект за минуту.

🎚️ Тиринг моделей и делегирование

Каждой задаче назначается грейд по её сложности — junior / middle / senior — и по умолчанию работает самая дешёвая модель, что справится. Механику с чётким результатом оркестратор делегирует субагенту на junior-модели; senior-модель остаётся на рассуждение и приёмку. Грейды вендоронейтральны: какая модель стоит за каждым — дело адаптера инструмента (в Claude Code junior=Haiku, middle=Sonnet, senior=Opus), сам канон моделей не знает. Зависимость от одной топ-модели — точка отказа; тиринг её снимает и попутно режет счёт.

🎯 RICE-приоритизация

Каждая задача оценена по формуле (reach × impact × confidence%) / effort, размер — в Story Points (валюта ИИ — токены, не часы). Беклог сортируется сам, и «что брать следующим» перестаёт быть спором с собой: сверху — то, что важнее всего.

✅ Отслеживаемость и апрув человека

Главное правило: агент не отчитается «готово», пока работа не отражена задачей — это касается и фич, и работы над самим инструментарием. По хранилищу всегда видно, что, когда и почему делалось. А done ставит только ваш апрув: агент доводит задачу до review, предъявляет результат и ждёт «ок». Потолок агента — review, и это закреплено механически, не на честном слове.

🔁 Храповик ошибок

Агент не учится между сессиями — переживают только файлы и механические гейты. Поэтому Огород не обещает «больше так не буду»: пойманная однажды ошибка фиксируется в журнале, а её повтор закрывается механическим гейтом (хук, валидатор), который работает без участия агента. Система не откатывается назад по уже понятым граблям — надёжность копится, а не выветривается.

🔓 Без вендор-лока

Ни базы, ни облака, ни проприетарного формата — только markdown и git. Навыки агента это тоже markdown-инструкции. Ваши проекты, задачи и память переживут смену агента, редактора и подписки.

👀 Как это выглядит

Локальный дашборд (npm run dashboard, Node 18+, без npm install) — веб-витрина над тем же markdown-хранилищем: те же файлы открываются и в Obsidian. У дашборда всего две точки записи — захват в инбокс и апрув задач review → done; всё остальное только читается. Подробнее — dashboard/README.md.

Проекты — карточки со статусом, прогрессом и топ-задачей по RICE

Канбан — задачи всех проектов по статусам, с тикетом, RICE и тегами

RICE-беклог — всё, отсортированное по приоритету

Инбокс — сырые мысли «на потом»; агент превращает их в задачи

Скриншоты сняты с демонстрационного хранилища. В шаблоне лежит один пример-проект под удаление.

🔄 Как это повлияет на вашу работу с агентами

«посмотри что по задачам, бери запланированное в работу»
   → sync → берёт верхнюю по RICE → doing → делает → review → ждёт апрува
«разбери инбокс»   → 3 сырые записи → 3 задачи с RICE, инбокс пуст
«итоги недели»     → что сделано и зачем, по проектам

🚀 Быстрый старт

1. Use this template (или клон) → чистое хранилище.
2. Откройте папку в своём агенте и дайте ему инструкцию ниже. (Claude Code подхватывает правила сам через CLAUDE.md → @AGENTS.md.)
3. (Опционально) Откройте папку как хранилище Obsidian и поставьте плагин Dataview — заработают сводки _dashboard.md и tasks.md.
4. Удалите projects/example-project/ и заведите свой первый проект: попросите агента «заведи проект X».

Инструкция для агента — вставьте в начало работы (Cursor, Codex и др. читают AGENTS.md сами):

Веди моё проектное хранилище по методологии «Огород». Ты — агент с доступом к файлам
этого репозитория и к инструментам (чтение/запись файлов, запуск команд).

1. Прочитай в корне репозитория AGENTS.md и _rules.md — это твои правила.
   (Cursor, Codex и некоторые другие читают AGENTS.md сами — тогда просто
   подтверди, что прочёл правила, и продолжай.)
2. Навыки — это пошаговые markdown-инструкции в skills/<имя>/SKILL.md:
   sync, backlog, close, recap, inbox, onboard, charter, setup. Когда задача
   соответствует навыку — открой его файл и выполни по шагам.
3. Главное правило: каждое значимое действие отражай задачей и не отчитывайся
   «готово», пока работа не отражена задачей и не проверена. Статус done ставит
   только человек — твой потолок review.
4. Если это первый запуск (в projects/ только example-project) — выполни навык
   setup (онбординг + выбор дашборда). Иначе начни с sync: загрузи контекст всех
   проектов и предложи, с чего начать.

Обновления методологии (канон, навыки, шаблоны) бери из шаблона
https://github.com/kringova/ogorodush — когда нужна свежая версия _rules.md,
_templates/, skills/ или docs/, синхронизируйся оттуда.

Дальше он работает сам — скажите «/sync» в любой момент, чтобы перечитал контекст.

📚 Документация

Документация в Огороде — обязательный артефакт, а не приложение к коду: это онбординг агента и кэш ваших решений. Канон описывает, какие документы обязательны на каждой стадии проекта (от идеи до прода) и как выбрать тип документа по APC.

🗂️ Структура

AGENTS.md            ← канонические правила для агента (вендор-нейтрально)
CLAUDE.md            ← шим `@AGENTS.md` для Claude Code (он не читает AGENTS.md сам)
_rules.md            ← полная методология
_templates/          ← шаблоны задачи, проекта и документов
_dashboard.md        ← Dataview-сводка по всем проектам
_inbox/              ← сырые мысли «на разбор» (по файлу на запись)
projects/
  <проект>/
    <проект>.md      ← карточка проекта: суть, статус, метрики, лог сессий
    roadmap.md       ← фазы и планы
    tasks/
      tasks.md       ← Dataview-индекс задач
      <задача>.md    ← задача с RICE-приоритетом и сквозным id
skills/
  sync/              ← загрузить контекст всех проектов в сессию
  backlog/           ← завести задачу с RICE, ролями и грейдом модели
  close/             ← закрыть задачу (review + лог сессии) или завести постфактум
  recap/             ← итоги за период (день/неделя/месяц) для ревью и саморефлексии
  inbox/             ← разобрать _inbox/ в задачи
  setup/             ← первый запуск vault: онбординг + выбор дашборда
  onboard/           ← поднять канон доки существующего проекта (brownfield)
  charter/           ← родить новый проект по канону (greenfield)

⚙️ Ключевые конвенции

• RICE-приоритизация — (reach × impact × confidence%) / effort; беклог сортируется сам.
• Story Points вместо часов — размер задачи в sp (Фибоначчи); у людей валюта — время, у ИИ — токены, поэтому velocity меряется в токенах на SP.
• Грейд модели по размеру — model_tier (junior ≤ 2 SP, middle 3–5, senior ≥ 8); при затыке эскалация на ступень вверх. Маппинг грейд→модель объявляет адаптер инструмента, не канон.
• Сквозные id тикетов — максимальный id по всем проектам + 1; не переиспользуются.
• Гейт отслеживаемости (главное правило) — агент не отчитывается о работе, пока она не отражена задачей; касается и работы над самим инструментарием.
• Закрытие через апрув — done ставится только человеком; потолок агента — review, закреплён механически.
• Храповик ошибок — повтор пойманной ошибки закрывается механическим гейтом, а не напоминанием.
• Инбокс-цикл — сырая мысль → _inbox/*.md → навык inbox превращает её в задачу и удаляет запись.
• Документация как часть DoD — значимое изменение не уходит в done, пока не обновлён нужный документ.
• Статусы — todo → doing → review → done (+ blocked, cancelled).

💬 Обратная связь

Нашли баг, есть идея или вопрос — заведите issue. Это и есть канал связи по проекту: обсуждение остаётся публичным и помогает следующему.