The five parts of a fix prompt that works
Five parts. The issue, named exactly: "SQL query built with an f-string, vulnerable to injection", not "security problem". The location, file and line, so the agent edits the right code instead of hunting for it. Why it matters, in one sentence of consequence, which anchors the agent on intent instead of pattern-matching the wrong fix. The exact change: "convert to a parameterised query using the driver's placeholder syntax, passing values separately". Then the constraints, which get their own section below.
All of it comes down to specificity. Hand an agent an exact location and an exact change and it's excellent at this kind of work. Hand it a goal and it improvises, and improvisation on a security fix is how you end up with a half-rewritten auth layer nobody asked for.
Why 'smallest diff' and 'check elsewhere' earn their place
"Smallest diff" caps the blast radius. Agents like to improve things they pass: renaming, restructuring, tidying. Every line in a diff that didn't have to change is review burden and regression risk. Hold the change to the minimum and the fix stays verifiable, because you can read the diff and confirm it does one thing.
"Check for the same pattern elsewhere" points the other way. The location names one instance, but codebases repeat their mistakes: string-built SQL turns up wherever queries got written, hardcoded keys wherever the AI needed credentials. That constraint turns one finding into a sweep. Smallest possible change, applied everywhere the problem exists, is the shape of a good security fix, and both constraints sit in every prompt quality·vibes writes. So do ordered next steps that put credential rotation first, because keys in git history stay compromised after deletion.
Review the diff, every time
Agent-applied fixes get reviewed before they get committed; that's the discipline that makes this workflow safe. Read the diff and check three things: the flagged issue is actually fixed (the interpolated value now goes through a placeholder, the key now comes from an environment variable), nothing unrelated changed, and behaviour is preserved, meaning the same queries and the same responses, only safe. Then run the app or its checks before you commit.
The loop closes with a re-scan. Paste the repo into quality·vibes again and watch the findings disappear and the score move. The free tier is two scans for that reason: one to find, one to verify. For a long findings list, the fix-everything mega-prompt covers every finding in severity order in one paste. Read that diff more slowly, since the change set is bigger.
how it works
- 01
Start from a concrete finding
Run a scan so each issue comes with a file, line, and severity. A quality·vibes finding already includes the full fix prompt. Writing one by hand, gather the same details first.
- 02
State issue, location, and why
Name the vulnerability precisely, point at the exact file and line, and include one sentence on the consequence so the agent fixes with intent.
- 03
Specify the exact change
Say what the code should become: parameterised query, env-var lookup, SafeLoader, verification re-enabled. Not just that it should be 'fixed'.
- 04
Add the two constraints
'Smallest diff' to stop drive-by refactoring, and 'check for the same pattern elsewhere' so every instance gets fixed, not just the one you found.
- 05
Paste into Claude Code and review the diff
Confirm the flagged issue is fixed, nothing unrelated moved, and behaviour is preserved. Run your checks before committing.
- 06
Handle secrets in the right order
For any committed credential, rotate it at the provider before code changes, because deletion doesn't remove it from git history. quality·vibes's next steps always lead with rotation.
- 07
Re-scan to verify
Run the scan again and confirm the findings are gone and the score moved. Your second free scan exists for this.
frequently asked
Why not just ask Claude to 'find and fix all security issues'?
Because discovery and fixing are different jobs. Ask freeform and you get patchy discovery plus a sprawling change set. A scan hands you a stable ranked list, and targeted prompts hand you small verifiable diffs. quality·vibes splits the work that way on purpose: it finds, your agent fixes.
What's in the prompts quality·vibes generates?
Each one states the issue, the file and line, why it matters, the exact fix, and the two constraints: smallest diff, check for the same pattern elsewhere. Every plan includes every prompt and the fix-everything mega-prompt, and Pro scans get their analysis from Claude Opus instead of Haiku.
What's the mega-prompt and when should I use it?
One prompt that covers every finding in severity order, so a single paste works the whole report. Use it for a dedicated fixing session on a repo with a long list, then give the resulting diff a slower read, because there's more of it.
Can the prompt fix a committed API key?
It can move the key to an environment variable and clean up the code. It can't un-leak it. Rotation at the provider comes first, because the key stays in git history and may already be harvested. That ordering is built into quality·vibes's next steps.
Last updated June 10, 2026