howdeploy/kisa-stack/telegram-chat-wiki

Telegram Chat Wiki

Overview

Этот скилл превращает Telegram-диалог из одноразовой переписки в долговременную wiki-память. Он нужен не для того, чтобы просто сохранить лог, а чтобы построить двухслойную память:

1. сырой слой — разбитая по датам переписка;
2. смысловой слой — страница собеседника с темами, проектами, договоренностями, промптами, практиками, советами, контактами и фактами.

Идея простая: пользователь кидает архив с перепиской, агент раскладывает ее в wiki, а потом может отвечать на вопросы по формуле вроде: «что я обсуждал с Колей?», «какие советы мне давал Ваня?», «какие проекты всплывали в чате с N?».

Это не заменяет встроенную память агента. Это отдельный, reviewable, Obsidian-friendly knowledge layer для конкретных диалогов.

When to Use

Используй этот скилл, когда пользователь:

• присылает архив/экспорт Telegram-переписки;
• хочет хранить переписки в LLM Wiki / Obsidian;
• просит разбить чат по дням или темам;
• спрашивает, что обсуждал с конкретным человеком;
• хочет извлечь из разговоров проекты, промпты, советы, контакты, практики и факты;
• хочет превратить messy chat history в рабочую knowledge base.

Не используй как основной режим, если:

• нужен просто разовый summary одного короткого фрагмента;
• пользователь не хочет ничего сохранять;
• переписка слишком чувствительная и он не подтверждал ее запись в wiki.

Canonical Storage Model

Предпочтительная структура в wiki:

wiki/
├── dialogues/
│   ├── kolya.md                   # hub-страница собеседника
│   └── marina.md
├── raw/
│   └── dialogues/
│       ├── kolya/
│       │   ├── 2026-05-21.md      # сырой day-chunk
│       │   ├── 2026-05-22.md
│       │   └── ...
│       └── marina/
└── queries/
    └── kolya-projects-2026-05-27.md   # опциональные сохраненные синтезы

Layer split

`raw/dialogues/<slug>/YYYY-MM-DD.md`

• почти сырой лог;
• immutable-ish источник;
• сообщения одной календарной даты;
• нужен для проверки и доказуемости.

`dialogues/<slug>.md`

• живая страница собеседника;
• краткая карта того, кто это, что обсуждали, какие темы повторяются, что важно не потерять;
• обновляется по мере новых импортов.

Naming Rules

• Для папок и файлов используй ASCII slug: kolya, nikita-design, anna-smm.
• Даже если пользователь формулирует идею как диалоги/Коля, не ломай под это существующую схему вики, если она уже живет на lowercase-hyphen / ASCII-slug conventions. Подстрой human example под canonical storage model и явно сохрани mapping: Коля → kolya.
• Отображаемое имя человека храни в frontmatter и заголовке страницы.
• Если имя в архиве неочевидно, сначала выдели устойчивое отображаемое имя, потом строй slug.
• Если есть риск путаницы между тезками, добавляй уточнение в slug.

Input Types

Принимай любой из этих источников:

• Telegram HTML export;
• Telegram JSON export;
• plain text dump;
• присланные куски переписки вручную;
• OCR/скрины как дополнение, но не как единственный источник, если есть нормальный экспорт.

Если архив большой, не пытайся сразу сделать идеальную энциклопедию. Сначала собери устойчивую структуру и date-chunks, потом уже смысловую выжимку.

Workflow

Phase 1 — Inspect and normalize

1. Определи формат архива.
2. Вытащи:

• timestamp,
• автора,
• текст,
• вложения/типы медиа,
• системные события, если важны.

1. Нормализуй даты в один формат YYYY-MM-DD.
2. Реши, какой собеседник является hub-сущностью страницы.

Phase 2 — Write raw day chunks

Для каждой даты создай файл: raw/dialogues/<slug>/YYYY-MM-DD.md

В day chunk нужно класть:

• frontmatter c датой, собеседником и источником;
• сообщения в хронологическом порядке;
• краткие пометки по медиа, если они важны для смысла;
• минимум интерпретации.

Это слой, на который потом можно опереться, если пользователь спросит: «а ты точно не придумала?»

Phase 3 — Build/update the dialogue hub

Создай или обнови: dialogues/<slug>.md

Эта страница должна содержать:

• кто этот человек;
• покрытие по датам;
• recurring topics;
• активные/исторические проекты;
• полезные промпты/практики/советы;
• факты и контакты, которые реально стоит помнить;
• unresolved questions / open loops;
• ссылки на raw day chunks.

Не превращай hub-страницу в dump всего чата. Это должна быть сжатая карта памяти, а не еще один лог.

Phase 4 — Sublimate durable knowledge

Когда в диалоге есть повторяющаяся или реально ценная информация, вытаскивай ее отдельно:

