Промпты Claude Opus 4.7 для технического писателя — топ-10

Напиши README для опен-сорс библиотеки [название, язык, назначение]. Структура: 1) Бейджи (build/coverage/version/license); 2) 2-3 предложения о проблеме, которую решает библиотека; 3) Quickstart — минимальный рабочий пример; 4) Установка (npm/pip/go get + версии); 5) Базовое использование с 3 примерами; 6) API reference (или ссылка); 7) Конфигурация; 8) Тестирование; 9) Contributing; 10) Лицензия. Тон — дружелюбно-технический. Markdown, не выдумывай функции которых нет.

Напиши документацию для REST API эндпоинта [метод, путь, назначение]. Стиль — как Stripe API docs. Структура: 1) Описание (что делает, для чего); 2) HTTP-метод + URL; 3) Параметры (path/query/body — таблица: имя, тип, обязательность, описание, пример); 4) Тело запроса с JSON-примером; 5) Тело ответа (success 200) с JSON-примером; 6) Коды ошибок (400/401/403/404/422/429/500) с объяснением и JSON-примером; 7) Rate limits; 8) Примеры на curl, Python, JS. Тон — нейтральный, точный.

Напиши runbook для алерта '[название алерта]'. Структура: 1) Severity (P1/P2/P3) и SLA на ответ; 2) Что значит этот алерт (на простом языке); 3) Возможные причины (топ-5 в порядке вероятности); 4) Шаги диагностики — конкретные команды для каждой причины (kubectl/grafana/sentry); 5) Шаги mitigation (rollback/scale/restart) — что безопасно делать в 3 ночи; 6) Когда эскалировать и кого; 7) Post-mortem чек-лист. Тон — спокойный, инструктивный, для уставшего человека.

Напиши tutorial (по Diátaxis) на тему '[задача]'. Tutorial — обучающий жанр для новичка. Требования: 1) Конкретная цель (что построим к концу — '30-минутный туториал'); 2) Список prerequisites; 3) Пошаговые инструкции с КОДОМ для копипасты; 4) После каждого шага — что должно получиться; 5) Промежуточные чек-пойнты; 6) Финал — рабочий результат + следующие шаги. НЕ объясняй теорию (это explanation), НЕ давай альтернативы (это how-to). Только один путь от A до Z.

Напиши how-to guide на тему '[конкретная задача]'. How-to отличается от tutorial: предполагает базовое знание, фокус на одной задаче. Структура: 1) Цель в 1 предложении; 2) Когда применять / когда НЕ применять; 3) Prerequisites; 4) Шаги (5-8 шт) — компактно, без объяснения основ; 5) Альтернативные пути (если есть); 6) Common pitfalls; 7) Связанные how-to и reference. Тон — задача-ориентированный, без воды.

Напиши changelog для версии [X.Y.Z] по Keep a Changelog формату. Я приложу git log и список PR. Структура: 1) Дата релиза; 2) Added — новые фичи; 3) Changed — изменения существующего поведения; 4) Deprecated — что стало deprecated и когда удалится; 5) Removed — что убрано в этой версии; 6) Fixed — баг-фиксы; 7) Security — security fixes (CVE если есть). Каждый пункт — 1-2 строки + ссылка на PR. Breaking changes — выделить отдельно вверху с migration guide.

Напиши Architecture Decision Record (ADR) на тему '[архитектурное решение]'. Формат Michael Nygard: 1) Title и номер; 2) Status (proposed/accepted/superseded); 3) Date; 4) Context — какую проблему решаем, какие силы действуют; 5) Decision — что решили, конкретно; 6) Consequences — позитивные, негативные, нейтральные; 7) Alternatives considered — что ещё рассматривали и почему отвергли (по 2-3 предложения на вариант); 8) References — ссылки на тикеты, статьи, прототипы. Тон — фактический, без маркетинга.

Напиши onboarding-документ для нового разработчика в команде [продукт]. Структура (week-1 формат): 1) День 1 — настройка среды (репозитории, доступы, инструменты); 2) Дни 2-3 — архитектурный обзор (диаграмма + текст); 3) Дни 4-5 — первый PR (мини-задача); 4) Неделя 2 — погружение в основной модуль; 5) Контакты команды и зоны ответственности; 6) Ссылки на runbook'и, ADR, design docs; 7) FAQ от прошлых новичков. Тон — приветливо-профессиональный.

Напиши migration guide с версии [X] на [Y]. Структура: 1) TL;DR в 3 предложениях — что меняется и зачем; 2) Сводная таблица breaking changes; 3) Для каждого breaking change — отдельная секция: что было / что стало / автоматизация миграции (codemod/regex/команда) / ручные шаги / как откатиться; 4) Новые рекомендуемые паттерны; 5) Deprecation timeline; 6) FAQ. Каждый пример — рабочий код до/после. Сложные миграции — с тестовым скриптом для проверки.

Напиши документацию для всех переменных окружения / параметров YAML конфига [имя приложения]. Структура: 1) Группировка по доменам (DB, Auth, Cache, Logging, Feature Flags); 2) Для каждой переменной — таблица: имя, тип, обязательность, default, диапазон валидных значений, описание, пример; 3) Зависимости между переменными (если включён A — нужен B); 4) Приоритет (env > file > defaults); 5) Sample config для dev/staging/prod; 6) Security — какие переменные содержат секреты и как их хранить (vault/sealed-secrets).