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
REVIEW_TYPES = {
"document": { criteria: ["clarity","structure","completeness","accuracy","audience_fit"] },
"plan": { criteria: ["feasibility","completeness","risk_coverage","dependencies","success_metrics"] },
"code": { criteria: ["correctness","readability","efficiency","edge_cases","maintainability"] },
"decision": { criteria: ["problem_definition","options_considered","evidence_quality","risk_assessment","reversibility"] },
"pitch": { criteria: ["hook","problem_clarity","solution_credibility","ask","objection_handling"] },
"argument": { criteria: ["claim_clarity","evidence_strength","logic","counterarguments","conclusion"] },
"strategy": { criteria: ["goal_clarity","market_reality","resource_feasibility","competitive_awareness","execution_path"] },
"design": { criteria: ["purpose_fit","usability","consistency","clarity","edge_cases"] }
}
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:
ASSESSMENT_SCALE = {
"strong": "Works well. No action needed. Worth noting so the user knows what to keep.",
"adequate": "Functional but could be stronger. Worth improving if time allows.",
"weak": "Noticeably limiting the effectiveness. Should be addressed.",
"missing": "Required for this to work and not present. Must be addressed."
}
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
def prioritize_feedback(issues):
critical = [i for i in issues if i.blocks_success or i.is_missing]
important = [i for i in issues if i.significantly_limits_effectiveness]
minor = [i for i in issues if i.is_polish_level]
return {
"fix_first": critical, # Must address before this goes further
"fix_if_able": important, # Will meaningfully improve outcome
"optional": minor # Worth noting, not worth delaying for
}
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:
REVIEW_FORMAT = {
"verdict": one sentence overall assessment — strong / solid / needs work / not ready,
"what_works": 2-3 specific strengths worth preserving (brief),
"fix_first": critical issues with specific suggested fixes,
"fix_if_able": important improvements with specific suggestions,
"optional": minor polish items (can be a list, kept short),
"bottom_line": one sentence on what would make this significantly stronger
}
Feedback Delivery Standards
Be specific:
- Weak: "The structure is confusing."
- Strong: "The key finding appears in paragraph four. Move it to paragraph one.
The reader should not have to search for the most important thing."
Suggest fixes, not just problems:
- Weak: "This argument is not convincing."
- Strong: "This claim needs evidence. Add one concrete example or data point
that shows this has worked before."
Calibrate to stakes:
CALIBRATION = {
"low_stakes": "Be efficient. Flag the top 2-3 issues. Do not over-engineer feedback.",
"high_stakes": "Be thorough. Cover all criteria. Miss nothing that could cause failure.",
"time_limited":"Lead with the single most important change. Everything else is secondary."
}
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
what they are being asked to do
Quality Check Before Delivering
