Challenges a recommendation, design, large change, or any artifact submitted for hard review (spec, proposal, policy, plan) across 5 dimensions (consistency, completeness, actionability, alignment, risk), from the standards of a named senior expert in the artifact's domain and ideally from a fresh context or a different model. Searches assuming defects exist and reports only those that survive evidence. Panel mode runs several independent lenses in parallel on a release candidate, verifies every finding against the current head, and routes confirmed ones to file owners. Use before shipping a significant recommendation, design, large branch, or multi-agent release, or when asked to tear something apart, be brutally honest, or poke holes in it.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Before shipping a recommendation, challenge it. Models still tend to agree with their own earlier reasoning and with the user, and to read a capable-looking artifact as good. A reviewer that shares the author's context inherits the author's blind spots, so the review is strongest when the reviewer doesn't share them.
Two rules govern the whole review. Search like a pessimist: assume defects exist, and treat finding none as a sign the search wasn't hard enough yet. Report like a scientist: say only what survives as a real, evidenced defect. The first rule sets how hard you look; the second sets what you say. A manufactured finding is as damaging as flattery, because it teaches the author to discount the next real one.
vibe-quality-loop)vibe-slop-filter)In order of preference:
Give the reviewer the artifact, the goals and constraints, the expert lens below, and this skill's 5 dimensions. Don't give it your own assessment.
Skepticism without domain standards is contrarianism. Before writing a critical word, name the senior expert whose standards govern this artifact, and review from inside that person's judgment:
If the artifact spans domains, name two or three lenses. If the right expert is genuinely unclear, ask one question first; reviewing from the wrong standard wastes the pass.
The expertise sits in the reviewer's chair; the charity is withheld from the author. Hold the work to the standard of the best in its field and treat every shortfall as a real defect, but don't invent errors or strawman it. Steelman what's there, then break it where it actually breaks.
file:line, or a concrete failure scenario). "The design is weak" is not a finding; "Section 3 names the retry budget as the goal but nothing defines how it's measured" is. Drop what you can't support.Run your own review through the same standard:
Three real defects and two named strengths beat ten findings, six of which are noise.
One reviewer carries one set of blind spots, and unverified findings waste fix cycles. For a release or content lock:
file:line, severity). Pick lenses that fit the product, for example: editorial and tone, facts and privacy, UX and accessibility, engineering and performance.vibe-workstream-orchestration), then re-run only the affected lenses.If the harness supports scripted workflows, run the panel as one: it verifies more rigorously than routing findings by hand.
Reviewer: [different model / fresh subagent / self] Expert lens: [e.g. principal engineer, maintains payment systems at scale]
| Dimension | Score | Issues |
|---|---|---|
| Consistency | X/5 | [count] |
| Completeness | X/5 | [count] |
| Actionability | X/5 | [count] |
| Alignment | X/5 | [count] |
| Risk | X/5 | [count] |
[rationale]
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Validates completed work against defined acceptance criteria. Use after completing a task that has specific success criteria defined in issues, specs, or task descriptions.
The English summary is being prepared. Showing the original description.
Generates edge case, failure mode, and spec-driven test cases. Covers boundary values, nil inputs, concurrency, resource exhaustion, malformed data, and requirement-linked traceability tests. Use after happy-path tests exist and before claiming coverage is complete, when requirements lack tests, or before a security review.
The English summary is being prepared. Showing the original description.
Catches shortcuts and reward hacking — weakening or deleting tests to make them pass, hard-coding expected outputs, silently dropping requirements, or claiming work is done without running it. Use before declaring a task complete and whenever a test or requirement feels like it's in the way.
The English summary is being prepared. Showing the original description.
Safely integrates commits from parallel agent branches using sequential cherry-pick. Use after parallel work completes in isolated branches or worktrees.
The English summary is being prepared. Showing the original description.
Audits tests for concurrency safety — race conditions, shared mock state, cleanup ordering. Use when writing tests that involve goroutines, async operations, or shared mutable state.
The English summary is being prepared. Showing the original description.
Enforces tiered test coverage standards with three dimensions — line coverage by tier, spec-to-test traceability, and spec-to-code implementation mapping. Use before claiming code is complete.
The English summary is being prepared. Showing the original description.