# Reyting Podryadchikov Do Zvonka

> «Найди топ компаний», «собери полный список», «ранжируй по признакам», «проверь отзывами, переранжируй», «почему не попала». Местные подрядчики, evidence-ranking, live-state.

- Skill: `kir-kopylov/reyting-podryadchikov-do-zvonka` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add kir-kopylov/reyting-podryadchikov-do-zvonka`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/reyting-podryadchikov-do-zvonka/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kir-kopylov (https://skillmd.com/u/kir-kopylov)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kir-kopylov/reyting-podryadchikov-do-zvonka

---


# Local Contractor Evidence Ranker

## Запуск Навыка

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

Применяю **«Доказательное сравнение местных подрядчиков»**: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания.

Не включайте в строку `author_github`, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

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

Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.

## Обзор

Этот skill нужен, когда пользователь ищет локальных подрядчиков для рискованной, дорогой или сложной услуги и хочет не "красивый топ", а evidence ranking по публичным следам.

Цель: восстановить вероятную операционную зрелость подрядчика через сайт, отдельные страницы услуги, отзывы на платформах, реквизиты, похожие кейсы, слабые сигналы и явные неизвестные. Итогом должен быть не уверенный выбор "лучшей компании", а список кандидатов по классам: кому звонить первым, кого проверять, кого держать в резерве и кого не тратить время проверять.

Четыре опоры skill: локальные подрядчики, evidence ranking, отзывы и live-state. Если запрос выпадает из этой рамки, сначала проверьте, не нужен ли другой workflow.

Если workflow связан с публичными платформами отзывов, локальными поисковыми фразами, строгим входным корпусом или live-state caveats, прочитайте `references/domain-playbook.md` перед поиском и финальным ответом.

## Естественные Входы

Запускайте skill по обычным фразам:

- "найди топ компаний в городе";
- "почему эти топ-3";
- "сколько вариантов рассмотрел";
- "кого отсеял";
- "собери полный список";
- "только компании с отдельной страницей услуги";
- "по каким признакам ранжировать";
- "операционализируй процедуру отбора";
- "примени этот план";
- "проверь список отзывами";
- "переранжируй с учётом реальных отзывов";
- "почему конкретная компания не попала".

## Процесс

1. Зафиксируйте корпус до ранжирования:
   - география;
   - тип услуги;
   - обязательные входные фильтры, например отдельная страница услуги;
   - что исключается, например агрегаторы, карточки без страницы, смежные услуги, чужие города;
   - статус кандидатов вне корпуса, если пользователь упоминает компанию, которая тематически подходит, но не проходит фильтр.

2. Соберите evidence pack для каждого кандидата:
   - компания;
   - URL или публичная карточка;
   - где и когда след виден: страница, поисковый сниппет, платформа отзывов, кэш;
   - название услуги;
   - локальная география подтверждена: да, нет или сомнительно;
   - юрлицо или ИП, если публично видно;
   - контакты только как проверяемый след, без утверждения что они актуальны;
   - критерии с баллом и evidence;
   - штрафы;
   - что проверить звонком или через платформу.

3. Постройте признаки под конкретную задачу. Если пользователь не дал критерии, предложите 4-6 операционных признаков, которые отличают способность выполнить сложный случай от маркетинга. Для сложных санитарных, аварийных, строительных или сервисных кейсов используйте базовый набор:
   - диагностика до обещаний;
   - устранение причины или источника, а не только симптома;
   - полный операционный цикл;
   - документы, ответственность и условия гарантии;
   - публичные следы похожих сложных кейсов.

4. Оцените каждый признак по одинаковой шкале:
   - `2` — конкретный проверяемый след на странице, в публичной карточке или в релевантном отзыве;
   - `1` — общее упоминание без достаточной операционной конкретики;
   - `0` — признака нет, он заменён маркетинговой формулировкой или относится к другой услуге.

5. Примените штрафы. Типовые штрафы:
   - `-2` за абсолютные обещания вроде "100%", "за один выезд", "без осмотра", если это не подтверждено диагностикой;
   - `-2` если решение сводится к одному инструменту, ароматизации, озону, сухому туману или косметической процедуре;
   - `-1` за отсутствие реквизитов исполнителя;
   - `-1` за гарантию без условий;
   - `-1` за шаблонную городскую страницу, чужие города, смешение филиалов или сомнительную локальность;
   - `-1` за отсутствие независимого локального следа;
   - `-1` если страница старая и нет свежих публичных подтверждений.

6. Добавьте слой отзывов отдельно от базовой операционной оценки:
   - ищите точное название, домен, юрлицо, адрес или устойчивый бренд на 2ГИС, Яндекс Картах, Flamp, Yell, Zoon, Avito, Google, локальных справочниках и отраслевых агрегаторах;
   - не смешивайте компании с похожими названиями;
   - независимые платформенные отзывы учитывайте сильнее собственных отзывов на сайте;
   - отзывы по обычной услуге повышают доверие к сервисности, но не доказывают способность к сложному кейсу;
   - отзывы с похожим сложным кейсом могут давать существенное повышение;
   - собственные отзывы с чужими городами, невозможными датами, копипастой или без привязки к платформе понижают доверие.

7. Отсортируйте и объясните:
   - общий итог;
   - класс кандидата;
   - кто поднялся или опустился после отзывов;
   - кто остался вне корпуса и почему;
   - какие компании имеют доказательства устранения источника, а не только симптома;
   - один контрольный вопрос для звонка по ключевому риску.

8. Не выдавайте поиск за live-state. Для цен, наличия, актуальных телефонов, графика, текущих реквизитов и доступности используйте формулу:
   - `видел в кэше [дата/источник] — нужно подтвердить в моменте через [конкретный канал]`.

9. Если пользователь оспаривает исключение кандидата, не защищайте старый список. Разведите:
   - кандидат не проходил входной фильтр;
   - кандидат был пропущен по ошибке;
   - кандидат относится к широкому рынку, но вне строгого корпуса;
   - кандидат надо добавить отдельной строкой "вне корпуса, проверить звонком".

## Границы

Нельзя использовать skill как гарантию, что подрядчик реально компетентен, доступен сегодня, имеет актуальные цены или выполнит работу. Публичные следы повышают вероятность, но не доказывают фактическое качество.

Нельзя:

- уверенно утверждать live-state по поисковому кэшу;
- подменять независимые отзывы собственными отзывами сайта;
- использовать отзывы по клопам, ремонту, обычному клинингу или доставке как доказательство сложного специализированного кейса;
- смешивать одноимённые компании, франшизы, филиалы или разные домены без явной привязки;
- скрывать, сколько вариантов рассмотрено и кого отсеяли;
- ранжировать только по SEO, цене, рейтингу или количеству отзывов;
- публиковать телефоны, адреса клиентов, номера квартир, личные данные, raw переписки, screenshots/private media или приватные пути в командном repo.

Если пользователь просит юридически значимый вывод, медицинскую рекомендацию, расследование частного лица или обвинение подрядчика в мошенничестве, ограничьтесь публичной evidence hygiene и безопасными следующими действиями.

## Опрос После Использования

Опрос задаётся один раз — после сдачи итогового ранжирования с evidence pack, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

```text
Опрос по skill:
1. Что в этом использовании reyting-podryadchikov-do-zvonka было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".
```

Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/reyting-podryadchikov-do-zvonka/usage-feedback.jsonl` — лучше через bundled script:

```bash
python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."
```

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет `redaction_applied` и `redaction_types`. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

## Логирование Сбоев

Перед выполнением прочитайте локальный `known-exceptions.yaml` как список уже известных случаев и применяйте подходящее `do_next_time` без нового поиска.

Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в `~/.codex/skill-runs/<skill-name>/exception-log.jsonl`.

Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите `unknown`. Raw logs не коммитить.

## Definition Of Done

Работа завершена, когда:

- входной корпус и exclusions явно зафиксированы;
- каждый кандидат оценён по одинаковой шкале;
- у каждого балла есть ссылка, цитируемый фрагмент или явная пометка `нет следа`;
- отзывы отделены от сайта и проверены на точное совпадение компании;
- итоговый список разделён на классы, а не только на места;
- live-state помечен формулой про кэш и канал подтверждения;
- для топ-кандидатов есть короткий контрольный вопрос;
- кандидат вне корпуса не потерян, если пользователь специально спрашивает о нём.