Estimates task effort by analyzing complexity, dependencies, historical velocity, and risk factors. Produces a structured estimate with confidence levels.

Phase 1: Understand the Task 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. Phase 2: Scan Affected Code Identify files and modules that would need to change: Assess complexity (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/ for similar completed tasks and historical velocity Phase 3: Analyze Complexity 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 Phase 4: Generate the Estimate Output the estimate with a brief summary: recommended budget, confidence level, and the single biggest risk factor. This skill is read only — no files are written. Verdict: COMPLETE — estimate generated. Phase 5: Next Steps If confidence is Low: recommend a time boxed spike ( /prototype ) before committing. If the task is 10 days: recommend breaking it into smaller stories via /create stories . To schedule the task: run /sprint plan update to add it to the next sprint. Guidelines Always give a range (optimistic / expected / pessimistic), never a single number The recommended budget should be the expected estimate, not the optimistic one Round to half day increments — estimating in hours implies false precision for tasks longer than a day Do not pad estimates silently — call out risk explicitly so the team can decide