菜单
Use when a live result contradicts the hoped-for story or a metric could be gamed — state what really works and never fake a green.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | honest-reframing-over-overclaiming |
| description | Use when a live result contradicts the hoped-for story or a metric could be gamed — state what really works and never fake a green. |
When results contradict the claim you wanted to make, rewrite the claim to match the measurement — carrying the exact numbers — instead of bending tests, fixtures, or ground truth until the metric turns green.
Red-flag thoughts — if you catch yourself thinking any of these, STOP and apply this skill:
An overclaim that survives into the next phase becomes the foundation someone else builds on; the cost compounds. A faked green hides exactly the failure the test existed to catch, so the bug ships anyway — now with a passing suite vouching for it. Tuning fixtures to the current model destroys the corpus's ability to detect the next regression. The honest number, stated once with its caveats, is cheaper than the silent debt of a story that was never true. Reframing also redirects energy productively: a precise "it ranks #3" points straight at the retrieval phase to strengthen, where "it works" pointed nowhere.
On the project this was distilled from — a human-in-the-loop AI agent — the design assumed an in-process embedding step would surface the correct reference article as the top hit. A single live run showed it did not rank the intended article #1. The honest move was taken twice: the result was written up as measured reality ("these motivate a stronger retrieval phase rather than being rescued by the current [approach]" — the bracket marks a substitution; the source string says "the current RAG"), and the correction was pushed into BOTH the user-facing evaluation doc and the original design spec, cross-linked. Separately, when an eval produced a flattering focused-slice score, the write-up reported the broader whole-corpus figure as the headline (0.90 across 20 cases) and named the specific under-escalating cases as concrete tuning targets — rather than leading with the better-looking slice. And when someone reached for the fixtures to get a metric green, the standing rule held: "Don't change fixtures, let's talk about it first." You can apply all three without knowing anything else about that project: correct the claim, correct it everywhere, and freeze ground truth.
What a machine can check: the temptation paths. Ground-truth fixtures behind required review (a CODEOWNERS rule or protected path), so no fix can silently edit the exam; a corpus-balance check that fails when the good or bad case count drops to zero; numbers in shipped claims traced to generated artifacts rather than hand-typed prose (docs-as-deliverable). The reframing itself is judgment — the machine's job is making the dishonest path loud, not choosing the honest words.
Related skills:
Use when wiring a project's dev workflow (local stack, test tiers, gates, docs), or when naming make targets in a repo that has siblings — build a thin self-documenting Makefile facade over real scripts, name targets from the shared cross-repo vocabulary, and split env files by owner so targets consume them but never write them.
Use when you need to prove a feature actually delivers its intended outcome to a user or caller, not just that its code paths run — write executable acceptance tests against real, observable outcomes, derived from the spec before or independent of the implementation.
Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior.
Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm it.
Use when building automation that edits, tests, or deploys itself — an agent that regenerates its own code, a self-updating pipeline, any loop that modifies the thing running it.
Use when about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence.
