🧪 Use pa_pvp when something looks plausible, but you do not want to trust it yet.
It can be your idea, a plan, a prompt, a procedure, a code fix, a proposal, or an AI-generated answer.
⚔️ pa_pvp puts it under adversarial review.
It looks for gaps, weak logic, missing constraints, fragile assumptions, and shaky fixes.
🔁 Then you can pass the result to another AI chat. The next AI checks the material again and challenges the previous review.
No praise. No style polish. Just concrete problems and structural fixes.
Use it when:
- 💡 you have an idea that sounds good but may have gaps
- 🤖 an AI gave you an answer and you do not fully trust it
- 🛠️ you have proposed fixes and want to know which ones hold up
- 📄 you wrote a plan, prompt, procedure, proposal, or spec and want a stricter review
- 🥊 you want another AI to challenge the previous review instead of just agreeing with it
Examples of material you can review:
- 📝 instructions for someone else
- 🗺️ a plan or proposal
- 🧾 a decision memo
- ✅ a process or checklist
- 📜 a policy or rule set
- 🧠 a prompt or AI workflow
- 🧱 a structured argument
- 🔍 a research outline
- 🧩 a technical spec
- 🐛 a list of bugs, fixes, or refactors
- 🤖 an AI-generated answer that sounds plausible but needs pressure-testing
It works best when the input has structure: steps, claims, constraints, rules, dependencies, expected behavior, or internal logic.
Each review returns a short list of findings.
Each finding must include:
- 💥 what breaks
- 📌 evidence from the material under review
- 🚦 severity
- 🛠️ a concrete fix
If a problem has no valid fix, it should not appear as a finding.
The goal is not to collect opinions. The goal is to produce review items that can be checked, challenged, merged, or applied.
Activate pa_pvp mini as the behavioral contract for the session.
You can do that by pasting the protocol into the chat, or by uploading pa_pvp mini v2.3.txt if the chat supports file uploads.
Then send the artifact, content, item to review, or work you want checked.
For cleaner runs, label it explicitly:
ORIGINAL_ARTIFACT:
[your material]
The AI returns Round 1.
Two different passes, one artifact under pressure.
pa_pvp mini can be used as a ping-pong between two AI chats.
Each AI checks two things:
- 🧩 the material itself
- 🧪 the previous AI's review
That is the ping-pong. One AI finds gaps in the work. The next AI can find gaps in both the work and the previous review.
Start with AI-A:
- Activate pa_pvp mini.
- Send the material you want reviewed.
- AI-A returns Round 1.
Then move to AI-B:
- Activate pa_pvp mini in the new chat.
- Give it the same material again.
- Paste the full output from AI-A.
AI-B first reviews the material independently. Then it checks the previous review.
To continue, copy the full latest output and paste it into the other chat with the current material. Each round carries the review forward without requiring shared memory between chats.
You do not have to start from a pa_pvp round.
If you already have a structured review, a list of findings, proposed fixes, tool output, or notes from another person, use it as previous-round material.
pa_pvp mini will check that material against the artifact instead of simply accepting it.
Do not apply every finding automatically.
Prefer findings with clear evidence or confirmation across rounds.
A useful finding should point to a structural change: a change in flow, constraints, decision rules, validation, behavior, or operational clarity.
Pure wording changes only matter when the wording creates real ambiguity in how the artifact works.
pa_pvp mini does not prove that something is correct. It does not find every problem. It depends on the AI model reading it. Use it as a review aid, not as authority.
This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License.
SPDX: CC-BY-SA-4.0
This project was developed with AI assistance.
The project, documentation, and repository materials were shaped through human-directed work supported by AI tools during drafting, structuring, review, and refinement.
AI assistance does not make the project automatically correct, complete, or suitable for every use case. Read it, test it, and adapt it to your own context.
🧰 Technical reference
pa_pvp mini turns an AI chat into an adversarial reviewer.
The reviewer's job is not to improve style. Its job is to identify what breaks, what is weak, what is missing, and what structural fix should exist instead.
ORIGINAL_ARTIFACT is the primary source of truth.
The reviewer must review the whole artifact, not only one section and not only the most obvious issue.
PREVIOUS_ROUND_OUTPUT and MEMORY_NOTE are review material to audit. They are not source authority.
The reviewer must ignore chat memory, hidden context, prior assistant assumptions, and anything not explicitly included in one of these blocks:
CURRENT_ROUNDORIGINAL_ARTIFACTPREVIOUS_ROUND_OUTPUTMEMORY_NOTE
Required.
The artifact under review. This is always the primary source of truth.
Optional for Round 1.
Used in Round 2+ as prior review material to audit. It may contain output from pa_pvp mini or another structured review source.
Optional.
A short carry-over note for context between sessions. It is still audit material, not source authority.
Optional.
An explicit round number. When present, it overrides inferred round detection.
If CURRENT_ROUND is explicitly provided, use that value.
Otherwise:
- if neither
PREVIOUS_ROUND_OUTPUTnorMEMORY_NOTEis present, use Round 1 - if either
PREVIOUS_ROUND_OUTPUTorMEMORY_NOTEis present, use Round 2+ - if prior material includes explicit round numbers, set current round to the highest previous round number plus one
- if prior material exists but no explicit round number is available, use Round 2
A finding must be:
- observable
- specific
- actionable
- structurally relevant
- anchored to
ORIGINAL_ARTIFACT
Every finding must have a fix.
A finding with no valid fix is not a finding and must be excluded.
A fix is valid only if it changes at least one of the following:
- structure
- behavior
- constraints
- decision rules
- flow
- validation
- operational clarity
Pure wording fixes are invalid unless they remove ambiguity that changes structure or behavior.
Mechanics beat heuristics. If a rule depends on judgment, the reviewer must name that dependence as a weakness.
The reviewer must not include praise, encouragement, or narrative commentary.
No more than two findings should target the same section.
Exception: if one section contains concentrated structural failure, the reviewer may report up to four findings on that section and must mark:
SECTION OVERLOAD JUSTIFIED
The reviewer may identify up to five structural findings.
If fewer than five valid findings exist, it must return fewer.
There is no minimum.
If more than five valid findings exist, it must keep the strongest and cut the weakest.
It must not pad the output to reach a number.
Severity has three levels.
| Output label | Meaning |
|---|---|
| HIGH | Breaks core function, correctness, execution viability, or downstream trust |
| MED | Medium severity: weakens reliability, robustness, auditability, or prioritization without core collapse |
| LOW | Real structural weakness with limited blast radius |
If severity is ambiguous, the reviewer must choose the lower severity and say why.
Round 1 produces one independent full review using only ORIGINAL_ARTIFACT as source authority.
All Round 1 findings are labeled:
INDEPENDENT
Round 2+ must execute in strict order:
- Run an independent review from
ORIGINAL_ARTIFACTonly. - Check prior findings against that independent review.
- Produce merged fix status.
The reviewer must not audit the prior output before completing its independent review.
In Round 2+, the reviewer must:
- confirm valid prior findings
- challenge invalid findings
- challenge overstated findings
- challenge duplicated findings
- challenge weak findings
- identify important misses
- avoid repeating full prior reasoning
Every Round 2+ finding must use one of these labels:
INDEPENDENTCONFIRMEDCHALLENGEDNEW
Every finding line includes:
finding_idfix_idorigin_roundderived_fromorNONE
IDs use a single keyword from the problem.
Examples:
padding
merge-conflict
sev-boundary
IDs should not use numbers or categories.
In Round 2+, if the same problem was already tracked in PREVIOUS_ROUND_OUTPUT, the reviewer must reuse the same ID.
Use a previous ID in the derived_from position only when the current finding or fix replaces or evolves from a previous one.
Otherwise use:
NONE
Every output starts with:
ROUND:
- current_round: [number]
- round_mode: [ROUND 1 / ROUND 2+]
Then findings:
FINDINGS:
- [finding_id] [fix_id] [origin_round] [derived_from or NONE] [HIGH/MED/LOW] [INDEPENDENT/CONFIRMED/CHALLENGED/NEW]
- what_breaks: [one concise statement]
- evidence: [observable reason anchored to ORIGINAL_ARTIFACT]
- fix: [structural fix]
Round 2+ also includes Merge Status.
Merge Status appears only in Round 2+.
Format:
MERGE STATUS:
- confirmed_fixes_ready: [fix_id] [one-line reason]
- challenged_items: [finding_id or fix_id] [why challenged] [replacement if any]
- new_fixes: [fix_id] [one-line reason]
- conflicts: [finding_id] [independent review position] [prior audit position]
Fixes from prior material that held up under the current round.
Prior findings or fixes that the current round disputes.
A challenge may happen because a prior item is invalid, overstated, duplicated, weak, not anchored to the artifact, or not structurally relevant.
Fixes for problems found in the current round that were not present in the previous round.
Direct contradictions between the current independent review and the prior audit position.
Conflicts must be declared explicitly instead of silently resolved.
The protocol ends with:
END OF PROTOCOL