analyze-bug-report

Generates quarterly bug analysis reports for Lucca Front by querying GitHub issues and pull requests.

52|7|Updated Apr 12, 2017
One-click install
npx skills add https://github.com/LuccaSA/lucca-front --skill analyze-bug-report-luccasa
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: analyze-bug-report
Source: https://github.com/LuccaSA/lucca-front/tree/main/.claude/skills/analyze-bug-report
Command: npx skills add https://github.com/LuccaSA/lucca-front --skill analyze-bug-report-luccasa

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Producing a quantitative bug report for the Lucca Front repository requires manually cross-referencing two disjoint populations — issues of type Bug (demand) and pull requests labeled FIX (delivery) — across volumes, criticality, affected components, and quarter-over-quarter trends. This Skill automates that analysis with ready-to-run GitHub CLI queries and a standardized report format. ## Core Features & Use Cases - Dual-population counting: Measures bugs reported (issues type:Bug) and fixes delivered (PRs labeled :bookmark::bug: FIX) separately, including opened, treated, remaining, and backlog volumes. - Criticality and subject breakdown: Tallies P0/P1/P2 priority labels on issues and derives bug subjects from actually modified component folders rather than unreliable topic labels. - Quarterly comparison: Computes deltas against the previous period and outputs a structured Markdown synthesis table. - Use Case: A design system lead needs the Q2 bug report for Lucca Front; the Skill runs the gh api queries, classifies merged FIX PRs by component and bug type, and produces the formatted Markdown report. ## Quick Start Ask the assistant to analyze Lucca Front bugs for a given quarter, for example: generate the bug analysis report for Q2 2026.

Frequently Asked Questions about analyze-bug-report

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I analyze bugs in a GitHub repository over a quarter?▼

Use GitHub search queries with date ranges like created:2026-04-01..2026-06-30 combined with is:issue type:Bug for reported bugs and is:pr is:merged label:FIX for delivered fixes. The gh api search/issues endpoint returns total_count for each query.

How to count GitHub issues by type using the gh CLI?▼

Run gh api -X GET search/issues with a query like repo:OWNER/REPO is:issue type:Bug created:RANGE and extract .total_count with --jq. The native GitHub issue type field is more reliable than labels for identifying bugs.

Why do bug issue counts and fix PR counts not match?▼

Many fix pull requests have no associated bug issue, and some issues are closed without a dedicated PR. The two populations measure demand versus delivery and should always be presented side by side, never summed.

Can I measure bug criticality from pull request labels?▼

No. Priority labels like P0/P1/P2 exist only on issues; fix PRs typically carry no priority. Criticality coverage is therefore partial and should be reported as a fraction of total correction work.

What are the GitHub search API rate limits for bug counting?▼

Unauthenticated search allows about 10 requests per minute and the REST API 60 per hour. Using the authenticated gh CLI raises search to 30 requests per minute, which is preferable for multi-query reports.