---
name: gemini-conversation-to-scientific-doc
description: Превращает ссылки на публичные диалоги Gemini в структурированный научно-исследовательский транскрипт с аналитическими главами и авторской мета-критикой Hermes Agent.
version: 1.3
tags: [gemini, document, research, transcript, scientific]
---

## Когда использовать

Когда пользователь Valentin скидывает ссылки на публичные диалоги Gemini (формата `https://gemini.google.com/share/...`) и просит:
- структурировать в научный документ
- написать «часть 2» / «часть N» к существующей работе
- создать аналитический обзор с критикой
- обновить существующий документ на основе новых диалогов

## Процесс

### 1. Изучение исходного материала

**Проблема:** Публичные страницы Gemini требуют принятия cookies через диалог Google.

**Решение:**
1. `browser_navigate(url)` → принять cookies (`browser_click` на «Принять все»)
2. Не ждать загрузки визуального контента — сразу извлекать через `browser_console`
3. Два метода извлечения:
   - **Точечный (для длинных диалогов):** `querySelectorAll('.conversation-container, [class*="turn"], [class*="message"]')` — собирает реплики по блокам
   - **Сплошной (для коротких/неизвестных):** `document.body.innerText` — берёт весь текст и вырезает от первого «Ваш запрос»

**Важно:** Многие ссылки ведут на один и тот же диалог (Gemini создаёт отдельную share-ссылку при каждом share). Не тратить время на чтение дубликатов — если первые 500 символов совпадают, переходить к следующей.

### 2. Структура итогового документа

Документ наследует формат из файла `gemini_conversation_scientific.md` (папка `~/Desktop/сансанга/`):

```markdown
# [Заголовок — отражает главную тему]

## Аналитический обзор диалога с Gemini (модель X)

**Дата:** ...
**Источники:** [ссылки]
**Тип документа:** Научно-исследовательский транскрипт...

---

## Оглавление
[автоматически генерируется]

---

## 1. Введение
## 2. Методологическая заметка
## 3. Основная часть — транскрипт диалога
   ### 3.1, 3.2, ... (каждый запрос-ответ)
## 4. Ключевые темы и концептуальный анализ
   - Сравнительная таблица
   - Метафоры и модели
   - Архитектура метода
   - Практические протоколы
## 5. Заключение и выводы
## 6. Библиография и источники
## 7+. Приложения (ранние диалоги, дополнительные материалы)
## N-2. Заключительный синтез: Мнение Hermes Agent
## N-1. Главная критика — Где всё ломается
## N. Финальный аккорд
```

### 3. Особенности форматирования

- **Таблицы:** markdown-таблицы для сравнений (учения vs наука, классический vs новый подход)
- **Схемы:** ASCII-диаграммы в code-блоках для архитектуры метода
- **Цитаты:** `>` для ключевых выводов и манифестов
- **Жирный:** для verdict'ов, ключевых терминов, названий концепций
- **Курсив:** для терминов на латинице, научных названий

### 4. Авторские главы Hermes Agent

Три обязательные авторские главы в конце основного документа:

1. **Заключительный синтез** — что я вижу в этом корпусе текстов как едином целом, архитектура мысли пользователя
2. **Главная критика** — режим «адвокат дьявола»: эпистемологические проблемы, физические нестыковки, логические тупики. **Минимум 5 пунктов**, каждый с возможным контраргументом. Формат: проблема → где ломается → вердикт/возможный ответ.
3. **Финальный аккорд** — поэтическое/инженерное резюме. Может содержать ключевую цитату-манифест.

### 4a. Дополнительные артефакты (создаются отдельными файлами)

По результатам работы над документом могут создаваться:

- **Инженерный манифест** (`manifest_*.md`) — отдельный, готовый к публикации документ. Структура: 5 разделов (точка отсчёта → диагноз эпохи → парадокс капитуляции → доктрина → финальный приказ). Без академического формата — чистый манифест на инженерном/морском языке.
- **Практический протокол** (`protocol_*.md`) — ультра-короткий чек-лист (1–2 страницы). Три уровня действий + экстренная версия (30 секунд). Без эзотерики — только работающие алгоритмы.
- **Фил-отчёт Hermes Agent** (`hermes_report.md`) — отдельный документ с честным мнением о проекте: нравится ли, критика, высасал ли себя, что дальше. Формат: 5 разделов (оценка → что работает → критика → потенциал → вердикт).

### 5. Многочастные проекты

Если пользователь просит «часть 2» к существующему документу:

1. Создать новый файл в той же папке (обычно `~/Desktop/сансанга/`)
2. Именование: `part2_[краткое_описание].md`, `part3_*.md` и т.д.
3. В заголовке — явная ссылка на Часть 1: «**Связь с Частью 1:** Прямое продолжение...»
4. В Часть 1 добавить перекрёстную ссылку в колофон: «**Продолжение:** Часть 2 — ... (`part2_*.md`)»
5. Архитектура общая между частями (например, трёхуровневая модель) — явно показывать стыковку в разделе «Ключевые темы»
6. Обновить README.md при появлении новых частей

### 6. Обновление существующих документов

Если пользователь просит «обновить часть 1»:
- Использовать `patch` для точечных правок
- Делать бэкап перед правками: `cp файл.md файл_BACKUP.md`
- Обновлять оглавление при добавлении секций
- Файлы держать в `~/Desktop/сансанга/`

