| name | task-estimation |
| description | Turn fuzzy work into one honest estimate packet by choosing the right sizing horizon, naming confidence and uncertainty, and separating discovery from delivery before anyone treats the number like a promise. Use when the user needs story points, t-shirt sizing, planning-poker prep, forecast-safe language, split-or-spike guidance, or cross-functional sizing across developer workflow, web/fullstack, product/ops, marketing/GTM, or game work. Route decomposition to `task-planning`, daily coordination to `standup-meeting`, and retrospective process learning to `sprint-retrospective`.
|
| allowed-tools | Bash Read Write Edit Glob Grep |
| compatibility | Best for backlog items, specs, issue lists, PRDs, GDDs, launch notes, support requests, and roadmap slices that need relative sizing and uncertainty language. This is an estimation and forecast-support workflow, not a deadline generator or commitment engine.
|
| license | MIT |
| metadata | {"tags":"task-estimation, story-points, t-shirt-sizing, planning-poker, forecasting, uncertainty, project-management, game-development","platforms":"Claude, ChatGPT, Gemini, Codex","version":"2.0.0","source":"akillness/jeo-skills","modernization":"2026-04-12T00:00:00.000Z","hardening":"2026-04-19T00:00:00.000Z"} |
Task Estimation
Use this skill when the job is to turn messy scope into one estimate packet with the right horizon, honest uncertainty, and one next move.
task-estimation owns:
- relative sizing before commitment
- choosing the lightest credible estimate unit
- confidence / uncertainty language
- split-or-spike decisions
- short forecast-safe translation notes
- cross-functional burden visibility for launch or game work
Read these support docs before unusual cases or when the request starts to sprawl:
When to use this skill
- A user asks “how big is this?”, “how risky is this?”, or “how should we estimate this?”
- A team needs story points, t-shirt sizing, planning-poker preparation, or confidence framing before a sprint or milestone discussion.
- A roadmap item, bug cluster, launch task, or game milestone needs an estimate without pretending it is already schedule-safe.
- Work is mixed enough that the first useful output is an estimate packet plus split/spike guidance.
- The estimate must surface dependencies, approvals, QA, release, content, or live-ops burden rather than only code effort.
When not to use this skill
- The main job is decomposition into execution-ready slices →
task-planning.
- The main job is daily status, blockers, or team synchronization →
standup-meeting.
- The main job is reviewing how the process went after delivery →
sprint-retrospective.
- The user wants a hard ship date, fixed commitment, or executive promise with no uncertainty language.
- The only honest estimate is discovery itself. In that case, estimate the spike/prototype/vertical-slice work, not the fantasy final implementation.
Instructions
Step 1: Classify one primary estimation mode
Normalize the request before assigning any numbers.
estimation_intake:
primary_mode: coarse-triage |
