Урок 16.7. Процесс оценки идей

Зачем это нужно

SDD строит фичу из спецификации, багфикс чинит сломанное. Но есть третья, более ранняя задача: решить, заслуживает ли идея вложений вообще - до обязательства решением, планом и кодом. Ошибка здесь самая дорогая: недели реализации тратятся на проблему, которой нет.

Bundled, opt-in расширение assess дает такой процесс: пять стадий intake -> research -> define -> shape -> decide, итог - обоснованное подтверждениями решение go, needs-clarification или kill, а не реализация. Процесс автономен: работает в инициализированном проекте без исходного кода и не запускает SDD автоматически. Подходит и не-программным решениям.

Основная идея

Оценка движется от сырой идеи к решению через артефакты - по одному на стадию, все в .specify/assessments/<slug>/:

flowchart LR A["/speckit.assess.intake захват идеи"] --> B["/speckit.assess.research за и против"] B --> C["/speckit.assess.define проблема и цели"] C --> D["/speckit.assess.shape варианты концепции"] D --> E["/speckit.assess.decide вердикт"] E --> F{"решение"} F -- go --> G["опциональная передача в SDD"] F -- needs-clarification --> H["уточнить артефакты"] F -- kill --> I["зафиксировать обоснование"]

Ключевой принцип: research обязан включать подтверждения против идеи - стадия бросает идее вызов, а не строит дело в ее защиту. Непроверяемые утверждения остаются помеченными как ASSUMPTION; цитаты не выдумываются, неопределенные подтверждения не выдаются за факты.

Установка

Установите Spec Kit и инициализируйте проект: пустого достаточно; если идея связана с существующим кодом - используйте существующий репозиторий (урок 16.17). В терминале в корне проекта:

bash
specify extension add assess

Запустите coding-агент в этом каталоге. Примеры - skills-режим Copilot (/speckit-assess-*); у других агентов свой синтаксис вызова (урок 16.10). Каждую команду вызывайте отдельно, ревьюя артефакт до перехода.

Команды и артефакты

Команда	Назначение	Выход
`/speckit.assess.intake`	захват идеи из текста, URL, тикета или указателя на кодовую базу	`intake.md`
`/speckit.assess.research`	сбор подтверждений за и против, с источниками и уверенностью	`research.md`
`/speckit.assess.define`	определить пользователей, проблему, цели, не-цели, метрики, цену бездействия	`problem.md`
`/speckit.assess.shape`	сравнить варианты уровня концепции, appetite и trade-offs	`concept.md`
`/speckit.assess.decide`	зафиксировать скоркард, вердикт, обоснование и опциональный handoff в SDD	`decision.md`

Начальная идея и slug передаются в intake, дальше slug переиспользуется:

/speckit.assess.intake "Let users work offline and sync when they reconnect." slug=offline-mode
/speckit.assess.research slug=offline-mode
/speckit.assess.define slug=offline-mode
/speckit.assess.shape slug=offline-mode
/speckit.assess.decide slug=offline-mode

Прохождение стадий

1. Захват идеи

/speckit-assess-intake "Let users work offline and sync when they reconnect." slug=offline-mode

Можно передать URL, тикет или указатель на кодовую базу. Агент фиксирует ввод в intake.md. Slug - общий хэндл всех пяти стадий.

2. Исследование подтверждений

/speckit-assess-research slug=offline-mode

Агент собирает подтверждающие и опровергающие подтверждения в research.md. Отревьюйте источники и уровни уверенности: непроцитированные допущения - не установленные факты. Стадия должна бросать идее вызов, а не только строить дело за нее.

3. Определение проблемы

/speckit-assess-define slug=offline-mode

Агент пишет problem.md: затронутые пользователи, проблема, цели, не-цели, метрики успеха и цена бездействия.

4. Формирование вариантов решений

/speckit-assess-shape slug=offline-mode

Агент сравнивает варианты уровня концепции, ограничения, appetite и trade-offs в concept.md. Детальная архитектура, задачи реализации и изменения исходников сознательно вне процесса.

5. Решение

/speckit-assess-decide slug=offline-mode

Агент записывает скоркард, обоснование и вердикт в decision.md. Скоркард оценивает критерии как strong, adequate, weak или unknown с обоснованиями из артефактов:

Вердикт	Требование или значение	Что делать
`go`	валидность проблемы и сила подтверждений минимум `adequate`, рекомендована концепция	решать, действовать ли; программную идею опционально передать в SDD
`needs-clarification`	именованные неизвестные блокируют защищаемое решение; слабые/неизвестные подтверждения или отсутствие концепции не оправдывают `go`	уточнить затронутые артефакты недостающей информацией
`kill`	идея не стоит усилий сейчас; решающая причина фиксируется явно	сохранить зафиксированное обоснование; остановка - успешный исход

