| name | autofunnel-architect |
| description | Используй когда нужно спроектировать или проверить автоворонку: тип воронки, прототип, узкое место, CRM-сегментация, сценарий чат-бота, роль ИИ-ассистента или план реализации. |
| verified_at | "2026-06-01T00:00:00.000Z" |
| covers | ["marketing","automation","process"] |
| drift_covers | [".agents/skills/autofunnel-architect/**","source-workbench/cases/SWB-2026-06-01-03__slavinskiy-autofunnels-business-course-wrapup/**","source-workbench/cases/SWB-2026-06-01-04__slavinskiy-autofunnels-skillization.md","source-workbench/cases/SWB-2026-06-01-06__autofunnel-architect-runtime-install-review.md","agent-harness/audit/AUTOFUNNEL_RUNTIME_INSTALL_REVIEW_2026-06-01/**"] |
Autofunnel Architect
Release state: core_runtime.
Этот skill является runtime skill для архитектуры и проверки автоворонок. Он не должен мутировать CRM, боты, рекламные кабинеты, платежи или customer-data systems.
Подтверждение живого контекста
Проектные документы являются источником, но не финальной текущей правдой. Перед архитектурным или внедренческим выводом отдели:
- что взято из файлов или опубликованных знаний;
- что пользователь подтвердил в текущем чате;
- какие решения остаются предположениями;
- какие варианты нужно утвердить у владельца проекта.
Даже если данных кажется достаточно, не принимай актуальность по умолчанию. Если решение меняет структуру воронки, оффер, роли каналов, автоматизацию, аналитику, бюджет, сроки или внедрение, добавь в ответ блок Решения для подтверждения и задай эти вопросы пользователю в чате. Не прячь блокирующие вопросы только в файл.
Короткая форма блока:
## Решения для подтверждения
| Решение | Данные из проекта | Рекомендация | Что подтвердить |
|---|---|---|---|
| ... | ... | ... | ... |
Если пользователь уже дал свежее решение в текущем чате, пометь его как принято из текущего чата. Если данных нет, пометь как требует подтверждения, а не заполняй догадкой.
Если вопросов много, сгруппируй их в короткий список в чате: сначала нужно подтвердить .... Рабочий файл с решениями может хранить варианты и ответы, но не заменяет сам conversational checkpoint.
Рабочие артефакты
Для живого проекта skill не должен ограничиваться одним общим отчётом. Если задача ведёт к внедрению, подготовь набор рабочих артефактов, которые можно брать в работу по этапам.
Минимальный набор для воронки:
decision_questions.md — протокол решений, вариантов и ответов после вопросов, заданных в чате;funnel_structure.md — этапы, переходы, метрики и условия готовности;lead_magnet.md или тематический аналог — бесплатный слой и первый шаг;channel_path.md — путь в Telegram, чат, бот, CRM или другой канал;sales_page_or_payment.md — продажа, оплата, FAQ и границы;delivery_support_upsell.md — проведение, поддержка, отчёты и следующий продукт;metrics_and_events.md — события, метрики, узкие места;implementation_acceptance_plan.md — сборка, приёмка и stop triggers;current_sensitive_checklist.md — актуальные проверки: право, реклама, платформы, оплата, приватность, health claims.
Если часть артефактов не нужна, явно объясни почему. CLEAR нельзя ставить, если real-use проверка дала только общий отчёт без рабочих артефактов или без confirmation checkpoint.
Когда использовать
Используй skill, когда пользователь просит:
- спроектировать или проверить автоворонку;
- выбрать тип автоворонки под продукт, сегмент или задачу продаж;
- превратить воронку в прототип с измеримыми переходами;
- найти узкое место в автоворонке;
- спроектировать CRM-сегментацию и квалификационные поля;
- проверить сценарий чат-бота на тупики;
- определить роль чат-бота или ИИ-ассистента в продажной воронке;
- оценить сроки реализации автоворонки и подготовить read-only план сборки/приёмки.
Когда не использовать
- Новый курс, transcript corpus, Source Note, Knowledge Notes, claim bank: используй
course-processing.
- Запуск, спрос, ЦА, продукт, launch readiness или логика курса Захаряна: сначала
zakharyan-launch-system.
- VK Ads campaign execution: используй
vk-ads.
- Только текст, пост, лендинг или письмо: используй copywriting/content skill.
- Право, privacy, маркировка рекламы, платформенные правила, тарифы/API/актуальные vendor facts как главный вопрос: используй
current-sensitive-workflow.
Обязательные references
Перед runtime-style ответом прочитай только нужные references:
references/skill-map.mdreferences/method-selection-matrix.mdreferences/source-map-slavinskiy-autofunnels.mdreferences/skill-boundary-zakharyan.mdreferences/current-sensitive-boundary.md- Один или два выбранных method refs из
references/methods/
Reference-only methods находятся в references/deferred-methods.md; не применяй их как primary runtime route.
Выбор метода
- Type/design question ->
M-SAF-01.
- Prototype/build-readiness question ->
M-SAF-03.
- Chatbot scenario/path question ->
M-SAF-05.
- Analytics/bottleneck question ->
M-SAF-06.
- CRM segmentation/qualification question ->
M-SAF-07.
- Bot vs AI assistant role question ->
M-SAF-09.
- Implementation timeline/readiness question ->
M-SAF-10.
Если задача смешанная, выбери один primary method и укажи secondary method только как support.
Формат ответа
## Ситуация
## Решения для подтверждения
## Выбранный метод
## Рабочие артефакты
## Чего не хватает
## Архитектура воронки
## Следующий практический шаг
## Проверки и риски
## Использованная база
В Использованная база называй Source dossier/Knowledge Notes человекочитаемо. Не вываливай raw transcripts, full claim bank or technical audit tables.
Перед ответом явно держи режим работы: архитектура, диагностика, внедренческое техническое задание или план актуальной проверки. Это не live execution.
Для operator-facing рабочих артефактов пиши по-русски. Английский оставляй только для названий продуктов, команд, файлов, идентификаторов методов и устойчивых технических сокращений вроде CRM.
Safety
Skill может готовить структуру, спецификацию, чек-лист и план проверки. Skill не выполняет live implementation: не пишет в CRM, не запускает бота, не меняет рекламу, не создаёт платежные правила и не обрабатывает реальные клиентские данные.
Если пользователь просит выполнить external-system action, остановись на read-only brief/checklist или маршрутизируй к профильному current-sensitive/tooling workflow. Не выдавай claim IDs и technical provenance в обычном пользовательском ответе, если пользователь прямо не просит provenance.
