От идеи до проверенного плана продукта

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

Экосистема: Универсальный

Инструкция

---
name: idea-to-blueprint
description: "Turn a raw product, app, bot or feature idea into one evidence-backed build blueprint (researched stack, epics, Given/When/Then criteria, tests) that coding agents build one epic per session."
category: planning
risk: safe
source: self
source_type: self
source_repo: iniesohidham/idea-to-blueprint
date_added: "2026-09-30"
author: iniesohidham
tags: [prd, specification, product-planning, user-stories, acceptance-criteria, tech-stack, agentic-engineering]
tools: [claude, codex]
license: "MIT"
license_source: "https://github.com/iniesohidham/idea-to-blueprint/blob/main/LICENSE"
---

# От идеи до проверенного плана продукта

## Обзор

Преобразуйте сырую идею в единый документ в формате Markdown, который будет достаточно полным для того, чтобы кодирующий агент мог строить продукт эпопея за эпопеей, в новых сессиях, не догадываясь о деталях. Этот план не является "PRD" в широком смысле: это единственная общая память о продукте между человеком, исследованием и каждой будущей сессией разработки.

Навык запускает вопросы для сбора информации, проводит веб-исследования и анализ конкурентов, а затем создает один Markdown-план: драйверы архитектуры и стиль, стек с фиксированными версиями и тегами доказательств, контроль качества, персонажи, потоки, UX-копии, крайние случаи и эпопеи, разбитые на истории с критериями приемки Given/When/Then, тестами и Определением завершенности. План включает в себя протокол сессии, чтобы Claude Code или Codex могли строить его по одной эпопее за новую сессию.

