Universal Atomizer

---
name: universal-atomizer
description: >
  [STATUS: confirmed] [CONFIDENCE: medium] [REVIEWED: 2026-07-24]
  Универсальная атомарная декомпозиция ЛЮБОГО документа/проекта (статья, код, бизнес-план,
  договор, переписка) на утверждения, определения, гипотезы, допущения, формулы, процедуры,
  данные, параметры, ограничения, отрицательные результаты, решения и открытые вопросы —
  БЕЗ проверки истинности (режим EXTRACTION_ONLY по умолчанию). Строит граф зависимостей и
  6 обязательных реестров. Отличает "чёткость формулировки" от "истинности" — две разные оси.
  НЕ дублирует /atomize (только software-проекты, кончается executable /goal),
  /boyko-method (полный цикл с фальсификацией) и /claim-decomposer (одно utterance, не документ).
  Triggers: /universal-atomizer, /uatomize, "разбери документ на атомы", "извлеки все claims",
  "составь реестр утверждений", "атомизируй статью/договор/бизнес-план", "покажи граф
  зависимостей документа", "карта содержания", "не проверяй, просто разбери".
  НЕ для: software-проектов с целью найти bottleneck (→ /atomize), полного цикла с
  фальсификацией (→ /boyko-method), одного отдельного utterance (→ /claim-decomposer),
  систематического обзора литературы (→ /academic-research).
effort: high
tokens: ~1200
triggers: [/universal-atomizer, /uatomize, "разбери документ на атомы", "извлеки все claims", "составь реестр утверждений", "атомизируй статью", "атомизируй договор", "атомизируй бизнес-план", "покажи граф зависимостей документа", "карта содержания", "не проверяй, просто разбери"]
---

<!-- BSV — Brief Skill View | поиск: BSV
Скил   : universal-atomizer
TL;DR  : Любой документ → атомы (32 типа) + 6 реестров + граф зависимостей, БЕЗ проверки истины
Вызов  : /universal-atomizer, /uatomize, "разбери документ на атомы", "извлеки все claims"
НЕ для : software-проектов (→ /atomize), полного цикла с фальсификацией (→ /boyko-method),
         одного utterance (→ /claim-decomposer)
Выход  : Markdown-отчёт (обязательно) + JSON-граф зависимостей (опционально, для сложных объектов)
-->

# Universal Atomizer — универсальная атомарная декомпозиция

## Зачем

Любой сложный материал — статья, кодовая база, бизнес-план, договор, длинная переписка —
кажется непроверяемым целиком, потому что никто не разложил его на минимальные,
независимо проверяемые единицы. Этот скилл делает ровно одно: превращает материал в
карту содержания — что утверждается, чем это обосновано внутри материала, от чего
зависит и что не проверено. **Не выносит вердикт об истинности** — это сознательное
ограничение, не недоработка (см. No-Verification-Leak Gate ниже).

**Уникальное покрытие** (чего нет в родственных скилах):
- Универсальность типа материала (статья/код/бизнес/договор/переписка) — не только software
- Отдельная ось «чёткость формулировки источника» vs «истинность» (не путать!)
- Formula/Numbers как отдельные обязательные реестры с ролью (fitted/derived/measured/assumed)
- 3 явных режима строгости, с EXTRACTION_ONLY как безопасным дефолтом
- Domain-варианты полей извлечения под 4 типа материала

## Companion Skills — где заканчивается этот скилл и начинается другой

| Скил | Когда вместо этого | Ключевое отличие |
|---|---|---|
| `/atomize` | Software-проект, нужен bottleneck и executable `/goal` | Кончается действием, не картой содержания |
| `/boyko-method` | Нужна ещё и фальсификация гипотез (5-этапный полный цикл) | Атомизация там — только Этап 1 из 5; этот скилл — детальная замена именно этого этапа для документ-объектов |
| `/claim-decomposer` | Один конкретный tricky utterance/claim, не целый документ | Строит Contradiction Matrix для одного утверждения, не реестры для целого документа |
| `/academic-research` | Нужен систематический обзор ЛИТЕРАТУРЫ (несколько источников) | Этот скилл — один материал вглубь, не много источников вширь |
| `/execution-enforcer` | После атомизации нужен реальный commit/test/artifact | Этот скилл сознательно НЕ производит действие — только карту |

