Recipe · Run an adversarial review

Goal: stress-test something — a PRD, an architecture spine, a story, a doc, or a diff — before declaring it done. Two ways in: run a single finder skill for one lens, or run e11-code-review for the full battery on code.

Time: 5–15 minutes per artifact · Phase: anytime · How: invoke the skills directly (they're on every install)

The four finder skills

Code	Skill	Method	What it finds
[AR]	e11-review-adversarial-general	Cynical, attitude-driven. Assumes problems exist and hunts hard for them.	What's missing or sloppy; weak arguments; implicit assumptions; vague language.
[ECH]	e11-review-edge-case-hunter	Mechanical, method-driven. Walks every branching path and boundary condition.	Unhandled paths only: missing else/default, unguarded inputs, off-by-one, implicit enum branches, races.
[VG]	e11-review-verification-gap	Evidence-driven. "If this behavior broke where it's used, would verification fail?"	Regressions no test would catch, places that should adopt the new behavior but don't, tests that lie.
[RC]	e11-review-reachability	Deployment-driven. "Deployed and used today, what would not work?"	Activation nobody performs, proof aimed at an artifact the runtime never reads, unregistered capabilities, environment skew — and gaps named without an owner.
[AA]	e11-review-alloy-auditor	Audit-driven. Checks each @engineering11/* import against its alloy doc.	Platform-convention violations, unresolvable alloy:// cites, dishonest claims about alloy consultation.

They're orthogonal — [AR] is about quality of thought, [ECH] about completeness of handling, [VG] about whether anything would notice a break, [RC] about whether the change is live or merely merged, [AA] about platform honesty. None of them assigns severity; you (or the code-review orchestrator) triage.

When to use what

• Before finalising a PRD or architecture doc → [AR] on the document (documents aren't code — the other three won't bite).
• Before merging code that handles user input or external state → [ECH] on the diff.
• After changing behavior in shared code → [VG] on the diff.
• On any platform-touching diff → [AA] standalone.
• On code you're actually shipping → don't hand-pick: e11-code-review runs all of them as layers.

Walkthrough — [AR] on a PRD

You: skill:e11-review-adversarial-general on planning-artifacts/prd.md

Skill: Loading prd.md. Cynical review begins. Looking for what's missing.

    Findings:
      1. "Smaller MRR loss" — quantify. What baseline? Acceptable variance?
      2. §2 acceptance criteria for "fast" are unspecified. Define a number.
      3. §3 assumes single-tenant. PRD never confirms multi-tenant is out of scope.
      4. No mention of degraded mode if reconciliation source is unavailable.
      5. "Audit trail" is mentioned twice without specifying retention or format.
      6. Out-of-scope list has 2 items; competitor analysis suggests at least 5.
      7. Personas don't cover the ops analyst who is also a tenant admin.
      8. Success metric §5.1 is a leading indicator; trailing indicator missing.
      9. No retirement path for reconciliation entries (manual override).
     10. Milestones omit data-migration; PRD elsewhere implies historical backfill.
     11. "We assume Firestore is fine" — unjustified by performance characteristics.
     12. Dashboard view spec doesn't address mobile.

The output is a flat findings list — descriptions only, no severity or ranking. Each finding is something to fix or explicitly decide not to fix.

Walkthrough — [ECH] on a diff

You: skill:e11-review-edge-case-hunter on the last commit

Skill: Content type: diff (one file, 47 added lines).
     Walking every branching path reachable from the changed lines.

     [
       {
         "location": "rest/handlers/tenants.ts:23",
         "trigger_condition": "tenantId is empty string",
         "guard_snippet": "if (!tenantId) return 400",
         "potential_consequence": "Datastore query runs with empty key; returns unrelated docs"
       },
       {
         "location": "rest/handlers/tenants.ts:31",
         "trigger_condition": "datastore.query throws on transient error",
         "guard_snippet": "wrap in try/catch with retry",
         "potential_consequence": "Unhandled rejection bubbles to 500 with stack trace"
       },
       {
         "location": "rest/handlers/tenants.ts:42",
         "trigger_condition": "user.role === undefined (legacy user records)",
         "guard_snippet": "default to 'viewer' or 403",
         "potential_consequence": "undefined === 'admin' is false; legacy users locked out silently"
       }
     ]

Output is a JSON array of unhandled paths — handled paths are discarded silently, and an empty array is a valid (good) result. When the diff deletes meaningful code, a secondary deletion check looks for callers left behind.

The full battery — e11-code-review on a bare diff

You don't need a story or spec. e11-code-review finds its target through a cascade (explicit ref → recent conversation → sprint board → current git state → ask), so all of these work:

skill:e11-code-review staged changes
skill:e11-code-review vs main
skill:e11-code-review PR 41
skill:e11-code-review          # on a feature branch: offers the branch diff

It constructs the diff, asks once whether a spec/story provides context (no is fine — that's no-spec mode), then runs its six layers as parallel subagents: blind-hunter ([AR] with zero context), edge-case-hunter, verification-gap, reachability, acceptance-auditor (spec mode only), and alloy-auditor. The orchestrator — not the finders — then rates severity after reading the surrounding code, dedups, and routes every finding into decision-needed / patch / defer / dismiss, applying patches and re-verifying, and recording defers in deferred-work.md.

The layers are data ([[workflow.review_layers]] in its customize.toml) — add a compliance layer or disable the alloy layer for a non-platform repo via .foundry/custom/e11-code-review.toml. See Customization.

Combining finders manually

For a high-stakes artifact that isn't a diff, run two lenses back-to-back:

You: skill:e11-review-adversarial-general on story 2-3-tenant-switch.md

Skill: [12 cynical findings]

You: skill:e11-review-edge-case-hunter on the same story's task descriptions

Skill: [3 edge cases: tenants-list pagination boundary, undefined active
     tenant on first load, double-click rate limiting]

You: Now I'll fix or explicitly defer each finding before running [DS].

Gotchas

• [ECH] and [VG] report problems only. They deliberately don't praise what's handled or verified. Short output is good news, not a bug.
• [AR] hunts, but does not invent. It assumes problems exist and digs for them — expect some minor findings; that's the price of the attitude — but a clean verdict backed by evidence of what was checked is a valid outcome, not a failed review. No finding quota means no manufactured findings.
• No finder assigns severity. Triage is the invoker's job — yours when running a finder standalone, the orchestrator's inside e11-code-review.
• Don't duplicate [CR]. e11-code-review already runs the finders as layers. If you've run it on a diff, re-running [AR]/[ECH] on the same diff adds noise, not coverage.
• Fresh context beats same-session review. The layers launch context-free subagents by design; when running finders manually on your own work, start a new session.

Source

Finder skills: e11-review-adversarial-general/SKILL.md · e11-review-edge-case-hunter/SKILL.md · e11-review-verification-gap/SKILL.md · e11-review-reachability/SKILL.md · e11-review-alloy-auditor/SKILL.md · orchestrator: e11-code-review/SKILL.md

See also: Ship a story end-to-end (where [CR] runs the battery) · Phase 4 — code review.