Review this code as a senior engineer would in a pull request. ```{language} {code} ``` Context: {what_the_code_does} Review priorities, in order: 1. Correctness bugs and unhandled edge cases (empty input, concurrency, error paths) 2. Security issues (injection, unvalidated input, secrets in code) 3. Readability and naming 4. Performance — only if there is a real problem, not micro-optimization Format each finding as: [severity] file/line — issue — suggested fix. Do not pad the review; if the code is fine, say so and stop.

Help me debug this error. Diagnose before proposing fixes. Error message / stack trace: {error_output} Relevant code: ```{language} {code} ``` What I expected: {expected_behavior} What I already tried: {attempts} Work through it in this order: 1. What the error literally means 2. The most likely root cause given the code, and 2 alternative causes ranked by probability 3. One cheap check to confirm the root cause before changing anything (a log line, a breakpoint, a minimal repro) 4. The fix — only after steps 1-3 Do not suggest 'try X and see if it works' fixes without a hypothesis.

Refactor this code without changing its observable behavior. ```{language} {code} ``` What bothers me about it: {pain_points} Constraints: - Public API and behavior must stay identical — no signature changes unless flagged separately - No new dependencies - Match the existing style of the codebase: {style_notes} Output: 1. The refactored code, complete and runnable 2. A bullet list of each change and why it improves the code 3. Anything you deliberately did NOT change and why (so I don't think you missed it) 4. Which existing tests should catch a regression here — or a note that coverage is missing

Write unit tests for this function. ```{language} {code} ``` Test framework: {test_framework} How it is called in production: {usage_context} Requirements: - Cover the happy path, boundary values, and every error path visible in the code - One behavior per test; test names describe the behavior ('returns_empty_list_when_no_matches'), not the method - No mocking anything that can run for real; mock only external I/O - Include at least one test you expect to FAIL against the current code if you spot a probable bug — mark it with a comment After the tests, list any behaviors that cannot be tested without refactoring, and what change would make them testable.

Write a commit message for this diff. ```diff {diff} ``` Extra context (why, ticket, etc.): {context} Format: - Subject: imperative mood, under 50 characters, no trailing period. Use conventional commit prefix ({commit_convention}) if one fits - Blank line, then a body explaining WHY the change was made, not what changed (the diff shows what) - If the diff mixes unrelated changes, say so and propose how to split it into separate commits instead of writing one blended message

Explain this code to me. I need to modify it safely. ```{language} {code} ``` What I need to change: {planned_change} Explain: 1. What it does, top-down: one-paragraph summary, then a walkthrough of the non-obvious parts only 2. Hidden contracts: invariants, ordering assumptions, side effects, and anything a caller depends on that isn't obvious from signatures 3. Where my planned change is most likely to break something, specifically 4. Any code that looks dead, duplicated, or suspicious — flagged, not fixed Skip line-by-line narration of obvious code.

Write a regex for this pattern and prove it works. What it should match: {match_requirements} What it must NOT match: {non_match_examples} Regex flavor / language: {regex_flavor} Output: 1. The regex 2. A piece-by-piece breakdown of what each part does 3. A test table: at least 5 strings that should match and 5 that should not, with the expected result for each 4. Known limitations — inputs where the regex gives the wrong answer, and whether a regex is even the right tool here Prefer readable over clever; use named groups and comments/verbose mode if the flavor supports them.

Review this API design before I implement it. Proposed endpoints / function signatures: {api_design} Who will call it: {consumers} Expected scale and constraints: {constraints} Evaluate: 1. Naming and consistency — do resources, verbs, and parameter names follow one predictable convention 2. Error handling — are failure modes explicit, and can a caller distinguish 'bad request' from 'try again later' 3. Evolution — what breaks when we add a field, paginate, or version this; what should be future-proofed now vs deferred 4. The one design decision most likely to be regretted in a year Suggest concrete revisions to signatures, not general principles.