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 read free-form submissions — it parses labeled blocks. Each block has a specific role in the review session, and only content inside a recognized block is considered by the reviewer. This structure exists to prevent the reviewer from drifting into chat history, ambient context, or prior assumptions. What you explicitly label is what gets reviewed. Nothing else is in scope.
Anything outside these labeled blocks is ignored by the reviewer. If your artifact or prior review output is not wrapped in the correct block label, the reviewer will not process it. Always use explicit block labels for every piece of content you intend to submit.

Input Blocks

ORIGINAL_ARTIFACT
required
The artifact under review. This is the primary source of truth for the entire session. Every finding must be anchored to content inside this block. The reviewer must review the whole artifact — not one section and not only the most obvious issue.This block is required for every round. Omitting it means the reviewer has no source material to anchor findings to, which makes any output invalid.
ORIGINAL_ARTIFACT:
[your material here — steps, rules, plan, prompt, spec, or any structured content]
PREVIOUS_ROUND_OUTPUT
optional — required for Round 2+
The full output from a prior review round, used as audit material in Round 2+. This block may contain output from a previous pa_pvp session or any other structured review — tool output, a colleague’s findings, or an external analysis.This block is not source authority. The reviewer must challenge it against ORIGINAL_ARTIFACT, not accept it. A prior finding that does not hold up under the current independent review will be challenged, not simply carried forward.When this block is present, the protocol automatically activates Round 2+ mode (unless CURRENT_ROUND overrides the inferred round number).
PREVIOUS_ROUND_OUTPUT:
[paste the full prior round output here, from ROUND: to END OF PROTOCOL]
MEMORY_NOTE
optional
A short carry-over note for context between sessions. Useful when you want to carry a brief explanation across session boundaries — for example, to note that a specific section was intentionally restructured before this round, or that a prior finding was manually resolved and should not be re-raised.Like PREVIOUS_ROUND_OUTPUT, this block is audit material, not source authority. It does not override ORIGINAL_ARTIFACT. Its presence triggers Round 2+ mode if PREVIOUS_ROUND_OUTPUT is absent and CURRENT_ROUND is not set.Keep this block short. It is not a second artifact — it is a context flag.
MEMORY_NOTE:
[brief carry-over note — one to a few sentences]
CURRENT_ROUND
optional
An explicit round number override. When present, this value is used directly and round detection logic is skipped entirely. Use this when you need to force a specific round number — for example, to rerun Round 1 in a chat that already has prior context, or to jump to Round 3 when assembling blocks manually.
CURRENT_ROUND: 3
When CURRENT_ROUND is absent, the round is inferred from context. See Round Detection for the full inference rules.

Source Authority

Only ORIGINAL_ARTIFACT is the source of truth. This rule is absolute and applies across all rounds. The reviewer must not use:
  • chat memory from prior sessions
  • hidden model context
  • prior assistant assumptions
  • anything not explicitly placed inside one of the four labeled blocks
PREVIOUS_ROUND_OUTPUT and MEMORY_NOTE are review material to audit, not facts to accept. A prior finding may be wrong. A memory note may be outdated. The reviewer’s job is to check both against ORIGINAL_ARTIFACT — not to treat them as additional source authority. This hierarchy exists because the artifact is the only thing that was explicitly put in front of the reviewer to evaluate. Everything else is one AI’s interpretation of that artifact, and interpretations must be challengeable.

Combining Blocks: A Full Round 2 Submission

The following example shows how all four blocks look together in a Round 2 submission:
CURRENT_ROUND: 2

ORIGINAL_ARTIFACT:
Step 1: Validate user input
Step 2: Save to database
Step 3: Send confirmation email
Step 4: Return success response

PREVIOUS_ROUND_OUTPUT:
ROUND:
- current_round: 1
- round_mode: ROUND 1

FINDINGS:
- validation fix-validation 1 NONE HIGH INDEPENDENT
- what_breaks: Input is passed to the database before validation can reject it
- evidence: Step 2 (Save to database) follows Step 1 (Validate input) with no conditional gate
- fix: Add a conditional branch after Step 1 that halts execution on validation failure before Step 2 runs

END OF PROTOCOL

MEMORY_NOTE:
The email step (Step 3) was flagged by a colleague as potentially triggering before the database write is confirmed. Keep this in view during review.
In this submission, CURRENT_ROUND explicitly sets Round 2, ORIGINAL_ARTIFACT provides the source material, PREVIOUS_ROUND_OUTPUT carries the prior review for auditing, and MEMORY_NOTE adds a brief contextual flag for the reviewer to consider — without granting it source authority.

Build docs developers (and LLMs) love