菜单
Применить обновление методологии Огорода — подтянуть свежие _rules.md, skills/, docs/, _templates/, scripts/, .githooks/ из последнего GitHub-релиза kringova/ogorodush, сохранив весь пользовательский контент vault'а. Используй по команде «обнови Огород» — обычно после баннера обновления в sync.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Загрузить контекст проектов и задач из vault в начале сессии. Используй, когда пользователь говорит «sync», «status», «что по проектам», «обзор» или начинает работу и нужно войти в курс дела.
Дайджест за период (неделя/месяц/полгода/произвольный) — умная сводка того, что сделано и какой эффект, что свернули и почему, темы и прогресс. Не список задач, а нарратив. Сохраняется файлом в vault. Используй, когда пользователь говорит «дайджест», «итоги недели/месяца», «что я сделал за…», «собери результаты», «для ревью», когда прощается/уходит (дай дайджест дня сам), и когда навык sync сообщил, что закрылся период без дайджеста.
Первый запуск Огорода — онбординг свежего vault: представить методологию, помочь выбрать дашборд (mini без сборки / full на Next.js) и записать выбор в ogorod.config.json. Используй при первом запуске (в projects/ только example-project) или по триггерам «setup», «онбординг», «первый запуск», «выбрать дашборд», «переключи дашборд».
Закрыть задачу в vault — но done ставит только человек (апрув через апрув-поверхность адоптера). Используй, когда работа по задаче готова к закрытию ИЛИ когда сделал что-то значимое без задачи (заведи постфактум, предъяви, отправь на подтверждение).
Завести задачу в беклог проекта (vault). Используй, когда пользователь говорит «добавь в беклог», «заведи задачу», «запиши задачу» или описывает дело, которое надо не потерять.
Родить новый проект по канону Огорода — собрать стартовую документацию (brief/RFC, карточка с JTBD, roadmap, пустые decisions/scenarios) ДО первой задачи. Используй для greenfield «с нуля»; триггеры — «заведи новый проект», «начни проект X», «charter», «рождение проекта». Для уже существующего кода без доки — это onboard, не charter.
| name | update |
| description | Применить обновление методологии Огорода — подтянуть свежие _rules.md, skills/, docs/, _templates/, scripts/, .githooks/ из последнего GitHub-релиза kringova/ogorodush, сохранив весь пользовательский контент vault'а. Используй по команде «обнови Огород» — обычно после баннера обновления в sync. |
| user_invocable | true |
Путь от баннера sync «🌱 Обновление Огорода» до применённого обновления. Не read-only — меняет файлы канона, но каждая запись — после диф-превью и явного подтверждения.
sync «🌱 Обновление Огорода» — по команде «обнови Огород».ogorodush (remote origin указывает на kringova/ogorodush, либо это репозиторий-методология) — источник канона и есть этот репозиторий, обновлять неоткуда. Скажи это прямо, ничего не делай.kringova/llmush), навык ему не нужен: обновления в llmush вносятся мейнтейнером вручную, не через pull апстрима. Если тебя всё же попросили выполнить update в llmush — уточни у пользователя, точно ли это нужно, прежде чем действовать.kringova/ogorodush) — навык применим, переходи к шагу 1.Источник истины — GitHub Releases kringova/ogorodush:
curl -fsS https://api.github.com/repos/kringova/ogorodush/releases/latest
tag_name (напр. v1.3.1) — целевая версия; semver без v — то, что пишется в ogorod_version. Пользователь может назвать версию явно («обнови до 1.2.0») — используй её, тег v1.2.0.
Сверь с текущей ogorod_version в ogorod.config.json. Целевая версия должна быть новее. Равна или старше — обновлять нечего, скажи и останови. Поля нет или файла нет — вероятно, setup не запускался; сначала он.
Каталог вне vault: dest=$(mktemp -d). Основной путь — git clone на конкретный тег, без истории:
git clone --depth 1 --branch v<version> https://github.com/kringova/ogorodush "$dest"
Fallback, если git недоступен или clone упал (сеть, приватность форка и т.п.) — архив релиза по HTTP:
curl -fsSL https://github.com/kringova/ogorodush/archive/refs/tags/v<version>.tar.gz | tar xz -C "$dest" --strip-components=1
Оба варианта кладут содержимое репозитория версии <version> прямо в $dest (без вложенной ogorodush-<version>/, для tar — за счёт --strip-components=1).
Обновляемые пути (канон, перезаписываются из апстрима целиком):
_rules.mdskills/docs/_templates/scripts/.githooks/Никогда не трогать (пользовательский контент и данные конкретного vault'а):
projects/, beds/, _inbox/, _dashboard.md, _lessons.md, _requests.mdogorod.config.json — меняется только поле ogorod_version (шаг 7); dashboard, default_bed и любые другие поля не трогатьТолько по явному согласию (могут быть кастомизированы под адаптер — спроси отдельно, не включай молча в диф шага 4):
dashboard/, dashboard-app/Остальное в корне апстрима (README.md, .github/, LICENSE, CHANGELOG.md, package.json, bed.json, AGENTS.md, CLAUDE.md) в обновление не входит — не копировать без отдельной явной просьбы.
До первой записи в vault покажи, что изменится:
diff -rq <vault>/skills "$dest"/skills
diff -rq <vault>/docs "$dest"/docs
diff -u <vault>/_rules.md "$dest"/_rules.md
# аналогично для _templates/, scripts/, .githooks/
diff -u, не только список путей) для ключевых файлов: _rules.md и каждый изменённый skills/*/SKILL.md._rules.md/skills/*/docs/* в vault'е отличается от версии апстрима, с которой обновлялись в прошлый раз (кастомизация, а не устаревание), подсвети отдельно: «локально изменено, будет перезаписано». Не смешивай с обычным «обновилось в апстриме».Только пути из «обновляемые» (шаг 3), только после подтверждения (шаг 4):
rsync -a --delete "$dest"/skills/ <vault>/skills/
rsync -a --delete "$dest"/docs/ <vault>/docs/
rsync -a --delete "$dest"/_templates/ <vault>/_templates/
rsync -a --delete "$dest"/scripts/ <vault>/scripts/
rsync -a --delete "$dest"/.githooks/ <vault>/.githooks/
cp "$dest"/_rules.md <vault>/_rules.md
--delete — канонная папка зеркалит апстрим: навык, удалённый в новой версии, не должен зависать сиротой. Нет rsync — cp -R + вручную удалить в vault'е файлы, которых нет в $dest (сверить по списку шага 4).
dashboard//dashboard-app/ — тем же способом, только если согласие получено в шаге 4.
Если vault — адаптер с собственным слоем поверх канона (пример — llmush: LLMUSH_APPROVE вместо OGOROD_APPROVE, абсолютные пути вместо «корень репозитория» в глобальных обёртках ~/.claude/skills/*), обновление канона могло затереть эти отличия там, где они лежат поверх канонных файлов (например, skills/sync/SKILL.md, если раздел «Где vault» переопределён). Сверь применённый диф с известными адаптациями этого vault'а и напомни пользователю переприменить их — не восстанавливай сам: адаптация специфична для инструмента, и решение, что в ней менять при новой версии канона, за пользователем.
Запиши целевую версию в ogorod.config.json → ogorod_version (только это поле, остальные не трогать).
Предложи коммит явными путями (не git add -A, см. _rules.md):
git add _rules.md skills/ docs/ _templates/ scripts/ .githooks/ ogorod.config.json
git commit -m "chore: обновление Огорода до v<version>"
Атрибуция — через scripts/agent-commit.sh, если в vault'е принят этот способ коммита, вместо git commit напрямую. Навык не коммитит без запроса пользователя — только предлагает команду.
Покажи релизноутс всех применённых версий: если между старой и новой ogorod_version были промежуточные релизы, возьми body каждого через GET .../releases (не только /releases/latest) и выведи по порядку.
Удали временный каталог $dest после применения (или отказа) — он не часть vault'а и не должен остаться на диске.
ogorodush, не llmush)ogorod_version_rules.md, изменённые скиллы); локальные правки подсвечены отдельно как «будут перезаписаны»projects/, beds/, _inbox/, _dashboard.md, _lessons.md, _requests.md и пользовательские поля ogorod.config.json не тронуты; dashboard//dashboard-app/ — только по согласиюogorod_version обновлён, коммит явными путями предложен (не выполнен без запроса пользователя)