| name | demo-content-delete |
| description | Удалить демо-контент из свежеразвёрнутого vault — примеры логов, отчёта и заметок, перечисленные в demo-manifest.json, — сверяясь с оригинальными хэшами, отдельными вопросами предлагает удалить инструкции по развёртыванию (README, INTEGRATION, CONTRIBUTING) и файлы, нужные только разработке базы (перечислены в `demo-manifest.json`, группа `baseOnly`), а затем удаляет себя и манифест. Используй, когда пользователь пишет /demo-content-delete, «удали демо», «убери примеры», «очисти vault от демо-контента», или когда адаптация vault по INTEGRATION.md завершена. |
Скилл одноразовый: в конце он удаляет сам себя. Запускается один раз, после того как vault адаптирован под пользователя.
Когда останавливаться и спрашивать
Демо-файл мог быть отредактирован пользователем — тогда в нём есть его работа, и удалять молча нельзя. Единственный признак — sha256 из demo-manifest.json.
Порядок
1. Прочитать манифест
Прочитай demo-manifest.json в корне vault.
- Есть — иди к шагу 2.
- Нет — сам по себе этот факт не значит, что демо убрано: так выглядит и прерванный прошлый запуск (шаг 6 удаляет манифест первым делом, ещё до удаления себя), и ручное удаление файла пользователем. Разберись, прежде чем что-то утверждать:
git show HEAD:demo-manifest.json — если манифест находится, восстанови его на диск в исходном виде и продолжай с шага 2 как обычно. Скилл ничего не коммитит сам (см. шаг 6), поэтому пока прошлый запуск не закоммичен, манифест почти всегда восстановим так. Если файлы уже разобраны прошлым запуском, шаги 2–4 просто ничего не найдут — это нормально, не ошибка.
- Не нашёлся и в HEAD (удаление закоммичено, либо манифеста никогда не было) — хэши потеряны безвозвратно, отличить нетронутый демо-файл от правки пользователя больше нельзя. Выполни грep из шага 5 — он найдёт ссылки на демо-заметку, но не всеобъемлющ: демо-файл без этих меток в тексте (например, отчёт
Log/Reports/...) он не покажет. Честно предупреди пользователя об этом ограничении, покажи всё, что нашёл грep, и спроси, что с этим делать, — не решай сам.
- Если по итогам проверки демо-следов не осталось, а
skills/demo-content-delete/ всё ещё на месте — скилл просто не доудалил себя в прошлый раз: доделай шаг 6. Только когда делать больше нечего вовсе, сообщи, что демо уже было убрано, и останови.
2. Разобраться с целыми демо-файлами
Для каждой записи demoFiles:
-
Если файла нет — пропусти молча.
-
Посчитай sha256 файла и сравни с sha256 из манифеста. Команда зависит от ОС — общей нет, зато на каждой платформе нужная есть из коробки, без Node, Python и jq (у пользователя их может не быть вовсе):
shasum -a 256 "<путь>"
Get-FileHash -Algorithm SHA256 "<путь>" # Windows
Get-FileHash печатает хэш заглавными буквами, shasum — строчными: сравнивай без учёта регистра. shasum дописывает после хэша имя файла, Get-FileHash выводит таблицу — бери из вывода саму hex-строку.
-
Совпал — файл не тронут, удали его.
-
Разошёлся — покажи пользователю дифф относительно версии из git (git show HEAD:"<путь>", путь в кавычках — в именах демо-файлов бывают пробелы и кириллица) и спроси: удалить целиком, оставить целиком, или удалить только демо-часть. Без ответа не удаляй.
Собери список удалённого и изменённого — он понадобится в шаге 6.
Демо-файлы лежат в месячных каталогах Log/<год>/<месяц>/ и Notes/<год>/<месяц>/, и после их удаления эти каталоги могут остаться пустыми — git такие не хранит, но в дереве файлов Obsidian они висят. Убери каталоги, опустевшие из-за удаления: поднимайся вверх, пока каталог пуст, и останавливайся, как только встретишь непустой, .gitkeep внутри (Log/Reports/, Notes/, files/ — это каркас vault, он остаётся даже пустым) или корень vault.
3. Предложить удалить инструкции по развёртыванию
Записи setupDocs — это README.md, README_ru.md, INTEGRATION.md, CONTRIBUTING.md: они рассказывают, как развернуть и адаптировать базу. Работу свою они к этому моменту сделали, но это справочники, а не примеры, поэтому удалять их молча нельзя даже при совпадении хэша.
- Посчитай sha256 каждого файла — так же, как в шаге 2.
- Покажи пользователю список целиком, пометив те, чей хэш разошёлся, и спроси один раз на всю группу: «Удалить инструкции по развёртыванию? Они больше не нужны, но в
INTEGRATION.md лежит единственное описание установки на второй машине».
- Да — удали файлы с совпавшим хэшем; по каждому разошедшемуся спроси отдельно, показав дифф (
git show HEAD:"<путь>"), как в шаге 2.
- Нет — оставь всё и просто сообщи об этом.
Файлы из этой группы упоминаются в лестнице задач: tasks.md несёт задачу «пройти INTEGRATION.md» со ссылками на README. Если группу удалили — почини эти строки в шаге 5.
4. Предложить удалить файлы, нужные только базе
Отдельным шагом, с явным подтверждением: пути из baseOnly нужны для разработки самой базы и бесполезны в личном vault — тесты, CI, git-хуки, конфиг changelog.
Каждая запись baseOnly — это либо файл (cliff.toml), либо каталог (tests, .githooks, .github); список их не различает. Определяй тип на месте: каталог удаляй рекурсивно, файл — как файл. Если пути нет вовсе — пропусти молча, это не ошибка.
Спроси прямо: «Планируешь присылать улучшения обратно в obsidian-agent-workspace?»
- Да — оставь всё, просто сообщи, что оставил.
- Нет — удали пути из
baseOnly, предупредив, что вместе с ними уйдёт npm test.
Каталог scripts/ целиком не удаляй: install-obsidian-plugins.sh / .ps1 и gen-skills-list.mjs полезны и в личном vault. Отдельные файлы из scripts/, перечисленные в baseOnly, — это скрипты релиза самой базы, они уходят вместе с группой.
5. Проверить, что демо не осталось в ссылках
grep -rn "Обустройство vault" --include="*.md" --exclude-dir=demo-content-delete .
Если в шаге 3 удалялись setupDocs, поищи ещё и ссылки на них — но только в содержимом vault, не в скиллах:
grep -rn "INTEGRATION\|\[\[README" --include="*.md" --exclude-dir=skills --exclude-dir=.claude .
Упоминания внутри skills/ и .claude/ не трогай: это инструкции на случай, когда файл на месте, а не ссылки из заметок.
В tasks.md найдётся две первые задачи лестницы — «Прочитать README» со ссылками ru/en и «Настроить vault под себя: пройти INTEGRATION.md» с подзадачей про удаление демо. К моменту, когда ты запускаешь этот скилл, обе уже выполнены: README прочитан, адаптация пройдена, демо удаляется прямо сейчас. Закрой их скиллом close-task, а не вычищай ссылки руками — так они попадут в дневной лог, как любая другая закрытая задача.
--exclude-dir=demo-content-delete исключает сам этот SKILL.md — он неизбежно упоминает название демо-заметки и эти же грep-команды в собственном тексте, и это не следы забытого демо, а инструкция, которая тебе ещё нужна до шага 6. Совпадения внутри путей из baseOnly (например, tests/) тоже не в счёт — их судьбу ты уже решил в шаге 4, будь то удаление или осознанное сохранение как дев-документации базы. Всё остальное найденное — недоделанная работа: на удалённые файлы ссылаются другие заметки vault. Битые wikilinks исправь или убери, задачу «пройти INTEGRATION.md» в tasks.md либо закрой, либо сними ссылку.
6. Удалить себя и манифест
Последним действием, и обязательно в этом порядке — манифест первым, каталог скилла вторым. Так прерывание между под-шагами остаётся понятным: манифест пропал, а skills/demo-content-delete/ ещё жив → шаг 1 при следующем запуске это распознает и доделает хвост. Если удалить в обратном порядке, прерывание сразу после удаления каталога скилла лишает возможности запустить его повторно — а манифест и Skills list.md так и останутся не приведены в порядок, и починить это можно будет только руками: сам скилл больше не сможет.
- Удали
demo-manifest.json.
- Удали каталог
skills/demo-content-delete/.
- Приведи в порядок
skills/Skills list.md — в нём осталась строка про этот скилл. Если на месте и scripts/gen-skills-list.mjs, и Node, перегенерируй: node scripts/gen-skills-list.mjs. Node на клиенте не обязателен, поэтому его отсутствие — не ошибка: просто убери строку про demo-content-delete из списка руками.
- Покажи пользователю итог: что удалено, что оставлено по его просьбе, что он правил руками.
Не коммить изменения сам — покажи git status и предложи закоммитить.
Связанные скиллы
obsidian-vault — конвенции vault, которые останутся после чистки.
new-task, worklog — первое, чем стоит воспользоваться на пустом vault.