fix-scope-before-estimating
Use when an estimate keeps moving because the thing being estimated keeps growing. Writes an explicit done-definition and exclusions first, so the estimate is attached to a fixed object.
- License 许可
- MIT
- 最近更新
- 2026-11-12
- Stars
- ★ 81
- Forks
- 17
01 前言 Front Matter
- name
- fix-scope-before-estimating
- description
- Use when an estimate keeps moving because the thing being estimated keeps growing. Writes an explicit done-definition and exclusions first, so the estimate is attached to a fixed object.
02 资源文件 3
- 许可证LICENSE1.0 KB
- 参考文档SOURCE.md353 B
- 参考文档TRUST.auto.yaml2.2 KB
03 SKILL.md 正文
Fix scope before estimating
An estimate on a moving definition is worthless: any number can be met by adding or removing work after the fact. Freeze what "done" means and what is out of scope, then estimate — and treat any change to that boundary as a change to the estimate.
Procedure
-
Write the done-definition in testable terms: "a user can reset their password via email link, on desktop, and the old password stops working." Not "improve auth."
-
List explicit exclusions: "no SMS reset, no admin-forced reset, no rate-limit UI." Exclusions are as load-bearing as inclusions.
-
Estimate only against the frozen definition in
notes/scope.md. If a step is needed but excluded, note that the exclusions assume it is not needed. -
Version the scope. When scope changes, bump it and re-estimate; never let a silent addition ride inside the old number:
notes/scope.md scope v1 (2026-02-01): as above — estimate 6-9 days scope v2 (2026-02-05): +SMS reset (asked by support) — estimate 9-14 days -
Attach the estimate's confidence to the scope version, so a "5-day" answer is never reused for a larger v2.
-
If asked for a number before scope is fixed, give a range and say it is conditional on scope: any change moves it.
-
Keep the exclusions visible in the same file reviewers read, not buried in a thread.
Pitfalls
- Estimating a feature name rather than a behaviour, so the object the number refers to is undefined.
- Accepting a small mid-flight addition as "obviously in scope," which is how a 6-day estimate becomes 14 with nobody deciding.
- Listing inclusions but no exclusions, so everything is arguably in scope.
- Re-using a v1 estimate after a v2 scope change because the ticket number stayed the same.
- Writing done-definition so loosely ("works well") that it cannot be tested and therefore cannot be frozen.
Verification
grep -n 'scope v' notes/scope.md
# passes when each scope version has a date, its additions/removals, and its own estimate
Report the frozen done-definition, the exclusions, the scope version the estimate belongs to, and the estimate.
04 同仓库更多 Skills
recipe-performance
Diagnose a specific MetaMask user flow's real-app performance and Sentry critical-user-flow telemetry with deterministic mm-harness recipes. Use for CUF boundaries, cold/warm/background-resume behavior, latency regressions, lifecycle tags, duplicate or blocking network requests, long tasks, layout/paint cost, screen redraws, React rerenders, or browser trace analysis where tests alone cannot prove the real app.
mexc-spot-websocket
MEXC Spot WebSocket workflows for public streams, protobuf handling, depth maintenance, listen keys, and private streams without exposing API keys.
mexc-spot-rest
MEXC Spot REST workflows for public data, signed account requests, orders, wallet/admin actions, and secure signing without exposing API keys.
mexc-futures-websocket
MEXC Futures WebSocket workflows for public streams, private account/order/position streams, ping/pong, subscriptions, and depth maintenance.
0xklen-version-and-refresh-sanctions-lists
暂无简介
verify-tests-cover-changed-lines
Use when a PR adds code that the existing suite may not exercise. Measures patch coverage — the share of newly changed lines hit by tests — before approving.