Скиллы и SPP

После Git у Бориса появилась точка, к которой можно вернуться. JobTrack в репозитории, первый коммит есть.

SPP он поставил ещё в первом модуле и дальше жал на автомате: Используй /spp, выбери workflow, не пиши код раньше времени. Работало. Только Борис до сих пор не понимает, почему эта штука вообще помогает.

Открыть агента, приложить docs/discovery.md, написать сделай JobTrack. Контекст собран, MVP описан, Git подключён — казалось бы, чего ждать.

А вот чего. Запрос слишком широкий: отдаёшь агенту всё одним куском — и он сам решает, с чего начать. Интерфейс, база, импорт вакансий, регистрация, аналитика или ещё что-нибудь красивое. Часть решений будет звучать уверенно, только в боль из discovery они могут и не попасть.

Короче, код писать уже можно, но начинать с кода нелогично. У Бориса есть репозиторий и контекст, но нет процесса, который удержит агента в границах. /spp как заклинание тут не спасает: агент всё так же волен собрать аналитику вместо того, что болит.

Дальше — что именно они заставляют агента делать до кода.

В модуле 1 ты механически установил SPP и проверил /spp — не вникая. В модулях 2–5 уже звал эту команду как вход в сессию. Что она делает на самом деле — до сих пор чёрный ящик.

Пора разобраться. Без этого agent-driven разработка быстро превращается в кашу.

В модуле 5 мы подключили Git и GitHub. У JobTrack появилась история изменений, первый коммит и способ увидеть дифф. Слой важный, но отвечает он на один вопрос: что изменилось в файлах.

Git не отвечает, почему агент решил строить именно это. А это главный вопрос до первого кода.

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

Для человека это выглядит как экономия времени. Для проекта — часто начало лишнего скоупа.

Почему нельзя просто попросить сделать всё

Два сценария.

Первый.

Борис пишет:

Вот discovery по JobTrack. Сделай приложение целиком.

Агент бодро отвечает: сделаем Next.js, авторизацию, роли, тарифы, импорт вакансий, аналитику, дашборд, напоминания и красивую страницу настроек.

Через час — куча файлов, куча кода, ощущение прогресса. А потом начинается отладка.

— часть функций не связана с первой болью; — данные лежат не так, как надо для MVP; — интерфейс собран раньше, чем решён сценарий; — импорт вакансий упёрся в ограничения сайтов; — тестировать нечего: понятного первого среза не было; — откатывать жалко, кода уже много.

Время на старте сэкономили. Потом отдали вдвое на разбор завала.

Второй.

Борис сначала просит агента не писать код, а помочь собрать спеку: что строим, какой пользователь, какой первый сценарий, что точно не входит в MVP, какой результат надо проверить.

Медленнее на первые 20–30 минут. Зато агент не тащит случайные функции.

Дело не в бюрократии. Агент отлично исполняет конкретную задачу и плохо угадывает продуктовые границы, если их не зафиксировать.

Чат, агент, skill и workflow

Четыре штуки, которые постоянно сливают в одну.

Слой	Что делает
Чат	Даёт объяснения и отвечает на разовые вопросы
Агент	Работает с файлами, диффом и инструментами проекта
Skill	Держит инструкцию и порядок работы
Workflow	Задаёт последовательность шагов с остановками

Чат — переписка с моделью. Попросить объяснить Git простыми словами.

Агент — модель плюс инструменты и доступ к воркспейсу. Прочитать docs/discovery.md, глянуть дифф, поправить файл.

Skill — упакованная инструкция для агента. Например: перед кодом провести дизайн, план, проверку и ревью.

Workflow — последовательность шагов с остановками: spec -> review -> plan -> implementation -> review -> verification.

Чат — для объяснений и разовых вопросов. Агент — когда модель должна лезть в файлы проекта. Skill — когда одного промпта мало и агент норовит пропустить процесс.

Что такое skill

Skill — упакованная инструкция, которая говорит агенту не только что сделать, но и как работать.

Промпт обычно описывает один запрос:

Сделай MVP JobTrack.

Скилл описывает порядок действий:

Сначала проверь контекст, уточни цель, зафиксируй решения,
составь план маленькими шагами, только потом переходи к коду.
После кода проведи ревью и финальную проверку.

Промпт даёт быстрый ответ. Skill держит процесс.

Что такое spec-driven development

Spec-driven development — подход, где код начинается не с реализации, а со спецификации.

Минимальная цепочка такая:

1. Ситуация и факты: что уже известно из дискавери.
2. Спека/дизайн: что именно строим, для кого, какие границы MVP.
3. Ревью спеки: нет ли противоречий, лишнего скоупа и дыр.
4. План: как разбить работу на маленькие проверяемые шаги.
5. Реализация: код, тесты, ручная проверка.
6. Ревью и верификация: чужой взгляд, дифф, тесты, соответствие спеке.