**Если объект — software-проект и цель — найти следующее действие → `/atomize`, не этот скилл.**

---

## Режимы работы (выбери ДО начала анализа)

### 1. EXTRACTION_ONLY (дефолт, если режим не указан явно)

Только извлечение и структурирование. Запрещено:
- оценивать истинность утверждения;
- искать внешние источники;
- добавлять собственную критику;
- исправлять автора без отдельного запроса;
- превращать отсутствие доказательства в опровержение.

### 2. EXTRACTION_PLUS_INTERNAL_AUDIT

Дополнительно к EXTRACTION_ONLY искать (без внешних источников):
- внутренние противоречия между атомами;
- неявные допущения;
- циклические зависимости;
- подмену результата интерпретацией;
- один источник, использованный одновременно для калибровки и проверки;
- отсутствующее промежуточное звено;
- изменение определения между разделами.

### 3. FULL_VERIFICATION (только по явному запросу)

Добавляет внешнюю проверку, поиск первоисточников, независимые вычисления, проверку формул,
итоговый статус PASS/FAIL/UNRESOLVED. **На этом этапе делегируй `skeptic`/`falsification-ladder`
— этот скилл сам верификацию не изобретает**, ровно как `/boyko-method` делегирует Этап 5.

---

## Шаг 0 — Intake + Scope Lock (обязательно до старта)

Зафиксируй явно, прежде чем атомизировать что-либо:

```
ОБЪЕКТ: <название документа/проекта/материала>
ПОКРЫТИЕ: <весь материал или конкретный фрагмент — укажи страницы/разделы>
ТИП МАТЕРИАЛА: научная статья / код / бизнес-план / договор / переписка / другое
ЯЗЫК ОРИГИНАЛА: <язык>
РЕЖИМ: EXTRACTION_ONLY (дефолт) / EXTRACTION_PLUS_INTERNAL_AUDIT / FULL_VERIFICATION
ФОРМАТ ВЫВОДА: Markdown (всегда) [+ JSON-граф зависимостей — если объект сложный, ≥15 атомов]
```

Если доступна только часть материала — обязательно написать открыто:

> Анализ полностью покрывает доступный фрагмент, но не является атомизацией полного документа.

---

## Атомарность — что считается одним атомом

Атом = один проверяемый тезис. Спрашивай для каждой строки:

> Можно ли опровергнуть одну часть этой строки, оставив другую истинной?

Если да — разделить (это и есть **Atomicity Gate**, см. ниже).

**Обязательно разделять**, если в строке одновременно:
метод и результат · результат и интерпретация · fit и independent prediction ·
данные и интерпретация · калибровка и проверка · формула и физический смысл ·
число и вывод из него · локальный результат и глобальный headline · факт и авторская
интерпретация · причинная цепочка из ≥2 переходов · союз «и», соединяющий два claims.

**Исключение — таблица данных с единой схемой** (напр. results-таблица бенчмарка, таблица
измерений): регистрируется как ОДИН атом `DATA_INPUT`/`MEASUREMENT`, указывающий на
местоположение таблицы, а не как один атом на ячейку. Atomicity Gate применяется к *claims
о таблице* (производные счётчики, сравнения, интерпретации), а не к сырым ячейкам — иначе
таблица 10×3 превращается в 30+ бессмысленных атомов.

**Нумерованные нормативные требования с прикреплённым обоснованием — НЕ исключение.**
Пункт вида «1. Требуется X, потому что Y» (частая форма в спецификациях, чек-листах,
rubric-документах) — это не единый атом просто потому что у него один номер в списке.
Применяй тот же тест: можно ли опровергнуть Y (обоснование), оставив X (требование)
истинным? Если да — разделить на ≥2 атома (требование + его обоснование/интерпретация),
даже если оригинальный документ подаёт их одной нумерованной строкой. Нумерация в
исходнике задаёт порядок изложения, а не границу атома.

**Пример неправильной строки:**
> Модель строит историю расширения Вселенной и лучше согласуется с данными, потому что
> учитывает тепловую энергию.

