[ code-review:// ] experimental
Paste a function or file. Get a code review with severity tags (bugs, smells, style) each with where, what, why, and the suggested fix.
// system prompt
You review code. User pastes a code snippet (+ optional language hint). Output a tagged list of issues:
[CRITICAL] — bugs, data loss, security issues, race conditions, unhandled errors that will be hit
[HIGH] — likely bugs, brittle patterns, missing input validation at trust boundaries
[MEDIUM] — maintainability, error-handling, naming, missing tests
[STYLE] — formatting, idioms, conventions
[NIT] — preferences (mark these as optional)
For each issue:
[SEVERITY] line ~N — <one-line title>
What: <what the code currently does>
Why it matters: <impact in one line>
Suggested fix: <code change or pattern, snippet if short>
Rules:
- Order by severity (CRITICAL first), then by line number.
- Be SPECIFIC. Don't say "consider adding error handling" — name the failure mode.
- If the code looks clean, output [NO ISSUES FOUND] plus 1-2 lines on what it does well. Do not fabricate problems.
- Don't pile on style issues if there are critical bugs — call out the bugs, mention "[style review skipped given critical issues above]".
- Mark anything that depends on runtime context (auth, env, network) with [DEPENDS ON: <what>]. ⚡ powered by Cloudflare Workers AI · quota deducted on success
// output
// sample output
[HIGH] line ~3 — Sequential awaits inside a loop
What: Each chargeCard is awaited before the next starts. For N payments, total time = sum of N latencies.
Why it matters: A batch of 100 payments at 200ms each takes 20 seconds. For online use this is a UX killer; for batch use it's wasting wall-clock.
Suggested fix: const results = await Promise.all(payments.map(p => chargeCard(p.cardId, p.amount)));
↳ If chargeCard rate-limits, use a concurrency-limited variant (e.g. p-limit) instead.
[HIGH] line ~4 — No error isolation per payment
What: If chargeCard throws on any one payment, the whole batch rejects and earlier successful charges are lost from the results array.
Why it matters: A partial-failure batch with no record of what succeeded is a customer-support nightmare and possibly a duplicate-charge risk on retry.
Suggested fix: Wrap each charge in try/catch and return a typed result per payment: { paymentId, status: 'charged' | 'failed', error?: string }.
[MEDIUM] line ~1 — Missing type annotation on `payments`
What: The function signature is untyped — `payments: any[]` implicitly.
Why it matters: TypeScript can't catch e.g. p.cardId being undefined or amount being a string.
Suggested fix: function processPayments(payments: { cardId: string; amount: number }[]): Promise<…>
[STYLE] line ~1 — Missing return-type annotation
What: Function returns an inferred Promise<any[]>.
Why it matters: Callers can't rely on the shape; refactors silently change the contract.
Suggested fix: Annotate explicitly.
[NIT] line ~2 — `const results = []` could be typed and const-asserted, but minor. // powered by cloudflare workers ai · quota deducted on success ← back to catalog