estimate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

When this skill is invoked:

Read the task description from the argument. If the description is too vague to estimate meaningfully, ask for clarification before proceeding.
Read CLAUDE.md for project context: tech stack, coding standards, architectural patterns, and any estimation guidelines.
Read relevant design documents from
```
design/gdd/
```
if the task relates to a documented feature or system.
Scan the codebase to understand the systems affected by this task:
- Identify files and modules that would need to change
- Assess the complexity of those files (size, dependency count, cyclomatic complexity)
- Identify integration points with other systems
- Check for existing test coverage in the affected areas
Read past sprint data from
```
production/sprints/
```
if available:
- Look for similar completed tasks and their actual effort
- Calculate historical velocity (planned vs actual)
- Identify any estimation bias patterns (consistently over or under)
Analyze the following factors:

Code Complexity:
- Lines of code in affected files
- Number of dependencies and coupling level
- Whether this touches core/engine code vs leaf/feature code
- Whether existing patterns can be followed or new patterns are needed
Scope:
- Number of systems touched
- New code vs modification of existing code
- Amount of new test coverage required
- Data migration or configuration changes needed
Risk:
- New technology or unfamiliar libraries
- Unclear or ambiguous requirements
- Dependencies on unfinished work
- Cross-system integration complexity
- Performance sensitivity
Generate the estimate:

markdown

undefined

当调用该Skill时：

读取参数中的任务描述。如果描述过于模糊无法进行有效估算，请先请求澄清再继续。
读取CLAUDE.md文件以了解项目背景：技术栈、编码规范、架构模式以及任何估算准则。
读取相关设计文档：如果任务涉及已文档化的功能或系统，请读取
```
design/gdd/
```
目录下的对应文档。
扫描代码库以了解任务影响的系统：
- 确定需要修改的文件和模块
- 评估这些文件的复杂度（文件大小、依赖数量、圈复杂度）
- 识别与其他系统的集成点
- 检查受影响区域的现有测试覆盖率
读取过往迭代数据（如果
```
production/sprints/
```
目录下有可用数据）：
- 查找类似已完成任务及其实际工作量
- 计算历史交付速度（计划值 vs 实际值）
- 识别估算偏差模式（持续高估或低估）
分析以下因素：

代码复杂度：
- 受影响文件的代码行数
- 依赖数量和耦合程度
- 任务是否涉及核心/引擎代码 vs 末端/功能代码
- 是否可以遵循现有模式或需要引入新模式
范围：
- 涉及的系统数量
- 新增代码 vs 修改现有代码的比例
- 需要新增的测试覆盖量
- 是否需要数据迁移或配置变更
风险：
- 新技术或不熟悉的库
- 需求不明确或存在歧义
- 依赖未完成的工作
- 跨系统集成复杂度
- 性能敏感性
生成估算结果：

markdown

undefined

Task Estimate: [Task Name]

任务估算：[任务名称]

Generated: [Date]

生成时间：[日期]

Task Description

任务描述

[Restate the task clearly in 1-2 sentences]

[用1-2句话清晰重述任务内容]

Complexity Assessment

复杂度评估

Factor	Assessment	Notes
Systems affected	[List]	[Core, gameplay, UI, etc.]
Files likely modified	[Count]	[Key files listed below]
New code vs modification	[Ratio, e.g., 70% new / 30% modification]
Integration points	[Count]	[Which systems interact]
Test coverage needed	[Low / Medium / High]	[Unit, integration, manual]
Existing patterns available	[Yes / Partial / No]	[Can follow existing code or new ground]

Key files likely affected:

```
[path/to/file1]
```
-- [what changes here]
```
[path/to/file2]
```
-- [what changes here]
```
[path/to/file3]
```
-- [what changes here]

因素	评估结果	备注
受影响系统	[列表]	[核心系统、游戏玩法、UI等]
可能修改的文件数	[数量]	[以下列出关键文件]
新增代码 vs 修改代码	[比例，如：70%新增 / 30%修改]
集成点数量	[数量]	[与哪些系统交互]
需要的测试覆盖率	[低 / 中 / 高]	[单元测试、集成测试、手动测试]
可复用现有模式	[是 / 部分可用 / 否]	[可遵循现有代码或需要全新实现]

可能受影响的关键文件：

```
[path/to/file1]
```
-- [此处说明修改内容]
```
[path/to/file2]
```
-- [此处说明修改内容]
```
[path/to/file3]
```
-- [此处说明修改内容]

Effort Estimate

工作量估算

Scenario	Days	Assumption
Optimistic	[X]	Everything goes right, no surprises, requirements are clear
Expected	[Y]	Normal pace, minor issues, one round of review feedback
Pessimistic	[Z]	Significant unknowns surface, blocked for a day, requirements change

Recommended budget: [Y days]

[If historical data is available: "Based on [N] similar tasks that averaged [X] days actual vs [Y] days estimated, a [correction factor] adjustment has been applied."]

场景	天数	假设条件
乐观值	[X]	一切顺利，无意外情况，需求明确
预期值	[Y]	正常推进，存在小问题，需一轮评审反馈
悲观值	[Z]	出现重大未知问题，被阻塞1天，需求变更

