mcpField
T
task-estimation

task-estimation

github.com/akillness生产力53395 次安装4 天前更新
代码仓库

关于 task-estimation

面向团队的任务估算技能，将模糊范围整理为包含估算单位、置信度、不确定因素和下一步建议的简明估算包。它根据决策阶段选择相对规模、范围估算或探索性任务，并明确拆分或先行验证的需要。

主要功能

  1. 01按决策阶段选择估算模式
  2. 02选择合适的估算单位
  3. 03说明置信度与不确定因素
  4. 04识别拆分或探索需求
  5. 05呈现跨职能工作负担

适用场景

  1. 01为待办事项粗略排序
  2. 02准备迭代候选任务估算
  3. 03评估路线图工作的不确定性
  4. 04估算发布或游戏里程碑工作

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/akillness/jeo-skills --skill task-estimation

安装后在 Claude Code 中输入/task-estimation确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

SKILL.toon
evals/
evals.json
references/
boundary-guide.md
estimation-modes.md
intake-packets-and-route-outs.md

详细介绍

任务估算

当需要将混乱的范围整理成一份包含合适规划时长、诚实的不确定性和一个后续行动的估算材料包时，使用此技能。

task-estimation 负责：

  • 承诺之前进行相对规模评估
  • 选择最轻量且可信的估算单位
  • 描述置信度／不确定性
  • 决定拆分还是进行探索性调查
  • 编写简短且不影响预测的说明
  • 让发布或游戏项目中的跨职能工作量清晰可见

遇到特殊情况或请求开始发散时，请先阅读以下支持文档：

何时使用此技能

  • 用户询问“这项工作规模有多大？”“风险有多高？”或“应该如何估算这项工作？”
  • 团队需要在冲刺或里程碑讨论之前准备故事点、T 恤尺码、计划扑克或置信度表述。
  • 路线图事项、Bug 集合、发布任务或游戏里程碑需要估算，但不能假装它已具备可靠的排期依据。
  • 工作内容足够混杂，首个有用的产出应是一份估算材料包，并附上拆分／探索性调查建议。
  • 估算必须揭示依赖项、审批、QA、发布、内容或线上运营工作量，而非只计算编码工作量。

何时不使用此技能

  • 主要工作是拆解为可直接执行的切片 → task-planning。
  • 主要工作是每日状态、阻塞项或团队同步 → standup-meeting。
  • 主要工作是交付后复盘流程表现 → sprint-retrospective。
  • 用户要求给出确定的发布日期、固定承诺或不带任何不确定性表述的高管承诺。
  • 唯一诚实的估算对象是探索工作本身。此时应估算探索性调查／原型／垂直切片工作，而不是幻想中的最终实现。

说明

第 1 步：确定一种主要估算模式

在给出任何数字之前，先规范化请求。

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

每次只使用一种主要模式：

  • coarse-triage — 用于受理、待办事项清理或路线图比较的粗略规模评估
  • sprint-candidate — 对近期工作进行相对规模评估
  • forecast-support — 为范围／日期讨论提供区间和假设
  • discovery-spike — 估算调查／原型工作，而非最终交付
  • milestone-cross-functional — 工程工作仅占总工作量一部分的任务

不要在一个回答中混用多种主要模式。

第 2 步：收集最精简且可信的证据材料包

只收集支持诚实估算所需的证据：

  • 事项摘要和预期结果
  • 当前材料：Issue、PRD、规格说明、笔记汇总、试玩笔记、Bug 列表、发布说明
  • 涉及的系统：前端、后端、数据、基础设施、QA、分析、内容、商店／发布、线上运营
  • 依赖项、审批或外部约束
  • 可能显著影响估算的已知未知项

如果证据不足，应立即降低置信度，或切换到 discovery-spike。

第 3 步：选择最轻量的估算单位

使用 references/intake-packets-and-route-outs.md。

默认选择：

  • T 恤尺码／粗略区间，用于受理和路线图比较
  • 故事点／相对尺度，用于冲刺候选项讨论
  • 区间 + 假设，用于预测支持材料包
  • 探索性调查估算，用于不确定性占主导的情况