### 7. Визуализация: Mermaid-диаграммы

**Когда создавать:** после завершения основного текста документа, перед финальной сборкой.

**Процесс:**
1. Создать отдельный файл `diagrams_mermaid.md` в папке проекта
2. Для каждой диаграммы:
   - Заголовок `## Диаграмма N: [название]`
   - Блок ` ```mermaid ... ``` ` с кодом диаграммы
3. Рекомендуемые диаграммы для типового проекта:
   - Трёхуровневая архитектура (flowchart с subgraph)
   - Кремниевая/основная космологическая цепочка (flowchart TD с цветными узлами)
   - Фазовый переход / сравнительная схема (graph с двумя subgraph-блоками)
   - Циклы/петли (flowchart LR с обратными стрелками)

**Встраивание в документ через `patch`:**
1. Найти уникальный текстовый якорь рядом с местом вставки (например, конец существующего ASCII-блока ` ``` ` или заголовок секции)
2. Использовать `patch` с `old_string` = существующий текст-якорь, `new_string` = тот же текст + `\n\n` + диаграмма
3. Проверять вставку: `grep -c '```mermaid' файл.md`

**Важно:** Не использовать `execute_code` для вставки диаграмм — `read_file` добавляет номера строк, а `terminal(cat)` обрезает вывод при больших файлах (>50KB). `patch` работает надёжно.

### 8. Git-файл (README)

По запросу создавать `README.md` или `GIT_INFO.txt` в папке проекта с:
- Датами и версиями
- Ссылками на исходные диалоги
- Кратким описанием каждой части
- Состоянием работы (что сделано, что в процессе)
- Дорожной картой (что дальше)

### 9. Сборка единого документа (компиляция всех частей)

Если пользователь просит собрать **один большой документ** из всех материалов:

**Структура единого документа:**
```
# [НАЗВАНИЕ ПРОЕКТА]
## [Подзаголовок]
[Метаданные: автор, дата, модели]
[Эпиграф — ключевая цитата]

## Содержание (краткое — 3-4 пункта)

===============================================================================
# ТОМ I — [НАЗВАВНИЕ]
## [Подзаголовок — тематика]
===============================================================================
[Содержимое Части 1]

--- <p align="center">Конец Тома I</p> ---

===============================================================================
# ТОМ II — [НАЗВАНИЕ]
## [Подзаголовок — тематика]
===============================================================================
[Содержимое Части 2]
[+ Манифест как финальная глава Тома II]

--- <p align="center">Конец Тома II</p> ---

===============================================================================
# ПРИЛОЖЕНИЕ
===============================================================================
[Практический протокол]
[Фил-отчёт Hermes Agent]

[Колофон]
```

**Разделение на тома:**
- **Том I** — ментальные/духовные практики, эзотерика, работа с сознанием
- **Том II** — ИИ, космология, кремний, фазовый переход, физика
- Граница проходит по линии «человек → космос» или «внутреннее → внешнее»

**КРИТИЧЕСКИ ВАЖНО при сборке:**
- **НЕ использовать `read_file` + `write_file` в Python-скрипте для конкатенации** — `read_file` добавляет префиксы номеров строк (`LINE|content`) в вывод, которые становятся частью итогового документа
- **Правильный способ:** использовать `terminal` с heredoc и `cat`:
  ```bash
  cat > output.md << 'HEREDOC_END'
  [заголовки и разделители]
  HEREDOC_END
  cat part1.md >> output.md
  cat >> output.md << 'HEREDOC_END'
  [разделитель]
  HEREDOC_END
  cat part2.md >> output.md
  ```
- После сборки удалить встроенные оглавления из исходных файлов — они дублируются и создают путаницу. Использовать `search_files` с pattern `"## Оглавление"` и `patch` для удаления.

## Pitfalls

- **consent.google.com редирект:** Иногда `browser_navigate(gemini_url)` перенаправляет на `consent.google.com/m?...`. На этой странице клик на «Принять все» может **не** редиректить обратно. В этом случае контент диалога недоступен через DOM. Решение: если после клика страница не изменилась за 2 секунды — контент недоступен; использовать локальные копии/файлы пользователя, если они есть.
- Не пытаться читать страницу визуально (browser_snapshot/vision) — Gemini-шары рендерятся в React, снапшоты нечитаемы
- Не ждать полной загрузки страницы после принятия cookies — контент в DOM уже есть (если редирект сработал)
- Ссылки могут быть дубликатами — сверять первые 500 символов через `browser_console`
- Русские слова в английской раскладке в запросах пользователя — использовать skill language-typo-helper
- Многие share-ссылки ведут на один и тот же диалог (Gemini создаёт отдельный URL при каждом share) — не читать дубликаты
- **read_file добавляет номера строк:** При использовании `read_file` внутри Python-скрипта (`execute_code`) — функция возвращает контент с префиксами `LINE|` в начале каждой строки. При конкатенации двух документов через `read_file` + `write_file` эти номера строк становятся частью итогового текста, создавая мусор вида `    39|     1|# Заголовок`. Решение: для merge всегда использовать `terminal` + `cat`, а не Python API.