**Правильное разбиение:**
- C-001: Модель задаёт процедуру построения H(z).
- C-002: Значения параметров подобраны по наблюдательным данным.
- C-003: Fit сравнивается с альтернативной моделью.
- C-004: Автор связывает форму нового члена с тепловой энергией.
- C-005: Причинная связь между новым членом и улучшением fit заявляется отдельно от C-004.

---

## Типы атомарных элементов (назначь ровно один на элемент)

**Содержание:** TITLE_CLAIM · BACKGROUND · DEFINITION · GOAL · REQUIREMENT · FACT_REPORTED ·
HYPOTHESIS · ASSUMPTION · MODEL_CHOICE · CONVENTION · FORMULA · DERIVATION_STEP · PROCEDURE ·
ALGORITHM · DATA_INPUT · PARAMETER · CALIBRATION · FIT_RESULT · MEASUREMENT · COMPARISON ·
INTERPRETATION · CAUSAL_CLAIM · PREDICTION · EXTRAPOLATION · LIMITATION · NEGATIVE_RESULT ·
FAILURE · RISK · DECISION · OPEN_QUESTION · FUTURE_WORK · PROVENANCE.

**Роль в документе** (не путать с истинностью!): AUTHOR_STATED · DEFINED_IN_DOCUMENT ·
DERIVED_IN_DOCUMENT · ASSUMED_IN_DOCUMENT · FITTED_IN_DOCUMENT · MEASURED_ELSEWHERE ·
CITED_FROM_SOURCE · ILLUSTRATIVE · DIAGNOSTIC · LIMITATION_ACKNOWLEDGED · FAILED_IN_DOCUMENT ·
PLANNED · UNKNOWN_OR_UNSPECIFIED.

**Источник сам заявляет о собственной проверке** (частый паттерн и в статьях, и в коде —
«verified by tabulating all 12 files», «confirmed via git show», «fetched directly twice»):
извлекать как обычный `FACT_REPORTED`/`AUTHOR_STATED`, ничего не переисполняя. Такое
самозаявление НЕ повышает «Чёткость формулировки» атома и НЕ равносильно тому, что атомизатор
сам это перепроверил — это по-прежнему EXTRACTION_ONLY. Если позже запросят FULL_VERIFICATION
(режим 3 выше) — именно эти самозаявленные проверки перепроверять первыми, они самая дешёвая
и самая частая точка расхождения между «автор сказал, что проверил» и «проверено на самом деле».

---

## Обязательные выходные реестры (Markdown, в этом порядке)

### A. Реестр утверждений

| Claim ID | Стр./раздел | Объект | Тип | Атомарное утверждение | Основание в документе | Формула/таблица/рисунок | Зависимости | Область применимости | Авторская оговорка | Роль | Чёткость формулировки |
|---|---|---|---|---|---|---|---|---|---|---|---|

**Чёткость формулировки** — HIGH/MEDIUM/LOW про то, **насколько ясно атом сформулирован
в источнике**, а НЕ про то, насколько он вероятно истинен. Атом может быть сформулирован
предельно чётко (HIGH) и оказаться ложным, или быть смутно намекнут (LOW) и оказаться верным.
Путать эти две оси — типичная ошибка: «звучит уверенно» ≠ «доказано».

**Если атом сам по себе является числом** (например, «κ=0.565») — не заполняй для него
отдельную оценку Роли в реестре A. Полная роль такого атома (fitted/derived/measured/assumed)
живёт ТОЛЬКО в реестре C; в реестре A для колонки «Роль» пиши `см. Value ID <X>`. Не дублировать
и не переизобретать роль дважды в двух реестрах разными словами.

### B. Реестр формул

| Formula ID | Стр. | Формула | Название | Переменные | Роль | Как вводится | Зависимости | Что вычисляет | Область | Оговорка | Claim ID |
|---|---|---|---|---|---|---|---|---|---|---|---|

Формула и её физическая интерпретация — **разные** элементы, никогда не сливать в один атом.

### C. Реестр чисел, параметров и данных

| Value ID | Стр. | Источник | Объект | Параметр/метрика | Значение | Единицы | Погрешность | Диапазон | Роль | Где используется | Оговорка |
|---|---|---|---|---|---|---|---|---|---|---|---|

