Промты для создания сайта с помощью ИИ: библиотека от брифа до запуска

Ты работаешь как редактор брифа. Подготовь бриф сайта на основе данных ниже.

Продукт: [PRODUCT]
Аудитория и ситуация: [AUDIENCE]
Главное действие посетителя: [ACTION]
Подтверждённые факты и доказательства: [PROOF]
Ограничения по сроку, платформе, тону и функциям: [CONSTRAINTS]

Сначала раздели сведения на ФАКТЫ, ДОПУЩЕНИЯ и НЕИЗВЕСТНО. Не выдумывай цены, отзывы, гарантии, статистику и юридические условия. Затем верни: 1) цель сайта одной фразой; 2) один основной сегмент; 3) предложение без рекламных клише; 4) главное действие; 5) необходимые доказательства; 6) функциональные требования; 7) ограничения; 8) вопросы, без которых нельзя продолжать. Формат - Markdown с короткими списками.

Проверь бриф по правилу: если утверждение нельзя подтвердить входными данными, перенеси его в НЕИЗВЕСТНО. Покажи только изменения и обновлённый список блокирующих вопросов.

На основе утверждённого брифа спроектируй карту сайта.

Бриф: [APPROVED_BRIEF]
Существующие страницы и их задачи: [CONTENT_INVENTORY]
Обязательные страницы: [MANDATORY_PAGES]

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

Верни: 1) таблицу задач; 2) иерархию страниц; 3) назначение каждой страницы одной фразой; 4) primary intent; 5) входящие и исходящие внутренние ссылки; 6) список дублей MERGE/HOLD; 7) неизвестные, требующие исследования.

Сделай проверку на дубли: сравни каждую предложенную страницу с [CONTENT_INVENTORY]. Для близких пар укажи MERGE, KEEP-BOTH с разными задачами или HOLD. Не переписывай остальную карту.

Подготовь спецификацию страницы.

Задача страницы: [PAGE_JOB]
Подтверждённые факты и первичные источники: [EVIDENCE]
Нужные внутренние связи: [LINKS]
Главное действие: [CTA]
Риски и запрещённые утверждения: [RISKS]

Верни: title, meta description, H1, answer-first блок до 60 слов, H2-H3 outline, цель каждого раздела, нужные доказательства, таблицы/визуалы, CTA, состояния формы, internal links и acceptance QA. Помечай [SOURCE REQUIRED] и [EXPERT REVIEW] там, где данных недостаточно. Не пиши финальный текст и не добавляй FAQ/schema автоматически.

Проведи ревизию как выпускающий редактор: удали разделы без отдельной задачи, добавь evidence slot к каждому сильному claim и верни только исправленную спецификацию.

Напиши черновик страницы строго по спецификации.

Спецификация: [SPEC]
Реестр подтверждённых фактов с URL и датами: [FACT_LEDGER]
Требования к стилю: [VOICE]
Запрещённые обещания и формулировки: [BANNED]

Правила: не придумывай цифры, кейсы, отзывы, должности, гарантии, цены, ссылки и условия. Если факта нет, поставь [FACT REQUIRED: что проверить]. Каждый H2 начни с прямого ответа, затем объясни действие и ограничение. Пиши короткими абзацами, не повторяй вывод соседнего блока. Ссылку на источник ставь рядом с утверждением. В конце верни отдельный список всех незакрытых маркеров.

Сравни черновик с [FACT_LEDGER]. Для каждого утверждения без опоры поставь [FACT REQUIRED] или удали его. Не улучшай стиль и не добавляй новых фактов.

Сформируй минимальную дизайн-систему сайта.

Бренд и допустимый характер: [BRAND]
Типы страниц и контента: [CONTENT_TYPES]
Технический стек: [DEV_STACK]
Требования доступности: [A11Y]

Верни: цветовые роли с проверяемым контрастом, типографическую шкалу, spacing tokens, сетку и breakpoints, список компонентов, их варианты и состояния default/hover/focus/disabled/error/loading/empty, правила изображений и таблиц. Для каждого решения объясни задачу, а не настроение. Не заявляй соответствие WCAG без инструментальной и ручной проверки. Формат - tokens table и component contracts.

