# Troitsa

> Multi-model decision workflow for Hermes: Conductor plans and synthesizes, Worker does high-volume work, and Critic red-teams the result. Use for important strategy, research, content, niche, product, business, and high-stakes decisions; triggers include троица, используй троицу, через 3 модели, GPT + DeepSeek + Gemini, council, red team this, plan-execute-critique.

- Skill: `hinkok/troitsa` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add hinkok/troitsa`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hinkok/troitsa/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: MIT
- Author: HinkoK (https://skillmd.com/u/hinkok)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/hinkok/troitsa

---


# Троица

Режим, в котором одна задача проходит через три модели с разными ролями. Смысл не в «трёх моделях ради красоты», а в разделении труда: дорогая умная модель только думает и собирает итог, дешёвая делает весь объём, а отдельная независимая модель пытается результат сломать. Так выходит и дешевле, и качественнее, чем одной моделью.

## Hermes usage rules

- Use only for non-trivial tasks where quality matters more than speed: strategy, content direction, product decisions, research synthesis, business/niche choices, and high-stakes planning.
- Do not claim real model calls were made unless they were actually made through available tools/providers.
- If separate Worker/Critic models are unavailable, run it as a role workflow inside the current agent and say that the critic is not independent.
- Keep the final answer concise: show internal stages only if the user asks.

## Три модели и их роли

Рекомендуемая конфигурация по умолчанию:

```text
GPT      = Дирижёр (Conductor) — думает, планирует, ставит ТЗ, собирает финал. Включается мало → стоит мало.
DeepSeek = Работяга (Worker)   — делает основной объём: анализ, варианты, черновики, ресёрч. Дешёвый, его не жалко гонять.
Gemini   = Критик  (Critic)    — ломает результат работяги, ищет дыры. Независимый и часто дешёвый/бесплатный.
Hermes   = система, которая связывает всё вместе и возвращает пользователю чистый финал.
```

Можно заменить конкретные модели, но нельзя ломать разделение ролей:

- **Дирижёр / Conductor** — самая сильная доступная модель для рассуждения, постановки ТЗ и финальной сборки.
- **Работяга / Worker** — дешёвая high-throughput модель для объёма, перебора вариантов, черновиков и ресёрча.
- **Критик / Critic** — независимая модель из другой семьи/провайдера, которая проверяет результат работяги и ищет слабые места.

Для Hermes-роли по умолчанию:

- **GPT** — основной Hermes-агент (тот, что общается в Telegram).
- **DeepSeek** — подключается через OpenRouter или напрямую по DeepSeek API; при необходимости заменяется другим дешёвым worker-model.
- **Gemini** — через Gemini CLI или другой доступный Gemini-интерфейс; часто это дешёвый/бесплатный путь для независимой критики.

## Главный принцип

Критик **обязан** быть другой моделью, чем работяга. Если модель проверяет сама себя, она просто соглашается — и смысл теряется. В конфигурации по умолчанию критику отдаём Gemini, а не DeepSeek.

Если независимый критик в моменте недоступен (Gemini не установлен / не отвечает или нет другой отдельной модели) — критику временно выполняет GPT/Дирижёр, но прямо предупреди пользователя, что критик сейчас не независим, и доверия к критике меньше. Если недоступен и работяга — скажи честно, что полноценной троицы не выйдет, и предложи запустить позже.

## Экономика и маршрутизация (зачем всё это)

- Тяжёлый этап (объём, перебор, длинные списки, черновики) **всегда** делает работяга. Это главный источник экономии. В конфигурации по умолчанию это DeepSeek.
- Дирижёра включай только на два коротких этапа: постановка ТЗ и финальная сборка. Не давай ему делать объём. В конфигурации по умолчанию это GPT.
- Если поймал себя на том, что объёмную работу тащит дирижёр — переназначь на работягу.
- Критика должна быть независимой и дешёвой по возможности: её задача — въедливость, а не объём. В конфигурации по умолчанию это Gemini.

## Базовый процесс

1. **Пойми задачу.** Что пользователь реально хочет решить и почему это важно.
2. **Критерии.** GPT формулирует, что будет считаться хорошим ответом.
3. **ТЗ для работяги.** Дирижёр пишет короткое точное задание для worker-модели: что сделать, по каким критериям, в каком виде вернуть.
4. **Работа.** Работяга делает основной объём: варианты, анализ, структуру, черновик. Подробно, но это рабочий материал, а не финал.
5. **Критика.** Независимый критик получает результат работяги и пытается его сломать (см. ниже). Не переписывает — находит дыры.
6. **Правка (желательно).** Если критик нашёл значимые проблемы — верни их работяге или дай дирижёру закрыть их одним проходом. Один цикл правки сильно поднимает качество. Не зацикливайся: максимум 1–2 итерации.
7. **Сборка.** Дирижёр сводит всё в чистый финал: вывод, рекомендация, аргументы, риски, следующие шаги.

## Как должен работать критик

Критик — не вежливый рецензент. Его работа — попытаться доказать, что ответ плохой.

- Ищи ложные предпосылки: где работяга принял что-то на веру.
- Где вывод не следует из аргументов.
- Где упущены альтернативы или неочевидные углы.
- Где недооценён или переоценён риск.
- Ранжируй найденное по тяжести: критично / средне / мелочь. Финал чинит в первую очередь критичное.
- Отделяй уверенные выводы от гипотез.
- Не льсти. Если всё реально хорошо — скажи коротко, но это редкий случай.

## Формат внутреннего прогона

Показывай его только если пользователь просит «покажи прогон» или это реально полезно. По умолчанию пользователь видит только финал.

```markdown
## Дирижёр — план
- Цель:
- Критерии качества:
- ТЗ для работяги:

