estimation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Estimation Skill

Estimation Skill(估算技能)

Core Principle: Estimate before committing.
核心原则:承接任务前先估算。

When to Invoke

调用时机

  • Before starting a large or complex task
  • When user asks about complexity or scope
  • Before providing time commitments
  • When decomposing tasks for orchestration
  • When uncertain about task scope

  • 启动大型或复杂任务前
  • 用户询问复杂度或范围时
  • 给出时间承诺前
  • 为任务编排拆分任务时
  • 对任务范围不确定时

Complexity Factors

复杂度因素

Assess each factor to determine overall complexity:
FactorWeightQuestions to Ask
Files to modifyHighHow many files? How spread across codebase?
New patterns requiredHighDoes this require patterns not in codebase?
External dependenciesHighNew APIs, services, or integrations?
Test coverage neededMediumUnit, integration, e2e tests required?
Documentation updatesLowREADME, API docs, comments needed?
Breaking changesHighWill this break existing functionality?
Unknown territoryHighAre you familiar with this code area?
评估以下各项因素以确定整体复杂度:
因素权重需考量的问题
需要修改的文件需要修改多少文件?在代码库中的分布如何?
需引入新实现模式是否需要使用代码库中未有的实现模式?
外部依赖项是否需要新增API、服务或集成?
所需测试覆盖是否需要单元测试、集成测试、端到端测试?
文档更新是否需要更新README、API文档或代码注释?
破坏性变更是否会破坏现有功能?
不熟悉的领域你对该代码区域是否熟悉?

Complexity Scoring

复杂度评分

LOW: 1-2 files, existing patterns, no new dependencies
MEDIUM: 3-5 files, minor new patterns, limited dependencies
HIGH: 6+ files, new patterns, new dependencies, cross-cutting
UNKNOWN: Cannot assess without more exploration

LOW: 1-2个文件,使用现有模式,无新增依赖项
MEDIUM: 3-5个文件,少量新模式,有限的依赖项
HIGH: 6个及以上文件,新实现模式,新增依赖项,跨模块影响
UNKNOWN: 无法评估,需进一步探索

Estimation Protocol

估算流程

Step 1: Scope Analysis

步骤1:范围分析

1. What is the task asking for?
2. What files will likely need changes?
3. What patterns exist for similar features?
4. What dependencies are involved?
5. What testing is required?
1. 任务要求是什么?
2. 哪些文件可能需要修改?
3. 类似功能已有哪些实现模式?
4. 涉及哪些依赖项?
5. 需要哪些测试?

Step 2: Factor Assessment

步骤2:因素评估

For each complexity factor:
  • Score as: none (0), low (1), medium (2), high (3)
  • Note specific concerns
针对每个复杂度因素:
  • 评分:无(0)、低(1)、中(2)、高(3)
  • 记录具体关注点

Step 3: Risk Identification

步骤3:风险识别

Risks to identify:
- Areas of uncertainty
- Potential blockers
- Dependencies on external factors
- Technical debt implications
需要识别的风险:
- 不确定的领域
- 潜在的阻碍
- 依赖外部因素的部分
- 技术债务的影响

Step 4: Output Estimation

步骤4:输出估算结果

Use the template below.

使用以下模板。

Output Template

输出模板

yaml
estimation:
  timestamp: [ISO 8601]
  task: |
    [Task description]

  scope:
    files_affected:
      known:
        - [file1.ts - reason]
        - [file2.ts - reason]
      likely:
        - [file3.ts - reason]
      unknown: [count or "cannot determine"]

    changes_required:
      - type: [new_file | modification | deletion]
        description: [what change]
      - type: [type]
        description: [what change]

  complexity:
    overall: [low | medium | high | unknown]
    factors:
      files_to_modify: [0-3]
      new_patterns: [0-3]
      external_dependencies: [0-3]
      test_coverage: [0-3]
      documentation: [0-3]
      breaking_changes: [0-3]
      unknown_territory: [0-3]
    total_score: [sum]

  risks:
    - risk: "[Risk description]"
      likelihood: [low | medium | high]
      impact: [low | medium | high]
      mitigation: "[How to address]"

  unknowns:
    - "[What you couldn't determine]"
    - "[What needs clarification]"

  recommendations:
    approach: |
      [Recommended approach]
    alternatives:
      - "[Alternative approach 1]"
    next_steps:
      - "[First step]"
      - "[Second step]"

  confidence: 0.0
  evidence:
    - "[What you examined]"

