estimate-jira

用途

本技能用于对 JIRA 工单、功能或项目进行结构化的复杂度与工作量评估，输出一致、专业的评估报告，包含复杂度等级、时间估算、依赖分析、风险评估以及未知项识别。

适用触发场景

当用户提出以下请求时激活：

“Estimate this JIRA ticket”
“Analyze complexity of [ticket/feature]”
“What's the effort for this project?”
“Size this feature”
“How long will this take?”
“What are the risks for this work?”

前提条件

用户提供 JIRA 工单内容（推荐 markdown 格式）
可访问仓库代码库以进行依赖分析
了解项目架构（必要时查阅 tools/prompts/technology-stack.md）

工作流程

步骤 0：加载必要文档

在分析前先阅读：

tools/prompts/guides/jira.md（JIRA 速查）
tools/prompts/technology-stack.md（架构约束与模式）
CLAUDE.md（仓库约定与构建要求）

阅读后确认理解：仓库结构与关键包、构建与测试命令、架构约束（例如零运行时依赖）。

步骤 1：收集并分析工单信息

需完成：接收 JIRA 工单内容，提取关键需求、验收标准与约束，识别主要受影响区域（包/文件），记录工单中已有与缺失的信息。

初步分析问题：工作类型是什么（缺陷修复、新功能、重构、文档等）？影响哪些包（community、enterprise、types、website 等）？是否提及相关工单或依赖？范围是明确还是模糊？

步骤 2：识别模糊点与实现选择

关键：未完成此步骤不得进入估算。

需分析以下方面的模糊点：

技术方案：是否存在多种有效实现策略？期望的架构/模式是否已指定？性能要求是否定义？
范围边界：功能范围是否清晰界定？边界情况与错误处理是否指定？是否要求向后兼容？
集成点：如何与现有系统集成？框架包装器（React/Angular/Vue）是否受影响？是否有公共 API 变更？
测试与质量：期望的测试覆盖级别？是否需要视觉回归测试？是否应添加/更新基准测试？
文档：是否需要文档？是否需要示例？是否应编写迁移指南？

对每个重要模糊点：清晰记录、列出可能的实现选择、说明各选择对时间/复杂度/风险的影响，并使用 AskUserQuestion 工具在继续前获取澄清。

步骤 3：调查代码库依赖与复杂度

使用 Explore agent 进行彻底的代码库分析：识别所有受影响的文件与包，分析现有类似实现以复用模式，检查对其他系统/模块的依赖，查找需更新的相关测试与文档。

重点调查区域：核心实现位置与复杂度、类型系统（ag-charts-types 是否需要更新、是否影响公共 API）、测试面（受影响测试文件数量、是否需要图像快照、是否需要 E2E 测试）、文档与示例（需更新的文档页数、是否需要新示例、是否会生成框架变体）、构建依赖（哪些包需要重建、是否有循环依赖风险、是否影响构建性能）。

步骤 4：生成结构化评估报告

使用固定模板以保证一致性。报告包含：

执行摘要（总工作量、复杂度、风险等级、置信度、要点）
估算的复杂度等级（整体与实现/测试/文档/集成拆分及理由）
估算时间（总估算、置信度、按调查与设计、核心实现、测试、文档、评审与迭代拆分，以及假设）
依赖、缺口与缺失信息（外部依赖、信息缺口、隐式范围、范围外事项）
最高风险的三个方面（类别、详情、缓解措施）
整体风险等级（风险评估与理由、技术/进度/集成/需求风险、对估算的置信度）
建议的后续步骤
实现决策（已确认）（仅在估算过程中澄清了重要实现选择时包含）

完成检查清单

在以下全部勾选前不得标记评估完成：用户已提供 JIRA 工单内容；已识别并与用户澄清所有重要模糊点；已使用 Explore agent 完成代码库调查；评估报告所有章节均已填写；复杂度等级有理由支撑；时间估算包含拆分与假设；已识别前三风险及缓解策略；已评估整体风险等级；报告已复核完整性与准确性。

关键规则

绝不跳过模糊点澄清：若实现选择显著影响估算，必须先通过 AskUserQuestion 工具询问用户。
始终使用 AskUserQuestion 工具处理模糊点，不使用临时文本对话。
始终使用 Explore agent 进行代码库分析。
对不确定性保持诚实：置信度低时明确说明，并列出可提高置信度的信息。
考虑完整范围：不要遗漏测试、文档、评审迭代和框架包装器，这些常占总工作量的 40-50%。
计入未知项：已知未知应成比例增加时间估算与风险等级。
使用区间而非点估算：给出区间（如“3-5 天”）以反映不确定性。
明确记录假设：每个估算都基于假设，清晰说明以便验证。

失败处理

工单信息不足：向用户请求更多细节，列出所需的具体信息，若无法提供则给出带较大不确定区间的估算。
找不到相关代码区域：使用 Explore agent 扩大搜索模式，向用户询问代码可能位置的提示，并在报告中记录为“已知未知”。
存在多种复杂度差异巨大的有效实现方案：使用 AskUserQuestion 工具将每种方案作为选项呈现，在选项描述中包含复杂度/时间影响，让用户通过结构化界面选择，并在“实现决策”章节记录所选方案。
估算超出合理时间（例如单人 >2 周）：考虑拆分为多个工单，在风险评估中突出，建议创建子任务或阶段，与用户讨论范围缩减选项。

估算校准参考

常见 AG Charts 工作项的基线估算：

系列实现：新系列类型约 10 天 / 2 周。包含核心实现、类型定义、渲染逻辑、主题集成、单元测试、视觉回归测试、文档页、框架示例。示例：重叠条形/柱形系列、时间线系列、象限图。不包含：高度复杂的渲染算法、超出标准的交互。
注解实现：新注解类型约 15-20 天（3-4 周）。包含核心注解类、渲染、拖拽/缩放交互、类型定义、全面测试（单元、E2E、视觉回归）、文档、示例。示例：文本注解、形状注解、测量工具。复杂度驱动：拖放交互、缩放手柄、连接点、样式系统。
其他常见工作项：简单缺陷修复（隔离、根因清晰）0.5-1 天；复杂缺陷修复（需调查、多区域）2-3 天；新图表选项（简单属性、最少逻辑）1-2 天；事件/回调新增 2-4 天；性能优化 3-5 天；破坏性 API 变更额外增加 20-30% 用于迁移指南与向后兼容测试。

调整准则：需要与多个系统深度集成时增加 20-30%；存在重大未知或需求不清时增加 30-50%；企业功能需要许可检查、高级主题时增加 40-60%；仅在利用大量现有基础设施且改动极小时可减少 20-30%。

使用示例

当用户说以下内容时：

“Estimate AG-12345”
“How complex is this feature?”
“Size this ticket for me”
“What's the effort for implementing [feature]?”
“Analyze the risks for this work”

本技能将：请求 JIRA 工单内容（若尚未提供）；分析需求并识别模糊点；与用户澄清实现选择；彻底调查代码库；生成包含所有请求章节的全面评估报告；突出风险、未知项与复杂区域。输出始终遵循结构化报告格式，以确保所有估算的一致性。

限制

具体收费、价格、可用平台或安装方式在资料中暂未提供。

技能介绍

用途