Преобразуй общие прилагательные в tokens, размеры, состояния и acceptance checks. Сохрани только решения, которые можно проверить в браузере.

Создай текстовый wireframe страницы и responsive rules.

Спецификация: [PAGE_SPEC]
Доступные компоненты: [COMPONENTS]
Контрольные viewport: [VIEWPORTS]
Реальный контент и самые длинные значения: [CONTENT]

Для desktop и mobile опиши порядок блоков, ширины, grid, навигацию, CTA, таблицы, формы, модальные элементы и состояния. На mobile не просто складывай колонки: сохрани порядок решения пользователя и доступ к главному действию. Для каждой секции укажи содержание above the fold, условие переноса, поведение длинного текста и manual QA. Не используй горизонтальный scroll, кроме явно обозначенных data tables/code blocks.

Проверь wireframe на 390×844 с самыми длинными значениями. Верни только проблемы переполнения, порядка фокуса и недоступных действий и точные исправления.

Подготовь production implementation plan для существующего проекта.

Контекст репозитория и текущие компоненты: [REPO_CONTEXT]
Спецификация страницы: [PAGE_SPEC]
Дизайн-система: [DESIGN_SYSTEM]
Ограничения по файлам, зависимостям и публикации: [CONSTRAINTS]

Сначала перечисли файлы, которые нужно прочитать, и неизвестные. Затем предложи минимальный diff: files owned, components reused, semantic HTML, data flow, form states, tests, security/privacy checks, build command, preview and rollback. Не создавай новую библиотеку, если компонент уже есть. Не вставляй secrets и не публикуй. Код показывай только после согласованного плана и по одному файлу с объяснением проверки.

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

Проведи SEO preflight страницы по rendered HTML.

HTML: [RENDERED_HTML]
Primary intent и query: [TARGET_INTENT]
Current URL/title/H1 inventory: [INVENTORY]
Current sitemap/canonical policy: [SITEMAP]

Проверь: status assumption, title, description, one H1, heading hierarchy, answer-first coverage, canonical, robots, OG, Article/Breadcrumb schema eligibility, images, internal links, anchor uniqueness, orphan risk, duplicate intent and sitemap consistency. Не рекомендуй FAQPage или HowTo rich-result markup. Не обещай рейтинг. Верни PASS/FAIL table, evidence, exact safe fix and HOLD items requiring GSC/SERP data.

Повтори аудит только по blockers: canonical/robots/status, duplicate intent, unsupported schema и broken links. Для каждого приложи строку evidence.

Подготовь и выполни план visual/accessibility/performance QA.

Preview: [URL_OR_PREVIEW]
Viewport: [VIEWPORTS]
Ключевые действия: [INTERACTIONS]
Performance budgets: [BUDGET]

Проверь keyboard-only flow, focus visibility/order, labels, errors, heading/landmark structure, alt text, contrast evidence, reduced motion, 200% zoom, horizontal overflow, tap targets, form success/failure, image dimensions, lazy loading below fold, render blocking and layout shifts. Отдели автоматические проверки от ручных. Верни screenshot list, reproduction steps, severity and exact fix. Не объявляй WCAG conformance по одному инструменту.

Для каждой найденной проблемы добавь viewport, selector, шаги, expected/actual и screenshot. Удали рекомендации без воспроизводимого evidence.

Проведи prelaunch gate.

Release scope и hashes: [RELEASE_SCOPE]
Preview URL: [PREVIEW]
Результаты content/SEO/accessibility/performance/security QA: [QA_RESULTS]
Backup и rollback plan: [ROLLBACK]

Проверь, что scope полный и минимальный; формы работают в success/error; аналитика и consent соответствуют утверждённой политике; нет secrets, персональных данных, localhost URLs и юридических placeholder; canonical/robots/sitemap согласованы; assets 200; backup проверен; rollback выполним; владелец выпуска назначен. Верни GO только если все blocking checks PASS. Иначе верни NO-GO с blocker, owner and verification command. Сам ничего не публикуй.

Пересчитай gate: любой FAIL или NOT_RUN в blocking category превращает результат в NO-GO. Покажи только blockers, owners и команды повторной проверки.