Power-User Feature Audit

Audit a large new-feature PR the way a demanding production user would encounter the feature: by first learning what the underlying APIs, protocols, and real-world integrators require, and only then checking whether the implementation lives up to that. The output is a set of review items for the PR author, each backed by evidence and precedent.

The core discipline is ordering. If you read the implementation first, it anchors your expectations and you end up reviewing the code against itself. So the knowledge base is built entirely from external sources, the ideal test suite is designed from that knowledge base, and only then is the PR opened and compared against it. Gaps between the ideal and the actual are the findings.

When To Use

• A big feature PR lands (realtime/voice APIs, image generation, a new provider protocol, a new subsystem) and you want an independent assessment, not a line-by-line review.
• The feature wraps an external API or protocol whose semantics, edge cases, and operational pitfalls are documented outside this repo.
• You want to know whether the implementation would satisfy a power user pushing it hard in production, and where technical users would need trade-off flexibility.

Not for general code review of a diff (use /review-branch if available), and not for completing a narrow fix (use complete-partial-pr). This skill deliberately ignores code style, naming, and diff mechanics — its lens is behavioral completeness and operational robustness.

Operating Principles