建议预算：[Y天]

[如果有历史数据：“基于[N]个类似任务的实际平均[X]天 vs 估算[Y]天，已应用[修正系数]进行调整。”]

Confidence: [High / Medium / Low]

置信度：[高 / 中 / 低]

High -- Clear requirements, familiar systems, follows existing patterns, similar tasks completed before.

Medium -- Some unknowns, touches moderately complex systems, partial precedent from previous work.

Low -- Significant unknowns, new technology, unclear requirements, or cross-cutting concerns across many systems.

[Explain which factors drive the confidence level for this specific task.]

高 -- 需求明确，系统熟悉，遵循现有模式，曾完成类似任务。

中 -- 存在部分未知因素，涉及中等复杂度系统，有部分过往工作可参考。

低 -- 存在大量未知因素，使用新技术，需求不明确，或涉及多系统的跨领域问题。

[说明驱动本次任务置信度的具体因素。]

Risk Factors

风险因素

Risk	Likelihood	Impact	Mitigation
[Specific risk]	[High/Med/Low]	[Days added if realized]	[How to reduce]
[Another risk]	[Likelihood]	[Impact]	[Mitigation]

风险	发生概率	影响	缓解措施
[具体风险]	[高/中/低]	[若发生将增加的天数]	[如何降低风险]
[另一风险]	[发生概率]	[影响]	[缓解措施]

Dependencies

依赖关系

Dependency	Status	Impact if Delayed
[What must be done first]	[Done / In Progress / Not Started]	[How it affects this task]

依赖项	状态	延迟影响
[必须先完成的工作]	[已完成 / 进行中 / 未开始]	[对本次任务的影响]

Suggested Breakdown

建议任务拆分

#	Sub-task	Estimate	Notes
1	[Research / spike]	[X days]	[If unknowns need investigation first]
2	[Core implementation]	[X days]	[The main work]
3	[Integration with system X]	[X days]	[Connecting to existing code]
4	[Testing and validation]	[X days]	[Writing tests, manual verification]
5	[Code review and iteration]	[X days]	[Review feedback, fixes]
	Total	[Y days]

#	子任务	估算天数	备注
1	[调研/探索性任务（Spike）]	[X天]	[若存在未知问题需先调研]
2	[核心实现]	[X天]	[主要工作内容]
3	[与系统X集成]	[X天]	[与现有代码对接]
4	[测试与验证]	[X天]	[编写测试、手动验证]
5	[代码评审与迭代]	[X天]	[处理评审反馈、修复问题]
	总计	[Y天]

Historical Comparison

历史对比

[If similar tasks exist in sprint history:]

Similar Task	Estimated	Actual	Relevant Difference
[Past task 1]	[X days]	[Y days]	[What makes it similar/different]
[Past task 2]	[X days]	[Y days]	[What makes it similar/different]

[如果迭代历史中有类似任务：]

类似任务	估算天数	实际天数	相关差异
[过往任务1]	[X天]	[Y天]	[相似/不同之处]
[过往任务2]	[X天]	[Y天]	[相似/不同之处]

Notes and Assumptions

备注与假设

[Key assumption that affects the estimate]
[Another assumption]
[Any caveats about scope boundaries -- what is included vs excluded]
[Recommendations: e.g., "Consider a spike first if requirement X is unclear"]


8. **Output the estimate** to the user with a brief summary: recommended
   budget, confidence level, and the single biggest risk factor.

[影响估算的关键假设]
[其他假设]
[范围边界说明：包含/不包含哪些内容]
[建议：例如“若需求X不明确，建议先进行探索性任务”]


8. **向用户输出估算结果**，同时附上简短摘要：建议预算、置信度以及最主要的风险因素。

Guidelines

准则

Always give a range (optimistic / expected / pessimistic), never a single number. Single-point estimates create false precision.
The recommended budget should be the expected estimate, not the optimistic one. Padding is not dishonest -- it is realistic.
If confidence is Low, recommend a time-boxed spike or prototype before committing to the full estimate.
Be explicit about what is included and excluded. Scope ambiguity is the most common source of estimation error.
Round to half-day increments. Estimating in hours implies false precision for tasks longer than a day.
If the task is too large to estimate confidently (more than 10 days expected), recommend breaking it into smaller tasks and estimating those individually.
Do not pad estimates silently. If risk exists, call it out explicitly in the risk factors section so the team can decide how to handle it.

始终提供估算范围（乐观值/预期值/悲观值），切勿只给单一数值。单点估算会造成虚假的精准感。
建议预算应采用预期值，而非乐观值。预留缓冲是务实的做法，并非不诚信。
如果置信度为低，建议在确定完整估算前先进行时间盒式的探索性任务（Spike）或原型开发。
明确说明估算包含和不包含的内容。范围模糊是估算误差最常见的来源。
估算值以半天为增量。对于超过1天的任务，按小时估算会造成虚假的精准感。
如果任务过大无法自信估算（预期值超过10天），建议拆分为更小的任务后单独估算。
切勿悄悄在估算中预留缓冲。若存在风险，请在风险因素部分明确指出，以便团队决定如何处理。