# Razbor Bardaka

> «Наведи порядок в заметках», «разбери бардак в закладках», «систематизируй коллекцию промптов», «упорядочи файлы, свалка», «разложи по папкам». Карта до перекладки.

- Skill: `kir-kopylov/razbor-bardaka` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add kir-kopylov/razbor-bardaka`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/razbor-bardaka/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kir-kopylov (https://skillmd.com/u/kir-kopylov)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kir-kopylov/razbor-bardaka

---


# Разбор Бардака (экспериментальный)

## Запуск Навыка

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

Применяю экспериментальный навык **«Разбор информационного беспорядка»** (обратная связь — @kir-kopylov): <кратко назовите конкретную пользу для текущего запроса>; продолжаю без ожидания.

Не включайте в строку `author_github`, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.

Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.

## Обзор

Skill превращает свалку (файлы, заметки, закладки, промпты, что угодно) в понятную структуру папок, в которой владелец находит нужное за секунды. Ничего не перекладывает и не удаляет без явного «да».

Общайтесь с владельцем простым языком, без жаргона: «структура папок», а не «таксономия»; «файл-задание», а не «handoff».

Три факта, на которых построен процесс:

1. **Названия папок врут.** Владелец копил годами; папка «недвижимость» может содержать заметку про объяснение слов. Классифицируйте по лучшему доступному сигналу самого объекта, никогда — по имени папки.
2. **Правильная структура живёт в голове владельца, а не в данных.** Кластеризация по содержимому даёт «логичную» схему, которой неудобно пользоваться. Ось структуры — то, что владелец ПОМНИТ, когда ищет вещь. Это узнаётся только вопросом и проверяется только на его реальных объектах.
3. **Половина смертей таких задач — необратимое действие или сломанная синхронизация.** Поэтому до финального «да» — только чтение; перекладка — отдельная фаза с пробой на одном объекте.

## Фаза 1 — Разведка (до любых вопросов владельцу)

Сначала инструментами, потом вопросами: разведка обычно снимает половину вопросов и находит жёсткие ограничения.

1. Определите канал доступа к данным. Сначала штатный: файловая система напрямую, экспорт, API, AppleScript. Только если штатного нет — файлы/база приложения (на macOS обычно `~/Library/Containers/<bundle-id>/` или `~/Library/Application Support/`). Базу или единый файл-хранилище скопируйте и анализируйте копию; обычную папку с файлами не копируйте — фазы 1–4 только читают.
2. Посчитайте корпус: сколько объектов, сколько текущих папок (если есть), какие типы (текст, картинки, бинарники, ссылки, пустые).
3. Проверьте жёсткие ограничения ДО проектирования структуры:
   - Вложенные папки поддерживаются? (видно в интерфейсе или документации; для баз — по parent-полю в схеме). Плоское хранилище → иерархию эмулировать префиксами имён ПАПОК: «Домен · Подтема». Если папок нет вообще — переименование самих объектов возможно только как отдельно согласованный механизм, показанный на карте.
   - Есть ли синхронизация с облаком или аккаунтом (iCloud/CloudKit, синхронизация браузера, облачный диск)? Синхронизируемое хранилище меняется только штатным механизмом — интерфейс приложения, API, AppleScript. Запись в его файлы/базу напрямую запрещена всегда: порча синка проявляется асинхронно и на других устройствах, «удачная проба» ничего не доказывает.
4. Прочитайте выборку объектов из разных частей корпуса (разных папок, если есть, иначе — разных типов и дат) — она покажет реальный разброс тем и проверит, врут ли имена.

## Фаза 2 — Вопросы Владельцу

Проверку проводи внутренне; пользователю не показывай вероятные ответы и карту изменений.

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

Каждый вопрос обязан менять результат; вопросы «для полноты» запрещены. Формат — один вопрос за ход. После ответа заново выберите ближайший вопрос; живые примеры показывайте по одному. Самые важные первыми:

1. **Ось поиска:** «Когда вы ищете вещь в этой коллекции — что вы о ней помните в первую очередь?» (тему/задачу, тип действия, инструмент, время). Это верхний уровень структуры.
2. **Живые примеры (обязательно):** подготовьте до 3 реальных объектов из разных частей корпуса и показывайте по одному: «вот это — куда должно лечь?» После каждого ответа проверьте, изменит ли следующий пример структуру; если нет — не спрашивайте. Полученные ответы становятся контрольными проверками результата. Абстрактно спрашивать бесполезно — владелец сам не знает свою ось, пока не увидит конкретную вещь.
3. **Судьба дублей и мусора:** по умолчанию — отдельный список кандидатов с причинами, ничего не удалять. «Устаревшее» попадает в список только по критерию, который назвал сам владелец; без критерия — не включать.
4. **Периметр:** что входит в разбор, а что нет (например, история буфера обмена — не сохранённые шаблоны; вложения — не заметки).

«Не знаю» — допустимый ответ: запишите пробел в `ASSUMPTIONS.md` и отразите обе трактовки в двух вариантах структуры (например, разная ось верхнего уровня в крупном и подробном) — владелец выберет глазами на карте.

## Фаза 3 — Раскладка На Бумаге

Всё в отдельной папке проекта (в рабочей директории пользователя, не в Downloads), под git с коммитами после каждого зелёного состояния.

Артефакты:

- `inventory.csv` — каждый объект: стабильный идентификатор (id из базы, полный путь или URL — сырой локатор живёт только здесь), текущая папка (если есть), имя, тип, дата, выдержка. Полные тексты — в `items/<file_id>.txt`, только для текстовых объектов; `file_id` — производное безопасное имя файла (короткий hash или slug от идентификатора), а не сырой путь/URL: слэши и двоеточия в имени ломают запись или уводят файл из папки `items/`.
- Два варианта структуры: **крупный** (≤10 папок) и **подробный** (10–20, через префиксы «Домен · Подтема»). Для каждой папки — критерий включения одной строкой + счётчик.
- `mapping.csv` — КАЖДЫЙ объект приписан к папке в обоих вариантах. Без пустых мест.
- `kill_list.csv` — дубли (точные и почти-копии: `file (1).ext`, одинаковые URL, итерации одной вещи — новейшая как основная, ранние в список, выбор пометить как допущение), устаревшее (только по критерию владельца), нечитаемое. С причинами. Объекты остаются в mapping.
- Проверочный скрипт: количество в mapping = количеству в inventory; пустых папок нет; живые примеры владельца легли туда, куда он сказал.

Правила классификации:

- Ось — как владелец ИЩЕТ и ИСПОЛЬЗУЕТ, не буквальное содержание (промпт-приём «решай как первокурсник» лежит в «Учёбе», потому что применяется там).
- Сигнал для классификации: текст — содержимое; бинарники — тип, метаданные, беглый просмотр; ссылки — URL и заголовок. Имя объекта — подсказка, не истина.
- Объекты без явной темы (приёмы, стили, мета) → свой домен, не размазывать по «Прочее».
- Сомнение между двумя папками → решить по ответам владельца на живых примерах и оси поиска; если сигнала нет — выбрать один следующий вопрос или положить объект в более крупный домен, записав допущение в `ASSUMPTIONS.md`.
- Большой корпус — батчами по ~30 с записью на диск после каждого, чтобы не держать всё в голове.

**Повторный разбор той же коллекции:** не пересчитывайте всё — сверьте живой корпус с прошлым `mapping.csv`, классифицируйте только новое, удалённое выкиньте из артефактов, прошлые решения не трогайте. Так сохраняются ручные правки владельца.

## Фаза 4 — Наглядная Карта (до любых перемещений)

Владелец должен УВИДЕТЬ будущую раскладку и утвердить её глазами. Сделайте интерактивную HTML-карту (домены → папки-аккордеоны → объекты с пометкой «из какой старой папки», метки «новый»/«дубль» с причиной, поиск) и продублируйте скелет структуры текстом прямо в ответе. Явно скажите: «это предложение, в хранилище ничего не тронуто».

## Фаза 5 — Перекладка (только после явного «да» на конкретный вариант)

«Да» может прозвучать в той же сессии, где показана карта, — этого достаточно; без «да» не начинать никогда.

0. **Гейт актуальности:** свежая резервная копия хранилища + сверка живого корпуса с inventory. Появившееся с момента снимка — доклассифицировать (или спросить владельца) ДО перемещений; иначе «каждый объект приписан» уже неправда.
1. Выберите механизм: для синхронизируемых хранилищ — только интерфейс приложения или официальный API/AppleScript; для локальных без синхронизации — допустима и прямая работа с файлами/базой, но гипотезу безопасности проверяйте пробой, а до пробы считайте её ложной.
2. **Проба на одном объекте:** переместите ОДИН; перезапустите приложение (если объекты живут в приложении) или обновите листинг; проверьте — объект на месте, не задвоился, а при наличии синхронизации изменение дошло до облака (веб-версия или второе устройство, если доступны; иначе — статус/логи синка после полного цикла).
3. Проба красная → стоп: не пробуйте молча другой механизм, откатите единственный объект тем же способом, доложите владельцу.
4. Проба зелёная → остальное батчами со сверкой после каждого.
5. Удаление старых пустых папок и объектов из kill-list — только после того, как владелец видел состав списка на карте; точные дубли и «устаревшее/почти-копии» подтверждаются отдельными «да».

Если работа передаётся в другую сессию — соберите файл-задание (цель, done-критерии, запреты, пути, проба-гейт, контрольные примеры) рядом с артефактами.

## Границы

- Не верить названиям папок; объект судить по его лучшему доступному сигналу.
- Не удалять и не редактировать объекты без отдельного «да» на просмотренный владельцем список.
- Не писать напрямую в файлы/базы синхронизируемых хранилищ — ни в работе, ни «на пробу».
- Не заполнять пробелы догадками («скорее всего», «обычно») — спросить или пометить пробел.
- Не выдавать один «правильный» вариант структуры — минимум два, выбор за владельцем.
- Не начинать перекладку, пока владелец не увидел карту и не сказал явное «да» конкретному варианту.
- Не для чистки диска ради места, не для задач и обязательств (`vtoroy-mozg`), не для переименования по шаблону.

## Definition Of Done

Владелец видел карту, выбрал вариант, проверочный скрипт зелёный (всё посчитано, ничего не потерялось, контрольные примеры на месте) — и либо перекладка выполнена с пробой-гейтом, либо владелец осознанно остановился на «раскладке на бумаге».

## Опрос После Использования

Опрос задаётся один раз — после сдачи карты владельцу или после завершения перекладки (что случилось последним), не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

```text
Опрос по skill:
1. Что в этом использовании razbor-bardaka было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".
```

Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/razbor-bardaka/usage-feedback.jsonl` — лучше через bundled script:

```bash
python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."
```

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет в JSONL `redaction_applied` и `redaction_types`. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

## Логирование Сбоев

Перед выполнением прочитайте локальный `known-exceptions.yaml` как список уже известных случаев и применяйте подходящее `do_next_time` без нового поиска.

Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в `~/.codex/skill-runs/<skill-name>/exception-log.jsonl`.

Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите `unknown`. Raw logs не коммитить.