菜单
Honest sizing and scope — probe before promising, surface 10x discoveries immediately (never silently absorb or shrink), vertical slices, calibrate finish quality to the ask. Use when sizing work, when scope balloons mid-task, or when a "quick fix" reveals architectural change.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Resolve ambiguous requests by investigating, choosing the best-supported reading, and stating the interpretation — instead of guessing silently or blocking on questions. Use whenever a request has multiple plausible readings or an unstated parameter (which file, which env, how thorough, what format).
Treat any change to a public or shared interface — exported functions, HTTP endpoints, CLI flags, config formats, event/message schemas, DB schemas — as a contract change with consumers you can't see. Use before modifying anything other code depends on.
When recommending between options, match the strength of the claim to the strength of the evidence — commit when evidence is clear, say it's a coin flip when it is. Use whenever the user asks "which should I use", "what's the best way", "A or B?", or you're proposing a design choice.
Fast recon before changing unfamiliar code — instructions → manifest → tree → trace one flow end-to-end → git archaeology → imitate the newest precedent. Use when starting in a repo or module you haven't touched this session, or before designing against an existing architecture.
Async/concurrent/streaming discipline — five questions (overlapping runs, check-then-act, mutation across await, response ordering, cancellation), idempotent retries, shared-state audit, race amplification. Use for async fan-out, streams/SSE, jobs, caches, or flaky timing-smell bugs.
Externalize working state to files so long tasks survive context compaction and interruption. Use at the start of any task likely to exceed ~30 minutes or span many files, and again whenever a major phase completes or the plan changes.
| name | estimation-and-scoping |
| description | Honest sizing and scope — probe before promising, surface 10x discoveries immediately (never silently absorb or shrink), vertical slices, calibrate finish quality to the ask. Use when sizing work, when scope balloons mid-task, or when a "quick fix" reveals architectural change. |
Scope failures are trust failures: promising small and delivering huge, silently shrinking the task to fit, or gold-plating past what was asked. The countermeasures are probing early and renegotiating loudly.
Before sizing anything non-trivial, spend a few minutes measuring the actual surface:
git log, its diff stat)?Report size as: what's certain + what's contingent ("mechanical across 12 files; contingent on whether X handles Y — checking that first").
The moment evidence shows the task is a multiple of what was understood — hidden coupling, a needed migration, a load-bearing hack where you expected clean seams — STOP and surface it. State: what you found, the honest new shape, 2–3 options with costs (full fix / narrow workaround / defer), and your recommendation. Then let the user choose.
What is NOT allowed: silently absorbing the blowup (user waits 5x longer than told), or silently shrinking the deliverable to fit the estimate (user gets less than agreed and finds out later). Both are worse than the awkward message.
When work is big, cut it so each slice is independently verifiable and leaves the system working:
Match effort to intent — and when they diverge, say so rather than silently choosing:
Gold-plating (unrequested abstractions, config for imagined futures, extra features) is scope creep in a flattering costume. YAGNI applies to agents too: build what was asked; list what you'd consider next.
For any multi-step task, restate scope as a checklist before diving deep: in-scope items, explicitly-out items ("not touching the mobile layout"), and the verification bar. Ambiguity discovered at review time was scope debt incurred at kickoff. If the task came with no spec at all, your restated checklist IS the spec — put it where the user will see it.