промпт: тз разработчику на доработку сайта

промпт

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

вот что я хочу:
[опишите своими словами, что не устраивает и что должно измениться. можно сумбурно — структура моя забота. если есть примеры «хочу как здесь» — вставьте ссылки]

вот про сайт:
[вставьте: адрес сайта, на чём сделан (тильда / вордпресс / битрикс / самописный / не знаю), кто делал, есть ли доступы, подключена ли метрика]

вот ограничения:
[вставьте: бюджет-потолок, сроки, что точно нельзя трогать — например «форма заявки должна работать всегда, с неё продажи»]

собери тз:

1. сначала переспроси: перечисли места, где моя хотелка неоднозначна, и задай вопросы — с вариантами ответов, чтобы мне было легко. не пиши тз, пока я не отвечу.
2. потом структура: цель доработки одним предложением → список задач, каждая в формате «что сейчас / что должно стать / как проверить готовность». критерий готовности — проверяемый глазами или кликом, не «работает корректно».
3. раздели задачи на «нужно» и «хотелось бы» — чтобы разработчик мог посчитать два бюджета.
4. блок «не трогать»: что должно продолжать работать как раньше, и как это проверить после доработки.
5. блок для разработчика: какие доступы понадобятся, какие вопросы он задаст первыми — чтобы я подготовил ответы заранее.
6. финал: чек-лист приёмки — по нему я пройдусь перед оплатой, пункт за пунктом.

правила:
- не выдумывай технических деталей, которых я не давал. не знаешь, на чём сайт, — напиши в тз «уточнить у разработчика», это честнее, чем угадать.
- формулировки — без жаргона в мою сторону и без воды в сторону разработчика.
- если моя хотелка тянет не на доработку, а на переделку сайта — скажи об этом до тз, а не внутри.

как использовать

1. пишите первый блок как есть, хоть голосом наговорите и вставьте расшифровку. структурировать сумбур — работа промпта, а не ваша.
2. на вопросы модели отвечайте все — каждый пропущенный вопрос вернётся созвоном с разработчиком по часовому тарифу.
3. готовое тз отправьте разработчику целиком и попросите оценить «нужно» и «хотелось бы» отдельно. по реакции сразу видно уровень: хороший задаст вопросы из блока 5, плохой скажет «всё понятно» и пропадёт.
4. чек-лист приёмки сохраните отдельно и пройдите по нему до оплаты, а не через месяц, когда что-то отвалится.

что получится

тз, по которому разработчик может оценить срок и деньги без часового созвона: задачи с проверяемыми критериями готовности, приоритеты для двух бюджетов, список «не сломать» и чек-лист приёмки. границы честные: промпт не оценит стоимость работ — это делает разработчик, у которого есть доступ к коду. зато с таким тз оценки разных исполнителей можно сравнивать между собой: они считают одно и то же, а не каждый своё.