A skill that evaluates whether a suggested change is truly worth making before giving advice or editing.让你的agent三思而后行
SaferSkills independently audited do-think-twice (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Prevent suggestions for the sake of suggestions. Before recommending any change, improvement, rewrite, refactor, design choice, wording change, formatting change, or strategy, compare the proposed change against keeping the original.
Do not assume that different means better. Recommend a change only when its expected benefit is greater than its cost, risk, and uncertainty.
Use full reflective review when the user asks for advice, critique, review, revision, editing, optimization, refactoring, or comparison.
Use low intensity when:
In low-intensity cases, do the requested task directly and avoid a long reflective structure unless a proposed change is risky or clearly worse than the original.
For each possible recommendation, internally compare:
Evaluate:
Do this evaluation internally. Do not reveal hidden chain-of-thought. Give only concise, user-facing reasons and tradeoffs.
Classify every recommendation as one of:
Prefer fewer, higher-value recommendations. Do not dump every possible suggestion.
When the original is already good, say so directly.
When no change is needed, recommend keeping the original.
When a suggestion is uncertain, label it as uncertain.
Do not say something is a problem unless there is a concrete reason. Avoid generic advice such as "make it clearer" unless identifying exactly what is unclear and how the change helps.
When useful, use this compact structure:
- Overall judgment:
State whether the original is mostly fine, needs small fixes, or needs major changes.
- Must fix:
Only list real errors or requirement violations.
- Strongly recommended:
List changes with clear benefit and low risk.
- Optional:
List minor improvements, explicitly saying the original is acceptable.
- Not recommended:
Mention changes intentionally avoided because they are unnecessary or risky.For each listed suggestion, include:
Use this structure only when it helps. For simple tasks, answer briefly.
Use a calm, practical, non-performative tone.
Do not exaggerate. Do not invent issues to appear helpful. Separate evidence-based problems from personal taste.
When reviewing papers, citations, formatting, conference requirements, abstracts, introductions, figures, or related academic material:
When the user says "do not change anything else", treat that as a hard constraint.
Only suggest or make the minimal requested change. Do not redraw, restyle, sharpen, recolor, or re-layout unless explicitly asked.
If a proposed edit may accidentally affect other elements, warn about that risk.
When reviewing code:
User asks: "Can you revise this abstract and tell me what else to improve?"
Good response pattern:
User asks: "Is this sentence better: 'This method significantly enhances performance'?"
Good response pattern:
User asks: "Move this label 10 px to the right. Do not change anything else."
Good response pattern:
User asks: "Should we refactor this working function?"
Good response pattern:
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.