Add SKILL.md
This commit is contained in:
commit
3e0cf88814
1 changed files with 66 additions and 0 deletions
66
SKILL.md
Normal file
66
SKILL.md
Normal file
|
|
@ -0,0 +1,66 @@
|
||||||
|
---
|
||||||
|
name: git-report
|
||||||
|
description: Генерирует аналитический отчёт о прогрессе в Git-репозитории за период, анализируя коммиты, задачи и активность участников. Использует LLM для осмысленного описания изменений.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Навык: git-report – Аналитический отчёт по репозиторию
|
||||||
|
|
||||||
|
## Назначение
|
||||||
|
Навык собирает данные о коммитах, задачах (issues) и пул-реквестах (PRs) за указанный период, а затем на основе этих данных формирует **содержательный отчёт о прогрессе**, написанный естественным языком. В отчёте отражаются:
|
||||||
|
- Ключевые изменения и их смысловая нагрузка (что сделано, зачем).
|
||||||
|
- Активность участников (кто, сколько и что делал).
|
||||||
|
- Выполнение задач и соответствие дедлайнам (если информация есть в issues).
|
||||||
|
- Общая оценка прогресса и рекомендации.
|
||||||
|
|
||||||
|
## Как использовать
|
||||||
|
Пользователь пишет агенту, например:
|
||||||
|
> "Сделай git-report для https://github.com/owner/repo за последние 2 недели"
|
||||||
|
> "Проанализируй прогресс в проекте https://gitlab.com/group/project за март 2026"
|
||||||
|
|
||||||
|
Если период не указан – анализируются **все изменения за всю историю** репозитория (от первого коммита до последнего).
|
||||||
|
|
||||||
|
## Порядок действий агента (строго!)
|
||||||
|
1. Извлеки из запроса URL репозитория и временной период (если не указан – анализируется вся история).
|
||||||
|
2. Выполни скрипт `scripts/generate_report.py`, передав аргументы:
|
||||||
|
- `--repo-url` (URL)
|
||||||
|
- `--since` (дата начала, YYYY-MM-DD) – если период указан
|
||||||
|
- `--until` (дата конца, YYYY-MM-DD) – если период указан
|
||||||
|
Скрипт соберёт данные и сохранит их в файл `/app/hermes_data/git_reports/<repo>_data.json`.
|
||||||
|
**Важно:** Теперь JSON содержит для каждого коммита не только сообщение и автора, но и список изменённых файлов (`files_changed`), количество добавленных (`insertions`) и удалённых (`deletions`) строк. Если период не задан, скрипт автоматически переключается на локальное клонирование и анализирует всю историю (это может занять больше времени, но даст полную картину).
|
||||||
|
3. **Прочитай этот JSON-файл** – в нём содержится вся собранная информация (коммиты, issues, PRs) в структурированном виде.
|
||||||
|
4. **Проанализируй данные** и напиши отчёт в формате Markdown. Отчёт должен включать:
|
||||||
|
- **Общий прогресс** (количество коммитов, задач, участников).
|
||||||
|
- **Содержательный разбор изменений** – сгруппируй изменения по темам (новые функции, исправления, рефакторинг, документация и т.д.) и укажи, кто, когда и что именно сделал. Не копируй комментарии коммитов, а сформулируй суть и смысл изменений человеческим языком на русском, исходя из комментария и содержания коммита. Используй данные о файлах и количестве изменённых строк, чтобы оценить масштаб работ.
|
||||||
|
НЕ КОПИРУЙ комментарии к коммитам. ТЫ ДОЛЖЕН сам НА РУССКОМ сформулировать суть изменений. Если коммитов, относящихся по смыслу к одному изменению, много - объедини их в один пункт. Этот раздел является ГЛАВНЫМ
|
||||||
|
в отчёте. Удели ему ОСОБОЕ ВНИМАНИЕ, хорошо формулируя смысл проделанной участниками работы. Эта та часть, на которую В ПЕРВУЮ ОЧЕРЕДЬ будет смотреть руководство при оценке прогресса команды в работе. Указывай даты выполнения работ и авторов.
|
||||||
|
Для КАЖДОГО блока изменений укажи тех, кто принимал участие в работе и сроки проведения работы.
|
||||||
|
В этой части не копируй метаданные и сухую статистику коммитов. В каждом блоке должны быть указаны авторы и сроки выполнения, далее - исключительно описание человеческим языком сути проделанной работы, без сухой статистики. Не надо перечислять изменённые файлы, количество строк и т.п. - только смысловое описание.
|
||||||
|
- **Активность участников** – кто внёс какой вклад, какие задачи закрыл.
|
||||||
|
- **Выполнение задач** – перечисли открытые/закрытые issues (если есть сведения), укажи, соблюдены ли сроки (если в issue есть метки с датами или дедлайнами).
|
||||||
|
- **Оценка прогресса** – достигнуты ли цели периода, есть ли риски, насколько эффективной и соответствующей поставленным задачам и срокам была работа с учётом активности участников.
|
||||||
|
- **Рекомендации** (если уместно).
|
||||||
|
Отчёт должен по стилю соответствовать отчёту по прогрессу в IT-компании (НЕ ИСПОЛЬЗУЙ эмодзи и т.п.). Содержательный отчёт должен включать не просто перечень коммитов, а сведения об их смысле: что было добавлено/изменено, какая задача/работа выполнена (ты должен сам понять и сформулировать это по комментарию и содержанию коммита, а не просто скопировать комментарий).
|
||||||
|
5. Сохрани написанный отчёт в файл `/app/hermes_data/git_reports/<repo_name>_report.md`.
|
||||||
|
6. Сообщи пользователю путь к отчёту и краткую выжимку.
|
||||||
|
|
||||||
|
## Важные требования
|
||||||
|
- При анализе смысла коммитов учитывай diff.
|
||||||
|
- Тщательно следи за корректностью оформления и форматирования отчёта и переносов строк
|
||||||
|
- **Ни в коем случае не используй сухую статистику как готовый отчёт.** Ты должен переработать данные в связный текст.
|
||||||
|
- Если данных слишком много (например, сотни коммитов), агрегируй их (сгруппируй по смыслу, не перечисляй каждый коммит).
|
||||||
|
- Если в данных есть ссылки на дедлайны (например, в описании issue указано "срок: 2026-04-20"), обязательно проверь, выполнено ли вовремя.
|
||||||
|
- Используй профессиональный, но понятный стиль. Отчёт должен быть полезен для руководителя или команды.
|
||||||
|
- **НИ В КОЕМ СЛУЧАЕ** не придумывай те сведения, которых нет – только делай выводы из существующих данных.
|
||||||
|
- При анализе коммитов обращай внимание на поле `files_changed`, `insertions` и `deletions` – это поможет понять масштаб изменений (например, «крупный рефакторинг затронул 15 файлов» или «добавлено 500 строк кода в новом модуле»).
|
||||||
|
- Отчёт должен по стилю соответствовать отчёту по прогрессу в IT-компании
|
||||||
|
- **НИ В КОЕМ СЛУЧАЕ НЕ ИСПОЛЬЗУЙ** в отчёте эмодзи и иные подобные символы.
|
||||||
|
- Отчёт должен соответствовать официальному стилю отчёта и быть информативным
|
||||||
|
- Оформление отчёта должно соответствовать допустимому для официального в IT компании
|
||||||
|
- **НЕ КОПИРУЙ** в содержательный разбор изменений комментарии коммитов. Ты должен сам человеческим языком на русском сформулировать смысл коммита.
|
||||||
|
- **НЕ ДЕЛАЙ** в содержательном разборе сухой список коммитов. Ты должен сам проанализировать, какие изменения были внесены.
|
||||||
|
|
||||||
|
## Примечания
|
||||||
|
- Убедись, что скрипт имеет права на выполнение, а зависимости установлены (см. `requirements.txt`).
|
||||||
|
- Для доступа к API некоторых хостингов могут потребоваться токены (переменные окружения `GITHUB_TOKEN`, `GITLAB_TOKEN`). Если их нет, скрипт использует локальное клонирование (только коммиты, без issues).
|
||||||
|
- Если скрипт не смог получить issues/PRs (нет токена или API недоступен), работай только с коммитами – этого достаточно для базового отчёта.
|
||||||
|
- **Для анализа всей истории репозитория** (без указания дат) скрипт автоматически использует локальное клонирование, что даёт полную информацию о каждом коммите. Это может занять время, но результат будет максимально детальным.
|
||||||
Loading…
Add table
Add a link
Reference in a new issue