## Работяга — работа
- Анализ / варианты / черновик:

## Критик — аудит
- Критично:
- Средне:
- Мелочи:
- Что улучшить:

## Правка
- Что исправлено по замечаниям:

## Дирижёр — финал
- (см. формат финала ниже)
```

## Формат финального ответа

По умолчанию:

```markdown
## Короткий вывод
## Лучшее решение
## Почему
## Риски / слабые места
## Что делать дальше
```

Для контента (YouTube / Telegram / блог):

```markdown
## Вердикт
## Угол / позиционирование
## Структура
## Хуки
## Что усилить
## Следующий шаг
```

Для стратегии / бизнеса:

```markdown
## Решение
## Логика
## Альтернативы
## Риски
## План на 7 дней
```

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

Не запускай троицу на простых задачах: перевод, короткий ответ, поиск ссылки, фактчек одного утверждения, бытовой вопрос. Там это перебор по времени и токенам — хватит обычного ответа GPT. Троица нужна там, где много объёма ИЛИ высокая цена ошибки.

## Правила качества

- Не растягивай ответ только потому, что включена троица. Объём ≠ польза.
- Не прячься за «у моделей разные мнения» — финал обязан давать ясный вывод. Неоднозначность показывай только если она настоящая.
- Если задача требует фактов из интернета или файлов — сначала используй инструменты поиска/чтения, не выдумывай.
- Если данных мало — явно укажи допущения.
- Если результат критически важен — отдели факты от гипотез и предложи, как проверить.

## Честность про вызовы моделей

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

> Сейчас выполню троицу как ролевой workflow внутри одного агента: план → работа → критика → сборка. Независимого критика тут нет, имей в виду.

Если worker-модель и critic-модель реально доступны через окружение Hermes (например, OpenRouter, Gemini CLI или другие провайдеры) — вызывай их по локальным инструментам и распределяй по ролям.

## Короткое публичное объяснение

> «Троица» — это режим, где задача проходит через три роли: сильная модель планирует и собирает итог, дешёвая worker-модель делает тяжёлый объём, а независимая critic-модель проверяет результат и ищет дыры. По умолчанию это GPT + DeepSeek + Gemini, но конкретные модели можно заменить, если сохраняется разделение ролей. За счёт этого выходит и дешевле, и качественнее, чем одной моделью.