从 Jira Server/Data Center 拉取 Bug 数据，进行全面分析，并生成自包含的 HTML 报表。
向用户收集以下必要信息（如果用户已在调用参数中提供，则跳过询问）：
必填参数：
https://jira.company.comPROJ可选参数：
--start-date): 筛选此日期之后创建的 Bug，格式 YYYY-MM-DD--end-date): 筛选此日期之前创建的 Bug，格式 YYYY-MM-DD--issue-type): 默认为 Bug。如果 Jira 实例使用中文或自定义名称（如 故障、缺陷），需指定实际名称。如果用户不确定，可先用 REST API 查询项目实际的 Issue Type 列表--severity-field): 如果 Jira 实例中有「严重程度」自定义字段，提供其字段 ID（如 customfield_10072）。告诉用户可以在 Jira 管理后台的自定义字段页面找到此 ID--no-verify 参数如果用户没有提供日期范围，建议默认使用最近 90 天。
运行以下命令安装 Python 依赖：
pip install -r ${SKILL_DIR}/requirements.txt
如果 pip 命令失败，尝试使用项目虚拟环境：
source ${SKILL_DIR}/.venv/bin/activate && pip install -r ${SKILL_DIR}/requirements.txt
构建并执行以下命令来获取 Jira Bug 数据：
python ${SKILL_DIR}/scripts/get_jiraData.py \
--server <JIRA_SERVER_URL> \
--token <PAT> \
--project <PROJECT_KEY> \
[--issue-type Bug] \
[--start-date YYYY-MM-DD] \
[--end-date YYYY-MM-DD] \
[--severity-field customfield_NNNNN] \
[--no-verify]
如果使用用户名密码认证，将 --token 替换为 --username 。
脚本输出：stdout 为结构化 JSON 数据，stderr 为进度信息。捕获 stdout 的 JSON 内容进行后续分析。
Issue Type 自动检测：如果脚本返回 0 条数据，可能是 Issue Type 名称不匹配。此时应通过 REST API 查询项目实际的 Issue Type 列表：
curl -u <USER>:<PASS> -k <SERVER>/rest/api/2/project/<PROJECT_KEY> | python3 -c "import sys,json;[print(t['name']) for t in json.load(sys.stdin).get('issueTypes',[])]"
如果发现实际名称为中文（如 故障、缺陷），用 --issue-type 参数指定后重新执行。
错误处理：
--no-verify 参数基于获取到的 JSON 数据进行全面分析。JSON 包含三部分：metadata（元数据）、aggregations（聚合统计）、issues（原始 Issue 列表）。
重点关注以下分析维度：
已解决/未解决判定规则（两步判定）：
脚本采用两步判定逻辑，聚合数据中的 unresolved_count、by_assignee_detailed 等字段均基于此规则：
resolution 字段 — 不为空则判定为「已解决」resolution 为空，再检查 status — 以下状态视为「已解决」：已关闭、INVALID、DUPLICATED、无法复现、已解决每条 Issue 的 JSON 中包含 _resolved 布尔字段，表示最终判定结果。
注意：聚合数据已在 Python 脚本中预计算，直接使用 aggregations 中的数值，不要自行重新计算。只在需要具体举例时才引用 issues 数组中的个别 Issue。
基于分析结果生成一个自包含的 HTML 文件，要求如下：
file:// 协议在浏览器中打开禁止在 HTML 中硬编码任何数据数值。 所有图表和表格必须从嵌入的原始 JSON 数据动态渲染：
```html
```
REPORT_DATA.aggregations 读取数据后动态创建 DOM 元素，不得在 SVG 标签中手写数字REPORT_DATA.issues 数组渲染REPORT_DATA.aggregations 和 REPORT_DATA.metadata 读取REPORT_DATA 中读取数据动态拼接，而非手写固定数字这样确保页面上展示的每一个数值都可追溯到原始数据，不存在数据编造或计算偏差的可能。
svgHeight = dataItems.length * 40 + topPadding + bottomPaddingmax-height: 600px; overflow-y: auto 实现滚动Header: 报表标题、项目名称、日期范围、生成时间（蓝紫渐变背景）
Navigation: 顶部粘性导航栏，包含各章节锚点链接
Sections:
1. Executive Summary — 8 张指标卡片（4列x2行），数据从 aggregations 读取
数据分类说明面板 — 可折叠，展示已解决/未解决的两步判定规则及来源拆分
2. Bug Trend — SVG 柱状图，按月展示创建数和解决数
3. Priority Distribution — SVG 水平柱状图或环形图
4. Severity Distribution — SVG 图表（如果有 severity 数据，否则跳过此节）
5. Component Hotspots — SVG 柱状图，按数量降序排列
6. Resolution Time — 统计表格（含说明列）+ 按优先级解决时间表格
7. Assignee Analysis — SVG 水平柱状图（使用 `aggregations.by_assignee_detailed` 数据，按 total 降序）+ 表格（经办人、总数、已解决、未解决、解决率、平均解决天数）。柱状图高度按经办人数量动态计算
8. Aging Analysis — SVG 柱状图展示老化区间分布 + 未解决按优先级表格
9. Labels — 柱状图（Top 25）
10. AI Recommendations — 从 REPORT_DATA 动态拼接的改进建议列表
11. Issue Detail Table — 完整 Bug 列表，支持客户端搜索、排序和 Excel 下载
Footer: 报告说明和生成信息
viewBox + preserveAspectRatio="xMinYMin meet" 实现自适应容器宽度，禁止固定像素宽度grid 4 列 布局（grid-template-columns: repeat(4, 1fr)），共 8 张卡片排成 2 行overflow: hidden; text-overflow: ellipsis; white-space: nowrap 防止内容溢出卡片边界在指标卡片下方放置一个可折叠面板，标题为「数据分类说明：已解决与未解决是如何判定的？」：
REPORT_DATA.issues 的 _resolved、resolution、status 字段动态统计在 Issue 明细表的搜索框旁边放置一个「下载 Excel」按钮，点击后在客户端生成并下载包含全部原始 Issue 数据的 Excel 文件。
技术实现要求：
issues 数组中的数据写入 Excel，每条 Issue 一行Number 类型，其余使用 String 类型&, <, >, "）进行转义{PROJECT_KEY}_bug_raw_data_{YYYY-MM-DD}.xlsBlob + URL.createObjectURL + 临时 按钮样式：绿色背景（#44bb66），白色粗体文字，圆角，与搜索框同行排列
{PROJECT_KEY}_bug_analysis_{YYYY-MM-DD}.html共 1 个版本