yaml
estimation:
  timestamp: [ISO 8601]
  task: |
    [Task description]

  scope:
    files_affected:
      known:
        - [file1.ts - reason]
        - [file2.ts - reason]
      likely:
        - [file3.ts - reason]
      unknown: [count or "cannot determine"]

    changes_required:
      - type: [new_file | modification | deletion]
        description: [what change]
      - type: [type]
        description: [what change]

  complexity:
    overall: [low | medium | high | unknown]
    factors:
      files_to_modify: [0-3]
      new_patterns: [0-3]
      external_dependencies: [0-3]
      test_coverage: [0-3]
      documentation: [0-3]
      breaking_changes: [0-3]
      unknown_territory: [0-3]
    total_score: [sum]

  risks:
    - risk: "[Risk description]"
      likelihood: [low | medium | high]
      impact: [low | medium | high]
      mitigation: "[How to address]"

  unknowns:
    - "[What you couldn't determine]"
    - "[What needs clarification]"

  recommendations:
    approach: |
      [Recommended approach]
    alternatives:
      - "[Alternative approach 1]"
    next_steps:
      - "[First step]"
      - "[Second step]"

  confidence: 0.0
  evidence:
    - "[What you examined]"

Complexity Thresholds

复杂度阈值

Low Complexity (Score 0-5)

低复杂度(评分0-5)

  • Can likely be completed in single session
  • Straightforward implementation
  • Well-understood patterns
  • 通常可在单次会话内完成
  • 实现方式直接明了
  • 使用成熟的已知模式

Medium Complexity (Score 6-10)

中等复杂度(评分6-10)

  • May require multiple sessions
  • Some exploration needed
  • Some new patterns required
  • 可能需要多轮会话
  • 需进行一定探索
  • 需引入少量新模式

High Complexity (Score 11+)

高复杂度(评分11+)

  • Definitely requires planning
  • Significant exploration needed
  • Consider breaking into phases
  • 必须进行规划
  • 需大量探索工作
  • 建议拆分为多个阶段

Unknown Complexity

未知复杂度

  • Cannot assess without more information
  • Recommend context-gathering first
  • Ask user clarifying questions

  • 缺乏足够信息无法评估
  • 建议先收集上下文信息
  • 向用户询问澄清问题

Rules

规则

[!CRITICAL] NEVER estimate without understanding scope. ALWAYS include unknowns.
[!CRITICAL] 绝不要在不了解范围的情况下进行估算。 务必包含未知项。

Do

需执行

  • List specific files you expect to change
  • Identify risks and unknowns
  • Provide confidence level
  • Recommend next steps
  • 列出预计会修改的具体文件
  • 识别风险和未知项
  • 提供置信度
  • 推荐后续步骤

Don't

禁止

  • Give point estimates (use ranges/categories)
  • Promise delivery timelines
  • Understate complexity to seem helpful
  • Skip the unknown factors

  • 给出精确的点估算(使用范围/类别)
  • 承诺交付时间
  • 为了显得高效而低估复杂度
  • 忽略未知因素

Integration with Other Skills

与其他技能的集成

After EstimationInvoke
Need more context
context-gathering
skill
Ready to plan implementation
writing-plans
skill
Ready to execute
orchestration
skill
估算完成后调用
需要更多上下文
context-gathering
skill
准备规划实现方案
writing-plans
skill
准备执行任务
orchestration
skill

Chaining Rules