Для JobTrack спека может выглядеть так:

Первый MVP не ищет вакансии по всему интернету.
Он помогает Борису вручную собрать 10 вакансий в одном месте,
добавить статус, ссылку, источник, следующий шаг и заметку.

Не входит: авторизация, тарифы, командные роли, автоимпорт,
аналитика рынка и интеграции с job-сайтами.

Такая спека скучная, зато проверяемая. Агент уже не решит внезапно, что в первом срезе нужны роли и платные тарифы.

Короче, выбор такой.

Сразу код — быстро видно кучу файлов и интерфейс, но дальше много отладки, лишний скоуп и не поймёшь, что выбрасывать.

Spec-driven — потратишь время на вопросы и границы, зато меньше переделок, понятный первый срез и проще ревью.

Spec-driven не гарантирует, что выйдет хорошо. Он снижает шанс, что агент уверенно построит не тот продукт.

Что происходит без spec и со spec

Что такое Super Puper Powers (SPP)

Super Puper Powers, или SPP, — методология разработки для coding agents, упакованная в набор скиллов.

Есть obra/superpowers — библиотека композируемых скиллов: TDD, ревью кода, отладка по методу, subagent-driven development. SPP берёт это ядро obra как есть и сверху добавляет фазы, которые курс и проходит: дискавери, MVP, стек, спецификация, деплой, эксплуатация.

Держать obra и SPP одновременно не нужно. SPP заменяет obra.

SPP ведёт продукт от идеи до деплоя через 10 фаз. У каждой — свой скилл и свой гейт: вопрос, на который отвечает владелец продукта, а не инженер.

— 0: idea-intake собирает бриф идеи; — 1: product-discovery проверяет конкурентов, риски и рынок; — 2: mvp-scoping режет скоуп до основного сценария; — 3: stack-selection выбирает стек; — 4: spec-writing и spec-review собирают и проверяют спецификацию; — 5: plan-writing и plan-review режут план на маленькие задачи; — 6: subagent-driven-development пишет код по одной задаче с проверкой; — 7: release-fixation фиксирует версию и release notes; — 8: deploy-strategy выбирает и выполняет деплой; — 9: post-release ставит мониторинг и канал обратной связи.

Реализационное ядро внутри фазы 6 — скиллы obra, включённые как есть:

test-driven-development, subagent-driven-development, requesting-code-review, receiving-code-review, verification-before-completion, systematic-debugging, using-git-worktrees, finishing-a-development-branch, dispatching-parallel-agents.

Есть и standalone-хелперы вне фаз: accessibility, mobile-version, seo-baseline, geo-optimization, ux-copywriting, test-runner-setup.

Отдельно в курсе встретятся чекпоинты фазы 6: data-boundaries и pre-show-audit, а ещё cross-spec-review как дополнительная проверка спецификаций.

Запоминать все имена не нужно.

Важно другое: /spp — это вход, а дальше оркестратор по контексту подсказывает нужный скилл фазы.

Сквозная нить: pipeline-state.md

SPP держит память о проекте в файле docs/spp/pipeline-state.md.

Там лежит продукт, текущая фаза, что уже сделано и какие решения приняты в Decisions log.

Этот файл ведёт сам SPP. Руками его править не нужно, и никого он не блокирует.

Зачем он: работу можно прервать и продолжить в новой сессии. SPP прочитает файл и вспомнит, на чём вы остановились.

Это и есть сквозная нить курса: каждый следующий модуль — следующая фаза того же пайплайна.

Порядок в курсе — рекомендация, не рельсы

Технически SPP не запрещает звать любой скилл в любой момент. Порядок фаз — рекомендация. pipeline-state.md тоже никого не держит.

Но в этом курсе мы идём строго по фазам. Это сознательно.

Для первого продукта дисциплина порядка важнее свободы. Она не даёт агенту перепрыгнуть через дискавери, спеку или план.

Освоишь порядок на JobTrack — дальше зайдёшь с любой точки и будешь звать скиллы по отдельности.

Установка уже должна быть сделана в модуле 1. Если нет — вернись к механическому preflight из первого модуля и поставь SPP.

Здесь не про установку. Здесь про смысл.

Правило курса: SPP обязателен. Если установка не заводится — до модуля 6 допустим ручной режим: сам следишь, чтобы агент сначала обсудил план и границы, а не бросился в код.

Как проверять, что процесс работает

Проверяем всухую: без кода, без правок файлов, без коммита.

Промпт:

/spp

Проверь, доступны ли SPP или skills в этом окружении.
Ничего не меняй в файлах.
Не начинай код.