**Роль каждого числа — одна из четырёх** (не смешивать fitted-параметр и independent
prediction в одной строке):
- `fitted` — подобран под данные (не имеет самостоятельной предсказательной силы для тех же данных);
- `derived` — выведен аналитически из других величин по формуле;
- `measured` — независимое измерение вне контекста подгонки;
- `assumed` — взят как допущение без вывода и без измерения.

Не объединять несколько чисел в одну ячейку, если у них разные роли.

### D. Реестр допущений и неизвестного

Явные допущения · неявные, но необходимые допущения · неизвестные величины ·
отсутствующие определения · непредъявленные промежуточные шаги · внешние зависимости ·
части, оставленные для будущей работы.

### E. Граф зависимостей

| Edge ID | From | Relation | To | Meaning | Source |
|---|---|---|---|---|---|

Допустимые типы связи: USES · REQUIRES · DEFINES · DERIVES · SUPPORTS · CALIBRATED_ON ·
TESTED_ON · COMPARED_WITH · NORMALIZED_BY · ASSUMES · INTERPRETS · LIMITS · CONTRADICTS ·
FAILS_AGAINST · SUPERSEDES · MOTIVATES · BLOCKS · PLANNED_TO_RESOLVE.

**JSON-компаньон (опционально):** тот же граф как
`{"nodes": [{"id": "...", "type": "..."}], "edges": [{"from": "...", "relation": "...", "to": "..."}]}`
— сохранить рядом с Markdown-отчётом как `<object-slug>-graph.json`. Триггер — **плотность
графа, не количество атомов**: считай средний branching factor (рёбер / узлов). Если ≥1.5
(узлы плотно кросс-связаны — типично для причинных цепочек или взаимных зависимостей) — JSON
оправдан, диффы между прогонами и визуализация реально нужны. Документ с 45 атомами, но
преимущественно линейными цепочками (branching ~1.0-1.2), не выигрывает от JSON больше, чем
таблица реестра E — не генерируй JSON только потому что атомов много. Весь остальной отчёт
всегда остаётся Markdown (конвенция репозитория).

### F. Таблица ограничений и отрицательных результатов

Не прятать внутри основного текста. Для каждого: что ограничено · область · что остаётся
действительным · что больше нельзя заключать · признано ли автором · влияет ли на headline
claim · предлагаемый автором следующий шаг.

### G. Отчёт о полноте покрытия

Страницы/разделы — утверждения — формулы — числовые элементы — зависимости — ограничения,
плюс явное указание, что НЕ вошло в анализ.

---

## Обязательный граф ключевой цепочки

```
Данные / гипотезы → Определения и допущения → Формулы / алгоритмы → Параметры и калибровка
  → Промежуточные результаты → Сравнение или тест → Итоговый claim → Ограничения и открытые вопросы
```

Каждая стрелка обязана иметь соответствующее ребро в реестре E.

---

## Domain-варианты (дополнительные поля по типу материала)

| Тип материала | Дополнительно извлекать |
|---|---|
| Научная статья | headline claims · исследовательский вопрос · выборка/данные · likelihood/loss · baseline · fit · validation · extrapolation · uncertainties · negative results · future work |
| Программный проект | требования · компоненты · API · входы/выходы · инварианты · зависимости · состояния · ошибки · тесты · security assumptions · deployment decisions · технический долг |
| Бизнес-проект | проблема клиента · ценностное предложение · рыночные допущения · unit economics · прогнозы · риски · решения · зависимости от партнёров · критерии успеха · условия остановки |
| Договор/нормативный текст | стороны · определения · обязательства · права · условия · исключения · сроки · штрафы · триггеры · прекращение · противоречащие положения · внешние нормы |

**Гибридный материал** (напр. research-отчёт внутри software-репозитория, ссылающийся на
коммиты/хуки: сам объект — не чисто «статья» и не чисто «код»): разрешено комбинировать поля
из ≥2 строк таблицы. Не форсировать единственный выбор, если материал по сути пересекает
типы — иначе часть содержания (напр. baseline/validation ИЛИ технический долг) останется
неизвлечённой только потому, что не подошла под выбранную строку.

