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

Estimate 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. Read them by section: find the headings you need with the Grep tool (pattern ^ , content mode) and Read those ranges with offset and limit. Phase 2: Scan Affected Code Identify files and modules that would need to change: Measure size and branching with Grep, per affected file — Read, Glob and Grep are this skill's only tools, so these counts are the measurement: Size: Grep pattern="[^[:space:]]" path="[file]" output mode="count" — non blank lines. Branching: Grep pattern="(^ [^A Za z0 9 ])(if elif for foreach while match switch case catch)([^A Za z0 9 ] $) && [ ][ ]" path="[file]" output mode="count" — lines holding a branch or a boolean operator. The count approximates cyclomatic complexity (comments and strings count too); report it as that, never as a measured complexity. Dependencies: what each file pulls in — preload / load( (GDScript), using (C ), include (C++) — and which other files reference it. Name any file Grep could not count (missing, binary, unreadable) under Notes and Assumptions rather than leaving it out of the totals. 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. If there is none , say so under Notes and Assumptions — "No sprint history found; this estimate is not calibrated to the team's velocity" — and treat that as a risk in the confidence level, not as a silent padding of the figures. Phase 3: Analyze Complexity Factors Code Complexity: Size and branching of the affected files (Phase 2's Grep counts) 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 (if the project has no sprint plan, as on the default minimal workflow, add it to the brief's build order instead). 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 Confidence is Low whenever the approach is undecided or the core requirements are still TBD — a range built on an unmade decision is a guess