Adversarially review the last 24h of multi-agent work by combining git history, GitHub issue state, generated analysis artifacts, governance tests, and duplicate-checked follow-up issue creation.
Adversarially review the last 24h of multi-agent work by combining git history, GitHub issue state, generated analysis artifacts, governance tests, and duplicate-checked follow-up issue creation.
Use when asked to review recent work done by multiple agents across the ecosystem, especially the last 24h. This is not a normal progress summary — the goal is to find regressions, contradictions, stale claims, enforcement gaps, and missing follow-through.
What this skill is for
Produce an evidence-backed review of recent agent work and create high-value follow-up GitHub issues without spamming duplicates.
gh issue list --state all --limit 30 --json number,title,state,createdAt,updatedAt,labels,author,url
3. Audit generated analysis artifacts directly
Treat generated result docs as first-class review targets.
Check recent files under patterns like:
docs/plans/*/results/*.md
docs/handoffs/*.md
Look for:
"directly executable" claims that are no longer true
blocked-status artifacts whose blockers were later cleared
false negatives about file/module existence
recommended next actions already completed elsewhere
4. Reproduce at least one concrete check
Do not stop at document review. Re-run focused tests or scripts for the changed area.
When reviewing Deckhand/customer-channel behavior, include an interaction inconsistency pass using references/deckhand-interaction-inconsistency-audit.md. This pass must compare channel logs, scope/routing config, audit rows, and Claude/session claims across five axes: channel fit, domain scope, result-delivery state, engineering credibility, and live-readiness/canary evidence.
Good pattern for governance/runtime work:
uv run pytest <focused test subset> -q
Also exercise both human-facing and machine-facing entrypoints when a tool claims automation support:
run the normal CLI mode
run --json / structured-output mode separately
verify exit codes as well as stdout shape
Adversarial check for governance/checker work:
compare the checker's enforced contract against the canonical schema/constants used by the main implementation
do not trust comments or issue summaries alone
if docs and implementation require fields A/B/C/D but the new checker only validates A/B/C, classify that as a real enforcement gap and fix it
Adversarial check for scheduled governance/cron wrappers:
inspect the exact JSON/status values emitted by the underlying tool and verify wrapper scripts compare against the real casing/spelling (fail vs FAIL, etc.)
verify any labels used for auto-created GitHub issues actually exist in the repo; do not assume descriptive labels like conformance or registry-health are defined
when labels do not exist, prefer existing repo taxonomy plus dedupe by issue-title search rather than by nonexistent labels
add a small regression test that reads the shell script text and asserts the expected status token and label strings are present
If one file fails in a combined run but passes alone, record it as a possible invocation-context/import-path problem rather than claiming a stable failure.
5. Use adversarial subreviews when scope is broad
Delegate independent subreviews for parallel adversarial pressure, for example:
governance/runtime enforcement changes
generated artifacts and issue-follow-up quality
Ask subreviewers for:
exact repro steps
concrete files/commits reviewed
suggested issue titles
whether the finding is already covered by an open GitHub issue
6. Check for duplicate issues before creating anything
Always search GitHub before opening follow-up items.
Use targeted searches such as:
gh issue list --state open --search '<keywords>' --limit 20
Important: distinguish exact duplicates from umbrella issues. If an umbrella exists, reference it in the new issue instead of skipping automatically.
6.5 Reopen incorrectly closed issues when live validation contradicts prior completion claims
If a previously closed issue is directly contradicted by a reproduced live failure, prefer reopening the original issue instead of creating a duplicate regression ticket.
Use this when:
the closed issue claimed a fix landed
your focused repro shows the same path still fails now
the reopened issue is a hard blocker for a downstream approval gate