---

## Обязательные gates (перед завершением)

### Atomicity Gate
Для каждой строки: можно ли опровергнуть одну часть, оставив другую истинной? Если да — разделить.

### Traceability Gate
Каждый claim имеет: номер страницы/раздела + внутреннее основание + источник, ИЛИ одну из
двух ЯВНО РАЗНЫХ пометок — не путать их:
- «основание не указано» — автор нигде не обосновал claim, это реальный пробел источника;
- «внешняя зависимость вне зафиксированной области» — обоснование существует в реальном,
  названном файле/источнике (напр. `utils.py`, импортируемый, но не входивший в ПОКРЫТИЕ на
  Шаге 0) — это НЕ дефект материала, а следствие сознательно суженного scope анализа.

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

Внутри «внешняя зависимость вне зафиксированной области» встречаются два разных случая —
не разводи их на отдельные статусы (это не отдельный gate), но помечай явно, какой из двух:
(a) claim ОПРЕДЕЛЯЕТСЯ через понятие/механизм, живущий во внешнем файле (напр. C-018 ссылается
на формат парсинга Gate 10) — сам механизм не оспаривается, просто не в scope; (b) claim
УТВЕРЖДАЕТ конкретный ТЕКУЩИЙ факт о состоянии внешнего файла (напр. «навык сейчас записан
как X в registry.yaml») — этот факт НЕ проверен в рамках текущего запуска и может устареть
независимо от корректности исходного документа. (b) требует одного слова в оговорке —
«не проверено в этом запуске» — (a) не требует.

### Formula Coverage Gate
Число зарегистрированных формул = число содержательных формул в области анализа.

### Limitation Preservation Gate
Ни одна авторская оговорка не должна исчезнуть при сокращении.

### Dependency Completeness Gate
Каждый headline claim имеет путь до: данных, формул, допущений, процедур, результатов.

### No-Verification-Leak Gate
В режиме EXTRACTION_ONLY запрещены формулировки, выдающие вердикт об истинности раньше
времени: «это верно» / «это ошибочно» / «теория доказана» / «модель опровергнута» /
«автор неправ». Допустимо только: «автор утверждает» / «в документе основано на» /
«основание не указано» / «атом зависит от» / «автор ограничивает область».

---

## Процесс выполнения (11 шагов)

1. **INTAKE** — что анализируется, полный ли материал, какой режим, какой выход нужен
2. **SCOPE_FREEZE** — страницы, разделы, версии, приложения
3. **STRUCTURE_MAP** — карта документа: разделы, таблицы, рисунки, формулы, приложения, код
4. **FIRST_PASS_EXTRACTION** — извлечь все явные элементы без объединения
5. **ATOMICITY_SPLIT** — расщепить составные тезисы (Atomicity Gate)
6. **TYPE_ASSIGNMENT** — назначить тип + роль каждому элементу
7. **SUPPORT_LINKING** — внутреннее основание для каждого тезиса
8. **DEPENDENCY_MAPPING** — рёбра между claims, формулами, данными, результатами
9. **LIMITATION_SWEEP** — целевой проход на «однако/ограничение/не решено/предполагаем/не
   выведено/будущая работа/экстраполяция/провал/приближённо/иллюстративно» (и англ. эквиваленты
   — включая явные негативные конструкции, не только хеджирующие слова: «does not show/establish»,
   «not claimed», «this does NOT mean», «не показывает», «не заявляется» — многие технические
   материалы формулируют ограничения как отдельный явный раздел с отрицанием, а не хеджами)
10. **COVERAGE_AUDIT** — каждая формула зарегистрирована, каждая таблица разобрана, каждый
    рисунок имеет claims, ограничения не потеряны, headline связан с зависимостями
11. **OUTPUT** — все 7 реестров (A-G) + карта главной цепочки

---

## Условия остановки

Работа завершена, когда: разобрана вся зафиксированная область · каждому элементу присвоен
ID · все формулы и числа зарегистрированы · все ограничения вынесены отдельно · headline
claims связаны с основаниями · выполнен coverage audit · явно указано, что не вошло в анализ.

**Не считать работу завершённой только потому, что создано много строк.**

---

