Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/pa-pvp-mini/llms.txt

Use this file to discover all available pages before exploring further.

pa_pvp mini does not require a prior pa_pvp round as its starting point. Any structured critique of your artifact can be used as PREVIOUS_ROUND_OUTPUT. The reviewer will audit it the same way it audits native pa_pvp output — challenging invalid findings, confirming valid ones, and surfacing important problems the prior review missed. The source of the critique does not change the protocol’s behavior. What matters is that the material is structured enough to audit.

​
What counts as prior material

These sources are all valid inputs for PREVIOUS_ROUND_OUTPUT:
  • A prior pa_pvp mini round output from an earlier session
  • Code review comments from a colleague or a tool such as a GitHub Copilot review
  • Linter or static analysis output with structured findings (specific locations, specific problems)
  • Team feedback on a proposal or spec, provided it is written as discrete observations rather than freeform discussion
  • An AI-generated critique from another session or tool that is not pa_pvp
  • Your own structured notes or concerns about the artifact — even a bullet list of things you are unsure about
The key property is structure. The reviewer needs discrete items to audit: a problem statement, a reference to the artifact, and some kind of position. A wall of unstructured text is harder for the reviewer to audit systematically. If your prior material is unstructured, consider organizing it into a short list before submitting it as PREVIOUS_ROUND_OUTPUT.

​
How to submit existing reviews

1

Activate pa_pvp mini in the AI chat

Paste the full protocol text into the chat or upload pa_pvp mini v2.3.txt if the chat supports file uploads. The protocol must be active before you submit your material or the reviewer will not apply the adversarial review rules.
2

Label your artifact with ORIGINAL_ARTIFACT:

Wrap your artifact in the label block. This identifies the primary source of truth for the session. The reviewer will anchor all findings to this content and ignore anything outside the labeled blocks.
3

Label your prior review with PREVIOUS_ROUND_OUTPUT:

Paste your existing critique — code review comments, tool output, team notes, or any structured prior review — inside this block. The reviewer will treat this as audit material: something to check against the artifact, not something to accept as authoritative.
4

Optionally set CURRENT_ROUND: 2 to avoid round inference errors

When prior material is present, the protocol infers Round 2+ behavior automatically. Setting CURRENT_ROUND: 2 explicitly removes any ambiguity and ensures the reviewer does not attempt Round 1 behavior. If you want Round 3 behavior — for example, because your prior material already contains two rounds of output — set CURRENT_ROUND: 3.
5

Send the full submission

Submit all three blocks together in a single message. The reviewer reads the full submission before producing output.
A complete submission using an existing review looks like this: 
CURRENT_ROUND: 2

ORIGINAL_ARTIFACT:
[your full artifact here]

PREVIOUS_ROUND_OUTPUT:
[your existing critique, code review, tool output, or structured notes here]
All three blocks should appear in a single message. The order of blocks does not affect behavior, but keeping ORIGINAL_ARTIFACT before PREVIOUS_ROUND_OUTPUT makes the submission easier to read and verify.

​
How pa_pvp mini treats existing reviews

PREVIOUS_ROUND_OUTPUT is audit material, not source authority. The reviewer is allowed — and expected — to challenge it. An existing review from a teammate, a tool, or another AI session is treated with the same scrutiny as a prior pa_pvp round. The reviewer will:
  • Confirm valid findings — problems that are well-anchored to the artifact, observable, and structurally relevant will carry forward with a CONFIRMED label
  • Challenge invalid or overstated findings — findings that are not anchored to the artifact, rely on misreadings, are duplicated, or make claims the artifact does not support will be challenged with a reason
  • Identify important misses — problems present in the artifact that the existing review did not surface will appear as new findings
This is the core value of using pa_pvp mini to audit an existing review: it does not simply accept the prior critique. It independently reviews the artifact first, then checks the prior material against that independent review. A finding your team agreed on may be challenged. A problem nobody noticed may surface as a new HIGH finding. The protocol is not deferential to the source of prior material — only to the artifact.

​
Setting CURRENT_ROUND explicitly

The CURRENT_ROUND override is most useful when there is a mismatch between how many rounds of output you have and what round behavior you want. Specific cases where explicit setting helps:
  • You have one round of prior material but want Round 3 behavior — set CURRENT_ROUND: 3. The reviewer will apply Round 2+ rules regardless of how many prior rounds are visible in the material.
  • Your prior material does not contain explicit round numbers — without round numbers in the prior output, the protocol defaults to Round 2. If that is correct, you do not need to set anything. If you want a different round number, set it explicitly.
  • You are submitting prior material from a non-pa_pvp source — external critiques never contain pa_pvp round numbers. Setting CURRENT_ROUND: 2 explicitly is cleaner than relying on inference.
The override is a precision tool. When you are unsure, setting it explicitly is always safer than relying on inference.
Prior material from a non-pa_pvp source — code review comments, tool output, team notes, or AI critiques from other tools — will not contain pa_pvp finding IDs. The protocol requires a finding_id for every finding in the output, so the reviewer will assign new IDs when producing its Round 2+ output. These new IDs follow the standard pa_pvp format: a single keyword from the problem, no numbers, no category prefixes. If the reviewer confirms a finding from your external review, it will assign a new ID to that confirmed finding and carry it forward in subsequent rounds under that ID.

Build docs developers (and LLMs) love

Get started for freeTalk to us