User-spec с Claude: от идеи к техспеку без хаоса

Бизнес-идея есть, вдохновение есть, а вот tech-spec обычно превращается в болото. Размытые требования, “ну тут как-нибудь”, и документ, который никто не читает. В 2026 году это уже не норма. С Claude можно выстроить другой процесс: спокойный, формализованный и удивительно рабочий.

Почему user-spec — это реальный скилл, а не бумажка

Большинство команд до сих пор пытаются перепрыгнуть из идеи сразу в архитектуру. Claude ломает эту привычку. User-spec — это не описание кнопок, а структурированное понимание проблемы глазами пользователя. Именно поэтому в AI-first подходе он вынесен в отдельный навык.

В claude-code-framework этот навык реализован как отдельный skill — user-spec-planning. Он не генерирует док по шаблону, а проводит интервью. Задает неудобные вопросы. Фиксирует edge-cases. Результат — user-spec.md, который реально можно согласовать с бизнесом.

Как выглядит поток: idea → user-spec → tech-spec

Практика 2026 года показывает, что лучше всего работает жесткий пайплайн. В рамках Claude Code он выглядит так:

• /new-user-spec — Claude выступает как бизнес-аналитик, а не разработчик
• Формируется user-spec.md на русском языке
• Документ утверждается без архитектурного шума
• /new-tech-spec — только после этого Claude переходит к технике

Ключевой момент: Claude не пытается угадать архитектуру, пока user-spec не закрыт. Это радикально снижает количество переделок.

Что именно делает user-spec-planning сильным

Если свести всё к практике, у этого скилла есть три киллер-фичи.

1. Интервью, а не промпт

Claude работает итеративно. Он спрашивает “зачем”, “что считается готовым”, “что будет, если”. Это похоже на работу хорошего PM, а не на генерацию текста.

2. Критерии готовности

Каждый user-spec содержит acceptance criteria. Это золото для Next.js команд: потом эти критерии один к одному уезжают в тесты.

3. Edge-cases по умолчанию

Claude методично ищет пограничные сценарии. Не потому что умный, а потому что skill так устроен.

Переход к tech-spec: где обычно ломаются

На этапе tech-spec-planning Claude уже не фантазирует. Он читает user-spec.md и строго из него выводит архитектуру. В хороших кейcах это выглядит как:

• чистая декомпозиция на non-breaking tasks
• понятная интеграция с Next.js app/router
• отсутствие “а давайте потом подумаем”

Именно поэтому создатели Claude Code так настаивают на Plan mode и spec-driven workflow (см. советы Бориса Черного).

Реальный кейс: Next.js SaaS без хаоса

Команда из трех разработчиков. Идея — B2B дашборд. Раньше они писали tech-spec сразу. Итог — две недели рефакторинга.

С user-spec-planning процесс изменился: один вечер на интервью, один день на согласование, и только потом техника. По их оценке, количество переделок упало примерно вдвое.

Мысль на вынос

User-spec-planning — это не про Claude. Это про дисциплину мышления. Claude просто заставляет ее соблюдать. Если вы в 2026 году все еще прыгаете из идеи в код, попробуйте остановиться. Сначала спросите пользователя. Даже если этот пользователь — Claude.