better-prompt — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited better-prompt (Agent Skill) and scored it 79/100 (yellow). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 5 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 5 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
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.
Vague prompts → generic answers. Users say "optimize my X" without specifying the environment, the success criterion, or the boundary. Default behavior jumps to generic best practices that don't fit their situation. The result is shallow, sometimes wrong, hard to verify.
This skill imposes a methodology that works:
Triage → Context → Research → Plan + self-review → Implement → Verify
The cost is a few minutes of upfront discipline. The benefit is solving the user's actual problem instead of producing a plausible-looking answer. The methodology is grounded in three pieces of well-known agent research — Plan-and-Solve (plan before acting beats raw chain-of-thought), Self-Refine (an LLM critiquing its own output and revising consistently improves quality), and Chain-of-Verification (drafting explicit verification questions catches errors that ad-hoc checking misses).
Before anything else, decide which branch fits the request. Wrong branch is the most common failure mode: heavy methodology on a one-line fix wastes time; light methodology on an open-ended task produces bad answers.
Skip the skill entirely (just answer directly) when:
foo to bar in file.ts")Light branch (mini version — read state + brief plan + simple verify, minimal asking) when:
Full branch (the whole methodology, with markdown artifacts) when:
When uncertain, go one level lighter than your instinct — but if the result feels wrong, escalate. Under-processing produces bad answers; over-processing wastes time.
Respecting "don't ask" directives. When the user signals they want speed, that's a directive about interaction style, not a license to skip the methodology. Apply Light: read state silently, infer the goal, do the work, verify. Surface assumptions in the result ("I assumed X — let me know if wrong"), so the user can correct cheaply after the fact instead of being interrupted before.
Follow-up turns within an ongoing Full task. Once you've established the Full context for a task, individual follow-up questions can use a lighter touch. "How do I revert change 3?" inside an ongoing Full task is a Skip — just answer. Don't drag every follow-up turn through the full methodology; that's the methodology becoming a ritual. Re-engage the heavier process only when the follow-up itself reopens a Phase 1 or Phase 3 decision.
Three things to nail down before doing anything else:
Map out what's relevant to this task:
Where to get it, in order of preference:
For a substantial task, delegate the context-gathering scan to a read-only search subagent — it keeps the main context lean and runs in parallel with your own work. In Claude Code, use the built-in Explore agent type if available; otherwise spawn a general-purpose agent constrained to read-only tools. Spawn it before reading files yourself if the search surface is large.
State explicitly:
Naming the scope prevents misalignment. Users often assume you can do more or less than you actually can.
"Optimize" is too vague. Pin down:
If the answer is material to design AND not inferable: ask (see Interaction Model). If inferable: state the inference explicitly so the user can cheaply correct ("I'm interpreting 'faster' as LCP under 2 seconds — say so if a different metric matters more").
Before proposing anything, inspect what's there:
current-state.md in the working directory — gives you and the user a durable recordDo not skip this. "I'll just fix it" without reading first is the single biggest cause of broken changes.
Generic best practices often don't apply. Use the right tool, in this order of preference:
context7 MCP if installed) for library / framework / SDK / CLI documentation — more current and accurate than the model's recallWatch for:
For full-branch tasks, the research output goes into current-state.md (or a separate research.md).
Write the proposed changes. For each change, answer:
| Field | What it says |
|---|---|
| What | The concrete change (file, line, value, command) |
| Why | The reason this change matters for this user's situation, not generically |
| Expected effect | What you expect to be different after |
| Risk | What could go wrong, and how likely |
| Rollback | How to undo it if it goes wrong |
If any field is hard to fill in, the change isn't well thought through.
Scale the depth per change. A high-risk irreversible change deserves a paragraph per field. A trivial low-risk change (e.g., rename a scheduled task time) can use one-line Risk and Rollback ("極低 / 改回原时间"). The point is to think through each field, not pad the document.
Rank by ROI. When a plan has multiple changes, sort or annotate them by expected impact × effort. Users often want "if I only do one thing, which one?" — answer that in the plan. Put zero-risk high-value items first; expensive or risky items later.
Non-expert user — add a plain-language summary. If the user has indicated limited technical background (or the description triggered partly because of that), prepend the plan with a 1-2 paragraph plain-language summary: "Here's what I want to do, in 3 buckets: things I can do for free that should help right away, things that need you to spend money or time, and things to keep an eye on." The detailed change list still follows for accountability.
plan.md in the working directoryGeneric "review the plan" rarely catches issues. Walk through the plan applying each of these lenses explicitly:
If any lens surfaces an issue → fix the plan → re-walk the lenses. Loop until clean.
Skip lenses that are obviously N/A. For a plan with 8 changes, walking 5 lenses × 8 changes = 40 judgments. Many are obvious (Lens 4 on a config-tweak change: "trivially reversible, done"). State the obvious cases briefly, focus the work on the non-obvious ones. The point of the lenses is to catch issues, not to perform a ritual.
Partial vs. full re-lens after a fix. If a lens reveals a problem in one change, fix that change and re-lens that change plus its dependencies. If a lens reveals a problem in the root assumption (e.g., "the entire plan assumes the user has a Plex Pass and they don't"), re-lens the whole plan. Don't waste effort re-lensing unaffected changes, but don't be stingy when the root has shifted.
For high-stakes plans (production, irreversible, multi-system), spawn a fresh subagent reviewer — it has no commitment to your draft and catches issues you missed. Use whatever review-oriented subagent type is available in the host environment, or fall back to general-purpose with a review-focused prompt. Give it only the plan + the user's situation, not your own justifications — its value is independent skepticism.
Sign-off rule: show the plan to the user and get explicit go-ahead before executing when any of the following holds:
Otherwise, proceed.
Follow the validated plan. If you discover during execution that the plan was wrong, stop, update the plan, re-review — don't improvise.
Status updates: brief, factual, only when something notable happens. Silence and over-narration are both bad.
Don't just run the change and call it done. Draft the verification questions first, then answer each one with evidence:
Each question gets an answer with evidence. "Tests pass" is fine if you ran them; "Looks right to me" is not.
Verification ≠ tool call succeeded. A tool call can return 0 and the system can still be broken. Test behavior, not syntax.
For UI / frontend work specifically: structural + behavioral verification requires a real browser. Type-check passing is not "verified". If you can't drive a browser, say so explicitly rather than claiming success.
Async verification. Some verifications need wall-clock time — a scheduled task that runs once a week, a 24-hour stability check, a backup that runs tonight. Don't fake-claim success. Instead: mark those checks as PENDING (verifies on next run @ <time>) in the plan's status table, tell the user when to expect closure, and remind them in your final report. If the task is time-critical, offer a proxy check (e.g., manually trigger the scheduled task once to confirm it runs cleanly).
When verification surfaces problems → don't retry harder, loop back to Phase 3 with the new evidence.
Default to autonomous. This skill is about removing the user's burden, not adding it.
Proceed without asking when:
Ask the user only when:
How to ask — strict rules:
(Recommended). This lets the user one-click confirm your best guess. *The Recommended option should minimize the user's effort, not yours.* For a non-expert user, "paste this output here" usually beats "give me SSH access" even if SSH would be faster for you. Bias toward what the user can actually do in 10 seconds.Good ask pattern:
Two things to confirm before I tune the OpenClash setup: [AskUserQuestion with options: 1) Work tools only (Recommended), 2) Work + streaming, 3) Add gaming priority] [AskUserQuestion with options: 1) Stability over speed (Recommended), 2) Speed over stability]
>
If both defaults are fine, just say "go".
Bad asks to avoid:
If this skill triggers mid-conversation, do not restart. Extract from prior turns:
Then summarize in 2-3 sentences for the user so they can correct drift:
Based on the conversation so far: bypass-router + Mesh setup, we tuned OpenClash and verified Google/OpenAI access. You're now asking whether the whole stack is optimal. Sound right?
If the current request contradicts a prior decision, surface it explicitly rather than silently picking one. Silent drift is one of the most common ways agents produce subtly wrong results in long conversations.
If important prior context appears to have been compressed away (the user references something you don't remember), don't pretend — either ask for a quick recap, or re-read any artifacts you wrote earlier.
See references/context-extraction.md for more patterns.
Match the user's language for everything user-facing — summaries, questions, status updates, and the content of plan / current-state markdown files. File names, code identifiers, and shell commands stay in English regardless of the user's language.
Read these when the main file doesn't give enough guidance — they're not required for every invocation:
references/methodology-deep-dive.md — fuller treatment of each phase with edge cases and decision rulesreferences/examples.md — before/after transformations across domains (network, code, data, frontend)references/context-extraction.md — patterns for extracting from prior turns, handling drift and missing context~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.