Это собственный навык автора, опубликованный на [iniesohidham/idea-to-blueprint](https://github.com/iniesohidham/idea-to-blueprint) под лицензией MIT (см. `LICENSE`). Файлы в `references/`, `assets/` и `scripts/` являются неизменными копиями исходных файлов; этот `SKILL.md` добавляет разделы каталога (Обзор, Когда использовать, Примеры, Ограничения, заметки по безопасности) вокруг исходных инструкций.

## Когда использовать этот навык

- Используйте, когда кто-то делится идеей продукта, приложения, бота или функции (даже 2–3 строки) и хочет PRD, спецификацию, бэклог, эпопеи, пользовательские истории, дорожную карту или план MVP, даже не упоминая "PRD".
- Используйте, когда пользователь хочет глубокие веб-исследования, рыночные исследования или анализ конкурентов перед тем, как что-либо будет построено.
- Используйте, когда пользователь хочет рекомендацию по архитектуре или стеку технологий с обоснованием и фиксированными версиями, или стандарты качества кода и рецензирования для нового продукта.
- Используйте, когда пользователь запрашивает "план для Claude Code/Codex", который кодирующий агент может выполнить по одной эпопее за раз.
- Предпочитайте его более легким PRD-навыкам, когда важна глубина исследования, строгость или отсутствие галлюцинаций.
- Не используйте его для проверки существующего PRD, для сравнения двух фреймворков в изоляции или для написания единственного элемента UX-копии.

## Как это работает

Запустите этот навык на самом мощном доступном модели с самым высоким уровнем усилий/мышления, который предлагает система. Если вы не можете определить, так ли это, скажите об этом один раз в начале и продолжайте.

### Почему этот документ должен быть другим

Сессия разработки, начинающаяся с пустого контекста, имеет ровно два источника правды: репозиторий и этот план. Все, что отсутствует, неясно или неверно в плане, становится догадкой в коде. Поэтому весь навык организован вокруг трех привычек:

1. **Доказательства или молчание.** Каждое утверждение о внешнем мире (библиотека, версия, конкурент, регулирование, рыночная цифра, доступность услуги в стране) несет тег доказательства: `[VERIFIED — <source>, <date>]`, `[ASSUMED — <why>]` или `[UNKNOWN → OQ-nn]` (направлено на Открытые Вопросы). Вы никогда не заполняете пробел правдоподобной догадкой, потому что читатель не может отличить вашу догадку от факта.
2. **Решайте, не уклоняйтесь.** "Используйте X или Y" перекладывает решение на агента с меньшим контекстом, чем у вас сейчас. Примите решение, запишите альтернативы и причины их отказа.
3. **Пишите для нулевого контекста.** Никаких "как обсуждалось", никаких "обычным образом". Каждый ID (персонаж, поток, экран, строка копии, история, критерий) уникален и перекрестно ссылается, чтобы новая сессия могла разрешить все по поиску.

Все ниже служит этим трем привычкам.

### Рабочий процесс

| Фаза | Что происходит | Ссылка для чтения |
|---|---|---|
| 0. Сбор информации | Разбор идеи, выполнение 2–5 быстрых поисков, задайте ОДНУ партию вопросов с умолчаниями, ожидание | `references/intake-questions.md` |
| 1. Глубокое исследование | Понять домен, провести анализ конкурентов, вывести драйверы архитектуры и форму, выбрать стек для агентного проектирования, проверить качество инструментов, интеграции и реалии локализации, собрать UX-бенчмарки | `references/research-protocol.md`, `references/architecture-decisions.md`, `references/code-quality-and-review.md` |
| 2. Краткое решение | Представить интерпретацию, персонажей, позиционирование, драйверы архитектуры и форму, стек, контроль качества, список эпопей и открытые вопросы в чате; получить согласие/корректировку | (шаблон ниже) |
| 3. Написание плана | Написать документ раздел за разделом, по частям, в один файл `.md` | `references/blueprint-template.md` плюс ссылки на темы, на которые он указывает |
| 4. Линтинг и доставка | Запустить `scripts/lint_blueprint.py`, исправить все ошибки, доставить файл с кратким итогом | (ниже) |
| 5. Сессии разработки | Пользователь запускает одну эпопею за новую сессию Claude Code / Codex, используя протокол, встроенный в план | `references/session-protocol.md` |

Не пропускайте фазы 0 и 2. Пользователь явно хочет, чтобы его спросили перед тем, как будет создан длинный документ, и двухминутная проверка предотвращает создание ста страниц на основе неверной интерпретации. Не выполняйте фазы в неправильном порядке: исследование перед ответами на вопросы о сборе информации тратит поиски на неправильную проблему; написание до утверждения краткого решения тратит документ.

Говорите с пользователем на языке, на котором он написал. Персидский в → персидский из для всего чата и для текста, обращенного к человеку в документе (см. Языковую конвенцию).

### Фаза 0 — Сбор информации

Прочитайте `references/intake-questions.md` перед тем, как задать какие-либо вопросы. Правила, которые имеют наибольшее значение:

- **Сначала разогрейтесь.** Выполните 2–5 быстрых поисков по идее, чтобы вопросы были конкретными ("Я вижу три продукта в этой области — A, B, C — какой из них ближе к тому, что вы имеете в виду?") вместо общих.
- **Одна партия, умолчания для каждого вопроса.** Группируйте вопросы, ставьте разумное умолчание рядом с каждым и говорите, что ответить "умолчания" или пропустить любой вопрос нормально. Никогда не задавайте вопросы по частям.
- **Никогда не спрашивайте то, что уже было отвечено или может быть выведено.** Подсказки из сообщения определяют: язык, валюта, названия городов, местные услуги, ".ir" домены, Джалали даты, "کاربر ایرانی" → пользователи, вероятно, иранцы, поэтому спросите, чтобы *подтвердить* это в одной строке, а не спрашивайте "где ваши пользователи?".
- **Спрашивайте только то, что изменяет архитектуру, персонажей или объем.** Большому продукту нужно около 10–15 вопросов; одной функции нужно 3–6.
- Где существует инструмент UI для извлечения (нажимаемые опции), используйте его для закрытых вопросов; открытые вопросы ставьте в прозе сразу после.

Когда ответы поступят, запишите каждый неотвеченный элемент как строку `[ASSUMED — …]` в ваших заметках; эти строки станут разделом Предположений позже.

### Фаза 1 — Глубокое исследование и анализ

Прочитайте `references/research-protocol.md` и следуйте его семи трекам **в порядке**:

- **A. Понять идею** — концепции домена, словарь (это станет Глоссарием), как проблема решается сегодня, сопредельные регулирования для отметки (никогда не юридические советы).
- **B. Анализ** — 5–10 прямых и косвенных конкурентов (глобальных, плюс местных, когда рынок Иран или другая конкретная страна), матрица функций, поведение лучших в классе по ключевым потокам, общие жалобы пользователей (перефразированные из отзывов, никогда не цитируемые), пробел, который заполняет этот продукт, заявление о позиционировании.
- **C. Драйверы архитектуры и форма** (`references/architecture-decisions.md`) — вывести ранжированные, *измеримые* драйверы качества-атрибутов из персонажей, потолка масштаба, стоимости неудачи основного цикла и реальности хостинга; назвать явные недрайверы; оценить 2–3 кандидатных архитектурных стиля по ним; решить форму, границы модулей и триггеры выхода, которые оправдали бы пересмотр. Проверить рекомендованную структуру фреймворка и возможность механического соблюдения правил границ в кандидатных языках.
- **D. Стек для агентного проектирования** — выбрать язык, фреймворк, базу данных, тестирование и инструменты, используя взвешенные критерии в протоколе (мейнстрим + хорошо документированные, строгая статическая типизация, однокомандный детерминированный `check`, быстрые тесты, LTS/стабильные, немного зависимостей, соответствие хостинга рынку) **и** драйверы из C. Проверить текущие стабильные версии, устаревания и лицензии, и зафиксировать их.
- **E. Контроль качества и инструменты** (`references/code-quality-and-review.md`) — проверить инструменты, которые делают контроль реальным для выбранного стека (форматтер, строгая конфигурация линтинга, флаги проверки типов, тестовый запускатель, покрытие, мутационное тестирование, если поддерживаемое, SAST и аудит зависимостей, сканирование секретов, обнаружение дублирования, проверки доступности, библиотека архитектурных правил), официальный стиль языка, возможности CI выбранного хоста, текущий базовый уровень безопасности для категории, и — только если документ будет их цитировать — текущие определения метрик доставки и текущие доказательства качества кода, созданного ИИ.
- **F. Интеграции и реалии локализации** — платежи, SMS/OTP, электронная почта, карты, пуш-уведомления, магазины приложений, хостинг/CDN. Для Ирана доступность иностранных услуг меняется в зависимости от санкций и фильтрации; проверьте текущий статус для каждого, на который вы полагаетесь, и запишите дату.
- **G. UX-бенчмарки** — ввод в систему, пустые состояния, обработка ошибок и нормы доступности от лучших продуктов в этой области.

C перед D имеет значение. Выбор фреймворка сначала, а затем написание драйверов, которые случайно его оправдывают, является самой распространенной тихой неудачей в документе подобного рода, и это невозможно обнаружить в готовом файле, если не спросить, мог ли какой-либо драйвер изменить ответ.

Записывайте каждый источник (URL, заголовок, дата доступа) по мере продвижения; раздел Источники строится из этого лога, а не восстанавливается позже. Ожидайте 20–60 поисков для целого продукта; отправляйте однострочную записку о прогрессе пользователю каждые несколько поисков ("анализ местных конкурентов…", "проверка песочницы шлюза…") так, чтобы длительная фаза исследования никогда не выглядела застывшей. Если веб-инструменты недоступны, остановитесь и скажите пользователю: план, написанный только из памяти, не может соответствовать стандарту отсутствия галлюцинаций, поэтому либо они включают доступ в интернет, либо документ доставляется с каждым внешним фактом, отмеченным как `[UNVERIFIED]` и предупреждением на обложке.

### Фаза 2 — Краткое решение (контрольный пункт)

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

```
## Decision brief — <product name>
**How I read the idea:** 2–3 sentences. What it is, for whom, and the single outcome it delivers.
**Users are:** <market/country>, <B2C/B2B>, <language(s)>. (confirmed / assumed)
**Personas:** P1 <name> — one line. P2 … (3–5 max, plus anti-personas if useful)
**Benchmark in one paragraph:** who exists, what the best of them do, the gap we take.
**Architecture drivers (top 3):** AD-1 … (target), AD-2 …, AD-3 … — and what we are explicitly NOT optimising for.
**Shape (locked unless you object):** <style> — one line on why it beat <runner-up>, and the trigger that would make us revisit it.
**Stack (locked unless you object):** language · framework · DB · hosting · testing — one line each with the deciding reason and what the runner-up would have bought.
**Quality gate:** `check` = … (expected runtime …); critical e2e paths: …; what we will measure: …
**Design direction:** reference-based (<their reference>) or chosen (<system/style>) — one line.
**Epics in order:** E00 Foundation, E01 …, E02 … (titles only, 6–14 typical)
**Needs your answer before I write:** only genuinely blocking questions, numbered OQ-01…
**Everything else I will assume** as written in the Assumptions table.
Reply "go" to write the full blueprint, or correct any line.
```

Если пользователь предварительно разрешил ("не останавливайтесь, просто пишите"), все равно опубликуйте краткое решение и продолжайте, не дожидаясь ответа. В противном случае дождитесь ответа и внесите исправления в исследовательские заметки.

### Фаза 3 — Написание плана

Прочитайте `references/blueprint-template.md` и держите его открытым; в нем есть полный скелет разделов, целевой уровень глубины для каждого раздела, форматы таблиц и схемы ID. Перед написанием соответствующих разделов прочитайте ссылки на темы, на которые он указывает:

- Персонажи, потоки, экраны, направление дизайна → `references/design-minimal.md`
- UX-письмо и таблицы копий → `references/ux-writing-guide.md` (персидский пакет, когда пользователи иранцы)
- Драйверы архитектуры, решение по стилю, границы модулей, функции соответствия, записи решений → `references/architecture-decisions.md`
- Контроль качества, контрольный список рецензирования, правила качества тестов, метрики и антиметрики → `references/code-quality-and-review.md`
- Реестр крайних случаев и крайние случаи для каждой истории → `references/edge-case-catalog.md`
- Истории, критерии приемки, тесты, Определение завершенности → `references/stories-ac-tests.md`
- Протокол сессии и Эпопея 0 → `references/session-protocol.md` и файлы в `assets/`

Механика написания, которая имеет значение:

- **Пишите частями.** Создайте файл с обложкой и оглавлением, затем добавляйте один основной раздел за каждую операцию записи. Документ на сто страниц, написанный в одном выводе, будет обрезан или спешен; документ, написанный раздел за разделом, сохраняет качество до конца.
- **ID повсюду.** Персонажи `P1…`, потоки `F-01…`, экраны `S-01…`, строки копии `CP-<screen>-<n>`, сущности `ENT-…`, эпопеи `E00…`, истории `E03-S02`, критерии `AC-1…` внутри истории, открытые вопросы `OQ-01…`, крайние случаи `EC-<cat>-<n>`. Линтер и будущие сессии разработки полагаются на них.
- **Текст для машин на английском, текст для человека на языке пользователя** (подробности в Языковой конвенции). Каждый заголовок несет английский якорь, чтобы линтер и кодирующий агент могли находить разделы независимо от языка прозы.
- **Глубина важнее краткости здесь.** Пользователь сказал, что файл на 100 страниц приемлем. Правильная длина — это то, что не оставляет ни одной истории, экрана, строки копии или крайнего случая неуточненными. Убирайте повторения, а не содержание.
- **Каждое решение называет своих проигравших и его цену.** Стек, стиль архитектуры, система дизайна, модель аутентификации, модель данных: укажите рассматриваемые альтернативы, решающее основание и *что бы принесла отклоненная опция*. Решение без указанной стоимости не было решением.
- **Определите форму перед инструментами.** Драйверы архитектуры → стиль архитектуры → технологии. Если драйвер не мог изменить выбор технологии, драйверы являются украшением.
- **Качество указывается, а не предполагается.** Контроль, контрольный список рецензирования и метрики входят в документ с конкретными командами и порогами, потому что рецензент часто является одним человеком, читающим разницу, которую агент произвел за минуту, и стандарт, придуманный во время рецензии, является другим стандартом каждый раз.

### Фаза 4 — Линтинг и доставка

Запустите линтер и исправьте все, что он сообщает как ошибку (предупреждения — это суждения — разрешите или обоснуйте их):

```bash
python3 <this skill's folder>/scripts/lint_blueprint.py <path/to/blueprint.md>
```

Он проверяет обязательные разделы, текст-заполнитель (TODO/TBD/…), уникальность ID истории, что каждая история имеет Критерии приемки / Крайние случаи / Тесты, что каждая эпопея имеет Определение завершенности, что каждый `[UNKNOWN → OQ-nn]` разрешается в запись Открытых Вопросов, что строки стека технологий несут теги доказательства, что каждый персонаж используется хотя бы одной историей и что существует раздел Источники с URL. Он также проверяет уровень качества: что драйверы архитектуры `AD-n` существуют с измеримыми целями и ссылаются на решение по стилю, что команда `check` и контрольный список рецензирования присутствуют в разделе Качества, что функции соответствия объявлены и что ни одна запрещенная метрика производительности (строки кода, коммиты на инженера, покрытие как цель) не появляется.

Затем выполните человеческий проход, который линтер не может: прочитайте Исполнительное резюме, одного персонажа, один поток и одну эпопею от начала до конца, как если бы вы были новой сессией. Все, что вам пришлось вывести, запишите.

Доставка:

- В чате с инструментами файлов: сохраните в каталоге выходов как `<product>-blueprint.md`, представьте его с инструментом представления файлов.
- В Claude Code / Codex: сохраните в `docs/BLUEPRINT.md` в репозитории (или по пути, который указывает пользователь) и также создайте `docs/PROGRESS.md`, `docs/DECISIONS.md`, `AGENTS.md` и `CLAUDE.md` из `assets/`, заполненные для этого продукта, чтобы Эпопея 0 могла начаться немедленно.
- Сообщение о завершении: 5–10 строк. Укажите на таблицу Предположений и Открытые Вопросы, назовите две или три вещи, в которых вы менее всего уверены, и скажите пользователю, что следующим шагом является открытие новой сессии кодирования и вставка подсказки сессии Эпопеи 0 из приложения документа. Не пересуммируйте документ.

### Языковая конвенция

- **Чат и текст, обращенный к человеку** (исполнительное резюме, нарратив исследования, описания персонажей, столбцы обоснования, риски): язык пользователя.
- **Текст для машин**: английский, всегда — заголовки эпопей, предложения историй, критерии приемки, крайние случаи, названия тестов, списки задач, Определение завершенности, архитектура, модель данных, контракты API, конвенции, протокол сессии, имена файлов, ID. Этот текст вставляется в или читается кодирующим агентом; английский делает его однозначным.
- **Копия продукта** (таблицы UX-копий, шаблоны уведомлений/SMS/электронной почты): язык(и) продукта, с колонкой английского глосса, чтобы агент понимал намерение. Иранские пользователи → персидская копия, следуя персидскому пакету.
- **Заголовки**: двуязычные, когда проза не на английском, например, `## 11. راهنمای UX Writing (UX Writing)` — английский якорь должен присутствовать.
- Укажите эту конвенцию один раз в разделе "Как использовать этот документ", чтобы читатель знал, почему язык меняется.

Если пользователь запрашивает другое разделение (все на английском, все на персидском), уважайте это, но сохраняйте ID и идентификаторы, обращенные к коду, на английском независимо от этого.

### Определение рынка по сообщению

Ищите: язык сообщения, слова валюты (تومان، ریال، IRR), иранские города или провинции, иранские услуги (Snapp, Digikala, Shaparak, Bale, Eitaa, Rubika, Zarinpal, Kavenegar…), домены `.ir`, Джалали даты, упоминания о کد ملی, или явное "کاربر ایرانی". Любое из этого → рассматривайте "пользователи находятся в Иране" как рабочую гипотезу, подтвердите это в сборе информации, и если подтверждено, загрузите специфические для Ирана части протокола исследования, руководства по UX-копиям и материала крайних случаев. Применяйте ту же логику для любого другого конкретного рынка, который раскрывает сообщение (создайте эквивалентный пакет локализации из исследования, если не существует заранее подготовленного).

### Обработка ссылок на дизайн

Если пользователь предоставляет ссылку (Figma, URL, скриншоты, бренд-кит): извлеките токены и шаблоны из нее и задокументируйте их как направление дизайна, отмечая, где вы отклоняетесь для удобства использования или RTL. Если нет: выберите направление сами — мобильный первый, минималистичный, стандартные компоненты, хорошо документированная система дизайна, проверенная через поиск — и скажите об этом в кратком решении, чтобы они могли возразить один раз. Никогда не оставляйте дизайн "решить позже"; сессии разработки нуждаются в конкретных токенах и решениях по компонентам.

### Ограничения, которые перекрывают все остальное

- Если идея включает взаимодействие незнакомцев, пользовательский контент, несовершеннолетних, платежи, здоровье или финансовые советы: базовая безопасность (сообщение/блокировка/ограничение частоты, согласие, аудит) включается в ту же эпопею, что и основной цикл, никогда как "приятная опция" позже. Скажите об этом в обосновании этой эпопеи.
- Юридические, налоговые и регуляторные вопросы отмечаются как Открытые Вопросы для профессионала, никогда не отвечаются.
- Держите спецификации модерации и предотвращения злоупотреблений на уровне *того, что делает система*; никогда не пишите логику обхода или списки фильтров слов.
- Никогда не выдумывайте источник, номер версии, функцию конкурента или метрику. `[UNKNOWN]` всегда является приемлемым ответом; уверенный неверный ответ никогда не является таковым.

## Примеры

### Пример 1: Полный продукт из двухстрочной идеи

```text
I want a Telegram bot that helps freelancers track invoices and nudges late clients.
Do the research, pick the stack, write me the PRD and epics so Codex can build it one epic at a time.
```

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

### Пример 2: Внутренний инструмент с меньшим объемом

```text
An internal tool for our 12-person support team to tag and search customer emails from Gmail,
nothing fancy. Give me the full spec with acceptance criteria and tests.
```

### Пример 3: Иранский рынок (персидская проза, английский текст для машин)

```text
یه اپ می‌خوام که رستوران‌های تهران بتونن منوی QR داشته باشن و مشتری از سر میز سفارش بده و با زرین‌پال پرداخت کنه. برام کامل پلن کن که با Claude Code بسازم.
```

Сигналы рынка (персидский, Тегеран, Zarinpal) делают "пользователи находятся в Иране" рабочей гипотезой; агент подтверждает это в сборе информации и загружает специфические для Ирана исследования, UX-копии и материалы крайних случаев.

### Пример 4: Линтинг готового плана

Запустите из папки этого навыка, указывая на файл плана:

```bash
python3 scripts/lint_blueprint.py docs/BLUEPRINT.md
```

Код выхода 0 означает отсутствие ошибок (предупреждения могут остаться); добавьте `--strict`, чтобы завершить с предупреждениями также.

## Лучшие практики

- ✅ Задавайте одну партию вопросов для сбора информации с умолчанием рядом с каждым, затем ждите ответов.
- ✅ Помечайте каждое внешнее утверждение `[VERIFIED — source, date]`, `[ASSUMED — why]` или `[UNKNOWN → OQ-nn]`.
- ✅ Выводите драйверы архитектуры перед выбором стека и указывайте, что бы принесла каждая отклоненная опция.
- ✅ Пишите документ частями, один основной раздел за запись, и запускайте линтер перед доставкой.
- ❌ Не пропускайте контрольный пункт краткого решения перед написанием длинного документа.
- ❌ Не заполняйте пробел в исследовании правдоподобной догадкой; направляйте его в Открытые Вопросы.

## Ограничения

- Нужен веб-поиск, чтобы соответствовать стандарту отсутствия галлюцинаций. Без доступа в интернет план доставляется с каждым внешним фактом, отмеченным как `[UNVERIFIED]` и предупреждением на обложке.
- Целый продукт обычно требует 20–60 поисков и длительной фазы написания, поэтому он медленный и требует много токенов по сравнению с быстрым PRD.
- Юридические, налоговые и регуляторные вопросы отмечаются как Открытые Вопросы для профессионала, никогда не отвечаются.
- Предварительно подготовленный пакет локализации охватывает Иран; другие рынки получают свою локализацию, построенную из исследований во время выполнения.
- `scripts/lint_blueprint.py` проверяет структуру и перекрестные ссылки, а не то, правильны ли исследования; человеческий просмотр на Фазе 4 все еще требуется.
- Навык планирует сборку; код пишется позже в отдельных сессиях кодирования, которые следуют за планом.

## Заметки по безопасности и безопасности

- Единственная команда, которую выполняет навык, это встроенный линтер, `python3 scripts/lint_blueprint.py <blueprint.md>`. Он использует стандартную библиотеку Python, читает один файл, который ему дан, выводит результаты и не делает сетевых вызовов.
- Веб-исследования используют собственные инструменты поиска и извлечения системы; навыку не нужны ключи API или учетные данные. Поисковые запросы описывают идею, поэтому спрашивайте перед поиском деталей, которые пользователь помечает как конфиденциальные.
- Он создает только файлы Markdown: план, а в Claude Code / Codex также `docs/PROGRESS.md`, `docs/DECISIONS.md`, `AGENTS.md` и `CLAUDE.md`. Если любой из этих файлов уже существует, покажите предлагаемые изменения и объедините их с одобрением пользователя вместо перезаписи.
- Он не удаляет файлы, не устанавливает пакеты, не отправляет и не разворачивает.

## Общие ошибки

- **Проблема:** Стек выбирается первым, а драйверы архитектуры пишутся, чтобы оправдать его.
  **Решение:** Запустите исследовательский трек C (драйверы и форма) перед D (стек), и проверьте, что хотя бы один драйвер мог изменить выбор технологии.
- **Проблема:** Документ на сто страниц, написанный в одном выводе, обрезается или спешит.
  **Решение:** Создайте файл с обложкой и оглавлением, затем добавляйте один основной раздел за запись.
- **Проблема:** "Используйте X или Y" оставляет решение на сессии разработки с меньшим контекстом.
  **Решение:** Решите, запишите альтернативы и укажите, почему они проиграли.

## Связанные навыки

- `@spec-driven-development` - Более легкий рабочий процесс спецификации перед кодом, когда глубокие исследования и анализ конкурентов не нужны.
- `@to-prd` - Превращает существующий разговор в PRD без интервью или фазы исследования.
- `@planning-and-task-breakdown` - Разбивает существующую спецификацию на упорядоченные задачи реализации.
- `@brainstorming` - Исследуйте и формируйте идею перед тем, как привязаться к плану.

## Дополнительные ресурсы

- [idea-to-blueprint на GitHub](https://github.com/iniesohidham/idea-to-blueprint)