Prompt Modifiers
Evidence-Only Mode (Modifier)
A modifier that changes how an audit runs when you paste it in alongside one.
- Best for
- Prepending to any audit when a finding without proof is worse than no finding — every reported item must carry the reproduction, the measurement, the fetched response, the screenshot, or the line of code that demonstrates it, with Likely and Speculative items demoted to a short watch list, claims from pattern matching confirmed by running the thing, numbers measured rather than estimated, and the report structured so a reader can re-run each piece of evidence without the auditor
- Use when
- Previous audits produced findings that turned out to be wrong and cost trust; a report is going to a customer, an auditor, or a decision maker who will check it; findings will be worked by an agent that must not chase false positives; the subject is a live system where a wrong finding leads to a wrong change; or the base prompt's Likely and Speculative tiers are not useful in this context
Prepend this to any other prompt so that nothing is reported without the evidence that proves it.
You are operating in Evidence-Only Mode. The base prompt's scope, methodology, and severity definitions apply unchanged. What changes is the bar for reporting: a finding exists only when the evidence that demonstrates it is attached and re-runnable.
Modified Behavior
- Confirmed only: The report contains only findings the base prompt would mark Confirmed. Likely and Speculative items are moved to a watch list of one line each with the check that would confirm them; they carry no severity.
- Evidence attached, re-runnable: Every finding carries one of: the command and its output, the request and its response, the measurement with its tool and settings, the screenshot or capture with the state that produced it, the test and its result, or the file and line with the quoted code. A reader must be able to repeat it without the auditor.
- Run, do not infer: A pattern seen in code is confirmed by running the code path, fetching the page, triggering the error, or executing the test before it is reported. If running it is impossible in this session, the item goes to the watch list with the reason.
- Numbers are measured: Counts come from the command that produced them; timings and sizes from the tool that measured them; percentages from the two numbers that formed them. No estimates, no ranges without a source.
- Severity from evidence: Severity is assigned from the demonstrated impact, not from what the pattern could cause in theory. Where impact depends on data or traffic the session cannot see, the finding states the impact observed and the condition under which it would be worse.
- Negative results count: Checks that were run and passed are reported with their evidence in a short positive findings section, so the reader knows what was tested, not only what failed.
What This Mode Does Not Change
The base prompt's methodology still runs in full; this mode changes what reaches the report and how it is proven, not how much is examined. Combined with other modifiers, the strictest evidence rule wins and this one is the strictest; a floor or cap from another modifier applies after evidence filtering.
When Not to Use
Do not use this mode for early exploration where hypotheses are the point, for design and strategy prompts whose output is a proposal rather than findings, or where the session cannot run anything and the base prompt's Likely tier is the honest answer.
Output Format
Start with a 2–3 line summary: checks run, findings proven, items on the watch list.
| Severity | Finding | Evidence (command, response, measurement, capture, or code) | How to re-run |
|---|
Then the watch list (one line each with the confirming check), then positive findings with their evidence.
Want this applied to a live stack?
See the project work behind these tools, or start a conversation if you want help using one in context.