Задокументированное решение остановиться - полезный результат: зафиксированное обоснование экономит будущие обсуждения той же идеи.

Пререквизиты и охват

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

define может работать прямо из пользовательского ввода; intake и research для определения проблемы опциональны;
shape требует problem.md и остается на уровне концепции; архитектура, модели данных, API, задачи и реализация принадлежат delivery, не оценке;
decide требует problem.md и читает все доступные артефакты оценки; вердикт go дополнительно требует сформированную концепцию и достаточные подтверждения - пропуск research не отменяет требования к подтверждениям.

Slug и существующие артефакты

Slug идентифицирует каталог одной идеи. Пользовательские slug нормализуются в lowercase kebab-case и сохраняются без добавленных таймстампов или номеров. Без slug intake спросит интерактивно; автоматические запуски генерируют уникальный. Поздние стадии могут взять slug из контекста, когда его каталог существует.

Существующие артефакты не перезаписываются без подтверждения; в автоматическом режиме команды отказываются перезаписывать. Для рутинного уточнения - дорабатывайте существующий артефакт, а не перезапускайте команду.

Уточнение вместо перегенерации

Обычный поток запускает каждую команду один раз. Если артефакт содержит маркеры [NEEDS CLARIFICATION: ...] или вердикт - needs-clarification, правьте затронутый Markdown напрямую или просите агента в свободной форме включить недостающие факты:

Update .specify/assessments/offline-mode/problem.md with these confirmed success metrics: <your metrics>. Update any dependent wording and revise decision.md if this resolves the blocker. Preserve source and confidence tags.

Правила этого паттерна: не перегенерировать стадию целиком автоматически; попросить агента проверить, снимают ли новые факты блокер, и доработать зависимый скоркард, вердикт или handoff; сохранить теги источников и уверенности. Перезапуск команды - исключение (неверный slug, отброшенный черновик), и существующие артефакты не перезаписываются без подтверждения.

Handoff и guardrails

Решение go включает handoff-сводку, которую можно передать в /speckit.specify. Никакие lifecycle-хуки не устанавливают оценку пререквизитом SDD; не-программные идеи могут вообще не входить в SDD. Опциональная передача:

/speckit-specify Use the handoff summary in .specify/assessments/offline-mode/decision.md to specify the approved offline-mode concept.

Команды оценки пишут только внутри .specify/assessments/<slug>/; исходный код они не редактируют. Расширение проверяет slug и пути, обращается с загружаемым контентом как с недоверенными данными и применяет политику доверия URL. Полные guardrails и связи с другими расширениями - в документации расширения assess репозитория.

Практика

Оцените реальную идею из своего бэклога (можно не-программную): пройдите пять стадий со slug и прочитайте все пять артефактов. Особенно отревьюйте research.md: есть ли там подтверждения против?
Проверьте паттерн уточнения: добейтесь вердикта needs-clarification (задайте идею с пробелами) и снимите блокер правкой артефакта, без перезапуска команды.
Возьмите идею, которую недавно «похоронили» без документирования. Оцените, что зафиксировал бы kill-вердикт и какие будущие обсуждения он бы закрыл.

Краткое резюме

Расширение assess - пятистадийная оценка идей: intake (захват), research (подтверждения за и против с источниками), define (проблема, цели, метрики), shape (варианты концепции), decide (скоркард и вердикт go / needs-clarification / kill). Процесс автономен, работает без кода, не запускает SDD; уточнение делается правкой артефактов, а не перегенерацией.

Главное из урока:

вердикт go требует минимум adequate по валидности проблемы и силе подтверждений плюс сформированную концепцию;
research обязан содержать подтверждения против; непроцитированные утверждения остаются ASSUMPTION;
[NEEDS CLARIFICATION] и needs-clarification лечатся доработкой артефакта с сохранением тегов источников;
остановка (kill) с зафиксированным обоснованием - успешный исход;
handoff в SDD опционален и не автоматичен.

Вопросы для самопроверки

Перечислите пять стадий оценки и артефакт каждой. Какие стадии опциональны для определения проблемы?
Какие дополнительные требования предъявляет вердикт go сверх наличия problem.md?
Почему research должен включать подтверждения против идеи? Как маркируются непроцитированные утверждения?
Опишите правильный ответ на needs-clarification: что правится, что сохраняется, когда допустим перезапуск команды?
Как оценка связывается с SDD? Может ли не-программная идея пройти весь процесс?
Какие guardrails применяет расширение к slug, путям и загружаемому контенту?

Что дальше

Три процесса агента разобраны. Урок 16.8 уходит в концепции под ними: модели хранения спецификаций, декомпозиция сложных фич и «спека спек» - как сам Spec Kit описан спецификациями.