running-adversarial-review-and-refinement

Attacks work products for failures, validates critiques, and regression-checks approved fixes.

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/alsdmlals4-eng/Base --skill running-adversarial-review-and-refinement-alsdmlals4-eng
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: running-adversarial-review-and-refinement
Source: https://github.com/alsdmlals4-eng/Base/tree/main/skills/running-adversarial-review-and-refinement
Command: npx skills add https://github.com/alsdmlals4-eng/Base --skill running-adversarial-review-and-refinement-alsdmlals4-eng

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Work products, PRs, and merged decisions often ship with hidden defects, contradictions, and omissions because self-review is biased toward confirmation. This Skill enforces a structured adversarial review loop that assumes failure, validates each critique before acting on it, and re-verifies the final state before completion is reported. ## Core Features & Use Cases - Attack and validate separation: Runs distinct modes (attack, validate-critique, refine-approved-findings, regression-recheck, decision-report) so criticisms are fact-checked for validity, scope, and cost before any change is made. - Bounded full-scope review loops: Executes exactly two complete full-scope review rounds per approved work lineage, then limits further work to targeted correction and regression verification, preventing endless audit churn. - Post-merge and repository-wide audits: Re-reads the new main HEAD, confirmed decisions, untouched consumers, and derivative drift after merges, and routes repository-wide findings to the correct owning Skill. - Use Case: After merging a PR that updates a canonical policy, run this Skill to verify no stale references, untouched consumer templates, or superseded decisions remain active, and to classify every finding as MUST_FIX, SHOULD_FIX, DEFER, or REJECTED_CRITIQUE before reporting completion. ## Quick Start Run an adversarial review of the latest merged PR against the current main HEAD and report validated findings with their severity decisions.

Frequently Asked Questions about running-adversarial-review-and-refinement

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run an adversarial review on a merged PR?

Use the post-merge-review mode to re-read the new main HEAD and actual diff, compare against confirmed decisions and canonical sources, check open and recent PRs for duplicate work, then classify findings as NO_CONFLICT, CONFLICT_FIXED, USER_DECISION_REQUIRED, or BLOCKED_UNVERIFIED.

How many review rounds does the adversarial review loop require?

The current contract requires exactly two complete full-scope review rounds per approved work lineage. After round two, only targeted correction, regression verification, and readback are performed; no automatic third full audit is allowed.

What is the difference between attack and validate-critique modes?

Attack mode assumes the work failed and hunts defects, contradictions, and edge cases without dilution. Validate-critique then re-judges each finding for factuality, probability, impact, scope, and cost, rejecting taste-based or out-of-scope criticisms before any fix is applied.

When should I use repository-wide-audit mode?

Use it only when auditing an entire repository for duplicate authorities, stale contracts, orphaned files, untouched consumers, and derivative drift. It reads the repository-wide-audit-protocol reference and routes findings to specialized owning Skills rather than fixing everything itself.

Can unverified checks be reported as passed?

No. CI runs, runtime tests, renders, and readbacks that were not actually executed must be marked NOT_RUN or BLOCKED_UNVERIFIED, never PASS. Completion is prohibited while verified blockers or unresolved regressions remain.

What are the limitations of this review approach?

It does not own static, runtime, accessibility, or performance validation evidence, which belongs to dedicated validation Skills. It also cannot create new broad Skills, perform background scheduling, or override user decision gates for direction-changing findings.