About

Imported from akillness/jeo-skills (.agent-skills/task-estimation/SKILL.md) via skills.sh. Install upstream with npx skills add akillness/jeo-skills --skill task-estimation. Copyright stays with the author (MIT).

Task Estimation

Name: task-estimation
Author: akillness

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 | sprint-candidate | forecast-support | discovery-spike | milestone-cross-functional
  domain: developer-workflow | web-fullstack | product-ops | marketing-gtm | game-development | mixed
  source_material: issue-spec | roadmap-note | launch-packet | gdd-playtest | bug-cluster | chat-context | unknown
  novelty: low | medium | high
  confidence: high | medium | low
  output_shape: estimate-packet | comparison-table | spike-brief | unknown

Use one primary mode per run:

coarse-triage — rough sizing for intake, backlog cleanup, or roadmap comparison
sprint-candidate — relative sizing for near-term work
forecast-support — range-and-assumptions help for scope/date conversations
discovery-spike — estimate investigation/prototype work, not final delivery
milestone-cross-functional — work where engineering is only part of the burden

Do not blend several primary modes into one answer.

Step 2: Gather the smallest credible evidence packet

Pull only the evidence needed to support an honest estimate:

item summary and intended outcome
current artifacts: issue, PRD, spec, note dump, playtest notes, bug list, launch notes
systems touched: frontend, backend, data, infra, QA, analytics, content, store/release, live ops
dependencies, approvals, or external constraints
known unknowns that could swing the estimate

If evidence is thin, lower confidence immediately or switch to discovery-spike.

Step 3: Choose the lightest estimate unit

Use references/intake-packets-and-route-outs.md.

Default selection:

T-shirt / coarse bucket for intake and roadmap comparison
Story points / relative scale for sprint-candidate discussion
Range + assumptions for forecast-support packets
Spike estimate when uncertainty dominates

Rules:

Keep relative sizing visible even if someone asks for time.
Translate to time only after stating assumptions.
If discovery and delivery are mixed together, estimate them separately.

Step 4: Calibrate against anchors and burden

Do not estimate in a vacuum.

Compare against 2-3 anchors when possible:

one small familiar item
one medium normal item
one large item that usually needs splitting

Check burden explicitly:

complexity and novelty
unknowns and dependency count
testing / QA / validation load
rollout, migration, approval, or coordination work
content, localization, certification, or live-ops burden for GTM/game cases

If no anchors exist, say so and increase caution rather than pretending confidence.

Step 5: Produce one estimate packet

Every answer should include:

estimate mode
estimate unit and value
confidence
why this size
uncertainty drivers
dependencies / approvals
split-or-spike recommendation
forecast note: how this should and should not be used
adjacent handoff when the next job changed

Use one compact packet, not a long agile tutorial.

Step 6: Trigger split-or-spike decisions early

Recommend a split when:

the estimate reaches 13, XL, or similar “too big” territory
discovery and implementation are bundled together
more than one owner/system/approval path is hidden in one item
validation, migration, or launch burden is non-trivial

Recommend a spike when:

key unknowns dominate the estimate
external APIs, vendors, or platform behavior are unclear
product/game direction is still being validated
the estimate would otherwise be fake precision

Step 7: Route adjacent work explicitly

Before finalizing, state what comes next:

use task-planning for slice design, acceptance criteria, owners, and execution packets
use standup-meeting when the next need is daily coordination on already-chosen work
use sprint-retrospective when the next need is learning whether the sizing process worked
do not turn this skill into roadmap commitments, status theater, or board management

Output format

# Estimate Packet

## Mode
- Primary mode:
- Domain:
- Why it fits:

## Evidence used
- Main artifacts:
- Systems / functions touched:
- Assumptions / gaps:

## Recommended estimate
- Unit:
- Estimate:
- Confidence:
- Comparable anchors:

## Why this size
- ...
- ...

## Uncertainty drivers
- ...

## Dependencies / approvals
- ...

## Split or spike recommendation
- Keep as-is | Split | Estimate the spike first
- Reason:

## Forecast note
- Safe use:
- Unsafe use:

## Adjacent handoff
- Next skill / process:

Examples

Example 1: Sprint-candidate SaaS feature

Input

Estimate adding Slack OAuth login plus account linking for the next sprint. We already have user accounts and one OAuth provider in production.

Good output direction

mode: sprint-candidate
unit: story points
estimate: moderate relative slice with medium confidence
include auth-flow and verification burden
route final decomposition to task-planning

Example 2: Product/ops roadmap item with high ambiguity

Input

How big is a full creator analytics dashboard for Q3? Metrics, data sources, and stakeholder definitions are still fuzzy.

Good output direction

mode: coarse-triage or discovery-spike
unit: t-shirt size or spike brief
confidence: low
explicitly say the estimate is not ready for a hard date conversation

Example 3: Game milestone packet

Input

Estimate adding a tutorial checkpoint system before the public demo build. It touches save state, UI messaging, QA regression, and demo flow polish.

Good output direction

mode: milestone-cross-functional
include non-code burden like QA/polish and release readiness
recommend split or spike if checkpoint rules are still undefined

Best practices

Estimate the current decision horizon, not the entire dream scope.
Keep relative sizing separate from hard commitments.
Use anchors and comparable work when available.
Separate discovery from delivery early.
Surface non-code burden instead of hiding it in one engineering number.
Prefer one compact estimate packet over a lecture on agile theory.
If the estimate is weak, say it is weak.

References

Use it

Copy one of these into your project. Installing also returns the manifest and these snippets.

yaml

targets:
  - https://api.opensmartroute.ai/api/v1/registry/akillness-jeo-skills-task-estimation/manifest   # or paste the manifest below

Manifest

An Open Capability Manifest: the router reads it to know what this does, what it costs and when to pick it.

akillness-jeo-skills-task-estimation.ocm.jsonjson

{
  "ocm": "1",
  "id": "akillness-jeo-skills-task-estimation",
  "kind": "skill",
  "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`.",
  "publisher": "akillness",
  "version": "1.0.0",
  "capabilities": {
    "domains": [
      "customer_support",
      "creative"
    ],
    "tags": [
      "skill-md",
      "task-estimation",
      "story-points",
      "t-shirt-sizing",
      "planning-poker",
      "forecasting",
      "uncertainty",
      "project-management",
      "game-development",
      "skills-sh"
    ],
    "languages": [
      "en"
    ]
  },
  "quality_prior": 0.6,
  "examples": [
    "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`."
  ],
  "primary": false,
  "metadata": {
    "source": {
      "provider": "skills.sh",
      "repository": "https://github.com/akillness/jeo-skills",
      "path": ".agent-skills/task-estimation/SKILL.md",
      "ref": "HEAD",
      "url": "https://www.skills.sh/akillness/jeo-skills/task-estimation",
      "key": "akillness/jeo-skills/.agent-skills/task-estimation/SKILL.md"
    },
    "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-suppor",
    "allowed_tools": [
      "Bash",
      "Read",
      "Write",
      "Edit",
      "Glob",
      "Grep"
    ],
    "license": "MIT"
  },
  "instructions": "# Task Estimation\n\nUse this skill when the job is to turn messy scope into **one estimate packet with the right horizon, honest uncertainty, and one next move**.\n\n`task-estimation` owns:\n- relative sizing before commitment\n- choosing the lightest credible estimate unit\n- confidence / uncertainty language\n- split-or-spike decisions\n- short forecast-safe translation notes\n- cross-functional burden visibility for launch or game work\n\nRead these support docs before unusual cases or when the request starts to sprawl:\n- [references/estimation-modes.md](references/estimation-modes.md)\n- [references/i",
  "cost": {
    "context_tokens": 2236
  }
}

Fetch it by URL: GET /api/v1/registry/akillness-jeo-skills-task-estimation/manifest?version=1.0.0

Reviews

Star ratings from people who tried it. One review per account; edit yours any time.

No reviews yet. Install it, try it, and be the first to rate it.