adversarial-review-lenses

Adversarial Review Lenses

Reviewer agents use this procedure to produce an independent, defensible verdict on a phase artifact. Pattern derived from Genesis Step 7 (Adversarial Review).

When to use

Every SKRAFT phase reviewer (backlog-discoverer-reviewer, backlog-planner-reviewer, solution-architect-reviewer, acceptance-designer-reviewer, software-engineer-reviewer) invokes this skill once per review pass, after reading the upstream phase artifact(s) and the relevant *-review-criteria skill.

The number of lenses actually executed is governed by the depth tier recorded in state.json::userPreferences.depthTier:

Depth tier	Lenses required
basic	1 (Completeness only)
standard	2 (Completeness + Business Fit)
comprehensive (default)	4 (all lenses)
custom	as configured in userPreferences.customDepth.reviewerLenses, minimum 1

The four lenses

Each lens is executed in isolation. The reviewer must not let observations from one lens influence another. Run them in this order, recording each lens's findings independently before computing the synthesis.

Lens 1 — Completeness

Does the artifact cover every input that fed into the phase?

• Are all referenced issues, requirements, or upstream artifacts addressed?
• Are there obvious gaps (missing scenarios, missing components, missing acceptance criteria)?
• Are the mandatory sections required by the phase's *-review-criteria skill all present and non-empty?

Output: a list of completeness findings, each tagged MISSING, THIN, or OK.

Lens 2 — Business Fit

Does the artifact correctly reflect the business intent?

• Vocabulary matches the domain lexicon (e.g. business-lexicon.instructions.md when present).
• Acceptance criteria express observable business behavior, not technical implementation.
• No invented requirements, no scope creep beyond the input.

Output: a list of business-fit findings, each tagged MISALIGNED, AMBIGUOUS, or OK.

Lens 3 — Quality

Is the artifact internally consistent and well-structured?

• Cross-references are valid (paths exist, IDs resolve).
• No contradictions between sections.
• Style follows the relevant authoring instructions (markdown, prompt-builder, story-quality, etc.).
• The artifact is self-contained enough that a downstream phase can consume it without additional context.

Output: a list of quality findings, each tagged BROKEN, INCONSISTENT, or OK.

Lens 4 — Risk

What could go wrong downstream because of this artifact?

• Are immutable invariants from skraft-difficulty-routing respected (TDD, Clean Architecture boundaries, test integrity, dated paths, reviewers read-only)?
• Are the assumptions explicit and bounded?
• Are there hidden coupling points to neighbor planners (Security, RAI, SSSC) that the artifact silently violates?
• Could a sub-agent dispatched on this artifact be misled into producing incorrect code or design?

Output: a list of risk findings, each tagged INVARIANT_VIOLATION, HIDDEN_COUPLING, AMBIGUOUS_ASSUMPTION, or OK.

No-contamination rule

While executing a lens, do not consult findings from another lens. Write the lens's findings to its own section in the review file before starting the next lens. If a finding seems to apply to multiple lenses, record it under each lens independently with the appropriate tag — do not merge.

Weighted synthesis

After all required lenses have run, compute the verdict using fixed lens weights:

Lens	Weight
Completeness	0.30
Business Fit	0.30
Quality	0.15
Risk	0.25

Per-lens score in {0, 0.5, 1}:

• 1.0 — all findings are OK.
• 0.5 — at least one finding is non-OK but none are INVARIANT_VIOLATION or BROKEN.
• 0.0 — at least one finding is INVARIANT_VIOLATION, BROKEN, or MISSING.

Weighted sum maps to the verdict:

Weighted sum	Verdict
>= 0.85 and no lens scored 0.0	APPROVED
>= 0.55	NEEDS_REWORK
< 0.55, or any lens scored 0.0 on an invariant	REJECTED

A single INVARIANT_VIOLATION finding in Lens 4 forces REJECTED regardless of the weighted sum.

Output format

Write the review under reviews/{YYYY-MM-DD}/{phase}-{slug}-review.md. Begin the file with <!-- markdownlint-disable-file -->, then the following structure:

<!-- markdownlint-disable-file -->

# {Phase} Review — {slug}

**Verdict:** APPROVED | NEEDS_REWORK | REJECTED
**Depth tier:** basic | standard | comprehensive | custom
**Lenses executed:** N
**Weighted score:** 0.XX
**Reviewed artifacts:** {relative paths}

## Lens 1 — Completeness
- finding 1 [TAG] — short description
- ...

## Lens 2 — Business Fit
- ...

## Lens 3 — Quality
- ...

## Lens 4 — Risk
- ...

## Synthesis
{2–4 sentences explaining the verdict, the dominant lens, and the required next actions if any}

## Required actions before next attempt
- {bulleted list — present only when verdict is NEEDS_REWORK or REJECTED}

The reviewer writes only this file. It never modifies upstream artifacts and never edits state.json — the orchestrator updates state.json::reviewerVerdicts[phase] from the verdict line above.

HVE alignment

Review artifact location and naming follow the HVE convention documented in .copilot-tracking/reviews/code-reviews/review-artifacts.instructions.md (resolved via the HVE-Core fallback path when the file is absent locally). SKRAFT places its reviews under .copilot-tracking/skraft-plans/{slug}/reviews/{YYYY-MM-DD}/ rather than reviews/code-reviews/, but the metadata schema and verdict normalization are identical.