链式调用规则

  1. IF unknowns are significant THEN invoke
    context-gathering
    first
  2. IF complexity is high THEN recommend phased approach
  3. AFTER estimation accepted THEN proceed to
    writing-plans

  1. 如果未知项较多 先调用
    context-gathering
    skill
  2. 如果复杂度为高 推荐分阶段实现
  3. 估算结果确认后 继续调用
    writing-plans
    skill

Example

示例

Task: "Add user authentication to the API"
yaml
estimation:
  timestamp: "2024-01-15T10:00:00Z"
  task: |
    Add user authentication to the existing Express API

  scope:
    files_affected:
      known:
        - src/routes/auth.ts - new route file
        - src/middleware/auth.ts - new middleware
        - src/models/user.ts - user model changes
      likely:
        - src/routes/index.ts - route registration
        - tests/auth.test.ts - new tests
      unknown: 2-3 additional files for utilities

    changes_required:
      - type: new_file
        description: Authentication routes (login, register, logout)
      - type: new_file
        description: Auth middleware for protected routes
      - type: modification
        description: Add auth to existing protected routes

  complexity:
    overall: medium
    factors:
      files_to_modify: 2
      new_patterns: 2
      external_dependencies: 2
      test_coverage: 2
      documentation: 1
      breaking_changes: 1
      unknown_territory: 1
    total_score: 11

  risks:
    - risk: "Password hashing library choice"
      likelihood: low
      impact: medium
      mitigation: "Use bcrypt, well-established"
    - risk: "JWT secret management"
      likelihood: medium
      impact: high
      mitigation: "Environment variable, document required setup"

  unknowns:
    - "Which routes should be protected?"
    - "OAuth integration needed?"
    - "Session vs JWT preference?"

  recommendations:
    approach: |
      Implement JWT-based auth with bcrypt password hashing.
      Start with login/register, add middleware, then protect routes.
    alternatives:
      - "Session-based auth with express-session"
      - "OAuth with passport.js"
    next_steps:
      - "Clarify auth requirements with user"
      - "Create detailed plan with writing-plans skill"

  confidence: 0.7
  evidence:
    - "Reviewed existing routes structure"
    - "Checked package.json for auth libraries"
    - "Examined similar features in codebase"
任务:"为API添加用户认证"
yaml
estimation:
  timestamp: "2024-01-15T10:00:00Z"
  task: |
    Add user authentication to the existing Express API

  scope:
    files_affected:
      known:
        - src/routes/auth.ts - new route file
        - src/middleware/auth.ts - new middleware
        - src/models/user.ts - user model changes
      likely:
        - src/routes/index.ts - route registration
        - tests/auth.test.ts - new tests
      unknown: 2-3 additional files for utilities

    changes_required:
      - type: new_file
        description: Authentication routes (login, register, logout)
      - type: new_file
        description: Auth middleware for protected routes
      - type: modification
        description: Add auth to existing protected routes

  complexity:
    overall: medium
    factors:
      files_to_modify: 2
      new_patterns: 2
      external_dependencies: 2
      test_coverage: 2
      documentation: 1
      breaking_changes: 1
      unknown_territory: 1
    total_score: 11

  risks:
    - risk: "Password hashing library choice"
      likelihood: low
      impact: medium
      mitigation: "Use bcrypt, well-established"
    - risk: "JWT secret management"
      likelihood: medium
      impact: high
      mitigation: "Environment variable, document required setup"

  unknowns:
    - "Which routes should be protected?"
    - "OAuth integration needed?"
    - "Session vs JWT preference?"

  recommendations:
    approach: |
      Implement JWT-based auth with bcrypt password hashing.
      Start with login/register, add middleware, then protect routes.
    alternatives:
      - "Session-based auth with express-session"
      - "OAuth with passport.js"
    next_steps:
      - "Clarify auth requirements with user"
      - "Create detailed plan with writing-plans skill"

  confidence: 0.7
  evidence:
    - "Reviewed existing routes structure"
    - "Checked package.json for auth libraries"
    - "Examined similar features in codebase"