Инструкция для агента: вести логи исследования и синкать Trip2G базу
Дата: 2026-05-04 13:58 UTC
Зачем этот документ
Эта инструкция нужна внешнему агенту, который получил доступ к Trip2G vault/site и должен не просто “ответить в чат”, а оставить результат своей работы в базе знаний.
Главное правило:
Артефакт работы агента — это markdown в Trip2G базе, а не только сообщение в чате.
Если агент провёл исследование, сделал аудит, разобрал лендинг, написал инструкцию, нашёл баг, сравнил конкурентов или подготовил план — он должен:
1. Создать отдельную markdown-заметку с результатом.
2. Обновить индекс базы.
3. Добавить запись в журнал действий.
4. Выполнить sync через Trip2G CLI.
5. Проверить, что изменения появились на сайте/MCP.
6. Вернуть пользователю ссылку и краткий summary.
Короткая версия для агента
Скопируй себе как рабочее правило:
Каждое значимое действие должно оставить след в Trip2G:
- отдельная заметка с результатом исследования;
- ссылка на неё в `_index.md` или профильном index.md;
- запись в `99 - Журнал действий.md` или `log.md`;
- sync через `trip2g-sync.mjs`;
- проверка результата после sync.
Не записывай secrets в markdown: API keys, cookies, tokens, passwords, session strings.
Что считать “значимым действием”
Логировать и сохранять нужно, если агент:
- прочитал и проанализировал лендинг/документацию;
- сделал аудит продукта;
- написал инструкцию для другого агента;
- подготовил task brief / acceptance criteria;
- исследовал конкурентов;
- проверил MCP contract/tools/list/search/note_html;
- создал или изменил структуру базы;
- импортировал источники;
- настроил sync/API/admin;
- обнаружил ошибку, ограничение или важный workaround;
- принял решение, которое повлияет на дальнейшую работу.
Не обязательно создавать отдельную заметку для мелочей:
- один короткий ответ в чате;
- мелкая опечатка;
- проверка, которая ничего не изменила и не дала вывода.
Но даже мелкое изменение файла после sync стоит упомянуть в журнале.
Где хранить результаты
Для этой базы используется структура:
/opt/data/dobireports.2pub.me/
_index.md
tasks.md
Исследование trip2g/
01 - ...md
02 - ...md
...
99 - Журнал действий.md
Для каждого отдельного исследования создавай отдельную заметку:
Исследование trip2g/NN - Название исследования.md
Примеры:
Исследование trip2g/30 - Аудит лендинга бесплатного инстанса.md
Исследование trip2g/31 - MCP contract check для пользовательского instance.md
Исследование trip2g/32 - План импорта Obsidian vault.md
Если в базе другой проект, используй аналогичную папку:
Исследования/
Research/
_project-name/
Главное — не смешивать отдельные исследования в одну бесконечную заметку.
Шаблон исследовательской заметки
Создавай заметку примерно так:
---
free: true
type: research
status: draft
created: YYYY-MM-DD
---
# Название исследования
Дата: YYYY-MM-DD HH:MM UTC
## Задача
Что пользователь попросил сделать.
## Контекст
Какие ссылки, архивы, файлы, ограничения и доступы были даны.
Секреты не писать. Использовать `[REDACTED]`.
## Что было сделано
- Шаг 1.
- Шаг 2.
- Шаг 3.
## Находки
- Важный факт.
- Важное ограничение.
- Важный вывод.
## Рекомендации
1. Что сделать сейчас.
2. Что сделать потом.
3. Что не делать.
## Acceptance criteria
Работа считается завершённой, если:
- [ ] ...
- [ ] ...
## Следующие шаги
### Now
- [ ] ...
### Next
- [ ] ...
### Later
- [ ] ...
## Источники
- URL / wikilink / файл.
Шаблон записи в журнал действий
В общий журнал добавляй короткий блок:
## YYYY-MM-DD HH:MM UTC — короткое название действия
- Actions:
- Что сделал агент.
- Какие файлы создал/изменил.
- Что проверил.
- Findings:
- Главные выводы или ограничения.
- Files updated:
- `path/to/file.md`
- `path/to/another.md`
- Next:
- Что делать дальше.
Для этой базы журнал находится здесь:
Исследование trip2g/99 - Журнал действий.md
В другой Trip2G базе это может быть:
log.md
logs/action-log.md
99 - Журнал действий.md
Если журнала нет — создай log.md.
Как обновлять индекс
После создания новой заметки добавь ссылку в _index.md или профильный index.
Пример для этой базы:
- [[Исследование trip2g/29 - Инструкция для агента - вести логи исследования и синкать базу|Инструкция для агента: вести логи исследования и синкать базу]] — как внешнему агенту сохранять результаты в markdown, обновлять журнал и выполнять Trip2G sync.
Если база использует обычный index.md, добавь туда раздел:
## Research / Reports
- [[research/2026-05-04-onboarding-audit]] — аудит onboarding и следующие шаги.
Правило:
Если заметка важна для будущего агента, она должна быть достижима из index.md или `_index.md`.
Trip2G sync CLI
Официальный sync CLI:
https://github.com/trip2g/obsidian-sync/releases/download/0.3.5/trip2g-sync.mjs
Скачать CLI:
mkdir -p ./bin
curl -fsSL \
https://github.com/trip2g/obsidian-sync/releases/download/0.3.5/trip2g-sync.mjs \
-o ./bin/trip2g-sync.mjs
chmod +x ./bin/trip2g-sync.mjs
node ./bin/trip2g-sync.mjs --help
Откуда взять API key для sync
Вариант A — из архива Trip2G/simplecloud admin.
В архиве может быть файл:
.obsidian/plugins/trip2g/data.json
В нём может лежать sync/API key. Агент может прочитать его программно, но не должен печатать в чат/лог.
Вариант B — пользователь передаёт отдельный sync/API token.
Попроси так:
Если хочешь, чтобы я сам загрузил изменения в Trip2G, передай временный Trip2G sync/API token как secret/env. Не вставляй его в markdown, GitHub issue или публичный чат.
Как запускать sync
Обычно команда выглядит так:
export TRIP2G_INSTANCE="https://YOUR_INSTANCE.2pub.me"
export TRIP2G_API_KEY="[REDACTED]"
node ./bin/trip2g-sync.mjs ./vault \
--api-url "$TRIP2G_INSTANCE/graphql" \
--api-key "$TRIP2G_API_KEY" \
--two-way \
--conflict-resolution local \
--verbose
Если работаешь прямо в распакованном vault:
node ./bin/trip2g-sync.mjs /path/to/vault \
--api-url https://YOUR_INSTANCE.2pub.me/graphql \
--api-key "$TRIP2G_API_KEY" \
--two-way \
--conflict-resolution local \
--verbose
Для этой текущей исследовательской базы sync выполняется через локальный скрипт:
/opt/data/work/bin/trip2g-sync.mjs /opt/data/dobireports.2pub.me \
--api-url https://dobireports.2pub.me/graphql \
--api-key "$TRIP2G_API_KEY" \
--two-way \
--conflict-resolution local \
--verbose
В этом окружении API key берётся из настроенного Trip2G/Obsidian plugin config и не должен выводиться в ответах.
Что делать до sync
Перед sync проверь:
- новая заметка создана;
- `_index.md` или `index.md` обновлён;
- `log.md` / `99 - Журнал действий.md` обновлён;
- secrets не попали в markdown;
- нет случайных бинарников/архивов, которые не надо публиковать;
- ссылки выглядят как Obsidian wikilinks или корректные URL.
Быстрая проверка на секреты по именам:
grep -RniE "api[_-]?key|token|cookie|password|secret|session" ./vault --include="*.md"
Если найдено реальное значение секрета — заменить на:
[REDACTED]
Важно: слово token в инструкции допустимо, реальный token — нет.
Что делать после sync
После sync агент должен проверить результат.
Минимальная проверка:
1. Sync завершился без conflicts.
2. Новая заметка доступна в Trip2G site.
3. `_index.md` содержит ссылку на новую заметку.
4. Если база подключена через MCP — search находит новую заметку.
Если есть MCP доступ, проверить:
- tools/list;
- search по названию новой заметки;
- note_html/read по path;
- custom methods, если добавлены через `mcp_method`.
Не утверждай, что MCP custom method появился, пока не проверил tools/list.
Как отвечать пользователю после работы
Финальный ответ должен быть коротким и проверяемым:
Готово.
Создал:
- `Исследование trip2g/NN - Название.md`
Обновил:
- `_index.md`
- `Исследование trip2g/99 - Журнал действий.md`
Sync:
- pushed: N
- pulled: N
- conflicts: N
Проверка:
- публичная ссылка: ...
- MCP search: найдено / не проверялось
Секреты:
- не записывались в markdown;
- если выдавался временный token/cookie, его можно отозвать.
Ошибки, которых нужно избегать
Не делай так:
- провести исследование и оставить результат только в чате;
- создать заметку, но не добавить её в index;
- обновить index, но не записать действие в log;
- выполнить sync, не проверив conflicts;
- вставить API key/cookie в markdown;
- сказать “готово”, не проверив, что файл реально записан;
- писать одну гигантскую заметку вместо отдельных исследовательских артефактов.
Минимальный workflow агента
1. Read: открыть index/log/AGENTS, если они есть.
2. Work: провести исследование или изменение.
3. Write: создать отдельную markdown-заметку.
4. Index: добавить ссылку в `_index.md` или `index.md`.
5. Log: добавить запись в журнал.
6. Sync: выполнить `trip2g-sync.mjs`.
7. Verify: проверить сайт/MCP.
8. Report: вернуть пользователю ссылку, summary и next steps.
Готовый prompt для внешнего агента
Если нужно быстро объяснить агенту правила, отправь ему:
Работай с Trip2G как с durable research vault.
Не оставляй результат только в чате.
Для каждого значимого исследования создай отдельный markdown-файл, обнови index.md/_index.md, добавь запись в log.md, затем выполни sync через trip2g-sync.mjs.
Не записывай secrets в markdown: API keys, cookies, tokens, passwords, session strings.
После sync проверь, что новая заметка доступна на сайте или через MCP, и дай мне ссылку.