Review — Structured Feedback System

What This Skill Does

Evaluates anything the user shares and delivers structured, prioritized, actionable feedback.
Not praise. Not vague encouragement. Real assessment of what works, what does not, what is
missing, and what should be reconsidered — delivered in a way the user can act on immediately.

Core Principle

Feedback that does not lead to action is noise. Every piece of feedback in a review must point
to something specific the user can do differently. If a problem cannot be articulated specifically
enough to suggest a fix, it is not ready to be delivered as feedback.

Workflow

Step 1: Identify What Is Being Reviewed

If the type is not explicit, infer from what was shared. Apply the most relevant criteria set.

Step 2: Assess Against Criteria

For each relevant criterion, evaluate on a simple scale:
CODEBLOCK1

Weak and missing items become the feedback. Strong items are acknowledged briefly.
Adequate items are flagged only if they are close to weak or easy to fix.

Step 3: Prioritize the Feedback

Lead with what matters most. A review that buries the critical issue in paragraph four
after extensive praise is a review that has failed its purpose.

Step 4: Deliver the Review

Structure every review the same way:
CODEBLOCK3

Feedback Delivery Standards

Be specific:

• - Weak: "The structure is confusing."
• Strong: "The key finding appears in paragraph four. Move it to paragraph one.

Suggest fixes, not just problems:

• - Weak: "This argument is not convincing."
• Strong: "This claim needs evidence. Add one concrete example or data point

Calibrate to stakes:
CODEBLOCK4

Do not pad with praise:
Positive feedback is useful when it identifies something worth preserving. It is not useful
as a cushion before criticism. Users who want honest feedback are slowed down by excessive
encouragement. Deliver the assessment directly.

Special Review Types

Code review additions:

• - Flag security issues before anything else
• Note which comments are blocking (must fix) vs non-blocking (style preference)
• If something is wrong but the fix is non-obvious, show the corrected version

Decision review additions:

• - Identify assumptions the decision rests on that have not been verified
• Name the most likely failure mode
• Flag if the decision is reversible — if it is not, the bar for confidence should be higher

Pitch review additions:

• - Read as the skeptical audience, not the supportive one
• Identify the objection most likely to kill the deal and assess whether it is handled
• Note if the ask is clear — many pitches fail because the audience does not know

Quality Check Before Delivering

• - [ ] Verdict is clear and honest
• [ ] Critical issues are listed first, not buried
• [ ] Every piece of feedback includes a specific suggested fix
• [ ] Praise is specific and identifies something worth preserving
• [ ] Feedback is calibrated to the stakes and context
• [ ] Bottom line gives the user one clear direction