Постановка задач для разработчиков — это то, что занимает лично у меня очень много времени, поэтому решил разобраться, а как же мне упростить этот процесс.
❓Что сделал:
— Собрал PRD(документ о требованиях к продукту) проекта, на котором запланировал тест
— Собрал в один файл наши стандарты разработки: код-стайл, git-flow, конфиги prettier/eslint и т.д.
— Собрал хорошие и плохие кейсы постановки задач в рамках текущего проекта
— Собрал сам скилл, который в рамках проекта видит все эти документы, а также AGENTS.md для каждого конкретного проекта, т.к. везде есть свои нюансы.
— Сделал MCP-сервер для интеграции с нашим таск-трекером
— Сделал конфигурационный файл для связи с трекером, чтобы понимал какой проект, доску, колонку, теги и исполнителей нужно взять для разного типа задач.
— Написал сам текст скила в котором учел все наши "хотелки"
✅ Что дальше:
1. Открываю Codex, вызываю скилл $new-task
2. Коротко описываю задачу
3. Агент анализирует все наши требования, которые указывал выше, анализирует кодовую базу и разбирается что и где нужно сделать
4. После анализа задаёт вопросы
5. После получения ответов формирует итоговое ТЗ для внедрения фичи
6. Я изучаю и прошу внести корректировки, если нужно но обычно не нужно
6. После этого агент предлагает добавить задачу в таймтрекер
7. Добавляет задачу в нужный проект/доску с тегами. исполнителем и т.д.
Пример из проекта:
На входе:
$new-task Добавить Авто-перевод причины отказа в выводе средств на язык пользователя.
На выходе в трекере:
Контекст
В модуле src/modules/withdrawals причина отказа задается админом в CancelWithdrawDto.description и сохраняется в withdraw.reason (AdminWithdrawalsService.cancelWithdraw).
Пользователь видит эту причину в своем списке заявок GET /withdrawals/my (WithdrawalsService.getAllUserWithdrawals), но сейчас текст не адаптируется под user.language.
Ожидаемый результат
При отклонении заявки причина автоматически переводится на язык конкретного пользователя и отдается в reason в его истории выводов, без изменения API-контракта.
Сценарий:
1. Админ отклоняет вывод через POST /admin-withdrawals/cancel/:id с description.
2. Система определяет user.language владельца заявки.
3. Текст причины переводится на язык пользователя.
4. В withdraw.reason сохраняется переведенный текст.
5. GET /withdrawals/my возвращает локализованную причину в поле reason.
Что нужно сделать:
1. В WithdrawalsModule подключить OpenaiModule и использовать OpenaiService в AdminWithdrawalsService.
2. В AdminWithdrawalsService.cancelWithdraw перед withdraw.reason = ... добавить шаг перевода:
определить target language по user.language (en/ru/es/zh, fallback en);
3. вызвать сервис перевода;
4. взять значение нужного языка и сохранить в withdraw.reason.
5. Добавить failover:
если перевод не удался или язык не поддержан, сохранять исходный description (не падать при cancel-операции).
6. Сохранить текущий формат логов/админки:
в admin-log (AdminLogInfo.payoutCanceled) оставлять исходную причину, чтобы не терять оригинал.
7. Обновить Swagger-описание admin cancel endpoint (зафиксировать, что текст для пользователя локализуется автоматически).
Особые случаи:
1. user.language пустой/null/неизвестен: использовать en.
2. description уже на нужном языке: сохраняем как есть.
3. Ошибка OpenAI/API: отмена вывода все равно успешна, в reason сохраняется исходный текст.
Критерии готовности:
1. При отклонении заявки причина в GET /withdrawals/my возвращается на языке пользователя.
2. При ошибке перевода отказ все равно проходит, а reason заполняется оригинальным текстом.
3. Контракт endpoint’ов и DTO остается обратно совместимым.
Тестирую эту приблуду всю неделю, экономит мне ~70% времени на постановку задач, но главным плюсом считаю то, что разработчики получают детализированную постановку задачи и вопросов стало сильно меньше. Где-то уже заметно, что нужны корректировки, но думаю за месяц отточу до того состояния чтобы меня на 100% устраивало
💬 Че думаете?) Делитесь мыслями в комментариях