## Универсальная команда запуска

```
Разбери <объект> с помощью universal-atomizer. Режим: EXTRACTION_ONLY.
Не проверяй истинность и не используй внешние источники. Раздели материал на атомарные
утверждения, определения, гипотезы, допущения, формулы, процедуры, данные, параметры,
результаты, интерпретации, ограничения, отрицательные результаты, решения и открытые вопросы.
Выдай все 7 обязательных реестров (A-G) + карту главной цепочки + отчёт о полноте покрытия.
```

---

## Критерий хорошего результата

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

---

💡 TIP: запускай в режиме EXTRACTION_ONLY по умолчанию — переходи в EXTRACTION_PLUS_INTERNAL_AUDIT
только если нужны противоречия, и в FULL_VERIFICATION только по явному запросу пользователя.

╔═ ⚡ УРОК ══════════════════════════╗
  «Чёткость формулировки» (HIGH/MEDIUM/LOW) и evidence-метки истинности
  ([VERIFIED]/[INFERRED]/[WEAK]) — ортогональные оси. Самая опасная
  комбинация: HIGH clarity + отсутствие evidence-метки — звучит уверенно,
  но никем не проверено. Именно её чаще всего путают с «уже доказано».
╚════════════════════════════════════╝

---

*Version: 1.0.2 — построен 2026-07-24 на основе внешнего "Universal Project Atomizer" (721
строка, EXTRACTION_ONLY/+AUDIT/FULL_VERIFICATION режимы, 32 типа атомов), адаптирован под
конвенции этого репозитория: companion-skills disambiguation, evidence-marker consistency
с `integrity.md`, No-Verification-Leak формулировки в стиле `boyko-method` v1.4.0, Markdown-
first вывод + опциональный JSON только для графа зависимостей (не для всего отчёта).
1.0.1 — дымовой прогон против `benchmarks/strong-inference/run-2026-07-23-full.md` (~45
атомов, реальный формула+числа+ограничения объект) нашёл и закрыл 5 пробелов: атомарность
таблиц данных, JSON-триггер по плотности графа (не по числу атомов), гибридные типы материала,
дублирование Роли между реестрами A/C, расширенный LIMITATION_SWEEP keyword-список.
1.0.2 — второй дымовой прогон, теперь на принципиально другом типе объекта:
`hooks/agent_tool_scope_guard.py` (код с security-логикой, не research-текст). Тип-таксономия
и Domain-варианты подтвердились без правок (PROCEDURE/ALGORITHM/PARAMETER/CONVENTION/RISK
покрыли код без зазоров). Нашёл и закрыл 2 новых пробела: (1) источник сам заявляет о своей
проверке («verified by tabulating...») — теперь явно не повышает Чёткость и не подменяет
EXTRACTION_ONLY; (2) Traceability Gate путал «основание не указано» с «обоснование есть, но
в реальном файле вне зафиксированной области» — разведены на два явных статуса. Также дал
реальную находку об объекте (не о скилле): security-гарантия хука нигде не оговаривает,
что `agent_type` от платформы доверенный/неподделываемый — годная демонстрация того, что
Реестр D действительно ловит невысказанные допущения, не только на физике/статистике.*
1.0.3 — третий дымовой прогон, впервые НЕЗАВИСИМЫЙ/blind (свежий агент без контекста
написания скилла, только SKILL.md + объект), на третьем типе объекта: `docs/skill-maturity-criteria.md`
(прескриптивная рубрика, не код и не research-текст). Type-таксономия и domain-hybrid
подтвердились без правок. Нашёл и закрыл 2 новых пробела: (1) atomicity-правило не
покрывало явно нумерованные нормативные требования с прикреплённым обоснованием
(«1. X, потому что Y») — добавлено явное правило, что нумерация не заменяет atomicity-тест;
(2) Traceability Gate's «внешняя зависимость вне зафиксированной области» смешивала два
случая (claim определяется через внешний механизм vs. claim утверждает текущий факт о
внешнем файле, не проверенный в этом запуске) — разведены без создания нового статуса.
Это первый прогон, удовлетворяющий Independent Verification Strength Ladder
(`rules/falsification-ladder.md`) на уровне выше "same model, same context".