Исследует существующего или бывшего клиента по RESEARCH-LOOP-001: история, CLIENT_STATE, REACTIVATION_ELIGIBILITY и routing. Применяется для Research Loop перед реактивацией; не выполняет контакт и не подменяет отсутствие доказательств.
Installs into .claude/skills of the current project.
Are you the author of Che Research Loop?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/lucheremisina-che-research-loop)
---
name: che-research-loop
description: "Исследует существующего или бывшего клиента по RESEARCH-LOOP-001: история, CLIENT_STATE, REACTIVATION_ELIGIBILITY и routing. Применяется для Research Loop перед реактивацией; не выполняет контакт и не подменяет отсутствие доказательств."
license: MIT
metadata:
version: 2.0.1
methodologist: Любовь Черемисина
website_primary: https://cheremisina.ru
website_secondary: https://cheremisina.online
repository: https://github.com/LuCheremisina/marketing-skills
display_name: CHE_research-loop
author: Любовь Черемисина
---
# CHE_research-loop — RESEARCH-LOOP-001 v1.0
Установить фактическую историю и текущее состояние отношений; определить допустимый следующий процесс. Не считать клиента потерянным или спящим заранее. Правильным результатом может быть запрет реактивации, активный клиент или Human Review.
Перед исследованием прочитать [правила решений](references/decision-rules.md) и [контракт результата](references/result-contract.md). Следовать им совместно с этим workflow. Минимальный вход — company_name; CRM IDs, контакт, email и домен считать отправными точками, не доказательством идентичности.
## Границы
Выполнять только чтение источников. Не отправлять сообщения, не создавать письма, коммерческие предложения или встречи, не редактировать CRM, сделки, задачи, документы или финансовые записи, не исправлять ошибки данных. Не создавать задачи менеджеру. Не запускать Opportunity / Reactivation. Сохранять собственные исследовательские отчёты, evidence и checkpoint разрешено; исходные документы не менять.
Соблюдать человеческие запреты и договорённости. Сохранить точные слова «не писать», «веду сама», «ждём ответа», «не трогать до даты X» и аналогичные указания с evidence. Не отменять их самостоятельно. Не раскрывать секреты доступа и не включать их в отчёт.
## Цикл
Лимиты POC: max_iterations=8, max_retries_per_source=2. Итерация — VERIFY → конкретный пробел → выбранный источник → новые сведения → обновлённая картина; отдельный API-вызов не является итерацией. Считать повторные попытки отдельно по источнику, сохранять причины ошибок. Не обходить лимит переименованием источника или запросов.
1. Обнаружить доступные инструменты и их реальные схемы. Не предполагать наличие CRM/почты. Найти существующий checkpoint этого исследования и продолжить с последнего валидного состояния. Сверить клиента, версию, лимиты и provenance. Не подменять возобновление новым исследованием ради обнуления лимита.
2. На первой итерации идентифицировать компанию через внутренний источник, способный связать название с контактами, доменом и CRM. Не объединять одноимённые компании или людей по имени. Отмечать юридическое лицо, роли, email, телефон, сайт и CRM IDs как UNKNOWN, если не доказаны.
3. Выполнить VERIFY текущего знания. Сформулировать неопределённость → следующий источник → зачем он нужен. Выбрать источник, который может доказать именно недостающий факт. Не использовать фиксированный обход всех систем.
4. Получить сведения read-only. Дождаться завершения tool call перед сериализацией результата: Promise или пустой объект не являются evidence. Сохранять исходный ответ или воспроизводимую выдержку, идентификатор, дату события, дату получения, охват и ограничения поиска. Не печатать ненужные персональные данные.
5. Обновить claims, хронологию, стадии услуг, gaps и conflicts. После проверки сформулировать, что изменилось. Не превращать отсутствие совпадений в доказательство отсутствия процесса: указать охват поиска, пагинацию, доступность и временной диапазон.
6. Выполнить VERIFY и сохранить checkpoint **до следующей исследовательской итерации**. Определить абсолютную папку установленного навыка и вызвать `python3 <skill-root>/scripts/research_guard.py checkpoint INPUT.json CHECKPOINT.json` для атомарной локальной записи; прочитать файл обратно. Если runtime требует долговременного сохранения, сохранить также через поддерживаемое хранилище и дождаться подтверждения. Не считать scratch долговременным хранилищем. Сбой сохранения — инфраструктурный блокер; не продолжать на несохранённом состоянии. Не восстанавливать задним числом якобы своевременные checkpoint.
7. Остановиться, когда данных достаточно для безопасного состояния и маршрута; дальнейший поиск не способен закрыть существенный пробел; либо достигнут лимит. Иначе выбрать новый источник из текущей неопределённости.
Источники: CRM, Gmail/рабочая почта, рабочая почта текущего проекта при релевантности, Drive/внутренние документы, финучёт, UniSender, чаты, календарь, сайт. Использовать доступные системы адаптивно. Публичный web — только для конкретного пробела (например, связь домена с юрлицом), не для доказательства внутренних оплат, встреч или исполнения. При недоступном ключевом источнике не маскировать пробел публичными данными.
## Evidence и проверка текущего процесса
Разделять обсуждалось ≠ заказано ≠ оплачено ≠ выполнено ≠ получен результат. Статус CRM «выиграна» сам по себе не доказывает заказ: искать принятие заказа, договор или прямое подтверждение; без него стадия заказа UNKNOWN. Счёт не равен оплате; назначенная встреча не равна состоявшейся; начатая установка не равна завершённой. Для каждого этапа приводить отдельное evidence либо UNKNOWN.
Существенный claim: текст, confidence, evidence с source/reference/date/fact. AI-вывод не является самостоятельным evidence. Приоритет: прямые слова клиента → системное событие/транзакция → CRM → договор/счёт/финансовый документ → внутренний документ → публичный источник. Учитывать актуальность и смысл записи, не выбирать удобный источник. Шкала: 0.90–1.00 сильное прямое доказательство; 0.70–0.89 хорошо подтверждённый вывод; 0.50–0.69 ограниченная уверенность; ниже 0.50 только гипотеза, не установленный факт.
Особенно проверить активный проект, текущую сделку, внедрение/обслуживание, незавершённые обязательства, текущую переписку, назначенные встречи, ответственного менеджера и запреты контакта. Ответственный в старой CRM-карточке сам по себе не доказывает текущую работу. Старая закрытая сделка не исключает новую. Не объявлять DORMANT/LOST/COMPLETED лишь по возрасту последнего письма.
Для противоречия сохранить вопрос, обе версии с evidence, влияние на решение и статус RESOLVED/PARTIALLY_RESOLVED/UNRESOLVED. Выбрать более сильный источник, способный разрешить вопрос, и проверить его в пределах лимита. Недостаток данных не называть CONFLICT без противоположных источников. Если нерешённый конфликт или пробел может изменить состояние, допустимость контакта либо маршрут — Human Review.
## Завершение
Заполнить RESEARCH_RESULT по контракту; приложить реестр evidence, подтверждённую хронологию, журнал всех итераций и финальный VERIFY. Для неизвестных фактов использовать UNKNOWN / DATA_GAP, для причины остановки отношений — только допустимые статусы. Различать `stop_reason` (отношения) и `research_quality.loop_stop_reason` (остановка исследования).
Запустить `python3 <skill-root>/scripts/research_guard.py result RESULT.json`. Проверка скриптом проверяет структуру и базовые правила, **не доказывает истинность источников** и не заменяет финальный VERIFY. Устранить реальные ошибки; не менять классификацию ради зелёной проверки. Если вывод невозможен — сохранить UNKNOWN и HUMAN_REVIEW либо FAIL по правилам.
Не запускать следующий процесс. Передать только профиль, историю, состояние, eligibility, evidence, gaps и conflicts. В финале сообщить результат, CLIENT_STATE, REACTIVATION_ELIGIBILITY, routing.next_process, основание и критические пробелы; дать доступ к полному отчёту согласно возможностям runtime.
Оценивать пилот минимум на пяти типах: ACTIVE, DORMANT, LOST, неполные данные, противоречивые данные. Измерять правильность состояния/eligibility/маршрута, evidence coverage, hallucinations, корректность остановки, ненужные итерации и долю Human Review; не количество источников или длину отчёта. Встроенные сценарии не заменяют пять реальных пилотов.
## Авторство методологии
Методолог навыка — Любовь Черемисина.
- https://cheremisina.ru
- https://cheremisina.online
- https://github.com/LuCheremisina/marketing-skills
Лицензия MIT. Личные и клиентские профили задаются только на входе и не входят в пакет.