From jiralyzer
Jira ticket analytics using natural language. Trigger when user asks about Jira ticket data, resolution times, re-assignment patterns, workload distribution, status transitions, ticket analytics, cycle time, or burndown metrics. Also trigger for: "analyze my Jira tickets", "show me ticket trends", "Jira dashboard", "ticket metrics", "cycle time analysis", "who has the most tickets", "resolution time by priority", "most re-assigned tickets", "status transition matrix", "workload distribution".
How this skill is triggered — by the user, by Claude, or both
Slash command
/jiralyzer:jiralyzerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You help users analyze Jira ticket data using the `jiralyzer` CLI tool. You translate natural language questions into DuckDB SQL queries, execute them, interpret results, and generate visualizations.
You help users analyze Jira ticket data using the jiralyzer CLI tool. You translate natural language questions into DuckDB SQL queries, execute them, interpret results, and generate visualizations.
Jiralyzer is a Python package managed with uv. All commands must be run from the jiralyzer project directory using uv run:
cd /Users/maorb/git/jiralyzer && uv run jiralyzer <command> [args...]
Every jiralyzer command shown in this skill should be run this way. For example:
jiralyzer stats → cd /Users/maorb/git/jiralyzer && uv run jiralyzer statsjiralyzer query "SELECT ..." → cd /Users/maorb/git/jiralyzer && uv run jiralyzer query "SELECT ..."The default database path is jiralyzer.db in the current directory (/Users/maorb/git/jiralyzer/jiralyzer.db). Use --db <path> to override.
Before querying, ensure data is in the database. The sync command pulls directly from Jira REST API:
# Set Jira credentials (one-time setup)
export JIRA_URL=https://your-site.atlassian.net
export [email protected]
export JIRA_API_TOKEN=your-api-token
# Full sync — all issues in a project
cd /Users/maorb/git/jiralyzer && uv run jiralyzer sync --project <KEY>
# Incremental sync — only issues updated since a date
cd /Users/maorb/git/jiralyzer && uv run jiralyzer sync --project <KEY> --since 2026-04-01
# Optionally save raw JSON export
cd /Users/maorb/git/jiralyzer && uv run jiralyzer sync --project <KEY> --output export.json
The sync command fetches all issues with expand=changelog (full history including status changes, assignments, worklogs) and automatically ingests them into DuckDB.
When the user asks an analytics question:
This step is critical. The database can contain multiple projects. You must determine which project the user is asking about and verify that project's data is present.
Extract the project key from the user's request (e.g., "analyze CSI-PM" → project key is CSI-PM, "CREQ tickets" → project key is CREQ).
Check which projects are in the database:
cd /Users/maorb/git/jiralyzer && uv run jiralyzer query "SELECT project, COUNT(*) as count FROM tickets GROUP BY project ORDER BY count DESC"
If the requested project is NOT in the results, sync it first:
cd /Users/maorb/git/jiralyzer && uv run jiralyzer sync --project <KEY>
This requires JIRA_URL, JIRA_EMAIL, and JIRA_API_TOKEN environment variables. If they're not set, ask the user to set them.
If the database has no data at all, ask the user for their Jira project key and run sync.
Always filter queries by project when multiple projects exist in the database. Add WHERE project = '<KEY>' to all queries. Do NOT mix data from different projects.
Run cd /Users/maorb/git/jiralyzer && uv run jiralyzer schema to get the current table structure. The database has 6 tables:
See references/schema.md for detailed column descriptions and types.
Translate the user's question into DuckDB SQL. Key considerations:
unnest() for expansionresolution_days is a generated column — no need to compute itreferences/query-patterns.md for pre-built patterns matching common questions# For data analysis
cd /Users/maorb/git/jiralyzer && uv run jiralyzer query "<sql>" --format json
# For display to user
cd /Users/maorb/git/jiralyzer && uv run jiralyzer query "<sql>" --format table
Always explain what the results mean in context. Don't just show numbers — provide insights.
If the results benefit from a chart, generate one:
cd /Users/maorb/git/jiralyzer && uv run jiralyzer chart "<sql>" --type <chart_type> --x <col> --y <col> --output chart.png
See references/visualization-guide.md for chart type selection guidance.
Chart types: bar, line, pie, histogram, scatter, heatmap, stacked_bar
Output formats: .png (static Matplotlib, default — works reliably), .html (interactive Plotly — may be blank behind corporate proxies)
Combine data and visualization into a concise report:
When the user asks to categorize, classify, segment, or understand their ticket data, do NOT fall back to SQL LIKE keyword matching. You are an LLM — use your semantic understanding.
Sample first, don't dump everything. Query a representative batch (50-100 tickets) with summaries:
cd /Users/maorb/git/jiralyzer && uv run jiralyzer query "SELECT key, summary, issue_type, priority, status, assignee FROM tickets WHERE project = '<KEY>' ORDER BY key LIMIT 100" --format json
Read and understand the summaries yourself. Look for themes, patterns, team names, work types, naming conventions, repeated structures. You are the classifier — not SQL.
Build categories from what you see. After reading the sample, define categories (e.g., by domain, by work type, by repetitiveness). Then query more batches if needed to validate.
Use SQL only for aggregation, not classification. Once you've identified categories and the patterns that define them, you can use SQL CASE WHEN for counting. But the category definitions come from your semantic understanding, not from guessing keywords.
Read ALL tickets, but in chunks. It is critical to read every ticket for thorough analysis. Use batches of 50-100 with OFFSET and LIMIT. After each batch, note the patterns and categories you've found so far, then continue to the next batch. This prevents context overflow while ensuring complete coverage.
Identify automation candidates by looking for:
Present findings incrementally. Write your analysis text as you go — don't accumulate everything and try to output it all at once. After each major finding, share it with the user.
LIKE '%keyword%' as your primary classification strategyAlways prefer the jiralyzer chart CLI for visualizations. It produces professional styled PNG charts automatically.
cd /Users/maorb/git/jiralyzer && uv run jiralyzer chart "<sql>" --type bar --x <col> --y <col> --output chart.png
If you need a custom visualization that the CLI can't produce:
cat > /tmp/chart_script.py << 'PYEOF'
import matplotlib.pyplot as plt
# ... your code ...
PYEOF
cd /Users/maorb/git/jiralyzer && .venv/bin/python3 /tmp/chart_script.py
.venv Python so matplotlib is available.| User asks about... | Tables to query | Typical chart |
|---|---|---|
| Resolution time | tickets (resolution_days) | histogram, bar |
| Status distribution | tickets (status) | pie, bar |
| Workload / assignees | tickets (assignee) | bar |
| Ticket trends | tickets (created, resolved) | line |
| Re-assignments | assignments | bar |
| Status transitions | status_changes | heatmap, stacked_bar |
| Cycle time | status_changes (time between states) | histogram, line |
| Activity / comments | comments | line, bar |
| Time tracking | worklogs | bar, scatter |
| Custom fields | custom_fields | bar |
For a quick overview, run:
cd /Users/maorb/git/jiralyzer && uv run jiralyzer stats # Text summary
cd /Users/maorb/git/jiralyzer && uv run jiralyzer stats --format json # Machine-readable
This shows: table row counts, date ranges, status distribution, top assignees, resolution metrics.
For downstream analysis (Snowflake, BigQuery, etc.):
cd /Users/maorb/git/jiralyzer && uv run jiralyzer export-parquet ./exports/ # All tables
cd /Users/maorb/git/jiralyzer && uv run jiralyzer export-parquet ./exports/ --tables tickets # Specific tables
cd /Users/maorb/git/jiralyzer && uv run jiralyzer export-parquet ./exports/ --compression zstd # Better compression
cd /Users/maorb/git/jiralyzer && uv run jiralyzer <command> — never use bare jiralyzerjiralyzer.db in the jiralyzer project directory; use --db <path> to overrideWHERE project = '<KEY>' when multiple projects existSearches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Implements vector databases with Pinecone, Weaviate, Qdrant, Milvus, pgvector for semantic search, RAG, recommendations, and similarity systems. Optimizes embeddings, indexing, and hybrid search.
npx claudepluginhub final-il/maor-skills-marketplace --plugin jiralyzer