ai-employee-monthly-report

AI Employee Monthly Report

Generates a factual, natural-language monthly report on a single employee's Jira activity, written in Russian in the first person (as if the employee is reporting on their own month). The employee is identified by an email passed in the request, and the month is given in natural language.

This skill is deliberately separate from the team weekly report. It keeps its own status mapping and its own wording rules below, so you can tune individual reports without touching the team report and vice-versa.

When to use

• The user asks for a monthly report about one person, e.g. «отчёт [email protected] за февраль», «месячный отчёт по [email protected] за март 2025», «отчёт за прошлый месяц по ».
• The signal is a single email + a month. There is no saved roster — the email always comes from the request.

If the request names several people or no email at all, this is probably not the right skill — ask the user for the one email, or point them to the team report.

Generating the report

Follow these steps in order.

1. Parse the email and the month

Pull the employee email straight from the request. If it is missing, ask for it — never invent one.

Resolve the month window with the helper script (run it from the skill directory). It accepts natural-language month specs and prints the exact date range as JSON:

python scripts/month_window.py "февраль"
python scripts/month_window.py "март 2025"
python scripts/month_window.py "прошлый месяц"
python scripts/month_window.py            # no arg -> current month

Output fields:

• start — inclusive lower bound (YYYY-MM-01).
• end_exclusive — exclusive upper bound for JQL. For a finished month this is the 1st of the next month; for the current month it is tomorrow, so the window runs from the 1st through today inclusive («до текущей даты»).
• end_inclusive — the last day actually covered, for display only.
• label — human label like «февраль 2026», for the header/intro.
• is_current_month — whether the month is still in progress.

The month rule, restated: always from the 1st of the month at 00:00, through the last day of the month — or, if it is the current month, through today inclusive. A month name without a year means the most recent past occurrence (if the named month is later than the current month, it belongs to last year).

2. Fetch the employee's issues for that window

Issue a single jira_search with this JQL, substituting the email and the two dates from step 1 (covers tasks, bugs, and every other issue type, filtered by the exact workflow statuses this team uses):

assignee = "EMAIL" AND updated >= "START" AND updated < "END_EXCLUSIVE" AND status in ("Done", "To release", "to merge", "On merge", "Cancelled", "To review", "to test", "Feature test", "Ready for Testing", "Pause", "Accepted", "In Progress") ORDER BY status DESC

Set fields to: summary,status,assignee,issuetype,updated,description. A month can hold many issues, so set limit to 50 and paginate with start_at if total exceeds what was returned — make sure you pull the whole month.

Notes on the response shape (Jira Server/DC at jira.devcats.kg):

• issues[].key, issues[].summary, issues[].description.
• issues[].status.name is the only grouping key — match it case-insensitively against the status lists in step 4.
• Ignore issues[].status.category completely. It does not match this team's grouping (e.g. «Ready for Testing» carries category «В работе» but is a Completed status here). Always group by status.name, never by category.
• issues[].issue_type.name (e.g. «Задача», «Ошибка»/bug, «Dev Task»).

3. Enrich sparse items only if needed

If a summary is too terse to understand at all, call jira_get_issue for that key (fields: "summary,description,issuetype,status") just to grasp the gist. Do this only for the few issues that need it. Use the description only to extract the essence; never copy long descriptions into the report.

4. Write the report (Russian, first person)

Compose the report in Russian using only factual data from Jira, written from the employee's point of view (first person — «я выполнил», «реализовал», «сейчас работаю над»). Rules:

• The report has two sections, in this order, grouped by status.name. Each section starts with its own fixed opening line, used as the heading — do not add separate short headers like «Завершённые задачи» / «Задачи в работе».
  1. Completed — open with exactly this line (it is also the report's first line): «За этот месяц я выполнил следующие задачи:». Statuses: Done, To release, to merge, On merge, Cancelled, To review, to test, Feature test, Ready for Testing.
  2. In Progress — open with exactly this line: «Сейчас в работе у меня находятся следующие задачи:». Statuses: Pause, Accepted, In Progress.
• Match status names case-insensitively (e.g. "to merge" == "To merge").
• Group strictly by status.name using the lists above — never by status.category. In particular «Ready for Testing», «to test», «To review», «to merge», «On merge» and «Feature test» go to Completed, even though some carry the Jira category «В работе».
• Describe Completed tasks as finished work in the past tense («исправил ошибку…», «реализовал…»), and the In Progress section in present continuous («дорабатываю…», «реализую…»).
• Write in flowing prose, in the first person, as the employee summarizing their own month. Group related tasks into a few thematic paragraphs (e.g. платежи и переводы, миграция интерфейса, безопасность) rather than one sentence per task.
• Since this is one person's report, you may freely use «я»/«мной», but do not name the employee in the third person or mention other people.
• State only the essence of each task in a few words — do not include long descriptions, full ticket text, or issue keys.
• Apart from the two fixed opening lines, do not use introductory, framing, or filler lead-ins, and drop intensifier/connective filler words. Avoid sentences like «Значительная часть работы была сосредоточена на…» and words like «Активно», «Также», «В рамках спринта…». Start each paragraph directly with the concrete work.
• Use plain, non-technical wording for UI and code concepts — describe things as a user would see them, not as a developer. Replace developer jargon with user-facing terms: «боттом-щит» / bottom-sheet → «окно»; activity / fragment / класс экрана → «экран». Avoid other low-level technical formulations when a plain word conveys the same meaning.
• Do not use enumerations, bullet lists, or numbered lists.
• Do not include images.
• Do not add personal opinions, conclusions, praise, or speculation — describe only what the data shows.
• If a section has no issues, state that plainly (e.g. «За этот месяц завершённых задач не зафиксировано.»).

By default present the finished report in the chat. Only save it to a file if the user asks for one. If the month window is the current (in-progress) month, you may note the covered period (e.g. «за период с 1 по 3 июня») so it is clear the month is not yet over.

Files

• scripts/month_window.py — resolve a natural-language month into an exact start / end_exclusive date window.