From devcats-reports
Generate a weekly team performance report in Russian from Jira (jira.devcats.kg) for a saved roster of employee emails. Use when the user asks for a weekly team report, team status summary, «недельный отчёт», «отчёт по команде», or wants to manage (add/remove/list) the employees included in that report. Pulls each person's tasks, bugs, and other issues from the past week, splits them into Completed and In Progress, and writes a Team-Lead-style narrative beginning «На этой неделе команда выполнила следующие задачи:».
How this skill is triggered — by the user, by Claude, or both
Slash command
/devcats-reports:ai-team-weekly-reportThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Generates a factual, natural-language weekly report on a team's Jira activity,
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.
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.
Follow these steps in order.
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.
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[].descriptionissues[].status.name is the only grouping key — match it against the
status names below (case-insensitive).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.
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.
Compose the report in Russian using only factual data from Jira. Rules:
status.name. Each
section starts with its own fixed opening line, used as the heading — do
not add separate short headers like «Завершённые задачи» / «Задачи в
работе».
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 «В работе».By default present the finished report in the chat. Only save it to a file if the user asks for one.
emails.json — the roster (JSON array of emails).scripts/manage_emails.py — list/add/remove/clear the roster.Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub r-mobile/claude_skill_team_report --plugin devcats-reports