规则：

  • 即使有人要求给出时间，也要明确呈现相对规模。
  • 陈述假设之后，才换算成时间。
  • 如果探索工作和交付工作混在一起，应分别估算。
第 4 步：对照基准并评估工作负担

不要凭空估算。

尽可能对照 2–3 个基准：

  • 一个熟悉的小型事项
  • 一个常规的中型事项
  • 一个通常需要拆分的大型事项

明确检查工作负担：

  • 复杂度和新颖性
  • 未知因素和依赖项数量
  • 测试 / QA / 验证工作量
  • 发布、迁移、审批或协调工作
  • GTM / 游戏场景中的内容、本地化、认证或实时运营工作量

如果没有可参考的基准，就如实说明，并提高谨慎程度，而不要假装有把握。

第 5 步：给出一份估算包

每次回答都应包含：

  • 估算模式
  • 估算单位和值
  • 置信度
  • 规模依据
  • 不确定因素
  • 依赖项 / 审批
  • 是否建议拆分或进行 Spike
  • 预测说明：该估算应如何使用，以及不应如何使用
  • 后续工作变化时的相邻交接

使用一份精简的估算包，不要写成长篇敏捷教程。

第 6 步：尽早决定是否拆分或进行 Spike

在以下情况下建议拆分：

  • 估算达到 13、XL 或类似“过大”的范围
  • 探索和实施捆绑在一起
  • 一个事项中暗含多个负责人 / 系统 / 审批流程
  • 验证、迁移或发布工作量不可忽略

在以下情况下建议进行 Spike：

  • 估算主要受关键未知因素影响
  • 外部 API、供应商或平台行为尚不明确
  • 产品 / 游戏方向仍在验证中
  • 否则估算会显得精确，实则虚假
第 7 步：明确交接相邻工作

定稿前，说明接下来要做什么：

  • 切片设计、验收标准、负责人和执行包使用 task-planning
  • 如果下一步需要围绕已选定的工作进行每日协调，使用 standup-meeting
  • 如果下一步需要了解估算流程是否有效，使用 sprint-retrospective
  • 不要把此技能变成路线图承诺、状态作秀或看板管理

输出格式

# 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:

示例

示例 1：冲刺候选 SaaS 功能

输入

估算一下在下个冲刺中添加 Slack OAuth 登录和账号关联的工作量。我们已经有用户账号，且有一个 OAuth 提供商已在生产环境中运行。

良好输出方向

  • 模式：sprint-candidate
  • 单位：故事点
  • 估算：相对适中的切片，置信度中等
  • 包含身份验证流程和验证工作量
  • 将最终拆解交给 task-planning
示例 2：模糊度较高的产品 / 运营路线图事项

输入

第 3 季度的完整创作者分析仪表板工作量有多大？指标、数据源和相关方定义仍不明确。

良好输出方向

  • 模式：coarse-triage 或 discovery-spike
  • 单位：T 恤尺码或 Spike 简报
  • 置信度：低
  • 明确说明该估算尚不适合用于确定具体日期
示例 3：游戏里程碑方案

输入

估算一下在公开演示版本构建前添加教程检查点系统的工作量。它涉及存档状态、UI 消息、QA 回归测试和演示流程打磨。

良好输出方向

  • 模式：milestone-cross-functional
  • 纳入 QA / 打磨和发布准备等非编码工作量
  • 如果检查点规则尚未明确，建议拆分或进行 Spike

最佳实践

  1. 估算当前决策周期内的工作，而不是全部理想范围。
  2. 将相对规模与硬性承诺分开。
  3. 有可用的基准和可比工作时，就加以利用。
  4. 尽早将探索与交付分开。
  5. 明确呈现非编码工作量，不要将其藏在单一工程数字中。
  6. 优先给出一份精简的估算包，而不是长篇讲解敏捷理论。
  7. 如果估算依据不足，就明确说明。

参考资料

评论

支持 Markdown