{ "schemaVersion": "1.0", "item": { "slug": "estimation-atterns", "name": "Estimation Patterns", "source": "tencent", "type": "skill", "category": "开发工具", "sourceUrl": "https://clawhub.ai/wpank/estimation-atterns", "canonicalUrl": "https://clawhub.ai/wpank/estimation-atterns", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/estimation-atterns", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=estimation-atterns", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "README.md", "SKILL.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-30T16:55:25.780Z", "expiresAt": "2026-05-07T16:55:25.780Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=network", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=network", "contentDisposition": "attachment; filename=\"network-1.0.0.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/estimation-atterns" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/estimation-atterns", "agentPageUrl": "https://openagent3.xyz/skills/estimation-atterns/agent", "manifestUrl": "https://openagent3.xyz/skills/estimation-atterns/agent.json", "briefUrl": "https://openagent3.xyz/skills/estimation-atterns/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "Estimation Patterns (Meta-Skill)", "body": "Systematic approaches for producing accurate, defensible software estimates." }, { "title": "OpenClaw / Moltbot / Clawbot", "body": "npx clawhub@latest install estimation-patterns" }, { "title": "When to Use", "body": "Estimating a feature, bug fix, or project timeline\nBreaking down work for sprint planning or roadmap forecasting\nPresenting estimates to stakeholders or product managers\nReviewing historical accuracy to calibrate future estimates\nNoticing a pattern of missed deadlines or blown budgets" }, { "title": "Estimation Methods", "body": "Choose the method that matches your context and audience.\n\nMethodBest ForGranularityProsConsT-Shirt SizingRoadmap planning, backlog groomingXS, S, M, L, XLFast, low-friction, good for relative rankingNot actionable for schedulingStory PointsSprint planning, team velocityFibonacci (1-21)Abstracts away individual speed, tracks velocityMeaningless outside the team, gaming riskTime-BasedClient quotes, contractor workHours / daysUniversally understood, maps to budgetsAnchoring bias, implies false precisionThree-PointHigh-uncertainty tasksMin / likely / maxCaptures uncertainty range, enables PERTRequires discipline to set honest boundsReference ComparisonRecurring task typesRelative to pastGrounded in real data, hard to argue withRequires historical records, breaks on novelty\n\nThree-point formula (PERT):\n\nExpected = (Optimistic + 4 x Likely + Pessimistic) / 6\nStandard Deviation = (Pessimistic - Optimistic) / 6\n\nUse the standard deviation to express confidence ranges (e.g., \"3-5 days at 68% confidence, 2-6 days at 95%\")." }, { "title": "Task Decomposition", "body": "Break work down until every sub-task is < 4 hours of effort. Anything larger hides unknowns.\n\nLevelExampleTarget SizeEpicUser authentication system2-6 weeksFeatureOAuth2 login with Google3-10 daysTaskImplement callback handler1-3 daysSub-taskParse and validate OAuth token1-4 hoursAtomic stepWrite token expiry check function30-90 minutes\n\nDecomposition checklist:\n\nCan I describe what \"done\" looks like in one sentence?\nIs there exactly one unknown, or zero?\nCould a teammate pick this up without a walkthrough?\nIs it under 4 hours? If no — split again.\n\nIf you cannot decompose a task, it signals a spike is needed. Timebox the spike (2-4 hours), then re-estimate." }, { "title": "Complexity Multipliers", "body": "Apply these multipliers to your base estimate when complexity factors are present. Multipliers stack multiplicatively.\n\nFactorMultiplierRationaleNew technology / stack1.5xLearning curve, unexpected gotchas, doc-huntingUnclear requirements2.0xDiscovery work, rework cycles, stakeholder alignmentLegacy code1.5xUndocumented behavior, fragile tests, hidden couplingCross-team dependency1.5xCoordination overhead, blocking, API negotiationFirst-time task2.0xNo reference point, unknown unknowns dominateRegulatory / compliance1.5xAudit trails, review gates, documentation overhead\n\nExample: A 2-day base estimate on legacy code (1.5x) with unclear requirements (2.0x) becomes 2 x 1.5 x 2.0 = 6 days.\n\nRule: Never apply more than 3 multipliers — if that many factors converge, the task needs a spike or a scope reduction, not a bigger number." }, { "title": "Buffer Calculation", "body": "Raw estimates are point predictions. Reality is a distribution.\n\nBuffer TypeRule of ThumbWhen to ApplyKnown unknowns+20% of total estimateIntegration points, third-party APIs, minor gapsUnknown unknowns+50% of total estimateNew domain, first release, greenfield systemTeam velocity factor/ focus ratio (e.g., 0.7)Account for meetings, reviews, context switchingSequential dependency+10% per handoffEach team/person boundary adds coordination drag\n\nEffective estimate formula:\n\nEffective = (Base Estimate x Multipliers) / Focus Ratio + Buffer\n\nFocus ratio guidelines:\n\nScenarioTypical Focus RatioDedicated to one project0.75-0.85Split across 2 projects0.50-0.60On-call rotation active0.60-0.70Heavy meeting load (> 3h/day)0.45-0.55" }, { "title": "Historical Calibration", "body": "Track actual vs estimated to improve over time. This is the single most effective way to get better at estimation.\n\nTracking table:\n\nTaskEstimatedActualRatio (A/E)NotesAuth flow3 days5 days1.67OAuth docs were outdatedDashboard charts5 days4 days0.80Reused existing componentDB migration2 days6 days3.00Discovered data quality issues\n\nAccuracy ratio: Calculate your rolling average of Actual / Estimated over the last 10-20 tasks.\n\nRatio < 0.8 — you're overestimating (sandbagging or excessive buffers)\nRatio 0.8-1.2 — well calibrated\nRatio > 1.2 — you're underestimating (apply the ratio as a correction factor)\n\nCalibration action: Multiply future estimates by your rolling accuracy ratio until it converges toward 1.0." }, { "title": "Common Estimation Biases", "body": "Recognize these cognitive traps — awareness alone reduces their effect.\n\nBiasDescriptionMitigationPlanning FallacyAssuming best-case scenario despite past evidenceUse historical data, not intuitionAnchoringFirst number heard dominates all subsequent estimatesEstimate independently before discussingOptimism Bias\"It'll be simpler than last time\"Apply the three-point method, honor the pessimisticScope CreepEstimate stays fixed while scope growsRe-estimate when scope changes, alwaysHofstadter's Law\"It always takes longer, even when you account for it\"Add buffer, then add more buffer for novel workDunning-KrugerNovices underestimate; experts sometimes overestimateCross-check with a second estimatorSunk Cost PressureRefusing to re-estimate because the original was \"approved\"Treat estimates as living artifacts, update often" }, { "title": "Estimation by Task Type", "body": "Use these ranges as starting heuristics, then adjust with multipliers and historical data.\n\nTask TypeTypical RangeKey VariablesBug fix (isolated)2-8 hoursReproducibility, code familiarity, test coverageBug fix (systemic)1-3 daysRoot cause depth, blast radius, regression riskSmall feature1-3 daysSpec clarity, UI complexity, number of endpointsMedium feature3-10 daysCross-cutting concerns, data model changesLarge feature2-4 weeksArchitecture decisions, team coordinationRefactor (local)1-3 daysTest coverage, coupling, blast radiusRefactor (systemic)1-4 weeksNumber of callers, migration strategy neededSpike / research2-8 hours (timeboxed)Always timebox — output is knowledge, not codeDevOps / infra1-5 daysProvider docs quality, IAM complexity, testing" }, { "title": "Communication", "body": "How you present an estimate matters as much as the number itself.\n\nAlways present as a range, never a single number:\n\nBad: \"It'll take 5 days.\"\nGood: \"3-7 days, most likely 5. The range depends on the payment API response format — I'll know more after the spike.\"\n\nConfidence levels:\n\nConfidenceWhat It MeansWhen to UseHigh (+-15%)Well-understood scope, done similar beforeFamiliar task, clear specMedium (+-30%)Some unknowns, reasonable decompositionMost sprint-level estimatesLow (+-50%+)Significant unknowns, rough order of magnitudeRoadmap forecasts, presale quotes\n\nStakeholder communication rules:\n\nState the range and the confidence level together\nName the top 1-3 risks that could push toward the upper bound\nOffer to de-risk with a timeboxed spike before committing\nExplicitly state what is not included (e.g., \"does not include QA, deployment, or docs\")\nUpdate estimates proactively when new information surfaces — don't wait until the deadline" }, { "title": "Anti-Patterns", "body": "Anti-PatternWhy It's HarmfulBetter ApproachPadding silentlyErodes trust when discovered; hides real uncertaintyUse explicit buffers with stated rationaleSandbaggingDestroys velocity data; breeds complacencyTrack accuracy ratio, aim for calibrationNot decomposingLarge estimates hide unknowns and compound errorsBreak to < 4-hour sub-tasks, estimate bottom-upSingle-point estimatesImplies false certainty, no room for varianceAlways give a range with confidence levelEstimating under pressureAnchoring to what the stakeholder wants to hearAsk for time to decompose; never estimate on the spotCopy-paste estimatesEvery task has different context and risk profileEstimate fresh, use references as starting points onlyIgnoring rework cyclesFirst pass is rarely final — reviews, feedback, QAFactor in at least one review-and-revise loop" }, { "title": "NEVER Do", "body": "NEVER give a single-number estimate without a range — it communicates false precision and sets you up for failure\nNEVER estimate a task you haven't decomposed — large estimates are guesses wearing a suit\nNEVER let an old estimate stand after scope changes — estimates are invalidated the moment requirements shift\nNEVER estimate in someone else's units — your days are not their days; clarify assumptions about focus time and interrupts\nNEVER skip recording actuals — estimation without feedback is astrology, not engineering\nNEVER commit to an estimate made under pressure — say \"let me break this down and get back to you in an hour\"\nNEVER treat an estimate as a promise or a deadline — estimates are probabilistic forecasts, not contracts" } ], "body": "Estimation Patterns (Meta-Skill)\n\nSystematic approaches for producing accurate, defensible software estimates.\n\nInstallation\nOpenClaw / Moltbot / Clawbot\nnpx clawhub@latest install estimation-patterns\n\nWhen to Use\nEstimating a feature, bug fix, or project timeline\nBreaking down work for sprint planning or roadmap forecasting\nPresenting estimates to stakeholders or product managers\nReviewing historical accuracy to calibrate future estimates\nNoticing a pattern of missed deadlines or blown budgets\nEstimation Methods\n\nChoose the method that matches your context and audience.\n\nMethod\tBest For\tGranularity\tPros\tCons\nT-Shirt Sizing\tRoadmap planning, backlog grooming\tXS, S, M, L, XL\tFast, low-friction, good for relative ranking\tNot actionable for scheduling\nStory Points\tSprint planning, team velocity\tFibonacci (1-21)\tAbstracts away individual speed, tracks velocity\tMeaningless outside the team, gaming risk\nTime-Based\tClient quotes, contractor work\tHours / days\tUniversally understood, maps to budgets\tAnchoring bias, implies false precision\nThree-Point\tHigh-uncertainty tasks\tMin / likely / max\tCaptures uncertainty range, enables PERT\tRequires discipline to set honest bounds\nReference Comparison\tRecurring task types\tRelative to past\tGrounded in real data, hard to argue with\tRequires historical records, breaks on novelty\n\nThree-point formula (PERT):\n\nExpected = (Optimistic + 4 x Likely + Pessimistic) / 6\nStandard Deviation = (Pessimistic - Optimistic) / 6\n\n\nUse the standard deviation to express confidence ranges (e.g., \"3-5 days at 68% confidence, 2-6 days at 95%\").\n\nTask Decomposition\n\nBreak work down until every sub-task is < 4 hours of effort. Anything larger hides unknowns.\n\nLevel\tExample\tTarget Size\nEpic\tUser authentication system\t2-6 weeks\nFeature\tOAuth2 login with Google\t3-10 days\nTask\tImplement callback handler\t1-3 days\nSub-task\tParse and validate OAuth token\t1-4 hours\nAtomic step\tWrite token expiry check function\t30-90 minutes\n\nDecomposition checklist:\n\nCan I describe what \"done\" looks like in one sentence?\nIs there exactly one unknown, or zero?\nCould a teammate pick this up without a walkthrough?\nIs it under 4 hours? If no — split again.\n\nIf you cannot decompose a task, it signals a spike is needed. Timebox the spike (2-4 hours), then re-estimate.\n\nComplexity Multipliers\n\nApply these multipliers to your base estimate when complexity factors are present. Multipliers stack multiplicatively.\n\nFactor\tMultiplier\tRationale\nNew technology / stack\t1.5x\tLearning curve, unexpected gotchas, doc-hunting\nUnclear requirements\t2.0x\tDiscovery work, rework cycles, stakeholder alignment\nLegacy code\t1.5x\tUndocumented behavior, fragile tests, hidden coupling\nCross-team dependency\t1.5x\tCoordination overhead, blocking, API negotiation\nFirst-time task\t2.0x\tNo reference point, unknown unknowns dominate\nRegulatory / compliance\t1.5x\tAudit trails, review gates, documentation overhead\n\nExample: A 2-day base estimate on legacy code (1.5x) with unclear requirements (2.0x) becomes 2 x 1.5 x 2.0 = 6 days.\n\nRule: Never apply more than 3 multipliers — if that many factors converge, the task needs a spike or a scope reduction, not a bigger number.\n\nBuffer Calculation\n\nRaw estimates are point predictions. Reality is a distribution.\n\nBuffer Type\tRule of Thumb\tWhen to Apply\nKnown unknowns\t+20% of total estimate\tIntegration points, third-party APIs, minor gaps\nUnknown unknowns\t+50% of total estimate\tNew domain, first release, greenfield system\nTeam velocity factor\t/ focus ratio (e.g., 0.7)\tAccount for meetings, reviews, context switching\nSequential dependency\t+10% per handoff\tEach team/person boundary adds coordination drag\n\nEffective estimate formula:\n\nEffective = (Base Estimate x Multipliers) / Focus Ratio + Buffer\n\n\nFocus ratio guidelines:\n\nScenario\tTypical Focus Ratio\nDedicated to one project\t0.75-0.85\nSplit across 2 projects\t0.50-0.60\nOn-call rotation active\t0.60-0.70\nHeavy meeting load (> 3h/day)\t0.45-0.55\nHistorical Calibration\n\nTrack actual vs estimated to improve over time. This is the single most effective way to get better at estimation.\n\nTracking table:\n\nTask\tEstimated\tActual\tRatio (A/E)\tNotes\nAuth flow\t3 days\t5 days\t1.67\tOAuth docs were outdated\nDashboard charts\t5 days\t4 days\t0.80\tReused existing component\nDB migration\t2 days\t6 days\t3.00\tDiscovered data quality issues\n\nAccuracy ratio: Calculate your rolling average of Actual / Estimated over the last 10-20 tasks.\n\nRatio < 0.8 — you're overestimating (sandbagging or excessive buffers)\nRatio 0.8-1.2 — well calibrated\nRatio > 1.2 — you're underestimating (apply the ratio as a correction factor)\n\nCalibration action: Multiply future estimates by your rolling accuracy ratio until it converges toward 1.0.\n\nCommon Estimation Biases\n\nRecognize these cognitive traps — awareness alone reduces their effect.\n\nBias\tDescription\tMitigation\nPlanning Fallacy\tAssuming best-case scenario despite past evidence\tUse historical data, not intuition\nAnchoring\tFirst number heard dominates all subsequent estimates\tEstimate independently before discussing\nOptimism Bias\t\"It'll be simpler than last time\"\tApply the three-point method, honor the pessimistic\nScope Creep\tEstimate stays fixed while scope grows\tRe-estimate when scope changes, always\nHofstadter's Law\t\"It always takes longer, even when you account for it\"\tAdd buffer, then add more buffer for novel work\nDunning-Kruger\tNovices underestimate; experts sometimes overestimate\tCross-check with a second estimator\nSunk Cost Pressure\tRefusing to re-estimate because the original was \"approved\"\tTreat estimates as living artifacts, update often\nEstimation by Task Type\n\nUse these ranges as starting heuristics, then adjust with multipliers and historical data.\n\nTask Type\tTypical Range\tKey Variables\nBug fix (isolated)\t2-8 hours\tReproducibility, code familiarity, test coverage\nBug fix (systemic)\t1-3 days\tRoot cause depth, blast radius, regression risk\nSmall feature\t1-3 days\tSpec clarity, UI complexity, number of endpoints\nMedium feature\t3-10 days\tCross-cutting concerns, data model changes\nLarge feature\t2-4 weeks\tArchitecture decisions, team coordination\nRefactor (local)\t1-3 days\tTest coverage, coupling, blast radius\nRefactor (systemic)\t1-4 weeks\tNumber of callers, migration strategy needed\nSpike / research\t2-8 hours (timeboxed)\tAlways timebox — output is knowledge, not code\nDevOps / infra\t1-5 days\tProvider docs quality, IAM complexity, testing\nCommunication\n\nHow you present an estimate matters as much as the number itself.\n\nAlways present as a range, never a single number:\n\nBad: \"It'll take 5 days.\"\nGood: \"3-7 days, most likely 5. The range depends on the payment API response format — I'll know more after the spike.\"\n\nConfidence levels:\n\nConfidence\tWhat It Means\tWhen to Use\nHigh (+-15%)\tWell-understood scope, done similar before\tFamiliar task, clear spec\nMedium (+-30%)\tSome unknowns, reasonable decomposition\tMost sprint-level estimates\nLow (+-50%+)\tSignificant unknowns, rough order of magnitude\tRoadmap forecasts, presale quotes\n\nStakeholder communication rules:\n\nState the range and the confidence level together\nName the top 1-3 risks that could push toward the upper bound\nOffer to de-risk with a timeboxed spike before committing\nExplicitly state what is not included (e.g., \"does not include QA, deployment, or docs\")\nUpdate estimates proactively when new information surfaces — don't wait until the deadline\nAnti-Patterns\nAnti-Pattern\tWhy It's Harmful\tBetter Approach\nPadding silently\tErodes trust when discovered; hides real uncertainty\tUse explicit buffers with stated rationale\nSandbagging\tDestroys velocity data; breeds complacency\tTrack accuracy ratio, aim for calibration\nNot decomposing\tLarge estimates hide unknowns and compound errors\tBreak to < 4-hour sub-tasks, estimate bottom-up\nSingle-point estimates\tImplies false certainty, no room for variance\tAlways give a range with confidence level\nEstimating under pressure\tAnchoring to what the stakeholder wants to hear\tAsk for time to decompose; never estimate on the spot\nCopy-paste estimates\tEvery task has different context and risk profile\tEstimate fresh, use references as starting points only\nIgnoring rework cycles\tFirst pass is rarely final — reviews, feedback, QA\tFactor in at least one review-and-revise loop\nNEVER Do\nNEVER give a single-number estimate without a range — it communicates false precision and sets you up for failure\nNEVER estimate a task you haven't decomposed — large estimates are guesses wearing a suit\nNEVER let an old estimate stand after scope changes — estimates are invalidated the moment requirements shift\nNEVER estimate in someone else's units — your days are not their days; clarify assumptions about focus time and interrupts\nNEVER skip recording actuals — estimation without feedback is astrology, not engineering\nNEVER commit to an estimate made under pressure — say \"let me break this down and get back to you in an hour\"\nNEVER treat an estimate as a promise or a deadline — estimates are probabilistic forecasts, not contracts" }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/wpank/estimation-atterns", "publisherUrl": "https://clawhub.ai/wpank/estimation-atterns", "owner": "wpank", "version": "1.0.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/estimation-atterns", "downloadUrl": "https://openagent3.xyz/downloads/estimation-atterns", "agentUrl": "https://openagent3.xyz/skills/estimation-atterns/agent", "manifestUrl": "https://openagent3.xyz/skills/estimation-atterns/agent.json", "briefUrl": "https://openagent3.xyz/skills/estimation-atterns/agent.md" } }