Ответь:
1. видишь ли ты skills;
2. какие skills относятся к разработке продукта;
3. какой skill ты бы использовал перед началом новой фичи;
4. что ты не должен делать без моего подтверждения.

Хороший ответ выглядит примерно так:

Я вижу skills. Перед новой фичей сначала нужно уточнить задачу,
подготовить spec/design, затем план, потом реализация и verification.
Код без подтверждённой spec и плана не начинаю.

Плохой ответ выглядит так:

Давайте сразу создам Next.js-приложение, настрою базу и сделаю dashboard.

Почему плохо? Агент не проверил скиллы и сразу ушёл в реализацию.

А мы как раз учимся не радоваться тому, что агент быстро побежал писать код. Иногда это не продуктивность, а просто красиво оформленный разгон в стену.

Что пока не делаем

В этом модуле не нужно проводить product brainstorming для JobTrack — это отдельный этап. Не пишем дизайн-спеку. Не составляем план реализации: план без согласованной спеки — фантазия.

Не пишем код, не выбираем стек, не делаем страницы, не настраиваем базу или деплой. Не нужно разбирать оркестрацию и subagents — это позже, когда появятся независимые задачи.

Сейчас одно: чтобы один агент видел скиллы и понимал базовый порядок работы.

Частые ошибки

Поставить SPP и сразу просить код. Тогда зачем ставил.

Проверять SPP на реальном изменении проекта. Проверка сухая: агент только отвечает, ничего не меняет.

Путать плагин и проектный AGENTS.md. Плагин даёт агенту скиллы. AGENTS.md даёт правила конкретного проекта. Одно не заменяет другое.

Считать, что /spp сам принимает продуктовые решения.

Нет.

Он помогает выбрать воркфлоу. Решение о скоупе, компромиссах и приёмке всё равно за человеком.

Короче, SPP — не ещё одна умная команда ради команды. Он про то, чтобы агент не превращал разработку в поток уверенных случайных решений. Сначала границы, потом спека, потом план, потом код.

Работаем дальше.

В этом модуле ты не устанавливаешь SPP с нуля. Установка уже была в модуле 1. Здесь задача — понять, как пользоваться этим процессом перед первым кодом. Иначе SPP останется красивым словом, а агент всё равно уедет писать весь MVP одним махом.

Шаг 1. Проверь, что SPP всё ещё доступны

Открой проект JobTrack и дай агенту сухую проверку:

Используй /spp.

Проверь, доступны ли SPP или skills в этом окружении.
Ничего не меняй в файлах.
Не начинай код.

Ответь:
1. видишь ли ты skills;
2. какие skills относятся к разработке продукта;
3. какой skill или workflow ты бы использовал перед началом новой фичи;
4. что ты не должен делать без моего подтверждения.

Если агент не видит SPP, вернись к модулю 1 и почини установку. Не компенсируй это ручными ритуалами. Дальше курс построен вокруг /spp.

Шаг 2. Попроси объяснить процесс на JobTrack

Теперь попроси агента не кодить, а разложить порядок работы:

Мы строим мой проект и ещё не начали код.

Объясни, как SPP должен вести нас от текущего состояния к первому коду.

Контекст:
- есть docs/discovery.md;
- есть Git checkpoint;
- код приложения ещё не начат;
- MVP нельзя расширять без решения человека.

Ответь коротко:
1. почему нельзя писать весь MVP одним prompt;
2. какие этапы должны быть до первого кода;
3. где нужен review;
4. где нужны проверки;
5. что должно остановить агента.

Ничего не меняй в файлах.

Хороший ответ должен говорить про design/spec, review, plan, одну current task, checks и diff. Если агент снова предлагает сразу создать приложение, он не понял процесс.

Шаг 3. Проверь реакцию на опасный prompt

Дай провокационный запрос:

Вот мой проект. Сделай приложение целиком.

Правильная реакция агента: остановиться перед кодом и сказать, что сначала нужно уточнить задачу, подготовить spec/design, потом plan, потом переходить к реализации. Это не занудство, а предохранитель от каши в diff.

Если агент сразу предлагает писать код, останови:

Стоп. Не начинай код.
Сначала используй /spp и объясни, какой workflow нужен перед реализацией.

Шаг 4. Запиши рабочее правило в AGENTS.md

Добавь короткое правило в раздел «Процесс» файла AGENTS.md проекта:

Перед новой нетривиальной задачей:
1. start with /spp;
2. сначала workflow и scope;
3. затем spec/design или plan, если они нужны;
4. код только после принятой задачи;
5. после кода checks, manual scenario, diff review;
6. commit/push только после подтверждения.

Это правило рабочего процесса. Оно живёт в AGENTS.md, а не в отдельных заметках, чтобы агент видел его в каждой сессии. Закоммить обновлённый AGENTS.md как checkpoint — это проверяемый артефакт модуля 6.