code-review
Review changes in clickhouse-java for correctness, compatibility, API stability, and missing tests. Use when reviewing pull requests, commits, diffs, patches, or when the user asks for a code review.
Works with
--- name: code-review description: Review changes in clickhouse-java for correctness, compatibility, API stability, and missing tests. Use when reviewing pull requests, commits, diffs, patches, or when the user asks for a code review. license: Apache-2.0 --- # Code Review ## Required context Before reviewing, read: - `AGENTS.md` - `docs/ai-review.md` If the review touches `client-v2` or `jdbc-v2`, also read: - `docs/features.md` ## Review workflow 1. Identify the changed module and any compatibility-sensitive surfaces. 2. Check correctness, regressions, API and behavior stability, JDBC or R2DBC semantics, and missing focused tests before style suggestions. 3. Use common Java and driver behavior as a comparison aid, but preserve existing project behavior unless the change is intentionally user-visible. 4. Report findings first, ordered by severity, then open questions or assumptions, then a brief summary. ## Final response requirements State: - what changed - whether compatibility risk exists - what tests were run, or why they were not run - whether docs should change If no issues are found, say so explicitly and mention residual risk or testing gaps.
More Code Review skills
pr-to-video
heygen-com/hyperframes
Turn a GitHub pull request (a PR URL, owner/repo#N, or 'this PR' in a checked-out repo) into a code-change explainer video — changelog, feature reveal, fix, or refactor walkthrough built from the diff, commits, and files: the input is a code change, not a website. Not a product promo (/product-launch-video) or a no-PR topic explainer (/faceless-explainer). Unclear → /hyperframes.
receiving-code-review
obra/superpowers
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
public-relations
coreyhaines31/marketingskills
When the user wants help with public relations, earned media, press coverage, journalist outreach, or media strategy (not pull requests). Also use when the user mentions 'PR,' 'public relations,' 'press,' 'press release,' 'press coverage,' 'media outreach,' 'pitch a journalist,' 'get featured,' 'media list,' 'media kit,' 'press kit,' 'newsjacking,' 'news hijack,' 'HARO,' 'Qwoted,' 'Featured,' 'Help A Reporter,' 'reporter request,' 'tech press,' 'TechCrunch,' 'earned media,' 'thought leadership placement,' 'op-ed,' 'guest article,' 'press contacts,' 'podcast prep,' 'going on a podcast,' 'podcast guest,' 'prep me for this podcast,' or 'how do I get press.' Use this for earned media work — finding journalists, pitching stories, newsjacking, prepping podcast appearances, and responding to press requests. For startup/SaaS/AI directory submissions, see directory-submissions. For product launches, see launch. For social-media engagement, see social. For cold-email outreach to prospects, see cold-email.
