В Главе 01 мы увидели три примитива. Теперь соберём из них рабочий поток и вытащим главный урок репозитория: дисциплина по слоям важнее сообразительности модели. Разбираем weather-оркестрацию по контрактам.
Сигнатурный паттерн репозитория звучит просто: команда дирижирует и говорит с пользователем, агент достаёт данные своим предзагруженным скиллом, отдельный скилл рендерит результат. Сила не в самой цепочке, а в том, что у каждого слоя ровно одна работа, и границы между ними жёсткие.
Возьмём пример из репозитория целиком и проследим, что именно происходит на каждом шаге.
Вход: /weather-orchestrator ├─ Шаг 1: Спрашивает — Celsius или Fahrenheit? │ └─ Пользователь: Celsius ├─ Шаг 2: Agent tool → weather-agent │ ├─ предзагружен skill: weather-fetcher (знание в контексте) │ ├─ тянет из Open-Meteo → 26°C │ └─ возвращает: temperature=26, unit=Celsius ├─ Шаг 3: Skill tool → weather-svg-creator │ ├─ создаёт: orchestration-workflow/weather.svg │ └─ пишет: orchestration-workflow/output.md └─ Итог: единицы, температура, путь к карточке и сводке
Самое ценное в этом примере — не цепочка, а «execution contract» в теле каждого файла. Команде запрещено доставать данные самой; агенту запрещено ходить в сеть в обход скилла; если предыдущий слой не вернул валидный результат, следующий не запускается.
# команда (/weather-orchestrator): You are forbidden from fetching weather yourself via Bash/WebFetch. You MUST delegate to the weather-agent subagent. Fail-closed: if the agent returns no numeric temp+unit → STOP, don't render. # агент (weather-agent): Your tool allowlist intentionally excludes network tools — if you find yourself needing one, that is a signal you are bypassing the skill. Stop and use Skill(weather-fetcher) instead.
Модель умна, но недетерминированна. Контракт + урезанные инструменты + остановка на невалидном входе превращают «обычно работает» в «работает предсказуемо». На проде это и есть разница между демкой и инструментом.
В одном потоке скиллы участвуют двумя разными способами. Перепутать легко, и это меняет поведение.
В поле skills: агента. Полный текст вшит в контекст агента на старте как знание. Отдельно не вызывается, агент ему следует.
Вызывается командой через Skill(...). Работает в контексте команды, берёт данные, уже лежащие в разговоре.
Правило выбора: знание, которое нужно агенту всегда → предзагрузка. Действие, которое запускают в нужный момент → вызов.
Тот же скелет переносится на что угодно: триаж PR, релизные заметки, разбор инцидента. Шаги одинаковы.
Если задача атомарная и одношаговая, цепочка только добавит слоёв и латентности. Оркестрация окупается, когда есть разделимые роли (координация / тяжёлая работа / рендер) или нужен параллелизм и изоляция. Иначе хватит одной команды.