AI Vibe Craft
← Назад к AI Vibe News

Редакция 18 апреля 2026 г.

Разборы

Десять промптов для Claude, которые превращают документацию из «черновика» в рабочий текст

Десять промптов для Claude, которые превращают документацию из «черновика» в рабочий текст. На Dev.to автор серии devprompts собрал шаблоны под Claude: их можно вставить в чат и получить Markdown под README, описание API, докстринги, changelog и другие артефакты, которые команда реально читает, а не складирует

На Dev.to автор серии devprompts собрал шаблоны под Claude: их можно вставить в чат и получить Markdown под README, описание API, докстринги, changelog и другие артефакты, которые команда реально читает, а не складирует «на потом». Ниже — сжатая карта материала: что обещает каждый из десяти сценариев, какие входы автор считает обязательными и какой общий приём связывает примеры.

Десять сценариев для Claude: от нуля до ADR и справочника по ошибкам

В статье перечислены десять отдельных заготовок.

  1. Write a README from Scratch — описание, prerequisites, quickstart с рабочим кодом (не псевдокод), три ключевые опции конфигурации, краткая структура репозитория и плейсхолдер ссылки на полные доки; тон «прямой и практичный», без маркетинговых оборотов; цель — Markdown, пригодный к публикации без доработки.
  2. Write Docstrings for a Function or Class — выбор стиля (Google / NumPy / JSDoc / reStructuredText), контракт поведения («что», а не «как»), исключения и пример для неочевидных комбинаций параметров.
  3. Write API Endpoint Documentation — метод и путь, параметры, схема ответа, коды ошибок с объяснением причин, заметка про аутентификацию и полный рабочий пример curl; снова ориентация на готовый к публикации Markdown.
  4. Write a CHANGELOG Entry — выбор формата (Keep a Changelog, conventional или plain), классификация изменений, взгляд со стороны апгрейда, явное выделение breaking changes с заметкой о миграции.
  5. Write an Onboarding Guide for New Contributors — команды окружения, тесты, «топ‑5» файлов и каталогов для первого чтения, кратко про деплой, частая ошибка новичков и как её обойти.
  6. Audit Existing Documentation for Gaps — приоритизированный список пробелов с уровнем severity (блокирует / замедляет / minor) и одной строкой «fix note»; без требования переписать всё с нуля.
  7. Rewrite Dense Technical Prose to Be Readable — ограничения на длину предложения, пассивный залог, номинализации и «воду»; задача — упростить чтение, не жертвуя точностью.
  8. Write Inline Code Comments — объяснять почему, а не что; акцент на неочевидных решениях, внешних ограничениях и подводных камнях; стиль под язык.
  9. Write an Architecture Decision Record (ADR) — поля Context, Decision, Alternatives, Consequences, Revisit trigger и статус (Proposed / Accepted / Deprecated / Superseded).
  10. Write Error Message Documentation — для каждой ошибки: код и текст, plain English о состоянии, типичные причины и путь разрешения; запрет «просто перефразировать сообщение»; формат — таблица плюс детали.

Публикация на площадке датирована 2026-04-17T16:21:48Z (UTC).

Идея автора: провал документации чаще про приоритизацию, а не про «умение писать»; у разработчика и у автора объяснений разный режим мышления.

Четыре куска контекста, без которых промпт «плывёт»

Перед перечнем шаблонов в материале зафиксирован чеклист того, что нужно сообщить Claude до работы: конкретный читатель (не абстрактный «разработчик»), два предложения plain English о том, что делает код, явный формат вывода (README в Markdown, JSDoc, проза под OpenAPI и т.д.) и планка качества — в тексте проводится различие между черновиком «на ревью» и целью «good enough to ship without editing» (формулировка автора на странице).

Там же сказано, что Claude не снимает проблему приоритизации, но снижает временную стоимость, из‑за которой документация кажется «слишком дорогой» по времени.

Как наглядный контраст «цены» плохих документов автор приводит сравнение «сорок минут» чтения исходников и «четырёх минут» на поиск в документации — это иллюстрация в тексте статьи, не внешняя метрика API.

От десяти шаблонов к одной схеме промпта

В конце автор сводит все десять промптов к формуле context + constraint + format и пишет, что для старта достаточно примерно двух минут контекста (читатель, что делает код, что неочевидно), чтобы получить документацию, «которой не стыдно shipнуть» (передача смысла англоязычной формулировки с оригинала).

В тексте есть перекрёстные ссылки на другие посты серии на Dev.to (например, про code review, debugging, system design) как ориентир ожиданий: «copy-paste ready templates».

В конце указан коммерческий пак «Claude Prompts for Developers» на Gumroad. В самой статье автор пишет, что в паке 55 промптов в 6 категориях и 15 в секции Writing & Documentation.

Эти числа приведены на странице как часть CTA; по внешнему сайту Gumroad в этом обзоре они не проверялись.

Источники

  • Dev.to — «10 Claude Prompts for Developer Documentation That People Actually Read»: Dev.to (дата доступа UTC: 2026-04-18).
  • Публичный JSON API Dev.to для сверки структуры body_markdown той же публикации: https://dev.to/api/articles/3516396 (дата доступа UTC: 2026-04-18).