adversarial-review-rerun-prompt-refresh
Prevent stale rerun reviews by regenerating provider prompt files from the latest plan or diff before every adversarial review rerun.
Best use case
adversarial-review-rerun-prompt-refresh is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Prevent stale rerun reviews by regenerating provider prompt files from the latest plan or diff before every adversarial review rerun.
Teams using adversarial-review-rerun-prompt-refresh should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/adversarial-review-rerun-prompt-refresh/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How adversarial-review-rerun-prompt-refresh Compares
| Feature / Agent | adversarial-review-rerun-prompt-refresh | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Prevent stale rerun reviews by regenerating provider prompt files from the latest plan or diff before every adversarial review rerun.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
SKILL.md Source
# Adversarial Review Rerun Prompt Refresh Use when a plan/code review is being rerun after edits. ## Problem A common failure mode in multi-provider review loops is rerunning Codex/Gemini against an old prompt file after the plan has already been edited. Reviewers then keep flagging defects that were already fixed, creating fake churn and misleading "still MAJOR" results. ## Rule After ANY material edit to the plan, diff, or acceptance criteria: 1. Regenerate the review prompt file from the latest artifact text. 2. Verify the prompt file contains the new artifact paths / deliverables / acceptance criteria. 3. Only then dispatch the rerun. Do not assume `.planning/quick/review-<issue>-prompt.md` is current just because the filename is the same. ## Minimal workflow 1. Read the latest plan/diff from disk. 2. Rewrite the prompt file from scratch. 3. Verify with a quick check: - `read_file` on the prompt file, or - `grep` for newly added artifact names / changed acceptance-criteria phrases. 4. Launch Codex/Gemini review. 5. Save new outputs to a new raw log filename (`-r2`, `-r3`, etc.) so stale logs are not confused with the latest wave. ## What to verify before rerun - New artifact paths are present in the prompt - Removed artifacts are no longer mentioned - Updated acceptance criteria are reflected - Updated deliverable wording is reflected - Reviewer is seeing the latest plan text, not a cached or older draft ## Additional stale-state checklist for plan reruns After each review wave, do not only refresh the provider prompt file. Also sync the plan document itself so the next reviewers are not reading contradictory metadata. Before rerunning, explicitly verify and update all of these when applicable: - frontmatter/header `Review artifacts:` paths point to the latest review wave you want considered canonical - `Artifact Map` review-artifact rows use the same timestamp/path set as the header - `Acceptance Criteria` references to review artifacts or verdict gates use the same latest timestamp/path set - `Adversarial Review Summary` reflects the latest actual wave verdicts rather than an older MAJOR wave - any `Wave N overall result` text matches the current state of the document after edits - stale future-tense text like `will reconcile in the next revision` is removed once that reconciliation is already present - summary tables like `Path Decision Summary` still match the body after revisions; these often drift and trigger repeated MAJOR findings - diagnostics vs verification are separated cleanly: preconditions/diagnostics stay in the pseudocode or prereq section, while green-state checks stay in the TDD/verification section ## Common multi-wave rerun failure pattern When a plan goes through 3+ adversarial waves, providers often keep returning MAJOR not because the technical fix is wrong, but because the plan's own metadata becomes internally inconsistent: - old review-artifact timestamps remain in one section but not another - acceptance criteria still reference old wave outputs - the review summary still says MAJOR after the body has already incorporated the fixes - decision-summary tables still describe pre-revision logic This creates fake churn. Fix the plan metadata and decision tables before assuming another technical redesign is needed. ## Signs you hit this bug - Reviewer repeats a MAJOR finding you already fixed - Review output mentions file paths no longer present in the plan - Raw prompt file still contains old artifact names after you edited the plan - Different reviewers seem to be critiquing different versions of the same draft ## Recommended naming - Prompt: `.planning/quick/review-<issue>-prompt.md` - Raw logs: `.planning/quick/review-<issue>-codex-rN.out`, `.planning/quick/review-<issue>-gemini-rN.out` - Canonical artifacts: `scripts/review/results/YYYY-MM-DD-plan-<issue>-<provider>.md` ## Why it matters Stale review prompts can make a plan look blocked when the latest draft may already have resolved the finding. Prompt freshness is part of review correctness.
Related Skills
plan-review-prompt-refresh-after-plan-edits
Refresh reviewer prompt files from the latest on-disk plan before every adversarial re-review. Prevents Codex/Gemini from critiquing stale plan text after local edits.
tdd-verification-and-adversarial-review
Verify pre-written TDD tests pass, conduct adversarial code review on committed diffs, and route findings to existing issues
multi-role-agent-contract-review-pipeline
Execute a 4-role agent team (Planner/Architect/Reviewer/Integrator) pipeline for self-reviewing knowledge artifacts before delivery
label-driven-prompt-generation-architecture
Pattern for building automation scripts that classify GitHub issues into prompt templates using label-based routing and extract contextual data for batch processing
gsd-adversarial-review-pattern
Catch hidden test failures by running adversarial review on sparse-data edge cases before final push
agent-team-prompt-generation
Create self-contained execution prompts that define multi-role workflows for Codex sessions without external dependencies
adversarial-code-review-tdd
Systematic adversarial review pattern to identify breaking assumptions in already-passing test suites
adversarial-code-review-for-committed-diffs
Systematic process for reviewing already-committed code changes to catch type inconsistencies, edge cases, and docstring gaps
adversarial-code-review-and-fix
Systematic pattern for catching design flaws in already-passing code through adversarial review, then fixing them with TDD confirmation.
learned-git-worktree-hook-path-and-real-hook-shape-review
Catch hook-installation and governance bugs that only appear in linked git worktrees or against the real generated hook shape, not simplified test fixtures.
ten-agent-pre-plan-review-wave
Launch and verify a 10-agent planning-only wave that moves open GitHub issues into status:plan-review using one isolated worktree per issue, wave-specific continuation cron, and post-run artifact-reconciliation checks.
static-site-build-artifact-plan-review
Plan-review pattern for static-site fixes where the deployed artifact is generated from source files (e.g. sitemap/robots/static assets). Prevents review churn by separating durable regression checks from one-time migration verification and by validating built output, not just source files.