Formalize Empirical Isolation Test After Review pattern

Context

During the review of PR #10242, an architectural pattern (subscribing inside neo.apply) was challenged as suspect. Rather than engaging in a lengthy theoretical debate, an empirical isolation test was conducted which proved the pattern to be dead weight.

The Problem

When a reviewer flags a pattern violation, the interaction often devolves into architectural arguments or defensive documentation. A faster, more productive resolution path is an empirical isolation test to prove or disprove the pattern's necessity. This pattern is currently undocumented in our review workflows.

The Architectural Reality

This touches the .agent/skills/pr-review/SKILL.md and .agent/skills/pull-request/SKILL.md workflows, defining how reviewer-author collaboration should handle architectural challenges.

The Fix

Update the relevant skill documentation to formally capture the "Empirical Isolation-Test-After-Review" pattern.

• State that when a reviewer flags a pattern violation, the author should either document its necessity or run an empirical isolation test.
• Recommend the isolation test as the preferred, faster path when feasible.

Acceptance Criteria

• Update pr-review or pull-request skill (or both) to document the empirical isolation test pattern.
• Provide a clear directive for reviewers to suggest this test and for authors to execute it.

Origin Session ID

Origin Session ID: 1c5933cc-a2d0-4296-ae3f-f4e815d385a2