From 3e0cf88814b716f6aa0e2d1417c9c0604228f2e8 Mon Sep 17 00:00:00 2001 From: slonovaad Date: Tue, 21 Apr 2026 18:17:03 +0000 Subject: [PATCH] Add SKILL.md --- SKILL.md | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 SKILL.md diff --git a/SKILL.md b/SKILL.md new file mode 100644 index 0000000..570d008 --- /dev/null +++ b/SKILL.md @@ -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/_data.json`. + **Важно:** Теперь JSON содержит для каждого коммита не только сообщение и автора, но и список изменённых файлов (`files_changed`), количество добавленных (`insertions`) и удалённых (`deletions`) строк. Если период не задан, скрипт автоматически переключается на локальное клонирование и анализирует всю историю (это может занять больше времени, но даст полную картину). +3. **Прочитай этот JSON-файл** – в нём содержится вся собранная информация (коммиты, issues, PRs) в структурированном виде. +4. **Проанализируй данные** и напиши отчёт в формате Markdown. Отчёт должен включать: + - **Общий прогресс** (количество коммитов, задач, участников). + - **Содержательный разбор изменений** – сгруппируй изменения по темам (новые функции, исправления, рефакторинг, документация и т.д.) и укажи, кто, когда и что именно сделал. Не копируй комментарии коммитов, а сформулируй суть и смысл изменений человеческим языком на русском, исходя из комментария и содержания коммита. Используй данные о файлах и количестве изменённых строк, чтобы оценить масштаб работ. + НЕ КОПИРУЙ комментарии к коммитам. ТЫ ДОЛЖЕН сам НА РУССКОМ сформулировать суть изменений. Если коммитов, относящихся по смыслу к одному изменению, много - объедини их в один пункт. Этот раздел является ГЛАВНЫМ + в отчёте. Удели ему ОСОБОЕ ВНИМАНИЕ, хорошо формулируя смысл проделанной участниками работы. Эта та часть, на которую В ПЕРВУЮ ОЧЕРЕДЬ будет смотреть руководство при оценке прогресса команды в работе. Указывай даты выполнения работ и авторов. + Для КАЖДОГО блока изменений укажи тех, кто принимал участие в работе и сроки проведения работы. + В этой части не копируй метаданные и сухую статистику коммитов. В каждом блоке должны быть указаны авторы и сроки выполнения, далее - исключительно описание человеческим языком сути проделанной работы, без сухой статистики. Не надо перечислять изменённые файлы, количество строк и т.п. - только смысловое описание. + - **Активность участников** – кто внёс какой вклад, какие задачи закрыл. + - **Выполнение задач** – перечисли открытые/закрытые issues (если есть сведения), укажи, соблюдены ли сроки (если в issue есть метки с датами или дедлайнами). + - **Оценка прогресса** – достигнуты ли цели периода, есть ли риски, насколько эффективной и соответствующей поставленным задачам и срокам была работа с учётом активности участников. + - **Рекомендации** (если уместно). + Отчёт должен по стилю соответствовать отчёту по прогрессу в IT-компании (НЕ ИСПОЛЬЗУЙ эмодзи и т.п.). Содержательный отчёт должен включать не просто перечень коммитов, а сведения об их смысле: что было добавлено/изменено, какая задача/работа выполнена (ты должен сам понять и сформулировать это по комментарию и содержанию коммита, а не просто скопировать комментарий). +5. Сохрани написанный отчёт в файл `/app/hermes_data/git_reports/_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 недоступен), работай только с коммитами – этого достаточно для базового отчёта. +- **Для анализа всей истории репозитория** (без указания дат) скрипт автоматически использует локальное клонирование, что даёт полную информацию о каждом коммите. Это может занять время, но результат будет максимально детальным. \ No newline at end of file