AI-промты для руководств пользователя

Роль: Ты Lead documentation engineer с 8 лет опыта в технической документации SaaS и промышленных продуктов. Экспертиза: Microsoft Style Guide, Google Developer Documentation Style Guide, методология Every Page is Page One Марка Бейкера.

Контекст: Я технический писатель в [тип компании — SaaS/промышленность]. Продукт: [название продукта и краткое описание]. У нас есть руководство версии [номер версии], которое [сколько страниц] и писалось [срок]. Основные жалобы: [жалобы пользователей или метрики — время на страницу, bounce rate, тикеты в поддержку].

Задача: Провести аудит руководства по 12 критериям: findability, scannability, task-orientation, точность терминологии, единый голос, примеры кода/скриншоты, inclusive language, глубина вложенности, длина параграфов, призыв к действию, перекрёстные ссылки, актуальность версии.

Формат вывода: (1) сводная таблица критерий-оценка 1-5-обоснование. (2) топ-10 конкретных проблем с цитатами из текста и предложенной правкой. (3) приоритизированный backlog задач на ближайший спринт с оценкой в story points.

Детали: Опирайся на Microsoft Style Guide и принципы DITA topic-based authoring. Избегай общих формулировок 'улучшить стиль' — давай конкретные переписанные фрагменты.

Роль: Ты эксперт по DITA и structured authoring с 10 лет опыта внедрения CCMS в enterprise. Экспертиза: DITA 1.3, Oxygen XML Author, Paligo, topic-based authoring, content reuse через conref и keyref.

Контекст: Я Lead documentation engineer в [тип компании]. Текущая документация: [объём в страницах или словах] в [текущий формат — Word/Confluence/Markdown]. Продукт: [тип продукта — SaaS/оборудование/SDK]. Команда: [число писателей] писателей, [число разработчиков] разработчиков. Бюджет на миграцию: [бюджет или ограничения].

Задача: Разработать roadmap миграции на structured authoring с оценкой ROI, рисков и этапов. Учесть переиспользование контента между разделами Quick Start, Troubleshooting, API Reference.

Формат вывода: (1) Lean Canvas миграции — проблема, аудитория, ценность, метрики успеха. (2) поэтапный план на 6 месяцев с вехами, ответственными, артефактами. (3) таблица рисков probability-impact-mitigation. (4) прогноз экономии человеко-часов через 12 месяцев.

Детали: Используй принципы minimalism John Carroll и DITA specialization. Избегай миграции ради миграции — каждое решение обоснуй метрикой.

Роль: Ты UX-writer для документации с 6 лет опыта в продуктовых компаниях. Экспертиза: информационная архитектура Питера Морвиля, card sorting, tree testing, анализ поисковых логов документации.

Контекст: Я технический писатель в [тип компании]. Продукт: [название и категория — SaaS B2B / мобильное приложение / API]. Прямые конкуренты: [3-5 конкурентов с URL их документации]. Наша целевая аудитория: [портрет читателя — разработчик / админ / конечный пользователь]. Типичная цель читателя: [задача читателя — запустить за 10 минут / интегрировать через API].

Задача: Сравнить документацию нашего продукта и конкурентов по 15 параметрам UX и contentов, выявить gaps и best practices.

Формат вывода: (1) матрица сравнения продукт-критерий со скорингом 0-3. (2) топ-5 best practices от конкурентов с цитатами и ссылками. (3) топ-5 наших уникальных преимуществ для усиления. (4) список из 10 конкретных изменений в нашу документацию с приоритетом ICE.

Детали: Параметры: скорость первого успеха, качество Quick Start, навигация, поиск, примеры кода, видео, интерактивные туры, API reference, changelog, i18n, accessibility, mobile-friendly, обратная связь, версионирование, community. Не оценивай дизайн — фокус на контенте и IA.

Роль: Ты Senior технический писатель с 7 лет опыта в SaaS и API-продуктах. Экспертиза: Docs-as-Code, Keep a Changelog, семантическое версионирование, фасилитация воркшопов по Liberating Structures.

Кonтекст: Я технический писатель в [тип компании]. Команда разработчиков: [число разработчиков] инженеров в [число команд] командах. Текущая проблема: [проблема — release notes пишет только писатель / пишут плохо / не пишут вообще]. Частота релизов: [частота — еженедельно / спринтами / CI/CD]. Инструменты: [Jira/GitHub/GitLab и система документации].

Задача: Спроектировать 90-минутный воркшоп, который научит разработчиков писать release notes самостоятельно по единому шаблону и встроить процесс в pipeline релиза.

Формат вывода: (1) поминутная программа воркшопа с активностями и тайминга. (2) шаблон release note с примерами good/bad для Added/Changed/Fixed/Deprecated/Security. (3) чек-лист для PR review заметок. (4) план внедрения на 30 дней с метриками успеха — % релизов с notes, NPS разработчиков.

Детали: Опирайся на Keep a Changelog 1.1.0 и принципы Docs-as-Code. Избегай лекционного формата — минимум 60% времени на практику с реальными PR команды.