# GitHub Spec Kit в Claude Code: спецификации вместо промптов > Практическое руководство по GitHub Spec Kit для Claude Code: установка, настройка и этапы Specify, Plan, Tasks, Implement и Converge для разработки на основе спецификаций. Source: https://ailoot.ai/blog/ru/spec-kit-claude-code-spec-driven-development/ Canonical: https://ailoot.ai/blog/ru/spec-kit-claude-code-spec-driven-development/ Language: ru Publisher: Ailoot (https://ailoot.ai/) Translation: guide-219 Revision: sha256-100ffbdcb31e72025db4df984af943f742fe6201f0b31b3232bd9ca927eaee1d
**Ключевые выводы** Spec Kit от GitHub помогает описать задачу обычными словами, а затем подготовить план, разбить работу на задачи и перейти к написанию кода с Claude Code. Инструмент получил 107 000 звёзд на GitHub за 8 месяцев. В опубликованном AWS разборе проекта в области поиска лекарств сообщается о более чем 80 сэкономленных часах на одной функции. В этом руководстве разобраны установка, шаблоны, четыре этапа работы, заключительная проверка и совместное использование Spec Kit с файлом `CLAUDE.md`.
[Документация Ailoot](https://ailoot.ai/docs/) — справочные материалы по сервису.
## Что изменилось в подходе к вайб-кодингу к маю 2026 года?
**Ключевые выводы** Спецификации стали заметной частью разработки с ИИ-агентами. За 8 месяцев GitHub Spec Kit набрал 107 000 звёзд, а в феврале 2026 года AWS опубликовала разбор проекта, где, по сообщению компании, спецификация помогла сэкономить более 80 часов на одной функции. Такой подход предлагает заранее фиксировать требования, чтобы меньше полагаться на импровизацию.
В феврале 2025 года термин «vibe coding» стал известен как описание работы, при которой разработчик полагается на ход генерации и почти не следит за самим кодом. Со временем этим выражением стали называть и неструктурированную работу с ИИ-агентами. В сентябре 2025 года GitHub выпустила [Spec Kit](https://github.com/github/spec-kit). По данным, указанным в исходном материале, инструмент собрал 107 000 звёзд за 8 месяцев. В феврале 2026 года AWS опубликовала [разбор проекта в области поиска лекарств](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/): компания сообщила, что 95% бизнес-логики было создано на основе спецификации, а экономия превысила 80 часов. К концу мая 2026 года разработка на основе спецификаций стала одной из обсуждаемых альтернатив импровизационному подходу. В этом руководстве показано, как установить и применять Spec Kit. ## Что такое Spec Kit и разработка на основе спецификаций?
**Ключевые выводы** Spec-Driven Development (SDD), или разработка на основе спецификаций, ставит спецификацию в центр работы: код реализует требования, зафиксированные в ней. Spec Kit — это CLI-инструмент GitHub, который помогает пройти этапы Specify, Plan, Tasks и Implement, а затем проверить результат на соответствие плану через Converge. Инструмент интегрируется с Claude Code, Cursor, Copilot и другими агентами.
Официальная документация GitHub описывает основную идею так:

Разработка на основе спецификаций меняет порядок приоритетов: код служит спецификации, а не наоборот. Спецификация становится главным результатом проектирования, а код выражает её на выбранном языке и с помощью выбранного фреймворка.

— GitHub Spec Kit Docs, https://github.com/github/spec-kit/blob/main/spec-driven.md
На практике работа проходит в четыре этапа. В Spec Kit к ним добавлен начальный этап constitution, о котором говорится ниже. 1. **Specify** — описать желаемую функцию обычным языком: что она должна делать и зачем, не выбирая способ реализации. 2. **Plan** — подготовить технический план: технологии, архитектура и основные компоненты. 3. **Tasks** — разбить план на конкретные проверяемые задачи и обозначить зависимости между ними. 4. **Implement** — выполнить задачи и написать код; при необходимости работу можно поручить субагентам. В актуальном описанном здесь процессе после Implement следует **Converge**: агент сравнивает готовый результат со спецификацией, планом и списком задач. Если обнаружены пропуски, он добавляет задачи в `tasks.md`. Цикл Implement и Converge повторяют, пока проверка не завершится ответом «Converged». Для этапов используются отдельные markdown-файлы в репозитории и slash-команды Claude Code: `/speckit-specify`, `/speckit-plan`, `/speckit-tasks`, `/speckit-implement` и `/speckit-converge`. В документации Spec Kit команды также записаны через точку, например `/speckit.specify`; в Claude Code они устанавливаются как skills и вызываются через дефис. Если на каком-либо этапе требуется исправление, можно изменить соответствующий markdown-файл и продолжить работу. Spec Kit — один из способов применять SDD. В мае 2026 года для него заявлено более 30 интеграций с ИИ-агентами. В одном репозитории его можно использовать с Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose и другими инструментами. | Этап Spec Kit | Slash-команда | Артефакт в репозитории | |----|----|----| | Constitution | `/speckit-constitution` | `.specify/memory/constitution.md` | | Specify | `/speckit-specify` | `specs/###-feature/spec.md` | | Clarify (необязательный) | `/speckit-clarify` | изменения в `spec.md` | | Plan | `/speckit-plan` | `specs/###-feature/plan.md` | | Checklist (необязательный) | `/speckit-checklist` | контрольный список качества требований | | Tasks | `/speckit-tasks` | `specs/###-feature/tasks.md` | | Analyze (необязательный) | `/speckit-analyze` | отчёт по spec, plan и tasks | | Implement | `/speckit-implement` | код проекта | | Converge | `/speckit-converge` | результат «Converged» или новые задачи в `tasks.md` | В результате в репозитории остаются не только исходники, но и спецификация, план и задачи. Вернувшись к проекту через месяц, можно открыть `spec.md` и восстановить, что именно реализовывали и по какой причине. Эти файлы становятся постоянной рабочей документацией проекта. ## Чем этот подход полезен тем, кто работает с ИИ без написания кода?
**Ключевые выводы** Одна из сложностей работы с ИИ-агентом — непредсказуемый результат при недостаточно точном описании задачи. Структурированная спецификация задаёт общий ориентир и остаётся в репозитории для дальнейшей работы. Пользовательские сценарии, критерии приёмки и уточняющие пометки помогают заранее обнаружить решения, которые иначе пришлось бы угадывать.
Три практических преимущества для человека, который поручает работу ИИ-агенту: - **Более предсказуемый результат.** В запросе «сделай форму регистрации с подтверждением по почте» остаются неуказанные детали. В `spec.md` можно зафиксировать User Stories, Acceptance Scenarios и пометки `[NEEDS CLARIFICATION]`, чтобы выявить неоднозначности до реализации. - **Сохранение контекста проекта.** Через месяц переписка в чате может быть недоступна или забыта, но `spec.md`, `plan.md` и `tasks.md` останутся рядом с кодом в `specs/###-feature/`. Они объясняют и результат, и требования, которые к нему привели. - **Удобство для крупных функций.** Для изменения в одном-двух файлах формальный процесс может не дать заметного преимущества. Когда функция затрагивает 20 файлов и 5 сущностей данных, планирование помогает заранее увидеть объём работы. В разборе AWS проекта TargetID компания сообщила, что 95% бизнес-логики было автоматизировано на основе спецификации. Импровизационный запрос может быстро дать прототип, но этот результат ещё предстоит проверить и поддерживать. Подход с предварительной спецификацией требует времени на старте; для сложной функции это может окупиться за счёт более ясных требований и сохранённых проектных решений. ## Как установить Spec Kit в Claude Code: четыре шага
**Ключевые выводы** Spec Kit устанавливается через `uv` — менеджер пакетов Python от Astral. После установки CLI нужно инициализировать репозиторий с интеграцией Claude Code: команда добавит структуру файлов и набор `/speckit-*` skills. Если `uv` уже установлен, на эти действия может потребоваться около 5 минут; установка с нуля может занять около 10 минут.
**Шаг 1. Установите uv.** Это однократная установка менеджера пакетов. ```bash # macOS / Linux curl -LsSf https://astral.sh/uv/install.sh | sh # Windows powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex" ``` Убедитесь, что установка прошла успешно: ```bash uv --version ``` **Шаг 2. Установите Spec Kit.** Выполните команду: ```bash uv tool install specify-cli --from git+https://github.com/github/spec-kit.git ``` Проверьте версию: ```bash specify --version ``` **Шаг 3. Инициализируйте репозиторий.** Перейдите в каталог проекта или создайте новый и запустите: ```bash specify init --here --integration claude ``` Параметр `--integration claude` выбирает Claude Code. Если не указывать его, Spec Kit предложит выбрать агента в интерактивном списке, а также может спросить, какой тип скриптов использовать. В macOS и Linux выберите `sh`. Если каталог уже содержит файлы, Spec Kit предупредит, что добавит свои файлы к существующим. Сначала сохраните текущие изменения в коммите, затем повторите команду с параметром `--force`. После инициализации в репозитории появится такая структура: ``` .specify/ memory/ constitution.md # правила проекта, их заполняет /speckit-constitution scripts/ templates/ spec-template.md plan-template.md tasks-template.md .claude/ skills/ speckit-constitution/SKILL.md speckit-specify/SKILL.md speckit-clarify/SKILL.md speckit-plan/SKILL.md speckit-checklist/SKILL.md speckit-tasks/SKILL.md speckit-analyze/SKILL.md speckit-implement/SKILL.md speckit-converge/SKILL.md speckit-taskstoissues/SKILL.md ``` **Шаг 4. Запустите Claude Code и проверьте slash-команды.** Выполните команду из того же каталога: ```bash claude ``` В сессии введите `/speckit`. В подсказках должны отобразиться команды `speckit-*`. Если их нет, перезапустите Claude Code, чтобы он перечитал каталог `.claude/skills/`. При наличии `CLAUDE.md` в корне проекта Spec Kit не изменяет этот файл: настройки Spec Kit находятся отдельно, в `.specify/memory/constitution.md`. Spec Kit поддерживает более 30 агентов, но далее рассматривается его использование именно с Claude Code. Для настройки Claude Code также могут пригодиться материалы о [файле CLAUDE.md](https://ailoot.ai/blog/ru/kak-nastroit-claude-md/) и [режиме Plan Mode](https://ailoot.ai/blog/ru/claude-code-plan-mode/). ## Как составить первую спецификацию (Specify)
**Ключевые выводы** Сначала опишите функцию свободным текстом, затем Spec Kit сформирует `spec.md` по шаблону. В нём будут пользовательские сценарии с приоритетами P1/P2/P3, критерии приёмки в формате Given/When/Then, функциональные требования с идентификаторами вроде FR-001 и измеримые критерии успеха. Для неясных мест инструмент добавит `[NEEDS CLARIFICATION: ...]`; эти вопросы нужно решить до перехода к Plan.
В Claude Code запустите: ``` /speckit-specify ``` Когда агент попросит описать функцию, изложите желаемый результат простыми словами, без технических подробностей: ``` Я хочу форму регистрации в моём приложении. Пользователь вводит email и пароль, получает письмо с подтверждением, после подтверждения попадает на дашборд. Подтверждение истекает через 48 часов. Если email всё ещё не подтверждён, аккаунт удаляется в течение следующих 5 минут. Подтверждённый аккаунт никогда не удаляется. ``` В этом иллюстративном примере допустимая задержка удаления уточнена как 5 минут после границы 48 часов. Для настоящего продукта согласуйте её до Plan: точный срок 48 часов требует более строгой реализации и проверок. Агент создаст `specs/001-registration/spec.md` со структурой ниже: ```markdown # Feature Specification: User Registration **Feature Branch**: `001-registration` **Created**: 2026-05-31 **Status**: Draft **Input**: User Description: "Я хочу форму регистрации..." ## User Scenarios & Testing *(mandatory)* ### Primary User Story As a new user, I want to register an account with email confirmation, so that I can access the dashboard with a verified identity. ### Acceptance Scenarios 1. **Given** I am on the registration page, **When** I submit valid email and password, **Then** I receive a confirmation email within 1 minute. 2. **Given** I clicked the confirmation link within 48 hours, **When** I land on the dashboard, **Then** I see my email confirmed in profile. 3. **Given** I have not confirmed at the 48-hour deadline, **When** cleanup runs within the next 5 minutes, **Then** my account is deleted and email is freed for re-registration. 4. **Given** my account is just under 48 hours old or already confirmed, **When** cleanup runs, **Then** the account is not deleted. ## Requirements *(mandatory)* ### Functional Requirements - **FR-001**: System MUST accept registration via [NEEDS CLARIFICATION: email/password only, or also SSO/OAuth?] - **FR-002**: System MUST send confirmation email within 60 seconds - **FR-003**: Confirmation MUST expire at 48 hours; the system MUST delete still-unconfirmed accounts no later than 5 minutes after that deadline and MUST NOT delete confirmed accounts - **FR-004**: System MUST log all registration attempts for [NEEDS CLARIFICATION: how long do we retain logs - 30 days, 90 days, forever?] ### Key Entities - User: email, password_hash, email_verified_at, created_at, deleted_at - ConfirmationToken: token, user_id, expires_at, used_at ## Success Criteria *(mandatory)* - **SC-001**: 95% of confirmation emails delivered within 60 seconds (p95) - **SC-002**: 0 accidental deletions of confirmed accounts - **SC-004**: No deletion before 48 hours; every eligible unconfirmed account is deleted by age 48 hours 5 minutes under the tested workload - **SC-003**: Registration completion rate > 60% (from form open to dashboard) ``` Обратите внимание на `[NEEDS CLARIFICATION: ...]`. Spec Kit ставит такие пометки, если описание не даёт однозначного ответа. До запуска Plan внесите решения в `spec.md` самостоятельно или вызовите `/speckit-clarify`, чтобы агент последовательно задал вопросы в диалоге. Спецификация не должна заранее фиксировать технологии вроде React, Postgres, Prisma или Redis. В ней описывается, что система делает для пользователя и бизнеса; технический стек будет определён на следующем этапе. ## Что происходит на этапе Plan?
**Ключевые выводы** Команда `/speckit-plan` преобразует согласованную спецификацию в технический план: предлагает стек, архитектуру, модули, сущности данных и контракты API. План сохраняется в `specs/###-feature/plan.md`, контракты — в каталоге `contracts/`, а модель данных описывается в `data-model.md`. Claude учитывает правила из `CLAUDE.md` или constitution и существующий код проекта.
Когда `spec.md` готов, выполните: ``` /speckit-plan ``` При необходимости добавьте технологические требования прямо к команде: ``` /speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend для писем ``` Claude изучит `spec.md`, `CLAUDE.md` или `memory/constitution.md`, а также существующий код. Результат `plan.md` может выглядеть так: ```markdown # Implementation Plan: User Registration ## Technical Context - Framework: Next.js 14 App Router - Database: PostgreSQL via Prisma - Email: Resend (single transport) - Validation: Zod schema in shared lib - Auth: NextAuth.js with credentials provider ## Architecture Decisions ### 1. Token storage Tokens stored in DB (table ConfirmationToken), not in JWT. Reason: need server-side revoke on email re-register. ### 2. Email delivery Async via cron `/api/cron/send-confirmation` triggered immediately after registration. Retries handled by Resend. Run `/api/cron/cleanup-unconfirmed` every minute. Delete rows only where created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL. The clarified example allows at most 5 minutes of deletion delay. Verify scheduler lag and completion time against that bound; report a missed bound as a failure, not a successful daily cleanup. ## Data Model See data-model.md ## API Contracts See contracts/ - POST /api/auth/register - POST /api/auth/confirm - GET /api/auth/resend-confirmation ## Implementation Phases 1. Database migration (Prisma schema + migration file) 2. API routes (3 endpoints) 3. UI: registration form + confirmation success page 4. Cron jobs (send + cleanup) 5. Email template 6. Integration tests ``` Файл `data-model.md` описывает сущности и связи между ними. В `contracts/` могут храниться наброски API-контрактов в формате OpenAPI YAML или TypeScript-типы запросов и ответов. Это ещё не работающий код, а описание решений, которые позднее будут реализованы. На этапе Plan спецификация и реализация рассматриваются отдельно: сначала агент формирует и записывает технические решения, затем переходит к дальнейшим этапам. После Tasks можно, до Implement, запустить необязательную команду `/speckit-analyze`. Она проверяет связку `spec.md`, `plan.md` и `tasks.md`, ищет противоречия и задачи, не покрывающие требования. Команда выдаёт отчёт и не меняет файлы. ## Как разбить план на задачи (Tasks)
**Ключевые выводы** Команда `/speckit-tasks` создаёт список конкретных задач с зависимостями и пометками о возможности параллельной работы. Результат сохраняется в `tasks.md` в формате чек-листа, например `[ ] T-001: ...`. Затем задачи можно выполнить через `/speckit-implement` или преобразовать в GitHub Issues командой `/speckit-taskstoissues`.
Когда уже готовы `spec.md` и `plan.md`, запустите: ``` /speckit-tasks ``` Claude разложит план по пунктам в `tasks.md`: ```markdown # Tasks: User Registration ## Phase 1: Database (no dependencies) - [ ] T-001: Add User model to prisma/schema.prisma (parallel-safe) - [ ] T-002: Add ConfirmationToken model to prisma/schema.prisma (after T-001) - [ ] T-003: Generate migration `add-user-registration` (after T-002) ## Phase 2: API contracts (no dependencies) - [ ] T-004: Create Zod schemas in shared/validation/auth.ts - [ ] T-005: Define TypeScript types in shared/types/auth.ts (after T-004) ## Phase 3: Routes (depends on Phase 1+2) - [ ] T-006: Implement POST /api/auth/register - [ ] T-007: Implement POST /api/auth/confirm - [ ] T-008: Implement GET /api/auth/resend-confirmation ## Phase 4: UI (parallel with Phase 3) - [ ] T-009: Build /register page with form - [ ] T-010: Build /register/confirm/[token] page - [ ] T-011: Build /register/success page ## Phase 5: Cron + integration (depends on Phase 3+4) - [ ] T-012: Cron /api/cron/send-confirmation - [ ] T-013: Cron /api/cron/cleanup-unconfirmed - [ ] T-014: Email template registration-confirmation.tsx - [ ] T-015: Integration tests (Playwright), including cleanup just before 48h, exactly at 48h, deletion by 48h 5m, delayed-job failure, and protection of confirmed accounts ## Notes - T-001, T-004, T-009-T-011 are parallel-safe (different files) - T-002 conflicts with T-001 (same file: schema.prisma) - run sequentially - T-006 needs T-003 (migration applied) and T-005 (types) ``` Метки `parallel-safe` и `after T-NNN` задают зависимости: одни задачи допустимо выполнять параллельно, другие — только по очереди. Например, несколько сессий Claude Code могут заниматься разными задачами одновременно, если они не редактируют одни и те же файлы. Команда `/speckit-taskstoissues` может создать GitHub Issues из `tasks.md`, добавив к каждой ссылку на `spec.md`. Это удобно для командной работы и отслеживания статуса в GitHub Projects. ## Как выполнять задачи с помощью субагентов (Implement)
**Ключевые выводы** Команда `/speckit-implement` запускает выполнение задач из `tasks.md` и отмечает готовые пункты как `[x]`. Работу можно разделить между несколькими сессиями Claude Code, если заранее учесть зависимости и пересечение файлов. В отдельных задачах можно задействовать субагентов для проверки кода, тестирования или подготовки документации.
``` /speckit-implement ``` Claude берёт первую невыполненную задачу из `tasks.md`. Для каждого пункта он читает необходимые файлы, вносит изменения, запускает предусмотренные проверки и помечает задачу `[x]`. Отдельные субагенты можно поручить, например, проверку кода, запуск линтера или поиск регрессий. В Spec Kit ход работы фиксируется в трёх связанных артефактах: `spec.md` содержит требования, `plan.md` — технические решения, а `tasks.md` — список работ. Если реализация не соответствует требованию, можно сослаться на его идентификатор, например FR-003, и запросить исправление. Если в проекте настроены рабочие процессы с субагентами, их можно применять при выполнении `/speckit-implement`, распределяя независимые задачи и проверяя результаты. Количество и параллельность таких задач следует соотносить с их зависимостями и ограничениями проекта. Когда задачи отмечены `[x]` и Converge подтверждает соответствие, проверьте изменения и выполните слияние. Файлы `spec.md`, `plan.md` и `tasks.md` останутся в репозитории как документация функции. ## Как проверить полноту реализации (Converge)
**Ключевые выводы** После Implement запустите `/speckit-converge`. Агент сравнит результат с `spec.md`, `plan.md` и `tasks.md`. При полном совпадении он ответит «Converged»; если обнаружит пропуски, добавит задачи в конец `tasks.md`. В последнем случае выполните новые задачи и запустите проверку повторно.
``` /speckit-converge ``` После сводки замечаний с указанием их важности агент выдаёт один из двух результатов. Ответ «Converged» означает, что пропуски не обнаружены и `tasks.md` не изменён. Ответ «Tasks appended» означает, что новые пункты добавлены в раздел Convergence файла `tasks.md`. Converge не изменяет код: его запись ограничивается добавлением задач в `tasks.md`. Запускайте проверку после того, как `/speckit-implement` обработал имеющийся список. После выполнения обнаруженных задач проверку можно повторить. ## Чем Spec Kit отличается от CLAUDE.md и Plan Mode?
**Ключевые выводы** `CLAUDE.md` хранит постоянные правила проекта, Plan Mode помогает составить план для отдельного запроса, а Spec Kit охватывает весь цикл одной функции — от требований до реализации. Эти средства можно сочетать: общий контекст проекта, constitution с правилами процесса и набор артефактов конкретной функции (`spec.md`, `plan.md`, `tasks.md`).
Сравним их по основным характеристикам: | Характеристика | CLAUDE.md | Plan Mode | Spec Kit | |----|----|----|----| | Когда используется | В каждой сессии | По запросу (Shift+Tab или /plan) | Через slash-команду /speckit-* | | Срок действия | Весь проект | Одна сессия | Одна функция | | Где хранится | Корень репозитория | В контексте Claude | `specs/###-feature/*` | | Что содержит | Стек, правила, словарь | Текущий план и наблюдения | spec + plan + tasks + contracts | | Формат | Свободные правила репозитория | Без фиксированного шаблона | Структурированный markdown | | Основная задача | Правила и стек проекта | Перепроверка перед крупным изменением | Полный цикл функции: от требований до кода | В Spec Kit роль правил проекта выполняет файл `.specify/memory/constitution.md`. При инициализации можно использовать существующие правила проекта как основу constitution либо вести этот файл отдельно. Например, в нём можно указать, что формы должны валидироваться через Zod, а ручные проверки использовать нельзя. Plan Mode предназначен для планирования внутри одной сессии и может подойти для небольшого исправления или рефакторинга. Для крупной функции отдельные файлы спецификации, плана и задач помогают сохранять решения между сессиями. Spec Kit переносит описание требований и архитектурных решений из переписки в файлы репозитория. Новая сессия может обратиться к этим материалам, поэтому требования не нужно каждый раз заново собирать из истории чата. Для большого проекта можно выстроить работу так: 1. **CLAUDE.md** — стек, словарь и ограничения проекта; файл находится в корне. 2. **.specify/memory/constitution.md** — правила процесса, используемые Spec Kit. 3. **specs/001-feature-A/spec.md, plan.md, tasks.md** — документы первой функции. 4. **specs/002-feature-B/spec.md, plan.md, tasks.md** — документы второй функции. 5. Для выполнения готовых задач запускайте `/speckit-implement`, а перед быстрым изменением используйте `/plan`, если нужна дополнительная проверка плана. ## Какие результаты опубликованы?
**Ключевые выводы** В опубликованном AWS разборе проекта TargetID указано, что Kiro создал более 95% кода бизнес-логики и сэкономил свыше 80 часов работы над одной функцией. В том же материале приведены показатели Rackspace Technology. Эти цифры отражают заявления, опубликованные в источнике AWS; они не гарантируют такой же результат в другом проекте.
В материале AWS о проекте TargetID, опубликованном 18 февраля 2026 года, описана работа трёх разработчиков над агентом для поиска лекарств за три недели. По данным AWS, Kiro сгенерировал более 95% кода бизнес-логики, что позволило сэкономить более 80 часов разработки. Там же сообщается, что подготовленная Kiro документация README сэкономила, по оценке команды, около 8 часов, а число итераций «промпт и исправление» сократилось на 40%. В том же блоге AWS приводит показатели Rackspace Technology: 52 недели оценённой работы были выполнены за 3 недели, а эффективность выросла на 90%. Это данные, приведённые самой AWS в её публикации. В репозитории GitHub Spec Kit число звёзд выросло с 93 000 на 7 мая 2026 года до 107 000 на 31 мая. Эти значения показывают динамику популярности репозитория, но сами по себе не подтверждают эффективность метода в каждом проекте. ## В каких случаях Spec Kit не подходит?
**Ключевые выводы** Полный цикл Spec Kit может быть избыточен для небольших правок, ранних экспериментов и проектов, где требования быстро меняются. В таких случаях подготовка и обновление спецификации требуют отдельного времени. Выбирайте глубину планирования с учётом масштаба функции и того, насколько устойчивы её требования.
**Случай 1 — небольшие правки.** Для переименования переменной, исправления опечатки или добавления записи в лог последовательность Specify, Plan и Tasks может оказаться дольше самого изменения. Для такой работы может хватить прямого запроса или Plan Mode. **Случай 2 — исследовательские эксперименты.** Если цель пока не определена и нужно попробовать интерфейс или быстро собрать прототип, подробную спецификацию может быть рано составлять. Сначала проверьте идею, а затем зафиксируйте требования, когда они станут яснее. **Случай 3 — легаси-системы с часто меняющимися требованиями.** Спецификация требует обновления при изменениях бизнес-логики. Например, правила расчётов и налогов для подписок могут измениться ещё до выпуска функции. Если требования меняются быстро, поддержка подробных документов сама становится частью работы. Ещё один риск — принять наличие документов за гарантию корректной реализации. Структурированный план облегчает проверку, но не доказывает, что агент правильно понял требования или учёл особенности репозитория. Результат всё равно нужно сверять с кодом и ожидаемым поведением. Большая спецификация, написанная задолго до первой проверки работающего решения, может привести к каскадной модели разработки. Чтобы уменьшить этот риск, проверяйте ключевые предположения по мере реализации и обновляйте требования при изменении условий. **Как выбрать процесс.** Ориентируйтесь на объём функции и время, необходимое для её описания. Если реализация займёт меньше 2 часов, прямой запрос или Plan Mode могут быть практичнее. Для функции, рассчитанной на неделю работы, Spec Kit может помочь согласовать требования и сохранить решения. В промежуточных случаях выбирайте процесс с учётом сложности и ценности документации для команды. ## Как начать использовать Spec Kit в проекте?
**Ключевые выводы** Начните с одной новой функции, а не с перестройки всего проекта. Установите Spec Kit, инициализируйте репозиторий и пройдите Specify, чтобы оценить созданную спецификацию. Практика на небольшой задаче поможет понять, когда нужен полный цикл, а когда достаточно короткого запроса.
План на ближайшие 7 дней: - **День 1.** Установите `uv` и Spec Kit; это может занять 5–10 минут. Убедитесь, что команды `/speckit-*` доступны в Claude Code. Для первой попытки выберите новый репозиторий. - **День 2.** Выберите реальную функцию и запустите `/speckit-specify`, описав её свободным текстом. Прочитайте `spec.md` и разберите все пометки `[NEEDS CLARIFICATION]`, прежде чем продолжать. - **День 3.** Запустите `/speckit-plan`, добавив сведения о стеке. Проверьте `plan.md`, особенно раздел Architecture Decisions. При необходимости отредактируйте документ. - **Дни 4–5.** Запустите `/speckit-tasks`, затем `/speckit-analyze` для проверки согласованности `spec`, `plan` и `tasks`, после чего выполните `/speckit-implement`. Следите за отметками `[x]` в `tasks.md`. Если агент остановится, уточните требование в `spec.md` и поручите ему конкретную задачу. Когда список будет выполнен, запускайте `/speckit-converge`; при обнаружении новых задач повторяйте Implement и Converge до ответа «Converged». - **Дни 6–7.** Проведите ревью PR или серии PR и выполните слияние. Сохраните `spec.md` и `plan.md` как документацию функции. Для продолжения могут пригодиться другие руководства Ailoot: - [Как настроить CLAUDE.md в 2026 году](https://ailoot.ai/blog/ru/kak-nastroit-claude-md/) — основа контекста проекта и правил Spec Kit. - [Plan Mode в Claude Code](https://ailoot.ai/blog/ru/claude-code-plan-mode/) — быстрый вариант для небольших задач. - [Контекстная инженерия в 2026 году](https://ailoot.ai/blog/ru/context-engineering/) — принципы работы с контекстом проекта. - [Skills, Subagents, MCP или Plugins](https://ailoot.ai/blog/ru/skills-subagents-mcp-plugins-claude-code/) — способы дополнить рабочий процесс. - [Dynamic Workflows в Claude Code](https://ailoot.ai/blog/ru/claude-code-dynamic-workflows/) — использование субагентов на этапе Implement.
### Официальные источники - [GitHub Spec Kit — репозиторий](https://github.com/github/spec-kit) - [GitHub Spec Kit — документация](https://github.github.com/spec-kit/) - [GitHub — описание разработки на основе спецификаций](https://github.com/github/spec-kit/blob/main/spec-driven.md) - [GitHub — шаблон спецификации](https://github.com/github/spec-kit/blob/main/templates/spec-template.md) - [AWS Industries — проект Kiro в области поиска лекарств, 18 февраля 2026 года](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) - [Anthropic — субагенты Claude Code](https://code.claude.com/docs/en/sub-agents) - [Anthropic — Skills для Claude Code](https://code.claude.com/docs/en/skills) - [Anthropic — команды Claude Code](https://code.claude.com/docs/en/commands)
Дополнительные материалы доступны на [Ailoot](https://ailoot.ai/). ## Вопросы и ответы ### Почему ежедневной очистки недостаточно для требования 48 часов? Аккаунт, достигший границы сразу после запуска, может ждать почти ещё сутки. Уточните допустимую задержку в спецификации, подберите расписание и проверьте границу 48 часов и максимальную задержку. ### Что делать при противоречии plan.md и spec.md? Вернитесь к требованию до реализации. Согласованно обновите спецификацию, план, задачи и приёмку. Затем через Analyze и проверки реализации подтвердите одинаковое согласованное поведение. ## Ailoot · Компания и портфель её проектов Ailoot опирается на накопленный опыт работы, большую клиентскую базу, стабильный сервис и постоянный контроль KPI. Компания и портфель её проектов: миллионы клиентов; продажи на миллиарды ежемесячно. Этот опыт Ailoot использует для API-доступа к нейросетям в продуктах клиентов, агентах, приложениях и автоматизациях.