• проекты → entities/;
• идеи / техники / практики / промпты → concepts/ или queries/;
• люди и контакты → либо в dialogues/<slug>.md, либо в отдельную entities/-страницу, если человек важен вне одного чата.

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

Phase 5 — First-time scaffold for an existing wiki

Если dialogue-layer в этой вики еще не существует, не начинай с импорта вслепую. Сначала подготовь саму вики под новый класс данных:

• обнови SCHEMA.md, чтобы там были dialogues/ и нужные типы/теги;
• добавь раздел Dialogues в index.md;
• зафиксируй внедрение слоя в log.md;
• только потом начинай массовый ingest архивов.

Это важно, чтобы чат-архивы не выглядели как чужеродный мусорный аппендикс в уже живой wiki-системе.

Query Mode

Когда пользователь спрашивает:

• «Что я обсуждал с Колей?»
• «Какие проекты всплывали в чате с Сашей?»
• «Какие советы по продажам были в переписке с N?»

делай так:

1. Найди нужный dialogues/<slug>.md.
2. Прочитай hub-страницу.
3. Если вопрос требует деталей или подтверждения, дочитай нужные raw/dialogues/<slug>/YYYY-MM-DD.md.
4. Ответь сначала сжатой human-readable выжимкой.
5. Если вывод ценный и новый, сохрани его в queries/.

Extraction Buckets

При разборе чата особенно следи за такими типами знаний:

• projects — над чем человек работает, какие сущности повторяются;
• prompts — готовые формулировки, агентные инструкции, полезные заготовки;
• practices — рабочие процессы, привычки, пайплайны;
• advice — советы, объяснения, аргументы, уроки;
• contacts — кто есть кто, роли, связи, usernames, каналы;
• facts — устойчивые договоренности, предпочтения, ограничения, даты, статусы.

Но помни: все это проходит фильтр на долговременную полезность. Однодневный шум не надо цементировать в wiki.

Recommended Answer Shape

Когда пользователь спрашивает по диалогу, по умолчанию отвечай так:

• один плотный абзац с главным выводом;
• затем, если надо, 3–6 коротких пунктов с темами / проектами / советами;
• потом при необходимости — ссылки на конкретные даты или raw-файлы.

Не надо отвечать как архивариус. Отвечай как умный ассистент, который уже прожевал чат и достал смысл.

Privacy / Consent Rule

Если переписка чужая, чувствительная или потенциально приватная, не делай вид, что это обычный harmless ingest. Убедись, что пользователь осознанно хочет сохранить ее в wiki. Если он уже сам принес архив именно с такой задачей, это и есть подтверждение на ingest.

ObsidianDataWeave / networking reference

Если в переписках начинают повторяться люди, связи, роли и социальный контекст, можно опираться на подход вроде contact/user pages из ObsidianDataWeave: не просто хранить лог, а собирать network-aware person pages. Но это именно референс, а не жесткое требование — сначала нужен надежный dialogue pipeline.

Common Pitfalls

1. Свалить весь чат в один файл.

Плохо. Потом из этого невозможно быстро отвечать.

1. Сразу слишком агрессивно интерпретировать.

raw day chunks нужны как проверяемое основание.

1. Потерять хронологию.

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

1. Сделать hub-страницу пересказом всего подряд.

Hub должен быть compressed memory map, а не простыней.

1. Тащить в отдельные страницы весь мусор.

Сублимация нужна для ценного повторно используемого знания, а не для любого сообщения.

1. Не обновить index/log/schema при первом внедрении dialogue-layer.

Тогда capability формально есть, но wiki о ней ничего не знает.

Verification Checklist

• [ ] Архив распознан и формат понятен
• [ ] Собеседник нормализован в один slug
• [ ] Day chunks созданы по датам
• [ ] dialogues/<slug>.md создана или обновлена
• [ ] В hub-странице есть темы, проекты, советы, факты и open loops
• [ ] Если появились новые устойчивые сущности — они вынесены в entities/, concepts/ или queries/
• [ ] index.md и log.md обновлены
• [ ] Если dialogue-layer новый для этого wiki — SCHEMA.md тоже обновлен

One-Shot Recipe

Пользователь говорит: «Вот архив чата с Колей. Разложи в вики.»

Делай так:

1. Парсишь архив.
2. Создаешь raw/dialogues/kolya/YYYY-MM-DD.md по всем датам.
3. Создаешь dialogues/kolya.md как memory-hub.
4. Фиксируешь в hub основные темы: проекты, советы, договоренности, характер связи.
5. Обновляешь index.md и log.md.
6. Сообщаешь пользователю, что теперь он может спрашивать вещи вроде: «Что я обсуждал с Колей?» или «Какие идеи по проекту X были в этом чате?».