feat(prompts): add /bugfix, /feature, /review, /rfc command templates
- Pi-native $ARGUMENTS placeholders (not {{}})
- reference skills and session corporate context; no hardcoded URLs
- feature.md stops for plan approval; rfc.md carries a TODO to match internal template
This commit is contained in:
@@ -0,0 +1,24 @@
|
|||||||
|
---
|
||||||
|
description: Починка бага по тикету трекера с воспроизведением и тестом
|
||||||
|
argument-hint: "<ключ-тикета>"
|
||||||
|
---
|
||||||
|
Ты чинишь баг по тикету **$ARGUMENTS**. Действуй строго по шагам и не пропускай их.
|
||||||
|
|
||||||
|
1. **Прочитай тикет.** Используй скилл `jira-workflow`, чтобы получить тикет `$ARGUMENTS`
|
||||||
|
(базовый адрес трекера и токен скилл берёт из корпоративного контекста сессии и переменных
|
||||||
|
окружения — не спрашивай их у меня и не выдумывай). Кратко перескажи суть проблемы,
|
||||||
|
ожидаемое и фактическое поведение.
|
||||||
|
2. **Воспроизведи проблему.** Найди затронутый код, определи, как воспроизвести баг локально,
|
||||||
|
и убедись, что он действительно воспроизводится. Если воспроизвести не удаётся — остановись
|
||||||
|
и напиши, какой информации не хватает.
|
||||||
|
3. **Напиши падающий тест.** Добавь тест, который сейчас падает и фиксирует некорректное
|
||||||
|
поведение. Следуй нашим стандартам тестирования из скилла `go-standards`.
|
||||||
|
4. **Почини.** Внеси минимальные изменения, которые делают тест зелёным. Не рефактори лишнего.
|
||||||
|
5. **Прогони проверки.** Запусти линтеры и весь набор тестов по инструкции из скилла
|
||||||
|
`go-standards`. Все проверки должны пройти.
|
||||||
|
6. **Подготовь описание MR.** Сформируй текст merge request: что было не так, что изменено,
|
||||||
|
как проверено, и ссылка на тикет `$ARGUMENTS`. Формат описания и ссылки — по скиллу
|
||||||
|
`jira-workflow` и `go-standards`. MR не создавай и не пушь без моего подтверждения.
|
||||||
|
|
||||||
|
Соблюдай корпоративные правила из контекста сессии (в том числе: не коммитить секреты,
|
||||||
|
не пушить в защищённые ветки, MR обязателен).
|
||||||
@@ -0,0 +1,26 @@
|
|||||||
|
---
|
||||||
|
description: Реализация фичи по тикету с обязательным согласованием плана
|
||||||
|
argument-hint: "<ключ-тикета>"
|
||||||
|
---
|
||||||
|
Ты реализуешь фичу по тикету **$ARGUMENTS**. Работа делится на две фазы: сначала план,
|
||||||
|
потом реализация. **Не начинай писать код до моего подтверждения плана.**
|
||||||
|
|
||||||
|
## Фаза 1. План (остановись после неё)
|
||||||
|
|
||||||
|
1. **Прочитай тикет.** Через скилл `jira-workflow` получи тикет `$ARGUMENTS` (адрес трекера и
|
||||||
|
токен — из корпоративного контекста сессии и переменных окружения, не выдумывай их).
|
||||||
|
Перескажи требования и критерии приёмки.
|
||||||
|
2. **Изучи код.** Найди затронутые сервисы и места изменений, опираясь на скилл `repo-map`.
|
||||||
|
3. **Составь план** и запиши его в файл `PLAN.md` в корне: цель, затрагиваемые модули,
|
||||||
|
пошаговый список изменений, какие тесты добавишь, риски и открытые вопросы.
|
||||||
|
4. **Остановись** и попроси меня согласовать план. Не переходи к реализации без явного «ок».
|
||||||
|
|
||||||
|
## Фаза 2. Реализация (только после подтверждения)
|
||||||
|
|
||||||
|
5. Реализуй строго по согласованному `PLAN.md`, следуя стандартам из скилла `go-standards`.
|
||||||
|
6. На каждый заметный кусок функциональности добавляй тесты.
|
||||||
|
7. Прогони линтеры и тесты (см. `go-standards`) — всё должно быть зелёным.
|
||||||
|
8. Подготовь описание MR со ссылкой на тикет `$ARGUMENTS`. MR не пушь без моего подтверждения.
|
||||||
|
|
||||||
|
Соблюдай корпоративные правила из контекста сессии (не коммитить секреты, не пушить в
|
||||||
|
защищённые ветки, MR обязателен).
|
||||||
@@ -0,0 +1,19 @@
|
|||||||
|
---
|
||||||
|
description: Ревью текущего диффа по стандартам Go с заданным фокусом
|
||||||
|
argument-hint: "[фокус: например безопасность, конкурентность, ошибки]"
|
||||||
|
---
|
||||||
|
Проведи ревью **текущего диффа** (незакоммиченные изменения и/или изменения ветки
|
||||||
|
относительно основной) по нашим стандартам Go.
|
||||||
|
|
||||||
|
Фокус ревью: **$ARGUMENTS**. Если фокус выше пустой — оценивай общее качество кода.
|
||||||
|
|
||||||
|
Порядок:
|
||||||
|
|
||||||
|
1. Определи, что именно изменилось (`git status`, `git diff`, при необходимости `git diff main...`).
|
||||||
|
2. Оцени изменения по скиллу `go-standards`: структура, идиоматичность, обработка ошибок,
|
||||||
|
конкурентность, тесты, линтеры. Если задан фокус — удели ему особое внимание.
|
||||||
|
3. Выдай замечания списком, сгруппированные по важности: **Блокеры → Важное → Мелочи/стиль**.
|
||||||
|
Для каждого замечания укажи файл и строку, объясни проблему и предложи конкретную правку.
|
||||||
|
4. Отдельно отметь, что сделано хорошо, и чего не хватает в тестах.
|
||||||
|
|
||||||
|
Только ревью — код не меняй, пока я не попрошу.
|
||||||
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
description: Черновик RFC по типовому шаблону на заданную тему
|
||||||
|
argument-hint: "<тема RFC>"
|
||||||
|
---
|
||||||
|
Подготовь черновик RFC по теме: **$ARGUMENTS**.
|
||||||
|
|
||||||
|
Сначала собери контекст: при необходимости изучи затронутые сервисы (скилл `repo-map`) и
|
||||||
|
существующую документацию (скилл `docs-map`). Затем составь документ по структуре ниже.
|
||||||
|
Не выдумывай факты о системе — если данных не хватает, помечай `TODO` и вопросом ко мне.
|
||||||
|
|
||||||
|
<!-- TODO: сверить структуру с внутренним шаблоном RFC компании и заменить при расхождении -->
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# RFC: $ARGUMENTS
|
||||||
|
|
||||||
|
- Автор:
|
||||||
|
- Дата:
|
||||||
|
- Статус: Draft
|
||||||
|
|
||||||
|
## 1. Контекст
|
||||||
|
Зачем это нужно, какая ситуация сейчас, кого затрагивает.
|
||||||
|
|
||||||
|
## 2. Проблема
|
||||||
|
Что именно не работает / чего не хватает. Требования и ограничения.
|
||||||
|
|
||||||
|
## 3. Рассмотренные варианты
|
||||||
|
Для каждого — суть, плюсы, минусы, оценка сложности.
|
||||||
|
- Вариант A —
|
||||||
|
- Вариант B —
|
||||||
|
|
||||||
|
## 4. Предлагаемое решение
|
||||||
|
Выбранный вариант и почему. Как это устроено, какие сервисы затронуты (см. repo-map).
|
||||||
|
|
||||||
|
## 5. Риски и влияние
|
||||||
|
Совместимость, миграции, производительность, безопасность, план отката.
|
||||||
|
|
||||||
|
## 6. Открытые вопросы
|
||||||
|
Список TODO и то, что нужно согласовать.
|
||||||
|
```
|
||||||
|
|
||||||
|
Готовый черновик сохрани в файл (имя предложи сам) и куда его выложить — подскажи по скиллу
|
||||||
|
`docs-map`.
|
||||||
Reference in New Issue
Block a user