ai-team-weekly-report

AI Team Weekly Report

Generates a factual, natural-language weekly report on a team's Jira activity, written in Russian in the voice of a Team Lead. The set of employees is a roster of emails stored in emails.json and managed through a helper script.

When to use

• The user wants a weekly team report / «недельный отчёт по команде».
• The user wants to add, remove, list, or clear the employees in the roster.

Roster management (save / add / remove)

The roster lives in emails.json (a JSON array of emails) in the skill root. Manage it only through scripts/manage_emails.py so validation and de-duplication are applied. Run from the skill directory:

python scripts/manage_emails.py list                       # show current roster
python scripts/manage_emails.py add [email protected] [email protected]   # add one or more
python scripts/manage_emails.py remove [email protected]        # remove one or more
python scripts/manage_emails.py clear                      # empty the roster

Every command prints the resulting roster as JSON ({"count": N, "emails": [...]}). Invalid emails are rejected with a non-zero exit code; surface the error to the user.

When the user only asks to manage emails, run the relevant command and confirm the result — do not generate a report.

Generating the report

Follow these steps in order.

1. Load the roster

Run python scripts/manage_emails.py list (or read emails.json) to get the emails. If the roster is empty, tell the user and ask them to add emails first (show the add command). Do not invent employees.

2. Fetch each employee's issues from the past week — in parallel

First determine the report window. "Week" means from Monday of the current week (00:00) through today, inclusive — not a rolling 7 days. Compute the Monday date explicitly so it does not depend on Jira's locale startOfWeek() (which may begin on Sunday):

python3 -c "import datetime; t=datetime.date.today(); print((t - datetime.timedelta(days=t.weekday())).isoformat())"

This prints the current week's Monday as YYYY-MM-DD (Mon→Mon, Tue→that Monday, … Sun→that Monday). Use it as WEEK_START below. Examples: today Tuesday → covers Mon–Tue; today Friday → covers Mon–Fri. No upper bound is needed — updated >= WEEK_START already includes everything up to now.

For each email, issue a jira_search call. Send all employee searches in a single message so they run in parallel. Use this JQL per employee (covers tasks, bugs, and every other issue type), filtering by the exact workflow statuses this team uses:

assignee = "EMAIL" AND updated >= "WEEK_START" 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

Replace WEEK_START with the computed Monday date (e.g. "2026-06-01"). Set fields to: summary,status,assignee,issuetype,updated,description. Raise limit (up to 50) if a person has many issues; paginate with start_at if total exceeds what was returned.

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 against the status names below (case-insensitive).
• Ignore issues[].status.category completely. It does not match this team's grouping. For example «Ready for Testing» has category «В работе», but it is a Completed status here. Never decide a task's group from status.category — always use status.name.
• issues[].issue_type.name (e.g. «Задача», «Ошибка»/bug, «Dev Task»).
• issues[].assignee.display_name / .email identify the person.

Aggregate all issues across all employees into one consolidated list, tagging each with its group (Completed vs In Progress) per the status mapping in step 4. The roster only defines whose work to fetch — the report itself is about the team as a whole, so do not track or report who did what.

3. Enrich sparse items only if needed

If a summary is too terse to understand at all, call jira_get_issue for that issue key (fields: "summary,description,issuetype,status") to grasp what the task is about. Do this only for the issues that need it — not for every issue. Use the description only to extract the essence of the task; never copy long descriptions into the report.

4. Write the report (Russian, Team-Lead voice)

Compose the report in Russian using only factual data from Jira. 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 (e.g. «исправлена ошибка…», «реализовано…»), not in present-continuous («исправляется…»), which is reserved for the In Progress section.
• Write in flowing prose, as a Team Lead summarizing the team's week. Group related tasks into a few thematic paragraphs (e.g. платежи и переводы, миграция интерфейса, безопасность) rather than one sentence per task.
• Write about the team as a whole. Do not break work down by person, name individuals, or attribute tasks to specific 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 that was done.
• 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.

Files

• emails.json — the roster (JSON array of emails).
• scripts/manage_emails.py — list/add/remove/clear the roster.