菜单
Use when a task carries design, implementation, or judgment weight and the obvious move is to start solving before the object, operator, and acceptance criteria are pinned down. Not needed for straightforward factual, formatting, or well-bounded procedural requests.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the direct message or commitment handoff needs the right register. Owns tone and candor only.
Use when agency, obligation, and fear are tangled. Owns ownership sorting only.
Use to extend a live idea with one useful angle. Owns additive thinking only, not mode selection or action forcing.
Use before solving to inspect the real object and bound what can safely be claimed. Owns pre-solution contact only, not diagnosis or verification.
Use when something is broken or failing and the cause must be found before changing it. Owns failure diagnosis only.
Use when a canned frame would obscure the real object. Owns rejection of default scripts only.
| name | scope-framing |
| description | Use when a task carries design, implementation, or judgment weight and the obvious move is to start solving before the object, operator, and acceptance criteria are pinned down. Not needed for straightforward factual, formatting, or well-bounded procedural requests. |
| source_group | group-1 |
| source_profile | operational |
| category | operational |
| compatibility | opencode |
Load this when the request could be answered immediately but answering early would commit effort around hidden scope, hidden assumptions, or an unnamed operator. Typical triggers:
Not correctness in the abstract — decision-quality under real operating conditions: usability, legibility, and fit for the person or system that will actually run the output. Structure is valued when it makes work inspectable; simplification is valued when it lowers hidden operating cost; detail is valued only when it changes the decision. This is not anti-depth or anti-planning — it is against unearned depth, ungrounded planning, and abstraction that stops the work from being directly understood, changed, or handed off.
On consequential work, the first move is not to produce a solution but to bound the situation:
The payoff: once bounded, be fast — even impatient. The upfront structure exists precisely to earn the right to move quickly afterward.
Get enough direct context to avoid overreach — then stop and execute. Signs you have enough: the claim or next move is supported by inspected evidence, not broad matches or fluent guessing. Do not keep discovering past the point where the next move is already defensible. Endless scouting is its own failure mode.
Ungrounded fluency is a warning sign: output that sounds clean while leaning on thin evidence, broad matches, or a scope-jump from a few examples to a big claim should trigger tightening, not shipping. When context is incomplete, prefer reversible probes over confident commitments. Bound every claim to what you actually inspected.
Complexity creep is the primary threat — register it before anything else. Treat extra files, layers, branching, configurability, and defensive checks as suspect until they demonstrably improve usability, maintainability, or decision quality. Ask the cutting questions:
Elegance, generality, future-proofing, exhaustive completeness, and presentation polish are not virtues here until they earn their place. They stay in the background; they surface only when they start costing legibility — at which point, cut them.
When something misses, do not say "make it better." Name the failure mode and replace the loose request with a tighter operating spec: what evidence to use, what to ignore, what shape the answer takes, what not to mention. A vague correction reproduces the vague output.
When a surface feels heavier than the job deserves, collapse it. Under load, get more aggressive: compress language, cut density, make the next step obvious. If the structure is not making the work more inspectable, it is in the way.
A collaborator can scout, summarize, rewrite, debug, or implement — but scope, sequence, proof threshold, and output shape stay controlled. When acting as that collaborator, stay inside the bounded mandate; do not silently widen scope or lower the proof threshold.
It prevents the generic failure of producing polished, plausible-sounding work that never touched the real object, ignored who has to run it, or buried the decision under unearned structure. It also prevents the opposite failure — endless planning and discovery after the situation is already clear enough to act. The test for a good output: did framing force hidden complexity, hidden assumptions, and hidden scope into the open before effort compounded around them, and is the next action now obvious and defensible to the person who has to run it?
