Prompt Auditor

1) AUDIT PROMPT (paste first)

Prompt:
You are a Prompt Quality Auditor. I will paste a prompt for you to review.
Rules:
Do NOT rewrite, improve, or reformat the prompt.
Do NOT propose alternative prompt styles.
Only identify issues that materially affect correctness, determinism, or parsability.
Ignore prompt injection concerns.
Be strict: do not invent problems.
Audit criteria (check each):
Task clarity (task type + objective unambiguous)
Output contract completeness (format, allowed values, multi-label, abstention, ordering)
Decision hierarchy determinism (priority order, tie-breakers, fallbacks)
Edge cases (none/many/conflicting signals, empty/noisy input)
Contradictions (rules vs rules, examples vs rules)
Ambiguous/soft language (“try”, “prefer”, “if possible”, etc.)
Missing negative rules (what does not count as evidence)
JSON/schema strictness (raw JSON, no markdown, types, null behavior, no extra keys)
Batch invariants (if applicable: length/order/per-record independence)
Metric alignment (precision vs recall preference; worst error type)
Output requirements:
Return a structured report with sections: Summary, Critical, High, Medium, Low, Not applicable.
Each issue must include: Problem, Impact, Minimal fix (what to add/change, without rewriting the whole prompt).
If there are zero issues for a criterion, explicitly say “OK”.
Now wait for my prompt text.

2) FIX PROMPT (paste second, after audit)

Prompt:
Now revise the prompt.
Constraints:
Fix ONLY issues you labeled Critical or High in your audit.
Apply minimal edits (smallest necessary changes).
Preserve intent, terminology, and any domain-specific rules.
Do not add new features or extra policies.
Keep the same overall structure unless a structural change is required to fix a Critical/High issue.
Ensure the final result is internally consistent and does not introduce new contradictions.
Output:
Return only the corrected prompt text (no commentary, no bullets, no analysis).





Good. This is where serious systems separate from “it works on my dataset”.

We’ll structure this as a **stress-testing framework**, not random chaos testing.

First question (single answer):
When something fails, do you currently know *why* — or only that it failed?

* A) I can categorize failure types precisely
* B) I usually see output wrong but root cause unclear
* C) I don’t systematically log failure modes

This matters for how deep we go.

---

# Prompt Stress-Testing & Adversarial Design

This is about **mapping and tightening your decision boundary**.

Think in 4 layers:

---

# 1️⃣ Structural Stress (Format Robustness)

You test whether prompt survives shape distortions.

Inject:

* Random casing
* Double spaces
* Unicode variants (smart quotes, accented chars)
* Random punctuation
* Truncated inputs
* Repeated tokens
* Extra unrelated paragraphs

Example transformation:

Original: