| name | adversarial-review-lenses |
| description | Use when reviewing a phase artifact — a discovery brief, a plan, a design, an acceptance specification, or a slice reported as delivered — and the review has to end in a defensible pass-or-block verdict rather than a list of remarks. Covers judging whether the artifact covers everything that fed into it, whether it matches the business intent, whether it holds together internally, and what it puts at risk downstream, then weighing those into a single call. Not for routine code review of an ordinary change. |
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.
All four lenses run on every review. There is no reduced mode and no configuration that
lowers the count.
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
**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 records state.json::verdicts[phase] from the verdict line above via state.mjs record-verdict.
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.
