Back to Details

estimate

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
When this skill is invoked:
  1. Read the task description from the argument. If the description is too vague to estimate meaningfully, ask for clarification before proceeding.
  2. Read CLAUDE.md for project context: tech stack, coding standards, architectural patterns, and any estimation guidelines.
  3. Read relevant design documents from 
    design/gdd/
    if the task relates to a documented feature or system.
  4. 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
  5. 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)
  6. 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
  7. Generate the estimate:
markdown
undefined
当调用该Skill时：
  1. 读取参数中的任务描述。如果描述过于模糊无法进行有效估算，请先请求澄清再继续。
  2. 读取CLAUDE.md文件以了解项目背景：技术栈、编码规范、架构模式以及任何估算准则。
  3. 读取相关设计文档：如果任务涉及已文档化的功能或系统，请读取
    design/gdd/
    目录下的对应文档。
  4. 扫描代码库以了解任务影响的系统：
    • 确定需要修改的文件和模块
    • 评估这些文件的复杂度（文件大小、依赖数量、圈复杂度）
    • 识别与其他系统的集成点
    • 检查受影响区域的现有测试覆盖率
  5. 读取过往迭代数据（如果
    production/sprints/
    目录下有可用数据）：
    • 查找类似已完成任务及其实际工作量
    • 计算历史交付速度（计划值 vs 实际值）
    • 识别估算偏差模式（持续高估或低估）
  6. 分析以下因素：
    代码复杂度：
    • 受影响文件的代码行数
    • 依赖数量和耦合程度
    • 任务是否涉及核心/引擎代码 vs 末端/功能代码
    • 是否可以遵循现有模式或需要引入新模式
    范围：
    • 涉及的系统数量
    • 新增代码 vs 修改现有代码的比例
    • 需要新增的测试覆盖量
    • 是否需要数据迁移或配置变更
    风险：
    • 新技术或不熟悉的库
    • 需求不明确或存在歧义
    • 依赖未完成的工作
    • 跨系统集成复杂度
    • 性能敏感性
  7. 生成估算结果：
markdown
undefined

Task Estimate: [Task Name]

任务估算：[任务名称]

Generated: [Date]
生成时间：[日期]

Task Description

任务描述

[Restate the task clearly in 1-2 sentences]
[用1-2句话清晰重述任务内容]

Complexity Assessment

复杂度评估

FactorAssessmentNotes
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

工作量估算

ScenarioDaysAssumption
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

风险因素

RiskLikelihoodImpactMitigation
[Specific risk][High/Med/Low][Days added if realized][How to reduce]
[Another risk][Likelihood][Impact][Mitigation]
风险发生概率影响缓解措施
[具体风险][高/中/低][若发生将增加的天数][如何降低风险]
[另一风险][发生概率][影响][缓解措施]

Dependencies

依赖关系

DependencyStatusImpact if Delayed
[What must be done first][Done / In Progress / Not Started][How it affects this task]
依赖项状态延迟影响
[必须先完成的工作][已完成 / 进行中 / 未开始][对本次任务的影响]

Suggested Breakdown

建议任务拆分

#Sub-taskEstimateNotes
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 TaskEstimatedActualRelevant 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天），建议拆分为更小的任务后单独估算。
  • 切勿悄悄在估算中预留缓冲。若存在风险，请在风险因素部分明确指出，以便团队决定如何处理。