review-this

name	review-this
description	Produce a structured review of code or documentation with category ratings, an overall score, a checklist, and actionable improvement suggestions. Use when the user asks for a review, feedback, or critique.
license	Apache-2.0
metadata	{"source":".prompts/review-this.md","version":"1.0"}

Review Code or Documentation

• Familiarize yourself with the project or item (code, docs, or related files).
• Give a 0–10 rating (10 = excellent, 0 = poor) with an emoji reaction and a short rationale.
• Provide both category ratings and an overall rating.
• Provide a summary checklist (✅ = good, ⚠️ = needs work, ❌ = missing).
• Suggest improvements clearly — don’t sugarcoat; highlight challenges.
• Keep reviews concise and structured: bullet list + rationale > long essay.

Rating Criteria

For Code

Rate across the following dimensions:

Code Quality

• Readability: Is the code easy to follow?
• Consistency: Style/formatting consistent? Follows language conventions?
• Simplicity: Is logic as simple/clear as possible?
• Correctness: Any obvious bugs or questionable logic?

Architecture & Design

• Modularity: Is code broken into reusable, composable units?
• Separation of Concerns: Responsibilities well-distributed across modules?
• Scalability: Can design handle growth in users, data, or features?
• Extensibility: How easy is it to add a new feature?
• Testability: Is code structured to be easily testable?

Maintainability

• Documentation: README, CONTRIBUTING guides, inline comments, user docs?
• Test Coverage: Are there meaningful unit/functional tests?
• Error Handling: Failures handled gracefully with clear diagnostics?
• Dependency Management: Dependencies minimal, current, and well managed?

Performance & Efficiency

• Resource Use: CPU, memory, disk, and network efficiency.
• Benchmarking: Any tools or results for performance testing?
• Latency / Critical Path: Is latency profile optimized? Critical tasks offloaded?

Security

• Input Validation: Is user input sanitized/validated?
• Secrets Management: Are secrets excluded from code, handled safely?
• Least Privilege: APIs/components scoped to minimum access?

Resiliency

• Defensive Programming: Safe handling of maps, arrays, error returns?
• Failure Scenarios: Handles dependency issues (HTTP errors, DB failures, etc.)?

For Documentation

Rate across the following dimensions:

• Substance: Does it cover what readers need?
• Packaging: Is it structured logically?
• Accuracy: Is it factually correct and up to date?
• Effectiveness: Does it help the intended audience?
• Clarity: Is it clear and free of ambiguity?
• Quality: Overall professionalism and polish.

Output Format

1. Category Ratings (0–10 each) with short rationale.
2. Overall Rating (0–10) with emoji + brief explanation.
3. Checklist Summary (✅/⚠️/❌).
4. Suggestions for Improvement (specific, concise, actionable).